From b0dcef704c0ceaa242af82afc3b64a59c7c1e542 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Sun, 15 Jan 2023 18:45:43 +0100 Subject: [PATCH 01/15] Update gnu custom file --- bundle/custom_gnu.el | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/bundle/custom_gnu.el b/bundle/custom_gnu.el index 696decd8..1655f85c 100644 --- a/bundle/custom_gnu.el +++ b/bundle/custom_gnu.el @@ -15,10 +15,9 @@ (width . 95) (height . 66) (alpha . 100) - (horizontal-scroll-bars) (vertical-scroll-bars) - (fullscreen . maximized) - (undecorated . t))) + (horizontal-scroll-bars) + (fullscreen . maximized))) '(delete-selection-mode nil) '(diary-file "~/Documents/diary/diary") '(gnus-init-file "~/.emacs.d/.gnus.el") @@ -74,5 +73,5 @@ ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. - '(font-lock-keyword-face ((t (:foreground "#81A1C1" :slant italic)))) + '(font-lock-keyword-face ((t (:slant italic)))) '(variable-pitch ((t (:weight semi-light :height 1.2 :family "Roboto Slab"))))) From 442f1d0d56a141ddfc1f0302550a0a3049d83ac1 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Mon, 16 Jan 2023 17:53:30 +0100 Subject: [PATCH 02/15] Update slime package --- bundle/bundle--package.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bundle/bundle--package.el b/bundle/bundle--package.el index 2d79f0c5..49f79fff 100644 --- a/bundle/bundle--package.el +++ b/bundle/bundle--package.el @@ -168,8 +168,10 @@ :defer t :custom (slime-autodoc-use-multiline-p 1) + :bind ("C-c C-q" . slime-close-all-parens-in-sexp) :config (slime-setup '(slime-autodoc + slime-banner slime-tramp slime-fancy slime-asdf From be5125e79f251c611c87d3d5f570c368d9348180 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Mon, 16 Jan 2023 17:53:50 +0100 Subject: [PATCH 03/15] Update --ux --- bundle/bundle--ux.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bundle/bundle--ux.el b/bundle/bundle--ux.el index 2235537a..e57703da 100644 --- a/bundle/bundle--ux.el +++ b/bundle/bundle--ux.el @@ -190,7 +190,7 @@ "https://www.interaction-design.org/") "Important websites for UX topics.") -(defvar ux:explain-codes +(defvar ux:behavior-model '((gain "Something wanted or Desirable." "I want to be a great scientist, bring humanity a step forward.") @@ -211,7 +211,7 @@ "I need to figure out the postal address of the university, using their website.")) "Explain codes used for thematic analysis.") -(defvar ux:map-codes-to-questions +(defvar ux:behavior-to-questions '((activity . how) (job . what) (objective . why) From 2d68650ceee0c20f9902e0df530ec39038bd52b9 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Mon, 16 Jan 2023 17:54:11 +0100 Subject: [PATCH 04/15] Update customfile for win32 --- bundle/custom_win32_EVG02667NB.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bundle/custom_win32_EVG02667NB.el b/bundle/custom_win32_EVG02667NB.el index 44827c7f..92c8ac52 100644 --- a/bundle/custom_win32_EVG02667NB.el +++ b/bundle/custom_win32_EVG02667NB.el @@ -49,6 +49,7 @@ ("FIXME" . "#dc752f") ("XXX+" . "#dc752f") ("\\?\\?\\?+" . "#dc752f"))) + '(inferior-lisp-program "C:/Program Files/Steel Bank Common Lisp/sbcl.exe --noinform" t) '(initial-buffer-choice "d:/UserData/marcus.kammer/OneDrive - Siemens AG/journal/tasks.org") '(initial-frame-alist '((fullscreen . maximized))) @@ -91,5 +92,5 @@ ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. - '(font-lock-keyword-face ((t (:foreground "#81A1C1" :slant italic)))) - '(variable-pitch ((t (:height 1.1 :family "Fira Sans"))))) + '(font-lock-keyword-face ((t (:slant italic)))) + '(variable-pitch ((t (:weight semi-light :height 1.2 :family "Roboto Slab Light"))))) From 1e8581c9adee1aa3f367e70e7741fa93ad8a3222 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Mon, 16 Jan 2023 17:55:50 +0100 Subject: [PATCH 05/15] Update custom file gnu --- bundle/custom_gnu.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bundle/custom_gnu.el b/bundle/custom_gnu.el index 1655f85c..e61f2764 100644 --- a/bundle/custom_gnu.el +++ b/bundle/custom_gnu.el @@ -13,7 +13,7 @@ '((tab-bar-lines . 0) (font . "MonoLisa-12") (width . 95) - (height . 66) + (height . 50) (alpha . 100) (vertical-scroll-bars) (horizontal-scroll-bars) From a81ce874b71099ca359fa6b328695d35b6e07c73 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 10:43:57 +0100 Subject: [PATCH 06/15] Use another value for olivetti body width with info mode --- bundle/bundle--gui.el | 2 +- quickurls | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) create mode 100644 quickurls diff --git a/bundle/bundle--gui.el b/bundle/bundle--gui.el index ccdc8d05..586c5e3d 100644 --- a/bundle/bundle--gui.el +++ b/bundle/bundle--gui.el @@ -28,7 +28,7 @@ :custom (olivetti-body-width 89) :bind ("" . olivetti-mode)) -(add-hook 'Info-mode-hook 'olivetti-mode) +(add-hook 'Info-mode-hook (lambda () (setq olivetti-body-width 73) (olivetti-mode))) (use-package ace-window :init (global-set-key (kbd "M-o") 'ace-window)) diff --git a/quickurls b/quickurls new file mode 100644 index 00000000..7d04e08f --- /dev/null +++ b/quickurls @@ -0,0 +1,3 @@ +;; -*- lisp -*- + +(("yale_edu" . "https://usability.yale.edu/")) From 1fd5a9e722290f1dfb8a5f543b095aab231c02e4 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 10:44:30 +0100 Subject: [PATCH 07/15] Update --ux --- bundle/bundle--ux.el | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bundle/bundle--ux.el b/bundle/bundle--ux.el index e57703da..d7e63f9e 100644 --- a/bundle/bundle--ux.el +++ b/bundle/bundle--ux.el @@ -183,11 +183,11 @@ "What do we want to learn from users or/and customers?") (defvar ux:websites - '("https://usability.yale.edu/" - "https://webaim.org/" - "https://digital.gov/" - "https://www.nngroup.com/articles/" - "https://www.interaction-design.org/") + '(("Yale Education" . "https://usability.yale.edu/") + ("Web Community" . "https://webaim.org/") + ("Digital Gov" . "https://digital.gov/") + ("Norman Group" . "https://www.nngroup.com/articles/") + ("IDF" . "https://www.interaction-design.org/")) "Important websites for UX topics.") (defvar ux:behavior-model From 3db3f493ebd069a36b58c9e08e62fa8bec526d7d Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 10:47:00 +0100 Subject: [PATCH 08/15] Move urls to quickurls --- bundle/bundle--ux.el | 8 -------- quickurls | 6 +++++- 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/bundle/bundle--ux.el b/bundle/bundle--ux.el index d7e63f9e..ec7c66b9 100644 --- a/bundle/bundle--ux.el +++ b/bundle/bundle--ux.el @@ -182,14 +182,6 @@ "Problems and frustrations with current products (or an analogous system if no current product exists).")) "What do we want to learn from users or/and customers?") -(defvar ux:websites - '(("Yale Education" . "https://usability.yale.edu/") - ("Web Community" . "https://webaim.org/") - ("Digital Gov" . "https://digital.gov/") - ("Norman Group" . "https://www.nngroup.com/articles/") - ("IDF" . "https://www.interaction-design.org/")) - "Important websites for UX topics.") - (defvar ux:behavior-model '((gain "Something wanted or Desirable." diff --git a/quickurls b/quickurls index 7d04e08f..4443d73f 100644 --- a/quickurls +++ b/quickurls @@ -1,3 +1,7 @@ ;; -*- lisp -*- -(("yale_edu" . "https://usability.yale.edu/")) +(("yale_edu" . "https://usability.yale.edu/") + ("web_community" . "https://webaim.org/") + ("digital_gov" . "https://digital.gov/") + ("norman_group" . "https://www.nngroup.com/articles/") + ("IDF" . "https://www.interaction-design.org/")) From 50133ed3f72b50b1f690ad265345593b45b45d32 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 11:23:34 +0100 Subject: [PATCH 09/15] Use buffer local binding for olivetti body width --- bundle/bundle--gui.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bundle/bundle--gui.el b/bundle/bundle--gui.el index 586c5e3d..cf7b4e37 100644 --- a/bundle/bundle--gui.el +++ b/bundle/bundle--gui.el @@ -28,7 +28,7 @@ :custom (olivetti-body-width 89) :bind ("" . olivetti-mode)) -(add-hook 'Info-mode-hook (lambda () (setq olivetti-body-width 73) (olivetti-mode))) +(add-hook 'Info-mode-hook (lambda () (make-local-variable 'olivetti-body-width) (setq olivetti-body-width 73) (olivetti-mode))) (use-package ace-window :init (global-set-key (kbd "M-o") 'ace-window)) From 9099bd0bf1fa4e04fe7d3f41aceab36b0ba40803 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 20:30:47 +0100 Subject: [PATCH 10/15] Update clones Add HyperSpec --- .../HyperSpec-7-0/HyperSpec-Legalese.text | 150 + .../lisp/HyperSpec-7-0/HyperSpec-README.text | 41 + .../lisp/HyperSpec-7-0/HyperSpec/Body/00_.htm | 335 + .../lisp/HyperSpec-7-0/HyperSpec/Body/01_.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/01_a.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/01_aa.htm | 27 + .../HyperSpec-7-0/HyperSpec/Body/01_ab.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/01_b.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/01_c.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/01_d.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/01_da.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/01_daa.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/01_dab.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/01_daba.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/01_dabb.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/01_dabc.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/01_dac.htm | 103 + .../HyperSpec-7-0/HyperSpec/Body/01_dad.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/01_dada.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/01_dadb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_dadc.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/01_dadd.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/01_dae.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/01_daf.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/01_db.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/01_dc.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/01_dd.htm | 97 + .../HyperSpec-7-0/HyperSpec/Body/01_dda.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_ddb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_ddd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_dde.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/01_ddf.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/01_ddfa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/01_ddfb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_ddfc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddfd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddg.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddh.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddi.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddj.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddk.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddl.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddm.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/01_ddn.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/01_ddo.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddp.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddq.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ddr.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_dds.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_ddt.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/01_ddta.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/01_ddtb.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/01_ddtc.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/01_ddtd.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/01_ddtda.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/01_ddtdb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/01_ddu.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_ddv.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_e.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/01_ea.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/01_eaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_eab.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_eac.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_ead.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/01_eada.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/01_eadaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_eae.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/01_eb.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/01_eba.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/01_ebaa.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/01_ebb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_f.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/01_g.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/01_h.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/01_ha.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/01_hb.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/01_hc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_hd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/01_i.htm | 526 + .../lisp/HyperSpec-7-0/HyperSpec/Body/02_.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/02_a.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/02_aa.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/02_aaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_aab.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/02_aac.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_ab.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_ac.htm | 106 + .../HyperSpec-7-0/HyperSpec/Body/02_ad.htm | 83 + .../HyperSpec-7-0/HyperSpec/Body/02_ada.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_adb.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/02_adc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_add.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_ade.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_adea.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/02_adf.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_adfa.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/02_adg.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_adga.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/02_b.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/02_c.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/02_ca.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/02_caa.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/02_caaa.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_caab.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/02_cb.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/02_cba.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_cbaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/02_cbab.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/02_cbb.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/02_cbc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/02_cc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_cd.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/02_ce.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/02_cf.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/02_d.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/02_da.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/02_db.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_dc.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_dca.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_dd.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/02_dda.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_ddb.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/02_ddba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_ddbb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_ddbc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_ddbd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_ddbe.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/02_de.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/02_df.htm | 87 + .../HyperSpec-7-0/HyperSpec/Body/02_dfa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/02_dg.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_dh.htm | 138 + .../HyperSpec-7-0/HyperSpec/Body/02_dha.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_dhb.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_dhc.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/02_dhd.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/02_dhda.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/02_dhe.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/02_dhf.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/02_dhg.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/02_dhh.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/02_dhi.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/02_dhj.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/02_dhk.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/02_dhl.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/02_dhm.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/02_dhn.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/02_dho.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/02_dhp.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/02_dhq.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/02_dhr.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/02_dhs.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/02_dhsa.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/02_dhsb.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/02_dht.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_dhu.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/02_dhv.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/02_di.htm | 29 + .../lisp/HyperSpec-7-0/HyperSpec/Body/03_.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/03_a.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/03_aa.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/03_aaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/03_aab.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_aac.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/03_aaca.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/03_aad.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_ab.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_aba.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/03_abaa.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/03_abaaa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_abaab.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/03_abaac.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/03_abaad.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/03_abab.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/03_ababa.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/03_ababb.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/03_ababc.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/03_ababd.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_abac.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/03_abaca.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/03_ac.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_ad.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/03_ae.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/03_af.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/03_ag.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/03_b.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/03_ba.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/03_bb.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/03_bba.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/03_bbaa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_bbab.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_bbac.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/03_bbaca.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_bbb.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/03_bbc.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/03_bc.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/03_bca.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/03_bcaa.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/03_bcab.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_bd.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/03_bda.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/03_bdb.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/03_bdba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/03_bdbb.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/03_bdc.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_bdd.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/03_be.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/03_c.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/03_ca.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/03_cb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/03_cc.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/03_cca.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/03_cd.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/03_cda.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/03_d.htm | 95 + .../HyperSpec-7-0/HyperSpec/Body/03_da.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/03_daa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/03_dab.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/03_dac.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/03_dad.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/03_dada.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/03_dadaa.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/03_dae.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/03_daf.htm | 92 + .../HyperSpec-7-0/HyperSpec/Body/03_db.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/03_dc.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/03_dd.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/03_dda.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/03_ddaa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_ddaaa.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/03_ddab.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/03_de.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/03_df.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/03_dg.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/03_dh.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_di.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/03_dj.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/03_dk.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/03_e.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_ea.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/03_eaa.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/03_eaaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/03_eab.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_eac.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_ead.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_eae.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_eaf.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/03_eag.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/03_eah.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/03_f.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/03_g.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/03_ga.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/03_gb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/03_gba.htm | 44 + .../lisp/HyperSpec-7-0/HyperSpec/Body/04_.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/04_a.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/04_b.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/04_ba.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/04_bb.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/04_bc.htm | 153 + .../HyperSpec-7-0/HyperSpec/Body/04_c.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/04_ca.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/04_caa.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/04_cb.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/04_cc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/04_cd.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/04_cda.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/04_cdb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/04_ce.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/04_cea.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/04_ceb.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/04_cf.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/04_cfa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/04_cfb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/04_cfc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/04_cg.htm | 71 + .../lisp/HyperSpec-7-0/HyperSpec/Body/05_.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/05_a.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/05_aa.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/05_aaa.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/05_aaaa.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/05_aab.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/05_aaba.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/05_ab.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/05_aba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/05_abb.htm | 107 + .../HyperSpec-7-0/HyperSpec/Body/05_abc.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/05_abd.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/05_abe.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/05_abf.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/05_abg.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/05_abh.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/05_abi.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/05_ac.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/05_b.htm | 36 + .../lisp/HyperSpec-7-0/HyperSpec/Body/06_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/06_a.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/06_aa.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/06_aaa.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/06_aaaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/06_aaab.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/06_aab.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/06_aac.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/06_aad.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/06_aae.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/06_aaea.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/06_aaeb.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/06_aaec.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/06_aaed.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/06_aaee.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/06_aaef.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/06_aaf.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/06_aag.htm | 103 + .../HyperSpec-7-0/HyperSpec/Body/06_aah.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/06_ab.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/06_aba.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/06_abaa.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/06_abaaa.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/06_abab.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/06_ababa.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/06_abac.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/06_abaca.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/06_abad.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/06_abada.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/06_abae.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/06_abaea.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/06_abaf.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/06_abag.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/06_abaga.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/06_abb.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/06_abba.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/06_ac.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/06_aca.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/06_acb.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/06_acc.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/06_acd.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/06_ace.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/06_ad.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/06_ada.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/06_adb.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/06_adc.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/06_ae.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/06_aea.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/06_af.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/06_afa.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/06_ag.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/06_aga.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/06_agaa.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/06_agb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/06_ah.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/06_aha.htm | 99 + .../HyperSpec-7-0/HyperSpec/Body/06_ai.htm | 38 + .../lisp/HyperSpec-7-0/HyperSpec/Body/07_.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/07_a.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/07_aa.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/07_ab.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/07_ac.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/07_ad.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/07_ae.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/07_af.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/07_ag.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/07_b.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/07_ba.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/07_bb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/07_bc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/07_c.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/07_ca.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/07_d.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/07_da.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/07_e.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/07_ea.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/07_eb.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/07_ec.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/07_f.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/07_fa.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/07_fb.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/07_fc.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/07_fd.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/07_fe.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/07_fea.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/07_ff.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/07_ffa.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/07_ffaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/07_ffab.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/07_ffac.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/07_ffb.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/07_ffc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/07_ffd.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/07_fg.htm | 31 + .../lisp/HyperSpec-7-0/HyperSpec/Body/08_.htm | 36 + .../lisp/HyperSpec-7-0/HyperSpec/Body/09_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/09_a.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/09_aa.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/09_aaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/09_ab.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/09_aba.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/09_ac.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/09_aca.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/09_acaa.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/09_acab.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/09_acac.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/09_acad.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/09_acae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/09_ad.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/09_ada.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/09_adaa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/09_adb.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/09_adba.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/09_adbb.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/09_adbc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/09_adbd.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/09_ae.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/09_af.htm | 29 + .../lisp/HyperSpec-7-0/HyperSpec/Body/10_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/10_a.htm | 39 + .../lisp/HyperSpec-7-0/HyperSpec/Body/11_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/11_a.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/11_aa.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/11_aaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/11_aab.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/11_aaba.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/11_aabb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/11_aabc.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/11_aabd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/11_aabe.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/11_ab.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/11_aba.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/11_abaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/11_abab.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/11_ababa.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/11_abb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/11_abc.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/11_abca.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/11_abcb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/11_abd.htm | 30 + .../lisp/HyperSpec-7-0/HyperSpec/Body/12_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/12_a.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/12_aa.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/12_aaa.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/12_aaaa.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/12_aab.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/12_aac.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/12_aaca.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/12_aacb.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/12_ab.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/12_ac.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/12_aca.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/12_acb.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/12_acc.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/12_ad.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/12_ada.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/12_adaa.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/12_adb.htm | 27 + .../HyperSpec-7-0/HyperSpec/Body/12_adc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/12_add.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/12_ae.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/12_aea.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/12_aeb.htm | 28 + .../HyperSpec-7-0/HyperSpec/Body/12_aec.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/12_aeca.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/12_aed.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/12_af.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/12_ag.htm | 34 + .../lisp/HyperSpec-7-0/HyperSpec/Body/13_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/13_a.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/13_aa.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/13_ab.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/13_aba.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/13_abb.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/13_ac.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/13_ad.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/13_ada.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/13_adb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/13_adc.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/13_adca.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/13_adcb.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/13_adcc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/13_adcd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/13_add.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/13_ade.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/13_adf.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/13_ae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/13_af.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/13_ag.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/13_ah.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/13_ai.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/13_aj.htm | 29 + .../lisp/HyperSpec-7-0/HyperSpec/Body/14_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/14_a.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/14_aa.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/14_aaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/14_ab.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/14_aba.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/14_abb.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/14_abc.htm | 30 + .../lisp/HyperSpec-7-0/HyperSpec/Body/15_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/15_a.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/15_aa.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/15_aaa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/15_aab.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/15_aaba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/15_aac.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/15_aaca.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/15_aacaa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/15_aacb.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/15_aacba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/15_aacbb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/15_ab.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/15_aba.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/15_abb.htm | 51 + .../lisp/HyperSpec-7-0/HyperSpec/Body/16_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/16_a.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/16_aa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/16_ab.htm | 29 + .../lisp/HyperSpec-7-0/HyperSpec/Body/17_.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/17_a.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/17_aa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/17_b.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/17_ba.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/17_baa.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/17_bb.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/17_bba.htm | 40 + .../lisp/HyperSpec-7-0/HyperSpec/Body/18_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/18_a.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/18_aa.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/18_ab.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/18_aba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/18_abb.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/18_abba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/18_abbb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/18_abc.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/18_abca.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/18_abcb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/18_abcc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/18_abd.htm | 30 + .../lisp/HyperSpec-7-0/HyperSpec/Body/19_.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/19_a.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/19_aa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/19_ab.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/19_ac.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_b.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/19_ba.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/19_baa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bab.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bac.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bad.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_baf.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_bb.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/19_bba.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/19_bbaa.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/19_bbab.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/19_bbaba.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_bbabb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_bbb.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/19_bbba.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/19_bbbb.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/19_bbbc.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/19_bbbca.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_bbc.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/19_bbd.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/19_bbda.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bbdb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_bbdc.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/19_bbdca.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bbdd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bbde.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_bbdf.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/19_bbdg.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/19_bbe.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/19_bc.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/19_bca.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/19_c.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/19_ca.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/19_caa.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/19_caaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_caab.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_caac.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_caad.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_caae.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_caaf.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_caag.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_caah.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/19_cb.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/19_cba.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/19_cbb.htm | 29 + .../lisp/HyperSpec-7-0/HyperSpec/Body/20_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/20_a.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/20_aa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/20_ab.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/20_ac.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/20_aca.htm | 31 + .../lisp/HyperSpec-7-0/HyperSpec/Body/21_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/21_a.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/21_aa.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/21_aaa.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/21_aaaa.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/21_aaab.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/21_aaac.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/21_aab.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/21_aaba.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/21_aac.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/21_ab.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/21_ac.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/21_ad.htm | 30 + .../lisp/HyperSpec-7-0/HyperSpec/Body/22_.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/22_a.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/22_aa.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/22_aaa.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/22_aaaa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/22_ab.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/22_ac.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/22_aca.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/22_acaa.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_acab.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_acac.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/22_acad.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_acae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_acb.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/22_acc.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/22_acca.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/22_accb.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/22_accba.htm | 88 + .../HyperSpec-7-0/HyperSpec/Body/22_acd.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_ace.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/22_acf.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_acg.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/22_ach.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/22_aci.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/22_acj.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/22_ack.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/22_acl.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/22_acm.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/22_ad.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/22_b.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/22_ba.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/22_baa.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/22_bab.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/22_bac.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_bad.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/22_bae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_bb.htm | 236 + .../HyperSpec-7-0/HyperSpec/Body/22_bc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_c.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/22_ca.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/22_caa.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/22_cab.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cac.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cad.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cb.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/22_cba.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/22_cbb.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/22_cbc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_cbd.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_cbe.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_cc.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/22_cca.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/22_ccb.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/22_ccc.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/22_ccd.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/22_cd.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/22_cda.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/22_cdb.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_cdc.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_ce.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/22_cea.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_ceb.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/22_cec.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/22_ced.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/22_cf.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/22_cfa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/22_cfb.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/22_cfc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cg.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/22_cga.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/22_cgb.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/22_cgc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cgd.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/22_cge.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cgf.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/22_ch.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/22_cha.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/22_chb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_chc.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/22_ci.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/22_cia.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cib.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/22_cic.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/22_cj.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/22_cja.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/22_cjb.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cjc.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_cjd.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/22_ck.htm | 128 + .../HyperSpec-7-0/HyperSpec/Body/22_cl.htm | 31 + .../lisp/HyperSpec-7-0/HyperSpec/Body/23_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/23_a.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/23_aa.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/23_ab.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/23_aba.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/23_ac.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/23_aca.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/23_acb.htm | 52 + .../lisp/HyperSpec-7-0/HyperSpec/Body/24_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/24_a.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/24_aa.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/24_ab.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/24_aba.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/24_abaa.htm | 59 + .../lisp/HyperSpec-7-0/HyperSpec/Body/25_.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/25_a.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/25_aa.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/25_ab.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/25_ac.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/25_ad.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/25_ada.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/25_adb.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/25_adc.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/25_add.htm | 33 + .../lisp/HyperSpec-7-0/HyperSpec/Body/26_.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/26_a.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_9.htm | 28 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_a.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_b.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_c.htm | 108 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_d.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_e.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_f.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_g.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_h.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_i.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_k.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_l.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_m.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_n.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_o.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_p.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_q.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_r.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_s.htm | 130 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_t.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_u.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_v.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_w.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/26_glo_y.htm | 28 + .../lisp/HyperSpec-7-0/HyperSpec/Body/27_.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/27_a.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/27_aa.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/27_ab.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/27_ac.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/27_ad.htm | 30 + .../HyperSpec-7-0/HyperSpec/Body/27_ae.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/27_af.htm | 29 + .../HyperSpec-7-0/HyperSpec/Body/27_ag.htm | 28 + .../lisp/HyperSpec-7-0/HyperSpec/Body/a__.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_abort.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_and.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_atom.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_bit.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_ch.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_comple.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_cons.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_contin.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_eql.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_error.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_float.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_fn.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_lambda.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_list.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_logica.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_member.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_method.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_mod.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_muffle.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_nil.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_not.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_null.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_or.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_pl.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_pn.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_ration.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_setf.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_sl.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_st.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_store_.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_string.htm | 21 + .../lisp/HyperSpec-7-0/HyperSpec/Body/a_t.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_type.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_use_va.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_values.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/a_vector.htm | 21 + .../HyperSpec-7-0/HyperSpec/Body/c_arrays.htm | 130 + .../HyperSpec-7-0/HyperSpec/Body/c_charac.htm | 87 + .../HyperSpec-7-0/HyperSpec/Body/c_condit.htm | 153 + .../HyperSpec-7-0/HyperSpec/Body/c_conses.htm | 172 + .../HyperSpec-7-0/HyperSpec/Body/c_data_a.htm | 232 + .../HyperSpec-7-0/HyperSpec/Body/c_enviro.htm | 119 + .../HyperSpec-7-0/HyperSpec/Body/c_evalua.htm | 118 + .../HyperSpec-7-0/HyperSpec/Body/c_filena.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/c_files.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/c_hash_t.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/c_iterat.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/c_number.htm | 262 + .../HyperSpec-7-0/HyperSpec/Body/c_object.htm | 151 + .../HyperSpec-7-0/HyperSpec/Body/c_packag.htm | 116 + .../HyperSpec-7-0/HyperSpec/Body/c_printe.htm | 121 + .../HyperSpec-7-0/HyperSpec/Body/c_reader.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/c_sequen.htm | 96 + .../HyperSpec-7-0/HyperSpec/Body/c_stream.htm | 193 + .../HyperSpec-7-0/HyperSpec/Body/c_string.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/c_struct.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/c_symbol.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/c_system.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/c_types_.htm | 98 + .../HyperSpec-7-0/HyperSpec/Body/d_declar.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/d_dynami.htm | 164 + .../HyperSpec-7-0/HyperSpec/Body/d_ftype.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/d_ignore.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/d_inline.htm | 83 + .../HyperSpec-7-0/HyperSpec/Body/d_optimi.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/d_specia.htm | 132 + .../HyperSpec-7-0/HyperSpec/Body/d_type.htm | 146 + .../HyperSpec-7-0/HyperSpec/Body/e_arithm.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_cell_e.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_cnd.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/e_contro.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/e_divisi.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/e_end_of.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_error.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/e_file_e.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_floa_1.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_floa_2.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/e_floa_3.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/e_floati.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_parse_.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/e_pkg_er.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_pr_not.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_progra.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/e_rder_e.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/e_seriou.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_smp_cn.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_smp_er.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/e_smp_tp.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/e_smp_wa.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/e_stm_er.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_storag.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_style_.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/e_tp_err.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/e_unbo_1.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/e_unboun.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/e_undefi.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/e_warnin.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/f_1pl_1_.htm | 65 + .../lisp/HyperSpec-7-0/HyperSpec/Body/f__.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_abortc.htm | 186 + .../HyperSpec-7-0/HyperSpec/Body/f_abs.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_acons.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_add_me.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_adjoin.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_adju_1.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_adjust.htm | 135 + .../HyperSpec-7-0/HyperSpec/Body/f_alloca.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_alpha_.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_alphan.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_append.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_apply.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_apropo.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_d_1.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_dim.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_dis.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_ele.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_has.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_in_.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_ran.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_row.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_ar_tot.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_aref.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_arithm.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_arrayp.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_ash.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_asin_.htm | 113 + .../HyperSpec-7-0/HyperSpec/Body/f_assocc.htm | 101 + .../HyperSpec-7-0/HyperSpec/Body/f_atom.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_boole.htm | 141 + .../HyperSpec-7-0/HyperSpec/Body/f_boundp.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_break.htm | 83 + .../HyperSpec-7-0/HyperSpec/Body/f_broadc.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/f_bt_and.htm | 112 + .../HyperSpec-7-0/HyperSpec/Body/f_bt_sb.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_bt_vec.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_butlas.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_by_by.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_call_n.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_car_c.htm | 229 + .../HyperSpec-7-0/HyperSpec/Body/f_cell_e.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/f_cerror.htm | 170 + .../HyperSpec-7-0/HyperSpec/Body/f_ch.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_char_.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_char_c.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_char_i.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_char_n.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/f_char_u.htm | 79 + .../HyperSpec-7-0/HyperSpec/Body/f_chareq.htm | 129 + .../HyperSpec-7-0/HyperSpec/Body/f_chg_cl.htm | 103 + .../HyperSpec-7-0/HyperSpec/Body/f_chp.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_cis.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_clas_1.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_class_.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_clear_.htm | 90 + .../HyperSpec-7-0/HyperSpec/Body/f_close.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_clrhas.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_cmp.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_cmp__1.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_cmp_fi.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/f_cmp_ma.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_cmpd_f.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/f_code_c.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_coerce.htm | 104 + .../HyperSpec-7-0/HyperSpec/Body/f_comp_1.htm | 93 + .../HyperSpec-7-0/HyperSpec/Body/f_comp_2.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_comp_3.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_comple.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/f_comput.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_conc_1.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/f_concat.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_conjug.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_cons.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_cons_1.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_consp.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_consta.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_countc.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_ali.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_lis.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_ppr.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_rdt.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_seq.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_stu.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_sym.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_cp_tre.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_dec_fl.htm | 135 + .../HyperSpec-7-0/HyperSpec/Body/f_dec_un.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_del_fi.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_del_pk.htm | 131 + .../HyperSpec-7-0/HyperSpec/Body/f_deposi.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_desc_1.htm | 87 + .../HyperSpec-7-0/HyperSpec/Body/f_descri.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_digi_1.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_digit_.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_dir.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/f_disass.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_docume.htm | 225 + .../HyperSpec-7-0/HyperSpec/Body/f_dpb.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_dribbl.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_echo_s.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_ed.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_elt.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_encode.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_endp.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_ensu_1.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_ensure.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_eq.htm | 97 + .../HyperSpec-7-0/HyperSpec/Body/f_eq_sle.htm | 102 + .../HyperSpec-7-0/HyperSpec/Body/f_eql.htm | 82 + .../HyperSpec-7-0/HyperSpec/Body/f_equal.htm | 103 + .../HyperSpec-7-0/HyperSpec/Body/f_equalp.htm | 111 + .../HyperSpec-7-0/HyperSpec/Body/f_error.htm | 105 + .../HyperSpec-7-0/HyperSpec/Body/f_eval.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_evenpc.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_everyc.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/f_exp_e.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/f_export.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_fbound.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/f_fdefin.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_file_a.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_file_e.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/f_file_l.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_file_p.htm | 98 + .../HyperSpec-7-0/HyperSpec/Body/f_file_s.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/f_file_w.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_fill.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_fill_p.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_find_.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/f_find_a.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_find_c.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_find_m.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_find_p.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_find_r.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_find_s.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/f_finish.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_firstc.htm | 126 + .../HyperSpec-7-0/HyperSpec/Body/f_float.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_floatp.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_floorc.htm | 118 + .../HyperSpec-7-0/HyperSpec/Body/f_fmakun.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_fn_kwd.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_fn_lam.htm | 101 + .../HyperSpec-7-0/HyperSpec/Body/f_fnp.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/f_format.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_funcal.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_gcd.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_gensym.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_gentem.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/f_get.htm | 96 + .../HyperSpec-7-0/HyperSpec/Body/f_get__1.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/f_get_in.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/f_get_ou.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_get_pr.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_get_se.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_get_un.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_getf.htm | 92 + .../HyperSpec-7-0/HyperSpec/Body/f_gethas.htm | 82 + .../HyperSpec-7-0/HyperSpec/Body/f_graphi.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_hash_1.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_hash_2.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_hash_3.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_hash_4.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/f_hash_5.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/f_hash_t.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_identi.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_import.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_in_stm.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_init_i.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_inspec.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/f_inte_1.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_intege.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_intera.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_intern.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_invali.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_invo_1.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_invo_2.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/f_invoke.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_isec_.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/f_kwdp.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_last.htm | 88 + .../HyperSpec-7-0/HyperSpec/Body/f_lcm.htm | 79 + .../HyperSpec-7-0/HyperSpec/Body/f_ld_log.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_ldb.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_ldb_te.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_ldiffc.htm | 117 + .../HyperSpec-7-0/HyperSpec/Body/f_length.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_lisp_i.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_list_.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_list_a.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_list_l.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/f_listen.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_listp.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_load.htm | 106 + .../HyperSpec-7-0/HyperSpec/Body/f_log.htm | 90 + .../HyperSpec-7-0/HyperSpec/Body/f_logand.htm | 140 + .../HyperSpec-7-0/HyperSpec/Body/f_logbtp.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_logcou.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/f_logi_1.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/f_logica.htm | 171 + .../HyperSpec-7-0/HyperSpec/Body/f_logtes.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_mach_i.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_mach_t.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_mach_v.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_macro_.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_makunb.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_map.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/f_map_in.htm | 79 + .../HyperSpec-7-0/HyperSpec/Body/f_mapc_.htm | 112 + .../HyperSpec-7-0/HyperSpec/Body/f_maphas.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_mask_f.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_max_m.htm | 89 + .../HyperSpec-7-0/HyperSpec/Body/f_mem_m.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/f_merge.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_merge_.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_meth_1.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_method.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_mexp_.htm | 124 + .../HyperSpec-7-0/HyperSpec/Body/f_minusp.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_mismat.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_ar.htm | 145 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_bro.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_cnd.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_con.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_dis.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_ech.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_has.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_i_1.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_ins.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_l_1.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_ld_.htm | 150 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_lis.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_pkg.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_pn.htm | 103 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_rnd.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_s_1.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_s_2.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_seq.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_stg.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_sym.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_syn.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_mk_two.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_mod_r.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_name_c.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_namest.htm | 115 + .../HyperSpec-7-0/HyperSpec/Body/f_nconc.htm | 89 + .../HyperSpec-7-0/HyperSpec/Body/f_next_m.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/f_no_app.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_no_nex.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_not.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_nth.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_nthcdr.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_null.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_numera.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_nump.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_open.htm | 135 + .../HyperSpec-7-0/HyperSpec/Body/f_open_s.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_opsetf.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/f_pairli.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/f_pars_1.htm | 95 + .../HyperSpec-7-0/HyperSpec/Body/f_parse_.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_peek_c.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_phase.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_pkg__1.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_pkg_er.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_pkg_na.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_pkg_ni.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_pkg_sh.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_pkg_us.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_pkgp.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_pl.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_pn.htm | 89 + .../HyperSpec-7-0/HyperSpec/Body/f_pn_hos.htm | 142 + .../HyperSpec-7-0/HyperSpec/Body/f_pn_mat.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/f_pnp.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_pos_p.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_ppr_di.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_ppr_fi.htm | 92 + .../HyperSpec-7-0/HyperSpec/Body/f_ppr_in.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_ppr_nl.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_ppr_ta.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_pr_not.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/f_pr_obj.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_probe_.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/f_procla.htm | 82 + .../HyperSpec-7-0/HyperSpec/Body/f_provid.htm | 89 + .../HyperSpec-7-0/HyperSpec/Body/f_random.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_rassoc.htm | 90 + .../HyperSpec-7-0/HyperSpec/Body/f_rati_1.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_ration.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_by.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_c_1.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_cha.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_del.htm | 88 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_fro.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_lin.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_rd.htm | 104 + .../HyperSpec-7-0/HyperSpec/Body/f_rd_seq.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_rdta_1.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_rdtabl.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_realp.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_realpa.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_reduce.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_reinit.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_remhas.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_rempro.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/f_replac.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/f_rest.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/f_revapp.htm | 100 + .../HyperSpec-7-0/HyperSpec/Body/f_revers.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_rm_dup.htm | 83 + .../HyperSpec-7-0/HyperSpec/Body/f_rm_met.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/f_rm_rm.htm | 137 + .../HyperSpec-7-0/HyperSpec/Body/f_rn_fil.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_rn_pkg.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_rnd_st.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_room.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/f_row_ma.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_rplaca.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/f_rst_na.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_sbs_s.htm | 123 + .../HyperSpec-7-0/HyperSpec/Body/f_search.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_set.htm | 94 + .../HyperSpec-7-0/HyperSpec/Body/f_set__1.htm | 88 + .../HyperSpec-7-0/HyperSpec/Body/f_set_di.htm | 91 + .../HyperSpec-7-0/HyperSpec/Body/f_set_ex.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/f_set_ma.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/f_set_pp.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_set_sy.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_shadow.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_shared.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_shdw_i.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_short_.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_signal.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/f_signum.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_sin_c.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_sinh_.htm | 91 + .../HyperSpec-7-0/HyperSpec/Body/f_sl.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_sleep.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_slt_bo.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_slt_ex.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/f_slt_ma.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_slt_mi.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_slt_un.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_slt_va.htm | 93 + .../HyperSpec-7-0/HyperSpec/Body/f_smp_bt.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_smp_cn.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_smp_st.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_smp_ve.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/f_sort_.htm | 107 + .../HyperSpec-7-0/HyperSpec/Body/f_specia.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_sqrt_.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/f_st.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_std_ch.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_stg_tr.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_stg_up.htm | 96 + .../HyperSpec-7-0/HyperSpec/Body/f_stgeq_.htm | 122 + .../HyperSpec-7-0/HyperSpec/Body/f_stgp.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_stm_el.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_stm_er.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_stm_ex.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_stmp.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_string.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_sublis.htm | 104 + .../HyperSpec-7-0/HyperSpec/Body/f_subseq.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/f_subset.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/f_substc.htm | 116 + .../HyperSpec-7-0/HyperSpec/Body/f_subtpp.htm | 133 + .../HyperSpec-7-0/HyperSpec/Body/f_svref.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/f_sw_tpc.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/f_sxhash.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_symb_1.htm | 98 + .../HyperSpec-7-0/HyperSpec/Body/f_symb_2.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/f_symb_3.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_symb_4.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_symb_5.htm | 90 + .../HyperSpec-7-0/HyperSpec/Body/f_symbol.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_syn_st.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/f_terpri.htm | 79 + .../HyperSpec-7-0/HyperSpec/Body/f_tn.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/f_tp_err.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/f_tp_of.htm | 98 + .../HyperSpec-7-0/HyperSpec/Body/f_tr_log.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_tr_pn.htm | 106 + .../HyperSpec-7-0/HyperSpec/Body/f_tree_e.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_two_wa.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_typep.htm | 100 + .../HyperSpec-7-0/HyperSpec/Body/f_unboun.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/f_unexpo.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_uninte.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_unionc.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/f_unrd_c.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/f_unuse_.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_upda_1.htm | 115 + .../HyperSpec-7-0/HyperSpec/Body/f_update.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_upgr_1.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_upgrad.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/f_upper_.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/f_use_pk.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/f_user_h.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/f_vals_l.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_values.htm | 79 + .../HyperSpec-7-0/HyperSpec/Body/f_vec_po.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_vec_ps.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_vecp.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_vector.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/f_warn.htm | 93 + .../HyperSpec-7-0/HyperSpec/Body/f_wild_p.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/f_wr_by.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/f_wr_cha.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/f_wr_pr.htm | 124 + .../HyperSpec-7-0/HyperSpec/Body/f_wr_seq.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/f_wr_stg.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/f_wr_to_.htm | 96 + .../HyperSpec-7-0/HyperSpec/Body/f_y_or_n.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/f_zerop.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/h_glossa.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/m_and.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/m_assert.htm | 99 + .../HyperSpec-7-0/HyperSpec/Body/m_call_m.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/m_case_.htm | 129 + .../HyperSpec-7-0/HyperSpec/Body/m_check_.htm | 121 + .../HyperSpec-7-0/HyperSpec/Body/m_cond.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/m_declai.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/m_defcla.htm | 116 + .../HyperSpec-7-0/HyperSpec/Body/m_defcon.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/m_defgen.htm | 101 + .../HyperSpec-7-0/HyperSpec/Body/m_defi_1.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/m_defi_2.htm | 80 + .../HyperSpec-7-0/HyperSpec/Body/m_defi_3.htm | 108 + .../HyperSpec-7-0/HyperSpec/Body/m_defi_4.htm | 262 + .../HyperSpec-7-0/HyperSpec/Body/m_defi_5.htm | 212 + .../HyperSpec-7-0/HyperSpec/Body/m_define.htm | 163 + .../HyperSpec-7-0/HyperSpec/Body/m_defmac.htm | 137 + .../HyperSpec-7-0/HyperSpec/Body/m_defmet.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/m_defpar.htm | 129 + .../HyperSpec-7-0/HyperSpec/Body/m_defpkg.htm | 130 + .../HyperSpec-7-0/HyperSpec/Body/m_defset.htm | 133 + .../HyperSpec-7-0/HyperSpec/Body/m_defstr.htm | 525 + .../HyperSpec-7-0/HyperSpec/Body/m_deftp.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/m_defun.htm | 100 + .../HyperSpec-7-0/HyperSpec/Body/m_destru.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/m_do_do.htm | 156 + .../HyperSpec-7-0/HyperSpec/Body/m_do_sym.htm | 95 + .../HyperSpec-7-0/HyperSpec/Body/m_dolist.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/m_dotime.htm | 102 + .../HyperSpec-7-0/HyperSpec/Body/m_format.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/m_hand_1.htm | 143 + .../HyperSpec-7-0/HyperSpec/Body/m_handle.htm | 88 + .../HyperSpec-7-0/HyperSpec/Body/m_ignore.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/m_in_pkg.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/m_incf_.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/m_lambda.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/m_loop.htm | 225 + .../HyperSpec-7-0/HyperSpec/Body/m_loop_f.htm | 93 + .../HyperSpec-7-0/HyperSpec/Body/m_mult_1.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/m_mult_2.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/m_multip.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/m_nth_va.htm | 71 + .../HyperSpec-7-0/HyperSpec/Body/m_or.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/m_pop.htm | 68 + .../HyperSpec-7-0/HyperSpec/Body/m_ppr_ex.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/m_ppr_lo.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/m_ppr_po.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/m_pr_unr.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/m_prog1c.htm | 91 + .../HyperSpec-7-0/HyperSpec/Body/m_prog_.htm | 128 + .../HyperSpec-7-0/HyperSpec/Body/m_psetq.htm | 93 + .../HyperSpec-7-0/HyperSpec/Body/m_pshnew.htm | 85 + .../HyperSpec-7-0/HyperSpec/Body/m_push.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/m_remf.htm | 63 + .../HyperSpec-7-0/HyperSpec/Body/m_return.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/m_rotate.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/m_rst_bi.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/m_rst_ca.htm | 203 + .../HyperSpec-7-0/HyperSpec/Body/m_setf_.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/m_shiftf.htm | 94 + .../HyperSpec-7-0/HyperSpec/Body/m_step.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/m_time.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/m_tpcase.htm | 136 + .../HyperSpec-7-0/HyperSpec/Body/m_tracec.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/m_w_acce.htm | 110 + .../HyperSpec-7-0/HyperSpec/Body/m_w_cnd_.htm | 60 + .../HyperSpec-7-0/HyperSpec/Body/m_w_comp.htm | 75 + .../HyperSpec-7-0/HyperSpec/Body/m_w_hash.htm | 95 + .../HyperSpec-7-0/HyperSpec/Body/m_w_in_f.htm | 74 + .../HyperSpec-7-0/HyperSpec/Body/m_w_op_1.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/m_w_open.htm | 98 + .../HyperSpec-7-0/HyperSpec/Body/m_w_out_.htm | 76 + .../HyperSpec-7-0/HyperSpec/Body/m_w_pkg_.htm | 124 + .../HyperSpec-7-0/HyperSpec/Body/m_w_slts.htm | 123 + .../HyperSpec-7-0/HyperSpec/Body/m_w_smp_.htm | 115 + .../HyperSpec-7-0/HyperSpec/Body/m_w_std_.htm | 86 + .../HyperSpec-7-0/HyperSpec/Body/m_when_.htm | 95 + .../HyperSpec-7-0/HyperSpec/Body/r_abort.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/r_contin.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/r_muffle.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/r_store_.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/r_use_va.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/s_block.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/s_catch.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/s_declar.htm | 88 + .../HyperSpec-7-0/HyperSpec/Body/s_eval_w.htm | 157 + .../HyperSpec-7-0/HyperSpec/Body/s_flet_.htm | 167 + .../HyperSpec-7-0/HyperSpec/Body/s_fn.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/s_go.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/s_if.htm | 73 + .../HyperSpec-7-0/HyperSpec/Body/s_lambda.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/s_ld_tim.htm | 99 + .../HyperSpec-7-0/HyperSpec/Body/s_let_l.htm | 115 + .../HyperSpec-7-0/HyperSpec/Body/s_locall.htm | 93 + .../HyperSpec-7-0/HyperSpec/Body/s_mult_1.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/s_multip.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/s_progn.htm | 64 + .../HyperSpec-7-0/HyperSpec/Body/s_progv.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/s_quote.htm | 72 + .../HyperSpec-7-0/HyperSpec/Body/s_ret_fr.htm | 106 + .../HyperSpec-7-0/HyperSpec/Body/s_setq.htm | 84 + .../HyperSpec-7-0/HyperSpec/Body/s_symbol.htm | 78 + .../HyperSpec-7-0/HyperSpec/Body/s_tagbod.htm | 96 + .../HyperSpec-7-0/HyperSpec/Body/s_the.htm | 83 + .../HyperSpec-7-0/HyperSpec/Body/s_throw.htm | 90 + .../HyperSpec-7-0/HyperSpec/Body/s_unwind.htm | 167 + .../HyperSpec-7-0/HyperSpec/Body/t_and.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/t_array.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/t_atom.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_ban.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/t_base_c.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/t_base_s.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/t_bignum.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_bit.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_broadc.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/t_bt_vec.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/t_built_.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_ch.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/t_class.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_cmpd_f.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/t_comple.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/t_concat.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/t_cons.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/t_echo_s.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/t_eql.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/t_extend.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/t_file_s.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/t_fixnum.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_float.htm | 55 + .../HyperSpec-7-0/HyperSpec/Body/t_fn.htm | 102 + .../HyperSpec-7-0/HyperSpec/Body/t_generi.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/t_hash_t.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/t_intege.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/t_kwd.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/t_list.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/t_logica.htm | 38 + .../HyperSpec-7-0/HyperSpec/Body/t_member.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/t_meth_1.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_method.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/t_mod.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/t_nil.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/t_not.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/t_null.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/t_number.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/t_or.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/t_pkg.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/t_pn.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_ratio.htm | 35 + .../HyperSpec-7-0/HyperSpec/Body/t_ration.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/t_rdtabl.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/t_real.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/t_rnd_st.htm | 36 + .../HyperSpec-7-0/HyperSpec/Body/t_rst.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_satisf.htm | 43 + .../HyperSpec-7-0/HyperSpec/Body/t_seq.htm | 34 + .../HyperSpec-7-0/HyperSpec/Body/t_sgn_by.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/t_short_.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/t_smp_ar.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/t_smp_ba.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/t_smp_bt.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/t_smp_st.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/t_smp_ve.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/t_std_ch.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/t_std_cl.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_std_ge.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_std_me.htm | 31 + .../HyperSpec-7-0/HyperSpec/Body/t_std_ob.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_stg_st.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/t_stream.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/t_string.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/t_stu_cl.htm | 33 + .../HyperSpec-7-0/HyperSpec/Body/t_stu_ob.htm | 37 + .../HyperSpec-7-0/HyperSpec/Body/t_symbol.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/t_syn_st.htm | 39 + .../lisp/HyperSpec-7-0/HyperSpec/Body/t_t.htm | 32 + .../HyperSpec-7-0/HyperSpec/Body/t_two_wa.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/t_unsgn_.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/t_values.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/t_vector.htm | 60 + .../lisp/HyperSpec-7-0/HyperSpec/Body/v__.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/v__stst_.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/v_ar_dim.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/v_ar_ran.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/v_ar_tot.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/v_b_1_b.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/v_break_.htm | 82 + .../HyperSpec-7-0/HyperSpec/Body/v_call_a.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/v_char_c.htm | 39 + .../HyperSpec-7-0/HyperSpec/Body/v_cmp_fi.htm | 51 + .../HyperSpec-7-0/HyperSpec/Body/v_cmp_pr.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/v_debug_.htm | 91 + .../HyperSpec-7-0/HyperSpec/Body/v_debugg.htm | 81 + .../HyperSpec-7-0/HyperSpec/Body/v_defaul.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/v_featur.htm | 67 + .../HyperSpec-7-0/HyperSpec/Body/v_gensym.htm | 47 + .../HyperSpec-7-0/HyperSpec/Body/v_intern.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/v_lamb_1.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/v_lambda.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/v_ld_pns.htm | 50 + .../HyperSpec-7-0/HyperSpec/Body/v_ld_prs.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/v_mexp_h.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/v_module.htm | 49 + .../HyperSpec-7-0/HyperSpec/Body/v_most_1.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/v_most_p.htm | 40 + .../HyperSpec-7-0/HyperSpec/Body/v_multip.htm | 41 + .../HyperSpec-7-0/HyperSpec/Body/v_nil.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/v_pi.htm | 54 + .../HyperSpec-7-0/HyperSpec/Body/v_pkg.htm | 66 + .../HyperSpec-7-0/HyperSpec/Body/v_pl_plp.htm | 59 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_ar.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_bas.htm | 77 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_cas.htm | 69 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_cir.htm | 62 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_esc.htm | 58 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_gen.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_lev.htm | 96 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_lin.htm | 53 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_mis.htm | 44 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_ppr.htm | 45 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_pre.htm | 82 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_rda.htm | 97 + .../HyperSpec-7-0/HyperSpec/Body/v_pr_rig.htm | 46 + .../HyperSpec-7-0/HyperSpec/Body/v_rd_bas.htm | 61 + .../HyperSpec-7-0/HyperSpec/Body/v_rd_def.htm | 56 + .../HyperSpec-7-0/HyperSpec/Body/v_rd_eva.htm | 48 + .../HyperSpec-7-0/HyperSpec/Body/v_rd_sup.htm | 70 + .../HyperSpec-7-0/HyperSpec/Body/v_rdtabl.htm | 57 + .../HyperSpec-7-0/HyperSpec/Body/v_rnd_st.htm | 65 + .../HyperSpec-7-0/HyperSpec/Body/v_short_.htm | 42 + .../HyperSpec-7-0/HyperSpec/Body/v_sl_sls.htm | 53 + .../lisp/HyperSpec-7-0/HyperSpec/Body/v_t.htm | 52 + .../HyperSpec-7-0/HyperSpec/Body/v_termin.htm | 57 + .../HyperSpec-7-0/HyperSpec/Data/Map_IssW.txt | 652 + .../HyperSpec-7-0/HyperSpec/Data/Map_IssX.txt | 730 + .../HyperSpec-7-0/HyperSpec/Data/Map_Sym.txt | 1956 ++ .../HyperSpec/Data/clhs.css | 0 .../lisp/HyperSpec-7-0/HyperSpec/Data/md5.txt | 2343 +++ .../HyperSpec/Front/Contents.htm | 67 + .../HyperSpec/Front/Help.htm | 98 +- .../HyperSpec/Front/Hilights.htm | 124 + .../HyperSpec-7-0/HyperSpec/Front/NoNext.htm | 32 + .../HyperSpec-7-0/HyperSpec/Front/NoPrev.htm | 31 + .../HyperSpec-7-0/HyperSpec/Front/NoUp.htm | 32 + .../HyperSpec/Front/StartPts.htm | 37 + .../HyperSpec/Front/X3J13Iss.htm | 47 + .../HyperSpec/Front/X_AllSym.htm | 1008 + .../HyperSpec/Front/X_Alph_9.htm | 99 + .../HyperSpec/Front/X_Alph_A.htm | 74 + .../HyperSpec/Front/X_Alph_B.htm | 75 + .../HyperSpec/Front/X_Alph_C.htm | 141 + .../HyperSpec/Front/X_Alph_D.htm | 85 + .../HyperSpec/Front/X_Alph_E.htm | 56 + .../HyperSpec/Front/X_Alph_F.htm | 83 + .../HyperSpec/Front/X_Alph_G.htm | 47 + .../HyperSpec/Front/X_Alph_H.htm | 39 + .../HyperSpec/Front/X_Alph_I.htm | 55 + .../HyperSpec/Front/X_Alph_K.htm | 31 + .../HyperSpec/Front/X_Alph_L.htm | 93 + .../HyperSpec/Front/X_Alph_M.htm | 101 + .../HyperSpec/Front/X_Alph_N.htm | 65 + .../HyperSpec/Front/X_Alph_O.htm | 36 + .../HyperSpec/Front/X_Alph_P.htm | 93 + .../HyperSpec/Front/X_Alph_Q.htm | 30 + .../HyperSpec/Front/X_Alph_R.htm | 85 + .../HyperSpec/Front/X_Alph_S.htm | 159 + .../HyperSpec/Front/X_Alph_T.htm | 56 + .../HyperSpec/Front/X_Alph_U.htm | 50 + .../HyperSpec/Front/X_Alph_V.htm | 37 + .../HyperSpec/Front/X_Alph_W.htm | 52 + .../HyperSpec/Front/X_Alph_Y.htm | 31 + .../HyperSpec/Front/X_Alph_Z.htm | 30 + .../HyperSpec/Front/X_Mast_9.htm | 1274 ++ .../HyperSpec/Front/X_Mast_A.htm | 355 + .../HyperSpec/Front/X_Mast_B.htm | 236 + .../HyperSpec/Front/X_Mast_C.htm | 551 + .../HyperSpec/Front/X_Mast_D.htm | 330 + .../HyperSpec/Front/X_Mast_E.htm | 292 + .../HyperSpec/Front/X_Mast_F.htm | 285 + .../HyperSpec/Front/X_Mast_G.htm | 114 + .../HyperSpec/Front/X_Mast_H.htm | 74 + .../HyperSpec/Front/X_Mast_I.htm | 298 + .../HyperSpec/Front/X_Mast_J.htm | 34 + .../HyperSpec/Front/X_Mast_K.htm | 88 + .../HyperSpec/Front/X_Mast_L.htm | 298 + .../HyperSpec/Front/X_Mast_M.htm | 292 + .../HyperSpec/Front/X_Mast_N.htm | 214 + .../HyperSpec/Front/X_Mast_O.htm | 131 + .../HyperSpec/Front/X_Mast_P.htm | 354 + .../HyperSpec/Front/X_Mast_Q.htm | 57 + .../HyperSpec/Front/X_Mast_R.htm | 324 + .../HyperSpec/Front/X_Mast_S.htm | 662 + .../HyperSpec/Front/X_Mast_T.htm | 303 + .../HyperSpec/Front/X_Mast_U.htm | 171 + .../HyperSpec/Front/X_Mast_V.htm | 97 + .../HyperSpec/Front/X_Mast_W.htm | 145 + .../HyperSpec/Front/X_Mast_X.htm | 37 + .../HyperSpec/Front/X_Mast_Y.htm | 37 + .../HyperSpec/Front/X_Mast_Z.htm | 33 + .../HyperSpec/Front/X_Master.htm | 29 + .../HyperSpec/Front/X_Perm_9.htm | 148 + .../HyperSpec/Front/X_Perm_A.htm | 100 + .../HyperSpec/Front/X_Perm_B.htm | 97 + .../HyperSpec/Front/X_Perm_C.htm | 208 + .../HyperSpec/Front/X_Perm_D.htm | 126 + .../HyperSpec/Front/X_Perm_E.htm | 117 + .../HyperSpec/Front/X_Perm_F.htm | 162 + .../HyperSpec/Front/X_Perm_G.htm | 56 + .../HyperSpec/Front/X_Perm_H.htm | 48 + .../HyperSpec/Front/X_Perm_I.htm | 120 + .../HyperSpec/Front/X_Perm_K.htm | 36 + .../HyperSpec/Front/X_Perm_L.htm | 143 + .../HyperSpec/Front/X_Perm_M.htm | 136 + .../HyperSpec/Front/X_Perm_N.htm | 137 + .../HyperSpec/Front/X_Perm_O.htm | 76 + .../HyperSpec/Front/X_Perm_P.htm | 219 + .../HyperSpec/Front/X_Perm_Q.htm | 33 + .../HyperSpec/Front/X_Perm_R.htm | 116 + .../HyperSpec/Front/X_Perm_S.htm | 266 + .../HyperSpec/Front/X_Perm_T.htm | 106 + .../HyperSpec/Front/X_Perm_U.htm | 64 + .../HyperSpec/Front/X_Perm_V.htm | 63 + .../HyperSpec/Front/X_Perm_W.htm | 65 + .../HyperSpec/Front/X_Perm_X.htm | 32 + .../HyperSpec/Front/X_Perm_Y.htm | 32 + .../HyperSpec/Front/X_Perm_Z.htm | 32 + .../HyperSpec/Front/X_Symbol.htm | 14 +- .../HyperSpec-7-0/HyperSpec/Front/index.htm | 58 + .../HyperSpec/Front/index_tx.htm | 46 + .../HyperSpec/Graphics/CLHS_Lg.gif | Bin .../HyperSpec/Graphics/CLHS_Sm.gif | Bin .../HyperSpec/Graphics/Contents.gif | Bin .../HyperSpec/Graphics/Glossary.gif | Bin .../HyperSpec/Graphics/Help.gif | Bin .../HyperSpec/Graphics/Hilights.gif | Bin .../HyperSpec/Graphics/Index.gif | Bin .../HyperSpec/Graphics/Issues.gif | Bin .../HyperSpec/Graphics/LWLarge.gif | Bin .../HyperSpec/Graphics/LWSmall.gif | Bin .../HyperSpec/Graphics/Next.gif | Bin .../HyperSpec/Graphics/NoNext.gif | Bin .../HyperSpec/Graphics/NoPrev.gif | Bin .../HyperSpec/Graphics/NoUp.gif | Bin .../HyperSpec/Graphics/Prev.gif | Bin .../HyperSpec/Graphics/Quadrant.gif | Bin 0 -> 1701 bytes .../HyperSpec/Graphics/StartPts.gif | Bin .../HyperSpec/Graphics/Symbols.gif | Bin .../HyperSpec/Graphics/Up.gif | Bin .../HyperSpec-7-0/HyperSpec/Issues/IC_ARR.htm | 45 + .../HyperSpec-7-0/HyperSpec/Issues/IC_CHA.htm | 77 + .../HyperSpec-7-0/HyperSpec/Issues/IC_CLO.htm | 79 + .../HyperSpec-7-0/HyperSpec/Issues/IC_COL.htm | 65 + .../HyperSpec-7-0/HyperSpec/Issues/IC_COM.htm | 227 + .../HyperSpec-7-0/HyperSpec/Issues/IC_CON.htm | 59 + .../HyperSpec-7-0/HyperSpec/Issues/IC_ENV.htm | 55 + .../HyperSpec-7-0/HyperSpec/Issues/IC_FIL.htm | 65 + .../HyperSpec-7-0/HyperSpec/Issues/IC_FUN.htm | 47 + .../HyperSpec-7-0/HyperSpec/Issues/IC_IO.htm | 111 + .../HyperSpec-7-0/HyperSpec/Issues/IC_ITE.htm | 47 + .../HyperSpec-7-0/HyperSpec/Issues/IC_MIS.htm | 69 + .../HyperSpec-7-0/HyperSpec/Issues/IC_NUM.htm | 49 + .../HyperSpec-7-0/HyperSpec/Issues/IC_STR.htm | 57 + .../HyperSpec-7-0/HyperSpec/Issues/IC_SYM.htm | 65 + .../HyperSpec-7-0/HyperSpec/Issues/IC_SYN.htm | 81 + .../HyperSpec-7-0/HyperSpec/Issues/IC_TAB.htm | 39 + .../HyperSpec-7-0/HyperSpec/Issues/IC_TYP.htm | 43 + .../HyperSpec/Issues/I_Alpha.htm | 758 + .../HyperSpec/Issues/I_Categ.htm | 64 + .../HyperSpec-7-0/HyperSpec/Issues/iss001.htm | 36 + .../HyperSpec/Issues/iss001_w.htm | 133 + .../HyperSpec-7-0/HyperSpec/Issues/iss002.htm | 37 + .../HyperSpec/Issues/iss002_w.htm | 59 + .../HyperSpec-7-0/HyperSpec/Issues/iss003.htm | 36 + .../HyperSpec/Issues/iss003_w.htm | 128 + .../HyperSpec-7-0/HyperSpec/Issues/iss004.htm | 36 + .../HyperSpec/Issues/iss004_w.htm | 127 + .../HyperSpec-7-0/HyperSpec/Issues/iss005.htm | 38 + .../HyperSpec/Issues/iss005_w.htm | 270 + .../HyperSpec-7-0/HyperSpec/Issues/iss006.htm | 36 + .../HyperSpec/Issues/iss006_w.htm | 112 + .../HyperSpec-7-0/HyperSpec/Issues/iss007.htm | 36 + .../HyperSpec/Issues/iss007_w.htm | 166 + .../HyperSpec-7-0/HyperSpec/Issues/iss008.htm | 36 + .../HyperSpec/Issues/iss008_w.htm | 175 + .../HyperSpec-7-0/HyperSpec/Issues/iss009.htm | 37 + .../HyperSpec/Issues/iss009_w.htm | 131 + .../HyperSpec-7-0/HyperSpec/Issues/iss010.htm | 39 + .../HyperSpec/Issues/iss010_w.htm | 93 + .../HyperSpec-7-0/HyperSpec/Issues/iss011.htm | 42 + .../HyperSpec/Issues/iss011_w.htm | 112 + .../HyperSpec-7-0/HyperSpec/Issues/iss012.htm | 36 + .../HyperSpec/Issues/iss012_w.htm | 355 + .../HyperSpec-7-0/HyperSpec/Issues/iss013.htm | 50 + .../HyperSpec/Issues/iss013_w.htm | 105 + .../HyperSpec-7-0/HyperSpec/Issues/iss014.htm | 53 + .../HyperSpec/Issues/iss014_w.htm | 135 + .../HyperSpec-7-0/HyperSpec/Issues/iss015.htm | 47 + .../HyperSpec/Issues/iss015_w.htm | 480 + .../HyperSpec-7-0/HyperSpec/Issues/iss016.htm | 36 + .../HyperSpec/Issues/iss016_w.htm | 99 + .../HyperSpec-7-0/HyperSpec/Issues/iss017.htm | 37 + .../HyperSpec/Issues/iss017_m.htm | 32 + .../HyperSpec/Issues/iss017_w.htm | 104 + .../HyperSpec-7-0/HyperSpec/Issues/iss018.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss019.htm | 36 + .../HyperSpec/Issues/iss019_w.htm | 167 + .../HyperSpec-7-0/HyperSpec/Issues/iss020.htm | 38 + .../HyperSpec/Issues/iss020_w.htm | 92 + .../HyperSpec-7-0/HyperSpec/Issues/iss021.htm | 36 + .../HyperSpec/Issues/iss021_w.htm | 177 + .../HyperSpec-7-0/HyperSpec/Issues/iss022.htm | 36 + .../HyperSpec/Issues/iss022_w.htm | 93 + .../HyperSpec-7-0/HyperSpec/Issues/iss023.htm | 37 + .../HyperSpec/Issues/iss023_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss024.htm | 36 + .../HyperSpec/Issues/iss024_w.htm | 223 + .../HyperSpec-7-0/HyperSpec/Issues/iss025.htm | 37 + .../HyperSpec/Issues/iss025_w.htm | 98 + .../HyperSpec-7-0/HyperSpec/Issues/iss026.htm | 36 + .../HyperSpec/Issues/iss026_m.htm | 32 + .../HyperSpec/Issues/iss026_w.htm | 389 + .../HyperSpec-7-0/HyperSpec/Issues/iss027.htm | 57 + .../HyperSpec-7-0/HyperSpec/Issues/iss028.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss029.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss030.htm | 38 + .../HyperSpec-7-0/HyperSpec/Issues/iss031.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss032.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss033.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss034.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss035.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss036.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss037.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss038.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss039.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss040.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss041.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss042.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss043.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss044.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss045.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss046.htm | 45 + .../HyperSpec/Issues/iss046_w.htm | 205 + .../HyperSpec-7-0/HyperSpec/Issues/iss047.htm | 37 + .../HyperSpec/Issues/iss047_w.htm | 102 + .../HyperSpec-7-0/HyperSpec/Issues/iss048.htm | 36 + .../HyperSpec/Issues/iss048_w.htm | 157 + .../HyperSpec-7-0/HyperSpec/Issues/iss049.htm | 38 + .../HyperSpec/Issues/iss049_w.htm | 261 + .../HyperSpec-7-0/HyperSpec/Issues/iss050.htm | 36 + .../HyperSpec/Issues/iss050_w.htm | 81 + .../HyperSpec-7-0/HyperSpec/Issues/iss051.htm | 36 + .../HyperSpec/Issues/iss051_w.htm | 195 + .../HyperSpec-7-0/HyperSpec/Issues/iss052.htm | 37 + .../HyperSpec/Issues/iss052_w.htm | 165 + .../HyperSpec-7-0/HyperSpec/Issues/iss053.htm | 46 + .../HyperSpec/Issues/iss053_w.htm | 166 + .../HyperSpec-7-0/HyperSpec/Issues/iss054.htm | 36 + .../HyperSpec/Issues/iss054_w.htm | 90 + .../HyperSpec-7-0/HyperSpec/Issues/iss055.htm | 36 + .../HyperSpec/Issues/iss055_w.htm | 94 + .../HyperSpec-7-0/HyperSpec/Issues/iss056.htm | 36 + .../HyperSpec/Issues/iss056_w.htm | 153 + .../HyperSpec-7-0/HyperSpec/Issues/iss057.htm | 38 + .../HyperSpec/Issues/iss057_w.htm | 95 + .../HyperSpec-7-0/HyperSpec/Issues/iss058.htm | 36 + .../HyperSpec/Issues/iss058_w.htm | 89 + .../HyperSpec-7-0/HyperSpec/Issues/iss059.htm | 51 + .../HyperSpec/Issues/iss059_w.htm | 252 + .../HyperSpec-7-0/HyperSpec/Issues/iss060.htm | 38 + .../HyperSpec/Issues/iss060_w.htm | 122 + .../HyperSpec-7-0/HyperSpec/Issues/iss061.htm | 36 + .../HyperSpec/Issues/iss061_w.htm | 84 + .../HyperSpec-7-0/HyperSpec/Issues/iss062.htm | 36 + .../HyperSpec/Issues/iss062_w.htm | 94 + .../HyperSpec-7-0/HyperSpec/Issues/iss063.htm | 37 + .../HyperSpec/Issues/iss063_w.htm | 278 + .../HyperSpec-7-0/HyperSpec/Issues/iss064.htm | 39 + .../HyperSpec/Issues/iss064_w.htm | 255 + .../HyperSpec-7-0/HyperSpec/Issues/iss065.htm | 40 + .../HyperSpec/Issues/iss065_w.htm | 229 + .../HyperSpec-7-0/HyperSpec/Issues/iss066.htm | 37 + .../HyperSpec/Issues/iss066_w.htm | 396 + .../HyperSpec-7-0/HyperSpec/Issues/iss067.htm | 38 + .../HyperSpec/Issues/iss067_w.htm | 136 + .../HyperSpec-7-0/HyperSpec/Issues/iss068.htm | 38 + .../HyperSpec/Issues/iss068_w.htm | 98 + .../HyperSpec-7-0/HyperSpec/Issues/iss069.htm | 36 + .../HyperSpec/Issues/iss069_w.htm | 119 + .../HyperSpec-7-0/HyperSpec/Issues/iss070.htm | 37 + .../HyperSpec/Issues/iss070_w.htm | 194 + .../HyperSpec-7-0/HyperSpec/Issues/iss071.htm | 39 + .../HyperSpec/Issues/iss071_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss072.htm | 36 + .../HyperSpec/Issues/iss072_w.htm | 98 + .../HyperSpec-7-0/HyperSpec/Issues/iss073.htm | 40 + .../HyperSpec/Issues/iss073_w.htm | 178 + .../HyperSpec-7-0/HyperSpec/Issues/iss074.htm | 36 + .../HyperSpec/Issues/iss074_w.htm | 71 + .../HyperSpec-7-0/HyperSpec/Issues/iss075.htm | 36 + .../HyperSpec/Issues/iss075_m.htm | 32 + .../HyperSpec/Issues/iss075_w.htm | 253 + .../HyperSpec-7-0/HyperSpec/Issues/iss076.htm | 47 + .../HyperSpec-7-0/HyperSpec/Issues/iss077.htm | 37 + .../HyperSpec/Issues/iss077_w.htm | 153 + .../HyperSpec-7-0/HyperSpec/Issues/iss078.htm | 36 + .../HyperSpec/Issues/iss078_w.htm | 136 + .../HyperSpec-7-0/HyperSpec/Issues/iss079.htm | 36 + .../HyperSpec/Issues/iss079_w.htm | 220 + .../HyperSpec-7-0/HyperSpec/Issues/iss080.htm | 36 + .../HyperSpec/Issues/iss080_w.htm | 148 + .../HyperSpec-7-0/HyperSpec/Issues/iss081.htm | 36 + .../HyperSpec/Issues/iss081_w.htm | 373 + .../HyperSpec-7-0/HyperSpec/Issues/iss082.htm | 36 + .../HyperSpec/Issues/iss082_w.htm | 142 + .../HyperSpec-7-0/HyperSpec/Issues/iss083.htm | 52 + .../HyperSpec/Issues/iss083_w.htm | 100 + .../HyperSpec-7-0/HyperSpec/Issues/iss084.htm | 36 + .../HyperSpec/Issues/iss084_w.htm | 461 + .../HyperSpec-7-0/HyperSpec/Issues/iss085.htm | 36 + .../HyperSpec/Issues/iss085_w.htm | 136 + .../HyperSpec-7-0/HyperSpec/Issues/iss086.htm | 36 + .../HyperSpec/Issues/iss086_w.htm | 142 + .../HyperSpec-7-0/HyperSpec/Issues/iss087.htm | 36 + .../HyperSpec/Issues/iss087_w.htm | 80 + .../HyperSpec-7-0/HyperSpec/Issues/iss088.htm | 36 + .../HyperSpec/Issues/iss088_w.htm | 91 + .../HyperSpec-7-0/HyperSpec/Issues/iss089.htm | 42 + .../HyperSpec/Issues/iss089_w.htm | 296 + .../HyperSpec-7-0/HyperSpec/Issues/iss090.htm | 38 + .../HyperSpec/Issues/iss090_w.htm | 102 + .../HyperSpec-7-0/HyperSpec/Issues/iss091.htm | 36 + .../HyperSpec/Issues/iss091_w.htm | 110 + .../HyperSpec-7-0/HyperSpec/Issues/iss092.htm | 37 + .../HyperSpec/Issues/iss092_w.htm | 384 + .../HyperSpec-7-0/HyperSpec/Issues/iss093.htm | 36 + .../HyperSpec/Issues/iss093_w.htm | 149 + .../HyperSpec-7-0/HyperSpec/Issues/iss094.htm | 39 + .../HyperSpec/Issues/iss094_w.htm | 143 + .../HyperSpec-7-0/HyperSpec/Issues/iss095.htm | 37 + .../HyperSpec/Issues/iss095_w.htm | 242 + .../HyperSpec-7-0/HyperSpec/Issues/iss096.htm | 36 + .../HyperSpec/Issues/iss096_w.htm | 414 + .../HyperSpec-7-0/HyperSpec/Issues/iss097.htm | 68 + .../HyperSpec/Issues/iss097_w.htm | 35 + .../HyperSpec-7-0/HyperSpec/Issues/iss098.htm | 36 + .../HyperSpec/Issues/iss098_w.htm | 116 + .../HyperSpec-7-0/HyperSpec/Issues/iss099.htm | 36 + .../HyperSpec/Issues/iss099_w.htm | 119 + .../HyperSpec-7-0/HyperSpec/Issues/iss100.htm | 36 + .../HyperSpec/Issues/iss100_w.htm | 93 + .../HyperSpec-7-0/HyperSpec/Issues/iss101.htm | 45 + .../HyperSpec/Issues/iss101_w.htm | 350 + .../HyperSpec-7-0/HyperSpec/Issues/iss102.htm | 36 + .../HyperSpec/Issues/iss102_w.htm | 144 + .../HyperSpec-7-0/HyperSpec/Issues/iss103.htm | 36 + .../HyperSpec/Issues/iss103_w.htm | 100 + .../HyperSpec-7-0/HyperSpec/Issues/iss104.htm | 43 + .../HyperSpec/Issues/iss104_w.htm | 172 + .../HyperSpec-7-0/HyperSpec/Issues/iss105.htm | 40 + .../HyperSpec/Issues/iss105_w.htm | 123 + .../HyperSpec-7-0/HyperSpec/Issues/iss106.htm | 38 + .../HyperSpec/Issues/iss106_w.htm | 188 + .../HyperSpec-7-0/HyperSpec/Issues/iss107.htm | 36 + .../HyperSpec/Issues/iss107_w.htm | 176 + .../HyperSpec-7-0/HyperSpec/Issues/iss108.htm | 36 + .../HyperSpec/Issues/iss108_w.htm | 308 + .../HyperSpec-7-0/HyperSpec/Issues/iss109.htm | 36 + .../HyperSpec/Issues/iss109_w.htm | 138 + .../HyperSpec-7-0/HyperSpec/Issues/iss110.htm | 36 + .../HyperSpec/Issues/iss110_w.htm | 119 + .../HyperSpec-7-0/HyperSpec/Issues/iss111.htm | 36 + .../HyperSpec/Issues/iss111_w.htm | 253 + .../HyperSpec-7-0/HyperSpec/Issues/iss112.htm | 36 + .../HyperSpec/Issues/iss112_w.htm | 115 + .../HyperSpec-7-0/HyperSpec/Issues/iss113.htm | 38 + .../HyperSpec/Issues/iss113_w.htm | 183 + .../HyperSpec-7-0/HyperSpec/Issues/iss114.htm | 36 + .../HyperSpec/Issues/iss114_w.htm | 157 + .../HyperSpec-7-0/HyperSpec/Issues/iss115.htm | 36 + .../HyperSpec/Issues/iss115_w.htm | 104 + .../HyperSpec-7-0/HyperSpec/Issues/iss116.htm | 42 + .../HyperSpec/Issues/iss116_w.htm | 164 + .../HyperSpec-7-0/HyperSpec/Issues/iss117.htm | 36 + .../HyperSpec/Issues/iss117_w.htm | 106 + .../HyperSpec-7-0/HyperSpec/Issues/iss118.htm | 36 + .../HyperSpec/Issues/iss118_w.htm | 159 + .../HyperSpec-7-0/HyperSpec/Issues/iss119.htm | 36 + .../HyperSpec/Issues/iss119_w.htm | 126 + .../HyperSpec-7-0/HyperSpec/Issues/iss120.htm | 36 + .../HyperSpec/Issues/iss120_w.htm | 87 + .../HyperSpec-7-0/HyperSpec/Issues/iss121.htm | 37 + .../HyperSpec/Issues/iss121_w.htm | 110 + .../HyperSpec-7-0/HyperSpec/Issues/iss122.htm | 37 + .../HyperSpec/Issues/iss122_w.htm | 130 + .../HyperSpec-7-0/HyperSpec/Issues/iss123.htm | 37 + .../HyperSpec/Issues/iss123_w.htm | 93 + .../HyperSpec-7-0/HyperSpec/Issues/iss124.htm | 36 + .../HyperSpec/Issues/iss124_w.htm | 99 + .../HyperSpec-7-0/HyperSpec/Issues/iss125.htm | 36 + .../HyperSpec/Issues/iss125_w.htm | 96 + .../HyperSpec-7-0/HyperSpec/Issues/iss126.htm | 36 + .../HyperSpec/Issues/iss126_w.htm | 142 + .../HyperSpec-7-0/HyperSpec/Issues/iss127.htm | 36 + .../HyperSpec/Issues/iss127_w.htm | 205 + .../HyperSpec-7-0/HyperSpec/Issues/iss128.htm | 37 + .../HyperSpec/Issues/iss128_w.htm | 176 + .../HyperSpec-7-0/HyperSpec/Issues/iss129.htm | 36 + .../HyperSpec/Issues/iss129_w.htm | 150 + .../HyperSpec-7-0/HyperSpec/Issues/iss130.htm | 36 + .../HyperSpec/Issues/iss130_w.htm | 207 + .../HyperSpec-7-0/HyperSpec/Issues/iss131.htm | 36 + .../HyperSpec/Issues/iss131_w.htm | 104 + .../HyperSpec-7-0/HyperSpec/Issues/iss132.htm | 36 + .../HyperSpec/Issues/iss132_w.htm | 139 + .../HyperSpec-7-0/HyperSpec/Issues/iss133.htm | 36 + .../HyperSpec/Issues/iss133_w.htm | 99 + .../HyperSpec-7-0/HyperSpec/Issues/iss134.htm | 36 + .../HyperSpec/Issues/iss134_w.htm | 115 + .../HyperSpec-7-0/HyperSpec/Issues/iss135.htm | 46 + .../HyperSpec/Issues/iss135_w.htm | 217 + .../HyperSpec-7-0/HyperSpec/Issues/iss136.htm | 37 + .../HyperSpec/Issues/iss136_w.htm | 164 + .../HyperSpec-7-0/HyperSpec/Issues/iss137.htm | 37 + .../HyperSpec/Issues/iss137_w.htm | 650 + .../HyperSpec-7-0/HyperSpec/Issues/iss138.htm | 55 + .../HyperSpec/Issues/iss138_w.htm | 286 + .../HyperSpec-7-0/HyperSpec/Issues/iss139.htm | 36 + .../HyperSpec/Issues/iss139_w.htm | 153 + .../HyperSpec-7-0/HyperSpec/Issues/iss140.htm | 36 + .../HyperSpec/Issues/iss140_w.htm | 108 + .../HyperSpec-7-0/HyperSpec/Issues/iss141.htm | 36 + .../HyperSpec/Issues/iss141_w.htm | 148 + .../HyperSpec-7-0/HyperSpec/Issues/iss142.htm | 38 + .../HyperSpec/Issues/iss142_w.htm | 308 + .../HyperSpec-7-0/HyperSpec/Issues/iss143.htm | 37 + .../HyperSpec/Issues/iss143_w.htm | 198 + .../HyperSpec-7-0/HyperSpec/Issues/iss144.htm | 36 + .../HyperSpec/Issues/iss144_w.htm | 92 + .../HyperSpec-7-0/HyperSpec/Issues/iss145.htm | 36 + .../HyperSpec/Issues/iss145_w.htm | 126 + .../HyperSpec-7-0/HyperSpec/Issues/iss146.htm | 36 + .../HyperSpec/Issues/iss146_w.htm | 166 + .../HyperSpec-7-0/HyperSpec/Issues/iss147.htm | 37 + .../HyperSpec/Issues/iss147_w.htm | 522 + .../HyperSpec-7-0/HyperSpec/Issues/iss148.htm | 37 + .../HyperSpec/Issues/iss148_w.htm | 121 + .../HyperSpec-7-0/HyperSpec/Issues/iss149.htm | 36 + .../HyperSpec/Issues/iss149_m.htm | 32 + .../HyperSpec/Issues/iss149_w.htm | 178 + .../HyperSpec-7-0/HyperSpec/Issues/iss150.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss151.htm | 36 + .../HyperSpec/Issues/iss151_w.htm | 138 + .../HyperSpec-7-0/HyperSpec/Issues/iss152.htm | 40 + .../HyperSpec/Issues/iss152_w.htm | 391 + .../HyperSpec-7-0/HyperSpec/Issues/iss153.htm | 36 + .../HyperSpec/Issues/iss153_w.htm | 118 + .../HyperSpec-7-0/HyperSpec/Issues/iss154.htm | 36 + .../HyperSpec/Issues/iss154_w.htm | 144 + .../HyperSpec-7-0/HyperSpec/Issues/iss155.htm | 37 + .../HyperSpec/Issues/iss155_w.htm | 201 + .../HyperSpec-7-0/HyperSpec/Issues/iss156.htm | 36 + .../HyperSpec/Issues/iss156_w.htm | 128 + .../HyperSpec-7-0/HyperSpec/Issues/iss157.htm | 63 + .../HyperSpec/Issues/iss157_w.htm | 220 + .../HyperSpec-7-0/HyperSpec/Issues/iss158.htm | 40 + .../HyperSpec/Issues/iss158_w.htm | 158 + .../HyperSpec-7-0/HyperSpec/Issues/iss159.htm | 36 + .../HyperSpec/Issues/iss159_m.htm | 32 + .../HyperSpec/Issues/iss159_w.htm | 129 + .../HyperSpec-7-0/HyperSpec/Issues/iss160.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss161.htm | 40 + .../HyperSpec/Issues/iss161_w.htm | 135 + .../HyperSpec-7-0/HyperSpec/Issues/iss162.htm | 36 + .../HyperSpec/Issues/iss162_w.htm | 150 + .../HyperSpec-7-0/HyperSpec/Issues/iss163.htm | 38 + .../HyperSpec/Issues/iss163_w.htm | 167 + .../HyperSpec-7-0/HyperSpec/Issues/iss164.htm | 36 + .../HyperSpec/Issues/iss164_w.htm | 84 + .../HyperSpec-7-0/HyperSpec/Issues/iss165.htm | 36 + .../HyperSpec/Issues/iss165_w.htm | 141 + .../HyperSpec-7-0/HyperSpec/Issues/iss166.htm | 37 + .../HyperSpec/Issues/iss166_w.htm | 113 + .../HyperSpec-7-0/HyperSpec/Issues/iss167.htm | 36 + .../HyperSpec/Issues/iss167_w.htm | 128 + .../HyperSpec-7-0/HyperSpec/Issues/iss168.htm | 36 + .../HyperSpec/Issues/iss168_w.htm | 130 + .../HyperSpec-7-0/HyperSpec/Issues/iss169.htm | 49 + .../HyperSpec/Issues/iss169_w.htm | 220 + .../HyperSpec-7-0/HyperSpec/Issues/iss170.htm | 56 + .../HyperSpec/Issues/iss170_w.htm | 177 + .../HyperSpec-7-0/HyperSpec/Issues/iss171.htm | 36 + .../HyperSpec/Issues/iss171_w.htm | 124 + .../HyperSpec-7-0/HyperSpec/Issues/iss172.htm | 37 + .../HyperSpec/Issues/iss172_w.htm | 129 + .../HyperSpec-7-0/HyperSpec/Issues/iss173.htm | 36 + .../HyperSpec/Issues/iss173_w.htm | 162 + .../HyperSpec-7-0/HyperSpec/Issues/iss174.htm | 53 + .../HyperSpec/Issues/iss174_w.htm | 559 + .../HyperSpec-7-0/HyperSpec/Issues/iss175.htm | 36 + .../HyperSpec/Issues/iss175_m.htm | 32 + .../HyperSpec/Issues/iss175_w.htm | 302 + .../HyperSpec-7-0/HyperSpec/Issues/iss176.htm | 36 + .../HyperSpec/Issues/iss176_w.htm | 192 + .../HyperSpec-7-0/HyperSpec/Issues/iss177.htm | 36 + .../HyperSpec/Issues/iss177_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss178.htm | 36 + .../HyperSpec/Issues/iss178_w.htm | 148 + .../HyperSpec-7-0/HyperSpec/Issues/iss179.htm | 49 + .../HyperSpec-7-0/HyperSpec/Issues/iss180.htm | 44 + .../HyperSpec/Issues/iss180_w.htm | 245 + .../HyperSpec-7-0/HyperSpec/Issues/iss181.htm | 49 + .../HyperSpec/Issues/iss181_w.htm | 163 + .../HyperSpec-7-0/HyperSpec/Issues/iss182.htm | 38 + .../HyperSpec/Issues/iss182_w.htm | 149 + .../HyperSpec-7-0/HyperSpec/Issues/iss183.htm | 36 + .../HyperSpec/Issues/iss183_w.htm | 105 + .../HyperSpec-7-0/HyperSpec/Issues/iss184.htm | 37 + .../HyperSpec/Issues/iss184_w.htm | 137 + .../HyperSpec-7-0/HyperSpec/Issues/iss185.htm | 39 + .../HyperSpec/Issues/iss185_w.htm | 147 + .../HyperSpec-7-0/HyperSpec/Issues/iss186.htm | 39 + .../HyperSpec/Issues/iss186_w.htm | 109 + .../HyperSpec-7-0/HyperSpec/Issues/iss187.htm | 36 + .../HyperSpec/Issues/iss187_w.htm | 265 + .../HyperSpec-7-0/HyperSpec/Issues/iss188.htm | 37 + .../HyperSpec/Issues/iss188_w.htm | 354 + .../HyperSpec-7-0/HyperSpec/Issues/iss189.htm | 37 + .../HyperSpec/Issues/iss189_w.htm | 112 + .../HyperSpec-7-0/HyperSpec/Issues/iss190.htm | 38 + .../HyperSpec/Issues/iss190_w.htm | 105 + .../HyperSpec-7-0/HyperSpec/Issues/iss191.htm | 37 + .../HyperSpec/Issues/iss191_w.htm | 164 + .../HyperSpec-7-0/HyperSpec/Issues/iss192.htm | 39 + .../HyperSpec/Issues/iss192_w.htm | 158 + .../HyperSpec-7-0/HyperSpec/Issues/iss193.htm | 39 + .../HyperSpec/Issues/iss193_w.htm | 121 + .../HyperSpec-7-0/HyperSpec/Issues/iss194.htm | 36 + .../HyperSpec/Issues/iss194_w.htm | 74 + .../HyperSpec-7-0/HyperSpec/Issues/iss195.htm | 36 + .../HyperSpec/Issues/iss195_w.htm | 182 + .../HyperSpec-7-0/HyperSpec/Issues/iss196.htm | 37 + .../HyperSpec/Issues/iss196_w.htm | 105 + .../HyperSpec-7-0/HyperSpec/Issues/iss197.htm | 44 + .../HyperSpec/Issues/iss197_w.htm | 224 + .../HyperSpec-7-0/HyperSpec/Issues/iss198.htm | 37 + .../HyperSpec/Issues/iss198_w.htm | 224 + .../HyperSpec-7-0/HyperSpec/Issues/iss199.htm | 36 + .../HyperSpec/Issues/iss199_m.htm | 32 + .../HyperSpec/Issues/iss199_w.htm | 96 + .../HyperSpec-7-0/HyperSpec/Issues/iss200.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss201.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss202.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss203.htm | 37 + .../HyperSpec-7-0/HyperSpec/Issues/iss204.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss205.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss206.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss207.htm | 39 + .../HyperSpec-7-0/HyperSpec/Issues/iss208.htm | 37 + .../HyperSpec/Issues/iss208_w.htm | 220 + .../HyperSpec-7-0/HyperSpec/Issues/iss209.htm | 36 + .../HyperSpec/Issues/iss209_w.htm | 133 + .../HyperSpec-7-0/HyperSpec/Issues/iss210.htm | 36 + .../HyperSpec/Issues/iss210_w.htm | 77 + .../HyperSpec-7-0/HyperSpec/Issues/iss211.htm | 41 + .../HyperSpec/Issues/iss211_w.htm | 134 + .../HyperSpec-7-0/HyperSpec/Issues/iss212.htm | 37 + .../HyperSpec/Issues/iss212_w.htm | 236 + .../HyperSpec-7-0/HyperSpec/Issues/iss213.htm | 38 + .../HyperSpec/Issues/iss213_w.htm | 119 + .../HyperSpec-7-0/HyperSpec/Issues/iss214.htm | 40 + .../HyperSpec/Issues/iss214_w.htm | 177 + .../HyperSpec-7-0/HyperSpec/Issues/iss215.htm | 40 + .../HyperSpec/Issues/iss215_w.htm | 319 + .../HyperSpec-7-0/HyperSpec/Issues/iss216.htm | 36 + .../HyperSpec/Issues/iss216_m.htm | 32 + .../HyperSpec/Issues/iss216_w.htm | 351 + .../HyperSpec-7-0/HyperSpec/Issues/iss217.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss218.htm | 39 + .../HyperSpec/Issues/iss218_w.htm | 214 + .../HyperSpec-7-0/HyperSpec/Issues/iss219.htm | 36 + .../HyperSpec/Issues/iss219_w.htm | 145 + .../HyperSpec-7-0/HyperSpec/Issues/iss220.htm | 36 + .../HyperSpec/Issues/iss220_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss221.htm | 36 + .../HyperSpec/Issues/iss221_w.htm | 128 + .../HyperSpec-7-0/HyperSpec/Issues/iss222.htm | 36 + .../HyperSpec/Issues/iss222_w.htm | 240 + .../HyperSpec-7-0/HyperSpec/Issues/iss223.htm | 48 + .../HyperSpec/Issues/iss223_w.htm | 262 + .../HyperSpec-7-0/HyperSpec/Issues/iss224.htm | 38 + .../HyperSpec/Issues/iss224_w.htm | 145 + .../HyperSpec-7-0/HyperSpec/Issues/iss225.htm | 37 + .../HyperSpec/Issues/iss225_w.htm | 116 + .../HyperSpec-7-0/HyperSpec/Issues/iss226.htm | 36 + .../HyperSpec/Issues/iss226_w.htm | 330 + .../HyperSpec-7-0/HyperSpec/Issues/iss227.htm | 36 + .../HyperSpec/Issues/iss227_w.htm | 100 + .../HyperSpec-7-0/HyperSpec/Issues/iss228.htm | 38 + .../HyperSpec/Issues/iss228_w.htm | 184 + .../HyperSpec-7-0/HyperSpec/Issues/iss229.htm | 38 + .../HyperSpec/Issues/iss229_w.htm | 260 + .../HyperSpec-7-0/HyperSpec/Issues/iss230.htm | 36 + .../HyperSpec/Issues/iss230_m.htm | 32 + .../HyperSpec/Issues/iss230_w.htm | 133 + .../HyperSpec-7-0/HyperSpec/Issues/iss231.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss232.htm | 36 + .../HyperSpec/Issues/iss232_w.htm | 114 + .../HyperSpec-7-0/HyperSpec/Issues/iss233.htm | 36 + .../HyperSpec/Issues/iss233_w.htm | 88 + .../HyperSpec-7-0/HyperSpec/Issues/iss234.htm | 36 + .../HyperSpec/Issues/iss234_w.htm | 100 + .../HyperSpec-7-0/HyperSpec/Issues/iss235.htm | 36 + .../HyperSpec/Issues/iss235_w.htm | 96 + .../HyperSpec-7-0/HyperSpec/Issues/iss236.htm | 38 + .../HyperSpec/Issues/iss236_w.htm | 367 + .../HyperSpec-7-0/HyperSpec/Issues/iss237.htm | 36 + .../HyperSpec/Issues/iss237_w.htm | 129 + .../HyperSpec-7-0/HyperSpec/Issues/iss238.htm | 37 + .../HyperSpec/Issues/iss238_w.htm | 214 + .../HyperSpec-7-0/HyperSpec/Issues/iss239.htm | 36 + .../HyperSpec/Issues/iss239_w.htm | 132 + .../HyperSpec-7-0/HyperSpec/Issues/iss240.htm | 70 + .../HyperSpec/Issues/iss240_w.htm | 138 + .../HyperSpec-7-0/HyperSpec/Issues/iss241.htm | 36 + .../HyperSpec/Issues/iss241_w.htm | 118 + .../HyperSpec-7-0/HyperSpec/Issues/iss242.htm | 36 + .../HyperSpec/Issues/iss242_w.htm | 224 + .../HyperSpec-7-0/HyperSpec/Issues/iss243.htm | 37 + .../HyperSpec/Issues/iss243_w.htm | 176 + .../HyperSpec-7-0/HyperSpec/Issues/iss244.htm | 36 + .../HyperSpec/Issues/iss244_w.htm | 72 + .../HyperSpec-7-0/HyperSpec/Issues/iss245.htm | 36 + .../HyperSpec/Issues/iss245_w.htm | 131 + .../HyperSpec-7-0/HyperSpec/Issues/iss246.htm | 36 + .../HyperSpec/Issues/iss246_w.htm | 118 + .../HyperSpec-7-0/HyperSpec/Issues/iss247.htm | 36 + .../HyperSpec/Issues/iss247_m.htm | 32 + .../HyperSpec/Issues/iss247_w.htm | 219 + .../HyperSpec-7-0/HyperSpec/Issues/iss248.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss249.htm | 37 + .../HyperSpec/Issues/iss249_w.htm | 84 + .../HyperSpec-7-0/HyperSpec/Issues/iss250.htm | 36 + .../HyperSpec/Issues/iss250_w.htm | 142 + .../HyperSpec-7-0/HyperSpec/Issues/iss251.htm | 37 + .../HyperSpec/Issues/iss251_w.htm | 92 + .../HyperSpec-7-0/HyperSpec/Issues/iss252.htm | 40 + .../HyperSpec/Issues/iss252_w.htm | 271 + .../HyperSpec-7-0/HyperSpec/Issues/iss253.htm | 39 + .../HyperSpec/Issues/iss253_w.htm | 235 + .../HyperSpec-7-0/HyperSpec/Issues/iss254.htm | 55 + .../HyperSpec/Issues/iss254_w.htm | 133 + .../HyperSpec-7-0/HyperSpec/Issues/iss255.htm | 41 + .../HyperSpec/Issues/iss255_w.htm | 95 + .../HyperSpec-7-0/HyperSpec/Issues/iss256.htm | 40 + .../HyperSpec/Issues/iss256_w.htm | 241 + .../HyperSpec-7-0/HyperSpec/Issues/iss257.htm | 38 + .../HyperSpec/Issues/iss257_w.htm | 291 + .../HyperSpec-7-0/HyperSpec/Issues/iss258.htm | 50 + .../HyperSpec/Issues/iss258_w.htm | 230 + .../HyperSpec-7-0/HyperSpec/Issues/iss259.htm | 65 + .../HyperSpec/Issues/iss259_w.htm | 670 + .../HyperSpec-7-0/HyperSpec/Issues/iss260.htm | 39 + .../HyperSpec/Issues/iss260_w.htm | 157 + .../HyperSpec-7-0/HyperSpec/Issues/iss261.htm | 45 + .../HyperSpec/Issues/iss261_m.htm | 32 + .../HyperSpec/Issues/iss261_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss262.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss263.htm | 41 + .../HyperSpec/Issues/iss263_w.htm | 334 + .../HyperSpec-7-0/HyperSpec/Issues/iss264.htm | 37 + .../HyperSpec/Issues/iss264_w.htm | 143 + .../HyperSpec-7-0/HyperSpec/Issues/iss265.htm | 36 + .../HyperSpec/Issues/iss265_w.htm | 238 + .../HyperSpec-7-0/HyperSpec/Issues/iss266.htm | 44 + .../HyperSpec/Issues/iss266_w.htm | 207 + .../HyperSpec-7-0/HyperSpec/Issues/iss267.htm | 49 + .../HyperSpec/Issues/iss267_w.htm | 381 + .../HyperSpec-7-0/HyperSpec/Issues/iss268.htm | 38 + .../HyperSpec/Issues/iss268_w.htm | 224 + .../HyperSpec-7-0/HyperSpec/Issues/iss269.htm | 45 + .../HyperSpec/Issues/iss269_w.htm | 140 + .../HyperSpec-7-0/HyperSpec/Issues/iss270.htm | 54 + .../HyperSpec/Issues/iss270_w.htm | 1515 ++ .../HyperSpec-7-0/HyperSpec/Issues/iss271.htm | 47 + .../HyperSpec/Issues/iss271_w.htm | 154 + .../HyperSpec-7-0/HyperSpec/Issues/iss272.htm | 38 + .../HyperSpec/Issues/iss272_w.htm | 139 + .../HyperSpec-7-0/HyperSpec/Issues/iss273.htm | 36 + .../HyperSpec/Issues/iss273_w.htm | 215 + .../HyperSpec-7-0/HyperSpec/Issues/iss274.htm | 36 + .../HyperSpec/Issues/iss274_w.htm | 74 + .../HyperSpec-7-0/HyperSpec/Issues/iss275.htm | 38 + .../HyperSpec/Issues/iss275_w.htm | 146 + .../HyperSpec-7-0/HyperSpec/Issues/iss276.htm | 46 + .../HyperSpec/Issues/iss276_w.htm | 150 + .../HyperSpec-7-0/HyperSpec/Issues/iss277.htm | 39 + .../HyperSpec/Issues/iss277_w.htm | 120 + .../HyperSpec-7-0/HyperSpec/Issues/iss278.htm | 38 + .../HyperSpec/Issues/iss278_w.htm | 211 + .../HyperSpec-7-0/HyperSpec/Issues/iss279.htm | 45 + .../HyperSpec/Issues/iss279_m.htm | 32 + .../HyperSpec/Issues/iss279_w.htm | 236 + .../HyperSpec-7-0/HyperSpec/Issues/iss280.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss281.htm | 36 + .../HyperSpec/Issues/iss281_w.htm | 121 + .../HyperSpec-7-0/HyperSpec/Issues/iss282.htm | 37 + .../HyperSpec/Issues/iss282_w.htm | 257 + .../HyperSpec-7-0/HyperSpec/Issues/iss283.htm | 37 + .../HyperSpec/Issues/iss283_w.htm | 190 + .../HyperSpec-7-0/HyperSpec/Issues/iss284.htm | 54 + .../HyperSpec/Issues/iss284_w.htm | 126 + .../HyperSpec-7-0/HyperSpec/Issues/iss285.htm | 40 + .../HyperSpec/Issues/iss285_w.htm | 226 + .../HyperSpec-7-0/HyperSpec/Issues/iss286.htm | 37 + .../HyperSpec/Issues/iss286_w.htm | 349 + .../HyperSpec-7-0/HyperSpec/Issues/iss287.htm | 36 + .../HyperSpec/Issues/iss287_w.htm | 201 + .../HyperSpec-7-0/HyperSpec/Issues/iss288.htm | 37 + .../HyperSpec/Issues/iss288_w.htm | 188 + .../HyperSpec-7-0/HyperSpec/Issues/iss289.htm | 37 + .../HyperSpec/Issues/iss289_w.htm | 128 + .../HyperSpec-7-0/HyperSpec/Issues/iss290.htm | 62 + .../HyperSpec/Issues/iss290_w.htm | 206 + .../HyperSpec-7-0/HyperSpec/Issues/iss291.htm | 37 + .../HyperSpec/Issues/iss291_w.htm | 191 + .../HyperSpec-7-0/HyperSpec/Issues/iss292.htm | 37 + .../HyperSpec/Issues/iss292_w.htm | 118 + .../HyperSpec-7-0/HyperSpec/Issues/iss293.htm | 47 + .../HyperSpec/Issues/iss293_w.htm | 320 + .../HyperSpec-7-0/HyperSpec/Issues/iss294.htm | 42 + .../HyperSpec/Issues/iss294_w.htm | 113 + .../HyperSpec-7-0/HyperSpec/Issues/iss295.htm | 37 + .../HyperSpec/Issues/iss295_w.htm | 148 + .../HyperSpec-7-0/HyperSpec/Issues/iss296.htm | 38 + .../HyperSpec/Issues/iss296_w.htm | 135 + .../HyperSpec-7-0/HyperSpec/Issues/iss297.htm | 36 + .../HyperSpec/Issues/iss297_w.htm | 260 + .../HyperSpec-7-0/HyperSpec/Issues/iss298.htm | 37 + .../HyperSpec/Issues/iss298_w.htm | 127 + .../HyperSpec-7-0/HyperSpec/Issues/iss299.htm | 40 + .../HyperSpec/Issues/iss299_w.htm | 133 + .../HyperSpec-7-0/HyperSpec/Issues/iss300.htm | 36 + .../HyperSpec/Issues/iss300_w.htm | 109 + .../HyperSpec-7-0/HyperSpec/Issues/iss301.htm | 36 + .../HyperSpec/Issues/iss301_w.htm | 113 + .../HyperSpec-7-0/HyperSpec/Issues/iss302.htm | 40 + .../HyperSpec/Issues/iss302_w.htm | 147 + .../HyperSpec-7-0/HyperSpec/Issues/iss303.htm | 36 + .../HyperSpec/Issues/iss303_w.htm | 69 + .../HyperSpec-7-0/HyperSpec/Issues/iss304.htm | 36 + .../HyperSpec/Issues/iss304_w.htm | 100 + .../HyperSpec-7-0/HyperSpec/Issues/iss305.htm | 39 + .../HyperSpec/Issues/iss305_w.htm | 124 + .../HyperSpec-7-0/HyperSpec/Issues/iss306.htm | 38 + .../HyperSpec/Issues/iss306_w.htm | 152 + .../HyperSpec-7-0/HyperSpec/Issues/iss307.htm | 36 + .../HyperSpec/Issues/iss307_w.htm | 126 + .../HyperSpec-7-0/HyperSpec/Issues/iss308.htm | 51 + .../HyperSpec/Issues/iss308_w.htm | 174 + .../HyperSpec-7-0/HyperSpec/Issues/iss309.htm | 40 + .../HyperSpec/Issues/iss309_w.htm | 180 + .../HyperSpec-7-0/HyperSpec/Issues/iss310.htm | 36 + .../HyperSpec/Issues/iss310_w.htm | 124 + .../HyperSpec-7-0/HyperSpec/Issues/iss311.htm | 37 + .../HyperSpec/Issues/iss311_w.htm | 150 + .../HyperSpec-7-0/HyperSpec/Issues/iss312.htm | 36 + .../HyperSpec/Issues/iss312_w.htm | 407 + .../HyperSpec-7-0/HyperSpec/Issues/iss313.htm | 36 + .../HyperSpec/Issues/iss313_m.htm | 32 + .../HyperSpec/Issues/iss313_w.htm | 151 + .../HyperSpec-7-0/HyperSpec/Issues/iss314.htm | 36 + .../HyperSpec-7-0/HyperSpec/Issues/iss315.htm | 37 + .../HyperSpec/Issues/iss315_w.htm | 138 + .../HyperSpec-7-0/HyperSpec/Issues/iss316.htm | 39 + .../HyperSpec/Issues/iss316_w.htm | 97 + .../HyperSpec-7-0/HyperSpec/Issues/iss317.htm | 36 + .../HyperSpec/Issues/iss317_w.htm | 197 + .../HyperSpec-7-0/HyperSpec/Issues/iss318.htm | 37 + .../HyperSpec/Issues/iss318_w.htm | 124 + .../HyperSpec-7-0/HyperSpec/Issues/iss319.htm | 41 + .../HyperSpec/Issues/iss319_w.htm | 102 + .../HyperSpec-7-0/HyperSpec/Issues/iss320.htm | 39 + .../HyperSpec/Issues/iss320_w.htm | 164 + .../HyperSpec-7-0/HyperSpec/Issues/iss321.htm | 39 + .../HyperSpec/Issues/iss321_w.htm | 104 + .../HyperSpec-7-0/HyperSpec/Issues/iss322.htm | 36 + .../HyperSpec/Issues/iss322_w.htm | 115 + .../HyperSpec-7-0/HyperSpec/Issues/iss323.htm | 36 + .../HyperSpec/Issues/iss323_w.htm | 208 + .../HyperSpec-7-0/HyperSpec/Issues/iss324.htm | 36 + .../HyperSpec/Issues/iss324_w.htm | 98 + .../HyperSpec-7-0/HyperSpec/Issues/iss325.htm | 37 + .../HyperSpec/Issues/iss325_w.htm | 141 + .../HyperSpec-7-0/HyperSpec/Issues/iss326.htm | 36 + .../HyperSpec/Issues/iss326_w.htm | 123 + .../HyperSpec-7-0/HyperSpec/Issues/iss327.htm | 60 + .../HyperSpec/Issues/iss327_w.htm | 193 + .../HyperSpec-7-0/HyperSpec/Issues/iss328.htm | 36 + .../HyperSpec/Issues/iss328_w.htm | 137 + .../HyperSpec-7-0/HyperSpec/Issues/iss329.htm | 40 + .../HyperSpec/Issues/iss329_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss330.htm | 38 + .../HyperSpec/Issues/iss330_w.htm | 141 + .../HyperSpec-7-0/HyperSpec/Issues/iss331.htm | 38 + .../HyperSpec/Issues/iss331_w.htm | 111 + .../HyperSpec-7-0/HyperSpec/Issues/iss332.htm | 54 + .../HyperSpec/Issues/iss332_w.htm | 134 + .../HyperSpec-7-0/HyperSpec/Issues/iss333.htm | 36 + .../HyperSpec/Issues/iss333_w.htm | 165 + .../HyperSpec-7-0/HyperSpec/Issues/iss334.htm | 39 + .../HyperSpec/Issues/iss334_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss335.htm | 36 + .../HyperSpec/Issues/iss335_w.htm | 169 + .../HyperSpec-7-0/HyperSpec/Issues/iss336.htm | 36 + .../HyperSpec/Issues/iss336_w.htm | 194 + .../HyperSpec-7-0/HyperSpec/Issues/iss337.htm | 38 + .../HyperSpec/Issues/iss337_w.htm | 108 + .../HyperSpec-7-0/HyperSpec/Issues/iss338.htm | 40 + .../HyperSpec/Issues/iss338_w.htm | 174 + .../HyperSpec-7-0/HyperSpec/Issues/iss339.htm | 36 + .../HyperSpec/Issues/iss339_w.htm | 162 + .../HyperSpec-7-0/HyperSpec/Issues/iss340.htm | 36 + .../HyperSpec/Issues/iss340_w.htm | 186 + .../HyperSpec-7-0/HyperSpec/Issues/iss341.htm | 36 + .../HyperSpec/Issues/iss341_w.htm | 119 + .../HyperSpec-7-0/HyperSpec/Issues/iss342.htm | 41 + .../HyperSpec/Issues/iss342_w.htm | 631 + .../HyperSpec-7-0/HyperSpec/Issues/iss343.htm | 36 + .../HyperSpec/Issues/iss343_w.htm | 139 + .../HyperSpec-7-0/HyperSpec/Issues/iss344.htm | 37 + .../HyperSpec/Issues/iss344_w.htm | 193 + .../HyperSpec-7-0/HyperSpec/Issues/iss345.htm | 57 + .../HyperSpec/Issues/iss345_w.htm | 174 + .../HyperSpec-7-0/HyperSpec/Issues/iss346.htm | 36 + .../HyperSpec/Issues/iss346_w.htm | 163 + .../HyperSpec-7-0/HyperSpec/Issues/iss347.htm | 36 + .../HyperSpec/Issues/iss347_w.htm | 185 + .../HyperSpec-7-0/HyperSpec/Issues/iss348.htm | 37 + .../HyperSpec/Issues/iss348_w.htm | 114 + .../HyperSpec-7-0/HyperSpec/Issues/iss349.htm | 36 + .../HyperSpec/Issues/iss349_w.htm | 199 + .../HyperSpec-7-0/HyperSpec/Issues/iss350.htm | 36 + .../HyperSpec/Issues/iss350_m.htm | 32 + .../HyperSpec/Issues/iss350_w.htm | 405 + .../HyperSpec-7-0/HyperSpec/Issues/iss351.htm | 55 + .../HyperSpec-7-0/HyperSpec/Issues/iss352.htm | 36 + .../HyperSpec/Issues/iss352_w.htm | 206 + .../HyperSpec-7-0/HyperSpec/Issues/iss353.htm | 43 + .../HyperSpec/Issues/iss353_w.htm | 172 + .../HyperSpec-7-0/HyperSpec/Issues/iss354.htm | 39 + .../HyperSpec/Issues/iss354_w.htm | 177 + .../HyperSpec-7-0/HyperSpec/Issues/iss355.htm | 38 + .../HyperSpec/Issues/iss355_w.htm | 171 + .../HyperSpec-7-0/HyperSpec/Issues/iss356.htm | 36 + .../HyperSpec/Issues/iss356_w.htm | 127 + .../HyperSpec-7-0/HyperSpec/Issues/iss357.htm | 36 + .../HyperSpec/Issues/iss357_w.htm | 95 + .../HyperSpec-7-0/HyperSpec/Issues/iss358.htm | 37 + .../HyperSpec/Issues/iss358_w.htm | 121 + .../HyperSpec-7-0/HyperSpec/Issues/iss359.htm | 45 + .../HyperSpec/Issues/iss359_w.htm | 89 + .../HyperSpec-7-0/HyperSpec/Issues/iss360.htm | 36 + .../HyperSpec/Issues/iss360_w.htm | 177 + .../HyperSpec-7-0/HyperSpec/Issues/iss361.htm | 36 + .../HyperSpec/Issues/iss361_w.htm | 125 + .../HyperSpec-7-0/HyperSpec/Issues/iss362.htm | 39 + .../HyperSpec/Issues/iss362_w.htm | 120 + .../HyperSpec-7-0/HyperSpec/Issues/iss363.htm | 39 + .../HyperSpec/Issues/iss363_w.htm | 129 + .../HyperSpec-7-0/HyperSpec/Issues/iss364.htm | 36 + .../HyperSpec/Issues/iss364_w.htm | 122 + .../HyperSpec-7-0/HyperSpec/Issues/iss365.htm | 37 + .../HyperSpec/Issues/iss365_w.htm | 139 + .../HyperSpec/Front/Contents.htm | 67 - .../HyperSpec/Front/Hilights.htm | 124 - .../documentation/HyperSpec/Front/NoNext.htm | 32 - .../documentation/HyperSpec/Front/NoPrev.htm | 31 - .../HyperSpec/Front/StartPts.htm | 37 - .../HyperSpec/Front/X3J13Iss.htm | 47 - .../HyperSpec/Front/X_AllSym.htm | 1008 - .../HyperSpec/Front/X_Alph_9.htm | 99 - .../HyperSpec/Front/X_Alph_A.htm | 74 - .../HyperSpec/Front/X_Alph_B.htm | 75 - .../HyperSpec/Front/X_Alph_C.htm | 141 - .../HyperSpec/Front/X_Alph_D.htm | 85 - .../HyperSpec/Front/X_Alph_E.htm | 56 - .../HyperSpec/Front/X_Alph_F.htm | 83 - .../HyperSpec/Front/X_Alph_G.htm | 47 - .../HyperSpec/Front/X_Alph_H.htm | 39 - .../HyperSpec/Front/X_Alph_I.htm | 55 - .../HyperSpec/Front/X_Alph_K.htm | 31 - .../HyperSpec/Front/X_Alph_L.htm | 93 - .../HyperSpec/Front/X_Alph_M.htm | 101 - .../HyperSpec/Front/X_Alph_N.htm | 65 - .../HyperSpec/Front/X_Alph_O.htm | 36 - .../HyperSpec/Front/X_Alph_P.htm | 93 - .../HyperSpec/Front/X_Alph_Q.htm | 30 - .../HyperSpec/Front/X_Alph_R.htm | 85 - .../HyperSpec/Front/X_Alph_S.htm | 159 - .../HyperSpec/Front/X_Alph_T.htm | 56 - .../HyperSpec/Front/X_Alph_U.htm | 50 - .../HyperSpec/Front/X_Alph_V.htm | 37 - .../HyperSpec/Front/X_Alph_W.htm | 52 - .../HyperSpec/Front/X_Alph_Y.htm | 31 - .../HyperSpec/Front/X_Alph_Z.htm | 30 - .../HyperSpec/Front/X_Mast_9.htm | 1274 -- .../HyperSpec/Front/X_Mast_A.htm | 355 - .../HyperSpec/Front/X_Mast_B.htm | 236 - .../HyperSpec/Front/X_Mast_C.htm | 551 - .../HyperSpec/Front/X_Mast_D.htm | 330 - .../HyperSpec/Front/X_Mast_E.htm | 292 - .../HyperSpec/Front/X_Mast_F.htm | 285 - .../HyperSpec/Front/X_Mast_G.htm | 114 - .../HyperSpec/Front/X_Mast_H.htm | 74 - .../HyperSpec/Front/X_Mast_I.htm | 298 - .../HyperSpec/Front/X_Mast_J.htm | 34 - .../HyperSpec/Front/X_Mast_K.htm | 88 - .../HyperSpec/Front/X_Mast_L.htm | 298 - .../HyperSpec/Front/X_Mast_M.htm | 292 - .../HyperSpec/Front/X_Mast_N.htm | 214 - .../HyperSpec/Front/X_Mast_O.htm | 131 - .../HyperSpec/Front/X_Mast_P.htm | 354 - .../HyperSpec/Front/X_Mast_Q.htm | 57 - .../HyperSpec/Front/X_Mast_R.htm | 324 - .../HyperSpec/Front/X_Mast_S.htm | 662 - .../HyperSpec/Front/X_Mast_T.htm | 303 - .../HyperSpec/Front/X_Mast_U.htm | 171 - .../HyperSpec/Front/X_Mast_V.htm | 97 - .../HyperSpec/Front/X_Mast_W.htm | 145 - .../HyperSpec/Front/X_Mast_X.htm | 37 - .../HyperSpec/Front/X_Mast_Y.htm | 37 - .../HyperSpec/Front/X_Mast_Z.htm | 33 - .../HyperSpec/Front/X_Master.htm | 29 - .../HyperSpec/Front/X_Perm_9.htm | 148 - .../HyperSpec/Front/X_Perm_A.htm | 100 - .../HyperSpec/Front/X_Perm_B.htm | 97 - .../HyperSpec/Front/X_Perm_C.htm | 208 - .../HyperSpec/Front/X_Perm_D.htm | 126 - .../HyperSpec/Front/X_Perm_E.htm | 117 - .../HyperSpec/Front/X_Perm_F.htm | 162 - .../HyperSpec/Front/X_Perm_G.htm | 56 - .../HyperSpec/Front/X_Perm_H.htm | 48 - .../HyperSpec/Front/X_Perm_I.htm | 120 - .../HyperSpec/Front/X_Perm_K.htm | 36 - .../HyperSpec/Front/X_Perm_L.htm | 143 - .../HyperSpec/Front/X_Perm_M.htm | 136 - .../HyperSpec/Front/X_Perm_N.htm | 137 - .../HyperSpec/Front/X_Perm_O.htm | 76 - .../HyperSpec/Front/X_Perm_P.htm | 219 - .../HyperSpec/Front/X_Perm_Q.htm | 33 - .../HyperSpec/Front/X_Perm_R.htm | 116 - .../HyperSpec/Front/X_Perm_S.htm | 266 - .../HyperSpec/Front/X_Perm_T.htm | 106 - .../HyperSpec/Front/X_Perm_U.htm | 64 - .../HyperSpec/Front/X_Perm_V.htm | 63 - .../HyperSpec/Front/X_Perm_W.htm | 65 - .../HyperSpec/Front/X_Perm_X.htm | 32 - .../HyperSpec/Front/X_Perm_Y.htm | 32 - .../HyperSpec/Front/X_Perm_Z.htm | 32 - .../documentation/HyperSpec/Front/index.htm | 58 - .../HyperSpec/Front/index_tx.htm | 46 - clones/www.sbcl.org/manual/index.html | 16503 ++++++++++++++++ .../Accessor-Discriminating-Functions.html | 83 + .../sbcl-internals/Additional-Notes.html | 65 + .../sbcl-internals/Assembly-Routines.html | 70 + .../sbcl-internals/Basic-Implementation.html | 105 + .../sbcl-internals/Binding-and-unbinding.html | 82 + clones/www.sbcl.org/sbcl-internals/Build.html | 51 + .../Cacheing-and-Dispatch-Functions.html | 58 + .../sbcl-internals/Callbacks.html | 95 + .../sbcl-internals/Calling-Convention.html | 82 + .../Character-and-String-Types.html | 80 + .../sbcl-internals/Cold-init.html | 64 + .../Compiler-Transformations.html | 123 + .../Discriminating-Functions.html | 75 + .../sbcl-internals/Foreign-Linkage.html | 53 + .../sbcl-internals/Full-Calls.html | 71 + .../sbcl-internals/Funcallable-Instances.html | 52 + .../sbcl-internals/Groups-of-signals.html | 66 + .../sbcl-internals/IR2-Conversion.html | 56 + .../Implementation-_0028Linux-x86_0029.html | 74 + ...plementation-of-Funcallable-Instances.html | 69 + .../sbcl-internals/Implementation-warts.html | 97 + .../sbcl-internals/Lazy-Alien-Resolution.html | 68 + .../sbcl-internals/Linkage_002dtable.html | 128 + .../sbcl-internals/Local-Calls.html | 66 + .../sbcl-internals/MOP-Optimizations.html | 64 + .../sbcl-internals/Memory-Layout.html | 74 + ...od_002dBased-Discriminating-Functions.html | 103 + .../Overview-of-Funcallable-Instances.html | 65 + .../www.sbcl.org/sbcl-internals/Overview.html | 58 + ...gramming-with-signal-handling-in-mind.html | 85 + .../sbcl-internals/Reader-and-Printer.html | 54 + .../sbcl-internals/Signal-handling.html | 54 + .../sbcl-internals/Slot_002dValue.html | 73 + .../www.sbcl.org/sbcl-internals/Specials.html | 52 + .../The-Cacheing-Mechanism.html | 94 + .../The-Initial-Discriminating-Function.html | 87 + .../The-deferral-mechanism.html | 81 + .../www.sbcl.org/sbcl-internals/Threads.html | 49 + .../Unknown_002dValues-Returns.html | 88 + .../discriminating-functions.png | Bin 0 -> 45461 bytes .../sbcl-internals/ex_003abuggycache.html | 1 + .../sbcl-internals/ex_003apred.html | 1 + .../sbcl-internals/ex_003aslot_002dvalue.html | 1 + ...03aslot_002dvalue_002dusing_002dclass.html | 1 + .../fig_003adfun_002dtransitions.html | 1 + clones/www.sbcl.org/sbcl-internals/index.html | 166 + 2479 files changed, 197240 insertions(+), 13062 deletions(-) create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec-Legalese.text create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec-README.text create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/00_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_d.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_da.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_db.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dde.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddh.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddk.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddo.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dds.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddt.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddta.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtdb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddu.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddv.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ead.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eadaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_g.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_h.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_add.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ade.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adfa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adga.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ce.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_d.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_da.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_db.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_de.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_df.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dfa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dh.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhh.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhk.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dho.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhs.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dht.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhu.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhv.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_di.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_be.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_d.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_da.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dadaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_db.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_de.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_df.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dh.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_di.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dk.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ead.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eah.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_g.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ga.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_caa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cdb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ce.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ceb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abh.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaeb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaed.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaee.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaef.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aah.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ababa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaga.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ace.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_afa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aga.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ah.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ai.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_d.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_da.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_eb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ff.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/08_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ababa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abcb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aacb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_add.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aed.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_add.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ade.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ah.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ai.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_baa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbabb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbde.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caah.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ace.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ach.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aci.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ack.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_baa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_caa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ce.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cea.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ceb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ced.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cga.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cge.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ci.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cia.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cib.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cic.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cja.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ck.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_acb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_abaa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ada.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_add.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_9.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_d.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_g.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_h.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_k.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_l.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_n.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_o.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_q.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_r.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_u.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_v.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_y.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_aa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ab.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ae.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_af.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a__.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_abort.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_and.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_atom.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_bit.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_comple.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_cons.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_contin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_eql.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_error.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_float.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_fn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_lambda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_list.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_logica.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_member.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_method.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_mod.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_muffle.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_nil.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_not.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_null.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_or.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ration.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_setf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_sl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_store_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_string.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_type.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_use_va.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_values.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_vector.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_arrays.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_charac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_condit.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_conses.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_data_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_enviro.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_evalua.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_filena.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_files.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_hash_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_iterat.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_number.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_object.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_packag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_printe.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_reader.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_sequen.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_stream.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_string.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_struct.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_symbol.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_system.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_types_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_declar.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_dynami.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ftype.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ignore.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_inline.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_optimi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_specia.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_type.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_arithm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cell_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cnd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_contro.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_divisi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_end_of.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_error.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_file_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_3.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floati.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_parse_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pkg_er.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pr_not.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_progra.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_rder_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_seriou.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_cn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_er.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_tp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_wa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_stm_er.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_storag.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_style_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_tp_err.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unbo_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unboun.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_undefi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_warnin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_1pl_1_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f__.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abortc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abs.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_acons.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_add_me.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjoin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adju_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjust.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alloca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alpha_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alphan.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_append.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apply.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apropo.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_d_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dim.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ele.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_has.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_in_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ran.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_row.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_tot.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_aref.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arithm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arrayp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ash.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_asin_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_assocc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_atom.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boole.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boundp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_break.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_broadc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_and.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_sb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_vec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_butlas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_by_by.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_call_n.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_car_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cell_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cerror.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_n.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_u.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chareq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chg_cl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clas_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_class_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clear_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_close.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clrhas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp__1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_fi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_ma.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmpd_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_code_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_coerce.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_3.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comple.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comput.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conc_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_concat.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conjug.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consta.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_countc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ali.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_lis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ppr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_rdt.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_seq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_stu.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_sym.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_tre.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_fl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_un.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_fi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_pk.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_deposi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_desc_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_descri.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digi_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digit_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dir.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_disass.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_docume.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dpb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dribbl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_echo_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ed.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_elt.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_encode.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_endp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensu_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensure.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq_sle.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eql.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equal.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equalp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_error.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eval.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_evenpc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_everyc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_exp_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_export.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fbound.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fdefin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_l.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_r.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_finish.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_firstc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_float.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floatp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floorc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fmakun.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_kwd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_lam.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fnp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_format.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_funcal.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gcd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gensym.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gentem.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get__1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_in.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_ou.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_pr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_se.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_un.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_getf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gethas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_graphi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_3.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_4.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_5.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_identi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_import.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_in_stm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_init_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inspec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inte_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intege.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intera.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intern.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invali.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invoke.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_isec_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_kwdp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_last.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lcm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ld_log.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb_te.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldiffc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_length.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lisp_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_l.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listen.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_load.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_log.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logand.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logbtp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logcou.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logi_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logica.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logtes.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_v.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_macro_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_makunb.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map_in.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mapc_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_maphas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mask_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_max_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mem_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_meth_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_method.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mexp_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_minusp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mismat.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ar.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_bro.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_cnd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_con.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_dis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ech.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_has.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_i_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ins.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_l_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ld_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_lis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pkg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_rnd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_seq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_stg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_sym.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_syn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_two.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mod_r.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_name_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_namest.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nconc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_next_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_app.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_nex.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_not.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nth.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nthcdr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_null.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_numera.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nump.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_opsetf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pairli.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pars_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_parse_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_peek_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_phase.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg__1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_er.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_na.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_ni.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_sh.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_us.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkgp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_hos.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_mat.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pnp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pos_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_di.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_fi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_in.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_nl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_ta.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_not.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_obj.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_probe_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_procla.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_provid.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_random.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rassoc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rati_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ration.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_by.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_c_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_cha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_del.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_fro.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_lin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_rd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_seq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdta_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdtabl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realpa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reduce.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reinit.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_remhas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rempro.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_replac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rest.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revapp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revers.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_dup.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_met.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_rm.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_fil.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_pkg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rnd_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_room.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_row_ma.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rplaca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rst_na.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sbs_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_search.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set__1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_di.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ex.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ma.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_pp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_sy.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shadow.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shared.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shdw_i.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_short_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signal.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signum.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sin_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sinh_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sleep.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_bo.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ex.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ma.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_mi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_un.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_va.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_bt.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_cn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_ve.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sort_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_specia.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sqrt_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_std_ch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_tr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_up.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgeq_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_el.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_er.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_ex.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stmp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_string.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sublis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subseq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subset.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_substc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subtpp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_svref.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sw_tpc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sxhash.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_3.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_4.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_5.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symbol.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_syn_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_terpri.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_err.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_of.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_log.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_pn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tree_e.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_two_wa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_typep.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unboun.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unexpo.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_uninte.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unionc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unrd_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unuse_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upda_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_update.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgr_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgrad.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upper_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_use_pk.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_user_h.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vals_l.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_values.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_po.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_ps.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vecp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vector.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_warn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wild_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_by.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_cha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_pr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_seq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_stg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_to_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_y_or_n.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_zerop.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/h_glossa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_and.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_assert.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_call_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_case_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_check_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_cond.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_declai.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcla.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcon.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defgen.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_3.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_4.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_5.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_define.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmac.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmet.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpar.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpkg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defset.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defstr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_deftp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defun.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_destru.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_do.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_sym.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dolist.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dotime.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_format.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_hand_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_handle.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ignore.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_in_pkg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_incf_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_lambda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_2.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_multip.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_nth_va.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_or.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pop.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_ex.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_lo.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_po.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pr_unr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog1c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_psetq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pshnew.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_push.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_remf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_return.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rotate.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_bi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_ca.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_setf_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_shiftf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_step.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_time.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tpcase.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tracec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_acce.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_cnd_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_comp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_hash.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_in_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_op_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_open.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_out_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_pkg_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_slts.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_smp_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_std_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_when_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_abort.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_contin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_muffle.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_store_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_use_va.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_block.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_catch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_declar.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_eval_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_flet_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_fn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_go.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_if.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_lambda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ld_tim.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_let_l.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_locall.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_mult_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_multip.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progv.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_quote.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ret_fr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_setq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_symbol.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_tagbod.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_the.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_throw.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_unwind.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_and.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_array.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_atom.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ban.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bignum.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bit.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_broadc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bt_vec.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_built_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_class.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cmpd_f.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_comple.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_concat.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cons.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_echo_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_eql.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_extend.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_file_s.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fixnum.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_float.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_generi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_hash_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_intege.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_kwd.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_list.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_logica.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_member.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_meth_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_method.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_mod.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_nil.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_not.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_null.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_number.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_or.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pkg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pn.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ratio.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ration.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rdtabl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_real.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rnd_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rst.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_satisf.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_seq.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_sgn_by.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_short_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ar.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ba.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_bt.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ve.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ch.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_cl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ge.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_me.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ob.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stg_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stream.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_string.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_cl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_ob.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_symbol.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_syn_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_two_wa.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_unsgn_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_values.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_vector.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__stst_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_dim.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_ran.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_tot.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_b_1_b.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_break_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_call_a.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_char_c.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_fi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_pr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debug_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debugg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_defaul.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_featur.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_gensym.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_intern.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lamb_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lambda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_pns.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_prs.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_mexp_h.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_module.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_1.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_p.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_multip.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_nil.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pi.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pkg.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pl_plp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ar.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_bas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cir.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_esc.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_gen.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lev.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_mis.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ppr.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_pre.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rda.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rig.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_bas.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_def.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_eva.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_sup.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rdtabl.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rnd_st.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_short_.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_sl_sls.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_t.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_termin.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssW.txt create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssX.txt create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_Sym.txt rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Data/clhs.css (100%) create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Data/md5.txt create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/Contents.htm rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Front/Help.htm (68%) create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/Hilights.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoNext.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoPrev.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoUp.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/StartPts.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X3J13Iss.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_AllSym.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_9.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_A.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_B.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_C.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_D.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_E.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_F.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_G.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_H.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_I.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_K.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_L.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_M.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_N.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_O.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_P.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Q.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_R.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_S.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_T.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_U.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_V.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_W.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Y.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Z.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_9.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_A.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_B.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_C.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_D.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_E.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_F.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_G.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_H.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_I.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_J.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_K.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_L.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_M.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_N.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_O.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_P.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Q.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_R.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_S.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_T.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_U.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_V.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_W.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_X.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Y.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Z.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Master.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_9.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_A.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_B.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_C.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_D.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_E.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_F.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_G.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_H.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_I.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_K.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_L.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_M.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_N.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_O.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_P.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Q.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_R.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_S.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_T.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_U.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_V.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_W.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_X.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Y.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Z.htm rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Front/X_Symbol.htm (62%) create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/index.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Front/index_tx.htm rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/CLHS_Lg.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/CLHS_Sm.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Contents.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Glossary.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Help.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Hilights.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Index.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Issues.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/LWLarge.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/LWSmall.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Next.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/NoNext.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/NoPrev.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/NoUp.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Prev.gif (100%) create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Quadrant.gif rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/StartPts.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Symbols.gif (100%) rename clones/lisp/{www.lispworks.com/documentation => HyperSpec-7-0}/HyperSpec/Graphics/Up.gif (100%) create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ARR.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CHA.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CLO.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COL.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COM.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CON.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ENV.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FIL.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FUN.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_IO.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ITE.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_MIS.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_NUM.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_STR.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYM.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYN.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TAB.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TYP.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Alpha.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Categ.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss018.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss027.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss028.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss029.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss030.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss031.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss032.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss033.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss034.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss035.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss036.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss037.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss038.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss039.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss040.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss041.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss042.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss043.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss044.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss045.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss076.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss150.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss160.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss179.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss200.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss201.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss202.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss203.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss204.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss205.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss206.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss207.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss217.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss231.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss248.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss262.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss280.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss314.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_m.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss351.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364_w.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365.htm create mode 100644 clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365_w.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Contents.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Hilights.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoNext.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoPrev.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/StartPts.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_AllSym.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_9.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_A.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_B.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_C.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_D.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_E.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_F.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_G.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_H.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_I.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_K.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_L.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_M.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_N.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_O.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_P.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Q.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_R.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_S.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_T.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_U.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_V.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_W.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Y.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Z.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_9.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_A.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_B.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_C.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_D.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_E.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_F.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_G.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_H.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_I.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_J.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_K.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_L.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_M.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_N.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_O.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_P.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Q.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_R.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_S.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_T.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_U.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_V.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_W.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_X.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Y.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Z.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Master.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_9.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_A.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_B.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_C.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_D.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_E.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_F.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_G.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_H.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_I.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_K.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_L.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_M.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_N.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_O.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_P.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Q.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_R.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_S.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_T.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_U.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_V.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_W.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_X.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Y.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Z.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index.htm delete mode 100644 clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index_tx.htm create mode 100644 clones/www.sbcl.org/manual/index.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Accessor-Discriminating-Functions.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Additional-Notes.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Assembly-Routines.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Basic-Implementation.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Binding-and-unbinding.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Build.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Cacheing-and-Dispatch-Functions.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Callbacks.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Calling-Convention.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Character-and-String-Types.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Cold-init.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Compiler-Transformations.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Discriminating-Functions.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Foreign-Linkage.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Full-Calls.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Funcallable-Instances.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Groups-of-signals.html create mode 100644 clones/www.sbcl.org/sbcl-internals/IR2-Conversion.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Implementation-_0028Linux-x86_0029.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Implementation-of-Funcallable-Instances.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Implementation-warts.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Lazy-Alien-Resolution.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Linkage_002dtable.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Local-Calls.html create mode 100644 clones/www.sbcl.org/sbcl-internals/MOP-Optimizations.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Memory-Layout.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Method_002dBased-Discriminating-Functions.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Overview-of-Funcallable-Instances.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Overview.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Programming-with-signal-handling-in-mind.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Reader-and-Printer.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Signal-handling.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Slot_002dValue.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Specials.html create mode 100644 clones/www.sbcl.org/sbcl-internals/The-Cacheing-Mechanism.html create mode 100644 clones/www.sbcl.org/sbcl-internals/The-Initial-Discriminating-Function.html create mode 100644 clones/www.sbcl.org/sbcl-internals/The-deferral-mechanism.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Threads.html create mode 100644 clones/www.sbcl.org/sbcl-internals/Unknown_002dValues-Returns.html create mode 100644 clones/www.sbcl.org/sbcl-internals/discriminating-functions.png create mode 100644 clones/www.sbcl.org/sbcl-internals/ex_003abuggycache.html create mode 100644 clones/www.sbcl.org/sbcl-internals/ex_003apred.html create mode 100644 clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue.html create mode 100644 clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue_002dusing_002dclass.html create mode 100644 clones/www.sbcl.org/sbcl-internals/fig_003adfun_002dtransitions.html create mode 100644 clones/www.sbcl.org/sbcl-internals/index.html diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec-Legalese.text b/clones/lisp/HyperSpec-7-0/HyperSpec-Legalese.text new file mode 100644 index 00000000..34436dbf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec-Legalese.text @@ -0,0 +1,150 @@ +For legal purposes, this document duplicates in plain text +important legal information available in the hypertext. +Please read this information carefully BEFORE copying or +installing the Common Lisp HyperSpec (TM). + + +------------------------------------------------------------------------ + AUTHORSHIP INFORMATION +------------------------------------------------------------------------ + +The Common Lisp HyperSpec is not the ANSI Common Lisp standard, but is +based on that standard (with permission from ANSI and X3). + +As an official reference to the Common Lisp language, hardcopy +documentation of ANSI Common Lisp, (American National Standard X3.226) +from ANSI is always definitive. + +The hypertext markup for this document was created by Kent Pitman, with +the aid of a custom program written in ANSI Common Lisp and created +specifically for this task. Funding for the markup task was provided by +and copyright of the result is owned by LispWorks Ltd. + +Some additional design documents have been included in marked up form +and cross-referenced which are not part of the standard but may be +useful in understanding it. Plaintext versions of these documents, +which offer a useful historical perspective, are available to anyone +by anonymous public FTP from ftp://parcftp.xerox.com/pub/cl/cleanup/. + +The Java applet used in the Symbol Index (visible only in some +browsers) was written by Evan Williams. Its copyright is owned by +LispWorks Ltd. + +------------------------------------------------------------------------ + IMPORTANT LEGAL NOTICES +------------------------------------------------------------------------ + +COPYRIGHT AND CONDITIONS OF USE + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved. + +The HTML hypertext markup that implements the hypertext features of +these World Wide Web pages of the Common Lisp specification, +collectively the Common Lisp HyperSpec, is the property of LispWorks +Ltd. + +Distribution of the Common Lisp HyperSpec as a hypertext document on +the Internet does not constitute consent to any use of the underlying +hypertext markup for redistribution of any kind, commercial or +otherwise, either via the Internet or using some other form of +distribution, in hypertext or otherwise. + +Permission to copy, distribute, display, and transmit the Common Lisp +HyperSpec is granted provided that copies are not made or distributed +or displayed or transmitted for direct commercial advantage, that +notice is given that copying, distribution, display, and/or +transmission is by permission of LispWorks Ltd., and that any +copy made is COMPLETE and UNMODIFIED. IN PARTICULAR, the material that +MUST appear in the copy includes: + + 1. this copyright notice and its date; + 2. the main index page, HyperSpec/Front/index.htm; + 3. all HTML pages to which the main index page links using relative links; + 4. all graphical (GIF) images to which it links using relative links, + such as the LispWorks logo that appears on each page; and + 5. all hypertext links, relative or absolute, such as the link + to http://www.lispworks.com/ that appears on each page. + +Permissions related to performance and to creation of derivative works +are expressly NOT granted. + +Permission to make partial copies is expressly NOT granted, EXCEPT +that limited permission is granted to transmit and display a partial +copy the Common Lisp HyperSpec for the ordinary purpose of direct +viewing by a human being in the usual manner that hypertext browsers +permit the viewing of such a complete document, provided that no +recopying, redistribution, redisplay, or retransmission is made of any +such partial copy. + +Permission to make modified copies is expressly NOT granted. + +Permission to add or replace any links or any graphical images to any +of these pages is expressly NOT granted. + +Permission to use any of the included graphical (GIF) images in any +document other than the Common Lisp HyperSpec is expressly NOT granted. + +ACKNOWLEDGMENTS + +Parts of this work incorporate material taken from American National +Standard X3.226, copyright 1994, and is used with permission of the X3 +Secretariat, ITI, 1250 Eye St., NW., Suite 200, Washington, DC 20005 +and of the copyright holder, American National Standards Institute. +ANSI/X3.226 was developed by Technical Committee X3J13, Common Lisp. + +Copies of the ANSI/X3.226 standard may be purchased from the American +National Standards Institute, 11 West 42nd Street, New York, NY 10036. + +RESTRICTED RIGHTS LEGEND + +The Common Lisp HyperSpec is subject to the following Restricted +Rights Legend: + + ``Use, duplication, or disclosure by the United States Government is + subject to the restrictions set forth in (i) FAR 52.227-14 Alt III, + (ii) FAR 52.227-19, (iii) DFARS 252.7013(c)(1)(ii), or + (iv) the accompanying license Agreement, as applicable. + For purposes of the FAR, the Software shall be deemed to be + ``unpublished'' and licensed with disclosure prohibitions, + rights reserved under the copyright laws of the United States. + LispWorks Ltd., St John's Innovation Centre, Cowley Road, + Cambridge, CB4 0WS, England.'' + +WARRANTY DISCLAIMER + +THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND +NON-INFRINGEMENT. IN NO EVENT WILL LISPWORKS BE LIABLE FOR DIRECT, +INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM +ANY INACCURACY OR ERROR IN THIS DOCUMENT, EVEN IF ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + +ADDITIONAL DISCLAIMERS + +Not all notations in that TeX-based document were possible to +represent exactly in HTML, although an attempt has been made to be as +accurate as possible. Nevertheless, the process of translation was +heuristic, and discrepancies might have resulted. Formally, the +official ANSI printed document is always the definitive reference. + +The X3J13 issue documents are not part of the standard and are +provided purely for historical perspective. It is possible that some +of the documents, as included, are not the final form that X3J13 +voted, or that some which were voted were omitted, or that references +from these documents into the source text are not complete, or that +some edits prescribed by these documents were incorrectly implemented, +or that other discrepancies exist between these documents and the +specification. These documents have no formal weight, and in all +cases, the hardcopy specification is definitive. + +TRADEMARKS + +LispWorks and Liquid Common Lisp are registered trademarks of +LispWorks Ltd. + +The LispWorks logo and Common Lisp HyperSpec are trademarks of +LispWorks Ltd. + +All other brand and product names mentioned herein are trademarks or +registered trademarks of their respective owners. diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec-README.text b/clones/lisp/HyperSpec-7-0/HyperSpec-README.text new file mode 100644 index 00000000..f9c00eab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec-README.text @@ -0,0 +1,41 @@ +The following files are of special interest: + + HyperSpec-Legalese.text + + This file contains IMPORTANT LEGAL NOTICES such as + Copyright and Conditions of Use, Acknowledgements, + Restricted Rights Legend, Warranty Disclaimers, and + Trademark notices. + + HyperSpec/Front/Help.htm + + This file contains the same IMPORTANT LEGAL NOTICES, + but in HTML format rather than plain ASCII. + + HyperSpec/Front/index.htm + + This is the cover page of the HTML document, + the Common Lisp HyperSpec (TM). + + HyperSpec/Data/md5.txt + + In order to provide a degree of confidence about + copies of this document, we have computed the MD5 + message-digest signature for each of the files in + the distribution. Independent computation of the + signature of each transferred file and verification + against these signatures may be used to claim a + substantially higher confidence level that the + transfer has been done correctly, but it is not an + absolute guarantee of correctness. + + The use of this signature information is primarily + of use to assure that a data transfer has been + complete and correct in cases where there may be + some doubt about that fact, or to re-verify a data + storage area after a suspected disk corruption of + some kind. + + For further information on the MD5 message-digest + signature and the algorithm for computing it, + consult RFC 1321. diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/00_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/00_.htm new file mode 100644 index 00000000..87983b0d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/00_.htm @@ -0,0 +1,335 @@ + + + +CLHS: Credits + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+Credits

+

+

+

+Principal Technical Editors:  
+
                                                                           
+Kent M. Pitman                Harlequin, Inc.                1993-present  
+                              Symbolics, Inc.                1990-1992     
+Kathy Chapman                 Digital Equipment Corporation  1987-1989     
+
                                                                           
+Occasional Guest Editors:     
+
                                                                           
+Richard P. Gabriel            Lucid, Inc.                    
+Sandra Loosemore              self                           
+
+

+

+

+Financial Contributors to the Editing Process:  
+
                                                
+Digital Equipment Corporation                   
+Harlequin, Ltd. and Harlequin, Inc.             
+Symbolics, Inc.                                 
+Apple, Inc.                                     
+Franz, Inc.                                     
+Lucid, Inc.                                     
+
+

+

+Special thanks to Guy L. Steele Jr. and Digital Press for producing Common Lisp: The Language, and for relaxing copyright restrictions enough to make it possible for that document's text to provide an early basis of this work.

+

+

+Edit and Review History:                                                                                      
+
                                                                                                 
+01-Jan-89  Chapman      Draft of Chapters 1.1 (scope).                                           
+01-Jan-89  Pitman       Draft of Chapters 5.1 (conditions).                                      
+01-May-89  Chapman      Draft of 1.2--1.6.                                                       
+01-May-89  Gabriel      Rewrite of Chapters 1.1 and 5.1.                                         
+01-Jun-89  Loosemore    Review of Chapter 4.2.                                                   
+01-Jun-89  Pitman       Review of Glossary                                                       
+15-Jun-89  Gabriel      Rewrite of Glossary                                                      
+16-Jun-89  Margolin     Comments on Chapters 2.1--2.4 (types, objects).                          
+23-Jun-89  Gabriel      Rewrite of 4.2.                                                          
+07-Jul-89  Moon         Review of Chapters 4.1, 4.3                                              
+12-Jul-89  Gabriel      Revision of 4.2.                                                         
+15-Jul-89  Pitman       Review of Glossary                                                       
+18-Jul-89  Gray         Comments on 5.1                                                          
+25-Jul-89  Gabriel      Revision of Chapters 1.2--1.6, 2.2                                       
+26-Jul-89  Gabriel      Rewrite of 5.1                                                           
+26-Jul-89  Gabriel      Rewrite of 4.1.                                                          
+27-Jul-89  Pitman       Revision of 5.1                                                          
+27-Jul-89  Gabriel      Revision of 5.1                                                          
+28-Jul-89  Chapman      Draft of 2.2, 3.2, 3.3, 5.4                                              
+28-Jul-89  Gabriel      Revision of Glossary.                                                    
+01-Oct-89  Margolin     Review of Dictionary from Jun-89 draft.                                  
+20-Jan-91  Pitman       Draft 8.81 (for X3J13 review). Document X3J13/91-101.                    
+29-Jan-91  Waters       Review of 8.81/Chapter 23 (Printer).                                     
+01-Mar-91  Moon         Review of 8.81/Chapter 4 (Evaluation and Compilation).                   
+01-Mar-91  Barrett      Review of 8.81/Chapter 4 (Evaluation and Compilation).                   
+01-Mar-91  Moon         Review of 8.81/Glossary.                                                 
+13-Mar-90  Wechsler     Review of 8.81/Glossary.                                                 
+21-Mar-91  Kerns        Review of 8.81/Chapter 1.                                                
+26-Apr-91  Margolin     Review of 8.81/Chapters 1--12.                                           
+15-May-91  Barrett      Review of 8.81/Chapters 5 (Misc), 11 (Conditions).                       
+04-Jun-91  Laddaga      Review of 9.60/Chapter 20 (Pathnames).                                   
+10-Jun-91  Pitman       Draft 9.126 (for X3J13 review). Document X3J13/91-102.                   
+02-Sep-91  Barrett      Review of 9.28/Chapter 4 (Evaluation and Compilation).                   
+02-Sep-91  Barrett      Review of 9.52/Chapter 4 (Evaluation and Compilation).                   
+15-Sep-91  Barrett      Review of 9.126/Chapter 4 (Evaluation and Compilation)                   
+                        and Chapter 7 (Evaluation/Compilation).                                  
+                        (some comments not yet merged)                                           
+18-Sep-91  Wechsler     Review of 9.126.                                                         
+21-Sep-91  Barrett      Review of 10.16/Chapter 7 (Evaluation/Compilation).                      
+                        (some comments not yet merged)                                           
+28-Sep-91  Barrett      Review of 10.95/Chapter 25 (Printer).                                    
+                        (some comments not yet merged)                                           
+13-Oct-91  Barrett      Review (and help editing) of 10.104/Chapter 4                            
+                        (Evaluation and Compilation)                                             
+15-Oct-91  Waters       Review of 10.95/Chapter 25 (Printer).                                    
+24-Oct-91  Pitman       Draft 10.156 (for X3J13 review). Document X3J13/91-103.                  
+04-Nov-91  Moon         Review of 10.156/Chapter 5 (Data and Control Flow)                       
+                        and Chapter 26 (Glossary).                                               
+11-Nov-91  Loosemore    Review of 10.156/Chapter 2 (Syntax),                                     
+                        Chapter 3 (Evaluation and Compilation),                                  
+                        Chapter 5 (Data and Control Flow), and Chapter 8 (Structures).           
+02-Dec-91  Barrett      Review of 10.156/Chapter 4 (Types and Classes),                          
+                        and Chapter 10 (Symbols).                                                
+02-Dec-91  Barrett      Review of 10.156/Chapter 3 (Evaluation and Compilation),                 
+                        Chapter 6 (Iteration), Chapter 9 (Conditions),                           
+                        and Chapter 14 (Conses).                                                 
+                        (some comments not yet merged)                                           
+09-Dec-91  Gabriel      Review of 10.156/Chapter 1 (Introduction),                               
+                        Chapter 2 (Syntax), and Chapter 3 (Evaluation and Compilation).          
+09-Dec-91  Ida          Light review of 10.156/Chapters 1-5.                                     
+09-Dec-91  Moon         Review of 10.156/Chapter 3 (Evaluation and Compilation).                 
+                        (some comments not yet merged)                                           
+10-Dec-91  Loosemore    Review of 10.156/Chapter 10 (Symbols),                                   
+                        Chapter 20 (Files), and Chapter 13 (Characters).                         
+10-Dec-91  Loosemore    Review of 10.156/Chapter 14 (Conses).                                    
+                        (some comments not yet merged)                                           
+10-Dec-91  Laubsch      Review of 10.156/Chapters 1 (Introduction),                              
+                        Chapter 2 (Syntax), Chapter 3 (Evaluation and Compilation),              
+                        Chapter 4 (Types and Classes), Chapter 5 (Data and Control Flow),        
+                        Chapter 7 (Objects), Chapter 11 (Packages),                              
+                        Chapter 19 (Filenames), and Chapter 21 (Streams).                        
+18-Dec-91  Margolin     Review of 10.156/Chapter 18 (Hash Tables).                               
+04-Jan-92  White        Review of 10.156/Chapter 6 (Iteration),                                  
+                        Chapter 11 (Packages), Chapter 18 (Hash Tables),                         
+                        and Chapter 23 (Reader).                                                 
+04-Jan-92  White        Review of 10.156/Chapter 26 (Glossary).                                  
+                        (some comments not yet merged)                                           
+04-Jan-92  Barrett      Review of 10.156/Chapter 18 (Hash Tables) and Chapter 16 (Strings).      
+04-Jan-92  Barrett      Review of 10.156/Chapter 15 (Arrays) and Chapter 21 (Streams).           
+                        (some comments not yet merged)                                           
+06-Jan-92  Loosemore    Review of 10.156/Chapter 16 (Strings),                                   
+                        Chapter 17 (Sequences), and Chapter 25 (Environment).                    
+06-Jan-92  Loosemore    Review of 10.156/Chapter 21 (Streams) and Chapter 23 (Reader).           
+                        (some comments not yet merged)                                           
+06-Jan-92  Margolin     Review of 10.156/Chapter 2 (Syntax).                                     
+07-Jan-92  Margolin     Review of 10.156/Chapter 4 (Types and Classes).                          
+03-Feb-92  Aspinall     Review of 10.156/Chapter 12 (Numbers).                                   
+16-Feb-92  Pitman       Draft 11.82 (for X3J13 letter ballot). Document X3J13/92-101.            
+16-Mar-92  Loosemore    Review of 11.82/Chapter 1, 3-5, 7-12, 18, and 22-26.                     
+16-Feb-92  Pitman       Draft 12.24 (for X3 consideration). Document X3J13/92-102.               
+09-Sep-92  Samson       Public Review Comments (#1). Documents X3J13/92-1001 to 92-1003.         
+22-Oct-92  Rose, Yen    Public Review Comments (#2). Documents X3J13/92-1101 to 92-1103.         
+23-Oct-92  Staley       Public Review Comments (#3). Documents X3J13/92-1201 to 92-1204.         
+09-Nov-92  Barrett      Public Review Comments (#4). Documents X3J13/92-3101 to 92-3110.         
+11-Nov-92  Moon         Public Review Comments (#5). Documents X3J13/92-3201 to 92-3248.         
+17-Nov-92  Loosemore    Public Review Comments (#6). Documents X3J13/92-1301 to 92-1335.         
+23-Nov-92  Margolin     Public Review Comments (#7). Documents X3J13/92-1401 to 92-1419.         
+23-Nov-92  Withington   Public Review Comments (#8a). Documents X3J13/92-1501 to 92-1512.        
+23-Nov-92  Feinberg     Public Review Comments (#8b). Documents X3J13/92-1601 to 92-1603.        
+23-Nov-92  Wechsler     Public Review Comments (#8c). Documents X3J13/92-1701 to 92-1703.        
+23-Nov-92  Moore        Public Review Comments (#9). Documents X3J13/92-1801 to 92-1802.         
+23-Nov-92  Flanagan     Public Review Comments (#10). Documents X3J13/92-1901 to 92-1910.        
+23-Nov-92  Dalton       Public Review Comments (#11). Documents X3J13/92-2001 to 92-2012.        
+23-Nov-92  Gallagher    Public Review Comments (#12). Documents X3J13/92-2101 to 92-2103.        
+23-Nov-92  Norvig       Public Review Comments (#13). Documents X3J13/92-2201 to 92-2208.        
+24-Nov-92  Robertson    Public Review Comments (#14). Document X3J13/92-2301.                    
+23-Nov-92  Kawabe       Public Review Comments (#15). Documents X3J13/92-2401 to 92-2403.        
+23-Nov-92  Barrett      Public Review Comments (#16). Documents X3J13/92-2511 to X3J13/92-2531.  
+23-Nov-92  Wertheimer   Public Review Comments (#17). Document X3J13/92-2601.                    
+24-Nov-92  Pitman       Public Review Comments (#18). Documents X3J13/92-2701 to 92-2742.        
+24-Nov-92  Mato Mira    Public Review Comments (#19). Documents X3J13/92-2801 to 92-2805.        
+24-Nov-92  Philpot      Public Review Comments (#20). Document X3J13/92-2901.                    
+23-Nov-92  Cerys        Public Review Comments (#21). Document X3J13/92-3001.                    
+30-Aug-93  Pitman       Draft 13.65 (for X3J13 consideration). Document X3J13/93-101.            
+04-Oct-93  X3J13        Minor fixes to Draft 13.65 before sending to X3.                         
+05-Oct-93  Pitman       Draft 14.10 (for X3 consideration). Document X3J13/93-102.               
+08-Nov-93  Dalton       ``reply to reply to pr comments''. Document X3J13/94-311.                
+04-Apr-94  Boyer, Kaufmann, Moore                                                                         
+                        Public Review Comments (#1). Document X3J13/94-305.                      
+05-Apr-94  Pitman       Public Review Comments (#2). Document X3J13/94-306.                      
+14-Mar-94  Schulenburg  Public Review Comments (#3). Document X3J13/94-307.                      
+04-Apr-94  Shepard      Late commentary. Document X3J13/94-309.                                  
+05-May-94  X3J13        Editorial-only changes to Draft 14.10 in response to comments.           
+10-May-94  Pitman       Draft 15.17 (for X3 consideration). Document X3J13/94-101.               
+12-Aug-94  X3J13        Letter ballot to make specific corrections to Credits.                   
+                        Drafts 15.17 and 15.17R are identical except for:                        
+                        Changes to document date and version number.                             
+                        Disclaimer added to back of cover page.                                  
+                        Changes to this Edit and Review History, page Credits iv.                
+                        Changes to names and headings, pages Credits v-vii.                      
+12-Aug-94  Pitman       Draft 15.17R (for X3 consideration). Document ANSI X3.266-1994.          
+01-Feb-94  Pitman       Pre-publication changes per ANSI. This is ANSI X3.226-1994!              
+
+

+

+

+The following lists of information are almost certainly incomplete, but it was felt that it was better to risk publishing incomplete information than to fail to acknowledge important contributions by the many people and organizations who have contributed to this effort.

+Mention here of any individual or organization does not imply endorsement of this document by that individual or organization.

+

+Ad Hoc Group Chairs:                              
+
                                                  
+Characters                  Linden, Thom          
+Charter                     Ennis, Susan P.       
+Compiler Specification      Haflich, Steven M.    
+                            Loosemore, Sandra     
+Editorial                   Chapman, Kathy        
+                            van Roggen, Walter    
+Error and Condition System  Pitman, Kent M.       
+Graphics &Windows           Douglas Rand          
+                            Schoen, Eric          
+Iteration Facility          White, JonL           
+Language Cleanup            Masinter, Larry       
+                            Fahlman, Scott        
+Lisp1/Lisp2                 Gabriel, Richard P.   
+Macros                      Haflich, Steven M.    
+                            Pitman, Kent M.       
+                            Wegman, Mark          
+Object System               Bobrow, Daniel G.     
+Presentation of Standard    Brown, Gary L.        
+Pretty Printer              Waters, Richard C.    
+Public Review               Ida, Masayuki         
+Types &Declarations         Scherlis, William L.  
+Validation                  Berman, Richard       
+
+

+

+

+Major Administrative Contributions:  
+
                                                          
+Barrett, Kim                         Mathis, Robert       
+Brown, Gary L.                       Pitman, Kent M.      
+Eiron, Hanoch                        Steele, Guy L., Jr.  
+Gabriel, Richard P.                  Tyson, Mabry         
+Haflich, Steven M.                   Van Deusen, Mary     
+Ida, Masayuki                        White, JonL          
+Loeffler, David D.                   Whittemore, Susan    
+Loosemore, Sandra                    Woodyatt, Anne       
+Masinter, Larry                      Zubkoff, Jan L.      
+
+

+

+

+Major Technical Contributions:  
+
                                                                        
+Barrett, Kim A.                 Keene, Sonya       Moon, David A.       
+Bobrow, Daniel G.               Kempf, James       Perdue, Crispin      
+Daniels, Andy                   Kerns, Robert W.   Pitman, Kent M.      
+DeMichiel, Linda G.             Kiczales, Gregor   Steele, Guy L., Jr.  
+Dussud, Patrick H.              Loosemore, Sandra  Waters, Richard C.   
+Fahlman, Scott                  Margolin, Barry    Weinreb, Daniel      
+Gabriel, Richard P.             Masinter, Larry    White, JonL          
+Ida, Masayuki                   Mlynarik, Richard                       
+
+

+

+Participating Companies and Organizations:  
+
                                                                           
+AI Architects, Inc.                         Lucid, Inc.                    
+Amoco Production Co.                        MCC                            
+Aoyama Gakuin University                    MIT                            
+Apple Computer                              MITRE Corporation              
+Boeing Advanced Technology Center           MSC                            
+Carnegie-Mellon University                  NASA Ames Research Center      
+Chestnut Software                           National Bureau of Standards   
+Computer Sciences                           Nihon Symbolics                
+Computer & Business Equipment Manufacturing Association (X3 Secretariat)                               
+CONTEL                                      ParcPlace Systems, Inc.        
+CSC                                         Prime Computer                 
+DARPA                                       Siemens                        
+Digital Equipment Corporation               Southern Illinois University   
+Encore                                      Sperry                         
+Evans & Sutherland                          SRI International              
+Franz, Inc.                                 Sun Microsystems               
+Gigamos                                     Symbolics                      
+GMD                                         Tektronix                      
+Gold Hill                                   Texas Instruments              
+Grumman Data Systems Corporation            The Aerospace Corporation      
+Harlequin, Ltd.                             Thinking Machines Corporation  
+Hewlett-Packard                             Unisys                         
+Honeywell                                   University of Bath             
+IBM                                         University of Edinburgh        
+Ibuki                                       University of Maryland         
+Integrated Inference Machines               University of Utah             
+International LISP Associates               US Army                        
+Johnson Controls, Inc.                      USC/ISI                        
+LMI                                         Xerox                          
+
+

+

+

+Individual Participants:  
+
                                                                         
+Adler, Annette            Haflich, Steven M.      Peck, Jeff             
+Allen, Stanley            Harris, Richard M.      Pellegrino, Bob        
+Antonisse, Jim            Hendler, Jim            Perdue, Crispin        
+Arbaugh, Bill             Hewitt, Carl            Philipp, Christopher   
+Balzer, Bob               Hornig, Charles         Pierson, Dan           
+Barrett, Kim              Ida, Masayuki           Pitman, Kent M.        
+Bartley, David H.         Kachurik, Catherine A.  Posner, Dave           
+Beckerle, Michael         Kahn, Ken               Raghavan, B.           
+Beiser, Paul              Keene, Sonya            Rand, Douglas          
+Benson, Eric              Keller, Shaun           Rininger, Jeff         
+Berman, Richard           Kempf, James            Rosenking, Jeffrey P.  
+Bobrow, Daniel G.         Kerns, Robert W.        Scherlis, William L.   
+Boelk, Mary P.            Kiczales, Gregor        Shiota, Eiji           
+Brittain, Skona           Kolb, Dieter            Sizer, Andy            
+Brown, Gary L.            Koschmann, Timothy      Slater, David          
+Chailloux, Jerome         Kosinski, Paul          Sodan, Angela          
+Chapman, Kathy            Larson, Aaron           Soley, Richard M.      
+Clinger, Will             Latto, Andy             Squires, Stephen L.    
+Coffee, Peter C.          Laubsch, Joachim        St. Clair, Bill        
+Cugini, John              Layer, Kevin            Stanhope, Philip       
+Curtis, Pavel             Linden, Thom            Steele, Guy L., Jr.    
+Dabrowski, Christopher    Loeffler, David D.      Tucker, Paul           
+Daessler, Klaus           Loosemore, Sandra       Turba, Thomas          
+Dalton, Jeff              Magataca, Mituhiro      Unietis, Dave          
+Daniels, Andy             Margolin, Barry         Van Deusen, Mary       
+DeMichiel, Linda G.       Masinter, Larry         van Roggen, Walter     
+Doi, Takumi               Mathis, Robert          Waldrum, Ellen         
+Drescher, Gary            Matthews, David C.      Waters, Richard C.     
+Duggan, Jerry             McCarthy, John          Wechsler, Allan        
+Dussud, Patrick H.        Mikelsons, Martin       Wegman, Mark           
+Ennis, Susan P.           Mlynarik, Richard       Weinreb, Daniel        
+Fahlman, Scott            Moon, David A.          Weyhrauch, Richard     
+Frayman, Felix            Moore, Timothy          White, JonL            
+Gabriel, Richard P.       Nicoud, Stephen         Wieland, Alexis        
+Giansiracusa, Bob         Nilsson, Jarl           Withington, P. Tucker  
+Goldstein, Brad           O'Dell, Jim             Wright, Whitman        
+Gray, David               Ohlander, Ron           York, Bill             
+Greenblatt, Richard       Padget, Julian          Zacharias, Gail        
+Hadden, George D.         Palter, Gary            Zubkoff, Jan L.        
+
+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_.htm new file mode 100644 index 00000000..afaa81f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_.htm @@ -0,0 +1,59 @@ + + + +CLHS: Chapter 1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+1. Introduction

+

+ + +

+1.1 Scope, Purpose, and History

+ +

+1.2 Organization of the Document

+ +

+1.3 Referenced Publications

+ +

+1.4 Definitions

+ +

+1.5 Conformance

+ +

+1.6 Language Extensions

+ +

+1.7 Language Subsets

+ +

+1.8 Deprecated Language Features

+ +

+1.9 Symbols in the COMMON-LISP Package

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_a.htm new file mode 100644 index 00000000..b6fac131 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_a.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.1 Scope, Purpose, and History

+ +

+1.1.1 Scope and Purpose

+ +

+1.1.2 History

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_aa.htm new file mode 100644 index 00000000..049e0280 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_aa.htm @@ -0,0 +1,27 @@ + + + +CLHS: Section 1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.1.1 Scope and Purpose

The specification set forth in this document is designed to promote the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide.
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ab.htm new file mode 100644 index 00000000..a072c891 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ab.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.1.2 History

+Lisp is a family of languages with a long history. Early key ideas in Lisp were developed by John McCarthy during the 1956 Dartmouth Summer Research Project on Artificial Intelligence. McCarthy's motivation was to develop an algebraic list processing language for artificial intelligence work. Implementation efforts for early dialects of Lisp were undertaken on the IBM 704, the IBM 7090, the Digital Equipment Corporation (DEC) PDP-1, the DEC PDP-6, and the PDP-10. The primary dialect of Lisp between 1960 and 1965 was Lisp 1.5. By the early 1970's there were two predominant dialects of Lisp, both arising from these early efforts: MacLisp and Interlisp. For further information about very early Lisp dialects, see The Anatomy of Lisp or Lisp 1.5 Programmer's Manual.

+MacLisp improved on the Lisp 1.5 notion of special variables and error handling. MacLisp also introduced the concept of functions that could take a variable number of arguments, macros, arrays, non-local dynamic exits, fast arithmetic, the first good Lisp compiler, and an emphasis on execution speed. By the end of the 1970's, MacLisp was in use at over 50 sites. For further information about Maclisp, see Maclisp Reference Manual, Revision 0 or The Revised Maclisp Manual.

+Interlisp introduced many ideas into Lisp programming environments and methodology. One of the Interlisp ideas that influenced Common Lisp was an iteration construct implemented by Warren Teitelman that inspired the loop macro used both on the Lisp Machines and in MacLisp, and now in Common Lisp. For further information about Interlisp, see Interlisp Reference Manual.

+Although the first implementations of Lisp were on the IBM 704 and the IBM 7090, later work focussed on the DEC PDP-6 and, later, PDP-10 computers, the latter being the mainstay of Lisp and artificial intelligence work at such places as Massachusetts Institute of Technology (MIT), Stanford University, and Carnegie Mellon University (CMU) from the mid-1960's through much of the 1970's. The PDP-10 computer and its predecessor the PDP-6 computer were, by design, especially well-suited to Lisp because they had 36-bit words and 18-bit addresses. This architecture allowed a cons cell to be stored in one word; single instructions could extract the car and cdr parts. The PDP-6 and PDP-10 had fast, powerful stack instructions that enabled fast function calling. But the limitations of the PDP-10 were evident by 1973: it supported a small number of researchers using Lisp, and the small, 18-bit address space (2^18 = 262,144 words) limited the size of a single program. One response to the address space problem was the Lisp Machine, a special-purpose computer designed to run Lisp programs. The other response was to use general-purpose computers with address spaces larger than 18 bits, such as the DEC VAX and the S-1 Mark IIA. For further information about S-1 Common Lisp, see ``S-1 Common Lisp Implementation.''

+The Lisp machine concept was developed in the late 1960's. In the early 1970's, Peter Deutsch, working with Daniel Bobrow, implemented a Lisp on the Alto, a single-user minicomputer, using microcode to interpret a byte-code implementation language. Shortly thereafter, Richard Greenblatt began work on a different hardware and instruction set design at MIT. Although the Alto was not a total success as a Lisp machine, a dialect of Interlisp known as Interlisp-D became available on the D-series machines manufactured by Xerox---the Dorado, Dandelion, Dandetiger, and Dove (or Daybreak). An upward-compatible extension of MacLisp called Lisp Machine Lisp became available on the early MIT Lisp Machines. Commercial Lisp machines from Xerox, Lisp Machines (LMI), and Symbolics were on the market by 1981. For further information about Lisp Machine Lisp, see Lisp Machine Manual.

+During the late 1970's, Lisp Machine Lisp began to expand towards a much fuller language. Sophisticated lambda lists, setf, multiple values, and structures like those in Common Lisp are the results of early experimentation with programming styles by the Lisp Machine group. Jonl White and others migrated these features to MacLisp. Around 1980, Scott Fahlman and others at CMU began work on a Lisp to run on the Scientific Personal Integrated Computing Environment (SPICE) workstation. One of the goals of the project was to design a simpler dialect than Lisp Machine Lisp.

+The Macsyma group at MIT began a project during the late 1970's called the New Implementation of Lisp (NIL) for the VAX, which was headed by White. One of the stated goals of the NIL project was to fix many of the historic, but annoying, problems with Lisp while retaining significant compatibility with MacLisp. At about the same time, a research group at Stanford University and Lawrence Livermore National Laboratory headed by Richard P. Gabriel began the design of a Lisp to run on the S-1 Mark IIA supercomputer. S-1 Lisp, never completely functional, was the test bed for adapting advanced compiler techniques to Lisp implementation. Eventually the S-1 and NIL groups collaborated. For further information about the NIL project, see ``NIL---A Perspective.''

+The first effort towards Lisp standardization was made in 1969, when Anthony Hearn and Martin Griss at the University of Utah defined Standard Lisp---a subset of Lisp 1.5 and other dialects---to transport REDUCE, a symbolic algebra system. During the 1970's, the Utah group implemented first a retargetable optimizing compiler for Standard Lisp, and then an extended implementation known as Portable Standard Lisp (PSL). By the mid 1980's, PSL ran on about a dozen kinds of computers. For further information about Standard Lisp, see ``Standard LISP Report.''

+PSL and Franz Lisp---a MacLisp-like dialect for Unix machines---were the first examples of widely available Lisp dialects on multiple hardware platforms.

+One of the most important developments in Lisp occurred during the second half of the 1970's: Scheme. Scheme, designed by Gerald J. Sussman and Guy L. Steele Jr., is a simple dialect of Lisp whose design brought to Lisp some of the ideas from programming language semantics developed in the 1960's. Sussman was one of the prime innovators behind many other advances in Lisp technology from the late 1960's through the 1970's. The major contributions of Scheme were lexical scoping, lexical closures, first-class continuations, and simplified syntax (no separation of value cells and function cells). Some of these contributions made a large impact on the design of Common Lisp. For further information about Scheme, see IEEE Standard for the Scheme Programming Language or ``Revised^3 Report on the Algorithmic Language Scheme.''

+In the late 1970's object-oriented programming concepts started to make a strong impact on Lisp. At MIT, certain ideas from Smalltalk made their way into several widely used programming systems. Flavors, an object-oriented programming system with multiple inheritance, was developed at MIT for the Lisp machine community by Howard Cannon and others. At Xerox, the experience with Smalltalk and Knowledge Representation Language (KRL) led to the development of Lisp Object Oriented Programming System (LOOPS) and later Common LOOPS. For further information on Smalltalk, see Smalltalk-80: The Language and its Implementation. For further information on Flavors, see Flavors: A Non-Hierarchical Approach to Object-Oriented Programming.

+These systems influenced the design of the Common Lisp Object System (CLOS). CLOS was developed specifically for this standardization effort, and was separately written up in ``Common Lisp Object System Specification.'' However, minor details of its design have changed slightly since that publication, and that paper should not be taken as an authoritative reference to the semantics of the object system as described in this document.

+In 1980 Symbolics and LMI were developing Lisp Machine Lisp; stock-hardware implementation groups were developing NIL, Franz Lisp, and PSL; Xerox was developing Interlisp; and the SPICE project at CMU was developing a MacLisp-like dialect of Lisp called SpiceLisp.

+In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. Initially spearheaded by White and Gabriel, the driving force behind this grassroots effort was provided by Fahlman, Daniel Weinreb, David Moon, Steele, and Gabriel. Common Lisp was designed as a description of a family of languages. The primary influences on Common Lisp were Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, and Scheme. Common Lisp: The Language is a description of that design. Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp esearch and use.

+In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_b.htm new file mode 100644 index 00000000..c77f4e0d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_b.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.2 Organization of the Document

+This is a reference document, not a tutorial document. Where possible and convenient, the order of presentation has been chosen so that the more primitive topics precede those that build upon them; however, linear readability has not been a priority.

+This document is divided into chapters by topic. Any given chapter might contain conceptual material, dictionary entries, or both.

+Defined names within the dictionary portion of a chapter are grouped in a way that brings related topics into physical proximity. Many such groupings were possible, and no deep significance should be inferred from the particular grouping that was chosen. To see defined names grouped alphabetically, consult the index. For a complete list of defined names, see Section 1.9 (Symbols in the COMMON-LISP Package).

+In order to compensate for the sometimes-unordered portions of this document, a glossary has been provided; see Section 26 (Glossary). The glossary provides connectivity by providing easy access to definitions of terms, and in some cases by providing examples or cross references to additional conceptual material.

+For information about notational conventions used in this document, see Section 1.4 (Definitions).

+For information about conformance, see Section 1.5 (Conformance).

+For information about extensions and subsets, see Section 1.6 (Language Extensions) nd Section 1.7 (Language Subsets).

+For information about how programs in the language are parsed by the Lisp reader, see Section 2 (Syntax).

+For information about how programs in the language are compiled and executed, see Section 3 (Evaluation and Compilation).

+For information about data types, see Section 4 (Types and Classes). Not all types and classes are defined in this chapter; many are defined in chapter corresponding to their topic--for example, the numeric types are defined in Section 12 (Numbers). For a complete list of standardized types, see Figure 4-2.

+For information about general purpose control and data flow, see Section 5 (Data and Control Flow) or Section 6 (Iteration).

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_c.htm new file mode 100644 index 00000000..3e5e37ee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_c.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.3 Referenced Publications

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_d.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_d.htm new file mode 100644 index 00000000..5a8a514e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_d.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4 Definitions

+This section contains notational conventions and definitions of terms used in this manual.

+ + +

+1.4.1 Notational Conventions

+ + +

+1.4.2 Error Terminology

+ +

+1.4.3 Sections Not Formally Part Of This Standard

+ +

+1.4.4 Interpreting Dictionary Entries

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_da.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_da.htm new file mode 100644 index 00000000..3f322dcd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_da.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1 Notational Conventions

+The following notational conventions are used throughout this document.

+ + +

+1.4.1.1 Font Key

+ +

+1.4.1.2 Modified BNF Syntax

+ +

+1.4.1.3 Special Symbols

+ +

+1.4.1.4 Objects with Multiple Notations

+ +

+1.4.1.5 Designators

+ +

+1.4.1.6 Nonsense Words

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daa.htm new file mode 100644 index 00000000..7811766d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daa.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 1.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.1 Font Key

+Fonts are used in this document to convey information.

+

+

name

+Denotes a formal term whose meaning is defined in the Glossary. When this font is used, the Glossary definition takes precedence over normal English usage.

+Sometimes a glossary term appears subscripted, as in ``whitespace[2].'' Such a notation selects one particular Glossary definition out of several, in this case the second. The subscript notation for Glossary terms is generally used where the context might be insufficient to disambiguate among the available definitions.

+

name

+Denotes the introduction of a formal term locally to the current text. There is still a corresponding glossary entry, and is formally equivalent to a use of ``name,'' but the hope is that making such uses conspicuous will save the reader a trip to the glossary in some cases.

+

name

+Denotes a symbol in the COMMON-LISP package. For information about case conventions, see Section 1.4.1.4.1 (Case in Symbols).

+

name

+Denotes a sample name or piece of code that a programmer might write in Common Lisp.

+This font is also used for certain standardized names that are not names of external symbols of the COMMON-LISP package, such as keywords[1], package names, and loop keywords.

+

name

+Denotes the name of a parameter or value.

+In some situations the notation ``<<name>>'' (i.e., the same font, but with surrounding ``angle brackets'') is used instead in order to provide better visual separation from surrounding characters. These ``angle brackets'' are metasyntactic, and never actually appear in program input or output.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dab.htm new file mode 100644 index 00000000..97f2aacd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dab.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 1.4.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.2 Modified BNF Syntax

+This specification uses an extended Backus Normal Form (BNF) to describe the syntax of Common Lisp macro forms and special forms. This section discusses the syntax of BNF expressions.

+ + +

+1.4.1.2.1 Splicing in Modified BNF Syntax

+ +

+1.4.1.2.2 Indirection in Modified BNF Syntax

+ +

+1.4.1.2.3 Additional Uses for Indirect Definitions in Modified BNF Syntax

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daba.htm new file mode 100644 index 00000000..be6846eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daba.htm @@ -0,0 +1,86 @@ + + + +CLHS: Section 1.4.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.2.1 Splicing in Modified BNF Syntax

+The primary extension used is the following:

+

[[O]]

+An expression of this form appears whenever a list of elements is to be spliced into a larger structure and the elements can appear in any order. The symbol O represents a description of the syntax of some number of syntactic elements to be spliced; that description must be of the form

+

O1 | ... | Ol

+ where each Oi can be of the form S or of the form S* or of the form {S}1 . The expression [[O]] means that a list of the form

+

(Oi1...Oij) 1<=j

+is spliced into the enclosing expression, such that if n /=m and 1<=n,m<=j, then either Oin/=Oim or Oin = Oim = Qk, where for some 1<=k <=n, Ok is of the form Qk*. Furthermore, for each Oin that is of the form {Qk}1 , that element is required to appear somewhere in the list to be spliced.

+For example, the expression

+(x [[A | B* | C]] y)

+means that at most one A, any number of B's, and at most one C can occur in any order. It is a description of any of these:

+

+ (x y)
+ (x B A C y)
+ (x A B B B B B C y)
+ (x C B A B B B y)
+
+

+but not any of these:

+

+ (x B B A A C C y)
+ (x C B C y)
+
+

+In the first case, both A and C appear too often, and in the second case C appears too often.

+

+The notation [[O1 | O2 | ...]]+ adds the additional restriction that at least one item from among the possible choices must be used. For example:

+(x [[A | B* | C]]+ y)

+means that at most one A, any number of B's, and at most one C can occur in any order, but that in any case at least one of these options must be selected. It is a description of any of these:

+

+ (x B y)
+ (x B A C y)
+ (x A B B B B B C y)
+ (x C B A B B B y)
+
+

+but not any of these:

+

+ (x y)
+ (x B B A A C C y)
+ (x C B C y)
+
+

+In the first case, no item was used; in the second case, both A and C appear too often; and in the third case C appears too often.

+Also, the expression:

+(x [[{A}1 | {B}1 | C]] y)

+can generate exactly these and no others:

+

+ (x A B C y)
+ (x A C B y)
+ (x A B y)
+ (x B A C y)
+ (x B C A y)
+ (x B A y)
+ (x C A B y)
+ (x C B A y)
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabb.htm new file mode 100644 index 00000000..03eb260d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabb.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 1.4.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.2.2 Indirection in Modified BNF Syntax

+An indirection extension is introduced in order to make this new syntax more readable:

+

O

+If O is a non-terminal symbol, the right-hand side of its definition is substituted for the entire expression O. For example, the following BNF is equivalent to the BNF in the previous example:

+(x [[O]] y) 

+O::= A | B* | C 
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabc.htm new file mode 100644 index 00000000..f0483fb8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dabc.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 1.4.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.2.3 Additional Uses for Indirect Definitions in Modified BNF Syntax

+In some cases, an auxiliary definition in the BNF might appear to be unused within the BNF, but might still be useful elsewhere. For example, consider the following definitions:

+ +case keyform {normal-clause}* [otherwise-clause] => result*

+ +ccase keyplace {normal-clause}* => result*

+ +ecase keyform {normal-clause}* => result*

+

+

+normal-clause::= (keys form*) 
+
+ 
+otherwise-clause::= ({otherwise | t} form*) 
+
+ 
+clause::= normal-clause | otherwise-clause 
+
+

+Here the term ``clause'' might appear to be ``dead'' in that it is not used in the BNF. However, the purpose of the BNF is not just to guide parsing, but also to define useful terms for reference in the descriptive text which follows. As such, the term ``clause'' might appear in text that follows, as shorthand for ``normal-clause or otherwise-clause.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dac.htm new file mode 100644 index 00000000..31e34b75 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dac.htm @@ -0,0 +1,103 @@ + + + +CLHS: Section 1.4.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.3 Special Symbols

+The special symbols described here are used as a notational convenience within this document, and are part of neither the Common Lisp language nor its environment.

+

=>

+This indicates evaluation. For example:

+

+ (+ 4 5) =>  9 
+
+ This means that the result of evaluating the form (+ 4 5) is 9.

+If a form returns multiple values, those values might be shown separated by spaces, line breaks, or commas. For example:

+

+ (truncate 7 5)
+=>  1 2
+ (truncate 7 5) 
+=>  1
+   2
+ (truncate 7 5)
+=>  1, 2
+
+

+Each of the above three examples is equivalent, and specifies that (truncate 7 5) returns two values, which are 1 and 2.

+Some conforming implementations actually type an arrow (or some other indicator) before showing return values, while others do not.

+

OR=>

+The notation ``OR=> '' is used to denote one of several possible alternate results. The example

+

+ (char-name #\a)
+=>  NIL
+OR=>  "LOWERCASE-a"
+OR=>  "Small-A"
+OR=>  "LA01"
+
+

+indicates that nil, "LOWERCASE-a", "Small-A", "LA01" are among the possible results of (char-name #\a)---each with equal preference. Unless explicitly specified otherwise, it should not be assumed that the set of possible results shown is exhaustive. Formally, the above example is equivalent to

+

+ (char-name #\a) =>  implementation-dependent
+
+

+but it is intended to provide additional information to illustrate some of the ways in which it is permitted for implementations to diverge.

+

NOT=>

+The notation ``NOT=> '' is used to denote a result which is not possible. This might be used, for example, in order to emphasize a situation where some anticipated misconception might lead the reader to falsely believe that the result might be possible. For example,

+

+ (function-lambda-expression 
+    (funcall #'(lambda (x) #'(lambda () x)) nil))
+=>  NIL, true, NIL
+OR=>  (LAMBDA () X), true, NIL
+NOT=>  NIL, false, NIL
+NOT=>  (LAMBDA () X), false, NIL
+
+

+

==

+This indicates code equivalence. For example:

+

+ (gcd x (gcd y z)) ==  (gcd (gcd x y) z)
+
+ This means that the results and observable side-effects of evaluating the form (gcd x (gcd y z)) are always the same as the results and observable side-effects of (gcd (gcd x y) z) for any x, y, and z.

+

>>

+Common Lisp specifies input and output with respect to a non-interactive stream model. The specific details of how interactive input and output are mapped onto that non-interactive model are implementation-defined.

+For example, conforming implementations are permitted to differ in issues of how interactive input is terminated. For example, the function read terminates when the final delimiter is typed on a non-interactive stream. In some implementations, an interactive call to read returns as soon as the final delimiter is typed, even if that delimiter is not a newline. In other implementations, a final newline is always required. In still other implementations, there might be a command which ``activates'' a buffer full of input without the command itself being visible on the program's input stream.

+In the examples in this document, the notation ``>> '' precedes lines where interactive input and output occurs. Within such a scenario, ``this notation'' notates user input.

+For example, the notation

+

+ (+ 1 (print (+ (sqrt (read)) (sqrt (read)))))
+>>  9 16 
+>>  7
+=>  8
+
+

+shows an interaction in which ``(+ 1 (print (+ (sqrt (read)) (sqrt (read)))))'' is a form to be evaluated, ``9 16 '' is interactive input, ``7'' is interactive output, and ``8'' is the value yielded from the evaluation.

+The use of this notation is intended to disguise small differences in interactive input and output behavior between implementations.

+Sometimes, the non-interactive stream model calls for a newline. How that newline character is interactively entered is an implementation-defined detail of the user interface, but in that case, either the notation ``<Newline>'' or ``<NEWLINE>'' might be used.

+

+ (progn (format t "~&Who? ") (read-line))
+>>  Who? Fred, Mary, and Sally<NEWLINE>
+=>  "Fred, Mary, and Sally", false
+
+

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dad.htm new file mode 100644 index 00000000..277d7a02 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dad.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 1.4.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.4 Objects with Multiple Notations

+Some objects in Common Lisp can be notated in more than one way. In such situations, the choice of which notation to use is technically arbitrary, but conventions may exist which convey a ``point of view'' or ``sense of intent.''

+ + +

+1.4.1.4.1 Case in Symbols

+ +

+1.4.1.4.2 Numbers

+ +

+1.4.1.4.3 Use of the Dot Character

+ +

+1.4.1.4.4 NIL

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dada.htm new file mode 100644 index 00000000..9ac6c530 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dada.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 1.4.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.4.1 Case in Symbols

+While case is significant in the process of interning a symbol, the Lisp reader, by default, attempts to canonicalize the case of a symbol prior to interning; see Section 23.1.2 (Effect of Readtable Case on the Lisp Reader). As such, case in symbols is not, by default, significant. Throughout this document, except as explicitly noted otherwise, the case in which a symbol appears is not significant; that is, HELLO, Hello, hElLo, and hello are all equivalent ways to denote a symbol whose name is "HELLO".

+The characters backslash and vertical-bar are used to explicitly quote the case and other parsing-related aspects of characters. As such, the notations |hello| and \h\e\l\l\o are equivalent ways to refer to a symbol whose name is "hello", and which is distinct from any symbol whose name is "HELLO".

+The symbols that correspond to Common Lisp defined names have uppercase names even though their names generally appear in lowercase in this document.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadb.htm new file mode 100644 index 00000000..8c2fda86 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.4.2 Numbers

+Although Common Lisp provides a variety of ways for programs to manipulate the input and output radix for rational numbers, all numbers in this document are in decimal notation unless explicitly noted otherwise.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadc.htm new file mode 100644 index 00000000..31aa9710 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadc.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 1.4.1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.4.3 Use of the Dot Character

+The dot appearing by itself in an expression such as

+(item1 item2 . tail)

+means that tail represents a list of objects at the end of a list. For example,

+(A B C . (D E F))

+is notationally equivalent to:

+(A B C D E F)

+Although dot is a valid constituent character in a symbol, no standardized symbols contain the character dot, so a period that follows a reference to a symbol at the end of a sentence in this document should always be interpreted as a period and never as part of the symbol's name. For example, within this document, a sentence such as ``This sample sentence refers to the symbol car.'' refers to a symbol whose name is "CAR" (with three letters), and never to a four-letter symbol "CAR."

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadd.htm new file mode 100644 index 00000000..d7df03eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dadd.htm @@ -0,0 +1,55 @@ + + + +CLHS: Section 1.4.1.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.4.4 NIL

+nil has a variety of meanings. It is a symbol in the COMMON-LISP package with the name "NIL", it is boolean (and generalized boolean) false, it is the empty list, and it is the name of the empty type (a subtype of all types).

+Within Common Lisp, nil can be notated interchangeably as either NIL or (). By convention, the choice of notation offers a hint as to which of its many roles it is playing.

+

+For Evaluation?  Notation  Typically Implied Role       
+----------

+                                              
+Yes              nil       use as a boolean.            
+Yes              'nil      use as a symbol.             
+Yes              '()       use as an empty list         
+No               nil       use as a symbol or boolean.  
+No               ()        use as an empty list.        
+
+

Figure 1-1. Notations for NIL

+Within this document only, nil is also sometimes notated as false to emphasize its role as a boolean.

+For example:

+

+ (print ())                          ;avoided
+ (defun three nil 3)                 ;avoided 
+ '(nil nil)                          ;list of two symbols
+ '(() ())                            ;list of empty lists
+ (defun three () 3)                  ;Emphasize empty parameter list.
+ (append '() '()) =>  ()              ;Emphasize use of empty lists
+ (not nil) =>  true                   ;Emphasize use as Boolean false
+ (get 'nil 'color)                   ;Emphasize use as a symbol
+
+

+A function is sometimes said to ``be false'' or ``be true'' in some circumstance. Since no function object can be the same as nil and all function objects represent true when viewed as booleans, it would be meaningless to say that the function was literally false and uninteresting to say that it was literally true. Instead, these phrases are just traditional alternative ways of saying that the function ``returns false'' or ``returns true,'' respectively.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dae.htm new file mode 100644 index 00000000..000762fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dae.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 1.4.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.5 Designators

+A designator is an object that denotes another object.

+Where a parameter of an operator is described as a designator, the description of the operator is written in a way that assumes that the value of the parameter is the denoted object; that is, that the parameter is already of the denoted type. (The specific nature of the object denoted by a ``<<type>> designator'' or a ``designator for a <<type>>'' can be found in the Glossary entry for ``<<type>> designator.'')

+For example, ``nil'' and ``the value of *standard-output*'' are operationally indistinguishable as stream designators. Similarly, the symbol foo and the string "FOO" are operationally indistinguishable as string designators.

+Except as otherwise noted, in a situation where the denoted object might be used multiple times, it is implementation-dependent whether the object is coerced only once or whether the coercion occurs each time the object must be used.

+For example, mapcar receives a function designator as an argument, and its description is written as if this were simply a function. In fact, it is implementation-dependent whether the function designator is coerced right away or whether it is carried around internally in the form that it was given as an argument and re-coerced each time it is needed. In most cases, conforming programs cannot detect the distinction, but there are some pathological situations (particularly those involving self-redefining or mutually-redefining functions) which do conform and which can detect this difference. The following program is a conforming program, but might or might not have portably correct results, depending on whether its correctness depends on one or the other of the results:

+

+ (defun add-some (x) 
+   (defun add-some (x) (+ x 2))
+   (+ x 1)) =>  ADD-SOME
+ (mapcar 'add-some '(1 2 3 4))
+=>  (2 3 4 5)
+OR=>  (2 4 5 6)
+
+

+In a few rare situations, there may be a need in a dictionary entry to refer to the object that was the original designator for a parameter. Since naming the parameter would refer to the denoted object, the phrase ``the <<parameter-name>> designator'' can be used to refer to the designator which was the argument from which the value of <<parameter-name>> was computed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daf.htm new file mode 100644 index 00000000..845381ed --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_daf.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 1.4.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.1.6 Nonsense Words

+When a word having no pre-attached semantics is required (e.g., in an example), it is common in the Lisp community to use one of the words ``foo,'' ``bar,'' ``baz,'' and ``quux.'' For example, in

+

+ (defun foo (x) (+ x 1))
+
+ the use of the name foo is just a shorthand way of saying ``please substitute your favorite name here.''

+These nonsense words have gained such prevalance of usage, that it is commonplace for newcomers to the community to begin to wonder if there is an attached semantics which they are overlooking---there is not.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_db.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_db.htm new file mode 100644 index 00000000..05e9f325 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_db.htm @@ -0,0 +1,77 @@ + + + +CLHS: Section 1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.2 Error Terminology

+Situations in which errors might, should, or must be signaled are described in the standard. The wording used to describe such situations is intended to have precise meaning. The following list is a glossary of those meanings.

+

Safe code

+This is code processed with the safety optimization at its highest setting (3). safety is a lexical property of code. The phrase ``the function F should signal an error'' means that if F is invoked from code processed with the highest safety optimization, an error is signaled. It is implementation-dependent whether F or the calling code signals the error.

+

Unsafe code

+This is code processed with lower safety levels.

+Unsafe code might do error checking. Implementations are permitted to treat all code as safe code all the time.

+

An error is signaled

+This means that an error is signaled in both safe and unsafe code. Conforming code may rely on the fact that the error is signaled in both safe and unsafe code. Every implementation is required to detect the error in both safe and unsafe code. For example, ``an error is signaled if unexport is given a symbol not accessible in the current package.''

+If an explicit error type is not specified, the default is error.

+

An error should be signaled

+This means that an error is signaled in safe code, and an error might be signaled in unsafe code. Conforming code may rely on the fact that the error is signaled in safe code. Every implementation is required to detect the error at least in safe code. When the error is not signaled, the ``consequences are undefined'' (see below). For example, ``+ should signal an error of type type-error if any argument is not of type number.''

+

Should be prepared to signal an error

+This is similar to ``should be signaled'' except that it does not imply that `extra effort' has to be taken on the part of an operator to discover an erroneous situation if the normal action of that operator can be performed successfully with only `lazy' checking. An implementation is always permitted to signal an error, but even in safe code, it is only required to signal the error when failing to signal it might lead to incorrect results. In unsafe code, the consequences are undefined.

+For example, defining that ``find should be prepared to signal an error of type type-error if its second argument is not a proper list'' does not imply that an error is always signaled. The form

+

+ (find 'a '(a b . c))
+
+

+must either signal an error of type type-error in safe code, else return A. In unsafe code, the consequences are undefined. By contrast,

+

+ (find 'd '(a b . c))
+
+

+must signal an error of type type-error in safe code. In unsafe code, the consequences are undefined. Also,

+

+ (find 'd '#1=(a b . #1#))
+
+

+in safe code might return nil (as an implementation-defined extension), might never return, or might signal an error of type type-error. In unsafe code, the consequences are undefined.

+Typically, the ``should be prepared to signal'' terminology is used in type checking situations where there are efficiency considerations that make it impractical to detect errors that are not relevant to the correct operation of the operator.

+

The consequences are unspecified

+This means that the consequences are unpredictable but harmless. Implementations are permitted to specify the consequences of this situation. No conforming code may depend on the results or effects of this situation, and all conforming code is required to treat the results and effects of this situation as unpredictable but harmless. For example, ``if the second argument to shared-initialize specifies a name that does not correspond to any slots accessible in the object, the results are unspecified.''

+

The consequences are undefined

+This means that the consequences are unpredictable. The consequences may range from harmless to fatal. No conforming code may depend on the results or effects. Conforming code must treat the consequences as unpredictable. In places where the words ``must,'' ``must not,'' or ``may not'' are used, then ``the consequences are undefined'' if the stated requirement is not met and no specific consequence is explicitly stated. An implementation is permitted to signal an error in this case.

+For example: ``Once a name has been declared by defconstant to be constant, any further assignment or binding of that variable has undefined consequences.''

+

An error might be signaled

+This means that the situation has undefined consequences; however, if an error is signaled, it is of the specified type. For example, ``open might signal an error of type file-error.''

+

The return values are unspecified

+This means that only the number and nature of the return values of a form are not specified. However, the issue of whether or not any side-effects or transfer of control occurs is still well-specified.

+A program can be well-specified even if it uses a function whose returns values are unspecified. For example, even if the return values of some function F are unspecified, an expression such as (length (list (F))) is still well-specified because it does not rely on any particular aspect of the value or values returned by F.

+

Implementations may be extended to cover this situation

+This means that the situation has undefined consequences; however, a conforming implementation is free to treat the situation in a more specific way. For example, an implementation might define that an error is signaled, or that an error should be signaled, or even that a certain well-defined non-error behavior occurs.

+No conforming code may depend on the consequences of such a situation; all conforming code must treat the consequences of the situation as undefined. Implementations are required to document how the situation is treated.

+For example, ``implementations may be extended to define other type specifiers to have a corresponding class.''

+

Implementations are free to extend the syntax

+This means that in this situation implementations are permitted to define unambiguous extensions to the syntax of the form being described. No conforming code may depend on this extension. Implementations are required to document each such extension. All conforming code is required to treat the syntax as meaningless. The standard might disallow certain extensions while allowing others. For example, ``no implementation is free to extend the syntax of defclass.''

+

A warning might be issued

+This means that implementations are encouraged to issue a warning if the context is appropriate (e.g., when compiling). However, a conforming implementation is not required to issue a warning.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dc.htm new file mode 100644 index 00000000..0df97e86 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dc.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.3 Sections Not Formally Part Of This Standard

+Front matter and back matter, such as the ``Table of Contents,'' ``Index,'' ``Figures,'' ``Credits,'' and ``Appendix'' are not considered formally part of this standard, so that we retain the flexibility needed to update these sections even at the last minute without fear of needing a formal vote to change those parts of the document. These items are quite short and very useful, however, and it is not recommended that they be removed even in an abridged version of this document.

+Within the concept sections, subsections whose names begin with the words ``Note'' or ``Notes'' or ``Example'' or ``Examples'' are provided for illustration purposes only, and are not considered part of the standard.

+An attempt has been made to place these sections last in their parent section, so that they could be removed without disturbing the contiguous numbering of the surrounding sections in order to produce a document of smaller size.

+Likewise, the ``Examples'' and ``Notes'' sections in a dictionary entry are not considered part of the standard and could be removed if necessary.

+Nevertheless, the examples provide important clarifications and consistency checks for the rest of the material, and such abridging is not recommended unless absolutely unavoidable.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dd.htm new file mode 100644 index 00000000..c357c1df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dd.htm @@ -0,0 +1,97 @@ + + + +CLHS: Section 1.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4 Interpreting Dictionary Entries

+The dictionary entry for each defined name is partitioned into sections. Except as explicitly indicated otherwise below, each section is introduced by a label identifying that section. The omission of a section implies that the section is either not applicable, or would provide no interesting information.

+This section defines the significance of each potential section in a dictionary entry.

+ + +

+1.4.4.1 The ``Affected By'' Section of a Dictionary Entry

+ +

+1.4.4.2 The ``Arguments'' Section of a Dictionary Entry

+ +

+1.4.4.3 The ``Arguments and Values'' Section of a Dictionary Entry

+ +

+1.4.4.4 The ``Binding Types Affected'' Section of a Dictionary Entry

+ +

+1.4.4.5 The ``Class Precedence List'' Section of a Dictionary Entry

+ +

+1.4.4.6 Dictionary Entries for Type Specifiers

+ +

+1.4.4.7 The ``Constant Value'' Section of a Dictionary Entry

+ +

+1.4.4.8 The ``Description'' Section of a Dictionary Entry

+ +

+1.4.4.9 The ``Examples'' Section of a Dictionary Entry

+ +

+1.4.4.10 The ``Exceptional Situations'' Section of a Dictionary Entry

+ +

+1.4.4.11 The ``Initial Value'' Section of a Dictionary Entry

+ +

+1.4.4.12 The ``Argument Precedence Order'' Section of a Dictionary Entry

+ + +

+1.4.4.13 The ``Method Signature'' Section of a Dictionary Entry

+ +

+1.4.4.14 The ``Name'' Section of a Dictionary Entry

+ +

+1.4.4.15 The ``Notes'' Section of a Dictionary Entry

+ +

+1.4.4.16 The ``Pronunciation'' Section of a Dictionary Entry

+ +

+1.4.4.17 The ``See Also'' Section of a Dictionary Entry

+ +

+1.4.4.18 The ``Side Effects'' Section of a Dictionary Entry

+ +

+1.4.4.19 The ``Supertypes'' Section of a Dictionary Entry

+ +

+1.4.4.20 The ``Syntax'' Section of a Dictionary Entry

+ +

+1.4.4.21 The ``Valid Context'' Section of a Dictionary Entry

+ +

+1.4.4.22 The ``Value Type'' Section of a Dictionary Entry

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dda.htm new file mode 100644 index 00000000..c756ab50 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dda.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.4.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.1 The ``Affected By'' Section of a Dictionary Entry

+For an operator, anything that can affect the side effects of or values returned by the operator.

+For a variable, anything that can affect the value of the variable including functions that bind or assign it.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddb.htm new file mode 100644 index 00000000..fc46b66c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.2 The ``Arguments'' Section of a Dictionary Entry

+This information describes the syntax information of entries such as those for declarations and special expressions which are never evaluated as forms, and so do not return values.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddc.htm new file mode 100644 index 00000000..67b68745 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.4.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.3 The ``Arguments and Values'' Section of a Dictionary Entry

+An English language description of what arguments the operator accepts and what values it returns, including information about defaults for parameters corresponding to omittable arguments (such as optional parameters and keyword parameters). For special operators and macros, their arguments are not evaluated unless it is explicitly stated in their descriptions that they are evaluated.

+Except as explicitly specified otherwise, the consequences are undefined if these type restrictions are violated.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddd.htm new file mode 100644 index 00000000..6e7e08b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.4 The ``Binding Types Affected'' Section of a Dictionary Entry

+This information alerts the reader to the kinds of bindings that might potentially be affected by a declaration. Whether in fact any particular such binding is actually affected is dependent on additional factors as well. See the ``Description'' section of the declaration in question for details.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dde.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dde.htm new file mode 100644 index 00000000..ae62b9b3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dde.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 1.4.4.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.5 The ``Class Precedence List'' Section of a Dictionary Entry

+This appears in the dictionary entry for a class, and contains an ordered list of the classes defined by Common Lisp that must be in the class precedence list of this class.

+It is permissible for other (implementation-defined) classes to appear in the implementation's class precedence list for the class.

+It is permissible for either standard-object or structure-object to appear in the implementation's class precedence list; for details, see Section 4.2.2 (Type Relationships).

+Except as explicitly indicated otherwise somewhere in this specification, no additional standardized classes may appear in the implementation's class precedence list.

+By definition of the relationship between classes and types, the classes listed in this section are also supertypes of the type denoted by the class.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddf.htm new file mode 100644 index 00000000..e5d597e8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddf.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 1.4.4.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.6 Dictionary Entries for Type Specifiers

+The atomic type specifiers are those defined names listed in Figure 4-2. Such dictionary entries are of kind ``Class,'' ``Condition Type,'' ``System Class,'' or ``Type.'' A description of how to interpret a symbol naming one of these types or classes as an atomic type specifier is found in the ``Description'' section of such dictionary entries.

+The compound type specifiers are those defined names listed in Figure 4-3. Such dictionary entries are of kind ``Class,'' ``System Class,'' ``Type,'' or ``Type Specifier.'' A description of how to interpret as a compound type specifier a list whose car is such a symbol is found in the ``Compound Type Specifier Kind,'' ``Compound Type Specifier Syntax,'' ``Compound Type Specifier Arguments,'' and ``Compound Type Specifier Description'' sections of such dictionary entries.

+ + +

+1.4.4.6.1 The ``Compound Type Specifier Kind'' Section of a Dictionary Entry

+ +

+1.4.4.6.2 The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry

+ +

+1.4.4.6.3 The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry

+ +

+1.4.4.6.4 The ``Compound Type Specifier Description'' Section of a Dictionary Entry

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfa.htm new file mode 100644 index 00000000..db630b46 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 1.4.4.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.6.1 The ``Compound Type Specifier Kind'' Section of a Dictionary Entry

+An ``abbreviating'' type specifier is one that describes a subtype for which it is in principle possible to enumerate the elements, but for which in practice it is impractical to do so.

+A ``specializing'' type specifier is one that describes a subtype by restricting the type of one or more components of the type, such as element type or complex part type.

+A ``predicating'' type specifier is one that describes a subtype containing only those objects that satisfy a given predicate.

+A ``combining'' type specifier is one that describes a subtype in a compositional way, using combining operations (such as ``and,'' ``or,'' and ``not'') on other types.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfb.htm new file mode 100644 index 00000000..7cc6a91a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.4.4.6.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.6.2 The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry

+This information about a type describes the syntax of a compound type specifier for that type.

+Whether or not the type is acceptable as an atomic type specifier is not represented here; see Section 1.4.4.6 (Dictionary Entries for Type Specifiers).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfc.htm new file mode 100644 index 00000000..74c68b3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.6.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.6.3 The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry

+This information describes type information for the structures defined in the ``Compound Type Specifier Syntax'' section.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfd.htm new file mode 100644 index 00000000..d5b11cc9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddfd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.6.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.6.4 The ``Compound Type Specifier Description'' Section of a Dictionary Entry

+This information describes the meaning of the structures defined in the ``Compound Type Specifier Syntax'' section.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddg.htm new file mode 100644 index 00000000..fee9dda4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddg.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.7 The ``Constant Value'' Section of a Dictionary Entry

+This information describes the unchanging type and value of a constant variable.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddh.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddh.htm new file mode 100644 index 00000000..ec25dfda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddh.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.8 The ``Description'' Section of a Dictionary Entry

+A summary of the operator and all intended aspects of the operator, but does not necessarily include all the fields referenced below it (``Side Effects,'' ``Exceptional Situations,'' etc.)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddi.htm new file mode 100644 index 00000000..472053e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddi.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.9 The ``Examples'' Section of a Dictionary Entry

+Examples of use of the operator. These examples are not considered part of the standard; see Section 1.4.3 (Sections Not Formally Part Of This Standard).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddj.htm new file mode 100644 index 00000000..ea04ab36 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddj.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.10 The ``Exceptional Situations'' Section of a Dictionary Entry

+ Three kinds of information may appear here:

  • Situations that are detected by the function and formally signaled.
  • Situations that are handled by the function.
  • Situations that may be detected by the function.

This field does not include conditions that could be signaled by functions passed to and called by this operator as arguments or through dynamic variables, nor by executing subforms of this operator if it is a macro or special operator.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddk.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddk.htm new file mode 100644 index 00000000..a2982c3a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddk.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.11 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.11 The ``Initial Value'' Section of a Dictionary Entry

+This information describes the initial value of a dynamic variable. Since this variable might change, see type restrictions in the ``Value Type'' section.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddl.htm new file mode 100644 index 00000000..816c0e53 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddl.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.12 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.12 The ``Argument Precedence Order'' Section of a Dictionary Entry

+This information describes the argument precedence order. If it is omitted, the argument precedence order is the default (left to right).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddm.htm new file mode 100644 index 00000000..4f944c59 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddm.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 1.4.4.13 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.13 The ``Method Signature'' Section of a Dictionary Entry

+The description of a generic function includes descriptions of the methods that are defined on that generic function by the standard. A method signature is used to describe the parameters and parameter specializers for each method. Methods defined for the generic function must be of the form described by the method signature.

+ +F (x class) (y t) &optional z &key k

+

+This signature indicates that this method on the generic function F has two required parameters: x, which must be a generalized instance of the class class; and y, which can be any object (i.e., a generalized instance of the class t). In addition, there is an optional parameter z and a keyword parameter k. This signature also indicates that this method on F is a primary method and has no qualifiers.

+For each parameter, the argument supplied must be in the intersection of the type specified in the description of the corresponding generic function and the type given in the signature of some method (including not only those methods defined in this specification, but also implementation-defined or user-defined methods in situations where the definition of such methods is permitted).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddn.htm new file mode 100644 index 00000000..727f77dc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddn.htm @@ -0,0 +1,67 @@ + + + +CLHS: Section 1.4.4.14 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.14 The ``Name'' Section of a Dictionary Entry

+This section introduces the dictionary entry. It is not explicitly labeled. It appears preceded and followed by a horizontal bar.

+In large print at left, the defined name appears; if more than one defined name is to be described by the entry, all such names are shown separated by commas.

+In somewhat smaller italic print at right is an indication of what kind of dictionary entry this is. Possible values are:

+

+

Accessor

+This is an accessor function.

+

Class

+This is a class.

+

Condition Type

+This is a subtype of type condition.

+

Constant Variable

+This is a constant variable.

+

Declaration

+This is a declaration identifier.

+

Function

+This is a function.

+

Local Function

+This is a function that is defined only lexically within the scope of some other macro form.

+

Local Macro

+This is a macro that is defined only lexically within the scope of some other macro form.

+

Macro

+This is a macro.

+

Restart

+This is a restart.

+

Special Operator

+This is a special operator.

+

Standard Generic Function

+This is a standard generic function.

+

Symbol

+This is a symbol that is specially recognized in some particular situation, such as the syntax of a macro.

+

System Class

+This is like class, but it identifies a class that is potentially a built-in class. (No class is actually required to be a built-in class.)

+

Type

+This is an atomic type specifier, and depending on information for each particular entry, may subject to form other type specifiers.

+

Type Specifier

+This is a defined name that is not an atomic type specifier, but that can be used in constructing valid type specifiers.

+

Variable

+This is a dynamic variable.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddo.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddo.htm new file mode 100644 index 00000000..e65beafd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddo.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.15 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.15 The ``Notes'' Section of a Dictionary Entry

+Information not found elsewhere in this description which pertains to this operator. Among other things, this might include cross reference information, code equivalences, stylistic hints, implementation hints, typical uses. This information is not considered part of the standard; any conforming implementation or conforming program is permitted to ignore the presence of this information.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddp.htm new file mode 100644 index 00000000..fdea39d8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddp.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.16 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.16 The ``Pronunciation'' Section of a Dictionary Entry

+This offers a suggested pronunciation for defined names so that people not in verbal communication with the original designers can figure out how to pronounce words that are not in normal English usage. This information is advisory only, and is not considered part of the standard. For brevity, it is only provided for entries with names that are specific to Common Lisp and would not be found in Webster's Third New International Dictionary the English Language, Unabridged.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddq.htm new file mode 100644 index 00000000..0fb2d448 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddq.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.17 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.17 The ``See Also'' Section of a Dictionary Entry

+List of references to other parts of this standard that offer information relevant to this operator. This list is not part of the standard.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddr.htm new file mode 100644 index 00000000..e2ae4ddd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddr.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.4.4.18 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.18 The ``Side Effects'' Section of a Dictionary Entry

+Anything that is changed as a result of the evaluation of the form containing this operator.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dds.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dds.htm new file mode 100644 index 00000000..a980760a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_dds.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.4.4.19 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.19 The ``Supertypes'' Section of a Dictionary Entry

+This appears in the dictionary entry for a type, and contains a list of the standardized types that must be supertypes of this type.

+In implementations where there is a corresponding class, the order of the classes in the class precedence list is consistent with the order presented in this section.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddt.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddt.htm new file mode 100644 index 00000000..3c23900f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddt.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 1.4.4.20 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20 The ``Syntax'' Section of a Dictionary Entry

+This section describes how to use the defined name in code. The ``Syntax'' description for a generic function describes the lambda list of the generic function itself, while the ``Method Signatures'' describe the lambda lists of the defined methods. The ``Syntax'' description for an ordinary function, a macro, or a special operator describes its parameters.

+For example, an operator description might say:

+ +F x y &optional z &key k

+

+This description indicates that the function F has two required parameters, x and y. In addition, there is an optional parameter z and a keyword parameter k.

+For macros and special operators, syntax is given in modified BNF notation; see Section 1.4.1.2 (Modified BNF Syntax). For functions a lambda list is given. In both cases, however, the outermost parentheses are omitted, and default value information is omitted.

+ + +

+1.4.4.20.1 Special ``Syntax'' Notations for Overloaded Operators

+ +

+1.4.4.20.2 Naming Conventions for Rest Parameters

+ +

+1.4.4.20.3 Requiring Non-Null Rest Parameters in the ``Syntax'' Section

+ +

+1.4.4.20.4 Return values in the ``Syntax'' Section

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddta.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddta.htm new file mode 100644 index 00000000..85ee5d95 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddta.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 1.4.4.20.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20.1 Special ``Syntax'' Notations for Overloaded Operators

+If two descriptions exist for the same operation but with different numbers of arguments, then the extra arguments are to be treated as optional. For example, this pair of lines:

+ +file-position stream => position

+ +file-position stream position-spec => success-p

+

+is operationally equivalent to this line:

+ +file-position stream &optional position-spec => result

+

+and differs only in that it provides on opportunity to introduce different names for parameter and values for each case. The separated (multi-line) notation is used when an operator is overloaded in such a way that the parameters are used in different ways depending on how many arguments are supplied (e.g., for the function /) or the return values are different in the two cases (e.g., for the function file-position).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtb.htm new file mode 100644 index 00000000..f5c79209 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtb.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 1.4.4.20.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20.2 Naming Conventions for Rest Parameters

+Within this specification, if the name of a rest parameter is chosen to be a plural noun, use of that name in parameter font refers to the list to which the rest parameter is bound. Use of the singular form of that name in parameter font refers to an element of that list.

+For example, given a syntax description such as:

+ +F &rest arguments

+

+it is appropriate to refer either to the rest parameter named arguments by name, or to one of its elements by speaking of ``an argument,'' ``some argument,'' ``each argument'' etc.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtc.htm new file mode 100644 index 00000000..c80cdc75 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtc.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 1.4.4.20.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20.3 Requiring Non-Null Rest Parameters in the ``Syntax'' Section

+In some cases it is useful to refer to all arguments equally as a single aggregation using a rest parameter while at the same time requiring at least one argument. A variety of imperative and declarative means are available in code for expressing such a restriction, however they generally do not manifest themselves in a lambda list. For descriptive purposes within this specification,

+ +F &rest arguments+

+

+means the same as

+ +F &rest arguments

+

+but introduces the additional requirement that there be at least one argument.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtd.htm new file mode 100644 index 00000000..4129a7f8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtd.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 1.4.4.20.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20.4 Return values in the ``Syntax'' Section

+An evaluation arrow ``=> '' precedes a list of values to be returned. For example:

+ +F a b c => x

+

+indicates that F is an operator that has three required parameters (i.e., a, b, and c) and that returns one value (i.e., x). If more than one value is returned by an operator, the names of the values are separated by commas, as in:

+ +F a b c => x, y, z

+

+ + +

+1.4.4.20.4.1 No Arguments or Values in the ``Syntax'' Section

+ +

+1.4.4.20.4.2 Unconditional Transfer of Control in the ``Syntax'' Section

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtda.htm new file mode 100644 index 00000000..8553e78e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtda.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 1.4.4.20.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20.4.1 No Arguments or Values in the ``Syntax'' Section

+If no arguments are permitted, or no values are returned, a special notation is used to make this more visually apparent. For example,

+ +F <no arguments> => <no values>

+

+indicates that F is an operator that accepts no arguments and returns no values.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtdb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtdb.htm new file mode 100644 index 00000000..1f2c3db3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddtdb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 1.4.4.20.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.20.4.2 Unconditional Transfer of Control in the ``Syntax'' Section

+Some operators perform an unconditional transfer of control, and so never have any return values. Such operators are notated using a notation such as the following:

+ +F a b c =>|

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddu.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddu.htm new file mode 100644 index 00000000..19e28a6a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddu.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.4.4.21 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.21 The ``Valid Context'' Section of a Dictionary Entry

+This information is used by dictionary entries such as ``Declarations'' in order to restrict the context in which the declaration may appear.

+A given ``Declaration'' might appear in a declaration (i.e., a declare expression), a proclamation (i.e., a declaim or proclaim form), or both.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddv.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddv.htm new file mode 100644 index 00000000..a1df2661 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ddv.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.4.4.22 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.4.4.22 The ``Value Type'' Section of a Dictionary Entry

+This information describes any type restrictions on a dynamic variable.

+Except as explicitly specified otherwise, the consequences are undefined if this type restriction is violated.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_e.htm new file mode 100644 index 00000000..10b2a787 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_e.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5 Conformance

+This standard presents the syntax and semantics to be implemented by a conforming implementation (and its accompanying documentation). In addition, it imposes requirements on conforming programs.

+ + +

+1.5.1 Conforming Implementations

+ +

+1.5.2 Conforming Programs

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ea.htm new file mode 100644 index 00000000..ff717c1b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ea.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 1.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1 Conforming Implementations

+A conforming implementation shall adhere to the requirements outlined in this section.

+ + +

+1.5.1.1 Required Language Features

+ +

+1.5.1.2 Documentation of Implementation-Dependent Features

+ +

+1.5.1.3 Documentation of Extensions

+ +

+1.5.1.4 Treatment of Exceptional Situations

+ +

+1.5.1.5 Conformance Statement

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eaa.htm new file mode 100644 index 00000000..4561a952 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.5.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.1 Required Language Features

+A conforming implementation shall accept all features (including deprecated features) of the language specified in this standard, with the meanings defined in this standard.

+A conforming implementation shall not require the inclusion of substitute or additional language elements in code in order to accomplish a feature of the language that is specified in this standard.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eab.htm new file mode 100644 index 00000000..60732446 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eab.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.5.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.2 Documentation of Implementation-Dependent Features

+A conforming implementation shall be accompanied by a document that provides a definition of all implementation-defined aspects of the language defined by this specification.

+In addition, a conforming implementation is encouraged (but not required) to document items in this standard that are identified as implementation-dependent, although in some cases such documentation might simply identify the item as ``undefined.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eac.htm new file mode 100644 index 00000000..30c4bc61 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eac.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.5.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.3 Documentation of Extensions

+A conforming implementation shall be accompanied by a document that separately describes any features accepted by the implementation that are not specified in this standard, but that do not cause any ambiguity or contradiction when added to the language standard. Such extensions shall be described as being ``extensions to Common Lisp as specified by ANSI <<standard number>>.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ead.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ead.htm new file mode 100644 index 00000000..2572a731 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ead.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 1.5.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.4 Treatment of Exceptional Situations

+A conforming implementation shall treat exceptional situations in a manner consistent with this specification.

+ + +

+1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eada.htm new file mode 100644 index 00000000..83e75555 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eada.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 1.5.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations

+If more than one passage in this specification appears to apply to the same situation but in conflicting ways, the passage that appears to describe the situation in the most specific way (not necessarily the passage that provides the most constrained kind of error detection) takes precedence.

+ + +

+1.5.1.4.1.1 Examples of Resolution of Apparent Conflicts in Exceptional Situations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eadaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eadaa.htm new file mode 100644 index 00000000..8ecaf17b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eadaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.5.1.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.4.1.1 Examples of Resolution of Apparent Conflicts in Exceptional Situations

+Suppose that function foo is a member of a set S of functions that operate on numbers. Suppose that one passage states that an error must be signaled if any function in S is ever given an argument of 17. Suppose that an apparently conflicting passage states that the consequences are undefined if foo receives an argument of 17. Then the second passage (the one specifically about foo) would dominate because the description of the situational context is the most specific, and it would not be required that foo signal an error on an argument of 17 even though other functions in the set S would be required to do so.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eae.htm new file mode 100644 index 00000000..04ae9934 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eae.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 1.5.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.1.5 Conformance Statement

+A conforming implementation shall produce a conformance statement as a consequence of using the implementation, or that statement shall be included in the accompanying documentation. If the implementation conforms in all respects with this standard, the conformance statement shall be

+

``<<Implementation>> conforms with the requirements of ANSI <<standard number>>''

+If the implementation conforms with some but not all of the requirements of this standard, then the conformance statement shall be

+

``<<Implementation>> conforms with the requirements of ANSI <<standard number>> with the following exceptions: <<reference to or complete list of the requirements of the standard with which the implementation does not conform>>.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eb.htm new file mode 100644 index 00000000..1737c512 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eb.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 1.5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.2 Conforming Programs

+Code conforming with the requirements of this standard shall adhere to the following:

+

  1. Conforming code shall use only those features of the language syntax and semantics that are either specified in this standard or defined using the extension mechanisms specified in the standard.

    +

  2. Conforming code may use implementation-dependent features and values, but shall not rely upon any particular interpretation of these features and values other than those that are discovered by the execution of code.

    +

  3. Conforming code shall not depend on the consequences of undefined or unspecified situations.

    +

  4. Conforming code does not use any constructions that are prohibited by the standard.

    +

  5. Conforming code does not depend on extensions included in an implementation.

+ + +

+1.5.2.1 Use of Implementation-Defined Language Features

+ +

+1.5.2.2 Character Set for Portable Code

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eba.htm new file mode 100644 index 00000000..d04533a2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_eba.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 1.5.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.2.1 Use of Implementation-Defined Language Features

+Note that conforming code may rely on particular implementation-defined values or features. Also note that the requirements for conforming code and conforming implementations do not require that the results produced by conforming code always be the same when processed by a conforming implementation. The results may be the same, or they may differ.

+ Conforming code may run in all conforming implementations, but might have allowable implementation-defined behavior that makes it non-portable code. For example, the following are examples of forms that are conforming, but that might return different values in different implementations:

+

+ (evenp most-positive-fixnum) =>  implementation-dependent
+ (random) =>  implementation-dependent
+ (> lambda-parameters-limit 93) =>  implementation-dependent
+ (char-name #\A) =>  implementation-dependent
+
+

+ + +

+1.5.2.1.1 Use of Read-Time Conditionals

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebaa.htm new file mode 100644 index 00000000..2bb3322f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebaa.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 1.5.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.2.1.1 Use of Read-Time Conditionals

+Use of #+ and #- does not automatically disqualify a program from being conforming. A program which uses #+ and #- is considered conforming if there is no set of features in which the program would not be conforming. Of course, conforming programs are not necessarily working programs. The following program is conforming:

+

+(defun foo ()
+  #+ACME (acme:initialize-something)
+  (print 'hello-there))
+
+

+However, this program might or might not work, depending on whether the presence of the feature ACME really implies that a function named acme:initialize-something is present in the environment. In effect, using #+ or #- in a conforming program means that the variable *features* becomes just one more piece of input data to that program. Like any other data coming into a program, the programmer is responsible for assuring that the program does not make unwarranted assumptions on the basis of input data.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebb.htm new file mode 100644 index 00000000..cbefc94a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ebb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.5.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.5.2.2 Character Set for Portable Code

+Portable code is written using only standard characters.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_f.htm new file mode 100644 index 00000000..703cb887 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_f.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.6 Language Extensions

+

+A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard, or a documented consequence of a situation that the standard specifies as undefined, unspecified, or extendable by the implementation. For example, if this standard says that ``the results are unspecified,'' an extension would be to specify the results.

+ If the correct behavior of a program depends on the results provided by an extension, only implementations with the same extension will execute the program correctly. Note that such a program might be non-conforming. Also, if this standard says that ``an implementation may be extended,'' a conforming, but possibly non-portable, program can be written using an extension.

+An implementation can have extensions, provided they do not alter the behavior of conforming code and provided they are not explicitly prohibited by this standard.

+

+The term ``extension'' refers only to extensions available upon startup. An implementation is free to allow or prohibit redefinition of an extension.

+The following list contains specific guidance to implementations concerning certain types of extensions.

+

Extra return values

+ An implementation must return exactly the number of return values specified by this standard unless the standard specifically indicates otherwise.

+

Unsolicited messages

+

+No output can be produced by a function other than that specified in the standard or due to the signaling of conditions detected by the function.

+Unsolicited output, such as garbage collection notifications and autoload heralds, should not go directly to the stream that is the value of a stream variable defined in this standard, but can go indirectly to terminal I/O by using a synonym stream to *terminal-io*.

+Progress reports from such functions as load and compile are considered solicited, and are not covered by this prohibition.

+

+

Implementation of macros and special forms

+

+Macros and special operators defined in this standard must not be functions.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_g.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_g.htm new file mode 100644 index 00000000..641e1d1e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_g.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.7 Language Subsets

+ The language described in this standard contains no subsets, though subsets are not forbidden.

+For a language to be considered a subset, it must have the property that any valid program in that language has equivalent semantics and will run directly (with no extralingual pre-processing, and no special compatibility packages) in any conforming implementation of the full language.

+A language that conforms to this requirement shall be described as being a ``subset of Common Lisp as specified by ANSI <<standard number>>.''

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_h.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_h.htm new file mode 100644 index 00000000..7daab891 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_h.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 1.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.8 Deprecated Language Features

+Deprecated language features are not expected to appear in future Common Lisp tandards, but are required to be implemented for conformance with this standard; see Section 1.5.1.1 (Required Language Features).

+Conforming programs can use deprecated features; however, it is considered good programming style to avoid them. It is permissible for the compiler to produce style warnings about the use of such features at compile time, but there should be no such warnings at program execution time.

+ + +

+1.8.1 Deprecated Functions

+ +

+1.8.2 Deprecated Argument Conventions

+ +

+1.8.3 Deprecated Variables

+ +

+1.8.4 Deprecated Reader Syntax

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ha.htm new file mode 100644 index 00000000..76f7e71a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_ha.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 1.8.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.8.1 Deprecated Functions

+ The functions in the next figure are deprecated. 

+assoc-if-not   nsubst-if-not       require            
+count-if-not   nsubstitute-if-not  set                
+delete-if-not  position-if-not     subst-if-not       
+find-if-not    provide             substitute-if-not  
+gentemp        rassoc-if-not                          
+member-if-not  remove-if-not                          
+
+

Figure 1-2. Deprecated Functions

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hb.htm new file mode 100644 index 00000000..b638f910 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hb.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 1.8.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.8.2 Deprecated Argument Conventions

+ The ability to pass a numeric argument to gensym has been deprecated.

+ The :test-not argument to the functions in the next figure are deprecated.

+

+adjoin             nset-difference    search            
+assoc              nset-exclusive-or  set-difference    
+count              nsublis            set-exclusive-or  
+delete             nsubst             sublis            
+delete-duplicates  nsubstitute        subsetp           
+find               nunion             subst             
+intersection       position           substitute        
+member             rassoc             tree-equal        
+mismatch           remove             union             
+nintersection      remove-duplicates                    
+
+

Figure 1-3. Functions with Deprecated :TEST-NOT Arguments

+ The use of the situation names compile, load, and eval in eval-when is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hc.htm new file mode 100644 index 00000000..9752bc2a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.8.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.8.3 Deprecated Variables

+ The variable *modules* is deprecated.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hd.htm new file mode 100644 index 00000000..f1d1826b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_hd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 1.8.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.8.4 Deprecated Reader Syntax

+ The #S reader macro forces keyword names into the KEYWORD package; see Section 2.4.8.13 (Sharpsign S). This feature is deprecated; in the future, keyword names will be taken in the package they are read in, so symbols that are actually in the KEYWORD package should be used if that is what is desired.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_i.htm new file mode 100644 index 00000000..3a2b4370 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/01_i.htm @@ -0,0 +1,526 @@ + + + +CLHS: Section 1.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+1.9 Symbols in the COMMON-LISP Package

+The figures on the next twelve pages contain a complete enumeration of the 978 external symbols in the COMMON-LISP package.

+

+&allow-other-keys            *print-miser-width*          
+&aux                         *print-pprint-dispatch*      
+&body                        *print-pretty*               
+&environment                 *print-radix*                
+&key                         *print-readably*             
+&optional                    *print-right-margin*         
+&rest                        *query-io*                   
+&whole                       *random-state*               
+*                            *read-base*                  
+**                           *read-default-float-format*  
+***                          *read-eval*                  
+*break-on-signals*           *read-suppress*              
+*compile-file-pathname*      *readtable*                  
+*compile-file-truename*      *standard-input*             
+*compile-print*              *standard-output*            
+*compile-verbose*            *terminal-io*                
+*debug-io*                   *trace-output*               
+*debugger-hook*              +                            
+*default-pathname-defaults*  ++                           
+*error-output*               +++                          
+*features*                   -                            
+*gensym-counter*             /                            
+*load-pathname*              //                           
+*load-print*                 ///                          
+*load-truename*              /=                           
+*load-verbose*               1+                           
+*macroexpand-hook*           1-                           
+*modules*                    <                            
+*package*                    <=                           
+*print-array*                =                            
+*print-base*                 >                            
+*print-case*                 >=                           
+*print-circle*               abort                        
+*print-escape*               abs                          
+*print-gensym*               acons                        
+*print-length*               acos                         
+*print-level*                acosh                        
+*print-lines*                add-method                   
+
+

Figure 1-4. Symbols in the COMMON-LISP package (part one of twelve).

+

+

+adjoin                      atom          boundp                    
+adjust-array                base-char     break                     
+adjustable-array-p          base-string   broadcast-stream          
+allocate-instance           bignum        broadcast-stream-streams  
+alpha-char-p                bit           built-in-class            
+alphanumericp               bit-and       butlast                   
+and                         bit-andc1     byte                      
+append                      bit-andc2     byte-position             
+apply                       bit-eqv       byte-size                 
+apropos                     bit-ior       caaaar                    
+apropos-list                bit-nand      caaadr                    
+aref                        bit-nor       caaar                     
+arithmetic-error            bit-not       caadar                    
+arithmetic-error-operands   bit-orc1      caaddr                    
+arithmetic-error-operation  bit-orc2      caadr                     
+array                       bit-vector    caar                      
+array-dimension             bit-vector-p  cadaar                    
+array-dimension-limit       bit-xor       cadadr                    
+array-dimensions            block         cadar                     
+array-displacement          boole         caddar                    
+array-element-type          boole-1       cadddr                    
+array-has-fill-pointer-p    boole-2       caddr                     
+array-in-bounds-p           boole-and     cadr                      
+array-rank                  boole-andc1   call-arguments-limit      
+array-rank-limit            boole-andc2   call-method               
+array-row-major-index       boole-c1      call-next-method          
+array-total-size            boole-c2      car                       
+array-total-size-limit      boole-clr     case                      
+arrayp                      boole-eqv     catch                     
+ash                         boole-ior     ccase                     
+asin                        boole-nand    cdaaar                    
+asinh                       boole-nor     cdaadr                    
+assert                      boole-orc1    cdaar                     
+assoc                       boole-orc2    cdadar                    
+assoc-if                    boole-set     cdaddr                    
+assoc-if-not                boole-xor     cdadr                     
+atan                        boolean       cdar                      
+atanh                       both-case-p   cddaar                    
+
+

Figure 1-5. Symbols in the COMMON-LISP package (part two of twelve).

+

+

+cddadr             clear-input                  copy-tree                  
+cddar              clear-output                 cos                        
+cdddar             close                        cosh                       
+cddddr             clrhash                      count                      
+cdddr              code-char                    count-if                   
+cddr               coerce                       count-if-not               
+cdr                compilation-speed            ctypecase                  
+ceiling            compile                      debug                      
+cell-error         compile-file                 decf                       
+cell-error-name    compile-file-pathname        declaim                    
+cerror             compiled-function            declaration                
+change-class       compiled-function-p          declare                    
+char               compiler-macro               decode-float               
+char-code          compiler-macro-function      decode-universal-time      
+char-code-limit    complement                   defclass                   
+char-downcase      complex                      defconstant                
+char-equal         complexp                     defgeneric                 
+char-greaterp      compute-applicable-methods   define-compiler-macro      
+char-int           compute-restarts             define-condition           
+char-lessp         concatenate                  define-method-combination  
+char-name          concatenated-stream          define-modify-macro        
+char-not-equal     concatenated-stream-streams  define-setf-expander       
+char-not-greaterp  cond                         define-symbol-macro        
+char-not-lessp     condition                    defmacro                   
+char-upcase        conjugate                    defmethod                  
+char/=             cons                         defpackage                 
+char<              consp                        defparameter               
+char<=             constantly                   defsetf                    
+char=              constantp                    defstruct                  
+char>              continue                     deftype                    
+char>=             control-error                defun                      
+character          copy-alist                   defvar                     
+characterp         copy-list                    delete                     
+check-type         copy-pprint-dispatch         delete-duplicates          
+cis                copy-readtable               delete-file                
+class              copy-seq                     delete-if                  
+class-name         copy-structure               delete-if-not              
+class-of           copy-symbol                  delete-package             
+
+

Figure 1-6. Symbols in the COMMON-LISP package (part three of twelve).

+

+

+denominator                    eq                   
+deposit-field                  eql                  
+describe                       equal                
+describe-object                equalp               
+destructuring-bind             error                
+digit-char                     etypecase            
+digit-char-p                   eval                 
+directory                      eval-when            
+directory-namestring           evenp                
+disassemble                    every                
+division-by-zero               exp                  
+do                             export               
+do*                            expt                 
+do-all-symbols                 extended-char        
+do-external-symbols            fboundp              
+do-symbols                     fceiling             
+documentation                  fdefinition          
+dolist                         ffloor               
+dotimes                        fifth                
+double-float                   file-author          
+double-float-epsilon           file-error           
+double-float-negative-epsilon  file-error-pathname  
+dpb                            file-length          
+dribble                        file-namestring      
+dynamic-extent                 file-position        
+ecase                          file-stream          
+echo-stream                    file-string-length   
+echo-stream-input-stream       file-write-date      
+echo-stream-output-stream      fill                 
+ed                             fill-pointer         
+eighth                         find                 
+elt                            find-all-symbols     
+encode-universal-time          find-class           
+end-of-file                    find-if              
+endp                           find-if-not          
+enough-namestring              find-method          
+ensure-directories-exist       find-package         
+ensure-generic-function        find-restart         
+
+

Figure 1-7. Symbols in the COMMON-LISP package (part four of twelve).

+

+

+find-symbol                       get-internal-run-time        
+finish-output                     get-macro-character          
+first                             get-output-stream-string     
+fixnum                            get-properties               
+flet                              get-setf-expansion           
+float                             get-universal-time           
+float-digits                      getf                         
+float-precision                   gethash                      
+float-radix                       go                           
+float-sign                        graphic-char-p               
+floating-point-inexact            handler-bind                 
+floating-point-invalid-operation  handler-case                 
+floating-point-overflow           hash-table                   
+floating-point-underflow          hash-table-count             
+floatp                            hash-table-p                 
+floor                             hash-table-rehash-size       
+fmakunbound                       hash-table-rehash-threshold  
+force-output                      hash-table-size              
+format                            hash-table-test              
+formatter                         host-namestring              
+fourth                            identity                     
+fresh-line                        if                           
+fround                            ignorable                    
+ftruncate                         ignore                       
+ftype                             ignore-errors                
+funcall                           imagpart                     
+function                          import                       
+function-keywords                 in-package                   
+function-lambda-expression        incf                         
+functionp                         initialize-instance          
+gcd                               inline                       
+generic-function                  input-stream-p               
+gensym                            inspect                      
+gentemp                           integer                      
+get                               integer-decode-float         
+get-decoded-time                  integer-length               
+get-dispatch-macro-character      integerp                     
+get-internal-real-time            interactive-stream-p         
+
+

Figure 1-8. Symbols in the COMMON-LISP package (part five of twelve).

+

+

+intern                                  lisp-implementation-type            
+internal-time-units-per-second          lisp-implementation-version         
+intersection                            list                                
+invalid-method-error                    list*                               
+invoke-debugger                         list-all-packages                   
+invoke-restart                          list-length                         
+invoke-restart-interactively            listen                              
+isqrt                                   listp                               
+keyword                                 load                                
+keywordp                                load-logical-pathname-translations  
+labels                                  load-time-value                     
+lambda                                  locally                             
+lambda-list-keywords                    log                                 
+lambda-parameters-limit                 logand                              
+last                                    logandc1                            
+lcm                                     logandc2                            
+ldb                                     logbitp                             
+ldb-test                                logcount                            
+ldiff                                   logeqv                              
+least-negative-double-float             logical-pathname                    
+least-negative-long-float               logical-pathname-translations       
+least-negative-normalized-double-float  logior                              
+least-negative-normalized-long-float    lognand                             
+least-negative-normalized-short-float   lognor                              
+least-negative-normalized-single-float  lognot                              
+least-negative-short-float              logorc1                             
+least-negative-single-float             logorc2                             
+least-positive-double-float             logtest                             
+least-positive-long-float               logxor                              
+least-positive-normalized-double-float  long-float                          
+least-positive-normalized-long-float    long-float-epsilon                  
+least-positive-normalized-short-float   long-float-negative-epsilon         
+least-positive-normalized-single-float  long-site-name                      
+least-positive-short-float              loop                                
+least-positive-single-float             loop-finish                         
+length                                  lower-case-p                        
+let                                     machine-instance                    
+let*                                    machine-type                        
+
+

Figure 1-9. Symbols in the COMMON-LISP package (part six of twelve).

+

+

+machine-version                mask-field                  
+macro-function                 max                         
+macroexpand                    member                      
+macroexpand-1                  member-if                   
+macrolet                       member-if-not               
+make-array                     merge                       
+make-broadcast-stream          merge-pathnames             
+make-concatenated-stream       method                      
+make-condition                 method-combination          
+make-dispatch-macro-character  method-combination-error    
+make-echo-stream               method-qualifiers           
+make-hash-table                min                         
+make-instance                  minusp                      
+make-instances-obsolete        mismatch                    
+make-list                      mod                         
+make-load-form                 most-negative-double-float  
+make-load-form-saving-slots    most-negative-fixnum        
+make-method                    most-negative-long-float    
+make-package                   most-negative-short-float   
+make-pathname                  most-negative-single-float  
+make-random-state              most-positive-double-float  
+make-sequence                  most-positive-fixnum        
+make-string                    most-positive-long-float    
+make-string-input-stream       most-positive-short-float   
+make-string-output-stream      most-positive-single-float  
+make-symbol                    muffle-warning              
+make-synonym-stream            multiple-value-bind         
+make-two-way-stream            multiple-value-call         
+makunbound                     multiple-value-list         
+map                            multiple-value-prog1        
+map-into                       multiple-value-setq         
+mapc                           multiple-values-limit       
+mapcan                         name-char                   
+mapcar                         namestring                  
+mapcon                         nbutlast                    
+maphash                        nconc                       
+mapl                           next-method-p               
+maplist                        nil                         
+
+

Figure 1-10. Symbols in the COMMON-LISP package (part seven of twelve).

+

+

+nintersection         package-error                  
+ninth                 package-error-package          
+no-applicable-method  package-name                   
+no-next-method        package-nicknames              
+not                   package-shadowing-symbols      
+notany                package-use-list               
+notevery              package-used-by-list           
+notinline             packagep                       
+nreconc               pairlis                        
+nreverse              parse-error                    
+nset-difference       parse-integer                  
+nset-exclusive-or     parse-namestring               
+nstring-capitalize    pathname                       
+nstring-downcase      pathname-device                
+nstring-upcase        pathname-directory             
+nsublis               pathname-host                  
+nsubst                pathname-match-p               
+nsubst-if             pathname-name                  
+nsubst-if-not         pathname-type                  
+nsubstitute           pathname-version               
+nsubstitute-if        pathnamep                      
+nsubstitute-if-not    peek-char                      
+nth                   phase                          
+nth-value             pi                             
+nthcdr                plusp                          
+null                  pop                            
+number                position                       
+numberp               position-if                    
+numerator             position-if-not                
+nunion                pprint                         
+oddp                  pprint-dispatch                
+open                  pprint-exit-if-list-exhausted  
+open-stream-p         pprint-fill                    
+optimize              pprint-indent                  
+or                    pprint-linear                  
+otherwise             pprint-logical-block           
+output-stream-p       pprint-newline                 
+package               pprint-pop                     
+
+

Figure 1-11. Symbols in the COMMON-LISP package (part eight of twelve).

+

+

+pprint-tab                 read-char                   
+pprint-tabular             read-char-no-hang           
+prin1                      read-delimited-list         
+prin1-to-string            read-from-string            
+princ                      read-line                   
+princ-to-string            read-preserving-whitespace  
+print                      read-sequence               
+print-not-readable         reader-error                
+print-not-readable-object  readtable                   
+print-object               readtable-case              
+print-unreadable-object    readtablep                  
+probe-file                 real                        
+proclaim                   realp                       
+prog                       realpart                    
+prog*                      reduce                      
+prog1                      reinitialize-instance       
+prog2                      rem                         
+progn                      remf                        
+program-error              remhash                     
+progv                      remove                      
+provide                    remove-duplicates           
+psetf                      remove-if                   
+psetq                      remove-if-not               
+push                       remove-method               
+pushnew                    remprop                     
+quote                      rename-file                 
+random                     rename-package              
+random-state               replace                     
+random-state-p             require                     
+rassoc                     rest                        
+rassoc-if                  restart                     
+rassoc-if-not              restart-bind                
+ratio                      restart-case                
+rational                   restart-name                
+rationalize                return                      
+rationalp                  return-from                 
+read                       revappend                   
+read-byte                  reverse                     
+
+

Figure 1-12. Symbols in the COMMON-LISP package (part nine of twelve).

+

+

+room                          simple-bit-vector                  
+rotatef                       simple-bit-vector-p                
+round                         simple-condition                   
+row-major-aref                simple-condition-format-arguments  
+rplaca                        simple-condition-format-control    
+rplacd                        simple-error                       
+safety                        simple-string                      
+satisfies                     simple-string-p                    
+sbit                          simple-type-error                  
+scale-float                   simple-vector                      
+schar                         simple-vector-p                    
+search                        simple-warning                     
+second                        sin                                
+sequence                      single-float                       
+serious-condition             single-float-epsilon               
+set                           single-float-negative-epsilon      
+set-difference                sinh                               
+set-dispatch-macro-character  sixth                              
+set-exclusive-or              sleep                              
+set-macro-character           slot-boundp                        
+set-pprint-dispatch           slot-exists-p                      
+set-syntax-from-char          slot-makunbound                    
+setf                          slot-missing                       
+setq                          slot-unbound                       
+seventh                       slot-value                         
+shadow                        software-type                      
+shadowing-import              software-version                   
+shared-initialize             some                               
+shiftf                        sort                               
+short-float                   space                              
+short-float-epsilon           special                            
+short-float-negative-epsilon  special-operator-p                 
+short-site-name               speed                              
+signal                        sqrt                               
+signed-byte                   stable-sort                        
+signum                        standard                           
+simple-array                  standard-char                      
+simple-base-string            standard-char-p                    
+
+

Figure 1-13. Symbols in the COMMON-LISP package (part ten of twelve).

+

+

+standard-class             sublis                      
+standard-generic-function  subseq                      
+standard-method            subsetp                     
+standard-object            subst                       
+step                       subst-if                    
+storage-condition          subst-if-not                
+store-value                substitute                  
+stream                     substitute-if               
+stream-element-type        substitute-if-not           
+stream-error               subtypep                    
+stream-error-stream        svref                       
+stream-external-format     sxhash                      
+streamp                    symbol                      
+string                     symbol-function             
+string-capitalize          symbol-macrolet             
+string-downcase            symbol-name                 
+string-equal               symbol-package              
+string-greaterp            symbol-plist                
+string-left-trim           symbol-value                
+string-lessp               symbolp                     
+string-not-equal           synonym-stream              
+string-not-greaterp        synonym-stream-symbol       
+string-not-lessp           t                           
+string-right-trim          tagbody                     
+string-stream              tailp                       
+string-trim                tan                         
+string-upcase              tanh                        
+string/=                   tenth                       
+string<                    terpri                      
+string<=                   the                         
+string=                    third                       
+string>                    throw                       
+string>=                   time                        
+stringp                    trace                       
+structure                  translate-logical-pathname  
+structure-class            translate-pathname          
+structure-object           tree-equal                  
+style-warning              truename                    
+
+

Figure 1-14. Symbols in the COMMON-LISP package (part eleven of twelve).

+

+

+truncate                             values-list               
+two-way-stream                       variable                  
+two-way-stream-input-stream          vector                    
+two-way-stream-output-stream         vector-pop                
+type                                 vector-push               
+type-error                           vector-push-extend        
+type-error-datum                     vectorp                   
+type-error-expected-type             warn                      
+type-of                              warning                   
+typecase                             when                      
+typep                                wild-pathname-p           
+unbound-slot                         with-accessors            
+unbound-slot-instance                with-compilation-unit     
+unbound-variable                     with-condition-restarts   
+undefined-function                   with-hash-table-iterator  
+unexport                             with-input-from-string    
+unintern                             with-open-file            
+union                                with-open-stream          
+unless                               with-output-to-string     
+unread-char                          with-package-iterator     
+unsigned-byte                        with-simple-restart       
+untrace                              with-slots                
+unuse-package                        with-standard-io-syntax   
+unwind-protect                       write                     
+update-instance-for-different-class  write-byte                
+update-instance-for-redefined-class  write-char                
+upgraded-array-element-type          write-line                
+upgraded-complex-part-type           write-sequence            
+upper-case-p                         write-string              
+use-package                          write-to-string           
+use-value                            y-or-n-p                  
+user-homedir-pathname                yes-or-no-p               
+values                               zerop                     
+
+

Figure 1-15. Symbols in the COMMON-LISP package (part twelve of twelve).

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_.htm new file mode 100644 index 00000000..4e332d91 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_.htm @@ -0,0 +1,44 @@ + + + +CLHS: Chapter 2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+2. Syntax

+

+ + +

+2.1 Character Syntax

+ +

+2.2 Reader Algorithm

+ +

+2.3 Interpretation of Tokens

+ +

+2.4 Standard Macro Characters

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_a.htm new file mode 100644 index 00000000..5295699d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_a.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1 Character Syntax

+The Lisp reader takes characters from a stream, interprets them as a printed representation of an object, constructs that object, and returns it.

+ The syntax described by this chapter is called the standard syntax. Operations are provided by Common Lisp so that various aspects of the syntax information represented by a readtable can be modified under program control; see Section 23 (Reader). Except as explicitly stated otherwise, the syntax used throughout this document is standard syntax.

+ + +

+2.1.1 Readtables

+ +

+2.1.2 Variables that affect the Lisp Reader

+ +

+2.1.3 Standard Characters

+ + +

+2.1.4 Character Syntax Types

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aa.htm new file mode 100644 index 00000000..01056a5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aa.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.1 Readtables

+Syntax information for use by the Lisp reader is embodied in an object called a readtable. Among other things, the readtable contains the association between characters and syntax types.

+The next figure lists some defined names that are applicable to readtables.

+

+*readtable*                    readtable-case                
+copy-readtable                 readtablep                    
+get-dispatch-macro-character   set-dispatch-macro-character  
+get-macro-character            set-macro-character           
+make-dispatch-macro-character  set-syntax-from-char          
+
+

Figure 2-1. Readtable defined names

+ + +

+2.1.1.1 The Current Readtable

+ +

+2.1.1.2 The Standard Readtable

+ +

+2.1.1.3 The Initial Readtable

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aaa.htm new file mode 100644 index 00000000..99278052 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.1.1 The Current Readtable

+Several readtables describing different syntaxes can exist, but at any given time only one, called the current readtable, affects the way in which expressions[2] are parsed into objects by the Lisp reader. The current readtable in a given dynamic environment is the value of *readtable* in that environment. To make a different readtable become the current readtable, *readtable* can be assigned or bound.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aab.htm new file mode 100644 index 00000000..2688f6a9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aab.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 2.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.1.2 The Standard Readtable

+The standard readtable conforms to standard syntax. The consequences are undefined if an attempt is made to modify the standard readtable. To achieve the effect of altering or extending standard syntax, a copy of the standard readtable can be created; see the function copy-readtable.

+The readtable case of the standard readtable is :upcase.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aac.htm new file mode 100644 index 00000000..16a7ae30 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_aac.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.1.3 The Initial Readtable

+The initial readtable is the readtable that is the current readtable at the time when the Lisp image starts. At that time, it conforms to standard syntax. The initial readtable is distinct from the standard readtable. It is permissible for a conforming program to modify the initial readtable.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ab.htm new file mode 100644 index 00000000..c0b80f46 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ab.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.2 Variables that affect the Lisp Reader

+The Lisp reader is influenced not only by the current readtable, but also by various dynamic variables. The next figure lists the variables that influence the behavior of the Lisp reader.

+

+*package*    *read-default-float-format*  *readtable*  
+*read-base*  *read-suppress*                           
+
+

Figure 2-2. Variables that influence the Lisp reader.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ac.htm new file mode 100644 index 00000000..e8eae84b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ac.htm @@ -0,0 +1,106 @@ + + + +CLHS: Section 2.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.3 Standard Characters

+ All implementations must support a character repertoire called standard-char; characters that are members of that repertoire are called standard characters.

+The standard-char repertoire consists of the non-graphic character newline, the graphic character space, and the following additional ninety-four graphic characters or their equivalents:

+

+Graphic ID  Glyph  Description  Graphic ID  Glyph  Description  
+LA01        a      small a      LN01        n      small n      
+LA02        A      capital A    LN02        N      capital N    
+LB01        b      small b      LO01        o      small o      
+LB02        B      capital B    LO02        O      capital O    
+LC01        c      small c      LP01        p      small p      
+LC02        C      capital C    LP02        P      capital P    
+LD01        d      small d      LQ01        q      small q      
+LD02        D      capital D    LQ02        Q      capital Q    
+LE01        e      small e      LR01        r      small r      
+LE02        E      capital E    LR02        R      capital R    
+LF01        f      small f      LS01        s      small s      
+LF02        F      capital F    LS02        S      capital S    
+LG01        g      small g      LT01        t      small t      
+LG02        G      capital G    LT02        T      capital T    
+LH01        h      small h      LU01        u      small u      
+LH02        H      capital H    LU02        U      capital U    
+LI01        i      small i      LV01        v      small v      
+LI02        I      capital I    LV02        V      capital V    
+LJ01        j      small j      LW01        w      small w      
+LJ02        J      capital J    LW02        W      capital W    
+LK01        k      small k      LX01        x      small x      
+LK02        K      capital K    LX02        X      capital X    
+LL01        l      small l      LY01        y      small y      
+LL02        L      capital L    LY02        Y      capital Y    
+LM01        m      small m      LZ01        z      small z      
+LM02        M      capital M    LZ02        Z      capital Z    
+
+

Figure 2-3. Standard Character Subrepertoire (Part 1 of 3: Latin Characters)

+

+Graphic ID  Glyph  Description  Graphic ID  Glyph  Description  
+ND01        1      digit 1      ND06        6      digit 6      
+ND02        2      digit 2      ND07        7      digit 7      
+ND03        3      digit 3      ND08        8      digit 8      
+ND04        4      digit 4      ND09        9      digit 9      
+ND05        5      digit 5      ND10        0      digit 0      
+
+

Figure 2-4. Standard Character Subrepertoire (Part 2 of 3: Numeric Characters)

+ 

+Graphic ID  Glyph  Description                              
+SP02        !      exclamation mark                         
+SC03        $      dollar sign                              
+SP04        "      quotation mark, or double quote          
+SP05        '      apostrophe, or [single] quote            
+SP06        (      left parenthesis, or open parenthesis    
+SP07        )      right parenthesis, or close parenthesis  
+SP08        ,      comma                                    
+SP09        _      low line, or underscore                  
+SP10        -      hyphen, or minus [sign]                  
+SP11        .      full stop, period, or dot                
+SP12        /      solidus, or slash                        
+SP13        :      colon                                    
+SP14        ;      semicolon                                
+SP15        ?      question mark                            
+SA01        +      plus [sign]                              
+SA03        <      less-than [sign]                         
+SA04        =      equals [sign]                            
+SA05        >      greater-than [sign]                      
+SM01        #      number sign, or sharp[sign]              
+SM02        %      percent [sign]                           
+SM03        &      ampersand                                
+SM04        *      asterisk, or star                        
+SM05        @      commercial at, or at-sign                
+SM06        [      left [square] bracket                    
+SM07        \      reverse solidus, or backslash            
+SM08        ]      right [square] bracket                   
+SM11        {      left curly bracket, or left brace        
+SM13        |      vertical bar                             
+SM14        }      right curly bracket, or right brace      
+SD13        `      grave accent, or backquote               
+SD15        ^      circumflex accent                        
+SD19        ~      tilde                                    
+
+

Figure 2-5. Standard Character Subrepertoire (Part 3 of 3: Special Characters)

+The graphic IDs are not used within Common Lisp, but are provided for cross reference purposes with ISO 6937/2. Note that the first letter of the graphic ID categorizes the character as follows: L---Latin, N---Numeric, S---Special.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ad.htm new file mode 100644 index 00000000..c893ec2d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ad.htm @@ -0,0 +1,83 @@ + + + +CLHS: Section 2.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4 Character Syntax Types

+The Lisp reader constructs an object from the input text by interpreting each character according to its syntax type. The Lisp reader cannot accept as input everything that the Lisp printer produces, and the Lisp reader has features that are not used by the Lisp printer. The Lisp reader can be used as a lexical analyzer for a more general user-written parser.

+When the Lisp reader is invoked, it reads a single character from the input stream and dispatches according to the syntax type of that character. Every character that can appear in the input stream is of one of the syntax types shown in Figure 2-6.

+ 

+constituent  macro character  single escape  
+invalid      multiple escape  whitespace[2]  
+
+

Figure 2-6. Possible Character Syntax Types

+The syntax type of a character in a readtable determines how that character is interpreted by the Lisp reader while that readtable is the current readtable. At any given time, every character has exactly one syntax type.

+Figure 2-7 lists the syntax type of each character in standard syntax.

+ 

+character  syntax type                 character  syntax type             
+Backspace  constituent                 0--9       constituent             
+Tab        whitespace[2]               :          constituent             
+Newline    whitespace[2]               ;          terminating macro char  
+Linefeed   whitespace[2]               <          constituent             
+Page       whitespace[2]               =          constituent             
+Return     whitespace[2]               >          constituent             
+Space      whitespace[2]               ?          constituent*            
+!          constituent*                @          constituent             
+"          terminating macro char      A--Z       constituent             
+#          non-terminating macro char  [          constituent*            
+$          constituent                 \          single escape           
+%          constituent                 ]          constituent*            
+&          constituent                 ^          constituent             
+'          terminating macro char      _          constituent             
+(          terminating macro char      `          terminating macro char  
+)          terminating macro char      a--z       constituent             
+*          constituent                 {          constituent*            
++          constituent                 |          multiple escape         
+,          terminating macro char      }          constituent*            
+-          constituent                 ~          constituent             
+.          constituent                 Rubout     constituent             
+/          constituent                 
+
+

Figure 2-7. Character Syntax Types in Standard Syntax

+The characters marked with an asterisk (*) are initially constituents, but they are not used in any standard Common Lisp notations. These characters are explicitly reserved to the programmer. ~ is not used in Common Lisp, and reserved to implementors. $ and % are alphabetic[2] characters, but are not used in the names of any standard Common Lisp defined names.

+Whitespace[2] characters serve as separators but are otherwise ignored. Constituent and escape characters are accumulated to make a token, which is then interpreted as a number or symbol. Macro characters trigger the invocation of functions (possibly user-supplied) that can perform arbitrary parsing actions. Macro characters are divided into two kinds, terminating and non-terminating, depending on whether or not they terminate a token. The following are descriptions of each kind of syntax type.

+ + +

+2.1.4.1 Constituent Characters

+ +

+2.1.4.3 Invalid Characters

+ +

+2.1.4.4 Macro Characters

+ +

+2.1.4.5 Multiple Escape Characters

+ +

+2.1.4.6 Single Escape Character

+ +

+2.1.4.7 Whitespace Characters

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ada.htm new file mode 100644 index 00000000..7a04face --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ada.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.1 Constituent Characters

+Constituent characters are used in tokens. A token is a representation of a number or a symbol. Examples of constituent characters are letters and digits.

+Letters in symbol names are sometimes converted to letters in the opposite case when the name is read; see Section 23.1.2 (Effect of Readtable Case on the Lisp Reader). Case conversion can be suppressed by the use of single escape or multiple escape characters.

+ + +

+2.1.4.2 Constituent Traits

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adb.htm new file mode 100644 index 00000000..2d47df76 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adb.htm @@ -0,0 +1,74 @@ + + + +CLHS: Section 2.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.2 Constituent Traits

+Every character has one or more constituent traits that define how the character is to be interpreted by the Lisp reader when the character is a constituent character. These constituent traits are alphabetic[2], digit, package marker, plus sign, minus sign, dot, decimal point, ratio marker, exponent marker, and invalid. Figure 2-8 shows the constituent traits of the standard characters and of certain semi-standard characters; no mechanism is provided for changing the constituent trait of a character. Any character with the alphadigit constituent trait in that figure is a digit if the current input base is greater than that character's digit value, otherwise the character is alphabetic[2]. Any character quoted by a single escape is treated as an alphabetic[2] constituent, regardless of its normal syntax.

+ 

+                                                                                    
+constituent  traits          constituent  traits                                    
+character                    character    
+----------
+                                                                                    
+Backspace    invalid         {            alphabetic[2]                             
+Tab          invalid*        }            alphabetic[2]                             
+Newline      invalid*        +            alphabetic[2], plus sign                  
+Linefeed     invalid*        -            alphabetic[2], minus sign                 
+Page         invalid*        .            alphabetic[2], dot, decimal point         
+Return       invalid*        /            alphabetic[2], ratio marker               
+Space        invalid*        A, a         alphadigit                                
+!            alphabetic[2]   B, b         alphadigit                                
+"            alphabetic[2]*  C, c         alphadigit                                
+#            alphabetic[2]*  D, d         alphadigit, double-float exponent marker  
+$            alphabetic[2]   E, e         alphadigit, float exponent marker         
+%            alphabetic[2]   F, f         alphadigit, single-float exponent marker  
+&            alphabetic[2]   G, g         alphadigit                                
+'            alphabetic[2]*  H, h         alphadigit                                
+(            alphabetic[2]*  I, i         alphadigit                                
+)            alphabetic[2]*  J, j         alphadigit                                
+*            alphabetic[2]   K, k         alphadigit                                
+,            alphabetic[2]*  L, l         alphadigit, long-float exponent marker    
+0-9          alphadigit      M, m         alphadigit                                
+:            package marker  N, n         alphadigit                                
+;            alphabetic[2]*  O, o         alphadigit                                
+<            alphabetic[2]   P, p         alphadigit                                
+=            alphabetic[2]   Q, q         alphadigit                                
+>            alphabetic[2]   R, r         alphadigit                                
+?            alphabetic[2]   S, s         alphadigit, short-float exponent marker   
+@            alphabetic[2]   T, t         alphadigit                                
+[            alphabetic[2]   U, u         alphadigit                                
+\            alphabetic[2]*  V, v         alphadigit                                
+]            alphabetic[2]   W, w         alphadigit                                
+^            alphabetic[2]   X, x         alphadigit                                
+_            alphabetic[2]   Y, y         alphadigit                                
+`            alphabetic[2]*  Z, z         alphadigit                                
+|            alphabetic[2]*  Rubout       invalid                                   
+~            alphabetic[2]   
+                                                                                    
+                             
+
+

Figure 2-8. Constituent Traits of Standard Characters and Semi-Standard Characters

+The interpretations in this table apply only to characters whose syntax type is constituent. Entries marked with an asterisk (*) are normally shadowed[2] because the indicated characters are of syntax type whitespace[2], macro character, single escape, or multiple escape; these constituent traits apply to them only if their syntax types are changed to constituent.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adc.htm new file mode 100644 index 00000000..96ff9265 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.3 Invalid Characters

+Characters with the constituent trait invalid cannot ever appear in a token except under the control of a single escape character. If an invalid character is encountered while an object is being read, an error of type reader-error is signaled. If an invalid character is preceded by a single escape character, it is treated as an alphabetic[2] constituent instead.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_add.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_add.htm new file mode 100644 index 00000000..158605b4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_add.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.1.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.4 Macro Characters

+When the Lisp reader encounters a macro character on an input stream, special parsing of subsequent characters on the input stream is performed.

+A macro character has an associated function called a reader macro function that implements its specialized parsing behavior. An association of this kind can be established or modified under control of a conforming program by using the functions set-macro-character and set-dispatch-macro-character.

+Upon encountering a macro character, the Lisp reader calls its reader macro function, which parses one specially formatted object from the input stream. The function either returns the parsed object, or else it returns no values to indicate that the characters scanned by the function are being ignored (e.g., in the case of a comment). Examples of macro characters are backquote, single-quote, left-parenthesis, and right-parenthesis.

+A macro character is either terminating or non-terminating. The difference between terminating and non-terminating macro characters lies in what happens when such characters occur in the middle of a token. If a non-terminating macro character occurs in the middle of a token, the function associated with the non-terminating macro character is not called, and the non-terminating macro character does not terminate the token's name; it becomes part of the name as if the macro character were really a constituent character. A terminating macro character terminates any token, and its associated reader macro function is called no matter where the character appears. The only non-terminating macro character in standard syntax is sharpsign.

+If a character is a dispatching macro character C1, its reader macro function is a function supplied by the implementation. This function reads decimal digit characters until a non-digit C2 is read. If any digits were read, they are converted into a corresponding integer infix parameter P; otherwise, the infix parameter P is nil. The terminating non-digit C2 is a character (sometimes called a ``sub-character'' to emphasize its subordinate role in the dispatching) that is looked up in the dispatch table associated with the dispatching macro character C1. The reader macro function associated with the sub-character C2 is invoked with three arguments: the stream, the sub-character C2, and the infix parameter P. For more information about dispatch characters, see the function set-dispatch-macro-character.

+For information about the macro characters that are available in standard syntax, see Section 2.4 (Standard Macro Characters).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ade.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ade.htm new file mode 100644 index 00000000..50bf602a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ade.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.1.4.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.5 Multiple Escape Characters

+A pair of multiple escape characters is used to indicate that an enclosed sequence of characters, including possible macro characters and whitespace[2] characters, are to be treated as alphabetic[2] characters with case preserved. Any single escape and multiple escape characters that are to appear in the sequence must be preceded by a single escape character.

+Vertical-bar is a multiple escape character in standard syntax.

+ + +

+2.1.4.5.1 Examples of Multiple Escape Characters

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adea.htm new file mode 100644 index 00000000..ae332b1e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adea.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 2.1.4.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.5.1 Examples of Multiple Escape Characters

+

+ ;; The following examples assume the readtable case of *readtable* 
+ ;; and *print-case* are both :upcase.
+ (eq 'abc 'ABC) =>  true
+ (eq 'abc '|ABC|) =>  true
+ (eq 'abc 'a|B|c) =>  true
+ (eq 'abc '|abc|) =>  false
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adf.htm new file mode 100644 index 00000000..400d668e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adf.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.1.4.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.6 Single Escape Character

+A single escape is used to indicate that the next character is to be treated as an alphabetic[2] character with its case preserved, no matter what the character is or which constituent traits it has.

+Backslash is a single escape character in standard syntax.

+ + +

+2.1.4.6.1 Examples of Single Escape Characters

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adfa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adfa.htm new file mode 100644 index 00000000..8cb048af --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adfa.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 2.1.4.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.6.1 Examples of Single Escape Characters

+

+ ;; The following examples assume the readtable case of *readtable* 
+ ;; and *print-case* are both :upcase.
+ (eq 'abc '\A\B\C) =>  true
+ (eq 'abc 'a\Bc) =>  true
+ (eq 'abc '\ABC) =>  true
+ (eq 'abc '\abc) =>  false
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adg.htm new file mode 100644 index 00000000..858d8235 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adg.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.1.4.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.7 Whitespace Characters

+Whitespace[2] characters are used to separate tokens.

+Space and newline are whitespace[2] characters in standard syntax.

+ + +

+2.1.4.7.1 Examples of Whitespace Characters

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adga.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adga.htm new file mode 100644 index 00000000..8b0a9843 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_adga.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 2.1.4.7.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.1.4.7.1 Examples of Whitespace Characters

+

+ (length '(this-that)) =>  1
+ (length '(this - that)) =>  3
+ (length '(a
+           b)) =>  2
+ (+ 34) =>  34
+ (+ 3 4) =>  7
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_b.htm new file mode 100644 index 00000000..31f1c643 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_b.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.2 Reader Algorithm

+This section describes the algorithm used by the Lisp reader to parse objects from an input character stream, including how the Lisp reader processes macro characters.

+When dealing with tokens, the reader's basic function is to distinguish representations of symbols from those of numbers. When a token is accumulated, it is assumed to represent a number if it satisfies the syntax for numbers listed in Figure 2-9. If it does not represent a number, it is then assumed to be a potential number if it satisfies the rules governing the syntax for a potential number. If a valid token is neither a representation of a number nor a potential number, it represents a symbol.

+The algorithm performed by the Lisp reader is as follows:

+

1. If at end of file, end-of-file processing is performed as specified in read. Otherwise, one character, x, is read from the input stream, and dispatched according to the syntax type of x to one of steps 2 to 7.

+
2. If x is an invalid character, an error of type reader-error is signaled.

+
3. If x is a whitespace[2] character, then it is discarded and step 1 is re-entered.

+
4. If x is a terminating or non-terminating macro character then its associated reader macro function is called with two arguments, the input stream and x.

+The reader macro function may read characters from the input stream; if it does, it will see those characters following the macro character. The Lisp reader may be invoked recursively from the reader macro function.

+The reader macro function must not have any side effects other than on the input stream; because of backtracking and restarting of the read operation, front ends to the Lisp reader (e.g., ``editors'' and ``rubout handlers'') may cause the reader macro function to be called repeatedly during the reading of a single expression in which x only appears once.

+The reader macro function may return zero values or one value. If one value is returned, then that value is returned as the result of the read operation; the algorithm is done. If zero values are returned, then step 1 is re-entered.

+

5. If x is a single escape character then the next character, y, is read, or an error of type end-of-file is signaled if at the end of file. y is treated as if it is a constituent whose only constituent trait is alphabetic[2]. y is used to begin a token, and step 8 is entered.

+
6. If x is a multiple escape character then a token (initially containing no characters) is begun and step 9 is entered.

+
7. If x is a constituent character, then it begins a token. After the token is read in, it will be interpreted either as a Lisp object or as being of invalid syntax. If the token represents an object, that object is returned as the result of the read operation. If the token is of invalid syntax, an error is signaled. If x is a character with case, it might be replaced with the corresponding character of the opposite case, depending on the readtable case of the current readtable, as outlined in Section 23.1.2 (Effect of Readtable Case on the Lisp Reader). X is used to begin a token, and step 8 is entered.

+
8. At this point a token is being accumulated, and an even number of multiple escape characters have been encountered. If at end of file, step 10 is entered. Otherwise, a character, y, is read, and one of the following actions is performed according to its syntax type:

+

* If y is a constituent or non-terminating macro character:

-- If y is a character with case, it might be replaced with the corresponding character of the opposite case, depending on the readtable case of the current readtable, as outlined in Section 23.1.2 (Effect of Readtable Case on the Lisp Reader).
-- Y is appended to the token being built.
-- Step 8 is repeated.

+

* If y is a single escape character, then the next character, z, is read, or an error of type end-of-file is signaled if at end of file. Z is treated as if it is a constituent whose only constituent trait is alphabetic[2]. Z is appended to the token being built, and step 8 is repeated.

+
* If y is a multiple escape character, then step 9 is entered.

+
* If y is an invalid character, an error of type reader-error is signaled.

+
* If y is a terminating macro character, then it terminates the token. First the character y is unread (see unread-char), and then step 10 is entered.

+
* If y is a whitespace[2] character, then it terminates the token. First the character y is unread if appropriate (see read-preserving-whitespace), and then step 10 is entered.

+

9. At this point a token is being accumulated, and an odd number of multiple escape characters have been encountered. If at end of file, an error of type end-of-file is signaled. Otherwise, a character, y, is read, and one of the following actions is performed according to its syntax type:

+

* If y is a constituent, macro, or whitespace[2] character, y is treated as a constituent whose only constituent trait is alphabetic[2]. Y is appended to the token being built, and step 9 is repeated.

+
* If y is a single escape character, then the next character, z, is read, or an error of type end-of-file is signaled if at end of file. Z is treated as a constituent whose only constituent trait is alphabetic[2]. Z is appended to the token being built, and step 9 is repeated.

+
* If y is a multiple escape character, then step 8 is entered.

+
* If y is an invalid character, an error of type reader-error is signaled.

+

10. An entire token has been accumulated. The object represented by the token is returned as the result of the read operation, or an error of type reader-error is signaled if the token is not of valid syntax.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_c.htm new file mode 100644 index 00000000..994e2200 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_c.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3 Interpretation of Tokens

+ + +

+2.3.1 Numbers as Tokens

+ +

+2.3.2 Constructing Numbers from Tokens

+ +

+2.3.3 The Consing Dot

+ +

+2.3.4 Symbols as Tokens

+ +

+2.3.5 Valid Patterns for Tokens

+ +

+2.3.6 Package System Consistency Rules

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ca.htm new file mode 100644 index 00000000..06c442cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ca.htm @@ -0,0 +1,68 @@ + + + +CLHS: Section 2.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.1 Numbers as Tokens

+When a token is read, it is interpreted as a number or symbol. The token is interpreted as a number if it satisfies the syntax for numbers specified in the next figure.

+ 

+numeric-token  ::=  integer |
+				   ratio   |
+				   float       
+integer        ::=  [sign]
+				   decimal-digit+
+				   decimal-point |
+				   [sign]
+				   digit+      
+ratio          ::=  [sign]
+				   {digit}+
+				   slash
+				   {digit}+    
+float          ::=  [sign]
+				   {decimal-digit}*
+				   decimal-point
+				   {decimal-digit}+
+				   [exponent]  
+                    | 
+				   [sign]
+				   {decimal-digit}+
+				   [decimal-point
+					   {decimal-digit}*]
+				   exponent    
+exponent       ::=  exponent-marker
+				   [sign]
+				   {digit}+    
+                                       
+sign---a sign.                         
+slash---a slash                        
+decimal-point---a dot.                        
+exponent-marker---an exponent marker.                        
+decimal-digit---a digit in radix 10.                        
+digit---a digit in the current input radix.                        
+
+

Figure 2-9. Syntax for Numeric Tokens

+ + +

+2.3.1.1 Potential Numbers as Tokens

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caa.htm new file mode 100644 index 00000000..efcaf9f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caa.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 2.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.1.1 Potential Numbers as Tokens

+To allow implementors and future Common Lisp standards to extend the syntax of numbers, a syntax for potential numbers is defined that is more general than the syntax for numbers. A token is a potential number if it satisfies all of the following requirements:

+

1. The token consists entirely of digits, signs, ratio markers, decimal points (.), extension characters (^ or _), and number markers. A number marker is a letter. Whether a letter may be treated as a number marker depends on context, but no letter that is adjacent to another letter may ever be treated as a number marker. Exponent markers are number markers.

+
2. The token contains at least one digit. Letters may be considered to be digits, depending on the current input base, but only in tokens containing no decimal points.

+
3. The token begins with a digit, sign, decimal point, or extension character, but not a package marker. The syntax involving a leading package marker followed by a potential number is not well-defined. The consequences of the use of notation such as :1, :1/2, and :2^3 in a position where an expression appropriate for read is expected are unspecified.

+
4. The token does not end with a sign.

+If a potential number has number syntax, a number of the appropriate type is constructed and returned, if the number is representable in an implementation. A number will not be representable in an implementation if it is outside the boundaries set by the implementation-dependent constants for numbers. For example, specifying too large or too small an exponent for a float may make the number impossible to represent in the implementation. A ratio with denominator zero (such as -35/000) is not represented in any implementation. When a token with the syntax of a number cannot be converted to an internal number, an error of type reader-error is signaled. An error must not be signaled for specifying too many significant digits for a float; a truncated or rounded value should be produced.

+If there is an ambiguity as to whether a letter should be treated as a digit or as a number marker, the letter is treated as a digit.

+ + +

+2.3.1.1.1 Escape Characters and Potential Numbers

+ +

+2.3.1.1.2 Examples of Potential Numbers

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caaa.htm new file mode 100644 index 00000000..f2bfa9a2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caaa.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.3.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.1.1.1 Escape Characters and Potential Numbers

+A potential number cannot contain any escape characters. An escape character robs the following character of all syntactic qualities, forcing it to be strictly alphabetic[2] and therefore unsuitable for use in a potential number. For example, all of the following representations are interpreted as symbols, not numbers:

+

+ \256   25\64   1.0\E6   |100|   3\.14159   |3/4|   3\/4   5||
+
+

+In each case, removing the escape character (or characters) would cause the token to be a potential number.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caab.htm new file mode 100644 index 00000000..a86db53f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_caab.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 2.3.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.1.1.2 Examples of Potential Numbers

+As examples, the tokens in the next figure are potential numbers, but they are not actually numbers, and so are reserved tokens; a conforming implementation is permitted, but not required, to define their meaning.

+

+1b5000                       777777q                1.7J  -3/4+6.7J  12/25/83  
+27^19                        3^4/5                  6//7  3.1.2.6    ^-43^     
+3.141_592_653_589_793_238_4  -3.7+2.6i-6.17j+19.6k  
+
+

Figure 2-10. Examples of reserved tokens

+The tokens in the next figure are not potential numbers; they are always treated as symbols:

+

+/     /5     +  1+  1-   
+foo+  ab.cd  _  ^   ^/-  
+
+

Figure 2-11. Examples of symbols

+The tokens in the next figure are potential numbers if the current input base is 16, but they are always treated as symbols if the current input base is 10.

+

+bad-face  25-dec-83  a/b  fad_cafe  f^  
+
+

Figure 2-12. Examples of symbols or potential numbers

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cb.htm new file mode 100644 index 00000000..a898c775 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cb.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 2.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.2 Constructing Numbers from Tokens

+A real is constructed directly from a corresponding numeric token; see Figure 2-9.

+A complex is notated as a #C (or #c) followed by a list of two reals; see Section 2.4.8.11 (Sharpsign C).

+The reader macros #B, #O, #X, and #R may also be useful in controlling the input radix in which rationals are parsed; see Section 2.4.8.7 (Sharpsign B), Section 2.4.8.8 (Sharpsign O), Section 2.4.8.9 (Sharpsign X), and Section 2.4.8.10 (Sharpsign R).

+This section summarizes the full syntax for numbers.

+ + +

+2.3.2.1 Syntax of a Rational

+ +

+2.3.2.2 Syntax of a Float

+ + +

+2.3.2.3 Syntax of a Complex

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cba.htm new file mode 100644 index 00000000..63948090 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cba.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.3.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.2.1 Syntax of a Rational

+ + +

+2.3.2.1.1 Syntax of an Integer

+ +

+2.3.2.1.2 Syntax of a Ratio

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbaa.htm new file mode 100644 index 00000000..70c22242 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 2.3.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.2.1.1 Syntax of an Integer

+Integers can be written as a sequence of digits, optionally preceded by a sign and optionally followed by a decimal point; see Figure 2-9. When a decimal point is used, the digits are taken to be in radix 10; when no decimal point is used, the digits are taken to be in radix given by the current input base.

+For information on how integers are printed, see Section 22.1.3.1.1 (Printing Integers).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbab.htm new file mode 100644 index 00000000..aa5827d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbab.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 2.3.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.2.1.2 Syntax of a Ratio

+Ratios can be written as an optional sign followed by two non-empty sequences of digits separated by a slash; see Figure 2-9. The second sequence may not consist entirely of zeros. Examples of ratios are in the next figure.

+

+2/3                 ;This is in canonical form                  
+4/6                 ;A non-canonical form for 2/3               
+-17/23              ;A ratio preceded by a sign                 
+-30517578125/32768  ;This is (-5/2)^15                          
+10/5                ;The canonical form for this is 2           
+#o-101/75           ;Octal notation for -65/61                  
+#3r120/21           ;Ternary notation for 15/7                  
+#Xbc/ad             ;Hexadecimal notation for 188/173           
+#xFADED/FACADE      ;Hexadecimal notation for 1027565/16435934  
+
+

Figure 2-13. Examples of Ratios

+

+For information on how ratios are printed, see Section 22.1.3.1.2 (Printing Ratios).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbb.htm new file mode 100644 index 00000000..0c95d77c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbb.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 2.3.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.2.2 Syntax of a Float

+Floats can be written in either decimal fraction or computerized scientific notation: an optional sign, then a non-empty sequence of digits with an embedded decimal point, then an optional decimal exponent specification. If there is no exponent specifier, then the decimal point is required, and there must be digits after it. The exponent specifier consists of an exponent marker, an optional sign, and a non-empty sequence of digits. If no exponent specifier is present, or if the exponent marker e (or E) is used, then the format specified by *read-default-float-format* is used. See Figure 2-9.

+An implementation may provide one or more kinds of float that collectively make up the type float. The letters s, f, d, and l (or their respective uppercase equivalents) explicitly specify the use of the types short-float, single-float, double-float, and long-float, respectively.

+The internal format used for an external representation depends only on the exponent marker, and not on the number of decimal digits in the external representation.

+The next figure contains examples of notations for floats:

+

+0.0       ;Floating-point zero in default format                          
+0E0       ;As input, this is also floating-point zero in default format.  
+          ;As output, this would appear as 0.0.                           
+0e0       ;As input, this is also floating-point zero in default format.  
+          ;As output, this would appear as 0.0.                           
+-.0       ;As input, this might be a zero or a minus zero,                
+          ; depending on whether the implementation supports              
+          ; a distinct minus zero.                                        
+          ;As output, 0.0 is zero and -0.0 is minus zero.                 
+0.        ;On input, the integer zero---not a floating-point number!      
+          ;Whether this appears as 0 or 0. on output depends              
+          ;on the value of *print-radix*.                                 
+0.0s0     ;A floating-point zero in short format                          
+0s0       ;As input, this is a floating-point zero in short format.       
+          ;As output, such a zero would appear as 0.0s0                   
+          ; (or as 0.0 if short-float was the default format).            
+6.02E+23  ;Avogadro's number, in default format                           
+602E+21   ;Also Avogadro's number, in default format                      
+
+

Figure 2-14. Examples of Floating-point numbers

+For information on how floats are printed, see Section 22.1.3.1.3 (Printing Floats).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbc.htm new file mode 100644 index 00000000..315a4822 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cbc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 2.3.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.2.3 Syntax of a Complex

+A complex has a Cartesian structure, with a real part and an imaginary part each of which is a real. The parts of a complex are not necessarily floats but both parts must be of the same type: either both are rationals, or both are of the same float subtype. When constructing a complex, if the specified parts are not the same type, the parts are converted to be the same type internally (i.e., the rational part is converted to a float). An object of type (complex rational) is converted internally and represented thereafter as a rational if its imaginary part is an integer whose value is 0.

+For further information, see Section 2.4.8.11 (Sharpsign C) and Section 22.1.3.1.4 (Printing Complexes).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cc.htm new file mode 100644 index 00000000..c49f8507 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.3 The Consing Dot

+If a token consists solely of dots (with no escape characters), then an error of type reader-error is signaled, except in one circumstance: if the token is a single dot and appears in a situation where dotted pair notation permits a dot, then it is accepted as part of such syntax and no error is signaled. See Section 2.4.1 (Left-Parenthesis).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cd.htm new file mode 100644 index 00000000..0f78296d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cd.htm @@ -0,0 +1,70 @@ + + + +CLHS: Section 2.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.4 Symbols as Tokens

+Any token that is not a potential number, does not contain a package marker, and does not consist entirely of dots will always be interpreted as a symbol. Any token that is a potential number but does not fit the number syntax is a reserved token and has an implementation-dependent interpretation. In all other cases, the token is construed to be the name of a symbol.

+Examples of the printed representation of symbols are in the next figure. For presentational simplicity, these examples assume that the readtable case of the current readtable is :upcase.

+

+FROBBOZ         The symbol whose name is FROBBOZ.                
+frobboz         Another way to notate the same symbol.           
+fRObBoz         Yet another way to notate it.                    
+unwind-protect  A symbol with a hyphen in its name.              
++$              The symbol named +$.                             
+1+              The symbol named 1+.                             
++1              This is the integer 1, not a symbol.             
+pascal_style    This symbol has an underscore in its name.       
+file.rel.43     This symbol has periods in its name.             
+\(              The symbol whose name is (.                      
+\+1             The symbol whose name is +1.                     
++\1             Also the symbol whose name is +1.                
+\frobboz        The symbol whose name is fROBBOZ.                
+3.14159265\s0   The symbol whose name is 3.14159265s0.           
+3.14159265\S0   A different symbol, whose name is 3.14159265S0.  
+3.14159265s0    A possible short float approximation to <PI>.    
+
+

Figure 2-15. Examples of the printed representation of symbols (Part 1 of 2)

+

+APL\\360            The symbol whose name is APL\360.       
+apl\\360            Also the symbol whose name is APL\360.  
+\(b^2\)\-\4*a*c     The name is (B^2) - 4*A*C.              
+                    Parentheses and two spaces in it.       
+\(\b^2\)\-\4*\a*\c  The name is (b^2) - 4*a*c.              
+                    Letters explicitly lowercase.           
+|"|                 The same as writing \".                 
+|(b^2) - 4*a*c|     The name is (b^2) - 4*a*c.              
+|frobboz|           The name is frobboz, not FROBBOZ.       
+|APL\360|           The name is APL360.                     
+|APL\\360|          The name is APL\360.                    
+|apl\\360|          The name is apl\360.                    
+|\|\||              Same as \|\| ---the name is ||.         
+|(B^2) - 4*A*C|     The name is (B^2) - 4*A*C.              
+                    Parentheses and two spaces in it.       
+|(b^2) - 4*a*c|     The name is (b^2) - 4*a*c.              
+
+

Figure 2-16. Examples of the printed representation of symbols (Part 2 of 2)

+ In the process of parsing a symbol, it is implementation-dependent which implementation-defined attributes are removed from the characters forming a token that represents a symbol.

+When parsing the syntax for a symbol, the Lisp reader looks up the name of that symbol in the current package. This lookup may involve looking in other packages whose external symbols are inherited by the current package. If the name is found, the corresponding symbol is returned. If the name is not found (that is, there is no symbol of that name accessible in the current package), a new symbol is created and is placed in the current package as an internal symbol. The current package becomes the owner (home package) of the symbol, and the symbol becomes interned in the current package. If the name is later read again while this same package is current, the same symbol will be found and returned.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ce.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ce.htm new file mode 100644 index 00000000..4d49d4aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ce.htm @@ -0,0 +1,55 @@ + + + +CLHS: Section 2.3.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.5 Valid Patterns for Tokens

+The valid patterns for tokens are summarized in the next figure.

+

+nnnnn              a number                                           
+xxxxx              a symbol in the current package                    
+:xxxxx             a symbol in the the KEYWORD package                
+ppppp:xxxxx        an external symbol in the ppppp package            
+ppppp::xxxxx       a (possibly internal) symbol in the ppppp package  
+:nnnnn             undefined                                          
+ppppp:nnnnn        undefined                                          
+ppppp::nnnnn       undefined                                          
+::aaaaa            undefined                                          
+aaaaa:             undefined                                          
+aaaaa:aaaaa:aaaaa  undefined                                          
+
+

Figure 2-17. Valid patterns for tokens

+Note that nnnnn has number syntax, neither xxxxx nor ppppp has number syntax, and aaaaa has any syntax.

+A summary of rules concerning package markers follows. In each case, examples are offered to illustrate the case; for presentational simplicity, the examples assume that the readtable case of the current readtable is :upcase.

+

1. If there is a single package marker, and it occurs at the beginning of the token, then the token is interpreted as a symbol in the KEYWORD package. It also sets the symbol-value of the newly-created symbol to that same symbol so that the symbol will self-evaluate.

+For example, :bar, when read, interns BAR as an external symbol in the KEYWORD package.

+

2. If there is a single package marker not at the beginning or end of the token, then it divides the token into two parts. The first part specifies a package; the second part is the name of an external symbol available in that package.

+For example, foo:bar, when read, looks up BAR among the external symbols of the package named FOO.

+

3. If there are two adjacent package markers not at the beginning or end of the token, then they divide the token into two parts. The first part specifies a package; the second part is the name of a symbol within that package (possibly an internal symbol).

+For example, foo::bar, when read, interns BAR in the package named FOO.

+

4. If the token contains no package markers, and does not have potential number syntax, then the entire token is the name of the symbol. The symbol is looked up in the current package.

+For example, bar, when read, interns BAR in the current package.

+

5. The consequences are unspecified if any other pattern of package markers in a token is used. All other uses of package markers within names of symbols are not defined by this standard but are reserved for implementation-dependent use.

+For example, assuming the readtable case of the current readtable is :upcase, editor:buffer refers to the external symbol named BUFFER present in the package named editor, regardless of whether there is a symbol named BUFFER in the current package. If there is no package named editor, or if no symbol named BUFFER is present in editor, or if BUFFER is not exported by editor, the reader signals a correctable error. If editor::buffer is seen, the effect is exactly the same as reading buffer with the EDITOR package being the current package.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cf.htm new file mode 100644 index 00000000..a051acde --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_cf.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 2.3.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.3.6 Package System Consistency Rules

+The following rules apply to the package system as long as the value of *package* is not changed:

+

Read-read consistency

+Reading the same symbol name always results in the same symbol.

+

Print-read consistency

+An interned symbol always prints as a sequence of characters that, when read back in, yields the same symbol.

+For information about how the Lisp printer treats symbols, see Section 22.1.3.3 (Printing Symbols).

+

Print-print consistency

+If two interned symbols are not the same, then their printed representations will be different sequences of characters.

+These rules are true regardless of any implicit interning. As long as the current package is not changed, results are reproducible regardless of the order of loading files or the exact history of what symbols were typed in when. If the value of *package* is changed and then changed back to the previous value, consistency is maintained. The rules can be violated by changing the value of *package*, forcing a change to symbols or to packages or to both by continuing from an error, or calling one of the following functions: unintern, unexport, shadow, shadowing-import, or unuse-package.

+An inconsistency only applies if one of the restrictions is violated between two of the named symbols. shadow, unexport, unintern, and shadowing-import can only affect the consistency of symbols with the same names (under string=) as the ones supplied as arguments.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_d.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_d.htm new file mode 100644 index 00000000..ddf2d5c0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_d.htm @@ -0,0 +1,57 @@ + + + +CLHS: Section 2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4 Standard Macro Characters

+If the reader encounters a macro character, then its associated reader macro function is invoked and may produce an object to be returned. This function may read the characters following the macro character in the stream in any syntax and return the object represented by that syntax.

+Any character can be made to be a macro character. The macro characters defined initially in a conforming implementation include the following:

+ + +

+2.4.1 Left-Parenthesis

+ +

+2.4.2 Right-Parenthesis

+ +

+2.4.3 Single-Quote

+ +

+2.4.4 Semicolon

+ +

+2.4.5 Double-Quote

+ +

+2.4.6 Backquote

+ +

+2.4.7 Comma

+ +

+2.4.8 Sharpsign

+ +

+2.4.9 Re-Reading Abbreviated Expressions

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_da.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_da.htm new file mode 100644 index 00000000..4a6d71d4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_da.htm @@ -0,0 +1,52 @@ + + + +CLHS: Section 2.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.1 Left-Parenthesis

+The left-parenthesis initiates reading of a list. read is called recursively to read successive objects until a right parenthesis is found in the input stream. A list of the objects read is returned. Thus

+

+ (a b c)
+
+ is read as a list of three objects (the symbols a, b, and c). The right parenthesis need not immediately follow the printed representation of the last object; whitespace[2] characters and comments may precede it.

+If no objects precede the right parenthesis, it reads as a list of zero objects (the empty list).

+If a token that is just a dot not immediately preceded by an escape character is read after some object then exactly one more object must follow the dot, possibly preceded or followed by whitespace[2] or a comment, followed by the right parenthesis:

+

+ (a b c . d)
+
+ This means that the cdr of the last cons in the list is not nil, but rather the object whose representation followed the dot. The above example might have been the result of evaluating

+

+ (cons 'a (cons 'b (cons 'c 'd)))
+
+ Similarly,

+

+ (cons 'this-one 'that-one) =>  (this-one . that-one)
+
+ It is permissible for the object following the dot to be a list:

+

+ (a b c d . (e f . (g))) ==  (a b c d e f g)
+
+

+For information on how the Lisp printer prints lists and conses, see Section 22.1.3.5 (Printing Lists and Conses).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_db.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_db.htm new file mode 100644 index 00000000..f520a94b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_db.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.2 Right-Parenthesis

+The right-parenthesis is invalid except when used in conjunction with the left parenthesis character. For more information, see Section 2.2 (Reader Algorithm).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dc.htm new file mode 100644 index 00000000..e4135de9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dc.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.3 Single-Quote

+Syntax: '<<exp>>

+A single-quote introduces an expression to be ``quoted.'' Single-quote followed by an expression exp is treated by the Lisp reader as an abbreviation for and is parsed identically to the expression (quote exp). See the special operator quote.

+ + +

+2.4.3.1 Examples of Single-Quote

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dca.htm new file mode 100644 index 00000000..f01bc7b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dca.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.4.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.3.1 Examples of Single-Quote

+

+ 'foo =>  FOO
+ ''foo =>  (QUOTE FOO)
+ (car ''foo) =>  QUOTE
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dd.htm new file mode 100644 index 00000000..34a2f83f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dd.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 2.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4 Semicolon

+Syntax: ;<<text>>

+A semicolon introduces characters that are to be ignored, such as comments. The semicolon and all characters up to and including the next newline or end of file are ignored.

+ + +

+2.4.4.1 Examples of Semicolon

+ +

+2.4.4.2 Notes about Style for Semicolon

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dda.htm new file mode 100644 index 00000000..6d5a2f0b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dda.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.4.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.1 Examples of Semicolon

+

+ (+ 3 ; three
+    4)
+=>  7    
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddb.htm new file mode 100644 index 00000000..46b8ea52 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddb.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 2.4.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.2 Notes about Style for Semicolon

+Some text editors make assumptions about desired indentation based on the number of semicolons that begin a comment. The following style conventions are common, although not by any means universal.

+ + +

+2.4.4.2.1 Use of Single Semicolon

+ +

+2.4.4.2.2 Use of Double Semicolon

+ +

+2.4.4.2.3 Use of Triple Semicolon

+ + +

+2.4.4.2.4 Use of Quadruple Semicolon

+ +

+2.4.4.2.5 Examples of Style for Semicolon

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddba.htm new file mode 100644 index 00000000..e93b7152 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.4.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.2.1 Use of Single Semicolon

+Comments that begin with a single semicolon are all aligned to the same column at the right (sometimes called the ``comment column''). The text of such a comment generally applies only to the line on which it appears. Occasionally two or three contain a single sentence together; this is sometimes indicated by indenting all but the first with an additional space (after the semicolon).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbb.htm new file mode 100644 index 00000000..8c272996 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.4.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.2.2 Use of Double Semicolon

+Comments that begin with a double semicolon are all aligned to the same level of indentation as a form would be at that same position in the code. The text of such a comment usually describes the state of the program at the point where the comment occurs, the code which follows the comment, or both.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbc.htm new file mode 100644 index 00000000..feb04428 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.4.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.2.3 Use of Triple Semicolon

+Comments that begin with a triple semicolon are all aligned to the left margin. Usually they are used prior to a definition or set of definitions, rather than within a definition.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbd.htm new file mode 100644 index 00000000..23ab446d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.4.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.2.4 Use of Quadruple Semicolon

+Comments that begin with a quadruple semicolon are all aligned to the left margin, and generally contain only a short piece of text that serve as a title for the code which follows, and might be used in the header or footer of a program that prepares code for presentation as a hardcopy document.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbe.htm new file mode 100644 index 00000000..15f289d2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_ddbe.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 2.4.4.2.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.4.2.5 Examples of Style for Semicolon

+

+;;;; Math Utilities
+
+;;; FIB computes the the Fibonacci function in the traditional
+;;; recursive way.
+
+(defun fib (n)
+  (check-type n integer)
+  ;; At this point we're sure we have an integer argument.
+  ;; Now we can get down to some serious computation.
+  (cond ((< n 0)
+         ;; Hey, this is just supposed to be a simple example.
+         ;; Did you really expect me to handle the general case?
+         (error "FIB got ~D as an argument." n))
+        ((< n 2) n)             ;fib[0]=0 and fib[1]=1
+        ;; The cheap cases didn't work.
+        ;; Nothing more to do but recurse.
+        (t (+ (fib (- n 1))     ;The traditional formula
+              (fib (- n 2)))))) ; is fib[n-1]+fib[n-2].
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_de.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_de.htm new file mode 100644 index 00000000..0a5fa2d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_de.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 2.4.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.5 Double-Quote

+Syntax: "<<text>>"

+The double-quote is used to begin and end a string. When a double-quote is encountered, characters are read from the input stream and accumulated until another double-quote is encountered. If a single escape character is seen, the single escape character is discarded, the next character is accumulated, and accumulation continues. The accumulated characters up to but not including the matching double-quote are made into a simple string and returned. It is implementation-dependent which attributes of the accumulated characters are removed in this process.

+Examples of the use of the double-quote character are in the next figure.

+

+"Foo"                      ;A string with three characters in it  
+""                         ;An empty string                       
+"\"APL\\360?\" he cried."  ;A string with twenty characters       
+"|x| = |-x|"               ;A ten-character string                
+
+

Figure 2-18. Examples of the use of double-quote

+Note that to place a single escape character or a double-quote into a string, such a character must be preceded by a single escape character. Note, too, that a multiple escape character need not be quoted by a single escape character within a string.

+For information on how the Lisp printer prints strings, see Section 22.1.3.4 (Printing Strings).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_df.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_df.htm new file mode 100644 index 00000000..8c6f9eb3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_df.htm @@ -0,0 +1,87 @@ + + + +CLHS: Section 2.4.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.6 Backquote

+The backquote introduces a template of a data structure to be built. For example, writing

+

+ `(cond ((numberp ,x) ,@y) (t (print ,x) ,@y))
+
+ is roughly equivalent to writing

+

+ (list 'cond 
+       (cons (list 'numberp x) y) 
+       (list* 't (list 'print x) y))
+
+ Where a comma occurs in the template, the expression following the comma is to be evaluated to produce an object to be inserted at that point. Assume b has the value 3, for example, then evaluating the form denoted by `(a b ,b ,(+ b 1) b) produces the result (a b 3 4 b).

+If a comma is immediately followed by an at-sign, then the form following the at-sign is evaluated to produce a list of objects. These objects are then ``spliced'' into place in the template. For example, if x has the value (a b c), then

+

+ `(x ,x ,@x foo ,(cadr x) bar ,(cdr x) baz ,@(cdr x))
+=>  (x (a b c) a b c foo b bar (b c) baz b c)
+
+ The backquote syntax can be summarized formally as follows.

+

* `basic is the same as 'basic, that is, (quote basic), for any expression basic that is not a list or a general vector.

+
* `,form is the same as form, for any form, provided that the representation of form does not begin with at-sign or dot. (A similar caveat holds for all occurrences of a form after a comma.)

+
* `,@form has undefined consequences.

+
* `(x1 x2 x3 ... xn . atom) may be interpreted to mean

+
+ (append [ x1] [ x2] [ x3] ... [ xn] (quote atom))
+
+ where the brackets are used to indicate a transformation of an xj as follows:

+

-- [form] is interpreted as (list `form), which contains a backquoted form that must then be further interpreted.

+
-- [,form] is interpreted as (list form).

+
-- [,@form] is interpreted as form.

+

* `(x1 x2 x3 ... xn) may be interpreted to mean the same as the backquoted form `(x1 x2 x3 ... xn . nil), thereby reducing it to the previous case.

+
* `(x1 x2 x3 ... xn . ,form) may be interpreted to mean

+
+ (append [ x1] [ x2] [ x3] ... [ xn] form)
+
+ where the brackets indicate a transformation of an xj as described above.

+

* `(x1 x2 x3 ... xn . ,@form) has undefined consequences.

+
* `#(x1 x2 x3 ... xn) may be interpreted to mean (apply #'vector `(x1 x2 x3 ... xn)).

+Anywhere ``,@'' may be used, the syntax ``,.'' may be used instead to indicate that it is permissible to operate destructively on the list structure produced by the form following the ``,.'' (in effect, to use nconc instead of append).

+If the backquote syntax is nested, the innermost backquoted form should be expanded first. This means that if several commas occur in a row, the leftmost one belongs to the innermost backquote.

+An implementation is free to interpret a backquoted form F1 as any form F2 that, when evaluated, will produce a result that is the same under equal as the result implied by the above definition, provided that the side-effect behavior of the substitute form F2 is also consistent with the description given above. The constructed copy of the template might or might not share list structure with the template itself. As an example, the above definition implies that

+

+ `((,a b) ,c ,@d)
+
+ will be interpreted as if it were

+

+ (append (list (append (list a) (list 'b) 'nil)) (list c) d 'nil)
+
+ but it could also be legitimately interpreted to mean any of the following:

+

+ (append (list (append (list a) (list 'b))) (list c) d)
+ (append (list (append (list a) '(b))) (list c) d)
+ (list* (cons a '(b)) c d)
+ (list* (cons a (list 'b)) c d)
+ (append (list (cons a '(b))) (list c) d)
+ (list* (cons a '(b)) c (copy-list d))
+
+

+ + +

+2.4.6.1 Notes about Backquote

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dfa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dfa.htm new file mode 100644 index 00000000..b9820117 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dfa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 2.4.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.6.1 Notes about Backquote

+Since the exact manner in which the Lisp reader will parse an expression involving the backquote reader macro is not specified, an implementation is free to choose any representation that preserves the semantics described.

+Often an implementation will choose a representation that facilitates pretty printing of the expression, so that (pprint `(a ,b)) will display `(a ,b) and not, for example, (list 'a b). However, this is not a requirement.

+Implementors who have no particular reason to make one choice or another might wish to refer to IEEE Standard for the Scheme Programming Language, which identifies a popular choice of representation for such expressions that might provide useful to be useful compatibility for some user communities. There is no requirement, however, that any conforming implementation use this particular representation. This information is provided merely for cross-reference purposes.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dg.htm new file mode 100644 index 00000000..08872486 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dg.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.7 Comma

+ The comma is part of the backquote syntax; see Section 2.4.6 (Backquote). Comma is invalid if used other than inside the body of a backquote expression as described above.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dh.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dh.htm new file mode 100644 index 00000000..e5f415f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dh.htm @@ -0,0 +1,138 @@ + + + +CLHS: Section 2.4.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8 Sharpsign

+Sharpsign is a non-terminating dispatching macro character. It reads an optional sequence of digits and then one more character, and uses that character to select a function to run as a reader macro function.

+The standard syntax includes constructs introduced by the # character. The syntax of these constructs is as follows: a character that identifies the type of construct is followed by arguments in some form. If the character is a letter, its case is not important; #O and #o are considered to be equivalent, for example.

+Certain # constructs allow an unsigned decimal number to appear between the # and the character.

+The reader macros associated with the dispatching macro character # are described later in this section and summarized in the next figure.

+ 

+dispatch char  purpose                  dispatch char  purpose                
+Backspace      signals error            {              undefined*             
+Tab            signals error            }              undefined*             
+Newline        signals error            +              read-time conditional  
+Linefeed       signals error            -              read-time conditional  
+Page           signals error            .              read-time evaluation   
+Return         signals error            /              undefined              
+Space          signals error            A, a           array                  
+!              undefined*               B, b           binary rational        
+"              undefined                C, c           complex number         
+#              reference to = label     D, d           undefined              
+$              undefined                E, e           undefined              
+%              undefined                F, f           undefined              
+&              undefined                G, g           undefined              
+'              function abbreviation    H, h           undefined              
+(              simple vector            I, i           undefined              
+)              signals error            J, j           undefined              
+*              bit vector               K, k           undefined              
+,              undefined                L, l           undefined              
+:              uninterned symbol        M, m           undefined              
+;              undefined                N, n           undefined              
+<              signals error            O, o           octal rational         
+=              labels following object  P, p           pathname               
+>              undefined                Q, q           undefined              
+?              undefined*               R, r           radix-n rational       
+@              undefined                S, s           structure              
+[              undefined*               T, t           undefined              
+\              character object         U, u           undefined              
+]              undefined*               V, v           undefined              
+^              undefined                W, w           undefined              
+_              undefined                X, x           hexadecimal rational   
+`              undefined                Y, y           undefined              
+|              balanced comment         Z, z           undefined              
+~              undefined                Rubout         undefined              
+
+

Figure 2-19. Standard #Dispatching Macro Character Syntax

+The combinations marked by an asterisk (*) are explicitly reserved to the user. No conforming implementation defines them.

+Note also that digits do not appear in the preceding table. This is because the notations #0, #1, ..., #9 are reserved for another purpose which occupies the same syntactic space. When a digit follows a sharpsign, it is not treated as a dispatch character. Instead, an unsigned integer argument is accumulated and passed as an argument to the reader macro for the character that follows the digits. For example, #2A((1 2) (3 4)) is a use of #A with an argument of 2.

+ + +

+2.4.8.1 Sharpsign Backslash

+ +

+2.4.8.2 Sharpsign Single-Quote

+ +

+2.4.8.3 Sharpsign Left-Parenthesis

+ +

+2.4.8.4 Sharpsign Asterisk

+ +

+2.4.8.5 Sharpsign Colon

+ +

+2.4.8.6 Sharpsign Dot

+ + +

+2.4.8.7 Sharpsign B

+ +

+2.4.8.8 Sharpsign O

+ +

+2.4.8.9 Sharpsign X

+ +

+2.4.8.10 Sharpsign R

+ +

+2.4.8.11 Sharpsign C

+ +

+2.4.8.12 Sharpsign A

+ +

+2.4.8.13 Sharpsign S

+ +

+2.4.8.14 Sharpsign P

+ +

+2.4.8.15 Sharpsign Equal-Sign

+ +

+2.4.8.16 Sharpsign Sharpsign

+ +

+2.4.8.17 Sharpsign Plus

+ +

+2.4.8.18 Sharpsign Minus

+ +

+2.4.8.19 Sharpsign Vertical-Bar

+ +

+2.4.8.20 Sharpsign Less-Than-Sign

+ +

+2.4.8.21 Sharpsign Whitespace

+ +

+2.4.8.22 Sharpsign Right-Parenthesis

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dha.htm new file mode 100644 index 00000000..62aeb4b6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dha.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.4.8.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.1 Sharpsign Backslash

+Syntax: #\<<x>>

+When the token x is a single character long, this parses as the literal character char. Uppercase and lowercase letters are distinguished after #\; #\A and #\a denote different character objects. Any single character works after #\, even those that are normally special to read, such as left-parenthesis and right-parenthesis.

+In the single character case, the x must be followed by a non-constituent character. After #\ is read, the reader backs up over the slash and then reads a token, treating the initial slash as a single escape character (whether it really is or not in the current readtable).

+When the token x is more than one character long, the x must have the syntax of a symbol with no embedded package markers. In this case, the sharpsign backslash notation parses as the character whose name is (string-upcase x); see Section 13.1.7 (Character Names).

+

+For information about how the Lisp printer prints character objects, see Section 22.1.3.2 (Printing Characters).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhb.htm new file mode 100644 index 00000000..10167f61 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhb.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.4.8.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.2 Sharpsign Single-Quote

+Any expression preceded by #' (sharpsign followed by single-quote), as in #'expression, is treated by the Lisp reader as an abbreviation for and parsed identically to the expression (function expression). See function. For example,

+

+(apply #'+ l) ==  (apply (function +) l)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhc.htm new file mode 100644 index 00000000..c62983ec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhc.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 2.4.8.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.3 Sharpsign Left-Parenthesis

+#( and ) are used to notate a simple vector.

+If an unsigned decimal integer appears between the # and (, it specifies explicitly the length of the vector. The consequences are undefined if the number of objects specified before the closing ) exceeds the unsigned decimal integer. If the number of objects supplied before the closing ) is less than the unsigned decimal integer but greater than zero, the last object is used to fill all remaining elements of the vector. The consequences are undefined if the unsigned decimal integer is non-zero and number of objects supplied before the closing ) is zero. For example,

+

+ #(a b c c c c)
+ #6(a b c c c c)
+ #6(a b c)
+ #6(a b c c)
+
+

+all mean the same thing: a vector of length 6 with elements a, b, and four occurrences of c. Other examples follow:

+

+ #(a b c)               ;A vector of length 3
+ #(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47)
+                        ;A vector containing the primes below 50
+ #()                    ;An empty vector
+
+ The notation #() denotes an empty vector, as does #0().

+For information on how the Lisp printer prints vectors, see Section 22.1.3.4 (Printing Strings), Section 22.1.3.6 (Printing Bit Vectors), or Section 22.1.3.7 (Printing Other Vectors).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhd.htm new file mode 100644 index 00000000..4f67eb14 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhd.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 2.4.8.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.4 Sharpsign Asterisk

+Syntax: #*<<bits>>

+A simple bit vector is constructed containing the indicated bits (0's and 1's), where the leftmost bit has index zero and the subsequent bits have increasing indices.

+Syntax: #<<n>>*<<bits>>

+With an argument n, the vector to be created is of length n. If the number of bits is less than n but greater than zero, the last bit is used to fill all remaining bits of the bit vector.

+The notations #* and #0* each denote an empty bit vector.

+ Regardless of whether the optional numeric argument n is provided, the token that follows the asterisk is delimited by a normal token delimiter. However, (unless the value of *read-suppress* is true) an error of type reader-error is signaled if that token is not composed entirely of 0's and 1's, or if n was supplied and the token is composed of more than n bits, or if n is greater than one, but no bits were specified. Neither a single escape nor a multiple escape is permitted in this token.

+For information on how the Lisp printer prints bit vectors, see Section 22.1.3.6 (Printing Bit Vectors).

+ + +

+2.4.8.4.1 Examples of Sharpsign Asterisk

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhda.htm new file mode 100644 index 00000000..31263233 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhda.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 2.4.8.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.4.1 Examples of Sharpsign Asterisk

+For example, +

+  #*101111
+ #6*101111
+ #6*101
+ #6*1011
+
+ all mean the same thing: a vector of length 6 with elements 1, 0, 1, 1, 1, and 1.

+For example:

+

+ #*         ;An empty bit-vector
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhe.htm new file mode 100644 index 00000000..27c6d0ec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhe.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 2.4.8.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.5 Sharpsign Colon

+Syntax: #:<<symbol-name>>

+#: introduces an uninterned symbol whose name is symbol-name. Every time this syntax is encountered, a distinct uninterned symbol is created. The symbol-name must have the syntax of a symbol with no package prefix.

+For information on how the Lisp reader prints uninterned symbols, see Section 22.1.3.3 (Printing Symbols).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhf.htm new file mode 100644 index 00000000..11d46c1b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhf.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 2.4.8.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.6 Sharpsign Dot

+#.foo is read as the object resulting from the evaluation of the object represented by foo. The evaluation is done during the read process, when the #. notation is encountered. The #. syntax therefore performs a read-time evaluation of foo.

+The normal effect of #. is inhibited when the value of *read-eval* is false. In that situation, an error of type reader-error is signaled.

+For an object that does not have a convenient printed representation, a form that computes the object can be given using the #. notation.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhg.htm new file mode 100644 index 00000000..c40f9618 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhg.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 2.4.8.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.7 Sharpsign B

+#Brational reads rational in binary (radix 2). For example,

+

+ #B1101 ==  13 ;11012
+ #b101/11 ==  5/3
+
+

+ The consequences are undefined if the token immediately following the #B does not have the syntax of a binary (i.e., radix 2) rational.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhh.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhh.htm new file mode 100644 index 00000000..c9e455aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhh.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 2.4.8.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.8 Sharpsign O

+#Orational reads rational in octal (radix 8). For example,

+

+ #o37/15 ==  31/13
+ #o777 ==  511
+ #o105 ==  69 ;1058
+
+

+ The consequences are undefined if the token immediately following the #O does not have the syntax of an octal (i.e., radix 8) rational.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhi.htm new file mode 100644 index 00000000..532588da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhi.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 2.4.8.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.9 Sharpsign X

+#Xrational reads rational in hexadecimal (radix 16). The digits above 9 are the letters A through F (the lowercase letters a through f are also acceptable). For example,

+

+ #xF00 ==  3840             
+ #x105 ==  261 ;10516
+
+

+ The consequences are undefined if the token immediately following the #X does not have the syntax of a hexadecimal (i.e., radix 16) rational.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhj.htm new file mode 100644 index 00000000..f9fcf1a2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhj.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 2.4.8.10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.10 Sharpsign R

+#nR

+#radixRrational reads rational in radix radix. radix must consist of only digits that are interpreted as an integer in decimal radix; its value must be between 2 and 36 (inclusive). Only valid digits for the specified radix may be used.

+For example, #3r102 is another way of writing 11 (decimal), and #11R32 is another way of writing 35 (decimal). For radices larger than 10, letters of the alphabet are used in order for the digits after 9. No alternate # notation exists for the decimal radix since a decimal point suffices.

+The next figure contains examples of the use of #B, #O, #X, and #R.

+

+#2r11010101  ;Another way of writing 213 decimal  
+#b11010101   ;Ditto                               
+#b+11010101  ;Ditto                               
+#o325        ;Ditto, in octal radix               
+#xD5         ;Ditto, in hexadecimal radix         
+#16r+D5      ;Ditto                               
+#o-300       ;Decimal -192, written in base 8     
+#3r-21010    ;Same thing in base 3                
+#25R-7H      ;Same thing in base 25               
+#xACCEDED    ;181202413, in hexadecimal radix     
+
+

Figure 2-20. Radix Indicator Example

+ The consequences are undefined if the token immediately following the #nR does not have the syntax of a rational in radix n.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhk.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhk.htm new file mode 100644 index 00000000..91ede6d4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhk.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 2.4.8.11 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.11 Sharpsign C

+ #C reads a following object, which must be a list of length two whose elements are both reals. These reals denote, respectively, the real and imaginary parts of a complex number. If the two parts as notated are not of the same data type, then they are converted according to the rules of floating-point contagion described in Section 12.1.1.2 (Contagion in Numeric Operations).

+#C(real imag) is equivalent to #.(complex (quote real) (quote imag)), except that #C is not affected by *read-eval*. See the function complex.

+The next figure contains examples of the use of #C.

+

+#C(3.0s1 2.0s-1)  ;A complex with small float parts.                
+#C(5 -3)          ;A ``Gaussian integer''                           
+#C(5/3 7.0)       ;Will be converted internally to #C(1.66666 7.0)  
+#C(0 1)           ;The imaginary unit; that is, i.                  
+
+

Figure 2-21. Complex Number Example

+For further information, see Section 22.1.3.1.4 (Printing Complexes) and Section 2.3.2.3 (Syntax of a Complex).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhl.htm new file mode 100644 index 00000000..ed34a3d6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhl.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 2.4.8.12 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.12 Sharpsign A

+#nA

+#nAobject constructs an n-dimensional array, using object as the value of the :initial-contents argument to make-array.

+For example, #2A((0 1 5) (foo 2 (hot dog))) represents a 2-by-3 matrix:

+

+ 0       1       5
+ foo     2       (hot dog)
+
+ In contrast, #1A((0 1 5) (foo 2 (hot dog))) represents a vector of length 2 whose elements are lists:

+

+ (0 1 5) (foo 2 (hot dog))
+
+ #0A((0 1 5) (foo 2 (hot dog))) represents a zero-dimensional array whose sole element is a list:

+

+ ((0 1 5) (foo 2 (hot dog)))
+
+ #0A foo represents a zero-dimensional array whose sole element is the symbol foo. The notation #1A foo is not valid because foo is not a sequence.

+If some dimension of the array whose representation is being parsed is found to be 0, all dimensions to the right (i.e., the higher numbered dimensions) are also considered to be 0.

+For information on how the Lisp printer prints arrays, see Section 22.1.3.4 (Printing Strings), Section 22.1.3.6 (Printing Bit Vectors), Section 22.1.3.7 (Printing Other Vectors), or Section 22.1.3.8 (Printing Other Arrays).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhm.htm new file mode 100644 index 00000000..8768eee5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhm.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 2.4.8.13 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.13 Sharpsign S

+#s(name slot1 value1 slot2 value2 ...) denotes a structure. This is valid only if name is the name of a structure type already defined by defstruct and if the structure type has a standard constructor function. Let cm stand for the name of this constructor function; then this syntax is equivalent to

+

+ #.(cm keyword1 'value1 keyword2 'value2 ...)
+
+

+where each keywordj is the result of computing

+

+ (intern (string slotj) (find-package 'keyword))
+
+

+The net effect is that the constructor function is called with the specified slots having the specified values. (This coercion feature is deprecated; in the future, keyword names will be taken in the package they are read in, so symbols that are actually in the KEYWORD package should be used if that is what is desired.)

+Whatever object the constructor function returns is returned by the #S syntax.

+For information on how the Lisp printer prints structures, see Section 22.1.3.12 (Printing Structures).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhn.htm new file mode 100644 index 00000000..f3db1ae1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhn.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 2.4.8.14 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.14 Sharpsign P

+

+#P reads a following object, which must be a string.

+#P<<expression>> is equivalent to #.(parse-namestring '<<expression>>), except that #P is not affected by *read-eval*.

+For information on how the Lisp printer prints pathnames, see Section 22.1.3.11 (Printing Pathnames).

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dho.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dho.htm new file mode 100644 index 00000000..7c1cfe83 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dho.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 2.4.8.15 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.15 Sharpsign Equal-Sign

+#n=

+#n=object reads as whatever object has object as its printed representation. However, that object is labeled by n, a required unsigned decimal integer, for possible reference by the syntax #n#. The scope of the label is the expression being read by the outermost call to read; within this expression, the same label may not appear twice.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhp.htm new file mode 100644 index 00000000..396dfdc9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhp.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 2.4.8.16 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.16 Sharpsign Sharpsign

+#n#

+#n#, where n is a required unsigned decimal integer, provides a reference to some object labeled by #n=; that is, #n# represents a pointer to the same (eq) object labeled by #n=. For example, a structure created in the variable y by this code:

+

+ (setq x (list 'p 'q))
+ (setq y (list (list 'a 'b) x 'foo x))
+ (rplacd (last y) (cdr y))
+
+ could be represented in this way:

+

+ ((a b) . #1=(#2=(p q) foo #2# . #1#))
+
+ Without this notation, but with *print-length* set to 10 and *print-circle* set to nil, the structure would print in this way:

+

+ ((a b) (p q) foo (p q) (p q) foo (p q) (p q) foo (p q) ...)
+
+ A reference #n# may only occur after a label #n=; forward references are not permitted. The reference may not appear as the labeled object itself (that is, #n=#n#) may not be written because the object labeled by #n= is not well defined in this case.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhq.htm new file mode 100644 index 00000000..1499c550 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhq.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 2.4.8.17 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.17 Sharpsign Plus

+#+ provides a read-time conditionalization facility; the syntax is #+test expression. If the feature expression test succeeds, then this textual notation represents an object whose printed representation is expression. If the feature expression test fails, then this textual notation is treated as whitespace[2]; that is, it is as if the ``#+ test expression'' did not appear and only a space appeared in its place.

+For a detailed description of success and failure in feature expressions, see Section 24.1.2.1 (Feature Expressions).

+#+ operates by first reading the feature expression and then skipping over the form if the feature expression fails. While reading the test, the current package is the KEYWORD package. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read.

+For examples, see Section 24.1.2.1.1 (Examples of Feature Expressions).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhr.htm new file mode 100644 index 00000000..c59a3f21 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhr.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 2.4.8.18 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.18 Sharpsign Minus

+#- is like #+ except that it skips the expression if the test succeeds; that is,

+

+#-test expression ==  #+(not test) expression
+
+

+For examples, see Section 24.1.2.1.1 (Examples of Feature Expressions).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhs.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhs.htm new file mode 100644 index 00000000..81f0862c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhs.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 2.4.8.19 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.19 Sharpsign Vertical-Bar

+#|...|# is treated as a comment by the reader. It must be balanced with respect to other occurrences of #| and |#, but otherwise may contain any characters whatsoever.

+ + +

+2.4.8.19.1 Examples of Sharpsign Vertical-Bar

+ +

+2.4.8.19.2 Notes about Style for Sharpsign Vertical-Bar

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsa.htm new file mode 100644 index 00000000..9a11ca5b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsa.htm @@ -0,0 +1,86 @@ + + + +CLHS: Section 2.4.8.19.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.19.1 Examples of Sharpsign Vertical-Bar

+The following are some examples that exploit the #|...|# notation:

+

+;;; In this example, some debugging code is commented out with #|...|#
+;;; Note that this kind of comment can occur in the middle of a line
+;;; (because a delimiter marks where the end of the comment occurs)
+;;; where a semicolon comment can only occur at the end of a line 
+;;; (because it comments out the rest of the line).
+ (defun add3 (n) #|(format t "~&Adding 3 to ~D." n)|# (+ n 3))
+
+;;; The examples that follow show issues related to #| ... |# nesting.
+
+;;; In this first example, #| and |# always occur properly paired,
+;;; so nesting works naturally.
+ (defun mention-fun-fact-1a ()
+   (format t "CL uses ; and #|...|# in comments."))
+=>  MENTION-FUN-FACT-1A
+ (mention-fun-fact-1a)
+>>  CL uses ; and #|...|# in comments.
+=>  NIL
+ #| (defun mention-fun-fact-1b ()
+      (format t "CL uses ; and #|...|# in comments.")) |#
+ (fboundp 'mention-fun-fact-1b) =>  NIL
+
+;;; In this example, vertical-bar followed by sharpsign needed to appear
+;;; in a string without any matching sharpsign followed by vertical-bar
+;;; having preceded this.  To compensate, the programmer has included a
+;;; slash separating the two characters.  In case 2a, the slash is 
+;;; unnecessary but harmless, but in case 2b, the slash is critical to
+;;; allowing the outer #| ... |# pair match.  If the slash were not present,
+;;; the outer comment would terminate prematurely.
+ (defun mention-fun-fact-2a ()
+   (format t "Don't use |\# unmatched or you'll get in trouble!"))
+=>  MENTION-FUN-FACT-2A
+ (mention-fun-fact-2a)
+>>  Don't use |# unmatched or you'll get in trouble!
+=>  NIL
+ #| (defun mention-fun-fact-2b ()
+      (format t "Don't use |\# unmatched or you'll get in trouble!") |#
+ (fboundp 'mention-fun-fact-2b) =>  NIL
+
+;;; In this example, the programmer attacks the mismatch problem in a
+;;; different way.  The sharpsign vertical bar in the comment is not needed
+;;; for the correct parsing of the program normally (as in case 3a), but 
+;;; becomes important to avoid premature termination of a comment when such 
+;;; a program is commented out (as in case 3b).
+ (defun mention-fun-fact-3a () ; #|
+   (format t "Don't use |# unmatched or you'll get in trouble!"))
+=>  MENTION-FUN-FACT-3A
+ (mention-fun-fact-3a)
+>>  Don't use |# unmatched or you'll get in trouble!
+=>  NIL
+ #|
+ (defun mention-fun-fact-3b () ; #|
+   (format t "Don't use |# unmatched or you'll get in trouble!"))
+ |#
+ (fboundp 'mention-fun-fact-3b) =>  NIL
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsb.htm new file mode 100644 index 00000000..09347438 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhsb.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 2.4.8.19.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.19.2 Notes about Style for Sharpsign Vertical-Bar

+Some text editors that purport to understand Lisp syntax treat any |...| as balanced pairs that cannot nest (as if they were just balanced pairs of the multiple escapes used in notating certain symbols). To compensate for this deficiency, some programmers use the notation #||...#||...||#...||# instead of #|...#|...|#...|#. Note that this alternate usage is not a different reader macro; it merely exploits the fact that the additional vertical-bars occur within the comment in a way that tricks certain text editor into better supporting nested comments. As such, one might sometimes see code like:

+

+ #|| (+ #|| 3 ||# 4 5) ||# 
+
+

+Such code is equivalent to:

+

+ #| (+ #| 3 |# 4 5) |#
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dht.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dht.htm new file mode 100644 index 00000000..fbad735f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dht.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.8.20 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.20 Sharpsign Less-Than-Sign

+#< is not valid reader syntax. The Lisp reader will signal an error of type reader-error on encountering #<. This syntax is typically used in the printed representation of objects that cannot be read back in.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhu.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhu.htm new file mode 100644 index 00000000..82b50477 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhu.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.8.21 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.21 Sharpsign Whitespace

+# followed immediately by whitespace[1] is not valid reader syntax. The Lisp reader will signal an error of type reader-error if it encounters the reader macro notation #<Newline> or #<Space>.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhv.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhv.htm new file mode 100644 index 00000000..71b69598 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_dhv.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 2.4.8.22 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.8.22 Sharpsign Right-Parenthesis

+This is not valid reader syntax.

+The Lisp reader will signal an error of type reader-error upon encountering #).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_di.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_di.htm new file mode 100644 index 00000000..d974d973 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/02_di.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 2.4.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+2.4.9 Re-Reading Abbreviated Expressions

+Note that the Lisp reader will generally signal an error of type reader-error when reading an expression[2] that has been abbreviated because of length or level limits (see *print-level*, *print-length*, and *print-lines*) due to restrictions on ``..'', ``...'', ``#'' followed by whitespace[1], and ``#)''.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_.htm new file mode 100644 index 00000000..8cc9cb9c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_.htm @@ -0,0 +1,57 @@ + + + +CLHS: Chapter 3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+3. Evaluation and Compilation

+

+ + +

+3.1 Evaluation

+ +

+3.2 Compilation

+ +

+3.3 Declarations

+ +

+3.4 Lambda Lists

+ +

+3.5 Error Checking in Function Calls

+ +

+3.6 Traversal Rules and Side Effects

+ +

+3.7 Destructive Operations

+ +

+3.8 The Evaluation and Compilation Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_a.htm new file mode 100644 index 00000000..9aab0266 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_a.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1 Evaluation

+Execution of code can be accomplished by a variety of means ranging from direct interpretation of a form representing a program to invocation of compiled code produced by a compiler.

+Evaluation is the process by which a program is executed in Common Lisp. The mechanism of evaluation is manifested both implicitly through the effect of the Lisp read-eval-print loop, and explicitly through the presence of the functions eval, compile, compile-file, and load. Any of these facilities might share the same execution strategy, or each might use a different one.

+The behavior of a conforming program processed by eval and by compile-file might differ; see Section 3.2.2.3 (Semantic Constraints).

+Evaluation can be understood in terms of a model in which an interpreter recursively traverses a form performing each step of the computation as it goes. This model, which describes the semantics of Common Lisp programs, is described in Section 3.1.2 (The Evaluation Model).

+ + +

+3.1.1 Introduction to Environments

+ +

+3.1.2 The Evaluation Model

+ +

+3.1.3 Lambda Expressions

+ +

+3.1.4 Closures and Lexical Binding

+ +

+3.1.5 Shadowing

+ +

+3.1.6 Extent

+ +

+3.1.7 Return Values

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aa.htm new file mode 100644 index 00000000..a2b47c87 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aa.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.1 Introduction to Environments

+A binding is an association between a name and that which the name denotes. Bindings are established in a lexical environment or a dynamic environment by particular special operators.

+An environment is a set of bindings and other information used during evaluation (e.g., to associate meanings with names).

+Bindings in an environment are partitioned into namespaces. A single name can simultaneously have more than one associated binding per environment, but can have only one associated binding per namespace.

+ + +

+3.1.1.1 The Global Environment

+ +

+3.1.1.2 Dynamic Environments

+ +

+3.1.1.3 Lexical Environments

+ +

+3.1.1.4 Environment Objects

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaa.htm new file mode 100644 index 00000000..2f11e020 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 3.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.1.1 The Global Environment

+The global environment is that part of an environment that contains bindings with both indefinite scope and indefinite extent. The global environment contains, among other things, the following:

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aab.htm new file mode 100644 index 00000000..b8b10f6c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aab.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.1.2 Dynamic Environments

+A dynamic environment for evaluation is that part of an environment that contains bindings whose duration is bounded by points of establishment and disestablishment within the execution of the form that established the binding. A dynamic environment contains, among other things, the following:

+

+The dynamic environment that is active at any given point in the execution of a program is referred to by definite reference as ``the current dynamic environment,'' or sometimes as just ``the dynamic environment.''

+Within a given namespace, a name is said to be bound in a dynamic environment if there is a binding associated with its name in the dynamic environment or, if not, there is a binding associated with its name in the global environment.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aac.htm new file mode 100644 index 00000000..bb5f8bb9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aac.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 3.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.1.3 Lexical Environments

+A lexical environment for evaluation at some position in a program is that part of the environment that contains information having lexical scope within the forms containing that position. A lexical environment contains, among other things, the following:

+

+The lexical environment that is active at any given position in a program being semantically processed is referred to by definite reference as ``the current lexical environment,'' or sometimes as just ``the lexical environment.''

+Within a given namespace, a name is said to be bound in a lexical environment if there is a binding associated with its name in the lexical environment or, if not, there is a binding associated with its name in the global environment.

+ + +

+3.1.1.3.1 The Null Lexical Environment

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaca.htm new file mode 100644 index 00000000..7c741e84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aaca.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 3.1.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.1.3.1 The Null Lexical Environment

+The null lexical environment is equivalent to the global environment.

+Although in general the representation of an environment object is implementation-dependent, nil can be used in any situation where an environment object is called for in order to denote the null lexical environment.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aad.htm new file mode 100644 index 00000000..e84553fe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aad.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.1.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.1.4 Environment Objects

+Some operators make use of an object, called an environment object, that represents the set of lexical bindings needed to perform semantic analysis on a form in a given lexical environment. The set of bindings in an environment object may be a subset of the bindings that would be needed to actually perform an evaluation; for example, values associated with variable names and function names in the corresponding lexical environment might not be available in an environment object.

+The type and nature of an environment object is implementation-dependent. The values of environment parameters to macro functions are examples of environment objects.

+The object nil when used as an environment object denotes the null lexical environment; see Section 3.1.1.3.1 (The Null Lexical Environment).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ab.htm new file mode 100644 index 00000000..1e2b1de1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ab.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2 The Evaluation Model

+A Common Lisp system evaluates forms with respect to lexical, dynamic, and global environments. The following sections describe the components of the Common Lisp evaluation model.

+ + +

+3.1.2.1 Form Evaluation

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aba.htm new file mode 100644 index 00000000..a3f4c096 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_aba.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 3.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1 Form Evaluation

+Forms fall into three categories: symbols, conses, and self-evaluating objects. The following sections explain these categories.

+ + +

+3.1.2.1.1 Symbols as Forms

+ +

+3.1.2.1.2 Conses as Forms

+ +

+3.1.2.1.3 Self-Evaluating Objects

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaa.htm new file mode 100644 index 00000000..820c794a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaa.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 3.1.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.1 Symbols as Forms

+If a form is a symbol, then it is either a symbol macro or a variable.

+The symbol names a symbol macro if there is a binding of the symbol as a symbol macro in the current lexical environment (see define-symbol-macro and symbol-macrolet). If the symbol is a symbol macro, its expansion function is obtained. The expansion function is a function of two arguments, and is invoked by calling the macroexpand hook with the expansion function as its first argument, the symbol as its second argument, and an environment object (corresponding to the current lexical environment) as its third argument. The macroexpand hook, in turn, calls the expansion function with the form as its first argument and the environment as its second argument. The value of the expansion function, which is passed through by the macroexpand hook, is a form. This resulting form is processed in place of the original symbol.

+If a form is a symbol that is not a symbol macro, then it is the name of a variable, and the value of that variable is returned. There are three kinds of variables: lexical variables, dynamic variables, and constant variables. A variable can store one object. The main operations on a variable are to read[1] and to write[1] its value.

+An error of type unbound-variable should be signaled if an unbound variable is referenced.

+Non-constant variables can be assigned by using setq or bound[3] by using let. The next figure lists some defined names that are applicable to assigning, binding, and defining variables.

+

+boundp        let                  progv         
+defconstant   let*                 psetq         
+defparameter  makunbound           set           
+defvar        multiple-value-bind  setq          
+lambda        multiple-value-setq  symbol-value  
+
+

Figure 3-1. Some Defined Names Applicable to Variables

+The following is a description of each kind of variable.

+ + +

+3.1.2.1.1.1 Lexical Variables

+ +

+3.1.2.1.1.2 Dynamic Variables

+ +

+3.1.2.1.1.3 Constant Variables

+ +

+3.1.2.1.1.4 Symbols Naming Both Lexical and Dynamic Variables

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaaa.htm new file mode 100644 index 00000000..4784f962 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaaa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.1.2.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.1.1 Lexical Variables

+A lexical variable is a variable that can be referenced only within the lexical scope of the form that establishes that variable; lexical variables have lexical scope. Each time a form creates a lexical binding of a variable, a fresh binding is established.

+Within the scope of a binding for a lexical variable name, uses of that name as a variable are considered to be references to that binding except where the variable is shadowed[2] by a form that establishes a fresh binding for that variable name, or by a form that locally declares the name special.

+A lexical variable always has a value. There is no operator that introduces a binding for a lexical variable without giving it an initial value, nor is there any operator that can make a lexical variable be unbound.

+Bindings of lexical variables are found in the lexical environment.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaab.htm new file mode 100644 index 00000000..67c5af51 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaab.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 3.1.2.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.1.2 Dynamic Variables

+A variable is a dynamic variable if one of the following conditions hold:

+

+A dynamic variable can be referenced at any time in any program; there is no textual limitation on references to dynamic variables. At any given time, all dynamic variables with a given name refer to exactly one binding, either in the dynamic environment or in the global environment.

+The value part of the binding for a dynamic variable might be empty; in this case, the dynamic variable is said to have no value, or to be unbound. A dynamic variable can be made unbound by using makunbound.

+The effect of binding a dynamic variable is to create a new binding to which all references to that dynamic variable in any program refer for the duration of the evaluation of the form that creates the dynamic binding.

+A dynamic variable can be referenced outside the dynamic extent of a form that binds it. Such a variable is sometimes called a ``global variable'' but is still in all respects just a dynamic variable whose binding happens to exist in the global environment rather than in some dynamic environment.

+A dynamic variable is unbound unless and until explicitly assigned a value, except for those variables whose initial value is defined in this specification or by an implementation.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaac.htm new file mode 100644 index 00000000..821f2e0e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaac.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 3.1.2.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.1.3 Constant Variables

+Certain variables, called constant variables, are reserved as ``named constants.'' The consequences are undefined if an attempt is made to assign a value to, or create a binding for a constant variable, except that a `compatible' redefinition of a constant variable using defconstant is permitted; see the macro defconstant.

+Keywords, symbols defined by Common Lisp or the implementation as constant (such as nil, t, and pi), and symbols declared as constant using defconstant are constant variables.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaad.htm new file mode 100644 index 00000000..4d0fc382 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaad.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 3.1.2.1.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.1.4 Symbols Naming Both Lexical and Dynamic Variables

+The same symbol can name both a lexical variable and a dynamic variable, but never in the same lexical environment.

+In the following example, the symbol x is used, at different times, as the name of a lexical variable and as the name of a dynamic variable.

+

+ (let ((x 1))            ;Binds a special variable X
+   (declare (special x))
+   (let ((x 2))          ;Binds a lexical variable X
+     (+ x                ;Reads a lexical variable X
+        (locally (declare (special x))
+                 x))))   ;Reads a special variable X
+=>  3
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abab.htm new file mode 100644 index 00000000..c69c06da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abab.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 3.1.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.2 Conses as Forms

+A cons that is used as a form is called a compound form.

+If the car of that compound form is a symbol, that symbol is the name of an operator, and the form is either a special form, a macro form, or a function form, depending on the function binding of the operator in the current lexical environment. If the operator is neither a special operator nor a macro name, it is assumed to be a function name (even if there is no definition for such a function).

+If the car of the compound form is not a symbol, then that car must be a lambda expression, in which case the compound form is a lambda form.

+How a compound form is processed depends on whether it is classified as a special form, a macro form, a function form, or a lambda form.

+ + +

+3.1.2.1.2.1 Special Forms

+ +

+3.1.2.1.2.2 Macro Forms

+ +

+3.1.2.1.2.3 Function Forms

+ +

+3.1.2.1.2.4 Lambda Forms

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababa.htm new file mode 100644 index 00000000..1d096dd6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababa.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 3.1.2.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.2.1 Special Forms

+A special form is a form with special syntax, special evaluation rules, or both, possibly manipulating the evaluation environment, control flow, or both. A special operator has access to the current lexical environment and the current dynamic environment. Each special operator defines the manner in which its subexpressions are treated---which are forms, which are special syntax, etc.

+Some special operators create new lexical or dynamic environments for use during the evaluation of subforms of the special form. For example, block creates a new lexical environment that is the same as the one in force at the point of evaluation of the block form with the addition of a binding of the block name to an exit point from the block.

+The set of special operator names is fixed in Common Lisp; no way is provided for the user to define a special operator. The next figure lists all of the Common Lisp symbols that have definitions as special operators.

+ 

+block      let*                  return-from      
+catch      load-time-value       setq             
+eval-when  locally               symbol-macrolet  
+flet       macrolet              tagbody          
+function   multiple-value-call   the              
+go         multiple-value-prog1  throw            
+if         progn                 unwind-protect   
+labels     progv                                  
+let        quote                                  
+
+

Figure 3-2. Common Lisp Special Operators

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababb.htm new file mode 100644 index 00000000..7d7935cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababb.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 3.1.2.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.2.2 Macro Forms

+If the operator names a macro, its associated macro function is applied to the entire form and the result of that application is used in place of the original form.

+Specifically, a symbol names a macro in a given lexical environment if macro-function is true of the symbol and that environment. The function returned by macro-function is a function of two arguments, called the expansion function. The expansion function is invoked by calling the macroexpand hook with the expansion function as its first argument, the entire macro form as its second argument, and an environment object (corresponding to the current lexical environment) as its third argument. The macroexpand hook, in turn, calls the expansion function with the form as its first argument and the environment as its second argument. The value of the expansion function, which is passed through by the macroexpand hook, is a form. The returned form is evaluated in place of the original form.

+ The consequences are undefined if a macro function destructively modifies any part of its form argument.

+A macro name is not a function designator, and cannot be used as the function argument to functions such as apply, funcall, or map.

+An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided.

+The next figure lists some defined names that are applicable to macros.

+

+*macroexpand-hook*  macro-function  macroexpand-1  
+defmacro            macroexpand     macrolet       
+
+

Figure 3-3. Defined names applicable to macros

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababc.htm new file mode 100644 index 00000000..a6433aa0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababc.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 3.1.2.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.2.3 Function Forms

+If the operator is a symbol naming a function, the form represents a function form, and the cdr of the list contains the forms which when evaluated will supply the arguments passed to the function.

+When a function name is not defined, an error of type undefined-function should be signaled at run time; see Section 3.2.2.3 (Semantic Constraints).

+A function form is evaluated as follows:

+The subforms in the cdr of the original form are evaluated in left-to-right order in the current lexical and dynamic environments. The primary value of each such evaluation becomes an argument to the named function; any additional values returned by the subforms are discarded.

+The functional value of the operator is retrieved from the lexical environment, and that function is invoked with the indicated arguments.

+ Although the order of evaluation of the argument subforms themselves is strictly left-to-right, it is not specified whether the definition of the operator in a function form is looked up before the evaluation of the argument subforms, after the evaluation of the argument subforms, or between the evaluation of any two argument subforms if there is more than one such argument subform. For example, the following might return 23 or 24.

+

+ (defun foo (x) (+ x 3))
+ (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
+ (foo (progn (bar) 20))
+
+

+A binding for a function name can be established in one of several ways. A binding for a function name in the global environment can be established by defun, setf of fdefinition, setf of symbol-function, ensure-generic-function, defmethod (implicitly, due to ensure-generic-function), or defgeneric. A binding for a function name in the lexical environment can be established by flet or labels.

+The next figure lists some defined names that are applicable to functions.

+ 

+apply                 fdefinition  mapcan               
+call-arguments-limit  flet         mapcar               
+complement            fmakunbound  mapcon               
+constantly            funcall      mapl                 
+defgeneric            function     maplist              
+defmethod             functionp    multiple-value-call  
+defun                 labels       reduce               
+fboundp               map          symbol-function      
+
+

Figure 3-4. Some function-related defined names

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababd.htm new file mode 100644 index 00000000..76b973fb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ababd.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.1.2.1.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.2.4 Lambda Forms

+A lambda form is similar to a function form, except that the function name is replaced by a lambda expression.

+A lambda form is equivalent to using funcall of a lexical closure of the lambda expression on the given arguments. (In practice, some compilers are more likely to produce inline code for a lambda form than for an arbitrary named function that has been declared inline; however, such a difference is not semantic.)

+For further information, see Section 3.1.3 (Lambda Expressions).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abac.htm new file mode 100644 index 00000000..6d999ff6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abac.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 3.1.2.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.3 Self-Evaluating Objects

+ A form that is neither a symbol nor a cons is defined to be a self-evaluating object. Evaluating such an object yields the same object as a result.

+Certain specific symbols and conses might also happen to be ``self-evaluating'' but only as a special case of a more general set of rules for the evaluation of symbols and conses; such objects are not considered to be self-evaluating objects.

+The consequences are undefined if literal objects (including self-evaluating objects) are destructively modified.

+ + +

+3.1.2.1.3.1 Examples of Self-Evaluating Objects

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaca.htm new file mode 100644 index 00000000..ad1663cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_abaca.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 3.1.2.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.2.1.3.1 Examples of Self-Evaluating Objects

+Numbers, pathnames, and arrays are examples of self-evaluating objects.

+

+ 3 =>  3
+ #c(2/3 5/8) =>  #C(2/3 5/8)
+ #p"S:[BILL]OTHELLO.TXT" =>  #P"S:[BILL]OTHELLO.TXT"
+ #(a b c) =>  #(A B C)
+ "fred smith" =>  "fred smith"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ac.htm new file mode 100644 index 00000000..15f26cfe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ac.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.3 Lambda Expressions

+In a lambda expression, the body is evaluated in a lexical environment that is formed by adding the binding of each parameter in the lambda list with the corresponding value from the arguments to the current lexical environment.

+For further discussion of how bindings are established based on the lambda list, see Section 3.4 (Lambda Lists).

+The body of a lambda expression is an implicit progn; the values it returns are returned by the lambda expression.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ad.htm new file mode 100644 index 00000000..736fd291 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ad.htm @@ -0,0 +1,85 @@ + + + +CLHS: Section 3.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.4 Closures and Lexical Binding

+A lexical closure is a function that can refer to and alter the values of lexical bindings established by binding forms that textually include the function definition.

+Consider this code, where x is not declared special:

+

+ (defun two-funs (x)
+   (list (function (lambda () x))
+         (function (lambda (y) (setq x y)))))
+ (setq funs (two-funs 6))
+ (funcall (car funs)) =>  6
+ (funcall (cadr funs) 43) =>  43
+ (funcall (car funs)) =>  43
+
+

+The function special form coerces a lambda expression into a closure in which the lexical environment in effect when the special form is evaluated is captured along with the lambda expression.

+The function two-funs returns a list of two functions, each of which refers to the binding of the variable x created on entry to the function two-funs when it was called. This variable has the value 6 initially, but setq can alter this binding. The lexical closure created for the first lambda expression does not ``snapshot'' the value 6 for x when the closure is created; rather it captures the binding of x. The second function can be used to alter the value in the same (captured) binding (to 43, in the example), and this altered variable binding then affects the value returned by the first function.

+ In situations where a closure of a lambda expression over the same set of bindings may be produced more than once, the various resulting closures may or may not be identical, at the discretion of the implementation. That is, two functions that are behaviorally indistinguishable might or might not be identical. Two functions that are behaviorally distinguishable are distinct. For example:

+

+ (let ((x 5) (funs '()))
+   (dotimes (j 10)                          
+     (push #'(lambda (z)                        
+               (if (null z) (setq x 0) (+ x z)))
+           funs))
+   funs)
+
+ The result of the above form is a list of ten closures. Each requires only the binding of x. It is the same binding in each case, but the ten closure objects might or might not be identical. On the other hand, the result of the form

+

+ (let ((funs '()))     
+   (dotimes (j 10)
+     (let ((x 5))
+       (push (function (lambda (z)
+                        (if (null z) (setq x 0) (+ x z))))
+             funs)))
+  funs)
+
+ is also a list of ten closures. However, in this case no two of the closure objects can be identical because each closure is closed over a distinct binding of x, and these bindings can be behaviorally distinguished because of the use of setq.

+The result of the form

+

+ (let ((funs '()))
+   (dotimes (j 10)
+     (let ((x 5))
+       (push (function (lambda (z) (+ x z)))
+            funs)))
+   funs)
+
+ is a list of ten closure objects that might or might not be identical. A different binding of x is involved for each closure, but the bindings cannot be distinguished because their values are the same and immutable (there being no occurrence of setq on x). A compiler could internally transform the form to

+

+ (let ((funs '()))
+   (dotimes (j 10)
+     (push (function (lambda (z) (+ 5 z)))
+           funs))
+  funs)
+
+ where the closures may be identical.

+It is possible that a closure does not close over any variable bindings. In the code fragment

+

+ (mapcar (function (lambda (x) (+ x 2))) y)
+
+ the function (lambda (x) (+ x 2)) contains no references to any outside object. In this case, the same closure might be returned for all evaluations of the function form.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ae.htm new file mode 100644 index 00000000..b7414471 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ae.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section 3.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.5 Shadowing

+If two forms that establish lexical bindings with the same name N are textually nested, then references to N within the inner form refer to the binding established by the inner form; the inner binding for N shadows the outer binding for N. Outside the inner form but inside the outer one, references to N refer to the binding established by the outer form. For example:

+

+ (defun test (x z)
+   (let ((z (* x 2)))
+     (print z))
+   z)
+
+ The binding of the variable z by let shadows the parameter binding for the function test. The reference to the variable z in the print form refers to the let binding. The reference to z at the end of the function test refers to the parameter named z.

+Constructs that are lexically scoped act as if new names were generated for each object on each execution. Therefore, dynamic shadowing cannot occur. For example:

+

+ (defun contorted-example (f g x)
+   (if (= x 0)
+       (funcall f)
+       (block here
+          (+ 5 (contorted-example g
+                                  #'(lambda () (return-from here 4))
+                                  (- x 1))))))
+
+ Consider the call (contorted-example nil nil 2). This produces 4. During the course of execution, there are three calls to contorted-example, interleaved with two blocks:

+

+ (contorted-example nil nil 2)
+   (block here1 ...)
+     (contorted-example nil #'(lambda () (return-from here1 4)) 1)
+       (block here2 ...)
+         (contorted-example #'(lambda () (return-from here1 4))
+                            #'(lambda () (return-from here2 4))
+                            0)
+             (funcall f)
+                    where f =>  #'(lambda () (return-from here1 4))
+                 (return-from here1 4)
+
+ At the time the funcall is executed there are two block exit points outstanding, each apparently named here. The return-from form executed as a result of the funcall operation refers to the outer outstanding exit point (here1), not the inner one (here2). It refers to that exit point textually visible at the point of execution of function (here abbreviated by the #' syntax) that resulted in creation of the function object actually invoked by funcall.

+If, in this example, one were to change the (funcall f) to (funcall g), then the value of the call (contorted-example nil nil 2) would be 9. The value would change because funcall would cause the execution of (return-from here2 4), thereby causing a return from the inner exit point (here2). When that occurs, the value 4 is returned from the middle invocation of contorted-example, 5 is added to that to get 9, and that value is returned from the outer block and the outermost call to contorted-example. The point is that the choice of exit point returned from has nothing to do with its being innermost or outermost; rather, it depends on the lexical environment that is packaged up with a lambda expression when function is executed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_af.htm new file mode 100644 index 00000000..ebde70f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_af.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 3.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.6 Extent

Contorted-example works only because the function named by f is invoked during the extent of the exit point. Once the flow of execution has left the block, the exit point is disestablished. For example:

+

+ (defun invalid-example ()
+   (let ((y (block here #'(lambda (z) (return-from here z)))))
+     (if (numberp y) y (funcall y 5))))
+
+ One might expect the call (invalid-example) to produce 5 by the following incorrect reasoning: let binds y to the value of block; this value is a function resulting from the lambda expression. Because y is not a number, it is invoked on the value 5. The return-from should then return this value from the exit point named here, thereby exiting from the block again and giving y the value 5 which, being a number, is then returned as the value of the call to invalid-example.

+The argument fails only because exit points have dynamic extent. The argument is correct up to the execution of return-from. The execution of return-from should signal an error of type control-error, however, not because it cannot refer to the exit point, but because it does correctly refer to an exit point and that exit point has been disestablished.

+A reference by name to a dynamic exit point binding such as a catch tag refers to the most recently established binding of that name that has not been disestablished. For example:

+

+ (defun fun1 (x)
+   (catch 'trap (+ 3 (fun2 x))))
+ (defun fun2 (y)
+   (catch 'trap (* 5 (fun3 y))))
+ (defun fun3 (z)
+   (throw 'trap z))
+
+ Consider the call (fun1 7). The result is 10. At the time the throw is executed, there are two outstanding catchers with the name trap: one established within procedure fun1, and the other within procedure fun2. The latter is the more recent, and so the value 7 is returned from catch in fun2. Viewed from within fun3, the catch in fun2 shadows the one in fun1. Had fun2 been defined as

+

+ (defun fun2 (y)
+   (catch 'snare (* 5 (fun3 y))))
+
+ then the two exit points would have different names, and therefore the one in fun1 would not be shadowed. The result would then have been 7.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ag.htm new file mode 100644 index 00000000..cec8d356 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ag.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 3.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.1.7 Return Values

+Ordinarily the result of calling a function is a single object. Sometimes, however, it is convenient for a function to compute several objects and return them.

+In order to receive other than exactly one value from a form, one of several special forms or macros must be used to request those values. If a form produces multiple values which were not requested in this way, then the first value is given to the caller and all others are discarded; if the form produces zero values, then the caller receives nil as a value.

+The next figure lists some operators for receiving multiple values[2]. These operators can be used to specify one or more forms to evaluate and where to put the values returned by those forms.

+

+multiple-value-bind  multiple-value-prog1  return-from  
+multiple-value-call  multiple-value-setq   throw        
+multiple-value-list  return                             
+
+

Figure 3-5. Some operators applicable to receiving multiple values

+The function values can produce multiple values[2]. (values) returns zero values; (values form) returns the primary value returned by form; (values form1 form2) returns two values, the primary value of form1 and the primary value of form2; and so on.

+See multiple-values-limit and values-list.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_b.htm new file mode 100644 index 00000000..f189d673 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_b.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2 Compilation

+

+ + +

+3.2.1 Compiler Terminology

+ +

+3.2.2 Compilation Semantics

+ +

+3.2.3 File Compilation

+ + +

+3.2.4 Literal Objects in Compiled Files

+ +

+3.2.5 Exceptional Situations in the Compiler

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ba.htm new file mode 100644 index 00000000..ae42808f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ba.htm @@ -0,0 +1,48 @@ + + + +CLHS: Section 3.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.1 Compiler Terminology

+ The following terminology is used in this section.

+The compiler is a utility that translates code into an implementation-dependent form that might be represented or executed efficiently. The term compiler refers to both of the functions compile and compile-file.

+The term compiled code refers to objects representing compiled programs, such as objects constructed by compile or by load when loading a compiled file.

+The term implicit compilation refers to compilation performed during evaluation.

+ The term literal object refers to a quoted object or a self-evaluating object or an object that is a substructure of such an object. A constant variable is not itself a literal object.

+The term coalesce is defined as follows. Suppose A and B are two literal constants in the source code, and that A' and B' are the corresponding objects in the compiled code. If A' and B' are eql but A and B are not eql, then it is said that A and B have been coalesced by the compiler.

+The term minimal compilation refers to actions the compiler must take at compile time. These actions are specified in Section 3.2.2 (Compilation Semantics).

+The verb process refers to performing minimal compilation, determining the time of evaluation for a form, and possibly evaluating that form (if required).

+The term further compilation refers to implementation-dependent compilation beyond minimal compilation. That is, processing does not imply complete compilation. Block compilation and generation of machine-specific instructions are examples of further compilation. Further compilation is permitted to take place at run time.

+Four different environments relevant to compilation are distinguished: the startup environment, the compilation environment, the evaluation environment, and the run-time environment.

+The startup environment is the environment of the Lisp image from which the compiler was invoked.

+The compilation environment is maintained by the compiler and is used to hold definitions and declarations to be used internally by the compiler. Only those parts of a definition needed for correct compilation are saved. The compilation environment is used as the environment argument to macro expanders called by the compiler. It is unspecified whether a definition available in the compilation environment can be used in an evaluation initiated in the startup environment or evaluation environment.

+The evaluation environment is a run-time environment in which macro expanders and code specified by eval-when to be evaluated are evaluated. All evaluations initiated by the compiler take place in the evaluation environment.

+The run-time environment is the environment in which the program being compiled will be executed.

+The compilation environment inherits from the evaluation environment, and the compilation environment and evaluation environment might be identical. The evaluation environment inherits from the startup environment, and the startup environment and evaluation environment might be identical.

+The term compile time refers to the duration of time that the compiler is processing source code. At compile time, only the compilation environment and the evaluation environment are available.

+The term compile-time definition refers to a definition in the compilation environment. For example, when compiling a file, the definition of a function might be retained in the compilation environment if it is declared inline. This definition might not be available in the evaluation environment.

+The term run time refers to the duration of time that the loader is loading compiled code or compiled code is being executed. At run time, only the run-time environment is available.

+The term run-time definition refers to a definition in the run-time environment.

+The term run-time compiler refers to the function compile or implicit compilation, for which the compilation and run-time environments are maintained in the same Lisp image. Note that when the run-time compiler is used, the run-time environment and startup environment are the same.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bb.htm new file mode 100644 index 00000000..921f81eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bb.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 3.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2 Compilation Semantics

+Conceptually, compilation is a process that traverses code, performs certain kinds of syntactic and semantic analyses using information (such as proclamations and macro definitions) present in the compilation environment, and produces equivalent, possibly more efficient code.

+

+ + +

+3.2.2.1 Compiler Macros

+ + +

+3.2.2.2 Minimal Compilation

+ +

+3.2.2.3 Semantic Constraints

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bba.htm new file mode 100644 index 00000000..ddea275a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bba.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 3.2.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.1 Compiler Macros

+A compiler macro can be defined for a name that also names a function or macro. That is, it is possible for a function name to name both a function and a compiler macro.

+A function name names a compiler macro if compiler-macro-function is true of the function name in the lexical environment in which it appears. Creating a lexical binding for the function name not only creates a new local function or macro definition, but also shadows[2] the compiler macro.

+The function returned by compiler-macro-function is a function of two arguments, called the expansion function. To expand a compiler macro, the expansion function is invoked by calling the macroexpand hook with the expansion function as its first argument, the entire compiler macro form as its second argument, and the current compilation environment (or with the current lexical environment, if the form is being processed by something other than compile-file) as its third argument. The macroexpand hook, in turn, calls the expansion function with the form as its first argument and the environment as its second argument. The return value from the expansion function, which is passed through by the macroexpand hook, might either be the same form, or else a form that can, at the discretion of the code doing the expansion, be used in place of the original form.

+

+*macroexpand-hook*  compiler-macro-function  define-compiler-macro  
+
+

Figure 3-6. Defined names applicable to compiler macros

+ + +

+3.2.2.1.1 Purpose of Compiler Macros

+ +

+3.2.2.1.2 Naming of Compiler Macros

+ +

+3.2.2.1.3 When Compiler Macros Are Used

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaa.htm new file mode 100644 index 00000000..5b4acef1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.2.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.1.1 Purpose of Compiler Macros

+The purpose of the compiler macro facility is to permit selective source code transformations as optimization advice to the compiler. When a compound form is being processed (as by the compiler), if the operator names a compiler macro then the compiler macro function may be invoked on the form, and the resulting expansion recursively processed in preference to performing the usual processing on the original form according to its normal interpretation as a function form or macro form.

+A compiler macro function, like a macro function, is a function of two arguments: the entire call form and the environment. Unlike an ordinary macro function, a compiler macro function can decline to provide an expansion merely by returning a value that is the same as the original form. The consequences are undefined if a compiler macro function destructively modifies any part of its form argument.

+The form passed to the compiler macro function can either be a list whose car is the function name, or a list whose car is funcall and whose cadr is a list (function name); note that this affects destructuring of the form argument by the compiler macro function. define-compiler-macro arranges for destructuring of arguments to be performed correctly for both possible formats.

+When compile-file chooses to expand a top level form that is a compiler macro form, the expansion is also treated as a top level form for the purposes of eval-when processing; see Section 3.2.3.1 (Processing of Top Level Forms).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbab.htm new file mode 100644 index 00000000..2f55d863 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbab.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.2.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.1.2 Naming of Compiler Macros

+Compiler macros may be defined for function names that name macros as well as functions.

+Compiler macro definitions are strictly global. There is no provision for defining local compiler macros in the way that macrolet defines local macros. Lexical bindings of a function name shadow any compiler macro definition associated with the name as well as its global function or macro definition.

+Note that the presence of a compiler macro definition does not affect the values returned by functions that access function definitions (e.g., fboundp) or macro definitions (e.g., macroexpand). Compiler macros are global, and the function compiler-macro-function is sufficient to resolve their interaction with other lexical and global definitions.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbac.htm new file mode 100644 index 00000000..3f12d077 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbac.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 3.2.2.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.1.3 When Compiler Macros Are Used

+The presence of a compiler macro definition for a function or macro indicates that it is desirable for the compiler to use the expansion of the compiler macro instead of the original function form or macro form. However, no language processor (compiler, evaluator, or other code walker) is ever required to actually invoke compiler macro functions, or to make use of the resulting expansion if it does invoke a compiler macro function.

+When the compiler encounters a form during processing that represents a call to a compiler macro name (that is not declared notinline), the compiler might expand the compiler macro, and might use the expansion in place of the original form.

+When eval encounters a form during processing that represents a call to a compiler macro name (that is not declared notinline), eval might expand the compiler macro, and might use the expansion in place of the original form.

+There are two situations in which a compiler macro definition must not be applied by any language processor:

+

  • The global function name binding associated with the compiler macro is shadowed by a lexical binding of the function name.

    +

  • The function name has been declared or proclaimed notinline and the call form appears within the scope of the declaration.

+It is unspecified whether compiler macros are expanded or used in any other situations.

+ + +

+3.2.2.1.3.1 Notes about the Implementation of Compiler Macros

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaca.htm new file mode 100644 index 00000000..5cb33d4a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbaca.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.2.2.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.1.3.1 Notes about the Implementation of Compiler Macros

+Although it is technically permissible, as described above, for eval to treat compiler macros in the same situations as compiler might, this is not necessarily a good idea in interpreted implementations.

+Compiler macros exist for the purpose of trading compile-time speed for run-time speed. Programmers who write compiler macros tend to assume that the compiler macros can take more time than normal functions and macros in order to produce code which is especially optimal for use at run time. Since eval in an interpreted implementation might perform semantic analysis of the same form multiple times, it might be inefficient in general for the implementation to choose to call compiler macros on every such evaluation.

+Nevertheless, the decision about what to do in these situations is left to each implementation.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbb.htm new file mode 100644 index 00000000..7773b2d7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbb.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 3.2.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.2 Minimal Compilation

+Minimal compilation is defined as follows:

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbc.htm new file mode 100644 index 00000000..06f62523 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bbc.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 3.2.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.2.3 Semantic Constraints

+All conforming programs must obey the following constraints, which are designed to minimize the observable differences between compiled and interpreted programs:

+

+Conforming programs should not be written using any additional assumptions about consistency between the run-time environment and the startup, evaluation, and compilation environments.

+Except where noted, when a compile-time and a run-time definition are different, one of the following occurs at run time:

+

    +

  • an error of type error is signaled
  • the compile-time definition prevails
  • the run-time definition prevails

    +

+If the compiler processes a function form whose operator is not defined at compile time, no error is signaled at compile time.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bc.htm new file mode 100644 index 00000000..0f765189 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bc.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 3.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.3 File Compilation

+The function compile-file performs compilation of forms in a file following the rules specified in Section 3.2.2 (Compilation Semantics), and produces an output file that can be loaded by using load.

+Normally, the top level forms appearing in a file compiled with compile-file are evaluated only when the resulting compiled file is loaded, and not when the file is compiled. However, it is typically the case that some forms in the file need to be evaluated at compile time so the remainder of the file can be read and compiled correctly.

+The eval-when special form can be used to control whether a top level form is evaluated at compile time, load time, or both. It is possible to specify any of three situations with eval-when, denoted by the symbols :compile-toplevel, :load-toplevel, and :execute. For top level eval-when forms, :compile-toplevel specifies that the compiler must evaluate the body at compile time, and :load-toplevel specifies that the compiler must arrange to evaluate the body at load time. For non-top level eval-when forms, :execute specifies that the body must be executed in the run-time environment.

+The behavior of this form can be more precisely understood in terms of a model of how compile-file processes forms in a file to be compiled. There are two processing modes, called ``not-compile-time'' and ``compile-time-too''.

+Successive forms are read from the file by compile-file and processed in not-compile-time mode; in this mode, compile-file arranges for forms to be evaluated only at load time and not at compile time. When compile-file is in compile-time-too mode, forms are evaluated both at compile time and load time.

+ + +

+3.2.3.1 Processing of Top Level Forms

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bca.htm new file mode 100644 index 00000000..94630c93 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bca.htm @@ -0,0 +1,68 @@ + + + +CLHS: Section 3.2.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.3.1 Processing of Top Level Forms

+Processing of top level forms in the file compiler is defined as follows:

+

  1. If the form is a compiler macro form (not disabled by a notinline declaration), the implementation might or might not choose to compute the compiler macro expansion of the form and, having performed the expansion, might or might not choose to process the result as a top level form in the same processing mode (compile-time-too or not-compile-time). If it declines to obtain or use the expansion, it must process the original form.

    +

  2. If the form is a macro form, its macro expansion is computed and processed as a top level form in the same processing mode (compile-time-too or not-compile-time).

    +

  3. If the form is a progn form, each of its body forms is sequentially processed as a top level form in the same processing mode.

    +

  4. If the form is a locally, macrolet, or symbol-macrolet, compile-file establishes the appropriate bindings and processes the body forms as top level forms with those bindings in effect in the same processing mode. (Note that this implies that the lexical environment in which top level forms are processed is not necessarily the null lexical environment.)

    +

  5. If the form is an eval-when form, it is handled according to the next figure.

    + plus .5 fil 

    +                                                 
+CT   LT   E    Mode  Action    New Mode          
+----------
+                                                 
+Yes  Yes  ---  ---   Process   compile-time-too  
+No   Yes  Yes  CTT   Process   compile-time-too  
+No   Yes  Yes  NCT   Process   not-compile-time  
+No   Yes  No   ---   Process   not-compile-time  
+Yes  No   ---  ---   Evaluate  ---               
+No   No   Yes  CTT   Evaluate  ---               
+No   No   Yes  NCT   Discard   ---               
+No   No   No   ---   Discard   ---               
+                                                 
+          
+
    +

    Figure 3-7. EVAL-WHEN processing

    +Column CT indicates whether :compile-toplevel is specified. Column LT indicates whether :load-toplevel is specified. Column E indicates whether :execute is specified. Column Mode indicates the processing mode; a dash (---) indicates that the processing mode is not relevant.

    +The Action column specifies one of three actions:

    +

    +

    Process: process the body as top level forms in the specified mode.

    +
    Evaluate: evaluate the body in the dynamic execution context of the compiler, using the evaluation environment as the global environment and the lexical environment in which the eval-when appears.

    +
    Discard: ignore the form.

    +The New Mode column indicates the new processing mode. A dash (---) indicates the compiler remains in its current mode.

    +

  6. Otherwise, the form is a top level form that is not one of the special cases. In compile-time-too mode, the compiler first evaluates the form in the evaluation environment and then minimally compiles it. In not-compile-time mode, the form is simply minimally compiled. All subforms are treated as non-top-level forms.

    +Note that top level forms are processed in the order in which they textually appear in the file and that each top level form read by the compiler is processed before the next is read. However, the order of processing (including macro expansion) of subforms that are not top level forms and the order of further compilation is unspecified as long as Common Lisp semantics are preserved.

    +

+eval-when forms cause compile-time evaluation only at top level. Both :compile-toplevel and :load-toplevel situation specifications are ignored for non-top-level forms. For non-top-level forms, an eval-when specifying the :execute situation is treated as an implicit progn including the forms in the body of the eval-when form; otherwise, the forms in the body are ignored.

+ + +

+3.2.3.1.1 Processing of Defining Macros

+ +

+3.2.3.1.2 Constraints on Macros and Compiler Macros

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcaa.htm new file mode 100644 index 00000000..f542a976 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcaa.htm @@ -0,0 +1,56 @@ + + + +CLHS: Section 3.2.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.3.1.1 Processing of Defining Macros

+

+Defining macros (such as defmacro or defvar) appearing within a file being processed by compile-file normally have compile-time side effects which affect how subsequent forms in the same file are compiled. A convenient model for explaining how these side effects happen is that the defining macro expands into one or more eval-when forms, and that the calls which cause the compile-time side effects to happen appear in the body of an (eval-when (:compile-toplevel) ...) form.

+The compile-time side effects may cause information about the definition to be stored differently than if the defining macro had been processed in the `normal' way (either interpretively or by loading the compiled file).

+In particular, the information stored by the defining macros at compile time might or might not be available to the interpreter (either during or after compilation), or during subsequent calls to the compiler. For example, the following code is nonportable because it assumes that the compiler stores the macro definition of foo where it is available to the interpreter:

+

+ (defmacro foo (x) `(car ,x))
+ (eval-when (:execute :compile-toplevel :load-toplevel)
+   (print (foo '(a b c))))
+
+

+A portable way to do the same thing would be to include the macro definition inside the eval-when form, as in:

+

+ (eval-when (:execute :compile-toplevel :load-toplevel)
+   (defmacro foo (x) `(car ,x))
+   (print (foo '(a b c))))
+
+

+

+The next figure lists macros that make definitions available both in the compilation and run-time environments. It is not specified whether definitions made available in the compilation environment are available in the evaluation environment, nor is it specified whether they are available in subsequent compilation units or subsequent invocations of the compiler. As with eval-when, these compile-time side effects happen only when the defining macros appear at top level.

+ 

+declaim                define-modify-macro   defsetf    
+defclass               define-setf-expander  defstruct  
+defconstant            defmacro              deftype    
+define-compiler-macro  defpackage            defvar     
+define-condition       defparameter                     
+
+

Figure 3-8. Defining Macros That Affect the Compile-Time Environment

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcab.htm new file mode 100644 index 00000000..7327ed7d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bcab.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.2.3.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.3.1.2 Constraints on Macros and Compiler Macros

+

+Except where explicitly stated otherwise, no macro defined in the Common Lisp standard produces an expansion that could cause any of the subforms of the macro form to be treated as top level forms. If an implementation also provides a special operator definition of a Common Lisp macro, the special operator definition must be semantically equivalent in this respect.

+Compiler macro expansions must also have the same top level evaluation semantics as the form which they replace. This is of concern both to conforming implementations and to conforming programs.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bd.htm new file mode 100644 index 00000000..30d2e3bc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bd.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 3.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4 Literal Objects in Compiled Files

+The functions eval and compile are required to ensure that literal objects referenced within the resulting interpreted or compiled code objects are the same as the corresponding objects in the source code. compile-file, on the other hand, must produce a compiled file that, when loaded with load, constructs the objects defined by the source code and produces references to them.

+In the case of compile-file, objects constructed by load of the compiled file cannot be spoken of as being the same as the objects constructed at compile time, because the compiled file may be loaded into a different Lisp image than the one in which it was compiled. This section defines the concept of similarity which relates objects in the evaluation environment to the corresponding objects in the run-time environment.

+The constraints on literal objects described in this section apply only to compile-file; eval and compile do not copy or coalesce constants.

+ + +

+3.2.4.1 Externalizable Objects

+ +

+3.2.4.2 Similarity of Literal Objects

+ +

+3.2.4.3 Extensions to Similarity Rules

+ +

+3.2.4.4 Additional Constraints on Externalizable Objects

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bda.htm new file mode 100644 index 00000000..78ea8ce4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bda.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 3.2.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4.1 Externalizable Objects

+ The fact that the file compiler represents literal objects externally in a compiled file and must later reconstruct suitable equivalents of those objects when that file is loaded imposes a need for constraints on the nature of the objects that can be used as literal objects in code to be processed by the file compiler.

+An object that can be used as a literal object in code to be processed by the file compiler is called an externalizable object.

+We define that two objects are similar if they satisfy a two-place conceptual equivalence predicate (defined below), which is independent of the Lisp image so that the two objects in different Lisp images can be understood to be equivalent under this predicate. Further, by inspecting the definition of this conceptual predicate, the programmer can anticipate what aspects of an object are reliably preserved by file compilation.

+The file compiler must cooperate with the loader in order to assure that in each case where an externalizable object is processed as a literal object, the loader will construct a similar object.

+The set of objects that are externalizable objects are those for which the new conceptual term ``similar'' is defined, such that when a compiled file is loaded, an object can be constructed which can be shown to be similar to the original object which existed at the time the file compiler was operating.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdb.htm new file mode 100644 index 00000000..cb1e0434 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdb.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 3.2.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4.2 Similarity of Literal Objects

+ + +

+3.2.4.2.1 Similarity of Aggregate Objects

+ + +

+3.2.4.2.2 Definition of Similarity

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdba.htm new file mode 100644 index 00000000..8f52ca15 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 3.2.4.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4.2.1 Similarity of Aggregate Objects

+Of the types over which similarity is defined, some are treated as aggregate objects. For these types, similarity is defined recursively. We say that an object of these types has certain ``basic qualities'' and to satisfy the similarity relationship, the values of the corresponding qualities of the two objects must also be similar.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdbb.htm new file mode 100644 index 00000000..9ac1e8d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdbb.htm @@ -0,0 +1,64 @@ + + + +CLHS: Section 3.2.4.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4.2.2 Definition of Similarity

+Two objects S (in source code) and C (in compiled code) are defined to be similar if and only if they are both of one of the types listed here (or defined by the implementation) and they both satisfy all additional requirements of similarity indicated for that type.

+

+

number

+Two numbers S and C are similar if they are of the same type and represent the same mathematical value.

+

character

+Two simple characters S and C are similar if they have similar code attributes.

+Implementations providing additional, implementation-defined attributes must define whether and how non-simple characters can be regarded as similar.

+

symbol

+Two apparently uninterned symbols S and C are similar if their names are similar.

+ Two interned symbols S and C are similar if their names are similar, and if either S is accessible in the current package at compile time and C is accessible in the current package at load time, or C is accessible in the package that is similar to the home package of S.

+(Note that similarity of symbols is dependent on neither the current readtable nor how the function read would parse the characters in the name of the symbol.)

+

package

+Two packages S and C are similar if their names are similar.

+Note that although a package object is an externalizable object, the programmer is responsible for ensuring that the corresponding package is already in existence when code referencing it as a literal object is loaded. The loader finds the corresponding package object as if by calling find-package with that name as an argument. An error is signaled by the loader if no package exists at load time.

+

random-state

+Two random states S and C are similar if S would always produce the same sequence of pseudo-random numbers as a copy[5] of C when given as the random-state argument to the function random, assuming equivalent limit arguments in each case.

+(Note that since C has been processed by the file compiler, it cannot be used directly as an argument to random because random would perform a side effect.)

+

cons

+Two conses, S and C, are similar if the car[2] of S is similar to the car[2] of C, and the cdr[2] of S is similar to the cdr[2] of C.

+

array

+Two one-dimensional arrays, S and C, are similar if the length of S is similar to the length of C, the actual array element type of S is similar to the actual array element type of C, and each active element of S is similar to the corresponding element of C.

+Two arrays of rank other than one, S and C, are similar if the rank of S is similar to the rank of C, each dimension[1] of S is similar to the corresponding dimension[1] of C, the actual array element type of S is similar to the actual array element type of C, and each element of S is similar to the corresponding element of C.

+In addition, if S is a simple array, then C must also be a simple array. If S is a displaced array, has a fill pointer, or is actually adjustable, C is permitted to lack any or all of these qualities.

+

hash-table

+Two hash tables S and C are similar if they meet the following three requirements:

+

  1. They both have the same test (e.g., they are both eql hash tables).

    +

  2. There is a unique one-to-one correspondence between the keys of the two hash tables, such that the corresponding keys are similar.

    +

  3. For all keys, the values associated with two corresponding keys are similar.

+If there is more than one possible one-to-one correspondence between the keys of S and C, the consequences are unspecified. A conforming program cannot use a table such as S as an externalizable constant.

+

pathname

+Two pathnames S and C are similar if all corresponding pathname components are similar.

+

function

+ Functions are not externalizable objects.

+

structure-object and standard-object

+ A general-purpose concept of similarity does not exist for structures and standard objects. However, a conforming program is permitted to define a make-load-form method for any class K defined by that program that is a subclass of either structure-object or standard-object. The effect of such a method is to define that an object S of type K in source code is similar to an object C of type K in compiled code if C was constructed from code produced by calling make-load-form on S.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdc.htm new file mode 100644 index 00000000..2d0cde39 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdc.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.2.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4.3 Extensions to Similarity Rules

+Some objects, such as streams, readtables, and methods are not externalizable objects under the definition of similarity given above. That is, such objects may not portably appear as literal objects in code to be processed by the file compiler.

+An implementation is permitted to extend the rules of similarity, so that other kinds of objects are externalizable objects for that implementation.

+If for some kind of object, similarity is neither defined by this specification nor by the implementation, then the file compiler must signal an error upon encountering such an object as a literal constant.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdd.htm new file mode 100644 index 00000000..88657882 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_bdd.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 3.2.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.4.4 Additional Constraints on Externalizable Objects

+If two literal objects appearing in the source code for a single file processed with the file compiler are the identical, the corresponding objects in the compiled code must also be the identical. With the exception of symbols and packages, any two literal objects in code being processed by the file compiler may be coalesced if and only if they are similar; if they are either both symbols or both packages, they may only be coalesced if and only if they are identical.

+ Objects containing circular references can be externalizable objects. The file compiler is required to preserve eqlness of substructures within a file. Preserving eqlness means that subobjects that are the same in the source code must be the same in the corresponding compiled code.

+In addition, the following are constraints on the handling of literal objects by the file compiler:

+

+

array: If an array in the source code is a simple array, then the corresponding array in the compiled code will also be a simple array. If an array in the source code is displaced, has a fill pointer, or is actually adjustable, the corresponding array in the compiled code might lack any or all of these qualities. If an array in the source code has a fill pointer, then the corresponding array in the compiled code might be only the size implied by the fill pointer.

+
packages: The loader is required to find the corresponding package object as if by calling find-package with the package name as an argument. An error of type package-error is signaled if no package of that name exists at load time.

+
random-state: A constant random state object cannot be used as the state argument to the function random because random modifies this data structure.

+
structure, standard-object: Objects of type structure-object and standard-object may appear in compiled constants if there is an appropriate make-load-form method defined for that type.

+ The file compiler calls make-load-form on any object that is referenced as a literal object if the object is a generalized instance of standard-object, structure-object, condition, or any of a (possibly empty) implementation-dependent set of other classes. The file compiler only calls make-load-form once for any given object within a single file.

+

symbol: In order to guarantee that compiled files can be loaded correctly, users must ensure that the packages referenced in those files are defined consistently at compile time and load time. Conforming programs must satisfy the following requirements:

+

  1. The current package when a top level form in the file is processed by compile-file must be the same as the current package when the code corresponding to that top level form in the compiled file is executed by load. In particular:

    +

    +

    a. Any top level form in a file that alters the current package must change it to a package of the same name both at compile time and at load time.

    +
    b. If the first non-atomic top level form in the file is not an in-package form, then the current package at the time load is called must be a package with the same name as the package that was the current package at the time compile-file was called.

    +

  2. For all symbols appearing lexically within a top level form that were accessible in the package that was the current package during processing of that top level form at compile time, but whose home package was another package, at load time there must be a symbol with the same name that is accessible in both the load-time current package and in the package with the same name as the compile-time home package.

    +

  3. For all symbols represented in the compiled file that were external symbols in their home package at compile time, there must be a symbol with the same name that is an external symbol in the package with the same name at load time.

+ If any of these conditions do not hold, the package in which the loader looks for the affected symbols is unspecified. Implementations are permitted to signal an error or to define this behavior.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_be.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_be.htm new file mode 100644 index 00000000..86846b57 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_be.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 3.2.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.2.5 Exceptional Situations in the Compiler

+

+

+compile and compile-file are permitted to signal errors and warnings, including errors due to compile-time processing of (eval-when (:compile-toplevel) ...) forms, macro expansion, and conditions signaled by the compiler itself.

+Conditions of type error might be signaled by the compiler in situations where the compilation cannot proceed without intervention.

+In addition to situations for which the standard specifies that conditions of type warning must or might be signaled, warnings might be signaled in situations where the compiler can determine that the consequences are undefined or that a run-time error will be signaled. Examples of this situation are as follows: violating type declarations, altering or assigning the value of a constant defined with defconstant, calling built-in Lisp functions with a wrong number of arguments or malformed keyword argument lists, and using unrecognized declaration specifiers.

+The compiler is permitted to issue warnings about matters of programming style as conditions of type style-warning. Examples of this situation are as follows: redefining a function using a different argument list, calling a function with a wrong number of arguments, not declaring ignore of a local variable that is not referenced, and referencing a variable declared ignore.

+Both compile and compile-file are permitted (but not required) to establish a handler for conditions of type error. For example, they might signal a warning, and restart compilation from some implementation-dependent point in order to let the compilation proceed without manual intervention.

+Both compile and compile-file return three values, the second two indicating whether the source code being compiled contained errors and whether style warnings were issued.

+ Some warnings might be deferred until the end of compilation. See with-compilation-unit.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_c.htm new file mode 100644 index 00000000..ee6f4df0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_c.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3 Declarations

+Declarations provide a way of specifying information for use by program processors, such as the evaluator or the compiler.

+Local declarations can be embedded in executable code using declare. Global declarations, or proclamations, are established by proclaim or declaim.

+The the special form provides a shorthand notation for making a local declaration about the type of the value of a given form.

+The consequences are undefined if a program violates a declaration or a proclamation.

+ + +

+3.3.1 Minimal Declaration Processing Requirements

+ +

+3.3.2 Declaration Specifiers

+ +

+3.3.3 Declaration Identifiers

+ +

+3.3.4 Declaration Scope

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ca.htm new file mode 100644 index 00000000..f77a1069 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ca.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 3.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3.1 Minimal Declaration Processing Requirements

+In general, an implementation is free to ignore declaration specifiers except for the declaration, notinline, safety, and special declaration specifiers.

+A declaration declaration must suppress warnings about unrecognized declarations of the kind that it declares. If an implementation does not produce warnings about unrecognized declarations, it may safely ignore this declaration.

+A notinline declaration must be recognized by any implementation that supports inline functions or compiler macros in order to disable those facilities. An implementation that does not use inline functions or compiler macros may safely ignore this declaration.

+A safety declaration that increases the current safety level must always be recognized. An implementation that always processes code as if safety were high may safely ignore this declaration.

+A special declaration must be processed by all implementations.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cb.htm new file mode 100644 index 00000000..63d6d8de --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 3.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3.2 Declaration Specifiers

+A declaration specifier is an expression that can appear at top level of a declare expression or a declaim form, or as the argument to proclaim. It is a list whose car is a declaration identifier, and whose cdr is data interpreted according to rules specific to the declaration identifier.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cc.htm new file mode 100644 index 00000000..dae40a4c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cc.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 3.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3.3 Declaration Identifiers

+The next figure shows a list of all declaration identifiers defined by this standard.

+ 

+declaration     ignore     special  
+dynamic-extent  inline     type     
+ftype           notinline           
+ignorable       optimize            
+
+

Figure 3-9. Common Lisp Declaration Identifiers

+An implementation is free to support other (implementation-defined) declaration identifiers as well. A warning might be issued if a declaration identifier is not among those defined above, is not defined by the implementation, is not a type name, and has not been declared in a declaration proclamation.

+ + +

+3.3.3.1 Shorthand notation for Type Declarations

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cca.htm new file mode 100644 index 00000000..13597290 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cca.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 3.3.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3.3.1 Shorthand notation for Type Declarations

+A type specifier can be used as a declaration identifier. (type-specifier var*) is taken as shorthand for (type type-specifier var*).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cd.htm new file mode 100644 index 00000000..98f80683 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cd.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 3.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3.4 Declaration Scope

+Declarations can be divided into two kinds: those that apply to the bindings of variables or functions; and those that do not apply to bindings.

+A declaration that appears at the head of a binding form and applies to a variable or function binding made by that form is called a bound declaration; such a declaration affects both the binding and any references within the scope of the declaration.

+Declarations that are not bound declarations are called free declarations.

+A free declaration in a form F1 that applies to a binding for a name N established by some form F2 of which F1 is a subform affects only references to N within F1; it does not to apply to other references to N outside of F1, nor does it affect the manner in which the binding of N by F2 is established.

+Declarations that do not apply to bindings can only appear as free declarations.

+ The scope of a bound declaration is the same as the lexical scope of the binding to which it applies; for special variables, this means the scope that the binding would have had had it been a lexical binding.

+Unless explicitly stated otherwise, the scope of a free declaration includes only the body subforms of the form at whose head it appears, and no other subforms. The scope of free declarations specifically does not include initialization forms for bindings established by the form containing the declarations.

+Some iteration forms include step, end-test, or result subforms that are also included in the scope of declarations that appear in the iteration form. Specifically, the iteration forms and subforms involved are:

+

+ + +

+3.3.4.1 Examples of Declaration Scope

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cda.htm new file mode 100644 index 00000000..c60d04fc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_cda.htm @@ -0,0 +1,75 @@ + + + +CLHS: Section 3.3.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.3.4.1 Examples of Declaration Scope

+Here is an example illustrating the scope of bound declarations.

+

+ (let ((x 1))                ;[1] 1st occurrence of x
+   (declare (special x))     ;[2] 2nd occurrence of x
+   (let ((x 2))              ;[3] 3rd occurrence of x
+     (let ((old-x x)         ;[4] 4th occurrence of x
+           (x 3))            ;[5] 5th occurrence of x
+       (declare (special x)) ;[6] 6th occurrence of x
+       (list old-x x))))     ;[7] 7th occurrence of x
+=>  (2 3)
+
+

+The first occurrence of x establishes a dynamic binding of x because of the special declaration for x in the second line. The third occurrence of x establishes a lexical binding of x (because there is no special declaration in the corresponding let form). The fourth occurrence of x x is a reference to the lexical binding of x established in the third line. The fifth occurrence of x establishes a dynamic binding of x for the body of the let form that begins on that line because of the special declaration for x in the sixth line. The reference to x in the fourth line is not affected by the special declaration in the sixth line because that reference is not within the ``would-be lexical scope'' of the variable x in the fifth line. The reference to x in the seventh line is a reference to the dynamic binding of x established in the fifth line.

+Here is another example, to illustrate the scope of a free declaration. In the following:

+

+ (lambda (&optional (x (foo 1))) ;[1]
+   (declare (notinline foo))     ;[2]
+   (foo x))                      ;[3]
+
+

+the call to foo in the first line might be compiled inline even though the call to foo in the third line must not be. This is because the notinline declaration for foo in the second line applies only to the body on the third line. In order to suppress inlining for both calls, one might write:

+

+ (locally (declare (notinline foo)) ;[1]
+   (lambda (&optional (x (foo 1)))  ;[2]
+     (foo x)))                      ;[3]
+
+

+or, alternatively:

+

+ (lambda (&optional                               ;[1]
+            (x (locally (declare (notinline foo)) ;[2]
+                 (foo 1))))                       ;[3]
+   (declare (notinline foo))                      ;[4]
+   (foo x))                                       ;[5]
+
+

+Finally, here is an example that shows the scope of declarations in an iteration form.

+

+ (let ((x  1))                     ;[1]
+   (declare (special x))           ;[2]
+     (let ((x 2))                  ;[3]
+       (dotimes (i x x)            ;[4]
+         (declare (special x)))))  ;[5]
+=>  1
+
+

+In this example, the first reference to x on the fourth line is to the lexical binding of x established on the third line. However, the second occurrence of x on the fourth line lies within the scope of the free declaration on the fifth line (because this is the result-form of the dotimes) and therefore refers to the dynamic binding of x.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_d.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_d.htm new file mode 100644 index 00000000..a4fd7f7c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_d.htm @@ -0,0 +1,95 @@ + + + +CLHS: Section 3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4 Lambda Lists

+A lambda list is a list that specifies a set of parameters (sometimes called lambda variables) and a protocol for receiving values for those parameters.

+There are several kinds of lambda lists.

+

+Context                                      Kind of Lambda List                              
+defun form                                   ordinary lambda list                             
+defmacro form                                macro lambda list                                
+lambda expression                            ordinary lambda list                             
+flet local function definition               ordinary lambda list                             
+labels local function definition             ordinary lambda list                             
+handler-case clause specification            ordinary lambda list                             
+restart-case clause specification            ordinary lambda list                             
+macrolet local macro definition              macro lambda list                                
+define-method-combination                    ordinary lambda list                             
+define-method-combination :arguments option  define-method-combination arguments lambda list  
+defstruct :constructor option                boa lambda list                                  
+defgeneric form                              generic function lambda list                     
+defgeneric method clause                     specialized lambda list                          
+defmethod form                               specialized lambda list                          
+defsetf form                                 defsetf lambda list                              
+define-setf-expander form                    macro lambda list                                
+deftype form                                 deftype lambda list                              
+destructuring-bind form                      destructuring lambda list                        
+define-compiler-macro form                   macro lambda list                                
+define-modify-macro form                     define-modify-macro lambda list                  
+
+

Figure 3-10. What Kind of Lambda Lists to Use

+The next figure lists some defined names that are applicable to lambda lists.

+

+lambda-list-keywords  lambda-parameters-limit    
+
+

Figure 3-11. Defined names applicable to lambda lists

+ + +

+3.4.1 Ordinary Lambda Lists

+ +

+3.4.2 Generic Function Lambda Lists

+ +

+3.4.3 Specialized Lambda Lists

+ +

+3.4.4 Macro Lambda Lists

+ + +

+3.4.5 Destructuring Lambda Lists

+ + +

+3.4.6 Boa Lambda Lists

+ +

+3.4.7 Defsetf Lambda Lists

+ +

+3.4.8 Deftype Lambda Lists

+ + +

+3.4.9 Define-modify-macro Lambda Lists

+ +

+3.4.10 Define-method-combination Arguments Lambda Lists

+ +

+3.4.11 Syntactic Interaction of Documentation Strings and Declarations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_da.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_da.htm new file mode 100644 index 00000000..59e97be6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_da.htm @@ -0,0 +1,75 @@ + + + +CLHS: Section 3.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1 Ordinary Lambda Lists

+An ordinary lambda list is used to describe how a set of arguments is received by an ordinary function. The defined names in the next figure are those which use ordinary lambda lists:

+

+define-method-combination  handler-case  restart-case  
+defun                      labels                      
+flet                       lambda                      
+
+

Figure 3-12. Standardized Operators that use Ordinary Lambda Lists

+An ordinary lambda list can contain the lambda list keywords shown in the next figure.

+

+&allow-other-keys  &key       &rest  
+&aux               &optional         
+
+

Figure 3-13. Lambda List Keywords used by Ordinary Lambda Lists

+Each element of a lambda list is either a parameter specifier or a lambda list keyword. Implementations are free to provide additional lambda list keywords. For a list of all lambda list keywords used by the implementation, see lambda-list-keywords.

+The syntax for ordinary lambda lists is as follows:

+

+lambda-list::= (var* 
+                [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
+                [&rest var] 
+                [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
+                [&aux {var | (var [init-form])}*]) 
+
+

+A var or supplied-p-parameter must be a symbol that is not the name of a constant variable.

+An init-form can be any form. Whenever any init-form is evaluated for any parameter specifier, that form may refer to any parameter variable to the left of the specifier in which the init-form appears, including any supplied-p-parameter variables, and may rely on the fact that no other parameter variable has yet been bound (including its own parameter variable).

+A keyword-name can be any symbol, but by convention is normally a keyword[1]; all standardized functions follow that convention.

+An ordinary lambda list has five parts, any or all of which may be empty. For information about the treatment of argument mismatches, see Section 3.5 (Error Checking in Function Calls).

+ + +

+3.4.1.1 Specifiers for the required parameters

+ + +

+3.4.1.2 Specifiers for optional parameters

+ +

+3.4.1.3 A specifier for a rest parameter

+ + +

+3.4.1.4 Specifiers for keyword parameters

+ +

+3.4.1.5 Specifiers for &aux variables

+ +

+3.4.1.6 Examples of Ordinary Lambda Lists

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daa.htm new file mode 100644 index 00000000..03327f21 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 3.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.1 Specifiers for the required parameters

+These are all the parameter specifiers up to the first lambda list keyword; if there are no lambda list keywords, then all the specifiers are for required parameters. Each required parameter is specified by a parameter variable var. var is bound as a lexical variable unless it is declared special.

+If there are n required parameters (n may be zero), there must be at least n passed arguments, and the required parameters are bound to the first n passed arguments; see Section 3.5 (Error Checking in Function Calls). The other parameters are then processed using any remaining arguments.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dab.htm new file mode 100644 index 00000000..c3d5c385 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 3.4.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.2 Specifiers for optional parameters

+If &optional is present, the optional parameter specifiers are those following &optional up to the next lambda list keyword or the end of the list. If optional parameters are specified, then each one is processed as follows. If any unprocessed arguments remain, then the parameter variable var is bound to the next remaining argument, just as for a required parameter. If no arguments remain, however, then init-form is evaluated, and the parameter variable is bound to the resulting value (or to nil if no init-form appears in the parameter specifier). If another variable name supplied-p-parameter appears in the specifier, it is bound to true if an argument had been available, and to false if no argument remained (and therefore init-form had to be evaluated). Supplied-p-parameter is bound not to an argument but to a value indicating whether or not an argument had been supplied for the corresponding var.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dac.htm new file mode 100644 index 00000000..1759bf31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dac.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 3.4.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.3 A specifier for a rest parameter

+&rest, if present, must be followed by a single rest parameter specifier, which in turn must be followed by another lambda list keyword or the end of the lambda list. After all optional parameter specifiers have been processed, then there may or may not be a rest parameter. If there is a rest parameter, it is bound to a list of all as-yet-unprocessed arguments. If no unprocessed arguments remain, the rest parameter is bound to the empty list. If there is no rest parameter and there are no keyword parameters, then an error should be signaled if any unprocessed arguments remain; see Section 3.5 (Error Checking in Function Calls). The value of a rest parameter is permitted, but not required, to share structure with the last argument to apply.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dad.htm new file mode 100644 index 00000000..cf765191 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dad.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 3.4.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.4 Specifiers for keyword parameters

+ If &key is present, all specifiers up to the next lambda list keyword or the end of the list are keyword parameter specifiers. When keyword parameters are processed, the same arguments are processed that would be made into a list for a rest parameter. It is permitted to specify both &rest and &key. In this case the remaining arguments are used for both purposes; that is, all remaining arguments are made into a list for the rest parameter, and are also processed for the &key parameters. If &key is specified, there must remain an even number of arguments; see Section 3.5.1.6 (Odd Number of Keyword Arguments). These arguments are considered as pairs, the first argument in each pair being interpreted as a name and the second as the corresponding value. The first object of each pair must be a symbol; see Section 3.5.1.5 (Invalid Keyword Arguments). The keyword parameter specifiers may optionally be followed by the lambda list keyword &allow-other-keys.

+In each keyword parameter specifier must be a name var for the parameter variable. If the var appears alone or in a (var init-form) combination, the keyword name used when matching arguments to parameters is a symbol in the KEYWORD package whose name is the same (under string=) as var's. If the notation ((keyword-name var) init-form) is used, then the keyword name used to match arguments to parameters is keyword-name, which may be a symbol in any package. (Of course, if it is not a symbol in the KEYWORD package, it does not necessarily self-evaluate, so care must be taken when calling the function to make sure that normal evaluation still yields the keyword name.) Thus

+

+ (defun foo (&key radix (type 'integer)) ...)
+
+ means exactly the same as

+

+ (defun foo (&key ((:radix radix)) ((:type type) 'integer)) ...)
+
+

+The keyword parameter specifiers are, like all parameter specifiers, effectively processed from left to right. For each keyword parameter specifier, if there is an argument pair whose name matches that specifier's name (that is, the names are eq), then the parameter variable for that specifier is bound to the second item (the value) of that argument pair. If more than one such argument pair matches, the leftmost argument pair is used. If no such argument pair exists, then the init-form for that specifier is evaluated and the parameter variable is bound to that value (or to nil if no init-form was specified). supplied-p-parameter is treated as for &optional parameters: it is bound to true if there was a matching argument pair, and to false otherwise.

+Unless keyword argument checking is suppressed, an argument pair must a name matched by a parameter specifier; see Section 3.5.1.4 (Unrecognized Keyword Arguments).

+If keyword argument checking is suppressed, then it is permitted for an argument pair to match no parameter specifier, and the argument pair is ignored, but such an argument pair is accessible through the rest parameter if one was supplied. The purpose of these mechanisms is to allow sharing of argument lists among several lambda expressions and to allow either the caller or the called lambda expression to specify that such sharing may be taking place.

+ Note that if &key is present, a keyword argument of :allow-other-keys is always permitted---regardless of whether the associated value is true or false. However, if the value is false, other non-matching keywords are not tolerated (unless &allow-other-keys was used).

+Furthermore, if the receiving argument list specifies a regular argument which would be flagged by :allow-other-keys, then :allow-other-keys has both its special-cased meaning (identifying whether additional keywords are permitted) and its normal meaning (data flow into the function in question).

+ + +

+3.4.1.4.1 Suppressing Keyword Argument Checking

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dada.htm new file mode 100644 index 00000000..2bdaebd3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dada.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 3.4.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.4.1 Suppressing Keyword Argument Checking

+If &allow-other-keys was specified in the lambda list of a function, keyword[2] argument checking is suppressed in calls to that function.

+If the :allow-other-keys argument is true in a call to a function, keyword[2] argument checking is suppressed in that call.

+The :allow-other-keys argument is permissible in all situations involving keyword[2] arguments, even when its associated value is false.

+ + +

+3.4.1.4.1.1 Examples of Suppressing Keyword Argument Checking

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dadaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dadaa.htm new file mode 100644 index 00000000..f466a65d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dadaa.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 3.4.1.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.4.1.1 Examples of Suppressing Keyword Argument Checking

+

+;;; The caller can supply :ALLOW-OTHER-KEYS T to suppress checking.
+ ((lambda (&key x) x) :x 1 :y 2 :allow-other-keys t) =>  1
+;;; The callee can use &ALLOW-OTHER-KEYS to suppress checking.
+ ((lambda (&key x &allow-other-keys) x) :x 1 :y 2) =>  1
+;;; :ALLOW-OTHER-KEYS NIL is always permitted.
+ ((lambda (&key) t) :allow-other-keys nil) =>  T
+;;; As with other keyword arguments, only the left-most pair
+;;; named :ALLOW-OTHER-KEYS has any effect.
+ ((lambda (&key x) x) 
+  :x 1 :y 2 :allow-other-keys t :allow-other-keys nil)
+=>  1
+;;; Only the left-most pair named :ALLOW-OTHER-KEYS has any effect,
+;;; so in safe code this signals a PROGRAM-ERROR (and might enter the
+;;; debugger).  In unsafe code, the consequences are undefined.
+ ((lambda (&key x) x)                   ;This call is not valid
+  :x 1 :y 2 :allow-other-keys nil :allow-other-keys t)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dae.htm new file mode 100644 index 00000000..ca0973b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dae.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 3.4.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.5 Specifiers for &aux variables

+These are not really parameters. If the lambda list keyword &aux is present, all specifiers after it are auxiliary variable specifiers. After all parameter specifiers have been processed, the auxiliary variable specifiers (those following &aux) are processed from left to right. For each one, init-form is evaluated and var is bound to that value (or to nil if no init-form was specified). &aux variable processing is analogous to let* processing.

+

+ (lambda (x y &aux (a (car x)) (b 2) c) (list x y a b c))
+    ==  (lambda (x y) (let* ((a (car x)) (b 2) c) (list x y a b c)))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daf.htm new file mode 100644 index 00000000..16ab2bff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_daf.htm @@ -0,0 +1,92 @@ + + + +CLHS: Section 3.4.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.1.6 Examples of Ordinary Lambda Lists

+Here are some examples involving optional parameters and rest parameters:

+

+ ((lambda (a b) (+ a (* b 3))) 4 5) =>  19
+ ((lambda (a &optional (b 2)) (+ a (* b 3))) 4 5) =>  19
+ ((lambda (a &optional (b 2)) (+ a (* b 3))) 4) =>  10
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)))
+=>  (2 NIL 3 NIL NIL)
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)) 6)
+=>  (6 T 3 NIL NIL)
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)) 6 3)
+=>  (6 T 3 T NIL)
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)) 6 3 8)
+=>  (6 T 3 T (8))
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x))
+  6 3 8 9 10 11)
+=>  (6 t 3 t (8 9 10 11))
+
+

+Here are some examples involving keyword parameters:

+

+ ((lambda (a b &key c d) (list a b c d)) 1 2) =>  (1 2 NIL NIL)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :c 6) =>  (1 2 6 NIL)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :d 8) =>  (1 2 NIL 8)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :c 6 :d 8) =>  (1 2 6 8)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :d 8 :c 6) =>  (1 2 6 8)
+ ((lambda (a b &key c d) (list a b c d)) :a 1 :d 8 :c 6) =>  (:a 1 6 8)
+ ((lambda (a b &key c d) (list a b c d)) :a :b :c :d) =>  (:a :b :d NIL)
+ ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6) =>  (1 2 6 NIL)
+ ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6) =>  (1 2 6 NIL)
+
+

+Here are some examples involving optional parameters, rest parameters, and keyword parameters together:

+

+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1)   
+=>  (1 3 NIL 1 ()) 
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 2)
+=>  (1 2 NIL 1 ())
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) :c 7)
+=>  (:c 7 NIL :c ())
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 6 :c 7)
+=>  (1 6 7 1 (:c 7))
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 6 :d 8)
+=>  (1 6 NIL 8 (:d 8))
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 6 :d 8 :c 9 :d 10)
+=>  (1 6 9 8 (:d 8 :c 9 :d 10))
+
+

+As an example of the use of &allow-other-keys and :allow-other-keys, consider a function that takes two named arguments of its own and also accepts additional named arguments to be passed to make-array:

+

+ (defun array-of-strings (str dims &rest named-pairs
+                          &key (start 0) end &allow-other-keys)
+   (apply #'make-array dims
+          :initial-element (subseq str start end)
+          :allow-other-keys t
+          named-pairs))
+
+

+This function takes a string and dimensioning information and returns an array of the specified dimensions, each of whose elements is the specified string. However, :start and :end named arguments may be used to specify that a substring of the given string should be used. In addition, the presence of &allow-other-keys in the lambda list indicates that the caller may supply additional named arguments; the rest parameter provides access to them. These additional named arguments are passed to make-array. The function make-array normally does not allow the named arguments :start and :end to be used, and an error should be signaled if such named arguments are supplied to make-array. However, the presence in the call to make-array of the named argument :allow-other-keys with a true value causes any extraneous named arguments, including :start and :end, to be acceptable and ignored.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_db.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_db.htm new file mode 100644 index 00000000..90844f69 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_db.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 3.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.2 Generic Function Lambda Lists

+A generic function lambda list is used to describe the overall shape of the argument list to be accepted by a generic function. Individual method signatures might contribute additional keyword parameters to the lambda list of the effective method.

+A generic function lambda list is used by defgeneric.

+A generic function lambda list has the following syntax:

+

+lambda-list::= (var* 
+                [&optional {var | (var)}*] 
+                [&rest var] 
+                [&key {var | ({var | (keyword-name var)})}* [&allow-other-keys]]) 
+
+

+A generic function lambda list can contain the lambda list keywords shown in the next figure.

+

+&allow-other-keys  &optional    
+&key               &rest        
+
+

Figure 3-14. Lambda List Keywords used by Generic Function Lambda Lists

+A generic function lambda list differs from an ordinary lambda list in the following ways:

+

Required arguments

+Zero or more required parameters must be specified.

+

Optional and keyword arguments

+Optional parameters and keyword parameters may not have default initial value forms nor use supplied-p parameters.

+

Use of &aux

+The use of &aux is not allowed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dc.htm new file mode 100644 index 00000000..33e41c41 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dc.htm @@ -0,0 +1,48 @@ + + + +CLHS: Section 3.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.3 Specialized Lambda Lists

+A specialized lambda list is used to specialize a method for a particular signature and to describe how arguments matching that signature are received by the method. The defined names in the next figure use specialized lambda lists in some way; see the dictionary entry for each for information about how.

+ 

+defmethod  defgeneric    
+
+

Figure 3-15. Standardized Operators that use Specialized Lambda Lists

+A specialized lambda list can contain the lambda list keywords shown in the next figure.

+

+&allow-other-keys  &key       &rest  
+&aux               &optional         
+
+

Figure 3-16. Lambda List Keywords used by Specialized Lambda Lists

+A specialized lambda list is syntactically the same as an ordinary lambda list except that each required parameter may optionally be associated with a class or object for which that parameter is specialized.

+

+lambda-list::= ({var | (var [specializer])}* 
+                [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
+                [&rest var] 
+                [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
+                [&aux {var | (var [init-form])}*]) 
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dd.htm new file mode 100644 index 00000000..e954a4e3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dd.htm @@ -0,0 +1,84 @@ + + + +CLHS: Section 3.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.4 Macro Lambda Lists

+A macro lambda list is used in describing macros defined by the operators in the next figure.

+

+define-compiler-macro  defmacro  macrolet  
+define-setf-expander                       
+
+

Figure 3-17. Operators that use Macro Lambda Lists

+With the additional restriction that an environment parameter may appear only once (at any of the positions indicated), a macro lambda list has the following syntax:

+

+reqvars::= var* 
+
+ 
+optvars::= [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
+
+ 
+restvar::= [{&rest | &body} var] 
+
+ 
+keyvars::= [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* 
+            [&allow-other-keys]] 
+
+ 
+auxvars::= [&aux {var | (var [init-form])}*] 
+
+ 
+envvar::= [&environment var] 
+
+ 
+wholevar::= [&whole var] 
+
+ 
+lambda-list::= (wholevar envvar  reqvars envvar  optvars envvar 
+                restvar envvar  keyvars envvar  auxvars envvar) | 
+               (wholevar envvar  reqvars envvar  optvars envvar .  var) 
+
+ 
+pattern::= (wholevar reqvars optvars restvar keyvars auxvars) | 
+           (wholevar reqvars optvars . var) 
+
+

+A macro lambda list can contain the lambda list keywords shown in the next figure.

+

+&allow-other-keys  &environment  &rest   
+&aux               &key          &whole  
+&body              &optional             
+
+

Figure 3-18. Lambda List Keywords used by Macro Lambda Lists

+Optional parameters (introduced by &optional) and keyword parameters (introduced by &key) can be supplied in a macro lambda list, just as in an ordinary lambda list. Both may contain default initialization forms and supplied-p parameters.

+&body is identical in function to &rest, but it can be used to inform certain output-formatting and editing functions that the remainder of the form is treated as a body, and should be indented accordingly. Only one of &body or &rest can be used at any particular level; see Section 3.4.4.1 (Destructuring by Lambda Lists). &body can appear at any level of a macro lambda list; for details, see Section 3.4.4.1 (Destructuring by Lambda Lists).

+&whole is followed by a single variable that is bound to the entire macro-call form; this is the value that the macro function receives as its first argument. If &whole and a following variable appear, they must appear first in lambda-list, before any other parameter or lambda list keyword. &whole can appear at any level of a macro lambda list. At inner levels, the &whole variable is bound to the corresponding part of the argument, as with &rest, but unlike &rest, other arguments are also allowed. The use of &whole does not affect the pattern of arguments specified.

+&environment is followed by a single variable that is bound to an environment representing the lexical environment in which the macro call is to be interpreted. This environment should be used with macro-function, get-setf-expansion, compiler-macro-function, and macroexpand (for example) in computing the expansion of the macro, to ensure that any lexical bindings or definitions established in the compilation environment are taken into account. &environment can only appear at the top level of a macro lambda list, and can only appear once, but can appear anywhere in that list; the &environment parameter is bound along with &whole before any other variables in the lambda list, regardless of where &environment appears in the lambda list. The object that is bound to the environment parameter has dynamic extent.

+Destructuring allows a macro lambda list to express the structure of a macro call syntax. If no lambda list keywords appear, then the macro lambda list is a tree containing parameter names at the leaves. The pattern and the macro form must have compatible tree structure; that is, their tree structure must be equivalent, or it must differ only in that some leaves of the pattern match non-atomic objects of the macro form. For information about error detection in this situation, see Section 3.5.1.7 (Destructuring Mismatch).

+ A destructuring lambda list (whether at top level or embedded) can be dotted, ending in a parameter name. This situation is treated exactly as if the parameter name that ends the list had appeared preceded by &rest.

+ It is permissible for a macro form (or a subexpression of a macro form) to be a dotted list only when (... &rest var) or (... . var) is used to match it. It is the responsibility of the macro to recognize and deal with such situations.

+ + +

+3.4.4.1 Destructuring by Lambda Lists

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dda.htm new file mode 100644 index 00000000..af88c7f8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dda.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 3.4.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.4.1 Destructuring by Lambda Lists

+Anywhere in a macro lambda list where a parameter name can appear, and where ordinary lambda list syntax (as described in Section 3.4.1 (Ordinary Lambda Lists)) does not otherwise allow a list, a destructuring lambda list can appear in place of the parameter name. When this is done, then the argument that would match the parameter is treated as a (possibly dotted) list, to be used as an argument list for satisfying the parameters in the embedded lambda list. This is known as destructuring.

+Destructuring is the process of decomposing a compound object into its component parts, using an abbreviated, declarative syntax, rather than writing it out by hand using the primitive component-accessing functions. Each component part is bound to a variable.

+ A destructuring operation requires an object to be decomposed, a pattern that specifies what components are to be extracted, and the names of the variables whose values are to be the components.

+ + +

+3.4.4.1.1 Data-directed Destructuring by Lambda Lists

+ +

+3.4.4.1.2 Lambda-list-directed Destructuring by Lambda Lists

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaa.htm new file mode 100644 index 00000000..172844c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.4.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.4.1.1 Data-directed Destructuring by Lambda Lists

+In data-directed destructuring, the pattern is a sample object of the type to be decomposed. Wherever a component is to be extracted, a symbol appears in the pattern; this symbol is the name of the variable whose value will be that component.

+ + +

+3.4.4.1.1.1 Examples of Data-directed Destructuring by Lambda Lists

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaaa.htm new file mode 100644 index 00000000..2d6a5bc9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddaaa.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 3.4.4.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.4.1.1.1 Examples of Data-directed Destructuring by Lambda Lists

+An example pattern is

+(a b c)

+which destructures a list of three elements. The variable a is assigned to the first element, b to the second, etc. A more complex example is

+((first . rest) . more)

+The important features of data-directed destructuring are its syntactic simplicity and the ability to extend it to lambda-list-directed destructuring.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddab.htm new file mode 100644 index 00000000..455ea6fb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ddab.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 3.4.4.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.4.1.2 Lambda-list-directed Destructuring by Lambda Lists

+An extension of data-directed destructuring of trees is lambda-list-directed destructuring. This derives from the analogy between the three-element destructuring pattern

+(first second third)

+and the three-argument lambda list

+(first second third)

+Lambda-list-directed destructuring is identical to data-directed destructuring if no lambda list keywords appear in the pattern. Any list in the pattern (whether a sub-list or the whole pattern itself) that contains a lambda list keyword is interpreted specially. Elements of the list to the left of the first lambda list keyword are treated as destructuring patterns, as usual, but the remaining elements of the list are treated like a function's lambda list except that where a variable would normally be required, an arbitrary destructuring pattern is allowed. Note that in case of ambiguity, lambda list syntax is preferred over destructuring syntax. Thus, after &optional a list of elements is a list of a destructuring pattern and a default value form.

+The detailed behavior of each lambda list keyword in a lambda-list-directed destructuring pattern is as follows:

+

&optional

+Each following element is a variable or a list of a destructuring pattern, a default value form, and a supplied-p variable. The default value and the supplied-p variable can be omitted. If the list being destructured ends early, so that it does not have an element to match against this destructuring (sub)-pattern, the default form is evaluated and destructured instead. The supplied-p variable receives the value nil if the default form is used, t otherwise.

+

&rest, &body

+The next element is a destructuring pattern that matches the rest of the list. &body is identical to &rest but declares that what is being matched is a list of forms that constitutes the body of form. This next element must be the last unless a lambda list keyword follows it.

+

&aux

+The remaining elements are not destructuring patterns at all, but are auxiliary variable bindings.

+

&whole

+The next element is a destructuring pattern that matches the entire form in a macro, or the entire subexpression at inner levels.

+

&key

+Each following element is one of

+

a variable,

+
or a list of a variable, an optional initialization form, and an optional supplied-p variable.

+
or a list of a list of a keyword and a destructuring pattern, an optional initialization form, and an optional supplied-p variable.

The rest of the list being destructured is taken to be alternating keywords and values and is taken apart appropriately.

+

&allow-other-keys

+Stands by itself.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_de.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_de.htm new file mode 100644 index 00000000..9877fc51 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_de.htm @@ -0,0 +1,58 @@ + + + +CLHS: Section 3.4.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.5 Destructuring Lambda Lists

+A destructuring lambda list is used by destructuring-bind.

+Destructuring lambda lists are closely related to macro lambda lists; see Section 3.4.4 (Macro Lambda Lists). A destructuring lambda list can contain all of the lambda list keywords listed for macro lambda lists except for &environment, and supports destructuring in the same way. Inner lambda lists nested within a macro lambda list have the syntax of destructuring lambda lists.

+A destructuring lambda list has the following syntax:

+

+reqvars::= var* 
+
+ 
+optvars::= [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
+
+ 
+restvar::= [{&rest | &body} var] 
+
+ 
+keyvars::= [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* 
+            [&allow-other-keys]] 
+
+ 
+auxvars::= [&aux {var | (var [init-form])}*] 
+
+ 
+envvar::= [&environment var] 
+
+ 
+wholevar::= [&whole var] 
+
+ 
+lambda-list::= (wholevar reqvars optvars restvar keyvars auxvars) | 
+               (wholevar reqvars optvars . var) 
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_df.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_df.htm new file mode 100644 index 00000000..0bd24f65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_df.htm @@ -0,0 +1,71 @@ + + + +CLHS: Section 3.4.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.6 Boa Lambda Lists

+A boa lambda list is a lambda list that is syntactically like an ordinary lambda list, but that is processed in ``by order of argument'' style.

+A boa lambda list is used only in a defstruct form, when explicitly specifying the lambda list of a constructor function (sometimes called a ``boa constructor'').

+The &optional, &rest, &aux, &key, and &allow-other-keys lambda list keywords are recognized in a boa lambda list. The way these lambda list keywords differ from their use in an ordinary lambda list follows.

+Consider this example, which describes how destruct processes its :constructor option.

+

+ (:constructor create-foo
+         (a &optional b (c 'sea) &rest d &aux e (f 'eff)))
+
+

+This defines create-foo to be a constructor of one or more arguments. The first argument is used to initialize the a slot. The second argument is used to initialize the b slot. If there isn't any second argument, then the default value given in the body of the defstruct (if given) is used instead. The third argument is used to initialize the c slot. If there isn't any third argument, then the symbol sea is used instead. Any arguments following the third argument are collected into a list and used to initialize the d slot. If there are three or fewer arguments, then nil is placed in the d slot. The e slot is not initialized; its initial value is implementation-defined. Finally, the f slot is initialized to contain the symbol eff. &key and &allow-other-keys arguments default in a manner similar to that of &optional arguments: if no default is supplied in the lambda list then the default value given in the body of the defstruct (if given) is used instead. For example:

+

+ (defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
+                                             &key (d 2)
+                                             &aux e (f 'eff))))
+   (a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
+ 
+ (create-foo 10) =>  #S(FOO A 10 B 2 C SEA D 2 E implemention-dependent F EFF)
+ (create-foo 10 'bee 'see :d 'dee) 
+=>  #S(FOO A 10 B BEE C SEE D DEE E implemention-dependent F EFF)
+
+

+If keyword arguments of the form ((key var) [default [svar]]) are specified, the slot name is matched with var (not key).

+The actions taken in the b and e cases were carefully chosen to allow the user to specify all possible behaviors. The &aux variables can be used to completely override the default initializations given in the body.

+ If no default value is supplied for an aux variable variable, the consequences are undefined if an attempt is later made to read the corresponding slot's value before a value is explicitly assigned. If such a slot has a :type option specified, this suppressed initialization does not imply a type mismatch situation; the declared type is only required to apply when the slot is finally assigned.

+With this definition, the following can be written:

+

+ (create-foo 1 2)
+
+ instead of

+

+ (make-foo :a 1 :b 2)
+
+ and create-foo provides defaulting different from that of make-foo.

+Additional arguments that do not correspond to slot names but are merely present to supply values used in subsequent initialization computations are allowed. For example, in the definition

+

+ (defstruct (frob (:constructor create-frob
+                  (a &key (b 3 have-b) (c-token 'c) 
+                          (c (list c-token (if have-b 7 2))))))
+         a b c)
+
+

+the c-token argument is used merely to supply a value used in the initialization of the c slot. The supplied-p parameters associated with optional parameters and keyword parameters might also be used this way.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dg.htm new file mode 100644 index 00000000..2b16543f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dg.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 3.4.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.7 Defsetf Lambda Lists

+A defsetf lambda list is used by defsetf.

+A defsetf lambda list has the following syntax:

+

+lambda-list::= (var* 
+                [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
+                [&rest var] 
+                [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
+                [&environment var] 
+
+

+A defsetf lambda list can contain the lambda list keywords shown in the next figure.

+

+&allow-other-keys  &key       &rest  
+&environment       &optional         
+
+

Figure 3-19. Lambda List Keywords used by Defsetf Lambda Lists

+A defsetf lambda list differs from an ordinary lambda list only in that it does not permit the use of &aux, and that it permits use of &environment, which introduces an environment parameter.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dh.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dh.htm new file mode 100644 index 00000000..6242e4f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dh.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.4.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.8 Deftype Lambda Lists

+A deftype lambda list is used by deftype.

+A deftype lambda list has the same syntax as a macro lambda list, and can therefore contain the lambda list keywords as a macro lambda list.

+ A deftype lambda list differs from a macro lambda list only in that if no init-form is supplied for an optional parameter or keyword parameter in the lambda-list, the default value for that parameter is the symbol * (rather than nil).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_di.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_di.htm new file mode 100644 index 00000000..def731a6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_di.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 3.4.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.9 Define-modify-macro Lambda Lists

+A define-modify-macro lambda list is used by define-modify-macro.

+A define-modify-macro lambda list can contain the lambda list keywords shown in the next figure.

+

+&optional  &rest  
+
+

Figure 3-20. Lambda List Keywords used by Define-modify-macro Lambda Lists

+Define-modify-macro lambda lists are similar to ordinary lambda lists, but do not support keyword arguments. define-modify-macro has no need match keyword arguments, and a rest parameter is sufficient. Aux variables are also not supported, since define-modify-macro has no body forms which could refer to such bindings. See the macro define-modify-macro.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dj.htm new file mode 100644 index 00000000..f1bb56a6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dj.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 3.4.10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.10 Define-method-combination Arguments Lambda Lists

+A define-method-combination arguments lambda list is used by the :arguments option to define-method-combination.

+A define-method-combination arguments lambda list can contain the lambda list keywords shown in the next figure.

+

+&allow-other-keys  &key       &rest   
+&aux               &optional  &whole  
+
+

Figure 3-21. Lambda List Keywords used by Define-method-combination arguments Lambda Lists

+Define-method-combination arguments lambda lists are similar to ordinary lambda lists, but also permit the use of &whole.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dk.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dk.htm new file mode 100644 index 00000000..f31fed9f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_dk.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 3.4.11 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.4.11 Syntactic Interaction of Documentation Strings and Declarations

+In a number of situations, a documentation string can appear amidst a series of declare expressions prior to a series of forms.

+In that case, if a string S appears where a documentation string is permissible and is not followed by either a declare expression or a form then S is taken to be a form; otherwise, S is taken as a documentation string. The consequences are unspecified if more than one such documentation string is present.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_e.htm new file mode 100644 index 00000000..46b74b6d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_e.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5 Error Checking in Function Calls

+

+ + +

+3.5.1 Argument Mismatch Detection

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ea.htm new file mode 100644 index 00000000..245bced9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ea.htm @@ -0,0 +1,52 @@ + + + +CLHS: Section 3.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1 Argument Mismatch Detection

+ + +

+3.5.1.1 Safe and Unsafe Calls

+ +

+3.5.1.2 Too Few Arguments

+ +

+3.5.1.3 Too Many Arguments

+ +

+3.5.1.4 Unrecognized Keyword Arguments

+ +

+3.5.1.5 Invalid Keyword Arguments

+ +

+3.5.1.6 Odd Number of Keyword Arguments

+ +

+3.5.1.7 Destructuring Mismatch

+ +

+3.5.1.8 Errors When Calling a Next Method

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaa.htm new file mode 100644 index 00000000..618a38d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaa.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 3.5.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.1 Safe and Unsafe Calls

+A call is a safe call if each of the following is either safe code or system code (other than system code that results from macro expansion of programmer code):

* the call.
* the definition of the function being called.
* the point of functional evaluation

+The following special cases require some elaboration:

+

* If the function being called is a generic function, it is considered safe if all of the following are safe code or system code:

+

-- its definition (if it was defined explicitly).
-- the method definitions for all applicable methods.
-- the definition of its method combination.

+

* For the form (coerce x 'function), where x is a lambda expression, the value of the optimize quality safety in the global environment at the time the coerce is executed applies to the resulting function.

+

+

+

* For a call to the function ensure-generic-function, the value of the optimize quality safety in the environment object passed as the :environment argument applies to the resulting generic function.

+
* For a call to compile with a lambda expression as the argument, the value of the optimize quality safety in the global environment at the time compile is called applies to the resulting compiled function.

+
* For a call to compile with only one argument, if the original definition of the function was safe, then the resulting compiled function must also be safe.

+
* A call to a method by call-next-method must be considered safe if each of the following is safe code or system code:

+

-- the definition of the generic function (if it was defined explicitly).
-- the method definitions for all applicable methods.
-- the definition of the method combination.
-- the point of entry into the body of the method defining form, where the binding of call-next-method is established.
-- the point of functional evaluation of the name call-next-method.

+

+An unsafe call is a call that is not a safe call.

+The informal intent is that the programmer can rely on a call to be safe, even when system code is involved, if all reasonable steps have been taken to ensure that the call is safe. For example, if a programmer calls mapcar from safe code and supplies a function that was compiled as safe, the implementation is required to ensure that mapcar makes a safe call as well.

+ + +

+3.5.1.1.1 Error Detection Time in Safe Calls

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaaa.htm new file mode 100644 index 00000000..b022802e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 3.5.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.1.1 Error Detection Time in Safe Calls

+If an error is signaled in a safe call, the exact point of the signal is implementation-dependent. In particular, it might be signaled at compile time or at run time, and if signaled at run time, it might be prior to, during, or after executing the call. However, it is always prior to the execution of the body of the function being called.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eab.htm new file mode 100644 index 00000000..c66c4b07 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eab.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.5.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.2 Too Few Arguments

+It is not permitted to supply too few arguments to a function. Too few arguments means fewer arguments than the number of required parameters for the function.

+ If this situation occurs in a safe call, an error of type program-error must be signaled; and in an unsafe call the situation has undefined consequences.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eac.htm new file mode 100644 index 00000000..c1d005cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eac.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.5.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.3 Too Many Arguments

+It is not permitted to supply too many arguments to a function. Too many arguments means more arguments than the number of required parameters plus the number of optional parameters; however, if the function uses &rest or &key, it is not possible for it to receive too many arguments.

+ If this situation occurs in a safe call, an error of type program-error must be signaled; and in an unsafe call the situation has undefined consequences.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ead.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ead.htm new file mode 100644 index 00000000..4aace29b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ead.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.5.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.4 Unrecognized Keyword Arguments

+It is not permitted to supply a keyword argument to a function using a name that is not recognized by that function unless keyword argument checking is suppressed as described in Section 3.4.1.4.1 (Suppressing Keyword Argument Checking).

+ If this situation occurs in a safe call, an error of type program-error must be signaled; and in an unsafe call the situation has undefined consequences.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eae.htm new file mode 100644 index 00000000..44cb27cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eae.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.5.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.5 Invalid Keyword Arguments

+It is not permitted to supply a keyword argument to a function using a name that is not a symbol.

+ If this situation occurs in a safe call, an error of type program-error must be signaled unless keyword argument checking is suppressed as described in Section 3.4.1.4.1 (Suppressing Keyword Argument Checking); and in an unsafe call the situation has undefined consequences.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaf.htm new file mode 100644 index 00000000..ca641dc6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eaf.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 3.5.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.6 Odd Number of Keyword Arguments

+

+An odd number of arguments must not be supplied for the keyword parameters.

+ If this situation occurs in a safe call, an error of type program-error must be signaled unless keyword argument checking is suppressed as described in Section 3.4.1.4.1 (Suppressing Keyword Argument Checking); and in an unsafe call the situation has undefined consequences.

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eag.htm new file mode 100644 index 00000000..bc42e396 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eag.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 3.5.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.7 Destructuring Mismatch

+

+When matching a destructuring lambda list against a form, the pattern and the form must have compatible tree structure, as described in Section 3.4.4 (Macro Lambda Lists).

+Otherwise, in a safe call, an error of type program-error must be signaled; and in an unsafe call the situation has undefined consequences.

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eah.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eah.htm new file mode 100644 index 00000000..7a4bab3a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_eah.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 3.5.1.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.5.1.8 Errors When Calling a Next Method

+If call-next-method is called with arguments, the ordered set of applicable methods for the changed set of arguments for call-next-method must be the same as the ordered set of applicable methods for the original arguments to the generic function, or else an error should be signaled.

+The comparison between the set of methods applicable to the new arguments and the set applicable to the original arguments is insensitive to order differences among methods with the same specializers.

+If call-next-method is called with arguments that specify a different ordered set of applicable methods and there is no next method available, the test for different methods and the associated error signaling (when present) takes precedence over calling no-next-method.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_f.htm new file mode 100644 index 00000000..6cf8188e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_f.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 3.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.6 Traversal Rules and Side Effects

+

+The consequences are undefined when code executed during an object-traversing operation destructively modifies the object in a way that might affect the ongoing traversal operation. In particular, the following rules apply.

List traversal

+ For list traversal operations, the cdr chain of the list is not allowed to be destructively modified.

+

Array traversal

+ For array traversal operations, the array is not allowed to be adjusted and its fill pointer, if any, is not allowed to be changed.

+

Hash-table traversal

+ For hash table traversal operations, new elements may not be added or deleted except that the element corresponding to the current hash key may be changed or removed.

+

Package traversal

+ For package traversal operations (e.g., do-symbols), new symbols may not be interned in or uninterned from the package being traversed or any package that it uses except that the current symbol may be uninterned from the package being traversed.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_g.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_g.htm new file mode 100644 index 00000000..bc07c61e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_g.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 3.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.7 Destructive Operations

+ + +

+3.7.1 Modification of Literal Objects

+ + +

+3.7.2 Transfer of Control during a Destructive Operation

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ga.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ga.htm new file mode 100644 index 00000000..28f3d801 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_ga.htm @@ -0,0 +1,57 @@ + + + +CLHS: Section 3.7.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.7.1 Modification of Literal Objects

+The consequences are undefined if literal objects are destructively modified. For this purpose, the following operations are considered destructive:

+

+

random-state

+Using it as an argument to the function random.

+

cons

+Changing the car[1] or cdr[1] of the cons, or performing a destructive operation on an object which is either the car[2] or the cdr[2] of the cons.

+

array

+Storing a new value into some element of the array, or performing a destructive operation on an object that is already such an element.

+Changing the fill pointer, dimensions, or displacement of the array (regardless of whether the array is actually adjustable).

+Performing a destructive operation on another array that is displaced to the array or that otherwise shares its contents with the array.

+

hash-table

+Performing a destructive operation on any key.

+Storing a new value[4] for any key, or performing a destructive operation on any object that is such a value.

+Adding or removing entries from the hash table.

+

structure-object

+Storing a new value into any slot, or performing a destructive operation on an object that is the value of some slot.

+

standard-object

+Storing a new value into any slot, or performing a destructive operation on an object that is the value of some slot.

+Changing the class of the object (e.g., using the function change-class).

+

readtable

+Altering the readtable case.

+Altering the syntax type of any character in this readtable.

+Altering the reader macro function associated with any character in the readtable, or altering the reader macro functions associated with characters defined as dispatching macro characters in the readtable.

+

stream

+Performing I/O operations on the stream, or closing the stream.

+

All other standardized types

+ [This category includes, for example, character, condition, function, method-combination, method, number, package, pathname, restart, and symbol.]

+There are no standardized destructive operations defined on objects of these types.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gb.htm new file mode 100644 index 00000000..6d0042ac --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 3.7.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.7.2 Transfer of Control during a Destructive Operation

+Should a transfer of control out of a destructive operation occur (e.g., due to an error) the state of the object being modified is implementation-dependent.

+ + +

+3.7.2.1 Examples of Transfer of Control during a Destructive Operation

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gba.htm new file mode 100644 index 00000000..7ded4dba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/03_gba.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 3.7.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.7.2.1 Examples of Transfer of Control during a Destructive Operation

+The following examples illustrate some of the many ways in which the implementation-dependent nature of the modification can manifest itself.

+

+ (let ((a (list 2 1 4 3 7 6 'five)))
+   (ignore-errors (sort a #'<))
+   a)
+=>  (1 2 3 4 6 7 FIVE)
+OR=>  (2 1 4 3 7 6 FIVE)
+OR=>  (2)
+
+ (prog foo ((a (list 1 2 3 4 5 6 7 8 9 10)))
+   (sort a #'(lambda (x y) (if (zerop (random 5)) (return-from foo a) (> x y)))))
+=>  (1 2 3 4 5 6 7 8 9 10)
+OR=>  (3 4 5 6 2 7 8 9 10 1)
+OR=>  (1 2 4 3)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_.htm new file mode 100644 index 00000000..cb8d30a6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_.htm @@ -0,0 +1,44 @@ + + + +CLHS: Chapter 4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+4. Types and Classes

+

+ + +

+4.1 Introduction

+ +

+4.2 Types

+ +

+4.3 Classes

+ +

+4.4 The Types and Classes Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_a.htm new file mode 100644 index 00000000..ef74fe4c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_a.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.1 Introduction

+A type is a (possibly infinite) set of objects. An object can belong to more than one type. Types are never explicitly represented as objects by Common Lisp. Instead, they are referred to indirectly by the use of type specifiers, which are objects that denote types.

+New types can be defined using deftype, defstruct, defclass, and define-condition.

+The function typep, a set membership test, is used to determine whether a given object is of a given type. The function subtypep, a subset test, is used to determine whether a given type is a subtype of another given type. The function type-of returns a particular type to which a given object belongs, even though that object must belong to one or more other types as well. (For example, every object is of type t, but type-of always returns a type specifier for a type more specific than t.)

+Objects, not variables, have types. Normally, any variable can have any object as its value. It is possible to declare that a variable takes on only values of a given type by making an explicit type declaration. Types are arranged in a directed acyclic graph, except for the presence of equivalences.

+Declarations can be made about types using declare, proclaim, declaim, or the. For more information about declarations, see Section 3.3 (Declarations).

+Among the fundamental objects of the object system are classes. A class determines the structure and behavior of a set of other objects, which are called its instances. Every object is a direct instance of a class. The class of an object determines the set of operations that can be performed on the object. For more information, see Section 4.3 (Classes).

+It is possible to write functions that have behavior specialized to the class of the objects which are their arguments. For more information, see Section 7.6 (Generic Functions and Methods).

+The class of the class of an object is called its metaclass. For more information about metaclasses, see Section 7.4 (Meta-Objects).

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_b.htm new file mode 100644 index 00000000..894b22d2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_b.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.2 Types

+ + +

+4.2.1 Data Type Definition

+ +

+4.2.2 Type Relationships

+ +

+4.2.3 Type Specifiers

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ba.htm new file mode 100644 index 00000000..599535be --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ba.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 4.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.2.1 Data Type Definition

+Information about type usage is located in the sections specified in Figure 4-1. Figure 4-7 lists some classes that are particularly relevant to the object system. Figure 9-1 lists the defined condition types.

+ 

+Section                                      Data Type                          
+----------

+                                                                      
+Section 4.3 (Classes)                        Object System types                
+Section 7.5 (Slots)                          Object System types                
+Section 7 (Objects)                          Object System types                
+Section 7.6 (Generic Functions and Methods)  Object System types                
+Section 9.1 (Condition System Concepts)      Condition System types             
+Section 4 (Types and Classes)                Miscellaneous types                
+Section 2 (Syntax)                           All types---read and print syntax  
+Section 22.1 (The Lisp Printer)              All types---print syntax           
+Section 3.2 (Compilation)                    All types---compilation issues     
+
+

Figure 4-1. Cross-References to Data Type Information

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bb.htm new file mode 100644 index 00000000..d2732500 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bb.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 4.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.2.2 Type Relationships

+

+

* The types cons, symbol, array, number, character, hash-table, function, readtable, package, pathname, stream, random-state, condition, restart, and any single other type created by defstruct, define-condition, or defclass are pairwise disjoint, except for type relations explicitly established by specifying superclasses in defclass or define-condition or the :include option of destruct.

+

+

+

* Any two types created by defstruct are disjoint unless one is a supertype of the other by virtue of the defstruct :include option.

+

+

* Any two distinct classes created by defclass or define-condition are disjoint unless they have a common subclass or one class is a subclass of the other.

+

+

* An implementation may be extended to add other subtype relationships between the specified types, as long as they do not violate the type relationships and disjointness requirements specified here. An implementation may define additional types that are subtypes or supertypes of any specified types, as long as each additional type is a subtype of type t and a supertype of type nil and the disjointness requirements are not violated.

+ At the discretion of the implementation, either standard-object or structure-object might appear in any class precedence list for a system class that does not already specify either standard-object or structure-object. If it does, it must precede the class t and follow all other standardized classes.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bc.htm new file mode 100644 index 00000000..0a2e38b9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_bc.htm @@ -0,0 +1,153 @@ + + + +CLHS: Section 4.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.2.3 Type Specifiers

+

+Type specifiers can be symbols, classes, or lists. Figure 4-2 lists symbols that are standardized atomic type specifiers, and Figure 4-3 lists standardized compound type specifier names. For syntax information, see the dictionary entry for the corresponding type specifier. It is possible to define new type specifiers using defclass, define-condition, defstruct, or deftype.

+

+ 

+arithmetic-error                  function            simple-condition           
+array                             generic-function    simple-error               
+atom                              hash-table          simple-string              
+base-char                         integer             simple-type-error          
+base-string                       keyword             simple-vector              
+bignum                            list                simple-warning             
+bit                               logical-pathname    single-float               
+bit-vector                        long-float          standard-char              
+broadcast-stream                  method              standard-class             
+built-in-class                    method-combination  standard-generic-function  
+cell-error                        nil                 standard-method            
+character                         null                standard-object            
+class                             number              storage-condition          
+compiled-function                 package             stream                     
+complex                           package-error       stream-error               
+concatenated-stream               parse-error         string                     
+condition                         pathname            string-stream              
+cons                              print-not-readable  structure-class            
+control-error                     program-error       structure-object           
+division-by-zero                  random-state        style-warning              
+double-float                      ratio               symbol                     
+echo-stream                       rational            synonym-stream             
+end-of-file                       reader-error        t                          
+error                             readtable           two-way-stream             
+extended-char                     real                type-error                 
+file-error                        restart             unbound-slot               
+file-stream                       sequence            unbound-variable           
+fixnum                            serious-condition   undefined-function         
+float                             short-float         unsigned-byte              
+floating-point-inexact            signed-byte         vector                     
+floating-point-invalid-operation  simple-array        warning                    
+floating-point-overflow           simple-base-string                             
+floating-point-underflow          simple-bit-vector                              
+
+

Figure 4-2. Standardized Atomic Type Specifiers

+

+If a type specifier is a list, the car of the list is a symbol, and the rest of the list is subsidiary type information. Such a type specifier is called a compound type specifier. Except as explicitly stated otherwise, the subsidiary items can be unspecified. The unspecified subsidiary items are indicated by writing *. For example, to completely specify a vector, the type of the elements and the length of the vector must be present.

+

+ (vector double-float 100)
+
+ The following leaves the length unspecified:

+

+ (vector double-float *)
+
+ The following leaves the element type unspecified:

+

+ (vector * 100)                                      
+
+ Suppose that two type specifiers are the same except that the first has a * where the second has a more explicit specification. Then the second denotes a subtype of the type denoted by the first.

+If a list has one or more unspecified items at the end, those items can be dropped. If dropping all occurrences of * results in a singleton list, then the parentheses can be dropped as well (the list can be replaced by the symbol in its car). For example, (vector double-float *) can be abbreviated to (vector double-float), and (vector * *) can be abbreviated to (vector) and then to vector.

+ 

+and           long-float    simple-base-string  
+array         member        simple-bit-vector   
+base-string   mod           simple-string       
+bit-vector    not           simple-vector       
+complex       or            single-float        
+cons          rational      string              
+double-float  real          unsigned-byte       
+eql           satisfies     values              
+float         short-float   vector              
+function      signed-byte                       
+integer       simple-array                      
+
+

Figure 4-3. Standardized Compound Type Specifier Names

+The next figure show the defined names that can be used as compound type specifier names but that cannot be used as atomic type specifiers.

+

+and     mod  satisfies  
+eql     not  values     
+member  or              
+
+

Figure 4-4. Standardized Compound-Only Type Specifier Names

+New type specifiers can come into existence in two ways.

* Defining a structure by using defstruct without using the :type specifier or defining a class by using defclass or define-condition automatically causes the name of the structure or class to be a new type specifier symbol.
* deftype can be used to define derived type specifiers, which act as `abbreviations' for other type specifiers.

+A class object can be used as a type specifier. When used this way, it denotes the set of all members of that class.

+The next figure shows some defined names relating to types and declarations.

+ 

+coerce            defstruct  subtypep  
+declaim           deftype    the       
+declare           ftype      type      
+defclass          locally    type-of   
+define-condition  proclaim   typep     
+
+

Figure 4-5. Defined names relating to types and declarations.

+The next figure shows all defined names that are type specifier names, whether for atomic type specifiers or compound type specifiers; this list is the union of the lists in Figure 4-2 and Figure 4-3.

+ 

+and                               function            simple-array               
+arithmetic-error                  generic-function    simple-base-string         
+array                             hash-table          simple-bit-vector          
+atom                              integer             simple-condition           
+base-char                         keyword             simple-error               
+base-string                       list                simple-string              
+bignum                            logical-pathname    simple-type-error          
+bit                               long-float          simple-vector              
+bit-vector                        member              simple-warning             
+broadcast-stream                  method              single-float               
+built-in-class                    method-combination  standard-char              
+cell-error                        mod                 standard-class             
+character                         nil                 standard-generic-function  
+class                             not                 standard-method            
+compiled-function                 null                standard-object            
+complex                           number              storage-condition          
+concatenated-stream               or                  stream                     
+condition                         package             stream-error               
+cons                              package-error       string                     
+control-error                     parse-error         string-stream              
+division-by-zero                  pathname            structure-class            
+double-float                      print-not-readable  structure-object           
+echo-stream                       program-error       style-warning              
+end-of-file                       random-state        symbol                     
+eql                               ratio               synonym-stream             
+error                             rational            t                          
+extended-char                     reader-error        two-way-stream             
+file-error                        readtable           type-error                 
+file-stream                       real                unbound-slot               
+fixnum                            restart             unbound-variable           
+float                             satisfies           undefined-function         
+floating-point-inexact            sequence            unsigned-byte              
+floating-point-invalid-operation  serious-condition   values                     
+floating-point-overflow           short-float         vector                     
+floating-point-underflow          signed-byte         warning                    
+
+

Figure 4-6. Standardized Type Specifier Names

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_c.htm new file mode 100644 index 00000000..14993089 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_c.htm @@ -0,0 +1,59 @@ + + + +CLHS: Section 4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3 Classes

+While the object system is general enough to describe all standardized classes (including, for example, number, hash-table, and symbol), the next figure contains a list of classes that are especially relevant to understanding the object system.

+ 

+built-in-class    method-combination         standard-object   
+class             standard-class             structure-class   
+generic-function  standard-generic-function  structure-object  
+method            standard-method                              
+
+

Figure 4-7. Object System Classes

+ + +

+4.3.1 Introduction to Classes

+ +

+4.3.2 Defining Classes

+ + +

+4.3.3 Creating Instances of Classes

+ +

+4.3.4 Inheritance

+ + +

+4.3.5 Determining the Class Precedence List

+ +

+4.3.6 Redefining Classes

+ +

+4.3.7 Integrating Types and Classes

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ca.htm new file mode 100644 index 00000000..ccfdb3f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ca.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 4.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.1 Introduction to Classes

+A class is an object that determines the structure and behavior of a set of other objects, which are called its instances.

+A class can inherit structure and behavior from other classes. A class whose definition refers to other classes for the purpose of inheriting from them is said to be a subclass of each of those classes. The classes that are designated for purposes of inheritance are said to be superclasses of the inheriting class.

+A class can have a name. The function class-name takes a class object and returns its name. The name of an anonymous class is nil. A symbol can name a class. The function find-class takes a symbol and returns the class that the symbol names. A class has a proper name if the name is a symbol and if the name of the class names that class. That is, a class C has the proper name S if S= (class-name C) and C= (find-class S). Notice that it is possible for (find-class S1) = (find-class S2) and S1/=S2. If C= (find-class S), we say that C is the class named S.

+A class C1 is a direct superclass of a class C2 if C2 explicitly designates C1 as a superclass in its definition. In this case C2 is a direct subclass of C1. A class Cn is a superclass of a class C1 if there exists a series of classes C2,...,Cn-1 such that Ci+1 is a direct superclass of Ci for 1 <=i<n. In this case, C1 is a subclass of Cn. A class is considered neither a superclass nor a subclass of itself. That is, if C1 is a superclass of C2, then C1 /=C2. The set of classes consisting of some given class C along with all of its superclasses is called ``C and its superclasses.''

+Each class has a class precedence list, which is a total ordering on the set of the given class and its superclasses. The total ordering is expressed as a list ordered from most specific to least specific. The class precedence list is used in several ways. In general, more specific classes can shadow[1] features that would otherwise be inherited from less specific classes. The method selection and combination process uses the class precedence list to order methods from most specific to least specific.

+When a class is defined, the order in which its direct superclasses are mentioned in the defining form is important. Each class has a local precedence order, which is a list consisting of the class followed by its direct superclasses in the order mentioned in the defining form.

+A class precedence list is always consistent with the local precedence order of each class in the list. The classes in each local precedence order appear within the class precedence list in the same order. If the local precedence orders are inconsistent with each other, no class precedence list can be constructed, and an error is signaled. The class precedence list and its computation is discussed in Section 4.3.5 (Determining the Class Precedence List).

+classes are organized into a directed acyclic graph. There are two distinguished classes, named t and standard-object. The class named t has no superclasses. It is a superclass of every class except itself. The class named standard-object is an instance of the class standard-class and is a superclass of every class that is an instance of the class standard-class except itself.

+There is a mapping from the object system class space into the type space. Many of the standard types specified in this document have a corresponding class that has the same name as the type. Some types do not have a corresponding class. The integration of the type and class systems is discussed in Section 4.3.7 (Integrating Types and Classes).

+Classes are represented by objects that are themselves instances of classes. The class of the class of an object is termed the metaclass of that object. When no misinterpretation is possible, the term metaclass is used to refer to a class that has instances that are themselves classes. The metaclass determines the form of inheritance used by the classes that are its instances and the representation of the instances of those classes. The object system provides a default metaclass, standard-class, that is appropriate for most programs.

+Except where otherwise specified, all classes mentioned in this standard are instances of the class standard-class, all generic functions are instances of the class standard-generic-function, and all methods are instances of the class standard-method.

+ + +

+4.3.1.1 Standard Metaclasses

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_caa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_caa.htm new file mode 100644 index 00000000..0b316db2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_caa.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 4.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.1.1 Standard Metaclasses

+The object system provides a number of predefined metaclasses. These include the classes standard-class, built-in-class, and structure-class:

+

+

* The class standard-class is the default class of classes defined by defclass.

+
* The class built-in-class is the class whose instances are classes that have special implementations with restricted capabilities. Any class that corresponds to a standard type might be an instance of built-in-class. The predefined type specifiers that are required to have corresponding classes are listed in Figure 4-8. It is implementation-dependent whether each of these classes is implemented as a built-in class.

+
* All classes defined by means of defstruct are instances of the class structure-class.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cb.htm new file mode 100644 index 00000000..f3c45521 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cb.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 4.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.2 Defining Classes

+The macro defclass is used to define a new named class.

+The definition of a class includes:

+

+

* The name of the new class. For newly-defined classes this name is a proper name.

+
* The list of the direct superclasses of the new class.

+
* A set of slot specifiers. Each slot specifier includes the name of the slot and zero or more slot options. A slot option pertains only to a single slot. If a class definition contains two slot specifiers with the same name, an error is signaled.

+
* A set of class options. Each class option pertains to the class as a whole.

+

+The slot options and class options of the defclass form provide mechanisms for the following:

+

+

* Supplying a default initial value form for a given slot.

+
* Requesting that methods for generic functions be automatically generated for reading or writing slots.

+
* Controlling whether a given slot is shared by all instances of the class or whether each instance of the class has its own slot.

+
* Supplying a set of initialization arguments and initialization argument defaults to be used in instance creation.

+
* Indicating that the metaclass is to be other than the default. The :metaclass option is reserved for future use; an implementation can be extended to make use of the :metaclass option.

+
* Indicating the expected type for the value stored in the slot.

+
* Indicating the documentation string for the slot.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cc.htm new file mode 100644 index 00000000..5b638f07 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 4.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.3 Creating Instances of Classes

+The generic function make-instance creates and returns a new instance of a class. The object system provides several mechanisms for specifying how a new instance is to be initialized. For example, it is possible to specify the initial values for slots in newly created instances either by giving arguments to make-instance or by providing default initial values. Further initialization activities can be performed by methods written for generic functions that are part of the initialization protocol. The complete initialization protocol is described in Section 7.1 (Object Creation and Initialization).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cd.htm new file mode 100644 index 00000000..d624f8d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cd.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 4.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.4 Inheritance

+A class can inherit methods, slots, and some defclass options from its superclasses. Other sections describe the inheritance of methods, the inheritance of slots and slot options, and the inheritance of class options.

+ + +

+4.3.4.1 Examples of Inheritance

+ +

+4.3.4.2 Inheritance of Class Options

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cda.htm new file mode 100644 index 00000000..f25fbaef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cda.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 4.3.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.4.1 Examples of Inheritance

+

+ (defclass C1 () 
+     ((S1 :initform 5.4 :type number) 
+      (S2 :allocation :class)))
+ 
+ (defclass C2 (C1) 
+     ((S1 :initform 5 :type integer)
+      (S2 :allocation :instance)
+      (S3 :accessor C2-S3)))
+
+

+Instances of the class C1 have a local slot named S1, whose default initial value is 5.4 and whose value should always be a number. The class C1 also has a shared slot named S2.

+There is a local slot named S1 in instances of C2. The default initial value of S1 is 5. The value of S1 should always be of type (and integer number). There are also local slots named S2 and S3 in instances of C2. The class C2 has a method for C2-S3 for reading the value of slot S3; there is also a method for (setf C2-S3) that writes the value of S3.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cdb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cdb.htm new file mode 100644 index 00000000..391eb199 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cdb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 4.3.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.4.2 Inheritance of Class Options

+The :default-initargs class option is inherited. The set of defaulted initialization arguments for a class is the union of the sets of initialization arguments supplied in the :default-initargs class options of the class and its superclasses. When more than one default initial value form is supplied for a given initialization argument, the default initial value form that is used is the one supplied by the class that is most specific according to the class precedence list.

+If a given :default-initargs class option specifies an initialization argument of the same name more than once, an error of type program-error is signaled.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ce.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ce.htm new file mode 100644 index 00000000..82e3d9ab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ce.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 4.3.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.5 Determining the Class Precedence List

+The defclass form for a class provides a total ordering on that class and its direct superclasses. This ordering is called the local precedence order. It is an ordered list of the class and its direct superclasses. The class precedence list for a class C is a total ordering on C and its superclasses that is consistent with the local precedence orders for each of C and its superclasses.

+A class precedes its direct superclasses, and a direct superclass precedes all other direct superclasses specified to its right in the superclasses list of the defclass form. For every class C, define

RC={(C,C1),(C1,C2),...,(Cn-1,Cn)}

where C1,...,Cn are the direct superclasses of C in the order in which they are mentioned in the defclass form. These ordered pairs generate the total ordering on the class C and its direct superclasses.

+Let SC be the set of C and its superclasses. Let R be

R=Uc<ELEMENT-OF>SCRc

.

+ The set R might or might not generate a partial ordering, depending on whether the Rc, c<ELEMENT-OF>SC, are consistent; it is assumed that they are consistent and that R generates a partial ordering. When the Rc are not consistent, it is said that R is inconsistent.

+To compute the class precedence list for C, topologically sort the elements of SC with respect to the partial ordering generated by R. When the topological sort must select a class from a set of two or more classes, none of which are preceded by other classes with respect to R, the class selected is chosen deterministically, as described below.

+If R is inconsistent, an error is signaled.

+

+ + +

+4.3.5.1 Topological Sorting

+ +

+4.3.5.2 Examples of Class Precedence List Determination

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cea.htm new file mode 100644 index 00000000..febab260 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cea.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 4.3.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.5.1 Topological Sorting

+Topological sorting proceeds by finding a class C in SC such that no other class precedes that element according to the elements in R. The class C is placed first in the result. Remove C from SC, and remove all pairs of the form (C,D), D<ELEMENT-OF>SC, from R. Repeat the process, adding classes with no predecessors to the end of the result. Stop when no element can be found that has no predecessor.

+If SC is not empty and the process has stopped, the set R is inconsistent. If every class in the finite set of classes is preceded by another, then R contains a loop. That is, there is a chain of classes C1,...,Cn such that Ci precedes Ci+1, 1<=i<n, and Cn precedes C1.

+Sometimes there are several classes from SC with no predecessors. In this case select the one that has a direct subclass rightmost in the class precedence list computed so far. (If there is no such candidate class, R does not generate a partial ordering---the Rc, c<ELEMENT-OF>SC, are inconsistent.)

+In more precise terms, let {N1,...,Nm}, m>=2, be the classes from SC with no predecessors. Let (C1...Cn), n>=1, be the class precedence list constructed so far. C1 is the most specific class, and Cn is the least specific. Let 1<=j<=n be the largest number such that there exists an i where 1<=i<=m and Ni is a direct superclass of Cj; Ni is placed next.

+The effect of this rule for selecting from a set of classes with no predecessors is that the classes in a simple superclass chain are adjacent in the class precedence list and that classes in each relatively separated subgraph are adjacent in the class precedence list. For example, let T1 and T2 be subgraphs whose only element in common is the class J. Suppose that no superclass of J appears in either T1 or T2, and that J is in the superclass chain of every class in both T1 and T2. Let C1 be the bottom of T1; and let C2 be the bottom of T2. Suppose C is a class whose direct superclasses are C1 and C2 in that order, then the class precedence list for C starts with C and is followed by all classes in T1 except J. All the classes of T2 are next. The class J and its superclasses appear last.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ceb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ceb.htm new file mode 100644 index 00000000..ed518eef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_ceb.htm @@ -0,0 +1,75 @@ + + + +CLHS: Section 4.3.5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.5.2 Examples of Class Precedence List Determination

+This example determines a class precedence list for the class pie. The following classes are defined:

+

+ (defclass pie (apple cinnamon) ())
+ 
+ (defclass apple (fruit) ())
+ 
+ (defclass cinnamon (spice) ())
+ 
+ (defclass fruit (food) ())
+
+ (defclass spice (food) ())
+
+ (defclass food () ())
+
+

+The set Spie = {pie, apple, cinnamon, fruit, spice, food, standard-object, t}. The set R = {(pie, apple), (apple, cinnamon), (apple, fruit), (cinnamon, spice),
+(fruit, food), (spice, food), (food, standard-object), (standard-object, t)}.

+The class pie is not preceded by anything, so it comes first; the result so far is (pie). Remove pie from S and pairs mentioning pie from R to get S = {apple, cinnamon, fruit, spice, food, standard-object, t} and R = {(apple, cinnamon), (apple, fruit), (cinnamon, spice),
+(fruit, food), (spice, food), (food, standard-object), (standard-object, t)}.

+The class apple is not preceded by anything, so it is next; the result is (pie apple). Removing apple and the relevant pairs results in S = {cinnamon, fruit, spice, food, standard-object, t} and R = {(cinnamon, spice), (fruit, food), (spice, food), (food, standard-object),
+(standard-object, t)}.

+The classes cinnamon and fruit are not preceded by anything, so the one with a direct subclass rightmost in the class precedence list computed so far goes next. The class apple is a direct subclass of fruit, and the class pie is a direct subclass of cinnamon. Because apple appears to the right of pie in the class precedence list, fruit goes next, and the result so far is (pie apple fruit). S = {cinnamon, spice, food, standard-object, t}; R = {(cinnamon, spice), (spice, food),
+(food, standard-object), (standard-object, t)}.

+The class cinnamon is next, giving the result so far as (pie apple fruit cinnamon). At this point S = {spice, food, standard-object, t}; R = {(spice, food), (food, standard-object), (standard-object, t)}.

+The classes spice, food, standard-object, and t are added in that order, and the class precedence list is (pie apple fruit cinnamon spice food standard-object t).

+It is possible to write a set of class definitions that cannot be ordered. For example:

+

+ (defclass new-class (fruit apple) ())
+ 
+ (defclass apple (fruit) ())
+
+

+The class fruit must precede apple because the local ordering of superclasses must be preserved. The class apple must precede fruit because a class always precedes its own superclasses. When this situation occurs, an error is signaled, as happens here when the system tries to compute the class precedence list of new-class.

+The following might appear to be a conflicting set of definitions:

+

+ (defclass pie (apple cinnamon) ())
+ 
+ (defclass pastry (cinnamon apple) ())
+ 
+ (defclass apple () ())
+ 
+ (defclass cinnamon () ())
+
+

+The class precedence list for pie is (pie apple cinnamon standard-object t).

+The class precedence list for pastry is (pastry cinnamon apple standard-object t).

+It is not a problem for apple to precede cinnamon in the ordering of the superclasses of pie but not in the ordering for pastry. However, it is not possible to build a new class that has both pie and pastry as superclasses.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cf.htm new file mode 100644 index 00000000..9a9dd029 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cf.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 4.3.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.6 Redefining Classes

+A class that is a direct instance of standard-class can be redefined if the new class is also a direct instance of standard-class. Redefining a class modifies the existing class object to reflect the new class definition; it does not create a new class object for the class. Any method object created by a :reader, :writer, or :accessor option specified by the old defclass form is removed from the corresponding generic function. Methods specified by the new defclass form are added.

+When the class C is redefined, changes are propagated to its instances and to instances of any of its subclasses. Updating such an instance occurs at an implementation-dependent time, but no later than the next time a slot of that instance is read or written. Updating an instance does not change its identity as defined by the function eq. The updating process may change the slots of that particular instance, but it does not create a new instance. Whether updating an instance consumes storage is implementation-dependent.

+Note that redefining a class may cause slots to be added or deleted. If a class is redefined in a way that changes the set of local slots accessible in instances, the instances are updated. It is implementation-dependent whether instances are updated if a class is redefined in a way that does not change the set of local slots accessible in instances.

+The value of a slot that is specified as shared both in the old class and in the new class is retained. If such a shared slot was unbound in the old class, it is unbound in the new class. Slots that were local in the old class and that are shared in the new class are initialized. Newly added shared slots are initialized.

+Each newly added shared slot is set to the result of evaluating the captured initialization form for the slot that was specified in the defclass form for the new class. If there was no initialization form, the slot is unbound.

+If a class is redefined in such a way that the set of local slots accessible in an instance of the class is changed, a two-step process of updating the instances of the class takes place. The process may be explicitly started by invoking the generic function make-instances-obsolete. This two-step process can happen in other circumstances in some implementations. For example, in some implementations this two-step process is triggered if the order of slots in storage is changed.

+The first step modifies the structure of the instance by adding new local slots and discarding local slots that are not defined in the new version of the class. The second step initializes the newly-added local slots and performs any other user-defined actions. These two steps are further specified in the next two sections.

+ + +

+4.3.6.1 Modifying the Structure of Instances

+ + +

+4.3.6.2 Initializing Newly Added Local Slots

+ +

+4.3.6.3 Customizing Class Redefinition

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfa.htm new file mode 100644 index 00000000..f52de8fb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 4.3.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.6.1 Modifying the Structure of Instances

+ The first step modifies the structure of instances of the redefined class to conform to its new class definition. Local slots specified by the new class definition that are not specified as either local or shared by the old class are added, and slots not specified as either local or shared by the new class definition that are specified as local by the old class are discarded. The names of these added and discarded slots are passed as arguments to update-instance-for-redefined-class as described in the next section.

+The values of local slots specified by both the new and old classes are retained. If such a local slot was unbound, it remains unbound.

+The value of a slot that is specified as shared in the old class and as local in the new class is retained. If such a shared slot was unbound, the local slot is unbound.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfb.htm new file mode 100644 index 00000000..17967f9e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 4.3.6.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.6.2 Initializing Newly Added Local Slots

+The second step initializes the newly added local slots and performs any other user-defined actions. This step is implemented by the generic function update-instance-for-redefined-class, which is called after completion of the first step of modifying the structure of the instance.

+The generic function update-instance-for-redefined-class takes four required arguments: the instance being updated after it has undergone the first step, a list of the names of local slots that were added, a list of the names of local slots that were discarded, and a property list containing the slot names and values of slots that were discarded and had values. Included among the discarded slots are slots that were local in the old class and that are shared in the new class.

+The generic function update-instance-for-redefined-class also takes any number of initialization arguments. When it is called by the system to update an instance whose class has been redefined, no initialization arguments are provided.

+There is a system-supplied primary method for update-instance-for-redefined-class whose parameter specializer for its instance argument is the class standard-object. First this method checks the validity of initialization arguments and signals an error if an initialization argument is supplied that is not declared as valid. (For more information, see Section 7.1.2 (Declaring the Validity of Initialization Arguments).) Then it calls the generic function shared-initialize with the following arguments: the instance, the list of names of the newly added slots, and the initialization arguments it received.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfc.htm new file mode 100644 index 00000000..f9fe8ec9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cfc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 4.3.6.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.6.3 Customizing Class Redefinition

+ Methods for update-instance-for-redefined-class may be defined to specify actions to be taken when an instance is updated. If only after methods for update-instance-for-redefined-class are defined, they will be run after the system-supplied primary method for initialization and therefore will not interfere with the default behavior of update-instance-for-redefined-class. Because no initialization arguments are passed to update-instance-for-redefined-class when it is called by the system, the initialization forms for slots that are filled by before methods for update-instance-for-redefined-class will not be evaluated by shared-initialize.

+Methods for shared-initialize may be defined to customize class redefinition. For more information, see Section 7.1.5 (Shared-Initialize).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cg.htm new file mode 100644 index 00000000..90684ede --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/04_cg.htm @@ -0,0 +1,71 @@ + + + +CLHS: Section 4.3.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.3.7 Integrating Types and Classes

+The object system maps the space of classes into the space of types. Every class that has a proper name has a corresponding type with the same name.

+The proper name of every class is a valid type specifier. In addition, every class object is a valid type specifier. Thus the expression (typep object class) evaluates to true if the class of object is class itself or a subclass of class. The evaluation of the expression (subtypep class1 class2) returns the values true and true if class1 is a subclass of class2 or if they are the same class; otherwise it returns the values false and true. If I is an instance of some class C named S and C is an instance of standard-class, the evaluation of the expression (type-of I) returns S if S is the proper name of C; otherwise, it returns C.

+Because the names of classes and class objects are type specifiers, they may be used in the special form the and in type declarations.

+Many but not all of the predefined type specifiers have a corresponding class with the same proper name as the type. These type specifiers are listed in Figure 4-8. For example, the type array has a corresponding class named array. No type specifier that is a list, such as (vector double-float 100), has a corresponding class. The operator deftype does not create any classes.

+Each class that corresponds to a predefined type specifier can be implemented in one of three ways, at the discretion of each implementation. It can be a standard class, a structure class, or a system class.

+A built-in class is one whose generalized instances have restricted capabilities or special representations. Attempting to use defclass to define subclasses of a built-in-class signals an error. Calling make-instance to create a generalized instance of a built-in class signals an error. Calling slot-value on a generalized instance of a built-in class signals an error. Redefining a built-in class or using change-class to change the class of an object to or from a built-in class signals an error. However, built-in classes can be used as parameter specializers in methods.

+It is possible to determine whether a class is a built-in class by checking the metaclass. A standard class is an instance of the class standard-class, a built-in class is an instance of the class built-in-class, and a structure class is an instance of the class structure-class.

+Each structure type created by defstruct without using the :type option has a corresponding class. This class is a generalized instance of the class structure-class. The :include option of defstruct creates a direct subclass of the class that corresponds to the included structure type.

+ It is implementation-dependent whether slots are involved in the operation of functions defined in this specification on instances of classes defined in this specification, except when slots are explicitly defined by this specification.

+If in a particular implementation a class defined in this specification has slots that are not defined by this specfication, the names of these slots must not be external symbols of packages defined in this specification nor otherwise accessible in the CL-USER package.

+ The purpose of specifying that many of the standard type specifiers have a corresponding class is to enable users to write methods that discriminate on these types. Method selection requires that a class precedence list can be determined for each class.

+The hierarchical relationships among the type specifiers are mirrored by relationships among the classes corresponding to those types.

+Figure 4-8 lists the set of classes that correspond to predefined type specifiers.

+ 

+arithmetic-error                  generic-function    simple-error               
+array                             hash-table          simple-type-error          
+bit-vector                        integer             simple-warning             
+broadcast-stream                  list                standard-class             
+built-in-class                    logical-pathname    standard-generic-function  
+cell-error                        method              standard-method            
+character                         method-combination  standard-object            
+class                             null                storage-condition          
+complex                           number              stream                     
+concatenated-stream               package             stream-error               
+condition                         package-error       string                     
+cons                              parse-error         string-stream              
+control-error                     pathname            structure-class            
+division-by-zero                  print-not-readable  structure-object           
+echo-stream                       program-error       style-warning              
+end-of-file                       random-state        symbol                     
+error                             ratio               synonym-stream             
+file-error                        rational            t                          
+file-stream                       reader-error        two-way-stream             
+float                             readtable           type-error                 
+floating-point-inexact            real                unbound-slot               
+floating-point-invalid-operation  restart             unbound-variable           
+floating-point-overflow           sequence            undefined-function         
+floating-point-underflow          serious-condition   vector                     
+function                          simple-condition    warning                    
+
+

Figure 4-8. Classes that correspond to pre-defined type specifiers

+The class precedence list information specified in the entries for each of these classes are those that are required by the object system.

+Individual implementations may be extended to define other type specifiers to have a corresponding class. Individual implementations may be extended to add other subclass relationships and to add other elements to the class precedence lists as long as they do not violate the type relationships and disjointness requirements specified by this standard. A standard class defined with no direct superclasses is guaranteed to be disjoint from all of the classes in the table, except for the class named t.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_.htm new file mode 100644 index 00000000..69c15a12 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_.htm @@ -0,0 +1,41 @@ + + + +CLHS: Chapter 5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+5. Data and Control Flow

+

+ + +

+5.1 Generalized Reference

+ +

+5.2 Transfer of Control to an Exit Point

+ +

+5.3 The Data and Control Flow Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_a.htm new file mode 100644 index 00000000..3d12a105 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_a.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1 Generalized Reference

+ + +

+5.1.1 Overview of Places and Generalized Reference

+ +

+5.1.2 Kinds of Places

+ +

+5.1.3 Treatment of Other Macros Based on SETF

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aa.htm new file mode 100644 index 00000000..08bd2da1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aa.htm @@ -0,0 +1,57 @@ + + + +CLHS: Section 5.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.1 Overview of Places and Generalized Reference

+A generalized reference is the use of a form, sometimes called a place, as if it were a variable that could be read and written. The value of a place is the object to which the place form evaluates. The value of a place can be changed by using setf. The concept of binding a place is not defined in Common Lisp, but an implementation is permitted to extend the language by defining this concept.

+The next figure contains examples of the use of setf. Note that the values returned by evaluating the forms in column two are not necessarily the same as those obtained by evaluating the forms in column three. In general, the exact macro expansion of a setf form is not guaranteed and can even be implementation-dependent; all that is guaranteed is that the expansion is an update form that works for that particular implementation, that the left-to-right evaluation of subforms is preserved, and that the ultimate result of evaluating setf is the value or values being stored.

+

+Access function   Update Function   Update using setf              
+x                 (setq x datum)    (setf x datum)                 
+(car x)           (rplaca x datum)  (setf (car x) datum)           
+(symbol-value x)  (set x datum)     (setf (symbol-value x) datum)  
+
+

Figure 5-1. Examples of setf

+The next figure shows operators relating to places and generalized reference.

+

+

+assert                defsetf             push     
+ccase                 get-setf-expansion  remf     
+ctypecase             getf                rotatef  
+decf                  incf                setf     
+define-modify-macro   pop                 shiftf   
+define-setf-expander  psetf                        
+
+

Figure 5-2. Operators relating to places and generalized reference.

+

+ Some of the operators above manipulate places and some manipulate setf expanders. A setf expansion can be derived from any place. New setf expanders can be defined by using defsetf and define-setf-expander.

+ + +

+5.1.1.1 Evaluation of Subforms to Places

+ + +

+5.1.1.2 Setf Expansions

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaa.htm new file mode 100644 index 00000000..8b75383c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaa.htm @@ -0,0 +1,52 @@ + + + +CLHS: Section 5.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.1.1 Evaluation of Subforms to Places

+The following rules apply to the evaluation of subforms in a place:

+

1. The evaluation ordering of subforms within a place is determined by the order specified by the second value returned by get-setf-expansion. For all places defined by this specification (e.g., getf, ldb, ...), this order of evaluation is left-to-right. When a place is derived from a macro expansion, this rule is applied after the macro is expanded to find the appropriate place.

+Places defined by using defmacro or define-setf-expander use the evaluation order defined by those definitions. For example, consider the following:

+

+ (defmacro wrong-order (x y) `(getf ,y ,x))
+
+

+This following form evaluates place2 first and then place1 because that is the order they are evaluated in the macro expansion:

+

+ (push value (wrong-order place1 place2))
+
+

+

2. For the macros that manipulate places (push, pushnew, remf, incf, decf, shiftf, rotatef, psetf, setf, pop, and those defined by define-modify-macro) the subforms of the macro call are evaluated exactly once in left-to-right order, with the subforms of the places evaluated in the order specified in (1).

+push, pushnew, remf, incf, decf, shiftf, rotatef, psetf, pop evaluate all subforms before modifying any of the place locations. setf (in the case when setf has more than two arguments) performs its operation on each pair in sequence. For example, in

+

+ (setf place1 value1 place2 value2 ...)
+
+ the subforms of place1 and value1 are evaluated, the location specified by place1 is modified to contain the value returned by value1, and then the rest of the setf form is processed in a like manner.

+

3. For check-type, ctypecase, and ccase, subforms of the place are evaluated once as in (1), but might be evaluated again if the type check fails in the case of check-type or none of the cases hold in ctypecase and ccase.

+
4. For assert, the order of evaluation of the generalized references is not specified.

+

Rules 2, 3 and 4 cover all standardized macros that manipulate places.

+ + +

+5.1.1.1.1 Examples of Evaluation of Subforms to Places

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaaa.htm new file mode 100644 index 00000000..bf5b6b52 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaaa.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 5.1.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.1.1.1 Examples of Evaluation of Subforms to Places

+

+ (let ((ref2 (list '())))
+   (push (progn (princ "1") 'ref-1)
+         (car (progn (princ "2") ref2)))) 
+>>  12
+=>  (REF1)
+
+ (let (x)
+    (push (setq x (list 'a))
+          (car (setq x (list 'b))))
+     x)
+=>  (((A) . B))
+
+

+push first evaluates (setq x (list 'a)) => (a), then evaluates (setq x (list 'b)) => (b), then modifies the car of this latest value to be ((a) . b).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aab.htm new file mode 100644 index 00000000..bc258d65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aab.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 5.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.1.2 Setf Expansions

+Sometimes it is possible to avoid evaluating subforms of a place multiple times or in the wrong order. A setf expansion for a given access form can be expressed as an ordered collection of five objects:

+

List of temporary variables

+a list of symbols naming temporary variables to be bound sequentially, as if by let*, to values resulting from value forms.

+

List of value forms

+a list of forms (typically, subforms of the place) which when evaluated yield the values to which the corresponding temporary variables should be bound.

+

List of store variables

+a list of symbols naming temporary store variables which are to hold the new values that will be assigned to the place.

+

Storing form

+a form which can reference both the temporary and the store variables, and which changes the value of the place and guarantees to return as its values the values of the store variables, which are the correct values for setf to return.

+

Accessing form

+a form which can reference the temporary variables, and which returns the value of the place.

+The value returned by the accessing form is affected by execution of the storing form, but either of these forms might be evaluated any number of times.

+It is possible to do more than one setf in parallel via psetf, shiftf, and rotatef. Because of this, the setf expander must produce new temporary and store variable names every time. For examples of how to do this, see gensym.

+ For each standardized accessor function F, unless it is explicitly documented otherwise, it is implementation-dependent whether the ability to use an F form as a setf place is implemented by a setf expander or a setf function. Also, it follows from this that it is implementation-dependent whether the name (setf F) is fbound.

+ + +

+5.1.1.2.1 Examples of Setf Expansions

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaba.htm new file mode 100644 index 00000000..6cd1daa5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aaba.htm @@ -0,0 +1,68 @@ + + + +CLHS: Section 5.1.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.1.2.1 Examples of Setf Expansions

+ Examples of the contents of the constituents of setf expansions follow.

+For a variable x:

+

+()              ;list of temporary variables  
+()              ;list of value forms          
+(g0001)         ;list of store variables      
+(setq x g0001)  ;storing form                 
+x               ;accessing form               
+
+

Figure 5-3. Sample Setf Expansion of a Variable

+For (car exp):

+

+(g0002)                             ;list of temporary variables  
+(exp)                               ;list of value forms          
+(g0003)                             ;list of store variables      
+(progn (rplaca g0002 g0003) g0003)  ;storing form                 
+(car g0002)                         ;accessing form               
+
+

Figure 5-4. Sample Setf Expansion of a CAR Form

+For (subseq seq s e):

+

+(g0004 g0005 g0006)         ;list of temporary variables  
+(seq s e)                   ;list of value forms          
+(g0007)                     ;list of store variables      
+(progn (replace g0004 g0007 :start1 g0005 :end1 g0006) g0007)                              
+                            ;storing form                 
+(subseq g0004 g0005 g0006)  ; accessing form              
+
+

Figure 5-5. Sample Setf Expansion of a SUBSEQ Form

+In some cases, if a subform of a place is itself a place, it is necessary to expand the subform in order to compute some of the values in the expansion of the outer place. For (ldb bs (car exp)):

+

+(g0001 g0002)            ;list of temporary variables  
+(bs exp)                 ;list of value forms          
+(g0003)                  ;list of store variables      
+(progn (rplaca g0002 (dpb g0003 g0001 (car g0002))) g0003)                              
+                         ;storing form                 
+(ldb g0001 (car g0002))  ; accessing form              
+
+

Figure 5-6. Sample Setf Expansion of a LDB Form

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ab.htm new file mode 100644 index 00000000..192c53d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ab.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section 5.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2 Kinds of Places

+Several kinds of places are defined by Common Lisp; this section enumerates them. This set can be extended by implementations and by programmer code.

+ + +

+5.1.2.1 Variable Names as Places

+ +

+5.1.2.2 Function Call Forms as Places

+ + +

+5.1.2.3 VALUES Forms as Places

+ + +

+5.1.2.4 THE Forms as Places

+ +

+5.1.2.5 APPLY Forms as Places

+ + +

+5.1.2.6 Setf Expansions and Places

+ +

+5.1.2.7 Macro Forms as Places

+ + +

+5.1.2.8 Symbol Macros as Places

+ +

+5.1.2.9 Other Compound Forms as Places

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aba.htm new file mode 100644 index 00000000..3d2d3cfa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_aba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 5.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.1 Variable Names as Places

+The name of a lexical variable or dynamic variable can be used as a place.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abb.htm new file mode 100644 index 00000000..cccf3215 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abb.htm @@ -0,0 +1,107 @@ + + + +CLHS: Section 5.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.2 Function Call Forms as Places

+A function form can be used as a place if it falls into one of the following categories:

+

+

* A function call form whose first element is the name of any one of the functions in the next figure.

+

+ 

+aref    cdadr                    get                            
+bit     cdar                     gethash                        
+caaaar  cddaar                   logical-pathname-translations  
+caaadr  cddadr                   macro-function                 
+caaar   cddar                    ninth                          
+caadar  cdddar                   nth                            
+caaddr  cddddr                   readtable-case                 
+caadr   cdddr                    rest                           
+caar    cddr                     row-major-aref                 
+cadaar  cdr                      sbit                           
+cadadr  char                     schar                          
+cadar   class-name               second                         
+caddar  compiler-macro-function  seventh                        
+cadddr  documentation            sixth                          
+caddr   eighth                   slot-value                     
+cadr    elt                      subseq                         
+car     fdefinition              svref                          
+cdaaar  fifth                    symbol-function                
+cdaadr  fill-pointer             symbol-plist                   
+cdaar   find-class               symbol-value                   
+cdadar  first                    tenth                          
+cdaddr  fourth                   third                          
+
+

Figure 5-7. Functions that setf can be used with---1

+In the case of subseq, the replacement value must be a sequence whose elements might be contained by the sequence argument to subseq, but does not have to be a sequence of the same type as the sequence of which the subsequence is specified. If the length of the replacement value does not equal the length of the subsequence to be replaced, then the shorter length determines the number of elements to be stored, as for replace.

+

* A function call form whose first element is the name of a selector function constructed by defstruct. The function name must refer to the global function definition, rather than a locally defined function.

+
* A function call form whose first element is the name of any one of the functions in the next figure, provided that the supplied argument to that function is in turn a place form; in this case the new place has stored back into it the result of applying the supplied ``update'' function.

+ 
+Function name  Argument that is a place  Update function used      
+ldb            second                    dpb                       
+mask-field     second                    deposit-field             
+getf           first                     implementation-dependent  
+
+

Figure 5-8. Functions that setf can be used with---2 During the setf expansion of these forms, it is necessary to call get-setf-expansion in order to figure out how the inner, nested generalized variable must be treated.

+The information from get-setf-expansion is used as follows.

ldb

+In a form such as:

+(setf (ldb byte-spec place-form) value-form)

+the place referred to by the place-form must always be both read and written; note that the update is to the generalized variable specified by place-form, not to any object of type integer.

+Thus this setf should generate code to do the following:

+

1. Evaluate byte-spec (and bind it into a temporary variable).
2. Bind the temporary variables for place-form.
3. Evaluate value-form (and bind its value or values into the store variable).
4. Do the read from place-form.
5. Do the write into place-form with the given bits of the integer fetched in step 4 replaced with the value from step 3.

If the evaluation of value-form in step 3 alters what is found in place-form, such as setting different bits of integer, then the change of the bits denoted by byte-spec is to that altered integer, because step 4 is done after the value-form evaluation. Nevertheless, the evaluations required for binding the temporary variables are done in steps 1 and 2, and thus the expected left-to-right evaluation order is seen. For example:

+

+ (setq integer #x69) =>  #x69
+ (rotatef (ldb (byte 4 4) integer) 
+          (ldb (byte 4 0) integer))
+ integer =>  #x96
+;;; This example is trying to swap two independent bit fields 
+;;; in an integer.  Note that the generalized variable of 
+;;; interest here is just the (possibly local) program variable
+;;; integer.
+
+

+

mask-field

+ This case is the same as ldb in all essential aspects.

+

getf

+ In a form such as:

+(setf (getf place-form ind-form) value-form)

+ the place referred to by place-form must always be both read and written; note that the update is to the generalized variable specified by place-form, not necessarily to the particular list that is the property list in question.

+ Thus this setf should generate code to do the following:

1. Bind the temporary variables for place-form.
2. Evaluate ind-form (and bind it into a temporary variable).
3. Evaluate value-form (and bind its value or values into the store variable).
4. Do the read from place-form.
5. Do the write into place-form with a possibly-new property list obtained by combining the values from steps 2, 3, and 4. (Note that the phrase ``possibly-new property list'' can mean that the former property list is somehow destructively re-used, or it can mean partial or full copying of it. Since either copying or destructive re-use can occur, the treatment of the resultant value for the possibly-new property list must proceed as if it were a different copy needing to be stored back into the generalized variable.)

If the evaluation of value-form in step 3 alters what is found in place-form, such as setting a different named property in the list, then the change of the property denoted by ind-form is to that altered list, because step 4 is done after the value-form evaluation. Nevertheless, the evaluations required for binding the temporary variables are done in steps 1 and 2, and thus the expected left-to-right evaluation order is seen.

+For example:

+

+ (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) =>  ((a 1 b 2 c 3))
+ (setf (getf (car r) 'b) 
+       (progn (setq r nil) 6)) =>  6
+ r =>  NIL
+ s =>  ((A 1 B 6 C 3))
+;;; Note that the (setq r nil) does not affect the actions of 
+;;; the SETF because the value of R had already been saved in 
+;;; a temporary variable as part of the step 1. Only the CAR
+;;; of this value will be retrieved, and subsequently modified 
+;;; after the value computation.
+
+

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abc.htm new file mode 100644 index 00000000..5d483728 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abc.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 5.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.3 VALUES Forms as Places

+A values form can be used as a place, provided that each of its subforms is also a place form.

+A form such as

+(setf (values place-1 ...place-n) values-form)

+does the following:

+

1. The subforms of each nested place are evaluated in left-to-right order.
2. The values-form is evaluated, and the first store variable from each place is bound to its return values as if by multiple-value-bind.
3. If the setf expansion for any place involves more than one store variable, then the additional store variables are bound to nil.
4. The storing forms for each place are evaluated in left-to-right order.

+The storing form in the setf expansion of values returns as multiple values[2] the values of the store variables in step 2. That is, the number of values returned is the same as the number of place forms. This may be more or fewer values than are produced by the values-form.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abd.htm new file mode 100644 index 00000000..969da458 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abd.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 5.1.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.4 THE Forms as Places

+A the form can be used as a place, in which case the declaration is transferred to the newvalue form, and the resulting setf is analyzed. For example,

+

+ (setf (the integer (cadr x)) (+ y 3))
+
+ is processed as if it were

+

+ (setf (cadr x) (the integer (+ y 3)))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abe.htm new file mode 100644 index 00000000..6058653f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abe.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 5.1.2.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.5 APPLY Forms as Places

+The following situations involving setf of apply must be supported:

+

* (setf (apply #'aref array subscript* more-subscripts) new-element)
* (setf (apply #'bit array subscript* more-subscripts) new-element)
* (setf (apply #'sbit array subscript* more-subscripts) new-element)

+In all three cases, the element of array designated by the concatenation of subscripts and more-subscripts (i.e., the same element which would be read by the call to apply if it were not part of a setf form) is changed to have the value given by new-element. For these usages, the function name (aref, bit, or sbit) must refer to the global function definition, rather than a locally defined function.

+No other standardized function is required to be supported, but an implementation may define such support. An implementation may also define support for implementation-defined operators.

+If a user-defined function is used in this context, the following equivalence is true, except that care is taken to preserve proper left-to-right evaluation of argument subforms:

+

+ (setf (apply #'name arg*) val)
+ ==  (apply #'(setf name) val arg*)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abf.htm new file mode 100644 index 00000000..0ea38f48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abf.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 5.1.2.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.6 Setf Expansions and Places

+Any compound form for which the operator has a setf expander defined can be used as a place. The operator must refer to the global function definition, rather than a locally defined function or macro.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abg.htm new file mode 100644 index 00000000..bea8ed82 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abg.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 5.1.2.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.7 Macro Forms as Places

+A macro form can be used as a place, in which case Common Lisp expands the macro form as if by macroexpand-1 and then uses the macro expansion in place of the original place. Such macro expansion is attempted only after exhausting all other possibilities other than expanding into a call to a function named (setf reader).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abh.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abh.htm new file mode 100644 index 00000000..d04b69e8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abh.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 5.1.2.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.8 Symbol Macros as Places

+A reference to a symbol that has been established as a symbol macro can be used as a place. In this case, setf expands the reference and then analyzes the resulting form.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abi.htm new file mode 100644 index 00000000..ef97109e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_abi.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 5.1.2.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.2.9 Other Compound Forms as Places

+For any other compound form for which the operator is a symbol f, the setf form expands into a call to the function named (setf f). The first argument in the newly constructed function form is newvalue and the remaining arguments are the remaining elements of place. This expansion occurs regardless of whether f or (setf f) is defined as a function locally, globally, or not at all. For example,

+(setf (f arg1 arg2 ...) new-value)

+expands into a form with the same effect and value as

+

+ (let ((#:temp-1 arg1)          ;force correct order of evaluation
+       (#:temp-2 arg2)
+       ...
+       (#:temp-0 new-value))
+   (funcall (function (setf f)) #:temp-0 #:temp-1 #:temp-2...))
+
+

+A function named (setf f) must return its first argument as its only value in order to preserve the semantics of setf.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ac.htm new file mode 100644 index 00000000..34bc5c27 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_ac.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 5.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.1.3 Treatment of Other Macros Based on SETF

+

+For each of the ``read-modify-write'' operators in the next figure, and for any additional macros defined by the programmer using define-modify-macro, an exception is made to the normal rule of left-to-right evaluation of arguments. Evaluation of argument forms occurs in left-to-right order, with the exception that for the place argument, the actual read of the ``old value'' from that place happens after all of the argument form evaluations, and just before a ``new value'' is computed and written back into the place.

+Specifically, each of these operators can be viewed as involving a form with the following general syntax:

+

+ (operator preceding-form* place following-form*)
+
+

+The evaluation of each such form proceeds like this:

+

1. Evaluate each of the preceding-forms, in left-to-right order.
2. Evaluate the subforms of the place, in the order specified by the second value of the setf expansion for that place.
3. Evaluate each of the following-forms, in left-to-right order.
4. Read the old value from place.
5. Compute the new value.
6. Store the new value into place.

+

+decf  pop   pushnew  
+incf  push  remf     
+
+

Figure 5-9. Read-Modify-Write Macros

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_b.htm new file mode 100644 index 00000000..9345e148 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/05_b.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.2 Transfer of Control to an Exit Point

+ When a transfer of control is initiated by go, return-from, or throw the following events occur in order to accomplish the transfer of control. Note that for go, the exit point is the form within the tagbody that is being executed at the time the go is performed; for return-from, the exit point is the corresponding block form; and for throw, the exit point is the corresponding catch form.

+

1. Intervening exit points are ``abandoned'' (i.e., their extent ends and it is no longer valid to attempt to transfer control through them).

+
2. The cleanup clauses of any intervening unwind-protect clauses are evaluated.

+
3. Intervening dynamic bindings of special variables, catch tags, condition handlers, and restarts are undone.

+
4. The extent of the exit point being invoked ends, and control is passed to the target.

+The extent of an exit being ``abandoned'' because it is being passed over ends as soon as the transfer of control is initiated. That is, event 1 occurs at the beginning of the initiation of the transfer of control. The consequences are undefined if an attempt is made to transfer control to an exit point whose dynamic extent has ended.

+Events 2 and 3 are actually performed interleaved, in the order corresponding to the reverse order in which they were established. The effect of this is that the cleanup clauses of an unwind-protect see the same dynamic bindings of variables and catch tags as were visible when the unwind-protect was entered.

+Event 4 occurs at the end of the transfer of control.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_.htm new file mode 100644 index 00000000..b73ef0d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+6. Iteration

+

+ + +

+6.1 The LOOP Facility

+ +

+6.2 The Iteration Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_a.htm new file mode 100644 index 00000000..e0ff7b4f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_a.htm @@ -0,0 +1,55 @@ + + + +CLHS: Section 6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1 The LOOP Facility

+ + +

+6.1.1 Overview of the Loop Facility

+ +

+6.1.2 Variable Initialization and Stepping Clauses

+ +

+6.1.3 Value Accumulation Clauses

+ +

+6.1.4 Termination Test Clauses

+ +

+6.1.5 Unconditional Execution Clauses

+ +

+6.1.6 Conditional Execution Clauses

+ +

+6.1.7 Miscellaneous Clauses

+ +

+6.1.8 Examples of Miscellaneous Loop Features

+ +

+6.1.9 Notes about Loop

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aa.htm new file mode 100644 index 00000000..fb387077 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aa.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 6.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1 Overview of the Loop Facility

+The loop macro performs iteration.

+ + +

+6.1.1.1 Simple vs Extended Loop

+ +

+6.1.1.2 Loop Keywords

+ +

+6.1.1.3 Parsing Loop Clauses

+ +

+6.1.1.4 Expanding Loop Forms

+ +

+6.1.1.5 Summary of Loop Clauses

+ +

+6.1.1.6 Order of Execution

+ +

+6.1.1.7 Destructuring

+ +

+6.1.1.8 Restrictions on Side-Effects

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaa.htm new file mode 100644 index 00000000..37edd7ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaa.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 6.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.1 Simple vs Extended Loop

+loop forms are partitioned into two categories: simple loop forms and extended loop forms.

+ + +

+6.1.1.1.1 Simple Loop

+ +

+6.1.1.1.2 Extended Loop

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaaa.htm new file mode 100644 index 00000000..8ca7b623 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 6.1.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.1.1 Simple Loop

+A simple loop form is one that has a body containing only compound forms. Each form is evaluated in turn from left to right. When the last form has been evaluated, then the first form is evaluated again, and so on, in a never-ending cycle. A simple loop form establishes an implicit block named nil. The execution of a simple loop can be terminated by explicitly transfering control to the implicit block (using return or return-from) or to some exit point outside of the block (e.g., using throw, go, or return-from).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaab.htm new file mode 100644 index 00000000..83c5709c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaab.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 6.1.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.1.2 Extended Loop

+An extended loop form is one that has a body containing atomic expressions. When the loop macro processes such a form, it invokes a facility that is commonly called ``the Loop Facility.''

+The Loop Facility provides standardized access to mechanisms commonly used in iterations through Loop schemas, which are introduced by loop keywords.

+The body of an extended loop form is divided into loop clauses, each which is in turn made up of loop keywords and forms.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aab.htm new file mode 100644 index 00000000..f97ca1c5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aab.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 6.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.2 Loop Keywords

+Loop keywords are not true keywords[1]; they are special symbols, recognized by name rather than object identity, that are meaningful only to the loop facility. A loop keyword is a symbol but is recognized by its name (not its identity), regardless of the packages in which it is accessible.

+ In general, loop keywords are not external symbols of the COMMON-LISP package, except in the coincidental situation that a symbol with the same name as a loop keyword was needed for some other purpose in Common Lisp. For example, there is a symbol in the COMMON-LISP package whose name is "UNLESS" but not one whose name is "UNTIL".

+If no loop keywords are supplied in a loop form, the Loop Facility executes the loop body repeatedly; see Section 6.1.1.1.1 (Simple Loop).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aac.htm new file mode 100644 index 00000000..6cdd1d77 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aac.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 6.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.3 Parsing Loop Clauses

+The syntactic parts of an extended loop form are called clauses; the rules for parsing are determined by that clause's keyword. The following example shows a loop form with six clauses:

+

+ (loop for i from 1 to (compute-top-value)       ; first clause
+       while (not (unacceptable i))              ; second clause
+       collect (square i)                        ; third clause
+       do (format t "Working on ~D now" i)       ; fourth clause
+       when (evenp i)                            ; fifth clause
+         do (format t "~D is a non-odd number" i)
+       finally (format t "About to exit!"))      ; sixth clause
+
+

+Each loop keyword introduces either a compound loop clause or a simple loop clause that can consist of a loop keyword followed by a single form. The number of forms in a clause is determined by the loop keyword that begins the clause and by the auxiliary keywords in the clause. The keywords do, doing, initially, and finally are the only loop keywords that can take any number of forms and group them as an implicit progn.

+Loop clauses can contain auxiliary keywords, which are sometimes called prepositions. For example, the first clause in the code above includes the prepositions from and to, which mark the value from which stepping begins and the value at which stepping ends.

+For detailed information about loop syntax, see the macro loop.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aad.htm new file mode 100644 index 00000000..60681c79 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aad.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 6.1.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.4 Expanding Loop Forms

+A loop macro form expands into a form containing one or more binding forms (that establish bindings of loop variables) and a block and a tagbody (that express a looping control structure). The variables established in loop are bound as if by let or lambda.

+Implementations can interleave the setting of initial values with the bindings. However, the assignment of the initial values is always calculated in the order specified by the user. A variable is thus sometimes bound to a meaningless value of the correct type, and then later in the prologue it is set to the true initial value by using setq. One implication of this interleaving is that it is implementation-dependent whether the lexical environment in which the initial value forms (variously called the form1, form2, form3, step-fun, vector, hash-table, and package) in any for-as-subclause, except for-as-equals-then, are evaluated includes only the loop variables preceding that form or includes more or all of the loop variables; the form1 and form2 in a for-as-equals-then form includes the lexical environment of all the loop variables.

+After the form is expanded, it consists of three basic parts in the tagbody: the loop prologue, the loop body, and the loop epilogue.

+

Loop prologue

+The loop prologue contains forms that are executed before iteration begins, such as any automatic variable initializations prescribed by the variable clauses, along with any initially clauses in the order they appear in the source.

+

Loop body

+The loop body contains those forms that are executed during iteration, including application-specific calculations, termination tests, and variable stepping[1].

+

Loop epilogue

+The loop epilogue contains forms that are executed after iteration terminates, such as finally clauses, if any, along with any implicit return value from an accumulation clause or an termination-test clause.

+

+Some clauses from the source form contribute code only to the loop prologue; these clauses must come before other clauses that are in the main body of the loop form. Others contribute code only to the loop epilogue. All other clauses contribute to the final translated form in the same order given in the original source form of the loop.

+Expansion of the loop macro produces an implicit block named nil unless named is supplied. Thus, return-from (and sometimes return) can be used to return values from loop or to exit loop.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aae.htm new file mode 100644 index 00000000..8699ceec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aae.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 6.1.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5 Summary of Loop Clauses

+Loop clauses fall into one of the following categories:

+ + +

+6.1.1.5.1 Summary of Variable Initialization and Stepping Clauses

+ +

+6.1.1.5.2 Summary of Value Accumulation Clauses

+ +

+6.1.1.5.3 Summary of Termination Test Clauses

+ +

+6.1.1.5.4 Summary of Unconditional Execution Clauses

+ +

+6.1.1.5.5 Summary of Conditional Execution Clauses

+ +

+6.1.1.5.6 Summary of Miscellaneous Clauses

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaea.htm new file mode 100644 index 00000000..d474084f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaea.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 6.1.1.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5.1 Summary of Variable Initialization and Stepping Clauses

+The for and as constructs provide iteration control clauses that establish a variable to be initialized. for and as clauses can be combined with the loop keyword and to get parallel initialization and stepping[1]. Otherwise, the initialization and stepping[1] are sequential.

+The with construct is similar to a single let clause. with clauses can be combined using the loop keyword and to get parallel initialization.

+For more information, see Section 6.1.2 (Variable Initialization and Stepping Clauses).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaeb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaeb.htm new file mode 100644 index 00000000..e5d1e504 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaeb.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 6.1.1.5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5.2 Summary of Value Accumulation Clauses

+The collect (or collecting) construct takes one form in its clause and adds the value of that form to the end of a list of values. By default, the list of values is returned when the loop finishes.

+The append (or appending) construct takes one form in its clause and appends the value of that form to the end of a list of values. By default, the list of values is returned when the loop finishes.

+The nconc (or nconcing) construct is similar to the append construct, but its list values are concatenated as if by the function nconc. By default, the list of values is returned when the loop finishes.

+The sum (or summing) construct takes one form in its clause that must evaluate to a number and accumulates the sum of all these numbers. By default, the cumulative sum is returned when the loop finishes.

+The count (or counting) construct takes one form in its clause and counts the number of times that the form evaluates to true. By default, the count is returned when the loop finishes.

+The minimize (or minimizing) construct takes one form in its clause and determines the minimum value obtained by evaluating that form. By default, the minimum value is returned when the loop finishes.

+The maximize (or maximizing) construct takes one form in its clause and determines the maximum value obtained by evaluating that form. By default, the maximum value is returned when the loop finishes.

+For more information, see Section 6.1.3 (Value Accumulation Clauses).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaec.htm new file mode 100644 index 00000000..258cbb04 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaec.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 6.1.1.5.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5.3 Summary of Termination Test Clauses

+The for and as constructs provide a termination test that is determined by the iteration control clause.

+The repeat construct causes termination after a specified number of iterations. (It uses an internal variable to keep track of the number of iterations.)

+The while construct takes one form, a test, and terminates the iteration if the test evaluates to false. A while clause is equivalent to the expression (if (not test) (loop-finish)).

+The until construct is the inverse of while; it terminates the iteration if the test evaluates to any non-nil value. An until clause is equivalent to the expression (if test (loop-finish)).

+The always construct takes one form and terminates the loop if the form ever evaluates to false; in this case, the loop form returns nil. Otherwise, it provides a default return value of t.

+The never construct takes one form and terminates the loop if the form ever evaluates to true; in this case, the loop form returns nil. Otherwise, it provides a default return value of t.

+The thereis construct takes one form and terminates the loop if the form ever evaluates to a non-nil object; in this case, the loop form returns that object. Otherwise, it provides a default return value of nil.

+If multiple termination test clauses are specified, the loop form terminates if any are satisfied.

+

+For more information, see Section 6.1.4 (Termination Test Clauses).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaed.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaed.htm new file mode 100644 index 00000000..66cf201e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaed.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 6.1.1.5.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5.4 Summary of Unconditional Execution Clauses

+The do (or doing) construct evaluates all forms in its clause.

+The return construct takes one form. Any values returned by the form are immediately returned by the loop form. It is equivalent to the clause do (return-from block-name value), where block-name is the name specified in a named clause, or nil if there is no named clause.

+For more information, see Section 6.1.5 (Unconditional Execution Clauses).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaee.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaee.htm new file mode 100644 index 00000000..ca68aec1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaee.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 6.1.1.5.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5.5 Summary of Conditional Execution Clauses

+The if and when constructs take one form as a test and a clause that is executed when the test yields true. The clause can be a value accumulation, unconditional, or another conditional clause; it can also be any combination of such clauses connected by the loop and keyword.

+The loop unless construct is similar to the loop when construct except that it complements the test result.

+The loop else construct provides an optional component of if, when, and unless clauses that is executed when an if or when test yields false or when an unless test yields true. The component is one of the clauses described under if.

+The loop end construct provides an optional component to mark the end of a conditional clause.

+For more information, see Section 6.1.6 (Conditional Execution Clauses).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaef.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaef.htm new file mode 100644 index 00000000..bea8177c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaef.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 6.1.1.5.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.5.6 Summary of Miscellaneous Clauses

+The loop named construct gives a name for the block of the loop.

+The loop initially construct causes its forms to be evaluated in the loop prologue, which precedes all loop code except for initial settings supplied by the constructs with, for, or as.

+The loop finally construct causes its forms to be evaluated in the loop epilogue after normal iteration terminates.

+For more information, see Section 6.1.7 (Miscellaneous Clauses).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaf.htm new file mode 100644 index 00000000..bec7c7e3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aaf.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 6.1.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.6 Order of Execution

+ With the exceptions listed below, clauses are executed in the loop body in the order in which they appear in the source. Execution is repeated until a clause terminates the loop or until a return, go, or throw form is encountered which transfers control to a point outside of the loop. The following actions are exceptions to the linear order of execution:

+

+

* All variables are initialized first, regardless of where the establishing clauses appear in the source. The order of initialization follows the order of these clauses.

+
* The code for any initially clauses is collected into one progn in the order in which the clauses appear in the source. The collected code is executed once in the loop prologue after any implicit variable initializations.

+
* The code for any finally clauses is collected into one progn in the order in which the clauses appear in the source. The collected code is executed once in the loop epilogue before any implicit values from the accumulation clauses are returned. Explicit returns anywhere in the source, however, will exit the loop without executing the epilogue code.

+
* A with clause introduces a variable binding and an optional initial value. The initial values are calculated in the order in which the with clauses occur.

+
* Iteration control clauses implicitly perform the following actions:

+

-- initialize variables;

+
-- step variables, generally between each execution of the loop body;

+
-- perform termination tests, generally just before the execution of the loop body.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aag.htm new file mode 100644 index 00000000..6f9c593b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aag.htm @@ -0,0 +1,103 @@ + + + +CLHS: Section 6.1.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.7 Destructuring

+The d-type-spec argument is used for destructuring. If the d-type-spec argument consists solely of the type fixnum, float, t, or nil, the of-type keyword is optional. The of-type construct is optional in these cases to provide backwards compatibility; thus, the following two expressions are the same:

+

+;;; This expression uses the old syntax for type specifiers.
+ (loop for i fixnum upfrom 3 ...)
+ 
+;;; This expression uses the new syntax for type specifiers.
+ (loop for i of-type fixnum upfrom 3 ...)
+
+;; Declare X and Y to be of type VECTOR and FIXNUM respectively.
+ (loop for (x y) of-type (vector fixnum) 
+       in l do ...)
+
+

+A type specifier for a destructuring pattern is a tree of type specifiers with the same shape as the tree of variable names, with the following exceptions:

+

* When aligning the trees, an atom in the tree of type specifiers that matches a cons in the variable tree declares the same type for each variable in the subtree rooted at the cons.

+
* A cons in the tree of type specifiers that matches an atom in the tree of variable names is a compound type specifer.

+

+Destructuring allows binding of a set of variables to a corresponding set of values anywhere that a value can normally be bound to a single variable. During loop expansion, each variable in the variable list is matched with the values in the values list. If there are more variables in the variable list than there are values in the values list, the remaining variables are given a value of nil. If there are more values than variables listed, the extra values are discarded.

+ To assign values from a list to the variables a, b, and c, the for clause could be used to bind the variable numlist to the car of the supplied form, and then another for clause could be used to bind the variables a, b, and c sequentially.

+ +

+;; Collect values by using FOR constructs.
+ (loop for numlist in '((1 2 4.0) (5 6 8.3) (8 9 10.4))
+       for a of-type integer = (first numlist)
+       and b of-type integer = (second numlist)
+       and c of-type float = (third numlist)
+       collect (list c b a))
+=>  ((4.0 2 1) (8.3 6 5) (10.4 9 8))
+
+

+Destructuring makes this process easier by allowing the variables to be bound in each loop iteration. Types can be declared by using a list of type-spec arguments. If all the types are the same, a shorthand destructuring syntax can be used, as the second example illustrates.

+

+;; Destructuring simplifies the process.
+ (loop for (a b c) of-type (integer integer float) in
+       '((1 2 4.0) (5 6 8.3) (8 9 10.4))
+       collect (list c b a))
+=>  ((4.0 2 1) (8.3 6 5) (10.4 9 8))
+ 
+
+;; If all the types are the same, this way is even simpler.
+ (loop for (a b c) of-type float in
+       '((1.0 2.0 4.0) (5.0 6.0 8.3) (8.0 9.0 10.4))
+       collect (list c b a))
+=>  ((4.0 2.0 1.0) (8.3 6.0 5.0) (10.4 9.0 8.0))
+
+

+ If destructuring is used to declare or initialize a number of groups of variables into types, the loop keyword and can be used to simplify the process further. +

+;; Initialize and declare variables in parallel by using the AND construct.
+ (loop with (a b) of-type float = '(1.0 2.0)
+       and (c d) of-type integer = '(3 4)
+       and (e f)
+       return (list a b c d e f))
+=>  (1.0 2.0 3 4 NIL NIL)
+
+

+ If nil is used in a destructuring list, no variable is provided for its place.

+

+ (loop for (a nil b) = '(1 2 3)
+       do (return (list a b)))
+=>  (1 3)
+
+

+Note that dotted lists can specify destructuring.

+

+ (loop for (x . y) = '(1 . 2)
+       do (return y))
+=>  2
+ (loop for ((a . b) (c . d)) of-type ((float . float) (integer . integer)) in
+       '(((1.2 . 2.4) (3 . 4)) ((3.4 . 4.6) (5 . 6)))
+       collect (list a b c d))
+=>  ((1.2 2.4 3 4) (3.4 4.6 5 6))
+
+

+An error of type program-error is signaled (at macro expansion time) if the same variable is bound twice in any variable-binding clause of a single loop expression. Such variables include local variables, iteration control variables, and variables found by destructuring.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aah.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aah.htm new file mode 100644 index 00000000..983b0e49 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aah.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 6.1.1.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.1.8 Restrictions on Side-Effects

+ See Section 3.6 (Traversal Rules and Side Effects).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ab.htm new file mode 100644 index 00000000..4fa3da29 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ab.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 6.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2 Variable Initialization and Stepping Clauses

+ + +

+6.1.2.1 Iteration Control

+ +

+6.1.2.2 Local Variable Initializations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aba.htm new file mode 100644 index 00000000..d97bf025 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aba.htm @@ -0,0 +1,56 @@ + + + +CLHS: Section 6.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1 Iteration Control

+Iteration control clauses allow direction of loop iteration. The loop keywords for and as designate iteration control clauses. Iteration control clauses differ with respect to the specification of termination tests and to the initialization and stepping[1] of loop variables. Iteration clauses by themselves do not cause the Loop Facility to return values, but they can be used in conjunction with value-accumulation clauses to return values.

+All variables are initialized in the loop prologue. A variable binding has lexical scope unless it is proclaimed special; thus, by default, the variable can be accessed only by forms that lie textually within the loop. Stepping assignments are made in the loop body before any other forms are evaluated in the body.

+The variable argument in iteration control clauses can be a destructuring list. A destructuring list is a tree whose non-nil atoms are variable names. See Section 6.1.1.7 (Destructuring).

+The iteration control clauses for, as, and repeat must precede any other loop clauses, except initially, with, and named, since they establish variable bindings. When iteration control clauses are used in a loop, the corresponding termination tests in the loop body are evaluated before any other loop body code is executed.

+ If multiple iteration clauses are used to control iteration, variable initialization and stepping[1] occur sequentially by default. The and construct can be used to connect two or more iteration clauses when sequential binding and stepping[1] are not necessary. The iteration behavior of clauses joined by and is analogous to the behavior of the macro do with respect to do*.

+The for and as clauses iterate by using one or more local loop variables that are initialized to some value and that can be modified or stepped[1] after each iteration. For these clauses, iteration terminates when a local variable reaches some supplied value or when some other loop clause terminates iteration. At each iteration, variables can be stepped[1] by an increment or a decrement or can be assigned a new value by the evaluation of a form). Destructuring can be used to assign values to variables during iteration.

+The for and as keywords are synonyms; they can be used interchangeably. There are seven syntactic formats for these constructs. In each syntactic format, the type of var can be supplied by the optional type-spec argument. If var is a destructuring list, the type supplied by the type-spec argument must appropriately match the elements of the list. By convention, for introduces new iterations and as introduces iterations that depend on a previous iteration specification.

+ + +

+6.1.2.1.1 The for-as-arithmetic subclause

+ +

+6.1.2.1.2 The for-as-in-list subclause

+ +

+6.1.2.1.3 The for-as-on-list subclause

+ +

+6.1.2.1.4 The for-as-equals-then subclause

+ +

+6.1.2.1.5 The for-as-across subclause

+ +

+6.1.2.1.6 The for-as-hash subclause

+ +

+6.1.2.1.7 The for-as-package subclause

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaa.htm new file mode 100644 index 00000000..575b965a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaa.htm @@ -0,0 +1,59 @@ + + + +CLHS: Section 6.1.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.1 The for-as-arithmetic subclause

+In the for-as-arithmetic subclause, the for or as construct iterates from the value supplied by form1 to the value supplied by form2 in increments or decrements denoted by form3. Each expression is evaluated only once and must evaluate to a number. The variable var is bound to the value of form1 in the first iteration and is stepped[1] by the value of form3 in each succeeding iteration, or by 1 if form3 is not provided. The following loop keywords serve as valid prepositions within this syntax. At least one of the prepositions must be used; and at most one from each line may be used in a single subclause.

+

+

from | downfrom | upfrom

+
to | downto | upto | below | above

+
by

+ The prepositional phrases in each subclause may appear in any order. For example, either ``from x by y'' or ``by y from x'' is permitted. However, because left-to-right order of evaluation is preserved, the effects will be different in the case of side effects. Consider:

+

+(let ((x 1)) (loop for i from x by (incf x) to 10 collect i))
+=>  (1 3 5 7 9)
+(let ((x 1)) (loop for i by (incf x) from x to 10 collect i))
+=>  (2 4 6 8 10)
+
+

+The descriptions of the prepositions follow:

+

from

+The loop keyword from specifies the value from which stepping[1] begins, as supplied by form1. Stepping[1] is incremental by default. If decremental stepping[1] is desired, the preposition downto or above must be used with form2. For incremental stepping[1], the default from value is 0.

+

downfrom, upfrom

+The loop keyword downfrom indicates that the variable var is decreased in decrements supplied by form3; the loop keyword upfrom indicates that var is increased in increments supplied by form3.

+

to

+The loop keyword to marks the end value for stepping[1] supplied in form2. Stepping[1] is incremental by default. If decremental stepping[1] is desired, the preposition downfrom must be used with form1, or else the preposition downto or above should be used instead of to with form2.

+

downto, upto

+The loop keyword downto specifies decremental stepping; the loop keyword upto specifies incremental stepping. In both cases, the amount of change on each step is specified by form3, and the loop terminates when the variable var passes the value of form2. Since there is no default for form1 in decremental stepping[1], a form1 value must be supplied (using from or downfrom) when downto is supplied.

+

below, above

+The loop keywords below and above are analogous to upto and downto respectively. These keywords stop iteration just before the value of the variable var reaches the value supplied by form2; the end value of form2 is not included. Since there is no default for form1 in decremental stepping[1], a form1 value must be supplied (using from or downfrom) when above is supplied.

+

by

+The loop keyword by marks the increment or decrement supplied by form3. The value of form3 can be any positive number. The default value is 1.

+

+In an iteration control clause, the for or as construct causes termination when the supplied limit is reached. That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2. The range is exclusive if form3 increases or decreases var to the value of form2 without reaching that value; the loop keywords below and above provide exclusive limits. An inclusive limit allows var to attain the value of form2; to, downto, and upto provide inclusive limits.

+ + +

+6.1.2.1.1.1 Examples of for-as-arithmetic subclause

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaaa.htm new file mode 100644 index 00000000..9f09302e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaaa.htm @@ -0,0 +1,55 @@ + + + +CLHS: Section 6.1.2.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.1.1 Examples of for-as-arithmetic subclause

+

+;; Print some numbers.
+ (loop for i from 1 to 3
+       do (print i))
+>>  1
+>>  2
+>>  3
+=>  NIL
+ 
+;; Print every third number.
+ (loop for i from 10 downto 1 by 3
+       do (print i))
+>>  10 
+>>  7 
+>>  4 
+>>  1 
+=>  NIL
+ 
+;; Step incrementally from the default starting value.
+ (loop for i below 3
+       do (print i))
+>>  0
+>>  1
+>>  2
+=>  NIL
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abab.htm new file mode 100644 index 00000000..84dfb2fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abab.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 6.1.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.2 The for-as-in-list subclause

+In the for-as-in-list subclause, the for or as construct iterates over the contents of a list. It checks for the end of the list as if by using endp. The variable var is bound to the successive elements of the list in form1 before each iteration. At the end of each iteration, the function step-fun is applied to the list; the default value for step-fun is cdr. The loop keywords in and by serve as valid prepositions in this syntax. The for or as construct causes termination when the end of the list is reached.

+ + +

+6.1.2.1.2.1 Examples of for-as-in-list subclause

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ababa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ababa.htm new file mode 100644 index 00000000..1bf49a54 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ababa.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 6.1.2.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.2.1 Examples of for-as-in-list subclause

+ +

+;; Print every item in a list.
+ (loop for item in '(1 2 3) do (print item))
+>>  1
+>>  2
+>>  3
+=>  NIL
+ 
+;; Print every other item in a list.
+ (loop for item in '(1 2 3 4 5) by #'cddr
+       do (print item))
+>>  1
+>>  3
+>>  5
+=>  NIL
+ 
+;; Destructure a list, and sum the x values using fixnum arithmetic.
+ (loop for (item . x) of-type (t . fixnum) in '((A . 1) (B . 2) (C . 3))
+       unless (eq item 'B) sum x)
+=>  4
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abac.htm new file mode 100644 index 00000000..434431a5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abac.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 6.1.2.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.3 The for-as-on-list subclause

+ In the for-as-on-list subclause, the for or as construct iterates over a list. It checks for the end of the list as if by using atom. The variable var is bound to the successive tails of the list in form1. At the end of each iteration, the function step-fun is applied to the list; the default value for step-fun is cdr. The loop keywords on and by serve as valid prepositions in this syntax. The for or as construct causes termination when the end of the list is reached.

+ + +

+6.1.2.1.3.1 Examples of for-as-on-list subclause

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaca.htm new file mode 100644 index 00000000..f1fbd26b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaca.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 6.1.2.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.3.1 Examples of for-as-on-list subclause

+

+;; Collect successive tails of a list.
+ (loop for sublist on '(a b c d)
+       collect sublist)
+=>  ((A B C D) (B C D) (C D) (D))
+ 
+;; Print a list by using destructuring with the loop keyword ON.
+ (loop for (item) on '(1 2 3)
+       do (print item))
+>>  1 
+>>  2 
+>>  3 
+=>  NIL
+ 
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abad.htm new file mode 100644 index 00000000..fc64b451 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abad.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 6.1.2.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.4 The for-as-equals-then subclause

+In the for-as-equals-then subclause the for or as construct initializes the variable var by setting it to the result of evaluating form1 on the first iteration, then setting it to the result of evaluating form2 on the second and subsequent iterations. If form2 is omitted, the construct uses form1 on the second and subsequent iterations. The loop keywords = and then serve as valid prepositions in this syntax. This construct does not provide any termination tests.

+ + +

+6.1.2.1.4.1 Examples of for-as-equals-then subclause

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abada.htm new file mode 100644 index 00000000..f24d14e7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abada.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 6.1.2.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.4.1 Examples of for-as-equals-then subclause

+

+;; Collect some numbers.
+ (loop for item = 1 then (+ item 10)
+       for iteration from 1 to 5
+       collect item)
+=>  (1 11 21 31 41)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abae.htm new file mode 100644 index 00000000..6b80a73c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abae.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 6.1.2.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.5 The for-as-across subclause

+ In the for-as-across subclause the for or as construct binds the variable var to the value of each element in the array vector. The loop keyword across marks the array vector; across is used as a preposition in this syntax. Iteration stops when there are no more elements in the supplied array that can be referenced. Some implementations might recognize a the special form in the vector form to produce more efficient code.

+ + +

+6.1.2.1.5.1 Examples of for-as-across subclause

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaea.htm new file mode 100644 index 00000000..53addc24 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaea.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 6.1.2.1.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.5.1 Examples of for-as-across subclause

+

+ (loop for char across (the simple-string (find-message channel))
+       do (write-char char stream))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaf.htm new file mode 100644 index 00000000..f189eec6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaf.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 6.1.2.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.6 The for-as-hash subclause

+ In the for-as-hash subclause the for or as construct iterates over the elements, keys, and values of a hash-table. In this syntax, a compound preposition is used to designate access to a hash table. The variable var takes on the value of each hash key or hash value in the supplied hash-table. The following loop keywords serve as valid prepositions within this syntax:

+

+

being

+The keyword being introduces either the Loop schema hash-key or hash-value.

+

each, the

+The loop keyword each follows the loop keyword being when hash-key or hash-value is used. The loop keyword the is used with hash-keys and hash-values only for ease of reading. This agreement isn't required.

+

hash-key, hash-keys

+These loop keywords access each key entry of the hash table. If the name hash-value is supplied in a using construct with one of these Loop schemas, the iteration can optionally access the keyed value. The order in which the keys are accessed is undefined; empty slots in the hash table are ignored.

+

hash-value, hash-values

+These loop keywords access each value entry of a hash table. If the name hash-key is supplied in a using construct with one of these Loop schemas, the iteration can optionally access the key that corresponds to the value. The order in which the keys are accessed is undefined; empty slots in the hash table are ignored.

+

using

+The loop keyword using introduces the optional key or the keyed value to be accessed. It allows access to the hash key if iteration is over the hash values, and the hash value if iteration is over the hash keys.

+

in, of

+These loop prepositions introduce hash-table.

+

+In effect

+being {each | the} {hash-value | hash-values | hash-key | hash-keys} {in | of}

+is a compound preposition.

+Iteration stops when there are no more hash keys or hash values to be referenced in the supplied hash-table.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abag.htm new file mode 100644 index 00000000..76c5aa9f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abag.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 6.1.2.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.7 The for-as-package subclause

+In the for-as-package subclause the for or as construct iterates over the symbols in a package. In this syntax, a compound preposition is used to designate access to a package. The variable var takes on the value of each symbol in the supplied package. The following loop keywords serve as valid prepositions within this syntax:

+

+

being

+The keyword being introduces either the Loop schema symbol, present-symbol, or external-symbol.

+

each, the

+The loop keyword each follows the loop keyword being when symbol, present-symbol, or external-symbol is used. The loop keyword the is used with symbols, present-symbols, and external-symbols only for ease of reading. This agreement isn't required.

+

present-symbol, present-symbols

+These Loop schemas iterate over the symbols that are present in a package. The package to be iterated over is supplied in the same way that package arguments to find-package are supplied. If the package for the iteration is not supplied, the current package is used. If a package that does not exist is supplied, an error of type package-error is signaled.

+

symbol, symbols

+These Loop schemas iterate over symbols that are accessible in a given package. The package to be iterated over is supplied in the same way that package arguments to find-package are supplied. If the package for the iteration is not supplied, the current package is used. If a package that does not exist is supplied, an error of type package-error is signaled.

+

external-symbol, external-symbols

+These Loop schemas iterate over the external symbols of a package. The package to be iterated over is supplied in the same way that package arguments to find-package are supplied. If the package for the iteration is not supplied, the current package is used. If a package that does not exist is supplied, an error of type package-error is signaled.

+

in, of

+These loop prepositions introduce package.

+

+In effect

+being {each | the} {symbol | symbols | present-symbol | present-symbols | external-symbol | external-symbols} {in | of}

+is a compound preposition.

+Iteration stops when there are no more symbols to be referenced in the supplied package.

+ + +

+6.1.2.1.7.1 Examples of for-as-package subclause

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaga.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaga.htm new file mode 100644 index 00000000..67b41746 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abaga.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 6.1.2.1.7.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.1.7.1 Examples of for-as-package subclause

+ +

+ (let ((*package* (make-package "TEST-PACKAGE-1")))
+   ;; For effect, intern some symbols
+   (read-from-string "(THIS IS A TEST)")
+   (export (intern "THIS"))
+   (loop for x being each present-symbol of *package*
+          do (print x)))
+>>  A 
+>>  TEST 
+>>  THIS
+>>  IS 
+=>  NIL
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abb.htm new file mode 100644 index 00000000..82f116c1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abb.htm @@ -0,0 +1,77 @@ + + + +CLHS: Section 6.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.2 Local Variable Initializations

+When a loop form is executed, the local variables are bound and are initialized to some value. These local variables exist until loop iteration terminates, at which point they cease to exist. Implicit variables are also established by iteration control clauses and the into preposition of accumulation clauses.

+The with construct initializes variables that are local to a loop. The variables are initialized one time only. If the optional type-spec argument is supplied for the variable var, but there is no related expression to be evaluated, var is initialized to an appropriate default value for its type. For example, for the types t, number, and float, the default values are nil, 0, and 0.0 respectively. The consequences are undefined if a type-spec argument is supplied for var if the related expression returns a value that is not of the supplied type. By default, the with construct initializes variables sequentially; that is, one variable is assigned a value before the next expression is evaluated. However, by using the loop keyword and to join several with clauses, initializations can be forced to occur in parallel; that is, all of the supplied forms are evaluated, and the results are bound to the respective variables simultaneously.

+Sequential binding is used when it is desireable for the initialization of some variables to depend on the values of previously bound variables. For example, suppose the variables a, b, and c are to be bound in sequence:

+

+ (loop with a = 1 
+       with b = (+ a 2) 
+       with c = (+ b 3)
+       return (list a b c))
+=>  (1 3 6)
+
+

+The execution of the above loop is equivalent to the execution of the following code:

+ +

+ (block nil
+   (let* ((a 1)
+          (b (+ a 2))
+          (c (+ b 3)))
+     (tagbody
+         (next-loop (return (list a b c))
+                    (go next-loop)
+                    end-loop))))
+
+

+If the values of previously bound variables are not needed for the initialization of other local variables, an and clause can be used to specify that the bindings are to occur in parallel:

+

+ (loop with a = 1 
+       and b = 2 
+       and c = 3
+       return (list a b c))
+=>  (1 2 3)
+
+

+The execution of the above loop is equivalent to the execution of the following code:

+ +

+ (block nil
+   (let ((a 1)
+         (b 2)
+         (c 3))
+     (tagbody
+         (next-loop (return (list a b c))
+                    (go next-loop)
+                    end-loop))))
+
+

+ + +

+6.1.2.2.1 Examples of WITH clause

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abba.htm new file mode 100644 index 00000000..4ee27886 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_abba.htm @@ -0,0 +1,58 @@ + + + +CLHS: Section 6.1.2.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.2.2.1 Examples of WITH clause

+

+;; These bindings occur in sequence.
+ (loop with a = 1 
+       with b = (+ a 2) 
+       with c = (+ b 3)
+       return (list a b c))
+=>  (1 3 6)
+ 
+;; These bindings occur in parallel.
+ (setq a 5 b 10)
+=>  10
+ (loop with a = 1
+       and b = (+ a 2)
+       and c = (+ b 3)
+       return (list a b c))
+=>  (1 7 13)
+ 
+;; This example shows a shorthand way to declare local variables 
+;; that are of different types.
+ (loop with (a b c) of-type (float integer float)
+       return (format nil "~A ~A ~A" a b c))
+=>  "0.0 0 0.0"
+ 
+;; This example shows a shorthand way to declare local variables 
+;; that are the same type.
+ (loop with (a b c) of-type float 
+       return (format nil "~A ~A ~A" a b c))
+=>  "0.0 0.0 0.0"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ac.htm new file mode 100644 index 00000000..7a88c429 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ac.htm @@ -0,0 +1,69 @@ + + + +CLHS: Section 6.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.3 Value Accumulation Clauses

+The constructs collect, collecting, append, appending, nconc, nconcing, count, counting, maximize, maximizing, minimize, minimizing, sum, and summing, allow values to be accumulated in a loop.

+ The constructs collect, collecting, append, appending, nconc, and nconcing, designate clauses that accumulate values in lists and return them. The constructs count, counting, maximize, maximizing, minimize, minimizing, sum, and summing designate clauses that accumulate and return numerical values.

+During each iteration, the constructs collect and collecting collect the value of the supplied form into a list. When iteration terminates, the list is returned. The argument var is set to the list of collected values; if var is supplied, the loop does not return the final list automatically. If var is not supplied, it is equivalent to supplying an internal name for var and returning its value in a finally clause. The var argument is bound as if by the construct with. No mechanism is provided for declaring the type of var; it must be of type list.

+The constructs append, appending, nconc, and nconcing are similar to collect except that the values of the supplied form must be lists.

+

* The append keyword causes its list values to be concatenated into a single list, as if they were arguments to the function append.

+
* The nconc keyword causes its list values to be concatenated into a single list, as if they were arguments to the function nconc.

+The argument var is set to the list of concatenated values; if var is supplied, loop does not return the final list automatically. The var argument is bound as if by the construct with. A type cannot be supplied for var; it must be of type list. The construct nconc destructively modifies its argument lists.

+The count construct counts the number of times that the supplied form returns true. The argument var accumulates the number of occurrences; if var is supplied, loop does not return the final count automatically. The var argument is bound as if by the construct with to a zero of the appropriate type. Subsequent values (including any necessary coercions) are computed as if by the function 1+. If into var is used, a type can be supplied for var with the type-spec argument; the consequences are unspecified if a nonnumeric type is supplied. If there is no into variable, the optional type-spec argument applies to the internal variable that is keeping the count. The default type is implementation-dependent; but it must be a supertype of type fixnum.

+The maximize and minimize constructs compare the value of the supplied form obtained during the first iteration with values obtained in successive iterations. The maximum (for maximize) or minimum (for minimize) value encountered is determined (as if by the function max for maximize and as if by the function min for minimize) and returned. If the maximize or minimize clause is never executed, the accumulated value is unspecified. The argument var accumulates the maximum or minimum value; if var is supplied, loop does not return the maximum or minimum automatically. The var argument is bound as if by the construct with. If into var is used, a type can be supplied for var with the type-spec argument; the consequences are unspecified if a nonnumeric type is supplied. If there is no into variable, the optional type-spec argument applies to the internal variable that is keeping the maximum or minimum value. The default type is implementation-dependent; but it must be a supertype of type real.

+The sum construct forms a cumulative sum of the successive primary values of the supplied form at each iteration. The argument var is used to accumulate the sum; if var is supplied, loop does not return the final sum automatically. The var argument is bound as if by the construct with to a zero of the appropriate type. Subsequent values (including any necessary coercions) are computed as if by the function +. If into var is used, a type can be supplied for var with the type-spec argument; the consequences are unspecified if a nonnumeric type is supplied. If there is no into variable, the optional type-spec argument applies to the internal variable that is keeping the sum. The default type is implementation-dependent; but it must be a supertype of type number.

+If into is used, the construct does not provide a default return value; however, the variable is available for use in any finally clause.

+ Certain kinds of accumulation clauses can be combined in a loop if their destination is the same (the result of loop or an into var) because they are considered to accumulate conceptually compatible quantities. In particular, any elements of following sets of accumulation clauses can be mixed with other elements of the same set for the same destination in a loop form:

+

* collect, append, nconc

+
* sum, count

+
* maximize, minimize

+

+;; Collect every name and the kids in one list by using 
+;; COLLECT and APPEND.
+ (loop for name in '(fred sue alice joe june)
+       for kids in '((bob ken) () () (kris sunshine) ())
+       collect name
+       append kids)
+=>  (FRED BOB KEN SUE ALICE JOE KRIS SUNSHINE JUNE)
+
+

+Any two clauses that do not accumulate the same type of object can coexist in a loop only if each clause accumulates its values into a different variable.

+ + +

+6.1.3.1 Examples of COLLECT clause

+ +

+6.1.3.2 Examples of APPEND and NCONC clauses

+ +

+6.1.3.3 Examples of COUNT clause

+ +

+6.1.3.4 Examples of MAXIMIZE and MINIMIZE clauses

+ +

+6.1.3.5 Examples of SUM clause

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aca.htm new file mode 100644 index 00000000..9251fce0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aca.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 6.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.3.1 Examples of COLLECT clause

+

+;; Collect all the symbols in a list.
+ (loop for i in '(bird 3 4 turtle (1 . 4) horse cat)
+       when (symbolp i) collect i)
+=>  (BIRD TURTLE HORSE CAT)
+ 
+;; Collect and return odd numbers.
+ (loop for i from 1 to 10
+       if (oddp i) collect i)
+=>  (1 3 5 7 9)
+ 
+;; Collect items into local variable, but don't return them.
+ (loop for i in '(a b c d) by #'cddr
+       collect i into my-list
+       finally (print my-list))
+>>  (A C) 
+=>  NIL
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acb.htm new file mode 100644 index 00000000..0c2fb5cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acb.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 6.1.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.3.2 Examples of APPEND and NCONC clauses

+

+;; Use APPEND to concatenate some sublists.
+  (loop for x in '((a) (b) ((c)))
+        append x)
+=>  (A B (C))
+ 
+;; NCONC some sublists together.  Note that only lists made by the
+;; call to LIST are modified.
+  (loop for i upfrom 0 
+        as x in '(a b (c))
+        nconc (if (evenp i) (list x) nil))
+=>  (A (C))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acc.htm new file mode 100644 index 00000000..8d58d5ac --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acc.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 6.1.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.3.3 Examples of COUNT clause

+

+ (loop for i in '(a b nil c nil d e)
+       count i)
+=>  5
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acd.htm new file mode 100644 index 00000000..aad9307c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_acd.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 6.1.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.3.4 Examples of MAXIMIZE and MINIMIZE clauses

+

+ (loop for i in '(2 1 5 3 4)
+       maximize i)
+=>  5
+ (loop for i in '(2 1 5 3 4)
+       minimize i)
+=>  1
+ 
+;; In this example, FIXNUM applies to the internal variable that holds
+;; the maximum value.
+ (setq series '(1.2 4.3 5.7))
+=>  (1.2 4.3 5.7)
+ (loop for v in series 
+       maximize (round v) of-type fixnum)
+=>  6
+ 
+;; In this example, FIXNUM applies to the variable RESULT.
+ (loop for v of-type float in series
+       minimize (round v) into result of-type fixnum
+       finally (return result))
+=>  1
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ace.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ace.htm new file mode 100644 index 00000000..24ee8b2b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ace.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 6.1.3.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.3.5 Examples of SUM clause

+

+ (loop for i of-type fixnum in '(1 2 3 4 5)
+       sum i)
+=>  15
+ (setq series '(1.2 4.3 5.7))
+=>  (1.2 4.3 5.7)
+ (loop for v in series 
+       sum (* 2.0 v))
+=>  22.4
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ad.htm new file mode 100644 index 00000000..8ef0257b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ad.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 6.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.4 Termination Test Clauses

+The repeat construct causes iteration to terminate after a specified number of times. The loop body executes n times, where n is the value of the expression form. The form argument is evaluated one time in the loop prologue. If the expression evaluates to 0 or to a negative number, the loop body is not evaluated.

+The constructs always, never, thereis, while, until, and the macro loop-finish allow conditional termination of iteration within a loop.

+The constructs always, never, and thereis provide specific values to be returned when a loop terminates. Using always, never, or thereis in a loop with value accumulation clauses that are not into causes an error of type program-error to be signaled (at macro expansion time). Since always, never, and thereis use the return-from special operator to terminate iteration, any finally clause that is supplied is not evaluated when exit occurs due to any of these constructs. In all other respects these constructs behave like the while and until constructs.

+ The always construct takes one form and terminates the loop if the form ever evaluates to nil; in this case, it returns nil. Otherwise, it provides a default return value of t. If the value of the supplied form is never nil, some other construct can terminate the iteration.

+The never construct terminates iteration the first time that the value of the supplied form is non-nil; the loop returns nil. If the value of the supplied form is always nil, some other construct can terminate the iteration. Unless some other clause contributes a return value, the default value returned is t.

+The thereis construct terminates iteration the first time that the value of the supplied form is non-nil; the loop returns the value of the supplied form. If the value of the supplied form is always nil, some other construct can terminate the iteration. Unless some other clause contributes a return value, the default value returned is nil.

+ There are two differences between the thereis and until constructs:

+

* The until construct does not return a value or nil based on the value of the supplied form.

+
* The until construct executes any finally clause. Since thereis uses the return-from special operator to terminate iteration, any finally clause that is supplied is not evaluated when exit occurs due to thereis.

+

+ The while construct allows iteration to continue until the supplied form evaluates to false. The supplied form is reevaluated at the location of the while clause.

+The until construct is equivalent to while (not form).... If the value of the supplied form is non-nil, iteration terminates.

+Termination-test control constructs can be used anywhere within the loop body. The termination tests are used in the order in which they appear. If an until or while clause causes termination, any clauses that precede it in the source are still evaluated. If the until and while constructs cause termination, control is passed to the loop epilogue, where any finally clauses will be executed.

+There are two differences between the never and until constructs:

+

* The until construct does not return t or nil based on the value of the supplied form.

+
* The until construct does not bypass any finally clauses. Since never uses the return-from special operator to terminate iteration, any finally clause that is supplied is not evaluated when exit occurs due to never.

+In most cases it is not necessary to use loop-finish because other loop control clauses terminate the loop. The macro loop-finish is used to provide a normal exit from a nested conditional inside a loop. Since loop-finish transfers control to the loop epilogue, using loop-finish within a finally expression can cause infinite looping.

+ + +

+6.1.4.1 Examples of REPEAT clause

+ +

+6.1.4.2 Examples of ALWAYS, NEVER, and THEREIS clauses

+ +

+6.1.4.3 Examples of WHILE and UNTIL clauses

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ada.htm new file mode 100644 index 00000000..ede49c17 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ada.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 6.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.4.1 Examples of REPEAT clause

+

+ (loop repeat 3
+       do (format t "~&What I say three times is true.~%"))
+>>  What I say three times is true.
+>>  What I say three times is true.
+>>  What I say three times is true.
+=>  NIL
+ (loop repeat -15
+   do (format t "What you see is what you expect~%"))
+=>  NIL
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adb.htm new file mode 100644 index 00000000..4a4ebbbc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adb.htm @@ -0,0 +1,81 @@ + + + +CLHS: Section 6.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.4.2 Examples of ALWAYS, NEVER, and THEREIS clauses

+

+;; Make sure I is always less than 11 (two ways).
+;; The FOR construct terminates these loops.
+ (loop for i from 0 to 10
+       always (< i 11))
+=>  T
+ (loop for i from 0 to 10
+       never (> i 11))
+=>  T
+ 
+;; If I exceeds 10 return I; otherwise, return NIL.
+;; The THEREIS construct terminates this loop.
+ (loop for i from 0
+       thereis (when (> i 10) i) )
+=>  11
+
+;;; The FINALLY clause is not evaluated in these examples.
+ (loop for i from 0 to 10
+       always (< i 9)
+       finally (print "you won't see this"))
+=>  NIL
+ (loop never t
+       finally (print "you won't see this"))
+=>  NIL
+ (loop thereis "Here is my value"
+       finally (print "you won't see this"))
+=>  "Here is my value"
+ 
+;; The FOR construct terminates this loop, so the FINALLY clause 
+;; is evaluated.
+ (loop for i from 1 to 10
+       thereis (> i 11)
+       finally (prin1 'got-here))
+>>  GOT-HERE
+=>  NIL
+ 
+;; If this code could be used to find a counterexample to Fermat's
+;; last theorem, it would still not return the value of the
+;; counterexample because all of the THEREIS clauses in this example
+;; only return T.  But if Fermat is right, that won't matter
+;; because this won't terminate.
+ 
+ (loop for z upfrom 2
+       thereis
+         (loop for n upfrom 3 below (log z 2)
+               thereis
+                 (loop for x below z
+                       thereis
+                         (loop for y below z
+                               thereis (= (+ (expt x n) (expt y n))
+                                          (expt z n))))))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adc.htm new file mode 100644 index 00000000..a088ea21 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_adc.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 6.1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.4.3 Examples of WHILE and UNTIL clauses

+

+ (loop while (hungry-p) do (eat))
+ 
+;; UNTIL NOT is equivalent to WHILE.
+ (loop until (not (hungry-p)) do (eat))
+ 
+;; Collect the length and the items of STACK.
+ (let ((stack '(a b c d e f)))
+   (loop for item = (length stack) then (pop stack)
+         collect item
+         while stack))
+=>  (6 A B C D E F)
+ 
+;; Use WHILE to terminate a loop that otherwise wouldn't terminate.
+;; Note that WHILE occurs after the WHEN.
+ (loop for i fixnum from 3
+       when (oddp i) collect i
+       while (< i 5))
+=>  (3 5)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ae.htm new file mode 100644 index 00000000..dceee4e8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ae.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 6.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.5 Unconditional Execution Clauses

+The do and doing constructs evaluate the supplied forms wherever they occur in the expanded form of loop. The form argument can be any compound form. Each form is evaluated in every iteration. Because every loop clause must begin with a loop keyword, the keyword do is used when no control action other than execution is required.

+ The return construct takes one form. Any values returned by the form are immediately returned by the loop form. It is equivalent to the clause do (return-from block-name value), where block-name is the name specified in a named clause, or nil if there is no named clause.

+ + +

+6.1.5.1 Examples of unconditional execution

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aea.htm new file mode 100644 index 00000000..1f626b14 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aea.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 6.1.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.5.1 Examples of unconditional execution

+

+;; Print numbers and their squares.
+;; The DO construct applies to multiple forms.
+ (loop for i from 1 to 3
+       do (print i)
+          (print (* i i)))
+>>  1 
+>>  1 
+>>  2 
+>>  4 
+>>  3 
+>>  9 
+=>  NIL
+
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_af.htm new file mode 100644 index 00000000..7a5c1f6f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_af.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 6.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.6 Conditional Execution Clauses

+

+The if, when, and unless constructs establish conditional control in a loop. If the test passes, the succeeding loop clause is executed. If the test does not pass, the succeeding clause is skipped, and program control moves to the clause that follows the loop keyword else. If the test does not pass and no else clause is supplied, control is transferred to the clause or construct following the entire conditional clause.

+If conditional clauses are nested, each else is paired with the closest preceding conditional clause that has no associated else or end.

+In the if and when clauses, which are synonymous, the test passes if the value of form is true.

+In the unless clause, the test passes if the value of form is false.

+

+Clauses that follow the test expression can be grouped by using the loop keyword and to produce a conditional block consisting of a compound clause.

+ The loop keyword it can be used to refer to the result of the test expression in a clause. Use the loop keyword it in place of the form in a return clause or an accumulation clause that is inside a conditional execution clause. If multiple clauses are connected with and, the it construct must be in the first clause in the block.

+The optional loop keyword end marks the end of the clause. If this keyword is not supplied, the next loop keyword marks the end. The construct end can be used to distinguish the scoping of compound clauses.

+ + +

+6.1.6.1 Examples of WHEN clause

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_afa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_afa.htm new file mode 100644 index 00000000..5b067baf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_afa.htm @@ -0,0 +1,72 @@ + + + +CLHS: Section 6.1.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.6.1 Examples of WHEN clause

+

+;; Signal an exceptional condition.
+ (loop for item in '(1 2 3 a 4 5)
+       when (not (numberp item))
+        return (cerror "enter new value" "non-numeric value: ~s" item))
+Error: non-numeric value: A
+ 
+;; The previous example is equivalent to the following one.
+ (loop for item in '(1 2 3 a 4 5)
+       when (not (numberp item))
+        do (return 
+            (cerror "Enter new value" "non-numeric value: ~s" item)))
+Error: non-numeric value: A
+
+

+

+;; This example parses a simple printed string representation from 
+;; BUFFER (which is itself a string) and returns the index of the
+;; closing double-quote character.
+ (let ((buffer "\"a\" \"b\""))
+   (loop initially (unless (char= (char buffer 0) #\")
+                     (loop-finish))
+         for i of-type fixnum from 1 below (length (the string buffer))
+         when (char= (char buffer i) #\")
+          return i))
+=>  2
+ 
+;; The collected value is returned.
+ (loop for i from 1 to 10
+       when (> i 5)
+         collect i
+       finally (prin1 'got-here))
+>>  GOT-HERE
+=>  (6 7 8 9 10) 
+
+;; Return both the count of collected numbers and the numbers.
+ (loop for i from 1 to 10
+       when (> i 5)
+         collect i into number-list
+         and count i into number-count
+       finally (return (values number-count number-list)))
+=>  5, (6 7 8 9 10)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ag.htm new file mode 100644 index 00000000..8687315a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ag.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 6.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.7 Miscellaneous Clauses

+ + +

+6.1.7.1 Control Transfer Clauses

+ +

+6.1.7.2 Initial and Final Execution

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aga.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aga.htm new file mode 100644 index 00000000..6c404624 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aga.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 6.1.7.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.7.1 Control Transfer Clauses

+The named construct establishes a name for an implicit block surrounding the entire loop so that the return-from special operator can be used to return values from or to exit loop. Only one name per loop form can be assigned. If used, the named construct must be the first clause in the loop expression.

+ The return construct takes one form. Any values returned by the form are immediately returned by the loop form. This construct is similar to the return-from special operator and the return macro. The return construct does not execute any finally clause that the loop form is given.

+ + +

+6.1.7.1.1 Examples of NAMED clause

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agaa.htm new file mode 100644 index 00000000..b1a341fa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agaa.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 6.1.7.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.7.1.1 Examples of NAMED clause

+

+;; Just name and return.
+ (loop named max
+       for i from 1 to 10
+       do (print i)
+       do (return-from max 'done))
+>>  1 
+=>  DONE
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agb.htm new file mode 100644 index 00000000..66299785 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_agb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 6.1.7.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.7.2 Initial and Final Execution

+The initially and finally constructs evaluate forms that occur before and after the loop body.

+The initially construct causes the supplied compound-forms to be evaluated in the loop prologue, which precedes all loop code except for initial settings supplied by constructs with, for, or as. The code for any initially clauses is executed in the order in which the clauses appeared in the loop.

+The finally construct causes the supplied compound-forms to be evaluated in the loop epilogue after normal iteration terminates. The code for any finally clauses is executed in the order in which the clauses appeared in the loop. The collected code is executed once in the loop epilogue before any implicit values are returned from the accumulation clauses. An explicit transfer of control (e.g., by return, go, or throw) from the loop body, however, will exit the loop without executing the epilogue code.

+Clauses such as return, always, never, and thereis can bypass the finally clause. return (or return-from, if the named option was supplied) can be used after finally to return values from a loop. Such an explicit return inside the finally clause takes precedence over returning the accumulation from clauses supplied by such keywords as collect, nconc, append, sum, count, maximize, and minimize; the accumulation values for these preempted clauses are not returned by loop if return or return-from is used.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ah.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ah.htm new file mode 100644 index 00000000..1dadb7b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ah.htm @@ -0,0 +1,57 @@ + + + +CLHS: Section 6.1.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.8 Examples of Miscellaneous Loop Features

+

+ (let ((i 0))                     ; no loop keywords are used
+    (loop (incf i) (if (= i 3) (return i)))) =>  3
+ (let ((i 0)(j 0))
+    (tagbody
+      (loop (incf j 3) (incf i) (if (= i 3) (go exit)))
+      exit)
+    j) =>  9
+
+

+In the following example, the variable x is stepped before y is stepped; thus, the value of y reflects the updated value of x:

+

+ (loop for x from 1 to 10 
+       for y = nil then x 
+       collect (list x y))
+=>  ((1 NIL) (2 2) (3 3) (4 4) (5 5) (6 6) (7 7) (8 8) (9 9) (10 10))
+
+

+In this example, x and y are stepped in parallel:

+

+ (loop for x from 1 to 10 
+       and y = nil then x 
+       collect (list x y))
+=>  ((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
+
+

+ + +

+6.1.8.1 Examples of clause grouping

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aha.htm new file mode 100644 index 00000000..1972ab16 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_aha.htm @@ -0,0 +1,99 @@ + + + +CLHS: Section 6.1.8.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.8.1 Examples of clause grouping

+
+;; Group conditional clauses.
+ (loop for i in '(1 324 2345 323 2 4 235 252)
+       when (oddp i)
+         do (print i)
+         and collect i into odd-numbers
+         and do (terpri)
+       else                              ; I is even.
+         collect i into even-numbers
+       finally
+         (return (values odd-numbers even-numbers)))
+>>  1 
+>>  
+>>  2345 
+>>  
+>>  323 
+>>  
+>>  235 
+=>  (1 2345 323 235), (324 2 4 252)
+
+;; Collect numbers larger than 3.
+ (loop for i in '(1 2 3 4 5 6)
+       when (and (> i 3) i)
+       collect it)                      ; IT refers to (and (> i 3) i).
+=>  (4 5 6)
+ 
+;; Find a number in a list.
+ (loop for i in '(1 2 3 4 5 6)
+       when (and (> i 3) i)
+       return it)
+=>  4
+     
+;; The above example is similar to the following one.
+ (loop for i in '(1 2 3 4 5 6)
+       thereis (and (> i 3) i))
+=>  4
+
+
+;; Nest conditional clauses.
+ (let ((list '(0 3.0 apple 4 5 9.8 orange banana)))
+   (loop for i in list
+         when (numberp i)
+           when (floatp i)
+             collect i into float-numbers
+           else                                  ; Not (floatp i)
+             collect i into other-numbers
+         else                                    ; Not (numberp i)
+           when (symbolp i) 
+             collect i into symbol-list
+           else                                  ; Not (symbolp i)
+             do (error "found a funny value in list ~S, value ~S~%" list i)
+         finally (return (values float-numbers other-numbers symbol-list))))
+=>  (3.0 9.8), (0 4 5), (APPLE ORANGE BANANA)
+
+;; Without the END preposition, the last AND would apply to the
+;; inner IF rather than the outer one.
+ (loop for x from 0 to 3 
+       do (print x)
+       if (zerop (mod x 2))
+         do (princ " a")
+          and if (zerop (floor x 2))
+                do (princ " b")
+                end
+          and do (princ " c"))
+>>  0  a b c
+>>  1 
+>>  2  a c
+>>  3 
+=>  NIL
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ai.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ai.htm new file mode 100644 index 00000000..9e5e9b78 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/06_ai.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 6.1.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.1.9 Notes about Loop

+Types can be supplied for loop variables. It is not necessary to supply a type for any variable, but supplying the type can ensure that the variable has a correctly typed initial value, and it can also enable compiler optimizations (depending on the implementation).

+The clause repeat n ... is roughly equivalent to a clause such as

+

+ (loop for internal-variable downfrom (- n 1) to 0 ...)
+
+

+but in some implementations, the repeat construct might be more efficient.

+Within the executable parts of the loop clauses and around the entire loop form, variables can be bound by using let.

+ Use caution when using a variable named IT (in any package) in connection with loop, since it is a loop keyword that can be used in place of a form in certain contexts.

+There is no standardized mechanism for users to add extensions to loop.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_.htm new file mode 100644 index 00000000..a2ad4905 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_.htm @@ -0,0 +1,54 @@ + + + +CLHS: Chapter 7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+7. Objects

+

+ + +

+7.1 Object Creation and Initialization

+ +

+7.2 Changing the Class of an Instance

+ +

+7.3 Reinitializing an Instance

+ +

+7.4 Meta-Objects

+ +

+7.5 Slots

+ +

+7.6 Generic Functions and Methods

+ +

+7.7 The Objects Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_a.htm new file mode 100644 index 00000000..459e04f5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_a.htm @@ -0,0 +1,58 @@ + + + +CLHS: Section 7.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1 Object Creation and Initialization

+ The generic function make-instance creates and returns a new instance of a class. The first argument is a class or the name of a class, and the remaining arguments form an initialization argument list.

+The initialization of a new instance consists of several distinct steps, including the following: combining the explicitly supplied initialization arguments with default values for the unsupplied initialization arguments, checking the validity of the initialization arguments, allocating storage for the instance, filling slots with values, and executing user-supplied methods that perform additional initialization. Each step of make-instance is implemented by a generic function to provide a mechanism for customizing that step. In addition, make-instance is itself a generic function and thus also can be customized.

+The object system specifies system-supplied primary methods for each step and thus specifies a well-defined standard behavior for the entire initialization process. The standard behavior provides four simple mechanisms for controlling initialization:

+

+

* Declaring a symbol to be an initialization argument for a slot. An initialization argument is declared by using the :initarg slot option to defclass. This provides a mechanism for supplying a value for a slot in a call to make-instance.

+
* Supplying a default value form for an initialization argument. Default value forms for initialization arguments are defined by using the :default-initargs class option to defclass. If an initialization argument is not explicitly provided as an argument to make-instance, the default value form is evaluated in the lexical environment of the defclass form that defined it, and the resulting value is used as the value of the initialization argument.

+
* Supplying a default initial value form for a slot. A default initial value form for a slot is defined by using the :initform slot option to defclass. If no initialization argument associated with that slot is given as an argument to make-instance or is defaulted by :default-initargs, this default initial value form is evaluated in the lexical environment of the defclass form that defined it, and the resulting value is stored in the slot. The :initform form for a local slot may be used when creating an instance, when updating an instance to conform to a redefined class, or when updating an instance to conform to the definition of a different class. The :initform form for a shared slot may be used when defining or re-defining the class.

+
* Defining methods for initialize-instance and shared-initialize. The slot-filling behavior described above is implemented by a system-supplied primary method for initialize-instance which invokes shared-initialize. The generic function shared-initialize implements the parts of initialization shared by these four situations: when making an instance, when re-initializing an instance, when updating an instance to conform to a redefined class, and when updating an instance to conform to the definition of a different class. The system-supplied primary method for shared-initialize directly implements the slot-filling behavior described above, and initialize-instance simply invokes shared-initialize.

+

+ + +

+7.1.1 Initialization Arguments

+ +

+7.1.2 Declaring the Validity of Initialization Arguments

+ +

+7.1.3 Defaulting of Initialization Arguments

+ +

+7.1.4 Rules for Initialization Arguments

+ +

+7.1.5 Shared-Initialize

+ +

+7.1.6 Initialize-Instance

+ +

+7.1.7 Definitions of Make-Instance and Initialize-Instance

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_aa.htm new file mode 100644 index 00000000..a622b506 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_aa.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 7.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.1 Initialization Arguments

+An initialization argument controls object creation and initialization. It is often convenient to use keyword symbols to name initialization arguments, but the name of an initialization argument can be any symbol, including nil. An initialization argument can be used in two ways: to fill a slot with a value or to provide an argument for an initialization method. A single initialization argument can be used for both purposes.

+ An initialization argument list is a property list of initialization argument names and values. Its structure is identical to a property list and also to the portion of an argument list processed for &key parameters. As in those lists, if an initialization argument name appears more than once in an initialization argument list, the leftmost occurrence supplies the value and the remaining occurrences are ignored. The arguments to make-instance (after the first argument) form an initialization argument list.

+An initialization argument can be associated with a slot. If the initialization argument has a value in the initialization argument list, the value is stored into the slot of the newly created object, overriding any :initform form associated with the slot. A single initialization argument can initialize more than one slot. An initialization argument that initializes a shared slot stores its value into the shared slot, replacing any previous value.

+An initialization argument can be associated with a method. When an object is created and a particular initialization argument is supplied, the generic functions initialize-instance, shared-initialize, and allocate-instance are called with that initialization argument's name and value as a keyword argument pair. If a value for the initialization argument is not supplied in the initialization argument list, the method's lambda list supplies a default value.

+Initialization arguments are used in four situations: when making an instance, when re-initializing an instance, when updating an instance to conform to a redefined class, and when updating an instance to conform to the definition of a different class.

+Because initialization arguments are used to control the creation and initialization of an instance of some particular class, we say that an initialization argument is ``an initialization argument for'' that class.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ab.htm new file mode 100644 index 00000000..6f0b8988 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ab.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 7.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.2 Declaring the Validity of Initialization Arguments

+Initialization arguments are checked for validity in each of the four situations that use them. An initialization argument may be valid in one situation and not another. For example, the system-supplied primary method for make-instance defined for the class standard-class checks the validity of its initialization arguments and signals an error if an initialization argument is supplied that is not declared as valid in that situation.

+There are two means for declaring initialization arguments valid.

+

+

* Initialization arguments that fill slots are declared as valid by the :initarg slot option to defclass. The :initarg slot option is inherited from superclasses. Thus the set of valid initialization arguments that fill slots for a class is the union of the initialization arguments that fill slots declared as valid by that class and its superclasses. Initialization arguments that fill slots are valid in all four contexts.

+
* Initialization arguments that supply arguments to methods are declared as valid by defining those methods. The keyword name of each keyword parameter specified in the method's lambda list becomes an initialization argument for all classes for which the method is applicable. The presence of &allow-other-keys in the lambda list of an applicable method disables validity checking of initialization arguments. Thus method inheritance controls the set of valid initialization arguments that supply arguments to methods. The generic functions for which method definitions serve to declare initialization arguments valid are as follows:

-- Making an instance of a class: allocate-instance, initialize-instance, and shared-initialize. Initialization arguments declared as valid by these methods are valid when making an instance of a class.

+
-- Re-initializing an instance: reinitialize-instance and shared-initialize. Initialization arguments declared as valid by these methods are valid when re-initializing an instance.

+
-- Updating an instance to conform to a redefined class: update-instance-for-redefined-class and shared-initialize. Initialization arguments declared as valid by these methods are valid when updating an instance to conform to a redefined class.

+
-- Updating an instance to conform to the definition of a different class: update-instance-for-different-class and shared-initialize. Initialization arguments declared as valid by these methods are valid when updating an instance to conform to the definition of a different class.

+

+The set of valid initialization arguments for a class is the set of valid initialization arguments that either fill slots or supply arguments to methods, along with the predefined initialization argument :allow-other-keys. The default value for :allow-other-keys is nil. Validity checking of initialization arguments is disabled if the value of the initialization argument :allow-other-keys is true.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ac.htm new file mode 100644 index 00000000..3fb861a8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ac.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 7.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.3 Defaulting of Initialization Arguments

+A default value form can be supplied for an initialization argument by using the :default-initargs class option. If an initialization argument is declared valid by some particular class, its default value form might be specified by a different class. In this case :default-initargs is used to supply a default value for an inherited initialization argument.

+The :default-initargs option is used only to provide default values for initialization arguments; it does not declare a symbol as a valid initialization argument name. Furthermore, the :default-initargs option is used only to provide default values for initialization arguments when making an instance.

+The argument to the :default-initargs class option is a list of alternating initialization argument names and forms. Each form is the default value form for the corresponding initialization argument. The default value form of an initialization argument is used and evaluated only if that initialization argument does not appear in the arguments to make-instance and is not defaulted by a more specific class. The default value form is evaluated in the lexical environment of the defclass form that supplied it; the resulting value is used as the initialization argument's value.

+The initialization arguments supplied to make-instance are combined with defaulted initialization arguments to produce a defaulted initialization argument list. A defaulted initialization argument list is a list of alternating initialization argument names and values in which unsupplied initialization arguments are defaulted and in which the explicitly supplied initialization arguments appear earlier in the list than the defaulted initialization arguments. Defaulted initialization arguments are ordered according to the order in the class precedence list of the classes that supplied the default values.

+There is a distinction between the purposes of the :default-initargs and the :initform options with respect to the initialization of slots. The :default-initargs class option provides a mechanism for the user to give a default value form for an initialization argument without knowing whether the initialization argument initializes a slot or is passed to a method. If that initialization argument is not explicitly supplied in a call to make-instance, the default value form is used, just as if it had been supplied in the call. In contrast, the :initform slot option provides a mechanism for the user to give a default initial value form for a slot. An :initform form is used to initialize a slot only if no initialization argument associated with that slot is given as an argument to make-instance or is defaulted by :default-initargs.

+ The order of evaluation of default value forms for initialization arguments and the order of evaluation of :initform forms are undefined. If the order of evaluation is important, initialize-instance or shared-initialize methods should be used instead.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ad.htm new file mode 100644 index 00000000..0c907122 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ad.htm @@ -0,0 +1,59 @@ + + + +CLHS: Section 7.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.4 Rules for Initialization Arguments

+The :initarg slot option may be specified more than once for a given slot.

+The following rules specify when initialization arguments may be multiply defined:

+

+

* A given initialization argument can be used to initialize more than one slot if the same initialization argument name appears in more than one :initarg slot option.

+
* A given initialization argument name can appear in the lambda list of more than one initialization method.

+
* A given initialization argument name can appear both in an :initarg slot option and in the lambda list of an initialization method.

+

+

+If two or more initialization arguments that initialize the same slot are given in the arguments to make-instance, the leftmost of these initialization arguments in the initialization argument list supplies the value, even if the initialization arguments have different names.

+If two or more different initialization arguments that initialize the same slot have default values and none is given explicitly in the arguments to make-instance, the initialization argument that appears in a :default-initargs class option in the most specific of the classes supplies the value. If a single :default-initargs class option specifies two or more initialization arguments that initialize the same slot and none is given explicitly in the arguments to make-instance, the leftmost in the :default-initargs class option supplies the value, and the values of the remaining default value forms are ignored.

+Initialization arguments given explicitly in the arguments to make-instance appear to the left of defaulted initialization arguments. Suppose that the classes C1 and C2 supply the values of defaulted initialization arguments for different slots, and suppose that C1 is more specific than C2; then the defaulted initialization argument whose value is supplied by C1 is to the left of the defaulted initialization argument whose value is supplied by C2 in the defaulted initialization argument list. If a single :default-initargs class option supplies the values of initialization arguments for two different slots, the initialization argument whose value is specified farther to the left in the :default-initargs class option appears farther to the left in the defaulted initialization argument list.

+

+If a slot has both an :initform form and an :initarg slot option, and the initialization argument is defaulted using :default-initargs or is supplied to make-instance, the captured :initform form is neither used nor evaluated.

+The following is an example of the above rules:

+

+ (defclass q () ((x :initarg a)))
+ (defclass r (q) ((x :initarg b))
+   (:default-initargs a 1 b 2))
+
+

+

+                              Defaulted                                         
+Form                          Initialization Argument List  Contents of Slot X  
+----------
+                                                                                
+(make-instance 'r)            (a 1 b 2)                     1                   
+(make-instance 'r 'a 3)       (a 3 b 2)                     3                   
+(make-instance 'r 'b 4)       (b 4 a 1)                     4                   
+(make-instance 'r 'a 1 'a 2)  (a 1 a 2 b 2)                 1                   
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ae.htm new file mode 100644 index 00000000..9b71f675 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ae.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 7.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.5 Shared-Initialize

+The generic function shared-initialize is used to fill the slots of an instance using initialization arguments and :initform forms when an instance is created, when an instance is re-initialized, when an instance is updated to conform to a redefined class, and when an instance is updated to conform to a different class. It uses standard method combination. It takes the following arguments: the instance to be initialized, a specification of a set of names of slots accessible in that instance, and any number of initialization arguments. The arguments after the first two must form an initialization argument list.

+The second argument to shared-initialize may be one of the following:

+

+

* It can be a (possibly empty) list of slot names, which specifies the set of those slot names.

+
* It can be the symbol t, which specifies the set of all of the slots.

+

+There is a system-supplied primary method for shared-initialize whose first parameter specializer is the class standard-object. This method behaves as follows on each slot, whether shared or local:

+

+

* If an initialization argument in the initialization argument list specifies a value for that slot, that value is stored into the slot, even if a value has already been stored in the slot before the method is run. The affected slots are independent of which slots are indicated by the second argument to shared-initialize.

+
* Any slots indicated by the second argument that are still unbound at this point are initialized according to their :initform forms. For any such slot that has an :initform form, that form is evaluated in the lexical environment of its defining defclass form and the result is stored into the slot. For example, if a before method stores a value in the slot, the :initform form will not be used to supply a value for the slot. If the second argument specifies a name that does not correspond to any slots accessible in the instance, the results are unspecified.

+
* The rules mentioned in Section 7.1.4 (Rules for Initialization Arguments) are obeyed.

+

+The generic function shared-initialize is called by the system-supplied primary methods for reinitialize-instance, update-instance-for-different-class, update-instance-for-redefined-class, and initialize-instance. Thus, methods can be written for shared-initialize to specify actions that should be taken in all of these contexts.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_af.htm new file mode 100644 index 00000000..92a67da0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_af.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 7.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.6 Initialize-Instance

+The generic function initialize-instance is called by make-instance to initialize a newly created instance. It uses standard method combination. Methods for initialize-instance can be defined in order to perform any initialization that cannot be achieved simply by supplying initial values for slots.

+ During initialization, initialize-instance is invoked after the following actions have been taken:

+

+

* The defaulted initialization argument list has been computed by combining the supplied initialization argument list with any default initialization arguments for the class.

+
* The validity of the defaulted initialization argument list has been checked. If any of the initialization arguments has not been declared as valid, an error is signaled.

+
* A new instance whose slots are unbound has been created.

+

+The generic function initialize-instance is called with the new instance and the defaulted initialization arguments. There is a system-supplied primary method for initialize-instance whose parameter specializer is the class standard-object. This method calls the generic function shared-initialize to fill in the slots according to the initialization arguments and the :initform forms for the slots; the generic function shared-initialize is called with the following arguments: the instance, t, and the defaulted initialization arguments.

+Note that initialize-instance provides the defaulted initialization argument list in its call to shared-initialize, so the first step performed by the system-supplied primary method for shared-initialize takes into account both the initialization arguments provided in the call to make-instance and the defaulted initialization argument list.

+Methods for initialize-instance can be defined to specify actions to be taken when an instance is initialized. If only after methods for initialize-instance are defined, they will be run after the system-supplied primary method for initialization and therefore will not interfere with the default behavior of initialize-instance.

+The object system provides two functions that are useful in the bodies of initialize-instance methods. The function slot-boundp returns a generic boolean value that indicates whether a specified slot has a value; this provides a mechanism for writing after methods for initialize-instance that initialize slots only if they have not already been initialized. The function slot-makunbound causes the slot to have no value.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ag.htm new file mode 100644 index 00000000..3af4788c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ag.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 7.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.1.7 Definitions of Make-Instance and Initialize-Instance

+The generic function make-instance behaves as if it were defined as follows, except that certain optimizations are permitted:

+

+ (defmethod make-instance ((class standard-class) &rest initargs)
+   ...
+   (let ((instance (apply #'allocate-instance class initargs)))
+     (apply #'initialize-instance instance initargs)
+     instance))
+
+ (defmethod make-instance ((class-name symbol) &rest initargs)
+   (apply #'make-instance (find-class class-name) initargs))
+
+

+ The elided code in the definition of make-instance augments the initargs with any defaulted initialization arguments and checks the resulting initialization arguments to determine whether an initialization argument was supplied that neither filled a slot nor supplied an argument to an applicable method.

+The generic function initialize-instance behaves as if it were defined as follows, except that certain optimizations are permitted:

+

+ (defmethod initialize-instance ((instance standard-object) &rest initargs)
+   (apply #'shared-initialize instance t initargs)))
+
+

+These procedures can be customized.

+Customizing at the Programmer Interface level includes using the :initform, :initarg, and :default-initargs options to defclass, as well as defining methods for make-instance, allocate-instance, and initialize-instance. It is also possible to define methods for shared-initialize, which would be invoked by the generic functions reinitialize-instance, update-instance-for-redefined-class, update-instance-for-different-class, and initialize-instance. The meta-object level supports additional customization.

+Implementations are permitted to make certain optimizations to initialize-instance and shared-initialize. The description of shared-initialize in Chapter 7 mentions the possible optimizations.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_b.htm new file mode 100644 index 00000000..37fc3f88 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_b.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 7.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.2 Changing the Class of an Instance

+The function change-class can be used to change the class of an instance from its current class, Cfrom, to a different class, Cto; it changes the structure of the instance to conform to the definition of the class Cto.

+Note that changing the class of an instance may cause slots to be added or deleted. Changing the class of an instance does not change its identity as defined by the eq function.

+When change-class is invoked on an instance, a two-step updating process takes place. The first step modifies the structure of the instance by adding new local slots and discarding local slots that are not specified in the new version of the instance. The second step initializes the newly added local slots and performs any other user-defined actions. These two steps are further described in the two following sections.

+ + +

+7.2.1 Modifying the Structure of the Instance

+ +

+7.2.2 Initializing Newly Added Local Slots

+ +

+7.2.3 Customizing the Change of Class of an Instance

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ba.htm new file mode 100644 index 00000000..0df4a0c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ba.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 7.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.2.1 Modifying the Structure of the Instance

+In order to make the instance conform to the class Cto, local slots specified by the class Cto that are not specified by the class Cfrom are added, and local slots not specified by the class Cto that are specified by the class Cfrom are discarded.

+The values of local slots specified by both the class Cto and the class Cfrom are retained. If such a local slot was unbound, it remains unbound.

+The values of slots specified as shared in the class Cfrom and as local in the class Cto are retained.

+This first step of the update does not affect the values of any shared slots.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bb.htm new file mode 100644 index 00000000..7dc1f06b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 7.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.2.2 Initializing Newly Added Local Slots

+The second step of the update initializes the newly added slots and performs any other user-defined actions. This step is implemented by the generic function update-instance-for-different-class. The generic function update-instance-for-different-class is invoked by change-class after the first step of the update has been completed.

+ The generic function update-instance-for-different-class is invoked on arguments computed by change-class. The first argument passed is a copy of the instance being updated and is an instance of the class Cfrom; this copy has dynamic extent within the generic function change-class. The second argument is the instance as updated so far by change-class and is an instance of the class Cto. The remaining arguments are an initialization argument list.

+

+There is a system-supplied primary method for update-instance-for-different-class that has two parameter specializers, each of which is the class standard-object. First this method checks the validity of initialization arguments and signals an error if an initialization argument is supplied that is not declared as valid. (For more information, see Section 7.1.2 (Declaring the Validity of Initialization Arguments).) Then it calls the generic function shared-initialize with the following arguments: the new instance, a list of names of the newly added slots, and the initialization arguments it received.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bc.htm new file mode 100644 index 00000000..aa3a5c80 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_bc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 7.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.2.3 Customizing the Change of Class of an Instance

+Methods for update-instance-for-different-class may be defined to specify actions to be taken when an instance is updated. If only after methods for update-instance-for-different-class are defined, they will be run after the system-supplied primary method for initialization and will not interfere with the default behavior of update-instance-for-different-class.

+Methods for shared-initialize may be defined to customize class redefinition. For more information, see Section 7.1.5 (Shared-Initialize).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_c.htm new file mode 100644 index 00000000..d1ef9d68 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_c.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 7.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.3 Reinitializing an Instance

+The generic function reinitialize-instance may be used to change the values of slots according to initialization arguments.

+The process of reinitialization changes the values of some slots and performs any user-defined actions. It does not modify the structure of an instance to add or delete slots, and it does not use any :initform forms to initialize slots.

+The generic function reinitialize-instance may be called directly. It takes one required argument, the instance. It also takes any number of initialization arguments to be used by methods for reinitialize-instance or for shared-initialize. The arguments after the required instance must form an initialization argument list.

+There is a system-supplied primary method for reinitialize-instance whose parameter specializer is the class standard-object. First this method checks the validity of initialization arguments and signals an error if an initialization argument is supplied that is not declared as valid. (For more information, see Section 7.1.2 (Declaring the Validity of Initialization Arguments).) Then it calls the generic function shared-initialize with the following arguments: the instance, nil, and the initialization arguments it received.

+ + +

+7.3.1 Customizing Reinitialization

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ca.htm new file mode 100644 index 00000000..ad8cea17 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ca.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 7.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.3.1 Customizing Reinitialization

+Methods for reinitialize-instance may be defined to specify actions to be taken when an instance is updated. If only after methods for reinitialize-instance are defined, they will be run after the system-supplied primary method for initialization and therefore will not interfere with the default behavior of reinitialize-instance.

+Methods for shared-initialize may be defined to customize class redefinition. For more information, see Section 7.1.5 (Shared-Initialize).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_d.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_d.htm new file mode 100644 index 00000000..30e2cc2d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_d.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 7.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.4 Meta-Objects

+The implementation of the object system manipulates classes, methods, and generic functions. The object system contains a set of generic functions defined by methods on classes; the behavior of those generic functions defines the behavior of the object system. The instances of the classes on which those methods are defined are called meta-objects.

+ + +

+7.4.1 Standard Meta-objects

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_da.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_da.htm new file mode 100644 index 00000000..c4dad1bb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_da.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 7.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.4.1 Standard Meta-objects

+The object system supplies a set of meta-objects, called standard meta-objects. These include the class standard-object and instances of the classes standard-method, standard-generic-function, and method-combination.

+

+

* The class standard-method is the default class of methods defined by the defmethod and defgeneric forms.

+
* The class standard-generic-function is the default class of generic functions defined by the forms defmethod, defgeneric, and defclass.

+
* The class named standard-object is an instance of the class standard-class and is a superclass of every class that is an instance of standard-class except itself and structure-class.

+
* Every method combination object is an instance of a subclass of class method-combination.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_e.htm new file mode 100644 index 00000000..36635eaa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_e.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 7.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.5 Slots

+ + +

+7.5.1 Introduction to Slots

+ +

+7.5.2 Accessing Slots

+ +

+7.5.3 Inheritance of Slots and Slot Options

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ea.htm new file mode 100644 index 00000000..631b2a4e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ea.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 7.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.5.1 Introduction to Slots

+An object of metaclass standard-class has zero or more named slots. The slots of an object are determined by the class of the object. Each slot can hold one value. The name of a slot is a symbol that is syntactically valid for use as a variable name.

+When a slot does not have a value, the slot is said to be unbound. When an unbound slot is read, the generic function slot-unbound is invoked. The system-supplied primary method for slot-unbound on class t signals an error. If slot-unbound returns, its primary value is used that time as the value of the slot.

+The default initial value form for a slot is defined by the :initform slot option. When the :initform form is used to supply a value, it is evaluated in the lexical environment in which the defclass form was evaluated. The :initform along with the lexical environment in which the defclass form was evaluated is called a captured initialization form. For more details, see Section 7.1 (Object Creation and Initialization).

+A local slot is defined to be a slot that is accessible to exactly one instance, namely the one in which the slot is allocated. A shared slot is defined to be a slot that is visible to more than one instance of a given class and its subclasses.

+A class is said to define a slot with a given name when the defclass form for that class contains a slot specifier with that name. Defining a local slot does not immediately create a slot; it causes a slot to be created each time an instance of the class is created. Defining a shared slot immediately creates a slot.

+The :allocation slot option to defclass controls the kind of slot that is defined. If the value of the :allocation slot option is :instance, a local slot is created. If the value of :allocation is :class, a shared slot is created.

+A slot is said to be accessible in an instance of a class if the slot is defined by the class of the instance or is inherited from a superclass of that class. At most one slot of a given name can be accessible in an instance. A shared slot defined by a class is accessible in all instances of that class. A detailed explanation of the inheritance of slots is given in Section 7.5.3 (Inheritance of Slots and Slot Options).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_eb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_eb.htm new file mode 100644 index 00000000..970fcd5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_eb.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 7.5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.5.2 Accessing Slots

+Slots can be accessed in two ways: by use of the primitive function slot-value and by use of generic functions generated by the defclass form.

+The function slot-value can be used with any of the slot names specified in the defclass form to access a specific slot accessible in an instance of the given class.

+The macro defclass provides syntax for generating methods to read and write slots. If a reader method is requested, a method is automatically generated for reading the value of the slot, but no method for storing a value into it is generated. If a writer method is requested, a method is automatically generated for storing a value into the slot, but no method for reading its value is generated. If an accessor method is requested, a method for reading the value of the slot and a method for storing a value into the slot are automatically generated. Reader and writer methods are implemented using slot-value.

+When a reader or writer method is specified for a slot, the name of the generic function to which the generated method belongs is directly specified. If the name specified for the writer method is the symbol name, the name of the generic function for writing the slot is the symbol name, and the generic function takes two arguments: the new value and the instance, in that order. If the name specified for the accessor method is the symbol name, the name of the generic function for reading the slot is the symbol name, and the name of the generic function for writing the slot is the list (setf name).

+A generic function created or modified by supplying :reader, :writer, or :accessor slot options can be treated exactly as an ordinary generic function.

+Note that slot-value can be used to read or write the value of a slot whether or not reader or writer methods exist for that slot. When slot-value is used, no reader or writer methods are invoked.

+The macro with-slots can be used to establish a lexical environment in which specified slots are lexically available as if they were variables. The macro with-slots invokes the function slot-value to access the specified slots.

+The macro with-accessors can be used to establish a lexical environment in which specified slots are lexically available through their accessors as if they were variables. The macro with-accessors invokes the appropriate accessors to access the specified slots.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ec.htm new file mode 100644 index 00000000..27a8bd65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ec.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 7.5.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.5.3 Inheritance of Slots and Slot Options

+The set of the names of all slots accessible in an instance of a class C is the union of the sets of names of slots defined by C and its superclasses. The structure of an instance is the set of names of local slots in that instance.

+In the simplest case, only one class among C and its superclasses defines a slot with a given slot name. If a slot is defined by a superclass of C, the slot is said to be inherited. The characteristics of the slot are determined by the slot specifier of the defining class. Consider the defining class for a slot S. If the value of the :allocation slot option is :instance, then S is a local slot and each instance of C has its own slot named S that stores its own value. If the value of the :allocation slot option is :class, then S is a shared slot, the class that defined S stores the value, and all instances of C can access that single slot. If the :allocation slot option is omitted, :instance is used.

+In general, more than one class among C and its superclasses can define a slot with a given name. In such cases, only one slot with the given name is accessible in an instance of C, and the characteristics of that slot are a combination of the several slot specifiers, computed as follows:

+

+

* All the slot specifiers for a given slot name are ordered from most specific to least specific, according to the order in C's class precedence list of the classes that define them. All references to the specificity of slot specifiers immediately below refers to this ordering.

+
* The allocation of a slot is controlled by the most specific slot specifier. If the most specific slot specifier does not contain an :allocation slot option, :instance is used. Less specific slot specifiers do not affect the allocation.

+
* The default initial value form for a slot is the value of the :initform slot option in the most specific slot specifier that contains one. If no slot specifier contains an :initform slot option, the slot has no default initial value form.

+
* The contents of a slot will always be of type (and T1 ... Tn) where T1 ...Tn are the values of the :type slot options contained in all of the slot specifiers. If no slot specifier contains the :type slot option, the contents of the slot will always be of type t. The consequences of attempting to store in a slot a value that does not satisfy the type of the slot are undefined.

+
* The set of initialization arguments that initialize a given slot is the union of the initialization arguments declared in the :initarg slot options in all the slot specifiers.

+
* The documentation string for a slot is the value of the :documentation slot option in the most specific slot specifier that contains one. If no slot specifier contains a :documentation slot option, the slot has no documentation string.

+

+A consequence of the allocation rule is that a shared slot can be shadowed. For example, if a class C1 defines a slot named S whose value for the :allocation slot option is :class, that slot is accessible in instances of C1 and all of its subclasses. However, if C2 is a subclass of C1 and also defines a slot named S, C1's slot is not shared by instances of C2 and its subclasses. When a class C1 defines a shared slot, any subclass C2 of C1 will share this single slot unless the defclass form for C2 specifies a slot of the same name or there is a superclass of C2 that precedes C1 in the class precedence list of C2 that defines a slot of the same name.

+A consequence of the type rule is that the value of a slot satisfies the type constraint of each slot specifier that contributes to that slot. Because the result of attempting to store in a slot a value that does not satisfy the type constraint for the slot is undefined, the value in a slot might fail to satisfy its type constraint.

+The :reader, :writer, and :accessor slot options create methods rather than define the characteristics of a slot. Reader and writer methods are inherited in the sense described in Section 7.6.7 (Inheritance of Methods).

+Methods that access slots use only the name of the slot and the type of the slot's value. Suppose a superclass provides a method that expects to access a shared slot of a given name, and a subclass defines a local slot with the same name. If the method provided by the superclass is used on an instance of the subclass, the method accesses the local slot.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_f.htm new file mode 100644 index 00000000..f999953d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_f.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 7.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6 Generic Functions and Methods

+ + +

+7.6.1 Introduction to Generic Functions

+ +

+7.6.2 Introduction to Methods

+ +

+7.6.3 Agreement on Parameter Specializers and Qualifiers

+ +

+7.6.4 Congruent Lambda-lists for all Methods of a Generic Function

+ + +

+7.6.5 Keyword Arguments in Generic Functions and Methods

+ +

+7.6.6 Method Selection and Combination

+ +

+7.6.7 Inheritance of Methods

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fa.htm new file mode 100644 index 00000000..82ac81a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fa.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 7.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.1 Introduction to Generic Functions

+A generic function is a function whose behavior depends on the classes or identities of the arguments supplied to it. A generic function object is associated with a set of methods, a lambda list, a method combination[2], and other information.

+Like an ordinary function, a generic function takes arguments, performs a series of operations, and perhaps returns useful values. An ordinary function has a single body of code that is always executed when the function is called. A generic function has a set of bodies of code of which a subset is selected for execution. The selected bodies of code and the manner of their combination are determined by the classes or identities of one or more of the arguments to the generic function and by its method combination.

+Ordinary functions and generic functions are called with identical syntax.

+Generic functions are true functions that can be passed as arguments and used as the first argument to funcall and apply.

+A binding of a function name to a generic function can be established in one of several ways. It can be established in the global environment by ensure-generic-function, defmethod (implicitly, due to ensure-generic-function) or defgeneric (also implicitly, due to ensure-generic-function). No standardized mechanism is provided for establishing a binding of a function name to a generic function in the lexical environment.

+

+

+When a defgeneric form is evaluated, one of three actions is taken (due to ensure-generic-function):

+

+

* If a generic function of the given name already exists, the existing generic function object is modified. Methods specified by the current defgeneric form are added, and any methods in the existing generic function that were defined by a previous defgeneric form are removed. Methods added by the current defgeneric form might replace methods defined by defmethod, defclass, define-condition, or defstruct. No other methods in the generic function are affected or replaced.

+
* If the given name names an ordinary function, a macro, or a special operator, an error is signaled.

+
* Otherwise a generic function is created with the methods specified by the method definitions in the defgeneric form.

+

+Some operators permit specification of the options of a generic function, such as the type of method combination it uses or its argument precedence order. These operators will be referred to as ``operators that specify generic function options.'' The only standardized operator in this category is defgeneric.

+Some operators define methods for a generic function. These operators will be referred to as method-defining operators; their associated forms are called method-defining forms. The standardized method-defining operators are listed in the next figure. 

+defgeneric        defmethod  defclass  
+define-condition  defstruct            
+
+

Figure 7-1. Standardized Method-Defining Operators Note that of the standardized method-defining operators only defgeneric can specify generic function options. defgeneric and any implementation-defined operators that can specify generic function options are also referred to as ``operators that specify generic function options.''

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fb.htm new file mode 100644 index 00000000..8edf2cda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fb.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 7.6.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.2 Introduction to Methods

+Methods define the class-specific or identity-specific behavior and operations of a generic function.

+A method object is associated with code that implements the method's behavior, a sequence of parameter specializers that specify when the given method is applicable, a lambda list, and a sequence of qualifiers that are used by the method combination facility to distinguish among methods.

+A method object is not a function and cannot be invoked as a function. Various mechanisms in the object system take a method object and invoke its method function, as is the case when a generic function is invoked. When this occurs it is said that the method is invoked or called.

+A method-defining form contains the code that is to be run when the arguments to the generic function cause the method that it defines to be invoked. When a method-defining form is evaluated, a method object is created and one of four actions is taken:

+

+

* If a generic function of the given name already exists and if a method object already exists that agrees with the new one on parameter specializers and qualifiers, the new method object replaces the old one. For a definition of one method agreeing with another on parameter specializers and qualifiers, see Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers).

+
* If a generic function of the given name already exists and if there is no method object that agrees with the new one on parameter specializers and qualifiers, the existing generic function object is modified to contain the new method object.

+
* If the given name names an ordinary function, a macro, or a special operator, an error is signaled.

+
* Otherwise a generic function is created with the method specified by the method-defining form.

+

+If the lambda list of a new method is not congruent with the lambda list of the generic function, an error is signaled. If a method-defining operator that cannot specify generic function options creates a new generic function, a lambda list for that generic function is derived from the lambda list of the method in the method-defining form in such a way as to be congruent with it. For a discussion of congruence, see Section 7.6.4 (Congruent Lambda-lists for all Methods of a Generic Function).

+Each method has a specialized lambda list, which determines when that method can be applied. A specialized lambda list is like an ordinary lambda list except that a specialized parameter may occur instead of the name of a required parameter. A specialized parameter is a list (variable-name parameter-specializer-name), where parameter-specializer-name is one of the following:

+

+

a symbol

+denotes a parameter specializer which is the class named by that symbol.

+

a class

+denotes a parameter specializer which is the class itself.

+

(eql form)

+denotes a parameter specializer which satisfies the type specifier (eql object), where object is the result of evaluating form. The form form is evaluated in the lexical environment in which the method-defining form is evaluated. Note that form is evaluated only once, at the time the method is defined, not each time the generic function is called.

+Parameter specializer names are used in macros intended as the user-level interface (defmethod), while parameter specializers are used in the functional interface.

+Only required parameters may be specialized, and there must be a parameter specializer for each required parameter. For notational simplicity, if some required parameter in a specialized lambda list in a method-defining form is simply a variable name, its parameter specializer defaults to the class t.

+Given a generic function and a set of arguments, an applicable method is a method for that generic function whose parameter specializers are satisfied by their corresponding arguments. The following definition specifies what it means for a method to be applicable and for an argument to satisfy a parameter specializer.

+Let <A1, ..., An> be the required arguments to a generic function in order. Let <P1, ..., Pn> be the parameter specializers corresponding to the required parameters of the method M in order. The method M is applicable when each Ai is of the type specified by the type specifier Pi. Because every valid parameter specializer is also a valid type specifier, the function typep can be used during method selection to determine whether an argument satisfies a parameter specializer.

+A method all of whose parameter specializers are the class t is called a default method; it is always applicable but may be shadowed by a more specific method.

+Methods can have qualifiers, which give the method combination procedure a way to distinguish among methods. A method that has one or more qualifiers is called a qualified method. A method with no qualifiers is called an unqualified method. A qualifier is any non-list. The qualifiers defined by the standardized method combination types are symbols.

+In this specification, the terms ``primary method'' and ``auxiliary method'' are used to partition methods within a method combination type according to their intended use. In standard method combination, primary methods are unqualified methods and auxiliary methods are methods with a single qualifier that is one of :around, :before, or :after. Methods with these qualifiers are called around methods, before methods, and after methods, respectively. When a method combination type is defined using the short form of define-method-combination, primary methods are methods qualified with the name of the type of method combination, and auxiliary methods have the qualifier :around. Thus the terms ``primary method'' and ``auxiliary method'' have only a relative definition within a given method combination type.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fc.htm new file mode 100644 index 00000000..d6286ba2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fc.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 7.6.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.3 Agreement on Parameter Specializers and Qualifiers

+Two methods are said to agree with each other on parameter specializers and qualifiers if the following conditions hold:

+

+

1. Both methods have the same number of required parameters. Suppose the parameter specializers of the two methods are P1,1...P1,n and P2,1...P2,n.

+
2. For each 1<=i<=n, P1,i agrees with P2,i. The parameter specializer P1,i agrees with P2,i if P1,i and P2,i are the same class or if P1,i=(eql object1), P2,i=(eql object2), and (eql object1 object2). Otherwise P1,i and P2,i do not agree.

+
3. The two lists of qualifiers are the same under equal.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fd.htm new file mode 100644 index 00000000..ac76c18b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fd.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 7.6.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.4 Congruent Lambda-lists for all Methods of a Generic Function

+These rules define the congruence of a set of lambda lists, including the lambda list of each method for a given generic function and the lambda list specified for the generic function itself, if given.

+

+

1. Each lambda list must have the same number of required parameters.

+
2. Each lambda list must have the same number of optional parameters. Each method can supply its own default for an optional parameter.

+
3. If any lambda list mentions &rest or &key, each lambda list must mention one or both of them.

+
4. If the generic function lambda list mentions &key, each method must accept all of the keyword names mentioned after &key, either by accepting them explicitly, by specifying &allow-other-keys, or by specifying &rest but not &key. Each method can accept additional keyword arguments of its own. The checking of the validity of keyword names is done in the generic function, not in each method. A method is invoked as if the keyword argument pair whose name is :allow-other-keys and whose value is true were supplied, though no such argument pair will be passed.

+
5. The use of &allow-other-keys need not be consistent across lambda lists. If &allow-other-keys is mentioned in the lambda list of any applicable method or of the generic function, any keyword arguments may be mentioned in the call to the generic function.

+
6. The use of &aux need not be consistent across methods.

+If a method-defining operator that cannot specify generic function options creates a generic function, and if the lambda list for the method mentions keyword arguments, the lambda list of the generic function will mention &key (but no keyword arguments).

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fe.htm new file mode 100644 index 00000000..d4872305 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fe.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 7.6.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.5 Keyword Arguments in Generic Functions and Methods

+When a generic function or any of its methods mentions &key in a lambda list, the specific set of keyword arguments accepted by the generic function varies according to the applicable methods. The set of keyword arguments accepted by the generic function for a particular call is the union of the keyword arguments accepted by all applicable methods and the keyword arguments mentioned after &key in the generic function definition, if any. A method that has &rest but not &key does not affect the set of acceptable keyword arguments. If the lambda list of any applicable method or of the generic function definition contains &allow-other-keys, all keyword arguments are accepted by the generic function.

+The lambda list congruence rules require that each method accept all of the keyword arguments mentioned after &key in the generic function definition, by accepting them explicitly, by specifying &allow-other-keys, or by specifying &rest but not &key. Each method can accept additional keyword arguments of its own, in addition to the keyword arguments mentioned in the generic function definition.

+If a generic function is passed a keyword argument that no applicable method accepts, an error should be signaled; see Section 3.5 (Error Checking in Function Calls).

+ + +

+7.6.5.1 Examples of Keyword Arguments in Generic Functions and Methods

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fea.htm new file mode 100644 index 00000000..4b89a99c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fea.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 7.6.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.5.1 Examples of Keyword Arguments in Generic Functions and Methods

+For example, suppose there are two methods defined for width as follows:

+

+ (defmethod width ((c character-class) &key font) ...)
+ 
+ (defmethod width ((p picture-class) &key pixel-size) ...)
+
+

+Assume that there are no other methods and no generic function definition for width. The evaluation of the following form should signal an error because the keyword argument :pixel-size is not accepted by the applicable method.

+

+ (width (make-instance `character-class :char #\Q) 
+        :font 'baskerville :pixel-size 10)
+
+

+The evaluation of the following form should signal an error.

+

+ (width (make-instance `picture-class :glyph (glyph #\Q)) 
+        :font 'baskerville :pixel-size 10)
+
+

+The evaluation of the following form will not signal an error if the class named character-picture-class is a subclass of both picture-class and character-class.

+

+ (width (make-instance `character-picture-class :char #\Q)
+        :font 'baskerville :pixel-size 10)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ff.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ff.htm new file mode 100644 index 00000000..49a1263e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ff.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 7.6.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6 Method Selection and Combination

+When a generic function is called with particular arguments, it must determine the code to execute. This code is called the effective method for those arguments. The effective method is a combination of the applicable methods in the generic function that calls some or all of the methods.

+ If a generic function is called and no methods are applicable, the generic function no-applicable-method is invoked, with the results from that call being used as the results of the call to the original generic function. Calling no-applicable-method takes precedence over checking for acceptable keyword arguments; see Section 7.6.5 (Keyword Arguments in Generic Functions and Methods).

+When the effective method has been determined, it is invoked with the same arguments as were passed to the generic function. Whatever values it returns are returned as the values of the generic function.

+ + +

+7.6.6.1 Determining the Effective Method

+ +

+7.6.6.2 Standard Method Combination

+ +

+7.6.6.3 Declarative Method Combination

+ +

+7.6.6.4 Built-in Method Combination Types

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffa.htm new file mode 100644 index 00000000..343f30a4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffa.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 7.6.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.1 Determining the Effective Method

+The effective method is determined by the following three-step procedure:

+

+

1. Select the applicable methods.

+
2. Sort the applicable methods by precedence order, putting the most specific method first.

+
3. Apply method combination to the sorted list of applicable methods, producing the effective method.

+

+ + +

+7.6.6.1.1 Selecting the Applicable Methods

+ +

+7.6.6.1.2 Sorting the Applicable Methods by Precedence Order

+ +

+7.6.6.1.3 Applying method combination to the sorted list of applicable methods

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffaa.htm new file mode 100644 index 00000000..9f12513a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 7.6.6.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.1.1 Selecting the Applicable Methods

+This step is described in Section 7.6.2 (Introduction to Methods).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffab.htm new file mode 100644 index 00000000..1f94713c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffab.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 7.6.6.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.1.2 Sorting the Applicable Methods by Precedence Order

+To compare the precedence of two methods, their parameter specializers are examined in order. The default examination order is from left to right, but an alternative order may be specified by the :argument-precedence-order option to defgeneric or to any of the other operators that specify generic function options.

+The corresponding parameter specializers from each method are compared. When a pair of parameter specializers agree, the next pair are compared for agreement. If all corresponding parameter specializers agree, the two methods must have different qualifiers; in this case, either method can be selected to precede the other. For information about agreement, see Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers).

+If some corresponding parameter specializers do not agree, the first pair of parameter specializers that do not agree determines the precedence. If both parameter specializers are classes, the more specific of the two methods is the method whose parameter specializer appears earlier in the class precedence list of the corresponding argument. Because of the way in which the set of applicable methods is chosen, the parameter specializers are guaranteed to be present in the class precedence list of the class of the argument.

+If just one of a pair of corresponding parameter specializers is (eql object), the method with that parameter specializer precedes the other method. If both parameter specializers are eql expressions, the specializers must agree (otherwise the two methods would not both have been applicable to this argument).

+The resulting list of applicable methods has the most specific method first and the least specific method last.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffac.htm new file mode 100644 index 00000000..cf7f6e98 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffac.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 7.6.6.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.1.3 Applying method combination to the sorted list of applicable methods

+In the simple case---if standard method combination is used and all applicable methods are primary methods---the effective method is the most specific method. That method can call the next most specific method by using the function call-next-method. The method that call-next-method will call is referred to as the next method. The predicate next-method-p tests whether a next method exists. If call-next-method is called and there is no next most specific method, the generic function no-next-method is invoked.

+In general, the effective method is some combination of the applicable methods. It is described by a form that contains calls to some or all of the applicable methods, returns the value or values that will be returned as the value or values of the generic function, and optionally makes some of the methods accessible by means of call-next-method.

+The role of each method in the effective method is determined by its qualifiers and the specificity of the method. A qualifier serves to mark a method, and the meaning of a qualifier is determined by the way that these marks are used by this step of the procedure. If an applicable method has an unrecognized qualifier, this step signals an error and does not include that method in the effective method.

+When standard method combination is used together with qualified methods, the effective method is produced as described in Section 7.6.6.2 (Standard Method Combination).

+Another type of method combination can be specified by using the :method-combination option of defgeneric or of any of the other operators that specify generic function options. In this way this step of the procedure can be customized.

+New types of method combination can be defined by using the define-method-combination macro.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffb.htm new file mode 100644 index 00000000..0fb4dc8a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffb.htm @@ -0,0 +1,48 @@ + + + +CLHS: Section 7.6.6.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.2 Standard Method Combination

+Standard method combination is supported by the class standard-generic-function. It is used if no other type of method combination is specified or if the built-in method combination type standard is specified.

+Primary methods define the main action of the effective method, while auxiliary methods modify that action in one of three ways. A primary method has no method qualifiers.

+An auxiliary method is a method whose qualifier is :before, :after, or :around. Standard method combination allows no more than one qualifier per method; if a method definition specifies more than one qualifier per method, an error is signaled.

+

+

* A before method has the keyword :before as its only qualifier. A before method specifies code that is to be run before any primary methods.

+
* An after method has the keyword :after as its only qualifier. An after method specifies code that is to be run after primary methods.

+
* An around method has the keyword :around as its only qualifier. An around method specifies code that is to be run instead of other applicable methods, but which might contain explicit code which calls some of those shadowed methods (via call-next-method).

+

+The semantics of standard method combination is as follows:

+

+

* If there are any around methods, the most specific around method is called. It supplies the value or values of the generic function.

+
* Inside the body of an around method, call-next-method can be used to call the next method. When the next method returns, the around method can execute more code, perhaps based on the returned value or values. The generic function no-next-method is invoked if call-next-method is used and there is no applicable method to call. The function next-method-p may be used to determine whether a next method exists.

+
* If an around method invokes call-next-method, the next most specific around method is called, if one is applicable. If there are no around methods or if call-next-method is called by the least specific around method, the other methods are called as follows:

-- All the before methods are called, in most-specific-first order. Their values are ignored. An error is signaled if call-next-method is used in a before method.

+
-- The most specific primary method is called. Inside the body of a primary method, call-next-method may be used to call the next most specific primary method. When that method returns, the previous primary method can execute more code, perhaps based on the returned value or values. The generic function no-next-method is invoked if call-next-method is used and there are no more applicable primary methods. The function next-method-p may be used to determine whether a next method exists. If call-next-method is not used, only the most specific primary method is called.

+
-- All the after methods are called in most-specific-last order. Their values are ignored. An error is signaled if call-next-method is used in an after method.

* If no around methods were invoked, the most specific primary method supplies the value or values returned by the generic function. The value or values returned by the invocation of call-next-method in the least specific around method are those returned by the most specific primary method.

+

+In standard method combination, if there is an applicable method but no applicable primary method, an error is signaled.

+The before methods are run in most-specific-first order while the after methods are run in least-specific-first order. The design rationale for this difference can be illustrated with an example. Suppose class C1 modifies the behavior of its superclass, C2, by adding before methods and after methods. Whether the behavior of the class C2 is defined directly by methods on C2 or is inherited from its superclasses does not affect the relative order of invocation of methods on instances of the class C1. Class C1's before method runs before all of class C2's methods. Class C1's after method runs after all of class C2's methods.

+By contrast, all around methods run before any other methods run. Thus a less specific around method runs before a more specific primary method.

+If only primary methods are used and if call-next-method is not used, only the most specific method is invoked; that is, more specific methods shadow more general ones.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffc.htm new file mode 100644 index 00000000..7083145a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 7.6.6.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.3 Declarative Method Combination

+The macro define-method-combination defines new forms of method combination. It provides a mechanism for customizing the production of the effective method. The default procedure for producing an effective method is described in Section 7.6.6.1 (Determining the Effective Method). There are two forms of define-method-combination. The short form is a simple facility while the long form is more powerful and more verbose. The long form resembles defmacro in that the body is an expression that computes a Lisp form; it provides mechanisms for implementing arbitrary control structures within method combination and for arbitrary processing of method qualifiers.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffd.htm new file mode 100644 index 00000000..9da27786 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_ffd.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 7.6.6.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.6.4 Built-in Method Combination Types

+The object system provides a set of built-in method combination types. To specify that a generic function is to use one of these method combination types, the name of the method combination type is given as the argument to the :method-combination option to defgeneric or to the :method-combination option to any of the other operators that specify generic function options.

+The names of the built-in method combination types are listed in the next figure.

+

++    append  max  nconc  progn     
+and  list    min  or     standard  
+
+

Figure 7-2. Built-in Method Combination Types

+The semantics of the standard built-in method combination type is described in Section 7.6.6.2 (Standard Method Combination). The other built-in method combination types are called simple built-in method combination types.

+The simple built-in method combination types act as though they were defined by the short form of define-method-combination. They recognize two roles for methods:

+

+

* An around method has the keyword symbol :around as its sole qualifier. The meaning of :around methods is the same as in standard method combination. Use of the functions call-next-method and next-method-p is supported in around methods.

+
* A primary method has the name of the method combination type as its sole qualifier. For example, the built-in method combination type and recognizes methods whose sole qualifier is and; these are primary methods. Use of the functions call-next-method and next-method-p is not supported in primary methods.

+

+The semantics of the simple built-in method combination types is as follows:

+

* If there are any around methods, the most specific around method is called. It supplies the value or values of the generic function.

+
* Inside the body of an around method, the function call-next-method can be used to call the next method. The generic function no-next-method is invoked if call-next-method is used and there is no applicable method to call. The function next-method-p may be used to determine whether a next method exists. When the next method returns, the around method can execute more code, perhaps based on the returned value or values.

+
* If an around method invokes call-next-method, the next most specific around method is called, if one is applicable. If there are no around methods or if call-next-method is called by the least specific around method, a Lisp form derived from the name of the built-in method combination type and from the list of applicable primary methods is evaluated to produce the value of the generic function. Suppose the name of the method combination type is operator and the call to the generic function is of the form

+

(generic-function a1...an)

+

Let M1,...,Mk be the applicable primary methods in order; then the derived Lisp form is

+

(operator <M1 a1...an>...<Mk a1...an>)

+

If the expression <Mi a1...an> is evaluated, the method Mi will be applied to the arguments a1...an. For example, if operator is or, the expression <Mi a1...an> is evaluated only if <Mj a1...an>, 1<=j<i, returned nil.

+
The default order for the primary methods is :most-specific-first. However, the order can be reversed by supplying :most-specific-last as the second argument to the :method-combination option.

+The simple built-in method combination types require exactly one qualifier per method. An error is signaled if there are applicable methods with no qualifiers or with qualifiers that are not supported by the method combination type. An error is signaled if there are applicable around methods and no applicable primary methods.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fg.htm new file mode 100644 index 00000000..2bd1708f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/07_fg.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 7.6.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.6.7 Inheritance of Methods

+A subclass inherits methods in the sense that any method applicable to all instances of a class is also applicable to all instances of any subclass of that class.

+The inheritance of methods acts the same way regardless of which of the method-defining operators created the methods.

+The inheritance of methods is described in detail in Section 7.6.6 (Method Selection and Combination).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/08_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/08_.htm new file mode 100644 index 00000000..c265626b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/08_.htm @@ -0,0 +1,36 @@ + + + +CLHS: Chapter 8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+8. Structures

+

+

+ +

+8.1 The Structures Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_.htm new file mode 100644 index 00000000..ae522394 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+9. Conditions

+

+ + +

+9.1 Condition System Concepts

+ +

+9.2 The Conditions Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_a.htm new file mode 100644 index 00000000..a078ed61 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_a.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section 9.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1 Condition System Concepts

+Common Lisp constructs are described not only in terms of their behavior in situations during which they are intended to be used (see the ``Description'' part of each operator specification), but in all other situations (see the ``Exceptional Situations'' part of each operator specification).

+A situation is the evaluation of an expression in a specific context. A condition is an object that represents a specific situation that has been detected. Conditions are generalized instances of the class condition. A hierarchy of condition classes is defined in Common Lisp. A condition has slots that contain data relevant to the situation that the condition represents.

+An error is a situation in which normal program execution cannot continue correctly without some form of intervention (either interactively by the user or under program control). Not all errors are detected. When an error goes undetected, the effects can be implementation-dependent, implementation-defined, unspecified, or undefined. See Section 1.4 (Definitions). All detected errors can be represented by conditions, but not all conditions represent errors.

+Signaling is the process by which a condition can alter the flow of control in a program by raising the condition which can then be handled. The functions error, cerror, signal, and warn are used to signal conditions.

+The process of signaling involves the selection and invocation of a handler from a set of active handlers. A handler is a function of one argument (the condition) that is invoked to handle a condition. Each handler is associated with a condition type, and a handler will be invoked only on a condition of the handler's associated type.

+Active handlers are established dynamically (see handler-bind or handler-case). Handlers are invoked in a dynamic environment equivalent to that of the signaler, except that the set of active handlers is bound in such a way as to include only those that were active at the time the handler being invoked was established. Signaling a condition has no side-effect on the condition, and there is no dynamic state contained in a condition.

+If a handler is invoked, it can address the situation in one of three ways:

+

Decline

+It can decline to handle the condition. It does this by simply returning rather than transferring control. When this happens, any values returned by the handler are ignored and the next most recently established handler is invoked. If there is no such handler and the signaling function is error or cerror, the debugger is entered in the dynamic environment of the signaler. If there is no such handler and the signaling function is either signal or warn, the signaling function simply returns nil.

+

Handle

+It can handle the condition by performing a non-local transfer of control. This can be done either primitively by using go, return, throw or more abstractly by using a function such as abort or invoke-restart.

+

Defer

+It can put off a decision about whether to handle or decline, by any of a number of actions, but most commonly by signaling another condition, resignaling the same condition, or forcing entry into the debugger.

+

+ + +

+9.1.1 Condition Types

+ +

+9.1.2 Creating Conditions

+ +

+9.1.3 Printing Conditions

+ +

+9.1.4 Signaling and Handling Conditions

+ +

+9.1.5 Assertions

+ + +

+9.1.6 Notes about the Condition System's Background

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aa.htm new file mode 100644 index 00000000..a4343947 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aa.htm @@ -0,0 +1,67 @@ + + + +CLHS: Section 9.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.1 Condition Types

+The next figure lists the standardized condition types. Additional condition types can be defined by using define-condition.

+ 

+arithmetic-error                  floating-point-overflow   simple-type-error   
+cell-error                        floating-point-underflow  simple-warning      
+condition                         package-error             storage-condition   
+control-error                     parse-error               stream-error        
+division-by-zero                  print-not-readable        style-warning       
+end-of-file                       program-error             type-error          
+error                             reader-error              unbound-slot        
+file-error                        serious-condition         unbound-variable    
+floating-point-inexact            simple-condition          undefined-function  
+floating-point-invalid-operation  simple-error              warning             
+
+

Figure 9-1. Standardized Condition Types

+All condition types are subtypes of type condition. That is,

+

+ (typep c 'condition) =>  true
+
+ if and only if c is a condition.

+Implementations must define all specified subtype relationships. Except where noted, all subtype relationships indicated in this document are not mutually exclusive. A condition inherits the structure of its supertypes.

+The metaclass of the class condition is not specified. Names of condition types may be used to specify supertype relationships in define-condition, but the consequences are not specified if an attempt is made to use a condition type as a superclass in a defclass form.

+The next figure shows operators that define condition types and creating conditions.

+

+define-condition  make-condition    
+
+

Figure 9-2. Operators that define and create conditions.

+The next figure shows operators that read the value of condition slots.

+ 

+arithmetic-error-operands   simple-condition-format-arguments  
+arithmetic-error-operation  simple-condition-format-control    
+cell-error-name             stream-error-stream                
+file-error-pathname         type-error-datum                   
+package-error-package       type-error-expected-type           
+print-not-readable-object   unbound-slot-instance              
+
+

Figure 9-3. Operators that read condition slots.

+ + +

+9.1.1.1 Serious Conditions

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aaa.htm new file mode 100644 index 00000000..b43cac71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 9.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.1.1 Serious Conditions

+A serious condition is a condition serious enough to require interactive intervention if not handled. Serious conditions are typically signaled with error or cerror; non-serious conditions are typically signaled with signal or warn.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ab.htm new file mode 100644 index 00000000..f98a1234 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ab.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 9.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.2 Creating Conditions

+The function make-condition can be used to construct a condition object explicitly. Functions such as error, cerror, signal, and warn operate on conditions and might create condition objects implicitly. Macros such as ccase, ctypecase, ecase, etypecase, check-type, and assert might also implicitly create (and signal) conditions.

+ + +

+9.1.2.1 Condition Designators

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aba.htm new file mode 100644 index 00000000..f62b358f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aba.htm @@ -0,0 +1,63 @@ + + + +CLHS: Section 9.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.2.1 Condition Designators

+A number of the functions in the condition system take arguments which are identified as condition designators. By convention, those arguments are notated as

+ datum &rest arguments

+Taken together, the datum and the arguments are ``designators for a condition of default type default-type.'' How the denoted condition is computed depends on the type of the datum:

+

+

* If the datum is a symbol naming a condition type ...

+The denoted condition is the result of

+

+ (apply #'make-condition datum arguments)
+
+

+

* If the datum is a format control ...

+The denoted condition is the result of

+ +

+ (make-condition defaulted-type 
+                 :format-control datum
+                 :format-arguments arguments)
+
+

+where the defaulted-type is a subtype of default-type.

+

* If the datum is a condition ...

+The denoted condition is the datum itself. In this case, unless otherwise specified by the description of the operator in question, the arguments must be null; that is, the consequences are undefined if any arguments were supplied.

+

+Note that the default-type gets used only in the case where the datum string is supplied. In the other situations, the resulting condition is not necessarily of type default-type.

+Here are some illustrations of how different condition designators can denote equivalent condition objects:

+ +

+(let ((c (make-condition 'arithmetic-error :operator '/ :operands '(7 0))))
+  (error c))
+==  (error 'arithmetic-error :operator '/ :operands '(7 0))
+
+(error "Bad luck.")
+==  (error 'simple-error :format-control "Bad luck." :format-arguments '())
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ac.htm new file mode 100644 index 00000000..a7b2bf98 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ac.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 9.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3 Printing Conditions

+If the :report argument to define-condition is used, a print function is defined that is called whenever the defined condition is printed while the value of *print-escape* is false. This function is called the condition reporter; the text which it outputs is called a report message.

+When a condition is printed and *print-escape* is false, the condition reporter for the condition is invoked. Conditions are printed automatically by functions such as invoke-debugger, break, and warn.

+When *print-escape* is true, the object should print in an abbreviated fashion according to the style of the implementation (e.g., by print-unreadable-object). It is not required that a condition can be recreated by reading its printed representation.

+No function is provided for directly accessing or invoking condition reporters.

+ + +

+9.1.3.1 Recommended Style in Condition Reporting

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aca.htm new file mode 100644 index 00000000..240d0216 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_aca.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 9.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3.1 Recommended Style in Condition Reporting

+In order to ensure a properly aesthetic result when presenting report messages to the user, certain stylistic conventions are recommended.

+There are stylistic recommendations for the content of the messages output by condition reporters, but there are no formal requirements on those programs. If a program violates the recommendations for some message, the display of that message might be less aesthetic than if the guideline had been observed, but the program is still considered a conforming program.

+The requirements on a program or implementation which invokes a condition reporter are somewhat stronger. A conforming program must be permitted to assume that if these style guidelines are followed, proper aesthetics will be maintained. Where appropriate, any specific requirements on such routines are explicitly mentioned below.

+ + +

+9.1.3.1.1 Capitalization and Punctuation in Condition Reports

+ +

+9.1.3.1.2 Leading and Trailing Newlines in Condition Reports

+ +

+9.1.3.1.3 Embedded Newlines in Condition Reports

+ +

+9.1.3.1.4 Note about Tabs in Condition Reports

+ +

+9.1.3.1.5 Mentioning Containing Function in Condition Reports

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acaa.htm new file mode 100644 index 00000000..1c5c528c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acaa.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 9.1.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3.1.1 Capitalization and Punctuation in Condition Reports

+It is recommended that a report message be a complete sentences, in the proper case and correctly punctuated. In English, for example, this means the first letter should be uppercase, and there should be a trailing period.

+

+ (error "This is a message")  ; Not recommended
+ (error "this is a message.") ; Not recommended
+
+ (error "This is a message.") ; Recommended instead
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acab.htm new file mode 100644 index 00000000..a0b21572 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acab.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 9.1.3.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3.1.2 Leading and Trailing Newlines in Condition Reports

+It is recommended that a report message not begin with any introductory text, such as ``Error: '' or ``Warning: '' or even just freshline or newline. Such text is added, if appropriate to the context, by the routine invoking the condition reporter.

+It is recommended that a report message not be followed by a trailing freshline or newline. Such text is added, if appropriate to the context, by the routine invoking the condition reporter.

+

+ (error "This is a message.~%")   ; Not recommended
+ (error "~&This is a message.")   ; Not recommended
+ (error "~&This is a message.~%") ; Not recommended
+
+ (error "This is a message.")     ; Recommended instead
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acac.htm new file mode 100644 index 00000000..eedd3d8b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acac.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 9.1.3.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3.1.3 Embedded Newlines in Condition Reports

+Especially if it is long, it is permissible and appropriate for a report message to contain one or more embedded newlines.

+If the calling routine conventionally inserts some additional prefix (such as ``Error: '' or ``;; Error: '') on the first line of the message, it must also assure that an appropriate prefix will be added to each subsequent line of the output, so that the left edge of the message output by the condition reporter will still be properly aligned.

+

+ (defun test ()
+   (error "This is an error message.~%It has two lines."))
+
+ ;; Implementation A
+ (test)
+ This is an error message.
+ It has two lines.
+
+ ;; Implementation B
+ (test)
+ ;; Error: This is an error message.
+ ;;        It has two lines.
+
+ ;; Implementation C
+ (test)
+ >> Error: This is an error message. 
+           It has two lines.
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acad.htm new file mode 100644 index 00000000..73008fd8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acad.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 9.1.3.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3.1.4 Note about Tabs in Condition Reports

+Because the indentation of a report message might be shifted to the right or left by an arbitrary amount, special care should be taken with the semi-standard character <Tab> (in those implementations that support such a character). Unless the implementation specifically defines its behavior in this context, its use should be avoided.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acae.htm new file mode 100644 index 00000000..a950fee1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_acae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 9.1.3.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.3.1.5 Mentioning Containing Function in Condition Reports

+The name of the containing function should generally not be mentioned in report messages. It is assumed that the debugger will make this information accessible in situations where it is necessary and appropriate.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ad.htm new file mode 100644 index 00000000..8cfbafa7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ad.htm @@ -0,0 +1,48 @@ + + + +CLHS: Section 9.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4 Signaling and Handling Conditions

+The operation of the condition system depends on the ordering of active applicable handlers from most recent to least recent.

+Each handler is associated with a type specifier that must designate a subtype of type condition. A handler is said to be applicable to a condition if that condition is of the type designated by the associated type specifier.

+Active handlers are established by using handler-bind (or an abstraction based on handler-bind, such as handler-case or ignore-errors).

+Active handlers can be established within the dynamic scope of other active handlers. At any point during program execution, there is a set of active handlers. When a condition is signaled, the most recent active applicable handler for that condition is selected from this set. Given a condition, the order of recentness of active applicable handlers is defined by the following two rules:

+

+

1. Each handler in a set of active handlers H1 is more recent than every handler in a set H2 if the handlers in H2 were active when the handlers in H1 were established.

+
2. Let h1 and h2 be two applicable active handlers established by the same form. Then h1 is more recent than h2 if h1 was defined to the left of h2 in the form that established them.

+

+Once a handler in a handler binding form (such as handler-bind or handler-case) has been selected, all handlers in that form become inactive for the remainder of the signaling process. While the selected handler runs, no other handler established by that form is active. That is, if the handler declines, no other handler established by that form will be considered for possible invocation.

+The next figure shows operators relating to the handling of conditions.

+

+handler-bind  handler-case  ignore-errors  
+
+

Figure 9-4. Operators relating to handling conditions.

+ + +

+9.1.4.1 Signaling

+ +

+9.1.4.2 Restarts

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ada.htm new file mode 100644 index 00000000..94c7332d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ada.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 9.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.1 Signaling

+When a condition is signaled, the most recent applicable active handler is invoked. Sometimes a handler will decline by simply returning without a transfer of control. In such cases, the next most recent applicable active handler is invoked.

+If there are no applicable handlers for a condition that has been signaled, or if all applicable handlers decline, the condition is unhandled.

+The functions cerror and error invoke the interactive condition handler (the debugger) rather than return if the condition being signaled, regardless of its type, is unhandled. In contrast, signal returns nil if the condition being signaled, regardless of its type, is unhandled.

+The variable *break-on-signals* can be used to cause the debugger to be entered before the signaling process begins.

+The next figure shows defined names relating to the signaling of conditions.

+

+*break-on-signals*  error   warn  
+cerror              signal        
+
+

Figure 9-5. Defined names relating to signaling conditions.

+ + +

+9.1.4.1.1 Resignaling a Condition

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adaa.htm new file mode 100644 index 00000000..2ae01f53 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adaa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 9.1.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.1.1 Resignaling a Condition

+ During the dynamic extent of the signaling process for a particular condition object, signaling the same condition object again is permitted if and only if the situation represented in both cases are the same.

+For example, a handler might legitimately signal the condition object that is its argument in order to allow outer handlers first opportunity to handle the condition. (Such a handlers is sometimes called a ``default handler.'') This action is permitted because the situation which the second signaling process is addressing is really the same situation.

+On the other hand, in an implementation that implemented asynchronous keyboard events by interrupting the user process with a call to signal, it would not be permissible for two distinct asynchronous keyboard events to signal identical condition objects at the same time for different situations.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adb.htm new file mode 100644 index 00000000..f0e9f91b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adb.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 9.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.2 Restarts

+The interactive condition handler returns only through non-local transfer of control to specially defined restarts that can be set up either by the system or by user code. Transferring control to a restart is called ``invoking'' the restart. Like handlers, active restarts are established dynamically, and only active restarts can be invoked. An active restart can be invoked by the user from the debugger or by a program by using invoke-restart.

+A restart contains a function to be called when the restart is invoked, an optional name that can be used to find or invoke the restart, and an optional set of interaction information for the debugger to use to enable the user to manually invoke a restart.

+The name of a restart is used by invoke-restart. Restarts that can be invoked only within the debugger do not need names.

+Restarts can be established by using restart-bind, restart-case, and with-simple-restart. A restart function can itself invoke any other restart that was active at the time of establishment of the restart of which the function is part.

+ The restarts established by a restart-bind form, a restart-case form, or a with-simple-restart form have dynamic extent which extends for the duration of that form's execution.

+Restarts of the same name can be ordered from least recent to most recent according to the following two rules:

+

+

1. Each restart in a set of active restarts R1 is more recent than every restart in a set R2 if the restarts in R2 were active when the restarts in R1 were established.

+
2. Let r1 and r2 be two active restarts with the same name established by the same form. Then r1 is more recent than r2 if r1 was defined to the left of r2 in the form that established them.

+

+If a restart is invoked but does not transfer control, the values resulting from the restart function are returned by the function that invoked the restart, either invoke-restart or invoke-restart-interactively.

+ + +

+9.1.4.2.1 Interactive Use of Restarts

+ +

+9.1.4.2.2 Interfaces to Restarts

+ +

+9.1.4.2.3 Restart Tests

+ +

+9.1.4.2.4 Associating a Restart with a Condition

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adba.htm new file mode 100644 index 00000000..15769771 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adba.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 9.1.4.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.2.1 Interactive Use of Restarts

+ For interactive handling, two pieces of information are needed from a restart: a report function and an interactive function.

+The report function is used by a program such as the debugger to present a description of the action the restart will take. The report function is specified and established by the :report-function keyword to restart-bind or the :report keyword to restart-case.

+The interactive function, which can be specified using the :interactive-function keyword to restart-bind or :interactive keyword to restart-case, is used when the restart is invoked interactively, such as from the debugger, to produce a suitable list of arguments.

+invoke-restart invokes the most recently established restart whose name is the same as the first argument to invoke-restart. If a restart is invoked interactively by the debugger and does not transfer control but rather returns values, the precise action of the debugger on those values is implementation-defined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbb.htm new file mode 100644 index 00000000..1c816973 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbb.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 9.1.4.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.2.2 Interfaces to Restarts

+Some restarts have functional interfaces, such as abort, continue, muffle-warning, store-value, and use-value. They are ordinary functions that use find-restart and invoke-restart internally, that have the same name as the restarts they manipulate, and that are provided simply for notational convenience.

+The next figure shows defined names relating to restarts.

+

+abort             invoke-restart-interactively  store-value          
+compute-restarts  muffle-warning                use-value            
+continue          restart-bind                  with-simple-restart  
+find-restart      restart-case                                       
+invoke-restart    restart-name                                       
+
+

Figure 9-6. Defined names relating to restarts.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbc.htm new file mode 100644 index 00000000..43e4e1f0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 9.1.4.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.2.3 Restart Tests

+

+Each restart has an associated test, which is a function of one argument (a condition or nil) which returns true if the restart should be visible in the current situation. This test is created by the :test-function option to restart-bind or the :test option to restart-case.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbd.htm new file mode 100644 index 00000000..7e007d31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_adbd.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 9.1.4.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.4.2.4 Associating a Restart with a Condition

+ A restart can be ``associated with'' a condition explicitly by with-condition-restarts, or implicitly by restart-case. Such an assocation has dynamic extent.

+A single restart may be associated with several conditions at the same time. A single condition may have several associated restarts at the same time.

+Active restarts associated with a particular condition can be detected by calling a function such as find-restart, supplying that condition as the condition argument. Active restarts can also be detected without regard to any associated condition by calling such a function without a condition argument, or by supplying a value of nil for such an argument.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ae.htm new file mode 100644 index 00000000..eb3ff76d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_ae.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 9.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.5 Assertions

+Conditional signaling of conditions based on such things as key match, form evaluation, and type are handled by assertion operators. The next figure shows operators relating to assertions.

+

+assert  check-type  ecase      
+ccase   ctypecase   etypecase  
+
+

Figure 9-7. Operators relating to assertions.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_af.htm new file mode 100644 index 00000000..815b8542 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/09_af.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 9.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.1.6 Notes about the Condition System's Background

+For a background reference to the abstract concepts detailed in this section, see Exceptional Situations in Lisp. The details of that paper are not binding on this document, but may be helpful in establishing a conceptual basis for understanding this material.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_.htm new file mode 100644 index 00000000..d1e1c044 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+10. Symbols

+

+ + +

+10.1 Symbol Concepts

+ +

+10.2 The Symbols Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_a.htm new file mode 100644 index 00000000..5e5fef5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/10_a.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 10.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+10.1 Symbol Concepts

+The next figure lists some defined names that are applicable to the property lists of symbols.

+

+get  remprop  symbol-plist  
+
+

Figure 10-1. Property list defined names

+The next figure lists some defined names that are applicable to the creation of and inquiry about symbols.

+

+copy-symbol  keywordp     symbol-package  
+gensym       make-symbol  symbol-value    
+gentemp      symbol-name                  
+
+

Figure 10-2. Symbol creation and inquiry defined names

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_.htm new file mode 100644 index 00000000..9011ced6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 11 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+11. Packages

+

+ + +

+11.1 Package Concepts

+ +

+11.2 The Packages Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_a.htm new file mode 100644 index 00000000..c3fdac54 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_a.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 11.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1 Package Concepts

+ + +

+11.1.1 Introduction to Packages

+ +

+11.1.2 Standardized Packages

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aa.htm new file mode 100644 index 00000000..3af4bb75 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aa.htm @@ -0,0 +1,48 @@ + + + +CLHS: Section 11.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1 Introduction to Packages

+A package establishes a mapping from names to symbols. At any given time, one package is current. The current package is the one that is the value of *package*. When using the Lisp reader, it is possible to refer to symbols in packages other than the current one through the use of package prefixes in the printed representation of the symbol.

+The next figure lists some defined names that are applicable to packages. Where an operator takes an argument that is either a symbol or a list of symbols, an argument of nil is treated as an empty list of symbols. Any package argument may be either a string, a symbol, or a package. If a symbol is supplied, its name will be used as the package name. 

+*modules*            import                     provide           
+*package*            in-package                 rename-package    
+defpackage           intern                     require           
+do-all-symbols       list-all-packages          shadow            
+do-external-symbols  make-package               shadowing-import  
+do-symbols           package-name               unexport          
+export               package-nicknames          unintern          
+find-all-symbols     package-shadowing-symbols  unuse-package     
+find-package         package-use-list           use-package       
+find-symbol          package-used-by-list                         
+
+

Figure 11-1. Some Defined Names related to Packages

+ + +

+11.1.1.1 Package Names and Nicknames

+ +

+11.1.1.2 Symbols in a Package

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaa.htm new file mode 100644 index 00000000..ff72c63d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 11.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.1 Package Names and Nicknames

+Each package has a name (a string) and perhaps some nicknames (also strings). These are assigned when the package is created and can be changed later.

+There is a single namespace for packages. The function find-package translates a package name or nickname into the associated package. The function package-name returns the name of a package. The function package-nicknames returns a list of all nicknames for a package. rename-package removes a package's current name and nicknames and replaces them with new ones specified by the caller.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aab.htm new file mode 100644 index 00000000..16370475 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aab.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 11.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.2 Symbols in a Package

+ + +

+11.1.1.2.1 Internal and External Symbols

+ +

+11.1.1.2.2 Package Inheritance

+ +

+11.1.1.2.3 Accessibility of Symbols in a Package

+ +

+11.1.1.2.4 Locating a Symbol in a Package

+ +

+11.1.1.2.5 Prevention of Name Conflicts in Packages

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaba.htm new file mode 100644 index 00000000..ae17e6a9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aaba.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 11.1.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.2.1 Internal and External Symbols

+The mappings in a package are divided into two classes, external and internal. The symbols targeted by these different mappings are called external symbols and internal symbols of the package. Within a package, a name refers to one symbol or to none; if it does refer to a symbol, then it is either external or internal in that package, but not both. External symbols are part of the package's public interface to other packages. Symbols become external symbols of a given package if they have been exported from that package.

+A symbol has the same name no matter what package it is present in, but it might be an external symbol of some packages and an internal symbol of others.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabb.htm new file mode 100644 index 00000000..72722ef6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 11.1.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.2.2 Package Inheritance

+Packages can be built up in layers. From one point of view, a package is a single collection of mappings from strings into internal symbols and external symbols. However, some of these mappings might be established within the package itself, while other mappings are inherited from other packages via use-package. A symbol is said to be present in a package if the mapping is in the package itself and is not inherited from somewhere else.

+There is no way to inherit the internal symbols of another package; to refer to an internal symbol using the Lisp reader, a package containing the symbol must be made to be the current package, a package prefix must be used, or the symbol must be imported into the current package.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabc.htm new file mode 100644 index 00000000..c42e8783 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabc.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 11.1.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.2.3 Accessibility of Symbols in a Package

+A symbol becomes accessible in a package if that is its home package when it is created, or if it is imported into that package, or by inheritance via use-package.

+If a symbol is accessible in a package, it can be referred to when using the Lisp reader without a package prefix when that package is the current package, regardless of whether it is present or inherited.

+Symbols from one package can be made accessible in another package in two ways.

+

-- Any individual symbol can be added to a package by use of import. After the call to import the symbol is present in the importing package. The status of the symbol in the package it came from (if any) is unchanged, and the home package for this symbol is unchanged. Once imported, a symbol is present in the importing package and can be removed only by calling unintern.

+A symbol is shadowed[3] by another symbol in some package if the first symbol would be accessible by inheritance if not for the presence of the second symbol. See shadowing-import.

+

-- The second mechanism for making symbols from one package accessible in another is provided by use-package. All of the external symbols of the used package are inherited by the using package. The function unuse-package undoes the effects of a previous use-package.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabd.htm new file mode 100644 index 00000000..31f5aa81 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 11.1.1.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.2.4 Locating a Symbol in a Package

+When a symbol is to be located in a given package the following occurs:

-- The external symbols and internal symbols of the package are searched for the symbol.
-- The external symbols of the used packages are searched in some unspecified order. The order does not matter; see the rules for handling name conflicts listed below.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabe.htm new file mode 100644 index 00000000..ef580bd0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aabe.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 11.1.1.2.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.1.2.5 Prevention of Name Conflicts in Packages

+Within one package, any particular name can refer to at most one symbol. A name conflict is said to occur when there would be more than one candidate symbol. Any time a name conflict is about to occur, a correctable error is signaled.

+The following rules apply to name conflicts:

-- Name conflicts are detected when they become possible, that is, when the package structure is altered. Name conflicts are not checked during every name lookup.

+
-- If the same symbol is accessible to a package through more than one path, there is no name conflict. A symbol cannot conflict with itself. Name conflicts occur only between distinct symbols with the same name (under string=).

+
-- Every package has a list of shadowing symbols. A shadowing symbol takes precedence over any other symbol of the same name that would otherwise be accessible in the package. A name conflict involving a shadowing symbol is always resolved in favor of the shadowing symbol, without signaling an error (except for one exception involving import). See shadow and shadowing-import.

+
-- The functions use-package, import, and export check for name conflicts.

+
-- shadow and shadowing-import never signal a name-conflict error.

+
-- unuse-package and unexport do not need to do any name-conflict checking. unintern does name-conflict checking only when a symbol being uninterned is a shadowing symbol.

+
-- Giving a shadowing symbol to unintern can uncover a name conflict that had previously been resolved by the shadowing.

+
-- Package functions signal name-conflict errors of type package-error before making any change to the package structure. When multiple changes are to be made, it is permissible for the implementation to process each change separately. For example, when export is given a list of symbols, aborting from a name conflict caused by the second symbol in the list might still export the first symbol in the list. However, a name-conflict error caused by export of a single symbol will be signaled before that symbol's accessibility in any package is changed.

+
-- Continuing from a name-conflict error must offer the user a chance to resolve the name conflict in favor of either of the candidates. The package structure should be altered to reflect the resolution of the name conflict, via shadowing-import, unintern, or unexport.

+
-- A name conflict in use-package between a symbol present in the using package and an external symbol of the used package is resolved in favor of the first symbol by making it a shadowing symbol, or in favor of the second symbol by uninterning the first symbol from the using package.

+
-- A name conflict in export or unintern due to a package's inheriting two distinct symbols with the same name (under string=) from two other packages can be resolved in favor of either symbol by importing it into the using package and making it a shadowing symbol, just as with use-package.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ab.htm new file mode 100644 index 00000000..743c2ca0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ab.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 11.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2 Standardized Packages

+This section describes the packages that are available in every conforming implementation. A summary of the names and nicknames of those standardized packages is given in the next figure.

+

+Name              Nicknames  
+COMMON-LISP       CL         
+COMMON-LISP-USER  CL-USER    
+KEYWORD           none       
+
+

Figure 11-2. Standardized Package Names

+

+

+ + +

+11.1.2.1 The COMMON-LISP Package

+ +

+11.1.2.2 The COMMON-LISP-USER Package

+ +

+11.1.2.3 The KEYWORD Package

+ +

+11.1.2.4 Implementation-Defined Packages

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aba.htm new file mode 100644 index 00000000..5dd6f862 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_aba.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 11.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.1 The COMMON-LISP Package

+

+The COMMON-LISP package contains the primitives of the Common Lisp system as defined by this specification. Its external symbols include all of the defined names (except for defined names in the KEYWORD package) that are present in the Common Lisp system, such as car, cdr, *package*, etc. The COMMON-LISP package has the nickname CL.

+ The COMMON-LISP package has as external symbols those symbols enumerated in the figures in Section 1.9 (Symbols in the COMMON-LISP Package), and no others. These external symbols are present in the COMMON-LISP package but their home package need not be the COMMON-LISP package.

+For example, the symbol HELP cannot be an external symbol of the COMMON-LISP package because it is not mentioned in Section 1.9 (Symbols in the COMMON-LISP Package). In contrast, the symbol variable must be an external symbol of the COMMON-LISP package even though it has no definition because it is listed in that section (to support its use as a valid second argument to the function documentation).

+The COMMON-LISP package can have additional internal symbols.

+ + +

+11.1.2.1.1 Constraints on the COMMON-LISP Package for Conforming Implementations

+ +

+11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abaa.htm new file mode 100644 index 00000000..c2accbc8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 11.1.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.1.1 Constraints on the COMMON-LISP Package for Conforming Implementations

+ In a conforming implementation, an external symbol of the COMMON-LISP package can have a function, macro, or special operator definition, a global variable definition (or other status as a dynamic variable due to a special proclamation), or a type definition only if explicitly permitted in this standard. For example, fboundp yields false for any external symbol of the COMMON-LISP package that is not the name of a standardized function, macro or special operator, and boundp returns false for any external symbol of the COMMON-LISP package that is not the name of a standardized global variable. It also follows that conforming programs can use external symbols of the COMMON-LISP package as the names of local lexical variables with confidence that those names have not been proclaimed special by the implementation unless those symbols are names of standardized global variables.

+A conforming implementation must not place any property on an external symbol of the COMMON-LISP package using a property indicator that is either an external symbol of any standardized package or a symbol that is otherwise accessible in the COMMON-LISP-USER package.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abab.htm new file mode 100644 index 00000000..2d2f59d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abab.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 11.1.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs

Except where explicitly allowed, the consequences are undefined if any of the following actions are performed on an external symbol of the COMMON-LISP package:

+

+

1. Binding or altering its value (lexically or dynamically). (Some exceptions are noted below.)

+
2. Defining, undefining, or binding it as a function. (Some exceptions are noted below.)

+
3. Defining, undefining, or binding it as a macro or compiler macro. (Some exceptions are noted below.)

+
4. Defining it as a type specifier (via defstruct, defclass, deftype, define-condition).

+
5. Defining it as a structure (via defstruct).

+
6. Defining it as a declaration with a declaration proclamation.

+
7. Defining it as a symbol macro.

+
8. Altering its home package.

+
9. Tracing it (via trace).

+
10. Declaring or proclaiming it special (via declare, declaim, or proclaim).

+
11. Declaring or proclaiming its type or ftype (via declare, declaim, or proclaim). (Some exceptions are noted below.)

+
12. Removing it from the COMMON-LISP package.

+

+

13. Defining a setf expander for it (via defsetf or define-setf-method).

+
14. Defining, undefining, or binding its setf function name.

+
15. Defining it as a method combination type (via define-method-combination).

+
16. Using it as the class-name argument to setf of find-class.

+
17. Binding it as a catch tag.

+
18. Binding it as a restart name.

+
19. Defining a method for a standardized generic function which is applicable when all of the arguments are direct instances of standardized classes.

+

+

+ + +

+11.1.2.1.2.1 Some Exceptions to Constraints on the COMMON-LISP Package for Conforming Programs

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ababa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ababa.htm new file mode 100644 index 00000000..54da275c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_ababa.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 11.1.2.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.1.2.1 Some Exceptions to Constraints on the COMMON-LISP Package for Conforming Programs

+If an external symbol of the COMMON-LISP package is not globally defined as a standardized dynamic variable or constant variable, it is allowed to lexically bind it and to declare the type of that binding, and it is allowed to locally establish it as a symbol macro (e.g., with symbol-macrolet).

+Unless explicitly specified otherwise, if an external symbol of the COMMON-LISP package is globally defined as a standardized dynamic variable, it is permitted to bind or assign that dynamic variable provided that the ``Value Type'' constraints on the dynamic variable are maintained, and that the new value of the variable is consistent with the stated purpose of the variable.

+If an external symbol of the COMMON-LISP package is not defined as a standardized function, macro, or special operator, it is allowed to lexically bind it as a function (e.g., with flet), to declare the ftype of that binding, and (in implementations which provide the ability to do so) to trace that binding.

+If an external symbol of the COMMON-LISP package is not defined as a standardized function, macro, or special operator, it is allowed to lexically bind it as a macro (e.g., with macrolet).

+

+ If an external symbol of the COMMON-LISP package is not defined as a standardized function, macro, or special operator, it is allowed to lexically bind its setf function name as a function, and to declare the ftype of that binding.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abb.htm new file mode 100644 index 00000000..443aaf81 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 11.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.2 The COMMON-LISP-USER Package

+The COMMON-LISP-USER package is the current package when a Common Lisp system starts up. This package uses the COMMON-LISP package. The COMMON-LISP-USER package has the nickname CL-USER. The COMMON-LISP-USER package can have additional symbols interned within it; it can use other implementation-defined packages.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abc.htm new file mode 100644 index 00000000..783d57c3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abc.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 11.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.3 The KEYWORD Package

+The KEYWORD package contains symbols, called keywords[1], that are typically used as special markers in programs and their associated data expressions[1].

+Symbol tokens that start with a package marker are parsed by the Lisp reader as symbols in the KEYWORD package; see Section 2.3.4 (Symbols as Tokens). This makes it notationally convenient to use keywords when communicating between programs in different packages. For example, the mechanism for passing keyword parameters in a call uses keywords[1] to name the corresponding arguments; see Section 3.4.1 (Ordinary Lambda Lists).

+Symbols in the KEYWORD package are, by definition, of type keyword.

+ + +

+11.1.2.3.1 Interning a Symbol in the KEYWORD Package

+ +

+11.1.2.3.2 Notes about The KEYWORD Package

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abca.htm new file mode 100644 index 00000000..0ed1fed4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abca.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 11.1.2.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.3.1 Interning a Symbol in the KEYWORD Package

+The KEYWORD package is treated differently than other packages in that special actions are taken when a symbol is interned in it. In particular, when a symbol is interned in the KEYWORD package, it is automatically made to be an external symbol and is automatically made to be a constant variable with itself as a value.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abcb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abcb.htm new file mode 100644 index 00000000..c1aa0b4a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abcb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 11.1.2.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.3.2 Notes about The KEYWORD Package

+It is generally best to confine the use of keywords to situations in which there are a finitely enumerable set of names to be selected between. For example, if there were two states of a light switch, they might be called :on and :off.

+In situations where the set of names is not finitely enumerable (i.e., where name conflicts might arise) it is frequently best to use symbols in some package other than KEYWORD so that conflicts will be naturally avoided. For example, it is generally not wise for a program to use a keyword[1] as a property indicator, since if there were ever another program that did the same thing, each would clobber the other's data.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abd.htm new file mode 100644 index 00000000..a2327e0e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/11_abd.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 11.1.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.1.2.4 Implementation-Defined Packages

+ Other, implementation-defined packages might be present in the initial Common Lisp environment.

+It is recommended, but not required, that the documentation for a conforming implementation contain a full list of all package names initially present in that implementation but not specified in this specification. (See also the function list-all-packages.)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_.htm new file mode 100644 index 00000000..29013af5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 12 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+12. Numbers

+

+ + +

+12.1 Number Concepts

+ +

+12.2 The Numbers Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_a.htm new file mode 100644 index 00000000..590c5ae5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_a.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 12.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1 Number Concepts

+ + +

+12.1.1 Numeric Operations

+ +

+12.1.2 Implementation-Dependent Numeric Constants

+ +

+12.1.3 Rational Computations

+ +

+12.1.4 Floating-point Computations

+ +

+12.1.5 Complex Computations

+ +

+12.1.6 Interval Designators

+ +

+12.1.7 Random-State Operations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aa.htm new file mode 100644 index 00000000..1f25e29d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aa.htm @@ -0,0 +1,80 @@ + + + +CLHS: Section 12.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1 Numeric Operations

+Common Lisp provides a large variety of operations related to numbers. This section provides an overview of those operations by grouping them into categories that emphasize some of the relationships among them.

+The next figure shows operators relating to arithmetic operations.

+

+*  1+         gcd   
++  1-         incf  
+-  conjugate  lcm   
+/  decf             
+
+

Figure 12-1. Operators relating to Arithmetic.

+The next figure shows defined names relating to exponential, logarithmic, and trigonometric operations.

+

+abs    cos    signum  
+acos   cosh   sin     
+acosh  exp    sinh    
+asin   expt   sqrt    
+asinh  isqrt  tan     
+atan   log    tanh    
+atanh  phase          
+cis    pi             
+
+

Figure 12-2. Defined names relating to Exponentials, Logarithms, and Trigonometry.

+The next figure shows operators relating to numeric comparison and predication.

+

+/=  >=      oddp   
+<   evenp   plusp  
+<=  max     zerop  
+=   min            
+>   minusp         
+
+

Figure 12-3. Operators for numeric comparison and predication.

+The next figure shows defined names relating to numeric type manipulation and coercion.

+

+ceiling          float-radix           rational     
+complex          float-sign            rationalize  
+decode-float     floor                 realpart     
+denominator      fround                rem          
+fceiling         ftruncate             round        
+ffloor           imagpart              scale-float  
+float            integer-decode-float  truncate     
+float-digits     mod                                
+float-precision  numerator                          
+
+

Figure 12-4. Defined names relating to numeric type manipulation and coercion.

+ + +

+12.1.1.1 Associativity and Commutativity in Numeric Operations

+ +

+12.1.1.2 Contagion in Numeric Operations

+ +

+12.1.1.3 Viewing Integers as Bits and Bytes

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaa.htm new file mode 100644 index 00000000..58d78054 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaa.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 12.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1.1 Associativity and Commutativity in Numeric Operations

+For functions that are mathematically associative (and possibly commutative), a conforming implementation may process the arguments in any manner consistent with associative (and possibly commutative) rearrangement. This does not affect the order in which the argument forms are evaluated; for a discussion of evaluation order, see Section 3.1.2.1.2.3 (Function Forms). What is unspecified is only the order in which the parameter values are processed. This implies that implementations may differ in which automatic coercions are applied; see Section 12.1.1.2 (Contagion in Numeric Operations).

+A conforming program can control the order of processing explicitly by separating the operations into separate (possibly nested) function forms, or by writing explicit calls to functions that perform coercions.

+ + +

+12.1.1.1.1 Examples of Associativity and Commutativity in Numeric Operations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaaa.htm new file mode 100644 index 00000000..cd39f37c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaaa.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 12.1.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1.1.1 Examples of Associativity and Commutativity in Numeric Operations

+Consider the following expression, in which we assume that 1.0 and 1.0e-15 both denote single floats:

+

+ (+ 1/3 2/3 1.0d0 1.0 1.0e-15)
+
+

+One conforming implementation might process the arguments from left to right, first adding 1/3 and 2/3 to get 1, then converting that to a double float for combination with 1.0d0, then successively converting and adding 1.0 and 1.0e-15.

+Another conforming implementation might process the arguments from right to left, first performing a single float addition of 1.0 and 1.0e-15 (perhaps losing accuracy in the process), then converting the sum to a double float and adding 1.0d0, then converting 2/3 to a double float and adding it, and then converting 1/3 and adding that.

+A third conforming implementation might first scan all the arguments, process all the rationals first to keep that part of the computation exact, then find an argument of the largest floating-point format among all the arguments and add that, and then add in all other arguments, converting each in turn (all in a perhaps misguided attempt to make the computation as accurate as possible).

+In any case, all three strategies are legitimate.

+A conforming program could control the order by writing, for example,

+

+ (+ (+ 1/3 2/3) (+ 1.0d0 1.0e-15) 1.0)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aab.htm new file mode 100644 index 00000000..d92f1298 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 12.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1.2 Contagion in Numeric Operations

+For information about the contagion rules for implicit coercions of arguments in numeric operations, see Section 12.1.4.4 (Rule of Float Precision Contagion), Section 12.1.4.1 (Rule of Float and Rational Contagion), and Section 12.1.5.2 (Rule of Complex Contagion).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aac.htm new file mode 100644 index 00000000..1bc039d1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aac.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 12.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1.3 Viewing Integers as Bits and Bytes

+ + +

+12.1.1.3.1 Logical Operations on Integers

+ +

+12.1.1.3.2 Byte Operations on Integers

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaca.htm new file mode 100644 index 00000000..60b900ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aaca.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 12.1.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1.3.1 Logical Operations on Integers

+Logical operations require integers as arguments; an error of type type-error should be signaled if an argument is supplied that is not an integer. Integer arguments to logical operations are treated as if they were represented in two's-complement notation.

+The next figure shows defined names relating to logical operations on numbers.

+

+ash          boole-ior       logbitp   
+boole        boole-nand      logcount  
+boole-1      boole-nor       logeqv    
+boole-2      boole-orc1      logior    
+boole-and    boole-orc2      lognand   
+boole-andc1  boole-set       lognor    
+boole-andc2  boole-xor       lognot    
+boole-c1     integer-length  logorc1   
+boole-c2     logand          logorc2   
+boole-clr    logandc1        logtest   
+boole-eqv    logandc2        logxor    
+
+

Figure 12-5. Defined names relating to logical operations on numbers.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aacb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aacb.htm new file mode 100644 index 00000000..a719da7b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aacb.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 12.1.1.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.1.3.2 Byte Operations on Integers

+The byte-manipulation functions use objects called byte specifiers to designate the size and position of a specific byte within an integer. The representation of a byte specifier is implementation-dependent; it might or might not be a number. The function byte will construct a byte specifier, which various other byte-manipulation functions will accept.

+The next figure shows defined names relating to manipulating bytes of numbers.

+

+byte           deposit-field  ldb-test    
+byte-position  dpb            mask-field  
+byte-size      ldb                        
+
+

Figure 12-6. Defined names relating to byte manipulation.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ab.htm new file mode 100644 index 00000000..f8cf7a68 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ab.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 12.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.2 Implementation-Dependent Numeric Constants

+The next figure shows defined names relating to implementation-dependent details about numbers.

+

+double-float-epsilon           most-negative-fixnum           
+double-float-negative-epsilon  most-negative-long-float       
+least-negative-double-float    most-negative-short-float      
+least-negative-long-float      most-negative-single-float     
+least-negative-short-float     most-positive-double-float     
+least-negative-single-float    most-positive-fixnum           
+least-positive-double-float    most-positive-long-float       
+least-positive-long-float      most-positive-short-float      
+least-positive-short-float     most-positive-single-float     
+least-positive-single-float    short-float-epsilon            
+long-float-epsilon             short-float-negative-epsilon   
+long-float-negative-epsilon    single-float-epsilon           
+most-negative-double-float     single-float-negative-epsilon  
+
+

Figure 12-7. Defined names relating to implementation-dependent details about numbers.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ac.htm new file mode 100644 index 00000000..1fdc8407 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ac.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 12.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.3 Rational Computations

+The rules in this section apply to rational computations.

+ + +

+12.1.3.1 Rule of Unbounded Rational Precision

+ +

+12.1.3.2 Rule of Canonical Representation for Rationals

+ +

+12.1.3.3 Rule of Float Substitutability

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aca.htm new file mode 100644 index 00000000..3dde1bb7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aca.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 12.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.3.1 Rule of Unbounded Rational Precision

+Rational computations cannot overflow in the usual sense (though there may not be enough storage to represent a result), since integers and ratios may in principle be of any magnitude.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acb.htm new file mode 100644 index 00000000..9d1f3860 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acb.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 12.1.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.3.2 Rule of Canonical Representation for Rationals

+If any computation produces a result that is a mathematical ratio of two integers such that the denominator evenly divides the numerator, then the result is converted to the equivalent integer.

+If the denominator does not evenly divide the numerator, the canonical representation of a rational number is as the ratio that numerator and that denominator, where the greatest common divisor of the numerator and denominator is one, and where the denominator is positive and greater than one.

+When used as input (in the default syntax), the notation -0 always denotes the integer 0. A conforming implementation must not have a representation of ``minus zero'' for integers that is distinct from its representation of zero for integers. However, such a distinction is possible for floats; see the type float.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acc.htm new file mode 100644 index 00000000..8b98f5cd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_acc.htm @@ -0,0 +1,57 @@ + + + +CLHS: Section 12.1.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.3.3 Rule of Float Substitutability

+When the arguments to an irrational mathematical function are all rational and the true mathematical result is also (mathematically) rational, then unless otherwise noted an implementation is free to return either an accurate rational result or a single float approximation. If the arguments are all rational but the result cannot be expressed as a rational number, then a single float approximation is always returned.

+ If the arguments to an irrational mathematical function are all of type (or rational (complex rational)) and the true mathematical result is (mathematically) a complex number with rational real and imaginary parts, then unless otherwise noted an implementation is free to return either an accurate result of type (or rational (complex rational)) or a single float (permissible only if the imaginary part of the true mathematical result is zero) or (complex single-float). If the arguments are all of type (or rational (complex rational)) but the result cannot be expressed as a rational or complex rational, then the returned value will be of type single-float (permissible only if the imaginary part of the true mathematical result is zero) or (complex single-float).

+Float substitutability applies neither to the rational functions +, -, *, and / nor to the related operators 1+, 1-, incf, decf, and conjugate. For rational functions, if all arguments are rational, then the result is rational; if all arguments are of type (or rational (complex rational)), then the result is of type (or rational (complex rational)).

+

+Function  Sample Results                                   
+abs       (abs #c(3 4)) =>  5 or 5.0                       
+acos      (acos 1) =>  0 or 0.0                            
+acosh     (acosh 1) =>  0 or 0.0                           
+asin      (asin 0) =>  0 or 0.0                            
+asinh     (asinh 0) =>  0 or 0.0                           
+atan      (atan 0) =>  0 or 0.0                            
+atanh     (atanh 0) =>  0 or 0.0                           
+cis       (cis 0) =>  1 or #c(1.0 0.0)                     
+cos       (cos 0) =>  1 or 1.0                             
+cosh      (cosh 0) =>  1 or 1.0                            
+exp       (exp 0) =>  1 or 1.0                             
+expt      (expt 8 1/3) =>  2 or 2.0                        
+log       (log 1) =>  0 or 0.0                             
+          (log 8 2) =>  3 or 3.0                           
+phase     (phase 7) =>  0 or 0.0                           
+signum    (signum #c(3 4)) =>  #c(3/5 4/5) or #c(0.6 0.8)  
+sin       (sin 0) =>  0 or 0.0                             
+sinh      (sinh 0) =>  0 or 0.0                            
+sqrt      (sqrt 4) =>  2 or 2.0                            
+          (sqrt 9/16) =>  3/4 or 0.75                      
+tan       (tan 0) =>  0 or 0.0                             
+tanh      (tanh 0) =>  0 or 0.0                            
+
+

Figure 12-8. Functions Affected by Rule of Float Substitutability

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ad.htm new file mode 100644 index 00000000..d69c4017 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ad.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 12.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.4 Floating-point Computations

+The following rules apply to floating point computations.

+ + +

+12.1.4.1 Rule of Float and Rational Contagion

+ +

+12.1.4.2 Rule of Float Approximation

+ +

+12.1.4.3 Rule of Float Underflow and Overflow

+ +

+12.1.4.4 Rule of Float Precision Contagion

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ada.htm new file mode 100644 index 00000000..8e2a1970 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ada.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 12.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.4.1 Rule of Float and Rational Contagion

+When rationals and floats are combined by a numerical function, the rational is first converted to a float of the same format. For functions such as + that take more than two arguments, it is permitted that part of the operation be carried out exactly using rationals and the rest be done using floating-point arithmetic.

+When rationals and floats are compared by a numerical function, the function rational is effectively called to convert the float to a rational and then an exact comparison is performed. In the case of complex numbers, the real and imaginary parts are effectively handled individually.

+ + +

+12.1.4.1.1 Examples of Rule of Float and Rational Contagion

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adaa.htm new file mode 100644 index 00000000..7aaacfd6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adaa.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 12.1.4.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.4.1.1 Examples of Rule of Float and Rational Contagion

+

+ ;;;; Combining rationals with floats.
+ ;;; This example assumes an implementation in which 
+ ;;; (float-radix 0.5) is 2 (as in IEEE) or 16 (as in IBM/360),
+ ;;; or else some other implementation in which 1/2 has an exact 
+ ;;;  representation in floating point.
+ (+ 1/2 0.5) =>  1.0
+ (- 1/2 0.5d0) =>  0.0d0
+ (+ 0.5 -0.5 1/2) =>  0.5
+
+ ;;;; Comparing rationals with floats.
+ ;;; This example assumes an implementation in which the default float 
+ ;;; format is IEEE single-float, IEEE double-float, or some other format
+ ;;; in which 5/7 is rounded upwards by FLOAT.
+ (< 5/7 (float 5/7)) =>  true
+ (< 5/7 (rational (float 5/7))) =>  true
+ (< (float 5/7) (float 5/7)) =>  false
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adb.htm new file mode 100644 index 00000000..afefe03e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adb.htm @@ -0,0 +1,27 @@ + + + +CLHS: Section 12.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.4.2 Rule of Float Approximation

Computations with floats are only approximate, although they are described as if the results were mathematically accurate. Two mathematically identical expressions may be computationally different because of errors inherent in the floating-point approximation process. The precision of a float is not necessarily correlated with the accuracy of that number. For instance, 3.142857142857142857 is a more precise approximation to <PI> than 3.14159, but the latter is more accurate. The precision refers to the number of bits retained in the representation. When an operation combines a short float with a long float, the result will be a long float. Common Lisp functions assume that the accuracy of arguments to them does not exceed their precision. Therefore when two small floats are combined, the result is a small float. Common Lisp functions never convert automatically from a larger size to a smaller one.
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adc.htm new file mode 100644 index 00000000..1f8bf660 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_adc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 12.1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.4.3 Rule of Float Underflow and Overflow

+An error of type floating-point-overflow or floating-point-underflow should be signaled if a floating-point computation causes exponent overflow or underflow, respectively.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_add.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_add.htm new file mode 100644 index 00000000..a9dfc6ee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_add.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 12.1.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.4.4 Rule of Float Precision Contagion

+The result of a numerical function is a float of the largest format among all the floating-point arguments to the function.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ae.htm new file mode 100644 index 00000000..0c042a3a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ae.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 12.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.5 Complex Computations

+The following rules apply to complex computations:

+ + +

+12.1.5.1 Rule of Complex Substitutability

+ +

+12.1.5.2 Rule of Complex Contagion

+ +

+12.1.5.3 Rule of Canonical Representation for Complex Rationals

+ +

+12.1.5.4 Principal Values and Branch Cuts

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aea.htm new file mode 100644 index 00000000..478647bd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aea.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 12.1.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.5.1 Rule of Complex Substitutability

+Except during the execution of irrational and transcendental functions, no numerical function ever yields a complex unless one or more of its arguments is a complex.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeb.htm new file mode 100644 index 00000000..c60cd3a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeb.htm @@ -0,0 +1,28 @@ + + + +CLHS: Section 12.1.5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.5.2 Rule of Complex Contagion

+ When a real and a complex are both part of a computation, the real is first converted to a complex by providing an imaginary part of 0.

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aec.htm new file mode 100644 index 00000000..ac87ffe1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aec.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 12.1.5.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.5.3 Rule of Canonical Representation for Complex Rationals

+If the result of any computation would be a complex number whose real part is of type rational and whose imaginary part is zero, the result is converted to the rational which is the real part. This rule does not apply to complex numbers whose parts are floats. For example, #C(5 0) and 5 are not different objects in Common Lisp(they are always the same under eql); #C(5.0 0.0) and 5.0 are always different objects in Common Lisp they are never the same under eql, although they are the same under equalp and =).

+ + +

+12.1.5.3.1 Examples of Rule of Canonical Representation for Complex Rationals

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeca.htm new file mode 100644 index 00000000..429dfea6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aeca.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 12.1.5.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.5.3.1 Examples of Rule of Canonical Representation for Complex Rationals

+

+ #c(1.0 1.0) =>  #C(1.0 1.0)
+ #c(0.0 0.0) =>  #C(0.0 0.0)
+ #c(1.0 1) =>  #C(1.0 1.0)
+ #c(0.0 0) =>  #C(0.0 0.0)
+ #c(1 1) =>  #C(1 1)
+ #c(0 0) =>  0
+ (typep #c(1 1) '(complex (eql 1))) =>  true
+ (typep #c(0 0) '(complex (eql 0))) =>  false
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aed.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aed.htm new file mode 100644 index 00000000..5cd79168 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_aed.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 12.1.5.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.5.4 Principal Values and Branch Cuts

+Many of the irrational and transcendental functions are multiply defined in the complex domain; for example, there are in general an infinite number of complex values for the logarithm function. In each such case, a principal value must be chosen for the function to return. In general, such values cannot be chosen so as to make the range continuous; lines in the domain called branch cuts must be defined, which in turn define the discontinuities in the range. Common Lisp defines the branch cuts, principal values, and boundary conditions for the complex functions following ``Principal Values and Branch Cuts in Complex APL.'' The branch cut rules that apply to each function are located with the description of that function.

+The next figure lists the identities that are obeyed throughout the applicable portion of the complex domain, even on the branch cuts:

+

+sin i z = i sinh z  sinh i z = i sin z        arctan i z = i arctanh z  
+cos i z = cosh z    cosh i z = cos z          arcsinh i z = i arcsin z  
+tan i z = i tanh z  arcsin i z = i arcsinh z  arctanh i z = i arctan z  
+
+

Figure 12-9. Trigonometric Identities for Complex Domain

+The quadrant numbers referred to in the discussions of branch cuts are as illustrated in the next figure.

+

[Quadrants image]

Figure 12-10. Quadrant Numbering for Branch Cuts

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_af.htm new file mode 100644 index 00000000..ed6cbb56 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_af.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 12.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.6 Interval Designators

+The compound type specifier form of the numeric type specifiers permit the user to specify an interval on the real number line which describe a subtype of the type which would be described by the corresponding atomic type specifier. A subtype of some type T is specified using an ordered pair of objects called interval designators for type T.

+The first of the two interval designators for type T can be any of the following:

+

+

a number N of type T

+This denotes a lower inclusive bound of N. That is, elements of the subtype of T will be greater than or equal to N.

+

a singleton list whose element is a number M of type T

+This denotes a lower exclusive bound of M. That is, elements of the subtype of T will be greater than M.

+

the symbol *

+This denotes the absence of a lower bound on the interval.

+

+The second of the two interval designators for type T can be any of the following:

+

+

a number N of type T

+This denotes an upper inclusive bound of N. That is, elements of the subtype of T will be less than or equal to N.

+

a singleton list whose element is a number M of type T

+This denotes an upper exclusive bound of M. That is, elements of the subtype of T will be less than M.

+

the symbol *

+This denotes the absence of an upper bound on the interval.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ag.htm new file mode 100644 index 00000000..7d41fbb0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/12_ag.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 12.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.1.7 Random-State Operations

+The next figure lists some defined names that are applicable to random states.

+

+*random-state*     random            
+make-random-state  random-state-p    
+
+

Figure 12-11. Random-state defined names

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_.htm new file mode 100644 index 00000000..f39a9274 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 13 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+13. Characters

+

+ + +

+13.1 Character Concepts

+ +

+13.2 The Characters Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_a.htm new file mode 100644 index 00000000..f7c18a3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_a.htm @@ -0,0 +1,59 @@ + + + +CLHS: Section 13.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1 Character Concepts

+ + +

+13.1.1 Introduction to Characters

+ +

+13.1.2 Introduction to Scripts and Repertoires

+ +

+13.1.3 Character Attributes

+ +

+13.1.4 Character Categories

+ +

+13.1.5 Identity of Characters

+ +

+13.1.6 Ordering of Characters

+ +

+13.1.7 Character Names

+ +

+13.1.8 Treatment of Newline during Input and Output

+ +

+13.1.9 Character Encodings

+ + +

+13.1.10 Documentation of Implementation-Defined Scripts

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aa.htm new file mode 100644 index 00000000..ed8b6798 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aa.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 13.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.1 Introduction to Characters

+A character is an object that represents a unitary token (e.g., a letter, a special symbol, or a ``control character'') in an aggregate quantity of text (e.g., a string or a text stream).

+ Common Lisp allows an implementation to provide support for international language characters as well as characters used in specialized arenas (e.g., mathematics).

+The following figures contain lists of defined names applicable to characters.

+The next figure lists some defined names relating to character attributes and character predicates.

+

+alpha-char-p     char-not-equal     char>            
+alphanumericp    char-not-greaterp  char>=           
+both-case-p      char-not-lessp     digit-char-p     
+char-code-limit  char/=             graphic-char-p   
+char-equal       char<              lower-case-p     
+char-greaterp    char<=             standard-char-p  
+char-lessp       char=              upper-case-p     
+
+

Figure 13-1. Character defined names -- 1

+The next figure lists some character construction and conversion defined names.

+

+char-code      char-name    code-char   
+char-downcase  char-upcase  digit-char  
+char-int       character    name-char   
+
+

Figure 13-2. Character defined names -- 2

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ab.htm new file mode 100644 index 00000000..cbf7e4b7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ab.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 13.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.2 Introduction to Scripts and Repertoires

+ + +

+13.1.2.1 Character Scripts

+ +

+13.1.2.2 Character Repertoires

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aba.htm new file mode 100644 index 00000000..86164af0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aba.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 13.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.2.1 Character Scripts

+A script is one of possibly several sets that form an exhaustive partition of the type character.

+The number of such sets and boundaries between them is implementation-defined. Common Lisp does not require these sets to be types, but an implementation is permitted to define such types as an extension. Since no character from one script can ever be a member of another script, it is generally more useful to speak about character repertoires.

+ Although the term ``script'' is chosen for definitional compatibility with ISO terminology, no conforming implementation is required to use any particular scripts standardized by ISO or by any other standards organization.

+ Whether and how the script or scripts used by any given implementation are named is implementation-dependent.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_abb.htm new file mode 100644 index 00000000..534c0b03 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_abb.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 13.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.2.2 Character Repertoires

+ A repertoire is a type specifier for a subtype of type character. This term is generally used when describing a collection of characters independent of their coding. Characters in repertoires are only identified by name, by glyph, or by character description.

+A repertoire can contain characters from several scripts, and a character can appear in more than one repertoire.

+ For some examples of repertoires, see the coded character standards ISO 8859/1, ISO 8859/2, and ISO 6937/2. Note, however, that although the term ``repertoire'' is chosen for definitional compatibility with ISO terminology, no conforming implementation is required to use repertoires standardized by ISO or any other standards organization.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ac.htm new file mode 100644 index 00000000..f662f9c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ac.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 13.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.3 Character Attributes

+ Characters have only one standardized attribute: a code. A character's code is a non-negative integer. This code is composed from a character script and a character label in an implementation-dependent way. See the functions char-code and code-char.

+

+Additional, implementation-defined attributes of characters are also permitted so that, for example, two characters with the same code may differ in some other, implementation-defined way.

+For any implementation-defined attribute there is a distinguished value called the null value for that attribute. A character for which each implementation-defined attribute has the null value for that attribute is called a simple character. If the implementation has no implementation-defined attributes, then all characters are simple characters.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ad.htm new file mode 100644 index 00000000..b45629a9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ad.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 13.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4 Character Categories

+There are several (overlapping) categories of characters that have no formally associated type but that are nevertheless useful to name. They include graphic characters, alphabetic[1] characters, characters with case (uppercase and lowercase characters), numeric characters, alphanumeric characters, and digits (in a given radix).

+For each implementation-defined attribute of a character, the documentation for that implementation must specify whether characters that differ only in that attribute are permitted to differ in whether are not they are members of one of the aforementioned categories.

+Note that these terms are defined independently of any special syntax which might have been enabled in the current readtable.

+ + +

+13.1.4.1 Graphic Characters

+ +

+13.1.4.2 Alphabetic Characters

+ +

+13.1.4.3 Characters With Case

+ +

+13.1.4.4 Numeric Characters

+ +

+13.1.4.5 Alphanumeric Characters

+ +

+13.1.4.6 Digits in a Radix

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ada.htm new file mode 100644 index 00000000..113ae311 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ada.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 13.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.1 Graphic Characters

+ Characters that are classified as graphic, or displayable, are each associated with a glyph, a visual representation of the character.

+A graphic character is one that has a standard textual representation as a single glyph, such as A or * or =. Space, which effectively has a blank glyph, is defined to be a graphic.

+Of the standard characters, newline is non-graphic and all others are graphic; see Section 2.1.3 (Standard Characters).

+ Characters that are not graphic are called non-graphic. Non-graphic characters are sometimes informally called ``formatting characters'' or ``control characters.''

+#\Backspace, #\Tab, #\Rubout, #\Linefeed, #\Return, and #\Page, if they are supported by the implementation, are non-graphic.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adb.htm new file mode 100644 index 00000000..c6c94aa7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 13.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.2 Alphabetic Characters

+The alphabetic[1] characters are a subset of the graphic characters. Of the standard characters, only these are the alphabetic[1] characters:

+A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

+a b c d e f g h i j k l m n o p q r s t u v w x y z

+Any implementation-defined character that has case must be alphabetic[1]. For each implementation-defined graphic character that has no case, it is implementation-defined whether that character is alphabetic[1].

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adc.htm new file mode 100644 index 00000000..211d7663 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adc.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 13.1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.3 Characters With Case

+The characters with case are a subset of the alphabetic[1] characters. A character with case has the property of being either uppercase or lowercase. Every character with case is in one-to-one correspondence with some other character with the opposite case.

+ + +

+13.1.4.3.1 Uppercase Characters

+ +

+13.1.4.3.2 Lowercase Characters

+ +

+13.1.4.3.3 Corresponding Characters in the Other Case

+ +

+13.1.4.3.4 Case of Implementation-Defined Characters

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adca.htm new file mode 100644 index 00000000..e486b665 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adca.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 13.1.4.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.3.1 Uppercase Characters

+An uppercase character is one that has a corresponding lowercase character that is different (and can be obtained using char-downcase).

+Of the standard characters, only these are uppercase characters:

+A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcb.htm new file mode 100644 index 00000000..b1651de3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcb.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 13.1.4.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.3.2 Lowercase Characters

+A lowercase character is one that has a corresponding uppercase character that is different (and can be obtained using char-upcase).

+Of the standard characters, only these are lowercase characters:

+a b c d e f g h i j k l m n o p q r s t u v w x y z

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcc.htm new file mode 100644 index 00000000..f0eb8f36 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.4.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.3.3 Corresponding Characters in the Other Case

+The uppercase standard characters A through Z mentioned above respectively correspond to the lowercase standard characters a through z mentioned above. For example, the uppercase character E corresponds to the lowercase character e, and vice versa.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcd.htm new file mode 100644 index 00000000..416e2a24 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adcd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.4.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.3.4 Case of Implementation-Defined Characters

+An implementation may define that other implementation-defined graphic characters have case. Such definitions must always be done in pairs---one uppercase character in one-to-one correspondence with one lowercase character.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_add.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_add.htm new file mode 100644 index 00000000..950a2b8c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_add.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 13.1.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.4 Numeric Characters

+The numeric characters are a subset of the graphic characters. Of the standard characters, only these are numeric characters:

+0 1 2 3 4 5 6 7 8 9

+For each implementation-defined graphic character that has no case, the implementation must define whether or not it is a numeric character.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ade.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ade.htm new file mode 100644 index 00000000..6b44f43c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ade.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.4.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.5 Alphanumeric Characters

+The set of alphanumeric characters is the union of the set of alphabetic[1] characters and the set of numeric characters.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adf.htm new file mode 100644 index 00000000..a0df0062 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_adf.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 13.1.4.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.4.6 Digits in a Radix

+What qualifies as a digit depends on the radix (an integer between 2 and 36, inclusive). The potential digits are:

+0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

+Their respective weights are 0, 1, 2, ... 35. In any given radix n, only the first n potential digits are considered to be digits. For example, the digits in radix 2 are 0 and 1, the digits in radix 10 are 0 through 9, and the digits in radix 16 are 0 through F.

+Case is not significant in digits; for example, in radix 16, both F and f are digits with weight 15.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ae.htm new file mode 100644 index 00000000..997700cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.5 Identity of Characters

+Two characters that are eql, char=, or char-equal are not necessarily eq.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_af.htm new file mode 100644 index 00000000..f14ac8a4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_af.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 13.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.6 Ordering of Characters

+The total ordering on characters is guaranteed to have the following properties:

+

+

+

* If two characters have the same implementation-defined attributes, then their ordering by char< is consistent with the numerical ordering by the predicate < on their code attributes.

+
* If two characters differ in any attribute, then they are not char=.

+

+

* The total ordering is not necessarily the same as the total ordering on the integers produced by applying char-int to the characters.

+
* While alphabetic[1] standard characters of a given case must obey a partial ordering, they need not be contiguous; it is permissible for uppercase and lowercase characters to be interleaved. Thus (char<= #\a x #\z) is not a valid way of determining whether or not x is a lowercase character.

+

+

+ Of the standard characters, those which are alphanumeric obey the following partial ordering:

+

+ A<B<C<D<E<F<G<H<I<J<K<L<M<N<O<P<Q<R<S<T<U<V<W<X<Y<Z
+ a<b<c<d<e<f<g<h<i<j<k<l<m<n<o<p<q<r<s<t<u<v<w<x<y<z
+ 0<1<2<3<4<5<6<7<8<9
+ either 9<A or Z<0
+ either 9<a or z<0                                                      
+
+ This implies that, for standard characters, alphabetic[1] ordering holds within each case (uppercase and lowercase), and that the numeric characters as a group are not interleaved with alphabetic characters. However, the ordering or possible interleaving of uppercase characters and lowercase characters is implementation-defined.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ag.htm new file mode 100644 index 00000000..a8eb14ae --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ag.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 13.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.7 Character Names

+The following character names must be present in all conforming implementations:

+

Newline

+The character that represents the division between lines. An implementation must translate between #\Newline, a single-character representation, and whatever external representation(s) may be used.

+

Space

+The space or blank character.

+The following names are semi-standard; if an implementation supports them, they should be used for the described characters and no others.

+

Rubout

+The rubout or delete character.

+

Page

+The form-feed or page-separator character.

+

Tab

+The tabulate character.

+

Backspace

+The backspace character.

+

Return

+The carriage return character.

+

Linefeed

+The line-feed character.

+In some implementations, one or more of these character names might denote a standard character; for example, #\Linefeed and #\Newline might be the same character in some implementations.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ah.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ah.htm new file mode 100644 index 00000000..1dd3feeb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ah.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.8 Treatment of Newline during Input and Output

+When the character #\Newline is written to an output file, the implementation must take the appropriate action to produce a line division. This might involve writing out a record or translating #\Newline to a CR/LF sequence. When reading, a corresponding reverse transformation must take place.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ai.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ai.htm new file mode 100644 index 00000000..75b29ce0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_ai.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.9 Character Encodings

+ A character is sometimes represented merely by its code, and sometimes by another integer value which is composed from the code and all implementation-defined attributes (in an implementation-defined way that might vary between Lisp images even in the same implementation). This integer, returned by the function char-int, is called the character's ``encoding.'' There is no corresponding function from a character's encoding back to the character, since its primary intended uses include things like hashing where an inverse operation is not really called for.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aj.htm new file mode 100644 index 00000000..d5e2732d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/13_aj.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 13.1.10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.1.10 Documentation of Implementation-Defined Scripts

+ An implementation must document the character scripts it supports. For each character script supported, the documentation must describe at least the following:

* Character labels, glyphs, and descriptions. Character labels must be uniquely named using only Latin capital letters A--Z, hyphen (-), and digits 0--9.
* Reader canonicalization. Any mechanisms by which read treats different characters as equivalent must be documented.
* The impact on char-upcase, char-downcase, and the case-sensitive format directives. In particular, for each character with case, whether it is uppercase or lowercase, and which character is its equivalent in the opposite case.
* The behavior of the case-insensitive functions char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp, and char-not-lessp.
* The behavior of any character predicates; in particular, the effects of alpha-char-p, lower-case-p, upper-case-p, both-case-p, graphic-char-p, and alphanumericp.
* The interaction with file I/O, in particular, the supported coded character sets (for example, ISO8859/1-1987) and external encoding schemes supported are documented.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_.htm new file mode 100644 index 00000000..3d2f69df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 14 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+14. Conses

+

+ + +

+14.1 Cons Concepts

+ +

+14.2 The Conses Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_a.htm new file mode 100644 index 00000000..b53f0454 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_a.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 14.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1 Cons Concepts

+A cons is a compound data object having two components called the car and the cdr.

+

+car  cons    rplacd  
+cdr  rplaca          
+
+

Figure 14-1. Some defined names relating to conses.

+Depending on context, a group of connected conses can be viewed in a variety of different ways. A variety of operations is provided to support each of these various views.

+ + +

+14.1.1 Conses as Trees

+ +

+14.1.2 Conses as Lists

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aa.htm new file mode 100644 index 00000000..16f74a10 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aa.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 14.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1.1 Conses as Trees

+A tree is a binary recursive data structure made up of conses and atoms: the conses are themselves also trees (sometimes called ``subtrees'' or ``branches''), and the atoms are terminal nodes (sometimes called leaves). Typically, the leaves represent data while the branches establish some relationship among that data.

+

+caaaar  caddar  cdar       nsubst         
+caaadr  cadddr  cddaar     nsubst-if      
+caaar   caddr   cddadr     nsubst-if-not  
+caadar  cadr    cddar      nthcdr         
+caaddr  cdaaar  cdddar     sublis         
+caadr   cdaadr  cddddr     subst          
+caar    cdaar   cdddr      subst-if       
+cadaar  cdadar  cddr       subst-if-not   
+cadadr  cdaddr  copy-tree  tree-equal     
+cadar   cdadr   nsublis                   
+
+

Figure 14-2. Some defined names relating to trees.

+ + +

+14.1.1.1 General Restrictions on Parameters that must be Trees

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aaa.htm new file mode 100644 index 00000000..71e6584e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 14.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1.1.1 General Restrictions on Parameters that must be Trees

+ Except as explicitly stated otherwise, for any standardized function that takes a parameter that is required to be a tree, the consequences are undefined if that tree is circular.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_ab.htm new file mode 100644 index 00000000..71651138 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_ab.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 14.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1.2 Conses as Lists

+A list is a chain of conses in which the car of each cons is an element of the list, and the cdr of each cons is either the next link in the chain or a terminating atom.

+A proper list is a list terminated by the empty list. The empty list is a proper list, but is not a cons.

+An improper list is a list that is not a proper list; that is, it is a circular list or a dotted list.

+A dotted list is a list that has a terminating atom that is not the empty list. A non-nil atom by itself is not considered to be a list of any kind---not even a dotted list.

+A circular list is a chain of conses that has no termination because some cons in the chain is the cdr of a later cons.

+

+append      last           nbutlast  rest       
+butlast     ldiff          nconc     revappend  
+copy-alist  list           ninth     second     
+copy-list   list*          nreconc   seventh    
+eighth      list-length    nth       sixth      
+endp        make-list      nthcdr    tailp      
+fifth       member         pop       tenth      
+first       member-if      push      third      
+fourth      member-if-not  pushnew              
+
+

Figure 14-3. Some defined names relating to lists.

+ + +

+14.1.2.1 Lists as Association Lists

+ +

+14.1.2.2 Lists as Sets

+ +

+14.1.2.3 General Restrictions on Parameters that must be Lists

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aba.htm new file mode 100644 index 00000000..17a085d1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_aba.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 14.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1.2.1 Lists as Association Lists

+An association list is a list of conses representing an association of keys with values, where the car of each cons is the key and the cdr is the value associated with that key.

+

+acons  assoc-if      pairlis  rassoc-if      
+assoc  assoc-if-not  rassoc   rassoc-if-not  
+
+

Figure 14-4. Some defined names related to assocation lists.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abb.htm new file mode 100644 index 00000000..b8573467 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abb.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 14.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1.2.2 Lists as Sets

+Lists are sometimes viewed as sets by considering their elements unordered and by assuming there is no duplication of elements.

+

+adjoin         nset-difference    set-difference    union  
+intersection   nset-exclusive-or  set-exclusive-or         
+nintersection  nunion             subsetp                  
+
+

Figure 14-5. Some defined names related to sets.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abc.htm new file mode 100644 index 00000000..a3cc48f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/14_abc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 14.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.1.2.3 General Restrictions on Parameters that must be Lists

+Except as explicitly specified otherwise, any standardized function that takes a parameter that is required to be a list should be prepared to signal an error of type type-error if the value received is a dotted list.

+Except as explicitly specified otherwise, for any standardized function that takes a parameter that is required to be a list, the consequences are undefined if that list is circular.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_.htm new file mode 100644 index 00000000..ac7c07ca --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 15 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+15. Arrays

+

+ + +

+15.1 Array Concepts

+ +

+15.2 The Arrays Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_a.htm new file mode 100644 index 00000000..b8b0823a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_a.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 15.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1 Array Concepts

+ + +

+15.1.1 Array Elements

+ +

+15.1.2 Specialized Arrays

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aa.htm new file mode 100644 index 00000000..4751724f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aa.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 15.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1 Array Elements

+An array contains a set of objects called elements that can be referenced individually according to a rectilinear coordinate system.

+ + +

+15.1.1.1 Array Indices

+ +

+15.1.1.2 Array Dimensions

+ +

+15.1.1.3 Array Rank

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaa.htm new file mode 100644 index 00000000..4fddaccf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 15.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.1 Array Indices

+An array element is referred to by a (possibly empty) series of indices. The length of the series must equal the rank of the array. Each index must be a non-negative fixnum less than the corresponding array dimension. Array indexing is zero-origin.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aab.htm new file mode 100644 index 00000000..984a9762 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aab.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 15.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.2 Array Dimensions

+An axis of an array is called a dimension.

+Each dimension is a non-negative fixnum; if any dimension of an array is zero, the array has no elements. It is permissible for a dimension to be zero, in which case the array has no elements, and any attempt to access an element is an error. However, other properties of the array, such as the dimensions themselves, may be used.

+ + +

+15.1.1.2.1 Implementation Limits on Individual Array Dimensions

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaba.htm new file mode 100644 index 00000000..2c898a51 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 15.1.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.2.1 Implementation Limits on Individual Array Dimensions

+An implementation may impose a limit on dimensions of an array, but there is a minimum requirement on that limit. See the variable array-dimension-limit.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aac.htm new file mode 100644 index 00000000..90d18bb9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aac.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 15.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.3 Array Rank

+An array can have any number of dimensions (including zero). The number of dimensions is called the rank.

+If the rank of an array is zero then the array is said to have no dimensions, and the product of the dimensions (see array-total-size) is then 1; a zero-rank array therefore has a single element.

+ + +

+15.1.1.3.1 Vectors

+ +

+15.1.1.3.2 Multidimensional Arrays

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaca.htm new file mode 100644 index 00000000..b8f5f8ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aaca.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 15.1.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.3.1 Vectors

+An array of rank one (i.e., a one-dimensional array) is called a vector.

+ + +

+15.1.1.3.1.1 Fill Pointers

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacaa.htm new file mode 100644 index 00000000..d24cb7ef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacaa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 15.1.1.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.3.1.1 Fill Pointers

+A fill pointer is a non-negative integer no larger than the total number of elements in a vector. Not all vectors have fill pointers. See the functions make-array and adjust-array.

+An element of a vector is said to be active if it has an index that is greater than or equal to zero, but less than the fill pointer (if any). For an array that has no fill pointer, all elements are considered active.

+Only vectors may have fill pointers; multidimensional arrays may not. A multidimensional array that is displaced to a vector that has a fill pointer can be created.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacb.htm new file mode 100644 index 00000000..3f218f0e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacb.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 15.1.1.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.3.2 Multidimensional Arrays

+ + +

+15.1.1.3.2.1 Storage Layout for Multidimensional Arrays

+ +

+15.1.1.3.2.2 Implementation Limits on Array Rank

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacba.htm new file mode 100644 index 00000000..7780d3b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 15.1.1.3.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.3.2.1 Storage Layout for Multidimensional Arrays

+Multidimensional arrays store their components in row-major order; that is, internally a multidimensional array is stored as a one-dimensional array, with the multidimensional index sets ordered lexicographically, last index varying fastest.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacbb.htm new file mode 100644 index 00000000..5c3617e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aacbb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 15.1.1.3.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.1.3.2.2 Implementation Limits on Array Rank

+An implementation may impose a limit on the rank of an array, but there is a minimum requirement on that limit. See the variable array-rank-limit.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_ab.htm new file mode 100644 index 00000000..881238ea --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_ab.htm @@ -0,0 +1,48 @@ + + + +CLHS: Section 15.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.2 Specialized Arrays

+An array can be a general array, meaning each element may be any object, or it may be a specialized array, meaning that each element must be of a restricted type.

+The phrasing ``an array specialized to type <<type>>'' is sometimes used to emphasize the element type of an array. This phrasing is tolerated even when the <<type>> is t, even though an array specialized to type t is a general array, not a specialized array.

+The next figure lists some defined names that are applicable to array creation, access, and information operations.

+

+adjust-array           array-has-fill-pointer-p  make-array                   
+adjustable-array-p     array-in-bounds-p         svref                        
+aref                   array-rank                upgraded-array-element-type  
+array-dimension        array-rank-limit          upgraded-complex-part-type   
+array-dimension-limit  array-row-major-index     vector                       
+array-dimensions       array-total-size          vector-pop                   
+array-displacement     array-total-size-limit    vector-push                  
+array-element-type     fill-pointer              vector-push-extend           
+
+

Figure 15-1. General Purpose Array-Related Defined Names

+ + +

+15.1.2.1 Array Upgrading

+ +

+15.1.2.2 Required Kinds of Specialized Arrays

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aba.htm new file mode 100644 index 00000000..1b8e3151 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_aba.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 15.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.2.1 Array Upgrading

+

+The upgraded array element type of a type T1 is a type T2 that is a supertype of T1 and that is used instead of T1 whenever T1 is used as an array element type for object creation or type discrimination.

+During creation of an array, the element type that was requested is called the expressed array element type. The upgraded array element type of the expressed array element type becomes the actual array element type of the array that is created.

+Type upgrading implies a movement upwards in the type hierarchy lattice. A type is always a subtype of its upgraded array element type. Also, if a type Tx is a subtype of another type Ty, then the upgraded array element type of Tx must be a subtype of the upgraded array element type of Ty. Two disjoint types can be upgraded to the same type.

+The upgraded array element type T2 of a type T1 is a function only of T1 itself; that is, it is independent of any other property of the array for which T2 will be used, such as rank, adjustability, fill pointers, or displacement. The function upgraded-array-element-type can be used by conforming programs to predict how the implementation will upgrade a given type.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_abb.htm new file mode 100644 index 00000000..6e2bf5c0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/15_abb.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 15.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.1.2.2 Required Kinds of Specialized Arrays

+Vectors whose elements are restricted to type character or a subtype of character are called strings. Strings are of type string. The next figure lists some defined names related to strings.

+Strings are specialized arrays and might logically have been included in this chapter. However, for purposes of readability most information about strings does not appear in this chapter; see instead Section 16 (Strings).

+

+char                string-equal         string-upcase  
+make-string         string-greaterp      string/=       
+nstring-capitalize  string-left-trim     string<        
+nstring-downcase    string-lessp         string<=       
+nstring-upcase      string-not-equal     string=        
+schar               string-not-greaterp  string>        
+string              string-not-lessp     string>=       
+string-capitalize   string-right-trim                   
+string-downcase     string-trim                         
+
+

Figure 15-2. Operators that Manipulate Strings

+Vectors whose elements are restricted to type bit are called bit vectors. Bit vectors are of type bit-vector. The next figure lists some defined names for operations on bit arrays.

+

+bit        bit-ior   bit-orc2  
+bit-and    bit-nand  bit-xor   
+bit-andc1  bit-nor   sbit      
+bit-andc2  bit-not             
+bit-eqv    bit-orc1            
+
+

Figure 15-3. Operators that Manipulate Bit Arrays

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_.htm new file mode 100644 index 00000000..2c266fb8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 16 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+16. Strings

+

+ + +

+16.1 String Concepts

+ +

+16.2 The Strings Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_a.htm new file mode 100644 index 00000000..34f46191 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_a.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 16.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+16.1 String Concepts

+ + +

+16.1.1 Implications of Strings Being Arrays

+ +

+16.1.2 Subtypes of STRING

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_aa.htm new file mode 100644 index 00000000..9f88e3f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_aa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 16.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+16.1.1 Implications of Strings Being Arrays

+Since all strings are arrays, all rules which apply generally to arrays also apply to strings. See Section 15.1 (Array Concepts).

+For example, strings can have fill pointers, and strings are also subject to the rules of element type upgrading that apply to arrays.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_ab.htm new file mode 100644 index 00000000..59e4b28c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/16_ab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 16.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+16.1.2 Subtypes of STRING

All functions that operate on strings will operate on subtypes of string as well.

+However, the consequences are undefined if a character is inserted into a string for which the element type of the string does not include that character.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_.htm new file mode 100644 index 00000000..a0416e0a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_.htm @@ -0,0 +1,41 @@ + + + +CLHS: Chapter 17 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+17. Sequences

+

+ + +

+17.1 Sequence Concepts

+ +

+17.2 Rules about Test Functions

+ +

+17.3 The Sequences Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_a.htm new file mode 100644 index 00000000..babbf2ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_a.htm @@ -0,0 +1,52 @@ + + + +CLHS: Section 17.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.1 Sequence Concepts

+A sequence is an ordered collection of elements, implemented as either a vector or a list.

+Sequences can be created by the function make-sequence, as well as other functions that create objects of types that are subtypes of sequence (e.g., list, make-list, mapcar, and vector).

+A sequence function is a function defined by this specification or added as an extension by the implementation that operates on one or more sequences. Whenever a sequence function must construct and return a new vector, it always returns a simple vector. Similarly, any strings constructed will be simple strings.

+ 

+concatenate        length              remove             
+copy-seq           map                 remove-duplicates  
+count              map-into            remove-if          
+count-if           merge               remove-if-not      
+count-if-not       mismatch            replace            
+delete             notany              reverse            
+delete-duplicates  notevery            search             
+delete-if          nreverse            some               
+delete-if-not      nsubstitute         sort               
+elt                nsubstitute-if      stable-sort        
+every              nsubstitute-if-not  subseq             
+fill               position            substitute         
+find               position-if         substitute-if      
+find-if            position-if-not     substitute-if-not  
+find-if-not        reduce                                 
+
+

Figure 17-1. Standardized Sequence Functions

+ + +

+17.1.1 General Restrictions on Parameters that must be Sequences

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_aa.htm new file mode 100644 index 00000000..0310448f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_aa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 17.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.1.1 General Restrictions on Parameters that must be Sequences

+In general, lists (including association lists and property lists) that are treated as sequences must be proper lists.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_b.htm new file mode 100644 index 00000000..841bb2d4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_b.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 17.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.2 Rules about Test Functions

+ + +

+17.2.1 Satisfying a Two-Argument Test

+ +

+17.2.2 Satisfying a One-Argument Test

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_ba.htm new file mode 100644 index 00000000..695fa718 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_ba.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 17.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.2.1 Satisfying a Two-Argument Test

+When an object O is being considered iteratively against each element Ei of a sequence S by an operator F listed in the next figure, it is sometimes useful to control the way in which the presence of O is tested in S is tested by F. This control is offered on the basis of a function designated with either a :test or :test-not argument.

+

+adjoin           nset-exclusive-or  search            
+assoc            nsublis            set-difference    
+count            nsubst             set-exclusive-or  
+delete           nsubstitute        sublis            
+find             nunion             subsetp           
+intersection     position           subst             
+member           pushnew            substitute        
+mismatch         rassoc             tree-equal        
+nintersection    remove             union             
+nset-difference  remove-duplicates                    
+
+

Figure 17-2. Operators that have Two-Argument Tests to be Satisfied

+The object O might not be compared directly to Ei. If a :key argument is provided, it is a designator for a function of one argument to be called with each Ei as an argument, and yielding an object Zi to be used for comparison. (If there is no :key argument, Zi is Ei.)

+The function designated by the :key argument is never called on O itself. However, if the function operates on multiple sequences (e.g., as happens in set-difference), O will be the result of calling the :key function on an element of the other sequence.

+A :test argument, if supplied to F, is a designator for a function of two arguments, O and Zi. An Ei is said (or, sometimes, an O and an Ei are said) to satisfy the test if this :test function returns a generalized boolean representing true.

+A :test-not argument, if supplied to F, is designator for a function of two arguments, O and Zi. An Ei is said (or, sometimes, an O and an Ei are said) to satisfy the test if this :test-not function returns a generalized boolean representing false.

+If neither a :test nor a :test-not argument is supplied, it is as if a :test argument of #'eql was supplied.

+The consequences are unspecified if both a :test and a :test-not argument are supplied in the same call to F.

+ + +

+17.2.1.1 Examples of Satisfying a Two-Argument Test

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_baa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_baa.htm new file mode 100644 index 00000000..682dbfb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_baa.htm @@ -0,0 +1,56 @@ + + + +CLHS: Section 17.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.2.1.1 Examples of Satisfying a Two-Argument Test

+

+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'equal)
+=>  (foo bar "BAR" "foo" "bar")
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'equalp)
+=>  (foo bar "BAR" "bar")
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'string-equal)
+=>  (bar "BAR" "bar")
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'string=)
+=>  (BAR "BAR" "foo" "bar")
+
+ (remove 1 '(1 1.0 #C(1.0 0.0) 2 2.0 #C(2.0 0.0)) :test-not #'eql)
+=>  (1)
+ (remove 1 '(1 1.0 #C(1.0 0.0) 2 2.0 #C(2.0 0.0)) :test-not #'=)
+=>  (1 1.0 #C(1.0 0.0))
+ (remove 1 '(1 1.0 #C(1.0 0.0) 2 2.0 #C(2.0 0.0)) :test (complement #'=))
+=>  (1 1.0 #C(1.0 0.0))
+
+ (count 1 '((one 1) (uno 1) (two 2) (dos 2)) :key #'cadr) =>  2
+
+ (count 2.0 '(1 2 3) :test #'eql :key #'float) =>  1
+
+ (count "FOO" (list (make-pathname :name "FOO" :type "X")  
+                    (make-pathname :name "FOO" :type "Y"))
+        :key #'pathname-name
+        :test #'equal)
+=>  2
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bb.htm new file mode 100644 index 00000000..9df9fcf2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bb.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 17.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.2.2 Satisfying a One-Argument Test

+When using one of the functions in the next figure, the elements E of a sequence S are filtered not on the basis of the presence or absence of an object O under a two argument predicate, as with the functions described in Section 17.2.1 (Satisfying a Two-Argument Test), but rather on the basis of a one argument predicate.

+

+assoc-if       member-if           rassoc-if          
+assoc-if-not   member-if-not       rassoc-if-not      
+count-if       nsubst-if           remove-if          
+count-if-not   nsubst-if-not       remove-if-not      
+delete-if      nsubstitute-if      subst-if           
+delete-if-not  nsubstitute-if-not  subst-if-not       
+find-if        position-if         substitute-if      
+find-if-not    position-if-not     substitute-if-not  
+
+

Figure 17-3. Operators that have One-Argument Tests to be Satisfied

+The element Ei might not be considered directly. If a :key argument is provided, it is a designator for a function of one argument to be called with each Ei as an argument, and yielding an object Zi to be used for comparison. (If there is no :key argument, Zi is Ei.)

+Functions defined in this specification and having a name that ends in ``-if'' accept a first argument that is a designator for a function of one argument, Zi. An Ei is said to satisfy the test if this :test function returns a generalized boolean representing true.

+Functions defined in this specification and having a name that ends in ``-if-not'' accept a first argument that is a designator for a function of one argument, Zi. An Ei is said to satisfy the test if this :test function returns a generalized boolean representing false.

+ + +

+17.2.2.1 Examples of Satisfying a One-Argument Test

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bba.htm new file mode 100644 index 00000000..75b2f0c0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/17_bba.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 17.2.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.2.2.1 Examples of Satisfying a One-Argument Test

+

+ (count-if #'zerop '(1 #C(0.0 0.0) 0 0.0d0 0.0s0 3)) =>  4
+
+ (remove-if-not #'symbolp '(0 1 2 3 4 5 6 7 8 9 A B C D E F))
+=>  (A B C D E F)
+ (remove-if (complement #'symbolp) '(0 1 2 3 4 5 6 7 8 9 A B C D E F))
+=>  (A B C D E F)
+
+ (count-if #'zerop '("foo" "" "bar" "" "" "baz" "quux") :key #'length)
+=>  3
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_.htm new file mode 100644 index 00000000..f345d7e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 18 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+18. Hash Tables

+

+ + +

+18.1 Hash Table Concepts

+ +

+18.2 The Hash Tables Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_a.htm new file mode 100644 index 00000000..8f4464e2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_a.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 18.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1 Hash Table Concepts

+ + +

+18.1.1 Hash-Table Operations

+ +

+18.1.2 Modifying Hash Table Keys

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aa.htm new file mode 100644 index 00000000..6a805ddf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aa.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 18.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.1 Hash-Table Operations

+The next figure lists some defined names that are applicable to hash tables. The following rules apply to hash tables.

+

-- A hash table can only associate one value with a given key. If an attempt is made to add a second value for a given key, the second value will replace the first. Thus, adding a value to a hash table is a destructive operation; the hash table is modified.

+
-- There are four kinds of hash tables: those whose keys are compared with eq, those whose keys are compared with eql, those whose keys are compared with equal, and those whose keys are compared with equalp.

+
-- Hash tables are created by make-hash-table. gethash is used to look up a key and find the associated value. New entries are added to hash tables using setf with gethash. remhash is used to remove an entry. For example:

+
+ (setq a (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32536573>
+ (setf (gethash 'color a) 'brown) =>  BROWN
+ (setf (gethash 'name a) 'fred) =>  FRED
+ (gethash 'color a) =>  BROWN, true
+ (gethash 'name a) =>  FRED, true
+ (gethash 'pointy a) =>  NIL, false
+
+

+In this example, the symbols color and name are being used as keys, and the symbols brown and fred are being used as the associated values. The hash table has two items in it, one of which associates from color to brown, and the other of which associates from name to fred.

+

-- A key or a value may be any object.

+

+

-- The existence of an entry in the hash table can be determined from the secondary value returned by gethash.

+

+clrhash           hash-table-p     remhash  
+gethash           make-hash-table  sxhash   
+hash-table-count  maphash                   
+
+

Figure 18-1. Hash-table defined names

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_ab.htm new file mode 100644 index 00000000..90fed937 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_ab.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 18.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2 Modifying Hash Table Keys

+

+The function supplied as the :test argument to make-hash-table specifies the `equivalence test' for the hash table it creates.

+An object is `visibly modified' with regard to an equivalence test if there exists some set of objects (or potential objects) which are equivalent to the object before the modification but are no longer equivalent afterwards.

+If an object O1 is used as a key in a hash table H and is then visibly modified with regard to the equivalence test of H, then the consequences are unspecified if O1, or any object O2 equivalent to O1 under the equivalence test (either before or after the modification), is used as a key in further operations on H. The consequences of using O1 as a key are unspecified even if O1 is visibly modified and then later modified again in such a way as to undo the visible modification.

+Following are specifications of the modifications which are visible to the equivalence tests which must be supported by hash tables. The modifications are described in terms of modification of components, and are defined recursively. Visible modifications of components of the object are visible modifications of the object.

+ + +

+18.1.2.1 Visible Modification of Objects with respect to EQ and EQL

+ +

+18.1.2.2 Visible Modification of Objects with respect to EQUAL

+ +

+18.1.2.3 Visible Modification of Objects with respect to EQUALP

+ +

+18.1.2.4 Visible Modifications by Language Extensions

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aba.htm new file mode 100644 index 00000000..0f9ea604 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_aba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 18.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.1 Visible Modification of Objects with respect to EQ and EQL

+No standardized function is provided that is capable of visibly modifying an object with regard to eq or eql.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abb.htm new file mode 100644 index 00000000..03525802 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abb.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 18.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.2 Visible Modification of Objects with respect to EQUAL

+As a consequence of the behavior for equal, the rules for visible modification of objects not explicitly mentioned in this section are inherited from those in Section 18.1.2.1 (Visible Modification of Objects with respect to EQ and EQL).

+ + +

+18.1.2.2.1 Visible Modification of Conses with respect to EQUAL

+ +

+18.1.2.2.2 Visible Modification of Bit Vectors and Strings with respect to EQUAL

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abba.htm new file mode 100644 index 00000000..f6001401 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 18.1.2.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.2.1 Visible Modification of Conses with respect to EQUAL

+Any visible change to the car or the cdr of a cons is considered a visible modification with regard to equal.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abbb.htm new file mode 100644 index 00000000..16e68611 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abbb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 18.1.2.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.2.2 Visible Modification of Bit Vectors and Strings with respect to EQUAL

+For a vector of type bit-vector or of type string, any visible change to an active element of the vector, or to the length of the vector (if it is actually adjustable or has a fill pointer) is considered a visible modification with regard to equal.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abc.htm new file mode 100644 index 00000000..63266477 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abc.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 18.1.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.3 Visible Modification of Objects with respect to EQUALP

+As a consequence of the behavior for equalp, the rules for visible modification of objects not explicitly mentioned in this section are inherited from those in Section 18.1.2.2 (Visible Modification of Objects with respect to EQUAL).

+ + +

+18.1.2.3.1 Visible Modification of Structures with respect to EQUALP

+ +

+18.1.2.3.2 Visible Modification of Arrays with respect to EQUALP

+ +

+18.1.2.3.3 Visible Modification of Hash Tables with respect to EQUALP

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abca.htm new file mode 100644 index 00000000..3d366869 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abca.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 18.1.2.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.3.1 Visible Modification of Structures with respect to EQUALP

+Any visible change to a slot of a structure is considered a visible modification with regard to equalp.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcb.htm new file mode 100644 index 00000000..20732024 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 18.1.2.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.3.2 Visible Modification of Arrays with respect to EQUALP

+In an array, any visible change to an active element, to the fill pointer (if the array can and does have one), or to the dimensions (if the array is actually adjustable) is considered a visible modification with regard to equalp.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcc.htm new file mode 100644 index 00000000..3af01da9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abcc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 18.1.2.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.3.3 Visible Modification of Hash Tables with respect to EQUALP

+In a hash table, any visible change to the count of entries in the hash table, to the keys, or to the values associated with the keys is considered a visible modification with regard to equalp.

+Note that the visibility of modifications to the keys depends on the equivalence test of the hash table, not on the specification of equalp.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abd.htm new file mode 100644 index 00000000..a50da240 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/18_abd.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 18.1.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.1.2.4 Visible Modifications by Language Extensions

+Implementations that extend the language by providing additional mutator functions (or additional behavior for existing mutator functions) must document how the use of these extensions interacts with equivalence tests and hash table searches.

+Implementations that extend the language by defining additional acceptable equivalence tests for hash tables (allowing additional values for the :test argument to make-hash-table) must document the visible components of these tests.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_.htm new file mode 100644 index 00000000..fd0398c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_.htm @@ -0,0 +1,44 @@ + + + +CLHS: Chapter 19 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+19. Filenames

+

+ + +

+19.1 Overview of Filenames

+ +

+19.2 Pathnames

+ +

+19.3 Logical Pathnames

+ +

+19.4 The Filenames Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_a.htm new file mode 100644 index 00000000..4fbc046c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_a.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 19.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.1 Overview of Filenames

+There are many kinds of file systems, varying widely both in their superficial syntactic details, and in their underlying power and structure. The facilities provided by Common Lisp for referring to and manipulating files has been chosen to be compatible with many kinds of file systems, while at the same time minimizing the program-visible differences between kinds of file systems.

+Since file systems vary in their conventions for naming files, there are two distinct ways to represent filenames: as namestrings and as pathnames.

+ + +

+19.1.1 Namestrings as Filenames

+ +

+19.1.2 Pathnames as Filenames

+ +

+19.1.3 Parsing Namestrings Into Pathnames

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_aa.htm new file mode 100644 index 00000000..7175a0d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_aa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 19.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.1.1 Namestrings as Filenames

+ A namestring is a string that represents a filename.

+In general, the syntax of namestrings involves the use of implementation-defined conventions, usually those customary for the file system in which the named file resides. The only exception is the syntax of a logical pathname namestring, which is defined in this specification; see Section 19.3.1 (Syntax of Logical Pathname Namestrings).

+A conforming program must never unconditionally use a literal namestring other than a logical pathname namestring because Common Lisp does not define any namestring syntax other than that for logical pathnames that would be guaranteed to be portable. However, a conforming program can, if it is careful, successfully manipulate user-supplied data which contains or refers to non-portable namestrings.

+A namestring can be coerced to a pathname by the functions pathname or parse-namestring.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ab.htm new file mode 100644 index 00000000..fef21c59 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ab.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 19.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.1.2 Pathnames as Filenames

+Pathnames are structured objects that can represent, in an implementation-independent way, the filenames that are used natively by an underlying file system.

+In addition, pathnames can also represent certain partially composed filenames for which an underlying file system might not have a specific namestring representation.

+A pathname need not correspond to any file that actually exists, and more than one pathname can refer to the same file. For example, the pathname with a version of :newest might refer to the same file as a pathname with the same components except a certain number as the version. Indeed, a pathname with version :newest might refer to different files as time passes, because the meaning of such a pathname depends on the state of the file system.

+Some file systems naturally use a structural model for their filenames, while others do not. Within the Common Lisp pathname model, all filenames are seen as having a particular structure, even if that structure is not reflected in the underlying file system. The nature of the mapping between structure imposed by pathnames and the structure, if any, that is used by the underlying file system is implementation-defined.

+Every pathname has six components: a host, a device, a directory, a name, a type, and a version. By naming files with pathnames, Common Lisp programs can work in essentially the same way even in file systems that seem superficially quite different. For a detailed description of these components, see Section 19.2.1 (Pathname Components).

+ The mapping of the pathname components into the concepts peculiar to each file system is implementation-defined. There exist conceivable pathnames for which there is no mapping to a syntactically valid filename in a particular implementation. An implementation may use various strategies in an attempt to find a mapping; for example, an implementation may quietly truncate filenames that exceed length limitations imposed by the underlying file system, or ignore certain pathname components for which the file system provides no support. If such a mapping cannot be found, an error of type file-error is signaled.

+The time at which this mapping and associated error signaling occurs is implementation-dependent. Specifically, it may occur at the time the pathname is constructed, when coercing a pathname to a namestring, or when an attempt is made to open or otherwise access the file designated by the pathname.

+The next figure lists some defined names that are applicable to pathnames.

+

+*default-pathname-defaults*  namestring          pathname-name          
+directory-namestring         open                pathname-type          
+enough-namestring            parse-namestring    pathname-version       
+file-namestring              pathname            pathnamep              
+file-string-length           pathname-device     translate-pathname     
+host-namestring              pathname-directory  truename               
+make-pathname                pathname-host       user-homedir-pathname  
+merge-pathnames              pathname-match-p    wild-pathname-p        
+
+

Figure 19-1. Pathname Operations

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ac.htm new file mode 100644 index 00000000..2440e2ea --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ac.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.1.3 Parsing Namestrings Into Pathnames

+Parsing is the operation used to convert a namestring into a pathname. Except in the case of parsing logical pathname namestrings, this operation is implementation-dependent, because the format of namestrings is implementation-dependent.

+A conforming implementation is free to accommodate other file system features in its pathname representation and provides a parser that can process such specifications in namestrings. Conforming programs must not depend on any such features, since those features will not be portable.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_b.htm new file mode 100644 index 00000000..041ab2c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_b.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 19.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2 Pathnames

+ + +

+19.2.1 Pathname Components

+ +

+19.2.2 Interpreting Pathname Component Values

+ +

+19.2.3 Merging Pathnames

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ba.htm new file mode 100644 index 00000000..c4812108 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ba.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 19.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1 Pathname Components

+A pathname has six components: a host, a device, a directory, a name, a type, and a version.

+ + +

+19.2.1.1 The Pathname Host Component

+ +

+19.2.1.2 The Pathname Device Component

+ +

+19.2.1.3 The Pathname Directory Component

+ +

+19.2.1.4 The Pathname Name Component

+ +

+19.2.1.5 The Pathname Type Component

+ +

+19.2.1.6 The Pathname Version Component

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baa.htm new file mode 100644 index 00000000..a7f2d452 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1.1 The Pathname Host Component

+The name of the file system on which the file resides, or the name of a logical host.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bab.htm new file mode 100644 index 00000000..d4af2bb3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1.2 The Pathname Device Component

+Corresponds to the ``device'' or ``file structure'' concept in many host file systems: the name of a logical or physical device containing files.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bac.htm new file mode 100644 index 00000000..eeb6fa05 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bac.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1.3 The Pathname Directory Component

+Corresponds to the ``directory'' concept in many host file systems: the name of a group of related files.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bad.htm new file mode 100644 index 00000000..20ee5902 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bad.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1.4 The Pathname Name Component

+The ``name'' part of a group of files that can be thought of as conceptually related.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bae.htm new file mode 100644 index 00000000..a9b21401 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1.5 The Pathname Type Component

+Corresponds to the ``filetype'' or ``extension'' concept in many host file systems. This says what kind of file this is. This component is always a string, nil, :wild, or :unspecific.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baf.htm new file mode 100644 index 00000000..efb54f5c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_baf.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.2.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.1.6 The Pathname Version Component

+Corresponds to the ``version number'' concept in many host file systems.

+The version is either a positive integer or a symbol from the following list: nil, :wild, :unspecific, or :newest (refers to the largest version number that already exists in the file system when reading a file, or to a version number greater than any already existing in the file system when writing a new file). Implementations can define other special version symbols.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bb.htm new file mode 100644 index 00000000..57802745 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bb.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 19.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2 Interpreting Pathname Component Values

+ + +

+19.2.2.1 Strings in Component Values

+ +

+19.2.2.2 Special Pathname Component Values

+ +

+19.2.2.3 Restrictions on Wildcard Pathnames

+ + +

+19.2.2.4 Restrictions on Examining Pathname Components

+ +

+19.2.2.5 Restrictions on Constructing Pathnames

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bba.htm new file mode 100644 index 00000000..fcdf6241 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bba.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 19.2.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.1 Strings in Component Values

+

+ + +

+19.2.2.1.1 Special Characters in Pathname Components

+ + +

+19.2.2.1.2 Case in Pathname Components

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaa.htm new file mode 100644 index 00000000..87f46b42 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaa.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 19.2.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.1.1 Special Characters in Pathname Components

+Strings in pathname component values never contain special characters that represent separation between pathname fields, such as slash in Unix filenames. Whether separator characters are permitted as part of a string in a pathname component is implementation-defined; however, if the implementation does permit it, it must arrange to properly ``quote'' the character for the file system when constructing a namestring. For example,

+

+ ;; In a TOPS-20 implementation, which uses ^V to quote 
+ (NAMESTRING (MAKE-PATHNAME :HOST "OZ" :NAME "<TEST>"))
+=>  #P"OZ:PS:^V<TEST^V>"
+NOT=>  #P"OZ:PS:<TEST>"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbab.htm new file mode 100644 index 00000000..283a3c0c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbab.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 19.2.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.1.2 Case in Pathname Components

+Namestrings always use local file system case conventions, but Common Lisp functions that manipulate pathname components allow the caller to select either of two conventions for representing case in component values by supplying a value for the :case keyword argument. The next figure lists the functions relating to pathnames that permit a :case argument:

+ 

+make-pathname    pathname-directory  pathname-name  
+pathname-device  pathname-host       pathname-type  
+
+

Figure 19-2. Pathname functions using a :CASE argument

+ + +

+19.2.2.1.2.1 Local Case in Pathname Components

+ +

+19.2.2.1.2.2 Common Case in Pathname Components

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaba.htm new file mode 100644 index 00000000..9d9384b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbaba.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.2.2.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.1.2.1 Local Case in Pathname Components

+For the functions in Figure 19-2, a value of :local for the :case argument (the default for these functions) indicates that the functions should receive and yield strings in component values as if they were already represented according to the host file system's convention for case.

+If the file system supports both cases, strings given or received as pathname component values under this protocol are to be used exactly as written. If the file system only supports one case, the strings will be translated to that case.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbabb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbabb.htm new file mode 100644 index 00000000..13514569 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbabb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.2.2.1.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.1.2.2 Common Case in Pathname Components

+For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions:

+

* All uppercase means to use a file system's customary case.
* All lowercase means to use the opposite of the customary case.
* Mixed case represents itself.

Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbb.htm new file mode 100644 index 00000000..46677f1d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbb.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 19.2.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.2 Special Pathname Component Values

+ + +

+19.2.2.2.1 NIL as a Component Value

+ +

+19.2.2.2.2 :WILD as a Component Value

+ + +

+19.2.2.2.3 :UNSPECIFIC as a Component Value

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbba.htm new file mode 100644 index 00000000..6d594159 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbba.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 19.2.2.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.2.1 NIL as a Component Value

+As a pathname component value, nilrepresents that the component is ``unfilled''; see Section 19.2.3 (Merging Pathnames).

+The value of any pathname component can be nil.

+When constructing a pathname, nil in the host component might mean a default host rather than an actual nil in some implementations.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbb.htm new file mode 100644 index 00000000..5513334e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbb.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 19.2.2.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.2.2 :WILD as a Component Value

+If :wild is the value of a pathname component, that component is considered to be a wildcard, which matches anything.

+A conforming program must be prepared to encounter a value of :wild as the value of any pathname component, or as an element of a list that is the value of the directory component.

+ When constructing a pathname, a conforming program may use :wild as the value of any or all of the directory, name, type, or version component, but must not use :wild as the value of the host, or device component.

+If :wild is used as the value of the directory component in the construction of a pathname, the effect is equivalent to specifying the list (:absolute :wild-inferiors), or the same as (:absolute :wild) in a file system that does not support :wild-inferiors.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbc.htm new file mode 100644 index 00000000..7dccbef4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbc.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 19.2.2.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.2.3 :UNSPECIFIC as a Component Value

+If :unspecific is the value of a pathname component, the component is considered to be ``absent'' or to ``have no meaning'' in the filename being represented by the pathname.

+Whether a value of :unspecific is permitted for any component on any given file system accessible to the implementation is implementation-defined. A conforming program must never unconditionally use a :unspecific as the value of a pathname component because such a value is not guaranteed to be permissible in all implementations. However, a conforming program can, if it is careful, successfully manipulate user-supplied data which contains or refers to non-portable pathname components. And certainly a conforming program should be prepared for the possibility that any components of a pathname could be :unspecific.

+ When reading[1] the value of any pathname component, conforming programs should be prepared for the value to be :unspecific.

+ When writing[1] the value of any pathname component, the consequences are undefined if :unspecific is given for a pathname in a file system for which it does not make sense.

+ + +

+19.2.2.2.3.1 Relation between component values NIL and :UNSPECIFIC

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbca.htm new file mode 100644 index 00000000..f067b862 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbbca.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.2.2.2.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.2.3.1 Relation between component values NIL and :UNSPECIFIC

+ If a pathname is converted to a namestring, the symbols nil and :unspecific cause the field to be treated as if it were empty. That is, both nil and :unspecific cause the component not to appear in the namestring.

+However, when merging a pathname with a set of defaults, only a nil value for a component will be replaced with the default for that component, while a value of :unspecific will be left alone as if the field were ``filled''; see the function merge-pathnames and Section 19.2.3 (Merging Pathnames).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbc.htm new file mode 100644 index 00000000..7ea0d9b7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbc.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 19.2.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.3 Restrictions on Wildcard Pathnames

+ Wildcard pathnames can be used with directory but not with open, and return true from wild-pathname-p. When examining wildcard components of a wildcard pathname, conforming programs must be prepared to encounter any of the following additional values in any component or any element of a list that is the directory component:

+

+

* The symbol :wild, which matches anything.

+
* A string containing implementation-dependent special wildcard characters.

+
* Any object, representing an implementation-dependent wildcard pattern.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbd.htm new file mode 100644 index 00000000..a4c42906 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbd.htm @@ -0,0 +1,52 @@ + + + +CLHS: Section 19.2.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4 Restrictions on Examining Pathname Components

+The space of possible objects that a conforming program must be prepared to read[1] as the value of a pathname component is substantially larger than the space of possible objects that a conforming program is permitted to write[1] into such a component.

+While the values discussed in the subsections of this section, in Section 19.2.2.2 (Special Pathname Component Values), and in Section 19.2.2.3 (Restrictions on Wildcard Pathnames) apply to values that might be seen when reading the component values, substantially more restrictive rules apply to constructing pathnames; see Section 19.2.2.5 (Restrictions on Constructing Pathnames).

+When examining pathname components, conforming programs should be aware of the following restrictions.

+ + +

+19.2.2.4.1 Restrictions on Examining a Pathname Host Component

+ +

+19.2.2.4.2 Restrictions on Examining a Pathname Device Component

+ +

+19.2.2.4.3 Restrictions on Examining a Pathname Directory Component

+ +

+19.2.2.4.4 Restrictions on Examining a Pathname Name Component

+ +

+19.2.2.4.5 Restrictions on Examining a Pathname Type Component

+ +

+19.2.2.4.6 Restrictions on Examining a Pathname Version Component

+ +

+19.2.2.4.7 Notes about the Pathname Version Component

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbda.htm new file mode 100644 index 00000000..1db236f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbda.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.2.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.1 Restrictions on Examining a Pathname Host Component

+It is implementation-dependent what object is used to represent the host.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdb.htm new file mode 100644 index 00000000..10e34764 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.2.2.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.2 Restrictions on Examining a Pathname Device Component

+The device might be a string, :wild, :unspecific, or nil.

+Note that :wild might result from an attempt to read[1] the pathname component, even though portable programs are restricted from writing[1] such a component value; see Section 19.2.2.3 (Restrictions on Wildcard Pathnames) and Section 19.2.2.5 (Restrictions on Constructing Pathnames).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdc.htm new file mode 100644 index 00000000..b6ed00cd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdc.htm @@ -0,0 +1,59 @@ + + + +CLHS: Section 19.2.2.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.3 Restrictions on Examining a Pathname Directory Component

+The directory might be a string, :wild, :unspecific, or nil.

+The directory can be a list of strings and symbols. The car of the list is one of the symbols :absolute or :relative, meaning:

+

+

:absolute

+ A list whose car is the symbol :absolute represents a directory path starting from the root directory. The list (:absolute) represents the root directory. The list (:absolute "foo" "bar" "baz") represents the directory called "/foo/bar/baz" in Unix (except possibly for case).

+

:relative

+ A list whose car is the symbol :relative represents a directory path starting from a default directory. The list (:relative) has the same meaning as nil and hence is not used. The list (:relative "foo" "bar") represents the directory named "bar" in the directory named "foo" in the default directory.

+

+Each remaining element of the list is a string or a symbol.

+Each string names a single level of directory structure. The strings should contain only the directory names themselves---no punctuation characters.

+In place of a string, at any point in the list, symbols can occur to indicate special file notations. The next figure lists the symbols that have standard meanings. Implementations are permitted to add additional objects of any type that is disjoint from string if necessary to represent features of their file systems that cannot be represented with the standard strings and symbols.

+Supplying any non-string, including any of the symbols listed below, to a file system for which it does not make sense signals an error of type file-error. For example, Unix does not support :wild-inferiors in most implementations.

+

+Symbol           Meaning                                             
+:wild            Wildcard match of one level of directory structure  
+:wild-inferiors  Wildcard match of any number of directory levels    
+:up              Go upward in directory structure (semantic)         
+:back            Go upward in directory structure (syntactic)        
+
+

Figure 19-3. Special Markers In Directory Component

+The following notes apply to the previous figure:

+

Invalid Combinations

+Using :absolute or :wild-inferiors immediately followed by :up or :back signals an error of type file-error.

+

Syntactic vs Semantic

+``Syntactic'' means that the action of :back depends only on the pathname and not on the contents of the file system.

+``Semantic'' means that the action of :up depends on the contents of the file system; to resolve a pathname containing :up to a pathname whose directory component contains only :absolute and strings requires probing the file system.

+:up differs from :back only in file systems that support multiple names for directories, perhaps via symbolic links. For example, suppose that there is a directory (:absolute "X" "Y" "Z") linked to (:absolute "A" "B" "C") and there also exist directories (:absolute "A" "B" "Q") and (:absolute "X" "Y" "Q"). Then (:absolute "X" "Y" "Z" :up "Q") designates (:absolute "A" "B" "Q") while (:absolute "X" "Y" "Z" :back "Q") designates (:absolute "X" "Y" "Q")

+

+ + +

+19.2.2.4.3.1 Directory Components in Non-Hierarchical File Systems

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdca.htm new file mode 100644 index 00000000..a54ae9c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdca.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.2.4.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.3.1 Directory Components in Non-Hierarchical File Systems

+In non-hierarchical file systems, the only valid list values for the directory component of a pathname are (:absolute string) and (:absolute :wild). :relative directories and the keywords :wild-inferiors, :up, and :back are not used in non-hierarchical file systems.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdd.htm new file mode 100644 index 00000000..cef1233e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.2.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.4 Restrictions on Examining a Pathname Name Component

+The name might be a string, :wild, :unspecific, or nil.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbde.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbde.htm new file mode 100644 index 00000000..0b802ade --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbde.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.2.2.4.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.5 Restrictions on Examining a Pathname Type Component

+The type might be a string, :wild, :unspecific, or nil.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdf.htm new file mode 100644 index 00000000..5b013732 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdf.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 19.2.2.4.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.6 Restrictions on Examining a Pathname Version Component

+The version can be any symbol or any integer.

+The symbol :newest refers to the largest version number that already exists in the file system when reading, overwriting, appending, superseding, or directory listing an existing file. The symbol :newest refers to the smallest version number greater than any existing version number when creating a new file.

+The symbols nil, :unspecific, and :wild have special meanings and restrictions; see Section 19.2.2.2 (Special Pathname Component Values) and Section 19.2.2.5 (Restrictions on Constructing Pathnames).

+Other symbols and integers have implementation-defined meaning.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdg.htm new file mode 100644 index 00000000..70e30403 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbdg.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 19.2.2.4.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.4.7 Notes about the Pathname Version Component

+It is suggested, but not required, that implementations do the following:

+

+

* Use positive integers starting at 1 as version numbers.

+
* Recognize the symbol :oldest to designate the smallest existing version number.

+
* Use keywords for other special versions.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbe.htm new file mode 100644 index 00000000..19691f77 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bbe.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 19.2.2.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.2.5 Restrictions on Constructing Pathnames

+ When constructing a pathname from components, conforming programs must follow these rules:

+

+

* Any component can be nil. nil in the host might mean a default host rather than an actual nil in some implementations.

+
* The host, device, directory, name, and type can be strings. There are implementation-dependent limits on the number and type of characters in these strings.

+
* The directory can be a list of strings and symbols. There are implementation-dependent limits on the list's length and contents.

+
* The version can be :newest.

+
* Any component can be taken from the corresponding component of another pathname. When the two pathnames are for different file systems (in implementations that support multiple file systems), an appropriate translation occurs. If no meaningful translation is possible, an error is signaled. The definitions of ``appropriate'' and ``meaningful'' are implementation-dependent.

+
* An implementation might support other values for some components, but a portable program cannot use those values. A conforming program can use implementation-dependent values but this can make it non-portable; for example, it might work only with Unix file systems.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bc.htm new file mode 100644 index 00000000..93d1c7cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bc.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 19.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.3 Merging Pathnames

+Merging takes a pathname with unfilled components and supplies values for those components from a source of defaults.

+If a component's value is nil, that component is considered to be unfilled. If a component's value is any non-nil object, including :unspecific, that component is considered to be filled.

+Except as explicitly specified otherwise, for functions that manipulate or inquire about files in the file system, the pathname argument to such a function is merged with *default-pathname-defaults* before accessing the file system (as if by merge-pathnames).

+ + +

+19.2.3.1 Examples of Merging Pathnames

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bca.htm new file mode 100644 index 00000000..312ccbbb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_bca.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 19.2.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.2.3.1 Examples of Merging Pathnames

+Although the following examples are possible to execute only in implementations which permit :unspecific in the indicated position andwhich permit four-letter type components, they serve to illustrate the basic concept of pathname merging.

+

+ (pathname-type 
+   (merge-pathnames (make-pathname :type "LISP")
+                    (make-pathname :type "TEXT")))
+=>  "LISP"
+
+ (pathname-type 
+   (merge-pathnames (make-pathname :type nil)
+                    (make-pathname :type "LISP")))
+=>  "LISP"
+
+ (pathname-type 
+   (merge-pathnames (make-pathname :type :unspecific)
+                    (make-pathname :type "LISP")))
+=>  :UNSPECIFIC
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_c.htm new file mode 100644 index 00000000..aad58b90 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_c.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 19.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3 Logical Pathnames

+ + +

+19.3.1 Syntax of Logical Pathname Namestrings

+ +

+19.3.2 Logical Pathname Components

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ca.htm new file mode 100644 index 00000000..e483b9ab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_ca.htm @@ -0,0 +1,66 @@ + + + +CLHS: Section 19.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1 Syntax of Logical Pathname Namestrings

+ The syntax of a logical pathname namestring is as follows. (Note that unlike many notational descriptions in this document, this is a syntactic description of character sequences, not a structural description of objects.)

+

+logical-pathname::= [host host-marker]  
+                    [relative-directory-marker] {directory directory-marker}*  
+                    [name] [type-marker type [version-marker version]] 
+
+

+

+host::= word 
+
+ 
+directory::= word | wildcard-word | wild-inferiors-word 
+
+ 
+name::= word | wildcard-word 
+
+ 
+type::= word | wildcard-word 
+
+ 
+version::= pos-int | newest-word | wildcard-version 
+
+

+host-marker---a colon.

+relative-directory-marker---a semicolon.

+directory-marker---a semicolon.

+type-marker---a dot.

+version-marker---a dot.

+wild-inferiors-word---The two character sequence ``**'' (two asterisks).

+newest-word---The six character sequence ``newest'' or the six character sequence ``NEWEST''.

+wildcard-version---an asterisk.

+wildcard-word---one or more asterisks, uppercase letters, digits, and hyphens, including at least one asterisk, with no two asterisks adjacent.

+word---one or more uppercase letters, digits, and hyphens.

+pos-int---a positive integer.

+ + +

+19.3.1.1 Additional Information about Parsing Logical Pathname Namestrings

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caa.htm new file mode 100644 index 00000000..1191fdb9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caa.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 19.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1 Additional Information about Parsing Logical Pathname Namestrings

+ + +

+19.3.1.1.1 The Host part of a Logical Pathname Namestring

+ +

+19.3.1.1.2 The Device part of a Logical Pathname Namestring

+ +

+19.3.1.1.3 The Directory part of a Logical Pathname Namestring

+ +

+19.3.1.1.4 The Type part of a Logical Pathname Namestring

+ +

+19.3.1.1.5 The Version part of a Logical Pathname Namestring

+ +

+19.3.1.1.6 Wildcard Words in a Logical Pathname Namestring

+ +

+19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring

+ +

+19.3.1.1.8 Other Syntax in a Logical Pathname Namestring

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaa.htm new file mode 100644 index 00000000..61e13a60 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.3.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.1 The Host part of a Logical Pathname Namestring

+The host must have been defined as a logical pathname host; this can be done by using setf of logical-pathname-translations.

+The logical pathname host name "SYS" is reserved for the implementation. The existence and meaning of SYS: logical pathnames is implementation-defined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caab.htm new file mode 100644 index 00000000..7bf6b1fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.3.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.2 The Device part of a Logical Pathname Namestring

+There is no syntax for a logical pathname device since the device component of a logical pathname is always :unspecific; see Section 19.3.2.1 (Unspecific Components of a Logical Pathname).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caac.htm new file mode 100644 index 00000000..6ac7c824 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caac.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.3.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.3 The Directory part of a Logical Pathname Namestring

+If a relative-directory-marker precedes the directories, the directory component parsed is as relative; otherwise, the directory component is parsed as absolute.

+If a wild-inferiors-marker is specified, it parses into :wild-inferiors.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caad.htm new file mode 100644 index 00000000..3c942698 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caad.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.3.1.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.4 The Type part of a Logical Pathname Namestring

+The type of a logical pathname for a source file is "LISP". This should be translated into whatever type is appropriate in a physical pathname.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caae.htm new file mode 100644 index 00000000..f29c4e3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caae.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.3.1.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.5 The Version part of a Logical Pathname Namestring

+Some file systems do not have versions. Logical pathname translation to such a file system ignores the version. This implies that a program cannot rely on being able to store more than one version of a file named by a logical pathname.

+If a wildcard-version is specified, it parses into :wild.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaf.htm new file mode 100644 index 00000000..c5cd8e3e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caaf.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.3.1.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.6 Wildcard Words in a Logical Pathname Namestring

+Each asterisk in a wildcard-word matches a sequence of zero or more characters. The wildcard-word ``*'' parses into :wild; other wildcard-words parse into strings.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caag.htm new file mode 100644 index 00000000..5103f407 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caag.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.3.1.1.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring

+When parsing words and wildcard-words, lowercase letters are translated to uppercase.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caah.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caah.htm new file mode 100644 index 00000000..76670d48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_caah.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 19.3.1.1.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.1.1.8 Other Syntax in a Logical Pathname Namestring

+The consequences of using characters other than those specified here in a logical pathname namestring are unspecified.

+The consequences of using any value not specified here as a logical pathname component are unspecified.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cb.htm new file mode 100644 index 00000000..e49dcf50 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cb.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 19.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.2 Logical Pathname Components

+ + +

+19.3.2.1 Unspecific Components of a Logical Pathname

+ +

+19.3.2.2 Null Strings as Components of a Logical Pathname

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cba.htm new file mode 100644 index 00000000..5ed9004b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cba.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.3.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.2.1 Unspecific Components of a Logical Pathname

+The device component of a logical pathname is always :unspecific; no other component of a logical pathname can be :unspecific.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cbb.htm new file mode 100644 index 00000000..3db54f5b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/19_cbb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 19.3.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.3.2.2 Null Strings as Components of a Logical Pathname

+The null string, "", is not a valid value for any component of a logical pathname.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_.htm new file mode 100644 index 00000000..e2b14052 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 20 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+20. Files

+

+ + +

+20.1 File System Concepts

+ +

+20.2 The Files Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_a.htm new file mode 100644 index 00000000..e29977cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_a.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 20.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+20.1 File System Concepts

+This section describes the Common Lisp interface to file systems. The model used by this interface assumes that files are named by filenames, that a filename can be represented by a pathname object, and that given a pathname a stream can be constructed that connects to a file whose filename it represents.

+For information about opening and closing files, and manipulating their contents, see Section 21 (Streams).

+The next figure lists some operators that are applicable to files and directories.

+

+compile-file  file-length      open            
+delete-file   file-position    probe-file      
+directory     file-write-date  rename-file     
+file-author   load             with-open-file  
+
+

Figure 20-1. File and Directory Operations

+ + +

+20.1.1 Coercion of Streams to Pathnames

+ +

+20.1.2 File Operations on Open and Closed Streams

+ +

+20.1.3 Truenames

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aa.htm new file mode 100644 index 00000000..996c846f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 20.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+20.1.1 Coercion of Streams to Pathnames

+A stream associated with a file is either a file stream or a synonym stream whose target is a stream associated with a file. Such streams can be used as pathname designators.

+Normally, when a stream associated with a file is used as a pathname designator, it denotes the pathname used to open the file; this may be, but is not required to be, the actual name of the file.

+Some functions, such as truename and delete-file, coerce streams to pathnames in a different way that involves referring to the actual file that is open, which might or might not be the file whose name was opened originally. Such special situations are always notated specifically and are not the default.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ab.htm new file mode 100644 index 00000000..da97fa76 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ab.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 20.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+20.1.2 File Operations on Open and Closed Streams

+

+Many functions that perform file operations accept either open or closed streams as arguments; see Section 21.1.3 (Stream Arguments to Standardized Functions).

+Of these, the functions in the next figure treat open and closed streams differently.

+

+delete-file  file-author      probe-file  
+directory    file-write-date  truename    
+
+

Figure 20-2. File Functions that Treat Open and Closed Streams Differently

+Since treatment of open streams by the file system may vary considerably between implementations, however, a closed stream might be the most reliable kind of argument for some of these functions---in particular, those in the next figure. For example, in some file systems, open files are written under temporary names and not renamed until closed and/or are held invisible until closed. In general, any code that is intended to be portable should use such functions carefully.

+

+directory  probe-file  truename  
+
+

Figure 20-3. File Functions where Closed Streams Might Work Best

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ac.htm new file mode 100644 index 00000000..25a322f8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_ac.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 20.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+20.1.3 Truenames

+Many file systems permit more than one filename to designate a particular file.

+Even where multiple names are possible, most file systems have a convention for generating a canonical filename in such situations. Such a canonical filename (or the pathname representing such a filename) is called a truename.

+The truename of a file may differ from other filenames for the file because of symbolic links, version numbers, logical device translations in the file system, logical pathname translations within Common Lisp, or other artifacts of the file system.

+The truename for a file is often, but not necessarily, unique for each file. For instance, a Unix file with multiple hard links could have several truenames.

+ + +

+20.1.3.1 Examples of Truenames

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aca.htm new file mode 100644 index 00000000..4d1f7442 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/20_aca.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 20.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+20.1.3.1 Examples of Truenames

+For example, a DEC TOPS-20 system with files PS:<JOE>FOO.TXT.1 and PS:<JOE>FOO.TXT.2 might permit the second file to be referred to as PS:<JOE>FOO.TXT.0, since the ``.0'' notation denotes ``newest'' version of several files. In the same file system, a ``logical device'' ``JOE:'' might be taken to refer to PS:<JOE>'' and so the names JOE:FOO.TXT.2 or JOE:FOO.TXT.0 might refer to PS:<JOE>FOO.TXT.2. In all of these cases, the truename of the file would probably be PS:<JOE>FOO.TXT.2.

+If a file is a symbolic link to another file (in a file system permitting such a thing), it is conventional for the truename to be the canonical name of the file after any symbolic links have been followed; that is, it is the canonical name of the file whose contents would become available if an input stream to that file were opened.

+In the case of a file still being created (that is, of an output stream open to such a file), the exact truename of the file might not be known until the stream is closed. In this case, the function truename might return different values for such a stream before and after it was closed. In fact, before it is closed, the name returned might not even be a valid name in the file system---for example, while a file is being written, it might have version :newest and might only take on a specific numeric value later when the file is closed even in a file system where all files have numeric versions.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_.htm new file mode 100644 index 00000000..0e0fe51e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 21 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+21. Streams

+

+ + +

+21.1 Stream Concepts

+ +

+21.2 The Streams Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_a.htm new file mode 100644 index 00000000..b4e8ad0f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_a.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 21.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1 Stream Concepts

+ + +

+21.1.1 Introduction to Streams

+ +

+21.1.2 Stream Variables

+ +

+21.1.3 Stream Arguments to Standardized Functions

+ +

+21.1.4 Restrictions on Composite Streams

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aa.htm new file mode 100644 index 00000000..abec93a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aa.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 21.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1 Introduction to Streams

+A stream is an object that can be used with an input or output function to identify an appropriate source or sink of characters or bytes for that operation. A character stream is a source or sink of characters. A binary stream is a source or sink of bytes.

+Some operations may be performed on any kind of stream; the next figure provides a list of standardized operations that are potentially useful with any kind of stream.

+

+close                 stream-element-type  
+input-stream-p        streamp              
+interactive-stream-p  with-open-stream     
+output-stream-p                            
+
+

Figure 21-1. Some General-Purpose Stream Operations

+Other operations are only meaningful on certain stream types. For example, read-char is only defined for character streams and read-byte is only defined for binary streams.

+ + +

+21.1.1.1 Abstract Classifications of Streams

+ +

+21.1.1.2 Abstract Classifications of Streams

+ +

+21.1.1.3 Other Subclasses of Stream

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaa.htm new file mode 100644 index 00000000..c4ae3e5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaa.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 21.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.1 Abstract Classifications of Streams

+ + +

+21.1.1.1.1 Input, Output, and Bidirectional Streams

+ +

+21.1.1.1.2 Open and Closed Streams

+ +

+21.1.1.1.3 Interactive Streams

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaaa.htm new file mode 100644 index 00000000..4548c12b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaaa.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 21.1.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.1.1 Input, Output, and Bidirectional Streams

+A stream, whether a character stream or a binary stream, can be an input stream (source of data), an output stream (sink for data), both, or (e.g., when ``:direction :probe'' is given to open) neither.

+The next figure shows operators relating to input streams.

+ 

+clear-input  read-byte            read-from-string            
+listen       read-char            read-line                   
+peek-char    read-char-no-hang    read-preserving-whitespace  
+read         read-delimited-list  unread-char                 
+
+

Figure 21-2. Operators relating to Input Streams.

+The next figure shows operators relating to output streams.

+ 

+clear-output   prin1            write            
+finish-output  prin1-to-string  write-byte       
+force-output   princ            write-char       
+format         princ-to-string  write-line       
+fresh-line     print            write-string     
+pprint         terpri           write-to-string  
+
+

Figure 21-3. Operators relating to Output Streams.

+A stream that is both an input stream and an output stream is called a bidirectional stream. See the functions input-stream-p and output-stream-p.

+Any of the operators listed in Figure 21-2 or Figure 21-3 an be used with bidirectional streams. In addition, the next figure hows a list of operators that relate specificaly to bidirectional streams.

+

+y-or-n-p  yes-or-no-p    
+
+

Figure 21-4. Operators relating to Bidirectional Streams.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaab.htm new file mode 100644 index 00000000..8c8b06c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaab.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 21.1.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.1.2 Open and Closed Streams

+Streams are either open or closed.

+Except as explicitly specified otherwise, operations that create and return streams return open streams.

+The action of closing a stream marks the end of its use as a source or sink of data, permitting the implementation to reclaim its internal data structures, and to free any external resources which might have been locked by the stream when it was opened.

+Except as explicitly specified otherwise, the consequences are undefined when a closed stream is used where a stream is called for.

+Coercion of streams to pathnames is permissible for closed streams; in some situations, such as for a truename computation, the result might be different for an open stream and for that same stream once it has been closed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaac.htm new file mode 100644 index 00000000..98c56a39 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaac.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 21.1.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.1.3 Interactive Streams

+An interactive stream is one on which it makes sense to perform interactive querying.

+The precise meaning of an interactive stream is implementation-defined, and may depend on the underlying operating system. Some examples of the things that an implementation might choose to use as identifying characteristics of an interactive stream include:

+

+

* The stream is connected to a person (or equivalent) in such a way that the program can prompt for information and expect to receive different input depending on the prompt.

+
* The program is expected to prompt for input and support ``normal input editing''.

+
* read-char might wait for the user to type something before returning instead of immediately returning a character or end-of-file.

+

+The general intent of having some streams be classified as interactive streams is to allow them to be distinguished from streams containing batch (or background or command-file) input. Output to batch streams is typically discarded or saved for later viewing, so interactive queries to such streams might not have the expected effect.

+Terminal I/O might or might not be an interactive stream.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aab.htm new file mode 100644 index 00000000..40470d90 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aab.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 21.1.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.2 Abstract Classifications of Streams

+ + +

+21.1.1.2.1 File Streams

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaba.htm new file mode 100644 index 00000000..dbab761d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aaba.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 21.1.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.2.1 File Streams

+Some streams, called file streams, provide access to files. An object of class file-stream is used to represent a file stream.

+The basic operation for opening a file is open, which typically returns a file stream (see its dictionary entry for details). The basic operation for closing a stream is close. The macro with-open-file is useful to express the common idiom of opening a file for the duration of a given body of code, and assuring that the resulting stream is closed upon exit from that body.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aac.htm new file mode 100644 index 00000000..5bd6d4aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_aac.htm @@ -0,0 +1,50 @@ + + + +CLHS: Section 21.1.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.1.3 Other Subclasses of Stream

+The class stream has a number of subclasses defined by this specification. The next figure shows some information about these subclasses.

+

+Class                Related Operators             
+broadcast-stream     make-broadcast-stream         
+                     broadcast-stream-streams      
+concatenated-stream  make-concatenated-stream      
+                     concatenated-stream-streams   
+echo-stream          make-echo-stream              
+                     echo-stream-input-stream      
+                     echo-stream-output-stream     
+string-stream        make-string-input-stream      
+                     with-input-from-string        
+                     make-string-output-stream     
+                     with-output-to-string         
+                     get-output-stream-string      
+synonym-stream       make-synonym-stream           
+                     synonym-stream-symbol         
+two-way-stream       make-two-way-stream           
+                     two-way-stream-input-stream   
+                     two-way-stream-output-stream  
+
+

Figure 21-5. Defined Names related to Specialized Streams

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ab.htm new file mode 100644 index 00000000..bf33dc82 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ab.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 21.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.2 Stream Variables

+Variables whose values must be streams are sometimes called stream variables.

+Certain stream variables are defined by this specification to be the proper source of input or output in various situations where no specific stream has been specified instead. A complete list of such standardized stream variables appears in the next figure. The consequences are undefined if at any time the value of any of these variables is not an open stream.

+ 

+Glossary Term    Variable Name      
+debug I/O        *debug-io*         
+error output     *error-output*     
+query I/O        *query-io*         
+standard input   *standard-input*   
+standard output  *standard-output*  
+terminal I/O     *terminal-io*      
+trace output     *trace-output*     
+
+

Figure 21-6. Standardized Stream Variables

+Note that, by convention, standardized stream variables have names ending in ``-input*'' if they must be input streams, ending in ``-output*'' if they must be output streams, or ending in ``-io*'' if they must be bidirectional streams.

+User programs may assign or bind any standardized stream variable except *terminal-io*.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ac.htm new file mode 100644 index 00000000..714e7587 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ac.htm @@ -0,0 +1,67 @@ + + + +CLHS: Section 21.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.3 Stream Arguments to Standardized Functions

+The operators in the next figure accept stream arguments that might be either open or closed streams.

+ 

+broadcast-stream-streams     file-author       pathnamep                     
+close                        file-namestring   probe-file                    
+compile-file                 file-write-date   rename-file                   
+compile-file-pathname        host-namestring   streamp                       
+concatenated-stream-streams  load              synonym-stream-symbol         
+delete-file                  logical-pathname  translate-logical-pathname    
+directory                    merge-pathnames   translate-pathname            
+directory-namestring         namestring        truename                      
+dribble                      open              two-way-stream-input-stream   
+echo-stream-input-stream     open-stream-p     two-way-stream-output-stream  
+echo-stream-ouput-stream     parse-namestring  wild-pathname-p               
+ed                           pathname          with-open-file                
+enough-namestring            pathname-match-p                                
+
+

Figure 21-7. Operators that accept either Open or Closed Streams

+The operators in the next figure accept stream arguments that must be open streams.

+

+clear-input               output-stream-p          read-char-no-hang           
+clear-output              peek-char                read-delimited-list         
+file-length               pprint                   read-line                   
+file-position             pprint-fill              read-preserving-whitespace  
+file-string-length        pprint-indent            stream-element-type         
+finish-output             pprint-linear            stream-external-format      
+force-output              pprint-logical-block     terpri                      
+format                    pprint-newline           unread-char                 
+fresh-line                pprint-tab               with-open-stream            
+get-output-stream-string  pprint-tabular           write                       
+input-stream-p            prin1                    write-byte                  
+interactive-stream-p      princ                    write-char                  
+listen                    print                    write-line                  
+make-broadcast-stream     print-object             write-string                
+make-concatenated-stream  print-unreadable-object  y-or-n-p                    
+make-echo-stream          read                     yes-or-no-p                 
+make-synonym-stream       read-byte                                            
+make-two-way-stream       read-char                                            
+
+

Figure 21-8. Operators that accept Open Streams only

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ad.htm new file mode 100644 index 00000000..9501effd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/21_ad.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 21.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.1.4 Restrictions on Composite Streams

+The consequences are undefined if any component of a composite stream is closed before the composite stream is closed.

+The consequences are undefined if the synonym stream symbol is not bound to an open stream from the time of the synonym stream's creation until the time it is closed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_.htm new file mode 100644 index 00000000..d28b9b40 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_.htm @@ -0,0 +1,45 @@ + + + +CLHS: Chapter 22 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+22. Printer

+

+ + +

+22.1 The Lisp Printer

+ +

+22.2 The Lisp Pretty Printer

+ +

+22.3 Formatted Output

+ +

+22.4 The Printer Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_a.htm new file mode 100644 index 00000000..9f44bb9b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_a.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 22.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1 The Lisp Printer

+ + +

+22.1.1 Overview of The Lisp Printer

+ +

+22.1.2 Printer Dispatching

+ +

+22.1.3 Default Print-Object Methods

+ + +

+22.1.4 Examples of Printer Behavior

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aa.htm new file mode 100644 index 00000000..c341ab00 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aa.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 22.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.1 Overview of The Lisp Printer

+Common Lisp provides a representation of most objects in the form of printed text called the printed representation. Functions such as print take an object and send the characters of its printed representation to a stream. The collection of routines that does this is known as the (Common Lisp) printer.

+Reading a printed representation typically produces an object that is equal to the originally printed object.

+ + +

+22.1.1.1 Multiple Possible Textual Representations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaa.htm new file mode 100644 index 00000000..4ad280e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaa.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section 22.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.1.1 Multiple Possible Textual Representations

+Most objects have more than one possible textual representation. For example, the positive integer with a magnitude of twenty-seven can be textually expressed in any of these ways:

+

+ 27    27.    #o33    #x1B    #b11011    #.(* 3 3 3)    81/3
+
+

+A list containing the two symbols A and B can also be textually expressed in a variety of ways:

+

+ (A B)    (a b)    (  a  b )    (\A |B|) 
+(|\A|
+  B
+)
+
+

+In general, from the point of view of the Lisp reader, wherever whitespace is permissible in a textual representation, any number of spaces and newlines can appear in standard syntax.

+When a function such as print produces a printed representation, it must choose from among many possible textual representations. In most cases, it chooses a program readable representation, but in certain cases it might use a more compact notation that is not program-readable.

+A number of option variables, called printer control variables, are provided to permit control of individual aspects of the printed representation of objects. The next figure shows the standardized printer control variables; there might also be implementation-defined printer control variables.

+ 

+*print-array*   *print-gensym*       *print-pprint-dispatch*  
+*print-base*    *print-length*       *print-pretty*           
+*print-case*    *print-level*        *print-radix*            
+*print-circle*  *print-lines*        *print-readably*         
+*print-escape*  *print-miser-width*  *print-right-margin*     
+
+

Figure 22-1. Standardized Printer Control Variables

+In addition to the printer control variables, the following additional defined names relate to or affect the behavior of the Lisp printer:

+

+*package*                    *read-eval*  readtable-case  
+*read-default-float-format*  *readtable*                  
+
+

Figure 22-2. Additional Influences on the Lisp printer.

+ + +

+22.1.1.1.1 Printer Escaping

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaaa.htm new file mode 100644 index 00000000..3cf86fbc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aaaa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 22.1.1.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.1.1.1 Printer Escaping

+The variable *print-escape* controls whether the Lisp printer tries to produce notations such as escape characters and package prefixes.

+The variable *print-readably* can be used to override many of the individual aspects controlled by the other printer control variables when program-readable output is especially important.

+ One of the many effects of making the value of *print-readably* be true is that the Lisp printer behaves as if *print-escape* were also true. For notational convenience, we say that if the value of either *print-readably* or *print-escape* is true, then printer escaping is ``enabled''; and we say that if the values of both *print-readably* and *print-escape* are false, then printer escaping is ``disabled''.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ab.htm new file mode 100644 index 00000000..3090a4aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ab.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 22.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.2 Printer Dispatching

+

+The Lisp printer makes its determination of how to print an object as follows:

+If the value of *print-pretty* is true, printing is controlled by the current pprint dispatch table; see Section 22.2.1.4 (Pretty Print Dispatch Tables).

+Otherwise (if the value of *print-pretty* is false), the object's print-object method is used; see Section 22.1.3 (Default Print-Object Methods).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ac.htm new file mode 100644 index 00000000..6bc612f4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ac.htm @@ -0,0 +1,65 @@ + + + +CLHS: Section 22.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3 Default Print-Object Methods

+This section describes the default behavior of print-object methods for the standardized types.

+ + +

+22.1.3.1 Printing Numbers

+ +

+22.1.3.2 Printing Characters

+ +

+22.1.3.3 Printing Symbols

+ +

+22.1.3.4 Printing Strings

+ +

+22.1.3.5 Printing Lists and Conses

+ +

+22.1.3.6 Printing Bit Vectors

+ +

+22.1.3.7 Printing Other Vectors

+ +

+22.1.3.8 Printing Other Arrays

+ +

+22.1.3.10 Printing Random States

+ +

+22.1.3.11 Printing Pathnames

+ +

+22.1.3.12 Printing Structures

+ +

+22.1.3.13 Printing Other Objects

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aca.htm new file mode 100644 index 00000000..3e32c299 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aca.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 22.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.1 Printing Numbers

+ + +

+22.1.3.1.1 Printing Integers

+ +

+22.1.3.1.2 Printing Ratios

+ +

+22.1.3.1.3 Printing Floats

+ +

+22.1.3.1.4 Printing Complexes

+ +

+22.1.3.1.5 Note about Printing Numbers

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acaa.htm new file mode 100644 index 00000000..5c1e9450 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acaa.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.1.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.1.1 Printing Integers

+Integers are printed in the radix specified by the current output base in positional notation, most significant digit first. If appropriate, a radix specifier can be printed; see *print-radix*. If an integer is negative, a minus sign is printed and then the absolute value of the integer is printed. The integer zero is represented by the single digit 0 and never has a sign. A decimal point might be printed, depending on the value of *print-radix*.

+For related information about the syntax of an integer, see Section 2.3.2.1.1 (Syntax of an Integer).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acab.htm new file mode 100644 index 00000000..f27a17a9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acab.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.1.3.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.1.2 Printing Ratios

+Ratios are printed as follows: the absolute value of the numerator is printed, as for an integer; then a /; then the denominator. The numerator and denominator are both printed in the radix specified by the current output base; they are obtained as if by numerator and denominator, and so ratios are printed in reduced form (lowest terms). If appropriate, a radix specifier can be printed; see *print-radix*. If the ratio is negative, a minus sign is printed before the numerator.

+For related information about the syntax of a ratio, see Section 2.3.2.1.2 (Syntax of a Ratio).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acac.htm new file mode 100644 index 00000000..316ebda6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acac.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 22.1.3.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.1.3 Printing Floats

+If the magnitude of the float is either zero or between 10^-3 (inclusive) and 10^7 (exclusive), it is printed as the integer part of the number, then a decimal point, followed by the fractional part of the number; there is always at least one digit on each side of the decimal point. If the sign of the number (as determined by float-sign) is negative, then a minus sign is printed before the number. If the format of the number does not match that specified by *read-default-float-format*, then the exponent marker for that format and the digit 0 are also printed. For example, the base of the natural logarithms as a short float might be printed as 2.71828S0.

+For non-zero magnitudes outside of the range 10^-3 to 10^7, a float is printed in computerized scientific notation. The representation of the number is scaled to be between 1 (inclusive) and 10 (exclusive) and then printed, with one digit before the decimal point and at least one digit after the decimal point. Next the exponent marker for the format is printed, except that if the format of the number matches that specified by *read-default-float-format*, then the exponent marker E is used. Finally, the power of ten by which the fraction must be multiplied to equal the original number is printed as a decimal integer. For example, Avogadro's number as a short float is printed as 6.02S23.

+For related information about the syntax of a float, see Section 2.3.2.2 (Syntax of a Float).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acad.htm new file mode 100644 index 00000000..5a95143e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acad.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.1.3.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.1.4 Printing Complexes

+A complex is printed as #C, an open parenthesis, the printed representation of its real part, a space, the printed representation of its imaginary part, and finally a close parenthesis.

+For related information about the syntax of a complex, see Section 2.3.2.3 (Syntax of a Complex) and Section 2.4.8.11 (Sharpsign C).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acae.htm new file mode 100644 index 00000000..779b9375 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.1.3.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.1.5 Note about Printing Numbers

+The printed representation of a number must not contain escape characters; see Section 2.3.1.1.1 (Escape Characters and Potential Numbers).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acb.htm new file mode 100644 index 00000000..f994ae87 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acb.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 22.1.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.2 Printing Characters

+ When printer escaping is disabled, a character prints as itself; it is sent directly to the output stream. When printer escaping is enabled, then #\ syntax is used.

+When the printer types out the name of a character, it uses the same table as the #\ reader macro would use; therefore any character name that is typed out is acceptable as input (in that implementation). If a non-graphic character has a standardized name[5], that name is preferred over non-standard names for printing in #\ notation. For the graphic standard characters, the character itself is always used for printing in #\ notation---even if the character also has a name[5].

+For details about the #\ reader macro, see Section 2.4.8.1 (Sharpsign Backslash).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acc.htm new file mode 100644 index 00000000..8c9d9a6d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acc.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 22.1.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.3 Printing Symbols

+ When printer escaping is disabled, only the characters of the symbol's name are output (but the case in which to print characters in the name is controlled by *print-case*; see Section 22.1.3.3.2 (Effect of Readtable Case on the Lisp Printer)).

+The remainder of Section 22.1.3.3 applies only when printer escaping is enabled.

+ When printing a symbol, the printer inserts enough single escape and/or multiple escape characters (backslashes and/or vertical-bars) so that if read were called with the same *readtable* and with *read-base* bound to the current output base, it would return the same symbol (if it is not apparently uninterned) or an uninterned symbol with the same print name (otherwise).

+For example, if the value of *print-base* were 16 when printing the symbol face, it would have to be printed as \FACE or \Face or |FACE|, because the token face would be read as a hexadecimal number (decimal value 64206) if the value of *read-base* were 16.

+For additional restrictions concerning characters with nonstandard syntax types in the current readtable, see the variable *print-readably*

+For information about how the Lisp reader parses symbols, see Section 2.3.4 (Symbols as Tokens) and Section 2.4.8.5 (Sharpsign Colon).

+nil might be printed as () when *print-pretty* is true and printer escaping is enabled.

+ + +

+22.1.3.3.1 Package Prefixes for Symbols

+ +

+22.1.3.3.2 Effect of Readtable Case on the Lisp Printer

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acca.htm new file mode 100644 index 00000000..3250e753 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acca.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 22.1.3.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.3.1 Package Prefixes for Symbols

+Package prefixes are printed if necessary. The rules for package prefixes are as follows. When the symbol is printed, if it is in the KEYWORD package, then it is printed with a preceding colon; otherwise, if it is accessible in the current package, it is printed without any package prefix; otherwise, it is printed with a package prefix.

+A symbol that is apparently uninterned is printed preceded by ``#:'' if *print-gensym* is true and printer escaping is enabled; if *print-gensym* is false or printer escaping is disabled, then the symbol is printed without a prefix, as if it were in the current package.

+Because the #: syntax does not intern the following symbol, it is necessary to use circular-list syntax if *print-circle* is true and the same uninterned symbol appears several times in an expression to be printed. For example, the result of

+

+ (let ((x (make-symbol "FOO"))) (list x x))
+
+ would be printed as (#:foo #:foo) if *print-circle* were false, but as (#1=#:foo #1#) if *print-circle* were true.

+A summary of the preceding package prefix rules follows:

+

foo:bar

+foo:bar is printed when symbol bar is external in its home package foo and is not accessible in the current package.

+

foo::bar

+foo::bar is printed when bar is internal in its home package foo and is not accessible in the current package.

+

:bar

+:bar is printed when the home package of bar is the KEYWORD package.

+

#:bar

+#:bar is printed when bar is apparently uninterned, even in the pathological case that bar has no home package but is nevertheless somehow accessible in the current package.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accb.htm new file mode 100644 index 00000000..dc311f24 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accb.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 22.1.3.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.3.2 Effect of Readtable Case on the Lisp Printer

+ When printer escaping is disabled, or the characters under consideration are not already quoted specifically by single escape or multiple escape syntax, the readtable case of the current readtable affects the way the Lisp printer writes symbols in the following ways:

+

:upcase

+ When the readtable case is :upcase, uppercase characters are printed in the case specified by *print-case*, and lowercase characters are printed in their own case.

+

:downcase

+ When the readtable case is :downcase, uppercase characters are printed in their own case, and lowercase characters are printed in the case specified by *print-case*.

+

:preserve

+ When the readtable case is :preserve, all alphabetic characters are printed in their own case.

+

:invert

+ When the readtable case is :invert, the case of all alphabetic characters in single case symbol names is inverted. Mixed-case symbol names are printed as is.

+The rules for escaping alphabetic characters in symbol names are affected by the readtable-case if printer escaping is enabled. Alphabetic characters are escaped as follows:

:upcase

+When the readtable case is :upcase, all lowercase characters must be escaped.

+

:downcase

+When the readtable case is :downcase, all uppercase characters must be escaped.

+

:preserve

+When the readtable case is :preserve, no alphabetic characters need be escaped.

+

:invert

+When the readtable case is :invert, no alphabetic characters need be escaped.

+

+ + +

+22.1.3.3.2.1 Examples of Effect of Readtable Case on the Lisp Printer

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accba.htm new file mode 100644 index 00000000..ad4e30b9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_accba.htm @@ -0,0 +1,88 @@ + + + +CLHS: Section 22.1.3.3.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.3.2.1 Examples of Effect of Readtable Case on the Lisp Printer

+

+ (defun test-readtable-case-printing ()
+   (let ((*readtable* (copy-readtable nil))
+         (*print-case* *print-case*))
+     (format t "READTABLE-CASE *PRINT-CASE*  Symbol-name  Output~
+              ~%--------------------------------------------------~
+              ~%")
+     (dolist (readtable-case '(:upcase :downcase :preserve :invert))
+       (setf (readtable-case *readtable*) readtable-case)
+       (dolist (print-case '(:upcase :downcase :capitalize))
+         (dolist (symbol '(|ZEBRA| |Zebra| |zebra|))
+           (setq *print-case* print-case)
+           (format t "~&:~A~15T:~A~29T~A~42T~A"
+                   (string-upcase readtable-case)
+                   (string-upcase print-case)
+                   (symbol-name symbol)
+                   (prin1-to-string symbol)))))))
+
+ The output from (test-readtable-case-printing) should be as follows:

+

+    READTABLE-CASE *PRINT-CASE*  Symbol-name  Output
+    --------------------------------------------------
+    :UPCASE        :UPCASE       ZEBRA        ZEBRA
+    :UPCASE        :UPCASE       Zebra        |Zebra|
+    :UPCASE        :UPCASE       zebra        |zebra|
+    :UPCASE        :DOWNCASE     ZEBRA        zebra
+    :UPCASE        :DOWNCASE     Zebra        |Zebra|
+    :UPCASE        :DOWNCASE     zebra        |zebra|
+    :UPCASE        :CAPITALIZE   ZEBRA        Zebra
+    :UPCASE        :CAPITALIZE   Zebra        |Zebra|
+    :UPCASE        :CAPITALIZE   zebra        |zebra|
+    :DOWNCASE      :UPCASE       ZEBRA        |ZEBRA|
+    :DOWNCASE      :UPCASE       Zebra        |Zebra|
+    :DOWNCASE      :UPCASE       zebra        ZEBRA
+    :DOWNCASE      :DOWNCASE     ZEBRA        |ZEBRA|
+    :DOWNCASE      :DOWNCASE     Zebra        |Zebra|
+    :DOWNCASE      :DOWNCASE     zebra        zebra
+    :DOWNCASE      :CAPITALIZE   ZEBRA        |ZEBRA|
+    :DOWNCASE      :CAPITALIZE   Zebra        |Zebra|
+    :DOWNCASE      :CAPITALIZE   zebra        Zebra
+    :PRESERVE      :UPCASE       ZEBRA        ZEBRA
+    :PRESERVE      :UPCASE       Zebra        Zebra
+    :PRESERVE      :UPCASE       zebra        zebra
+    :PRESERVE      :DOWNCASE     ZEBRA        ZEBRA
+    :PRESERVE      :DOWNCASE     Zebra        Zebra
+    :PRESERVE      :DOWNCASE     zebra        zebra
+    :PRESERVE      :CAPITALIZE   ZEBRA        ZEBRA
+    :PRESERVE      :CAPITALIZE   Zebra        Zebra
+    :PRESERVE      :CAPITALIZE   zebra        zebra
+    :INVERT        :UPCASE       ZEBRA        zebra
+    :INVERT        :UPCASE       Zebra        Zebra
+    :INVERT        :UPCASE       zebra        ZEBRA
+    :INVERT        :DOWNCASE     ZEBRA        zebra
+    :INVERT        :DOWNCASE     Zebra        Zebra
+    :INVERT        :DOWNCASE     zebra        ZEBRA
+    :INVERT        :CAPITALIZE   ZEBRA        zebra
+    :INVERT        :CAPITALIZE   Zebra        Zebra
+    :INVERT        :CAPITALIZE   zebra        ZEBRA
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acd.htm new file mode 100644 index 00000000..4482d6d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acd.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.1.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.4 Printing Strings

+The characters of the string are output in order. If printer escaping is enabled, a double-quote is output before and after, and all double-quotes and single escapes are preceded by backslash. The printing of strings is not affected by *print-array*. Only the active elements of the string are printed.

+For information on how the Lisp reader parses strings, see Section 2.4.5 (Double-Quote).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ace.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ace.htm new file mode 100644 index 00000000..f59b17d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ace.htm @@ -0,0 +1,62 @@ + + + +CLHS: Section 22.1.3.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.5 Printing Lists and Conses

+Wherever possible, list notation is preferred over dot notation. Therefore the following algorithm is used to print a cons x:

+

1. A left-parenthesis is printed.

+
2. The car of x is printed.

+
3. If the cdr of x is itself a cons, it is made to be the current cons (i.e., x becomes that cons), a space is printed, and step 2 is re-entered.

+
4. If the cdr of x is not null, a space, a dot, a space, and the cdr of x are printed.

+
5. A right-parenthesis is printed.

+ Actually, the above algorithm is only used when *print-pretty* is false. When *print-pretty* is true (or when pprint is used), additional whitespace[1] may replace the use of a single space, and a more elaborate algorithm with similar goals but more presentational flexibility is used; see Section 22.1.2 (Printer Dispatching).

+Although the two expressions below are equivalent, and the reader accepts either one and produces the same cons, the printer always prints such a cons in the second form.

+

+ (a . (b . ((c . (d . nil)) . (e . nil))))
+ (a b (c d) e)
+
+ The printing of conses is affected by *print-level*, *print-length*, and *print-circle*.

+Following are examples of printed representations of lists:

+

+ (a . b)     ;A dotted pair of a and b
+ (a.b)       ;A list of one element, the symbol named a.b
+ (a. b)      ;A list of two elements a. and b
+ (a .b)      ;A list of two elements a and .b
+ (a b . c)   ;A dotted list of a and b with c at the end; two conses
+ .iot        ;The symbol whose name is .iot
+ (. b)       ;Invalid -- an error is signaled if an attempt is made to read 
+             ;this syntax.
+ (a .)       ;Invalid -- an error is signaled.
+ (a .. b)    ;Invalid -- an error is signaled.
+ (a . . b)   ;Invalid -- an error is signaled.
+ (a b c ...) ;Invalid -- an error is signaled.
+ (a \. b)    ;A list of three elements a, ., and b
+ (a |.| b)   ;A list of three elements a, ., and b
+ (a \... b)  ;A list of three elements a, ..., and b
+ (a |...| b) ;A list of three elements a, ..., and b
+
+

+For information on how the Lisp reader parses lists and conses, see Section 2.4.1 (Left-Parenthesis).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acf.htm new file mode 100644 index 00000000..ba8bf19a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acf.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.1.3.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.6 Printing Bit Vectors

+A bit vector is printed as #* followed by the bits of the bit vector in order. If *print-array* is false, then the bit vector is printed in a format (using #<) that is concise but not readable. Only the active elements of the bit vector are printed.

+ For information on Lisp reader parsing of bit vectors, see Section 2.4.8.4 (Sharpsign Asterisk).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acg.htm new file mode 100644 index 00000000..0c76e822 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acg.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 22.1.3.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.7 Printing Other Vectors

+ If *print-array* is true and *print-readably* is false, any vector other than a string or bit vector is printed using general-vector syntax; this means that information about specialized vector representations does not appear. The printed representation of a zero-length vector is #(). The printed representation of a non-zero-length vector begins with #(. Following that, the first element of the vector is printed. If there are any other elements, they are printed in turn, with each such additional element preceded by a space if *print-pretty* is false, or whitespace[1] if *print-pretty* is true. A right-parenthesis after the last element terminates the printed representation of the vector. The printing of vectors is affected by *print-level* and *print-length*. If the vector has a fill pointer, then only those elements below the fill pointer are printed.

+ If both *print-array* and *print-readably* are false, the vector is not printed as described above, but in a format (using #<) that is concise but not readable.

+ If *print-readably* is true, the vector prints in an implementation-defined manner; see the variable *print-readably*.

+For information on how the Lisp reader parses these ``other vectors,'' see Section 2.4.8.3 (Sharpsign Left-Parenthesis).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ach.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ach.htm new file mode 100644 index 00000000..61978d2b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ach.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 22.1.3.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.8 Printing Other Arrays

+ If *print-array* is true and *print-readably* is false, any array other than a vector is printed using #nA format. Let n be the rank of the array. Then # is printed, then n as a decimal integer, then A, then n open parentheses. Next the elements are scanned in row-major order, using write on each element, and separating elements from each other with whitespace[1]. The array's dimensions are numbered 0 to n-1 from left to right, and are enumerated with the rightmost index changing fastest. Every time the index for dimension j is incremented, the following actions are taken:

+

* If j < n-1, then a close parenthesis is printed.

+
* If incrementing the index for dimension j caused it to equal dimension j, that index is reset to zero and the index for dimension j-1 is incremented (thereby performing these three steps recursively), unless j=0, in which case the entire algorithm is terminated. If incrementing the index for dimension j did not cause it to equal dimension j, then a space is printed.

+
* If j < n-1, then an open parenthesis is printed.

+This causes the contents to be printed in a format suitable for :initial-contents to make-array. The lists effectively printed by this procedure are subject to truncation by *print-level* and *print-length*.

+If the array is of a specialized type, containing bits or characters, then the innermost lists generated by the algorithm given above can instead be printed using bit-vector or string syntax, provided that these innermost lists would not be subject to truncation by *print-length*.

+ If both *print-array* and *print-readably* are false, then the array is printed in a format (using #<) that is concise but not readable.

+ If *print-readably* is true, the array prints in an implementation-defined manner; see the variable *print-readably*. In particular, this may be important for arrays having some dimension 0.

+For information on how the Lisp reader parses these ``other arrays,'' see Section 2.4.8.12 (Sharpsign A).

+ + +

+22.1.3.9 Examples of Printing Arrays

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aci.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aci.htm new file mode 100644 index 00000000..a754fb26 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_aci.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 22.1.3.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.9 Examples of Printing Arrays

+

+ (let ((a (make-array '(3 3)))
+       (*print-pretty* t)
+       (*print-array* t))
+   (dotimes (i 3) (dotimes (j 3) (setf (aref a i j) (format nil "<~D,~D>" i j))))
+   (print a)
+   (print (make-array 9 :displaced-to a)))
+>>  #2A(("<0,0>" "<0,1>" "<0,2>") 
+>>      ("<1,0>" "<1,1>" "<1,2>") 
+>>      ("<2,0>" "<2,1>" "<2,2>")) 
+>>  #("<0,0>" "<0,1>" "<0,2>" "<1,0>" "<1,1>" "<1,2>" "<2,0>" "<2,1>" "<2,2>") 
+=>  #<ARRAY 9 indirect 36363476>
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acj.htm new file mode 100644 index 00000000..18d85148 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acj.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 22.1.3.10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.10 Printing Random States

+A specific syntax for printing objects of type random-state is not specified. However, every implementation must arrange to print a random state object in such a way that, within the same implementation, read can construct from the printed representation a copy of the random state object as if the copy had been made by make-random-state.

+If the type random state is effectively implemented by using the machinery for defstruct, the usual structure syntax can then be used for printing random state objects; one might look something like

+

+ #S(RANDOM-STATE :DATA #(14 49 98436589 786345 8734658324 ... ))
+
+ where the components are implementation-dependent.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ack.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ack.htm new file mode 100644 index 00000000..d60c2f1d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ack.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 22.1.3.11 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.11 Printing Pathnames

+

+ When printer escaping is enabled, the syntax #P"..." is how a pathname is printed by write and the other functions herein described. The "..." is the namestring representation of the pathname.

+ When printer escaping is disabled, write writes a pathname P by writing (namestring P) instead.

+For information on how the Lisp reader parses pathnames, see Section 2.4.8.14 (Sharpsign P).

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acl.htm new file mode 100644 index 00000000..2133da31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acl.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 22.1.3.12 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.12 Printing Structures

+ By default, a structure of type S is printed using #S syntax. This behavior can be customized by specifying a :print-function or :print-object option to the defstruct form that defines S, or by writing a print-object method that is specialized for objects of type S.

+ Different structures might print out in different ways; the default notation for structures is:

+

+ #S(structure-name {slot-key slot-value}*)
+
+ where #S indicates structure syntax, structure-name is a structure name, each slot-key is an initialization argument name for a slot in the structure, and each corresponding slot-value is a representation of the object in that slot.

+For information on how the Lisp reader parses structures, see Section 2.4.8.13 (Sharpsign S).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acm.htm new file mode 100644 index 00000000..2b5e16ce --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_acm.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 22.1.3.13 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.3.13 Printing Other Objects

+Other objects are printed in an implementation-dependent manner. It is not required that an implementation print those objects readably.

+For example, hash tables, readtables, packages, streams, and functions might not print readably.

+A common notation to use in this circumstance is #<...>. Since #< is not readable by the Lisp reader, the precise format of the text which follows is not important, but a common format to use is that provided by the print-unreadable-object macro.

+For information on how the Lisp reader treats this notation, see Section 2.4.8.20 (Sharpsign Less-Than-Sign). For information on how to notate objects that cannot be printed readably, see Section 2.4.8.6 (Sharpsign Dot).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ad.htm new file mode 100644 index 00000000..63a0bc41 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ad.htm @@ -0,0 +1,81 @@ + + + +CLHS: Section 22.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.1.4 Examples of Printer Behavior

+

+ (let ((*print-escape* t)) (fresh-line) (write #\a))
+>>  #\a
+=>  #\a
+ (let ((*print-escape* nil) (*print-readably* nil))
+   (fresh-line)
+   (write #\a))
+>>  a
+=>  #\a
+ (progn (fresh-line) (prin1 #\a))
+>>  #\a
+=>  #\a
+ (progn (fresh-line) (print #\a))
+>>  
+>>  #\a
+=>  #\a
+ (progn (fresh-line) (princ #\a))
+>>  a
+=>  #\a
+
+ (dolist (val '(t nil))
+   (let ((*print-escape* val) (*print-readably* val))
+     (print '#\a) 
+     (prin1 #\a) (write-char #\Space)
+     (princ #\a) (write-char #\Space)
+     (write #\a)))
+>>  #\a #\a a #\a
+>>  #\a #\a a a
+=>  NIL
+
+ (progn (fresh-line) (write '(let ((a 1) (b 2)) (+ a b))))
+>>  (LET ((A 1) (B 2)) (+ A B))
+=>  (LET ((A 1) (B 2)) (+ A B))
+
+ (progn (fresh-line) (pprint '(let ((a 1) (b 2)) (+ a b))))
+>>  (LET ((A 1)
+>>        (B 2))               
+>>    (+ A B))
+=>  (LET ((A 1) (B 2)) (+ A B))
+
+ (progn (fresh-line) 
+        (write '(let ((a 1) (b 2)) (+ a b)) :pretty t))
+>>  (LET ((A 1)
+>>        (B 2))
+>>    (+ A B))                 
+=>  (LET ((A 1) (B 2)) (+ A B))
+
+ (with-output-to-string (s)  
+    (write 'write :stream s)
+    (prin1 'prin1 s))
+=>  "WRITEPRIN1"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_b.htm new file mode 100644 index 00000000..d1be34d7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_b.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 22.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2 The Lisp Pretty Printer

+

+ + +

+22.2.1 Pretty Printer Concepts

+ +

+22.2.2 Examples of using the Pretty Printer

+ +

+22.2.3 Notes about the Pretty Printer's Background

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ba.htm new file mode 100644 index 00000000..a5ea7c7f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ba.htm @@ -0,0 +1,47 @@ + + + +CLHS: Section 22.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.1 Pretty Printer Concepts

+The facilities provided by the pretty printer permit programs to redefine the way in which code is displayed, and allow the full power of pretty printing to be applied to complex combinations of data structures.

+Whether any given style of output is in fact ``pretty'' is inherently a somewhat subjective issue. However, since the effect of the pretty printer can be customized by conforming programs, the necessary flexibility is provided for individual programs to achieve an arbitrary degree of aesthetic control.

+By providing direct access to the mechanisms within the pretty printer that make dynamic decisions about layout, the macros and functions pprint-logical-block, pprint-newline, and pprint-indent make it possible to specify pretty printing layout rules as a part of any function that produces output. They also make it very easy for the detection of circularity and sharing, and abbreviation based on length and nesting depth to be supported by the function.

+The pretty printer is driven entirely by dispatch based on the value of *print-pprint-dispatch*. The function set-pprint-dispatch makes it possible for conforming programs to associate new pretty printing functions with a type.

+ + +

+22.2.1.1 Dynamic Control of the Arrangement of Output

+ +

+22.2.1.2 Format Directive Interface

+ +

+22.2.1.3 Compiling Format Strings

+ +

+22.2.1.4 Pretty Print Dispatch Tables

+ +

+22.2.1.5 Pretty Printer Margins

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_baa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_baa.htm new file mode 100644 index 00000000..65cd386b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_baa.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 22.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.1.1 Dynamic Control of the Arrangement of Output

+The actions of the pretty printer when a piece of output is too large to fit in the space available can be precisely controlled. Three concepts underlie the way these operations work---logical blocks, conditional newlines, and sections. Before proceeding further, it is important to define these terms.

+The first line of the next figure shows a schematic piece of output. Each of the characters in the output is represented by ``-''. The positions of conditional newlines are indicated by digits. The beginnings and ends of logical blocks are indicated by ``<'' and ``>'' respectively.

+The output as a whole is a logical block and the outermost section. This section is indicated by the 0's on the second line of Figure 1. Logical blocks nested within the output are specified by the macro pprint-logical-block. Conditional newline positions are specified by calls to pprint-newline. Each conditional newline defines two sections (one before it and one after it) and is associated with a third (the section immediately containing it).

+The section after a conditional newline consists of: all the output up to, but not including, (a) the next conditional newline immediately contained in the same logical block; or if (a) is not applicable, (b) the next newline that is at a lesser level of nesting in logical blocks; or if (b) is not applicable, (c) the end of the output.

+The section before a conditional newline consists of: all the output back to, but not including, (a) the previous conditional newline that is immediately contained in the same logical block; or if (a) is not applicable, (b) the beginning of the immediately containing logical block. The last four lines in Figure 1 indicate the sections before and after the four conditional newlines.

+The section immediately containing a conditional newline is the shortest section that contains the conditional newline in question. In the next figure, the first conditional newline is immediately contained in the section marked with 0's, the second and third conditional newlines are immediately contained in the section before the fourth conditional newline, and the fourth conditional newline is immediately contained in the section after the first conditional newline.

+

+ <-1---<--<--2---3->--4-->->
+ 000000000000000000000000000
+ 11 111111111111111111111111
+           22 222
+              333 3333
+        44444444444444 44444
+
+

Figure 22-3. Example of Logical Blocks, Conditional Newlines, and Sections

+Whenever possible, the pretty printer displays the entire contents of a section on a single line. However, if the section is too long to fit in the space available, line breaks are inserted at conditional newline positions within the section.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bab.htm new file mode 100644 index 00000000..1844e917 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bab.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 22.2.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.1.2 Format Directive Interface

+The primary interface to operations for dynamically determining the arrangement of output is provided through the functions and macros of the pretty printer. The next figure shows the defined names related to pretty printing.

+

+*print-lines*            pprint-dispatch                pprint-pop           
+*print-miser-width*      pprint-exit-if-list-exhausted  pprint-tab           
+*print-pprint-dispatch*  pprint-fill                    pprint-tabular       
+*print-right-margin*     pprint-indent                  set-pprint-dispatch  
+copy-pprint-dispatch     pprint-linear                  write                
+format                   pprint-logical-block                                
+formatter                pprint-newline                                      
+
+

Figure 22-4. Defined names related to pretty printing.

+The next figure identifies a set of format directives which serve as an alternate interface to the same pretty printing operations in a more textually compact form.

+ 

+~I   ~W      ~<...~:>  
+~:T  ~/.../  ~_        
+
+

Figure 22-5. Format directives related to Pretty Printing

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bac.htm new file mode 100644 index 00000000..5acb737b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bac.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.2.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.1.3 Compiling Format Strings

+ A format string is essentially a program in a special-purpose language that performs printing, and that is interpreted by the function format. The formatter macro provides the efficiency of using a compiled function to do that same printing but without losing the textual compactness of format strings.

+A format control is either a format string or a function that was returned by the the formatter macro.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bad.htm new file mode 100644 index 00000000..80ebdf44 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bad.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 22.2.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.1.4 Pretty Print Dispatch Tables

+

+A pprint dispatch table is a mapping from keys to pairs of values. Each key is a type specifier. The values associated with a key are a ``function'' (specifically, a function designator or nil) and a ``numerical priority'' (specifically, a real). Basic insertion and retrieval is done based on the keys with the equality of keys being tested by equal.

+When *print-pretty* is true, the current pprint dispatch table (in *print-pprint-dispatch*) controls how objects are printed. The information in this table takes precedence over all other mechanisms for specifying how to print objects. In particular, it has priority over user-defined print-object methods because the current pprint dispatch table is consulted first.

+The function is chosen from the current pprint dispatch table by finding the highest priority function that is associated with a type specifier that matches the object; if there is more than one such function, it is implementation-dependent which is used.

+However, if there is no information in the table about how to pretty print a particular kind of object, a function is invoked which uses print-object to print the object. The value of *print-pretty* is still true when this function is called, and individual methods for print-object might still elect to produce output in a special format conditional on the value of *print-pretty*.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bae.htm new file mode 100644 index 00000000..4768544a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.2.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.1.5 Pretty Printer Margins

+A primary goal of pretty printing is to keep the output between a pair of margins. The column where the output begins is taken as the left margin. If the current column cannot be determined at the time output begins, the left margin is assumed to be zero. The right margin is controlled by *print-right-margin*.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bb.htm new file mode 100644 index 00000000..0d8ee359 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bb.htm @@ -0,0 +1,236 @@ + + + +CLHS: Section 22.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.2 Examples of using the Pretty Printer

+As an example of the interaction of logical blocks, conditional newlines, and indentation, consider the function simple-pprint-defun below. This function prints out lists whose cars are defun in the standard way assuming that the list has exactly length 4.

+

+(defun simple-pprint-defun (*standard-output* list)
+  (pprint-logical-block (*standard-output* list :prefix "(" :suffix ")")
+    (write (first list))
+    (write-char #\Space)
+    (pprint-newline :miser)
+    (pprint-indent :current 0)
+    (write (second list))
+    (write-char #\Space)
+    (pprint-newline :fill)
+    (write (third list))
+    (pprint-indent :block 1)
+    (write-char #\Space)
+    (pprint-newline :linear)
+    (write (fourth list))))
+
+

+Suppose that one evaluates the following:

+

+(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y)))
+
+

+If the line width available is greater than or equal to 26, then all of the output appears on one line. If the line width available is reduced to 25, a line break is inserted at the linear-style conditional newline before the expression (* x y), producing the output shown. The (pprint-indent :block 1) causes (* x y) to be printed at a relative indentation of 1 in the logical block.

+

+ (DEFUN PROD (X Y) 
+   (* X Y))
+
+

+If the line width available is 15, a line break is also inserted at the fill style conditional newline before the argument list. The call on (pprint-indent :current 0) causes the argument list to line up under the function name.

+

+(DEFUN PROD
+       (X Y)
+  (* X Y))
+
+

+If *print-miser-width* were greater than or equal to 14, the example output above would have been as follows, because all indentation changes are ignored in miser mode and line breaks are inserted at miser-style conditional newlines.

+

+ (DEFUN
+  PROD
+  (X Y)
+  (* X Y))
+
+

+As an example of a per-line prefix, consider that evaluating the following produces the output shown with a line width of 20 and *print-miser-width* of nil.

+

+ (pprint-logical-block (*standard-output* nil :per-line-prefix ";;; ")
+   (simple-pprint-defun *standard-output* '(defun prod (x y) (* x y))))
+ 
+ ;;; (DEFUN PROD
+ ;;;        (X Y)
+ ;;;   (* X Y))
+
+

+As a more complex (and realistic) example, consider the function pprint-let below. This specifies how to print a let form in the traditional style. It is more complex than the example above, because it has to deal with nested structure. Also, unlike the example above it contains complete code to readably print any possible list that begins with the symbol let. The outermost pprint-logical-block form handles the printing of the input list as a whole and specifies that parentheses should be printed in the output. The second pprint-logical-block form handles the list of binding pairs. Each pair in the list is itself printed by the innermost pprint-logical-block. (A loop form is used instead of merely decomposing the pair into two objects so that readable output will be produced no matter whether the list corresponding to the pair has one element, two elements, or (being malformed) has more than two elements.) A space and a fill-style conditional newline are placed after each pair except the last. The loop at the end of the topmost pprint-logical-block form prints out the forms in the body of the let form separated by spaces and linear-style conditional newlines.

+

+ (defun pprint-let (*standard-output* list)
+   (pprint-logical-block (nil list :prefix "(" :suffix ")")
+     (write (pprint-pop))
+     (pprint-exit-if-list-exhausted)
+     (write-char #\Space)
+     (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
+       (pprint-exit-if-list-exhausted)
+       (loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
+               (pprint-exit-if-list-exhausted)
+               (loop (write (pprint-pop))
+                     (pprint-exit-if-list-exhausted)
+                     (write-char #\Space)
+                     (pprint-newline :linear)))
+             (pprint-exit-if-list-exhausted)
+             (write-char #\Space)
+             (pprint-newline :fill)))
+     (pprint-indent :block 1)
+     (loop (pprint-exit-if-list-exhausted)
+           (write-char #\Space)
+           (pprint-newline :linear)
+           (write (pprint-pop)))))
+
+

+Suppose that one evaluates the following with *print-level* being 4, and *print-circle* being true.

+

+ (pprint-let *standard-output*
+             '#1=(let (x (*print-length* (f (g 3))) 
+                       (z . 2) (k (car y)))
+                   (setq x (sqrt z)) #1#))
+
+

+If the line length is greater than or equal to 77, the output produced appears on one line. However, if the line length is 76, line breaks are inserted at the linear-style conditional newlines separating the forms in the body and the output below is produced. Note that, the degenerate binding pair x is printed readably even though it fails to be a list; a depth abbreviation marker is printed in place of (g 3); the binding pair (z . 2) is printed readably even though it is not a proper list; and appropriate circularity markers are printed.

+

+ #1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y))) 
+      (SETQ X (SQRT Z))
+      #1#)
+
+

+If the line length is reduced to 35, a line break is inserted at one of the fill-style conditional newlines separating the binding pairs.

+

+ #1=(LET (X (*PRINT-PRETTY* (F #))
+          (Z . 2) (K (CAR Y)))
+      (SETQ X (SQRT Z))
+      #1#)
+
+

+Suppose that the line length is further reduced to 22 and *print-length* is set to 3. In this situation, line breaks are inserted after both the first and second binding pairs. In addition, the second binding pair is itself broken across two lines. Clause (b) of the description of fill-style conditional newlines (see the function pprint-newline) prevents the binding pair (z . 2) from being printed at the end of the third line. Note that the length abbreviation hides the circularity from view and therefore the printing of circularity markers disappears.

+

+ (LET (X
+       (*PRINT-LENGTH*
+        (F #))
+       (Z . 2) ...)
+   (SETQ X (SQRT Z))
+   ...)
+
+

+The next function prints a vector using ``#(...)'' notation.

+

+(defun pprint-vector (*standard-output* v)
+  (pprint-logical-block (nil nil :prefix "#(" :suffix ")")
+    (let ((end (length v)) (i 0))
+      (when (plusp end)
+        (loop (pprint-pop)
+              (write (aref v i))
+              (if (= (incf i) end) (return nil))
+              (write-char #\Space)
+              (pprint-newline :fill))))))
+
+

+Evaluating the following with a line length of 15 produces the output shown.

+

+ (pprint-vector *standard-output* '#(12 34 567 8 9012 34 567 89 0 1 23))
+ 
+ #(12 34 567 8 
+   9012 34 567 
+   89 0 1 23)
+
+

+As examples of the convenience of specifying pretty printing with format strings, consider that the functions simple-pprint-defun and pprint-let used as examples above can be compactly defined as follows. (The function pprint-vector cannot be defined using format because the data structure it traverses is not a list.)

+

+(defun simple-pprint-defun (*standard-output* list)
+  (format T "~:<~W ~@_~:I~W ~:_~W~1I ~_~W~:>" list))
+
+(defun pprint-let (*standard-output* list)
+  (format T "~:<~W~^~:<~@{~:<~@{~W~^~_~}~:>~^~:_~}~:>~1I~@{~^~_~W~}~:>" list)) 
+
+

+In the following example, the first form restores *print-pprint-dispatch* to the equivalent of its initial value. The next two forms then set up a special way to pretty print ratios. Note that the more specific type specifier has to be associated with a higher priority.

+

+ (setq *print-pprint-dispatch* (copy-pprint-dispatch nil))
+
+ (set-pprint-dispatch 'ratio
+   #'(lambda (s obj)
+       (format s "#.(/ ~W ~W)" 
+                 (numerator obj) (denominator obj))))
+
+ (set-pprint-dispatch '(and ratio (satisfies minusp))
+   #'(lambda (s obj)
+       (format s "#.(- (/ ~W ~W))" 
+               (- (numerator obj)) (denominator obj)))
+   5)
+
+ (pprint '(1/3 -2/3))
+ (#.(/ 1 3) #.(- (/ 2 3)))
+
+

+The following two forms illustrate the definition of pretty printing functions for types of code. The first form illustrates how to specify the traditional method for printing quoted objects using single-quote. Note the care taken to ensure that data lists that happen to begin with quote will be printed readably. The second form specifies that lists beginning with the symbol my-let should print the same way that lists beginning with let print when the initial pprint dispatch table is in effect.

+

+ (set-pprint-dispatch '(cons (member quote)) () 
+   #'(lambda (s list)
+       (if (and (consp (cdr list)) (null (cddr list)))
+          (funcall (formatter "'~W") s (cadr list))
+          (pprint-fill s list))))
+ 
+ (set-pprint-dispatch '(cons (member my-let)) 
+                      (pprint-dispatch '(let) nil))
+
+

+The next example specifies a default method for printing lists that do not correspond to function calls. Note that the functions pprint-linear, pprint-fill, and pprint-tabular are all defined with optional colon-p and at-sign-p arguments so that they can be used as pprint dispatch functions as well as ~/.../ functions.

+

+ (set-pprint-dispatch '(cons (not (and symbol (satisfies fboundp))))
+                      #'pprint-fill -5)
+ 
+ ;; Assume a line length of 9
+ (pprint '(0 b c d e f g h i j k))
+ (0 b c d
+  e f g h
+  i j k)
+
+

+This final example shows how to define a pretty printing function for a user defined data structure.

+

+ (defstruct family mom kids)
+ 
+ (set-pprint-dispatch 'family
+   #'(lambda (s f)
+       (funcall (formatter "~@<#<~;~W and ~2I~_~/pprint-fill/~;>~:>")
+               s (family-mom f) (family-kids f))))
+
+

+The pretty printing function for the structure family specifies how to adjust the layout of the output so that it can fit aesthetically into a variety of line widths. In addition, it obeys the printer control variables *print-level*, *print-length*, *print-lines*, *print-circle* and *print-escape*, and can tolerate several different kinds of malformity in the data structure. The output below shows what is printed out with a right margin of 25, *print-pretty* being true, *print-escape* being false, and a malformed kids list.

+

+ (write (list 'principal-family
+              (make-family :mom "Lucy"
+                           :kids '("Mark" "Bob" . "Dan")))
+        :right-margin 25 :pretty T :escape nil :miser-width nil)
+ (PRINCIPAL-FAMILY
+  #<Lucy and
+      Mark Bob . Dan>)
+
+

+ Note that a pretty printing function for a structure is different from the structure's print-object method. While print-object methods are permanently associated with a structure, pretty printing functions are stored in pprint dispatch tables and can be rapidly changed to reflect different printing needs. If there is no pretty printing function for a structure in the current pprint dispatch table, its print-object method is used instead.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bc.htm new file mode 100644 index 00000000..d9c16f7e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_bc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.2.3 Notes about the Pretty Printer's Background

+For a background reference to the abstract concepts detailed in this section, see XP: A Common Lisp Pretty Printing System. The details of that paper are not binding on this document, but may be helpful in establishing a conceptual basis for understanding this material.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_c.htm new file mode 100644 index 00000000..059bb808 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_c.htm @@ -0,0 +1,85 @@ + + + +CLHS: Section 22.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3 Formatted Output

+

+format is useful for producing nicely formatted text, producing good-looking messages, and so on. format can generate and return a string or output to destination.

+The control-string argument to format is actually a format control. That is, it can be either a format string or a function, for example a function returned by the formatter macro.

+If it is a function, the function is called with the appropriate output stream as its first argument and the data arguments to format as its remaining arguments. The function should perform whatever output is necessary and return the unused tail of the arguments (if any).

+The compilation process performed by formatter produces a function that would do with its arguments as the format interpreter would do with those arguments.

+The remainder of this section describes what happens if the control-string is a format string.

+Control-string is composed of simple text (characters) and embedded directives.

+format writes the simple text as is; each embedded directive specifies further text output that is to appear at the corresponding point within the simple text. Most directives use one or more elements of args to create their output.

+A directive consists of a tilde, optional prefix parameters separated by commas, optional colon and at-sign modifiers, and a single character indicating what kind of directive this is. There is no required ordering between the at-sign and colon modifier. The case of the directive character is ignored. Prefix parameters are notated as signed (sign is optional) decimal numbers, or as a single-quote followed by a character. For example, ~5,'0d can be used to print an integer in decimal radix in five columns with leading zeros, or ~5,'*d to get leading asterisks.

+In place of a prefix parameter to a directive, V (or v) can be used. In this case, format takes an argument from args as a parameter to the directive. The argument should be an integer or character. If the arg used by a V parameter is nil, the effect is as if the parameter had been omitted. # can be used in place of a prefix parameter; it represents the number of args remaining to be processed. When used within a recursive format, in the context of ~? or ~{, the # prefix parameter represents the number of format arguments remaining within the recursive call.

+Examples of format strings:

+

+"~S"        ;This is an S directive with no parameters or modifiers.  
+"~3,-4:@s"  ;This is an S directive with two parameters, 3 and -4,    
+            ; and both the colon and at-sign flags.                   
+"~,+4S"     ;Here the first prefix parameter is omitted and takes     
+            ; on its default value, while the second parameter is 4.  
+
+

Figure 22-6. Examples of format control strings

+format sends the output to destination. If destination is nil, format creates and returns a string containing the output from control-string. If destination is non-nil, it must be a string with a fill pointer, a stream, or the symbol t. If destination is a string with a fill pointer, the output is added to the end of the string. If destination is a stream, the output is sent to that stream. If destination is t, the output is sent to standard output.

+In the description of the directives that follows, the term arg in general refers to the next item of the set of args to be processed. The word or phrase at the beginning of each description is a mnemonic for the directive. format directives do not bind any of the printer control variables (*print-...*) except as specified in the following descriptions. Implementations may specify the binding of new, implementation-specific printer control variables for each format directive, but they may neither bind any standard printer control variables not specified in description of a format directive nor fail to bind any standard printer control variables as specified in the description.

+ + +

+22.3.1 FORMAT Basic Output

+ +

+22.3.2 FORMAT Radix Control

+ +

+22.3.3 FORMAT Floating-Point Printers

+ +

+22.3.4 FORMAT Printer Operations

+ +

+22.3.5 FORMAT Pretty Printer Operations

+ +

+22.3.6 FORMAT Layout Control

+ +

+22.3.7 FORMAT Control-Flow Operations

+ +

+22.3.8 FORMAT Miscellaneous Operations

+ +

+22.3.9 FORMAT Miscellaneous Pseudo-Operations

+ +

+22.3.10 Additional Information about FORMAT Operations

+ +

+22.3.11 Examples of FORMAT

+ +

+22.3.12 Notes about FORMAT

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ca.htm new file mode 100644 index 00000000..e9af7019 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ca.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 22.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.1 FORMAT Basic Output

+ + +

+22.3.1.1 Tilde C: Character

+ +

+22.3.1.2 Tilde Percent: Newline

+ +

+22.3.1.3 Tilde Ampersand: Fresh-Line

+ +

+22.3.1.4 Tilde Vertical-Bar: Page

+ + +

+22.3.1.5 Tilde Tilde: Tilde

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_caa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_caa.htm new file mode 100644 index 00000000..315369d8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_caa.htm @@ -0,0 +1,54 @@ + + + +CLHS: Section 22.3.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.1.1 Tilde C: Character

+ The next arg should be a character; it is printed according to the modifier flags.

+ ~C prints the character as if by using write-char if it is a simple character. Characters that are not simple are not necessarily printed as if by write-char, but are displayed in an implementation-defined, abbreviated format. For example,

+

+ (format nil "~C" #\A) =>  "A"
+ (format nil "~C" #\Space) =>  " "
+
+

+~:C is the same as ~C for printing characters, but other characters are ``spelled out.'' The intent is that this is a ``pretty'' format for printing characters. For simple characters that are not printing, what is spelled out is the name of the character (see char-name). For characters that are not simple and not printing, what is spelled out is implementation-defined. For example,

+

+ (format nil "~:C" #\A) =>  "A"
+ (format nil "~:C" #\Space) =>  "Space"
+;; This next example assumes an implementation-defined "Control" attribute.
+ (format nil "~:C" #\Control-Space)
+=>  "Control-Space"
+OR=>  "c-Space"
+
+

+~:@C prints what ~:C would, and then if the character requires unusual shift keys on the keyboard to type it, this fact is mentioned. For example,

+ +

+ (format nil "~:@C" #\Control-Partial) =>  "Control-<PARTIAL> (Top-F)"  
+
+

+This is the format used for telling the user about a key he is expected to type, in prompts, for instance. The precise output may depend not only on the implementation, but on the particular I/O devices in use.

+~@C prints the character in a way that the Lisp reader can understand, using #\ syntax.

+ ~@C binds *print-escape* to t.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cab.htm new file mode 100644 index 00000000..298f1dc4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.1.2 Tilde Percent: Newline

+This outputs a #\Newline character, thereby terminating the current output line and beginning a new one. ~n% outputs n newlines. No arg is used.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cac.htm new file mode 100644 index 00000000..beced92a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cac.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.1.3 Tilde Ampersand: Fresh-Line

+Unless it can be determined that the output stream is already at the beginning of a line, this outputs a newline. ~n& calls fresh-line and then outputs n-1 newlines. ~0& does nothing.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cad.htm new file mode 100644 index 00000000..08c7b759 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cad.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.1.4 Tilde Vertical-Bar: Page

+This outputs a page separator character, if possible. ~n| does this n times.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cae.htm new file mode 100644 index 00000000..aa8591d4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.1.5 Tilde Tilde: Tilde

+This outputs a tilde. ~n~ outputs n tildes.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cb.htm new file mode 100644 index 00000000..be7b82fc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cb.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 22.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.2 FORMAT Radix Control

+ + +

+22.3.2.1 Tilde R: Radix

+ +

+22.3.2.2 Tilde D: Decimal

+ +

+22.3.2.3 Tilde B: Binary

+ +

+22.3.2.4 Tilde O: Octal

+ +

+22.3.2.5 Tilde X: Hexadecimal

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cba.htm new file mode 100644 index 00000000..a27dbe7d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cba.htm @@ -0,0 +1,45 @@ + + + +CLHS: Section 22.3.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.2.1 Tilde R: Radix

+~nR prints arg in radix n. The modifier flags and any remaining parameters are used as for the ~D directive. ~D is the same as ~10R. The full form is ~radix,mincol,padchar,commachar,comma-intervalR.

+If no prefix parameters are given to ~R, then a different interpretation is given. The argument should be an integer. For example, if arg is 4:

+

* ~R prints arg as a cardinal English number: four.

+
* ~:R prints arg as an ordinal English number: fourth.

+
* ~@R prints arg as a Roman numeral: IV.

+
* ~:@R prints arg as an old Roman numeral: IIII.

+ For example:

+

+ (format nil "~,,' ,4:B" 13) =>  "1101"
+ (format nil "~,,' ,4:B" 17) =>  "1 0001"
+ (format nil "~19,0,' ,4:B" 3333) =>  "0000 1101 0000 0101"
+ (format nil "~3,,,' ,2:R" 17) =>  "1 22"
+ (format nil "~,,'|,2:D" #xFFFF) =>   "6|55|35"
+
+

+ If and only if the first parameter, n, is supplied, ~R binds *print-escape* to false, *print-radix* to false, *print-base* to n, and *print-readably* to false.

+If and only if no parameters are supplied, ~R binds *print-base* to 10.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbb.htm new file mode 100644 index 00000000..d66a0648 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbb.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 22.3.2.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.2.2 Tilde D: Decimal

+An arg, which should be an integer, is printed in decimal radix. ~D will never put a decimal point after the number.

+~mincolD uses a column width of mincol; spaces are inserted on the left if the number requires fewer than mincol columns for its digits and sign. If the number doesn't fit in mincol columns, additional columns are used as needed.

+~mincol,padcharD uses padchar as the pad character instead of space.

+If arg is not an integer, it is printed in ~A format and decimal base.

+The @ modifier causes the number's sign to be printed always; the default is to print it only if the number is negative. The : modifier causes commas to be printed between groups of digits; commachar may be used to change the character used as the comma. comma-interval must be an integer and defaults to 3. When the : modifier is given to any of these directives, the commachar is printed between groups of comma-interval digits.

+Thus the most general form of ~D is ~mincol,padchar,commachar,comma-intervalD.

+ ~D binds *print-escape* to false, *print-radix* to false, *print-base* to 10, and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbc.htm new file mode 100644 index 00000000..f9accf94 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.3.2.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.2.3 Tilde B: Binary

+This is just like ~D but prints in binary radix (radix 2) instead of decimal. The full form is therefore ~mincol,padchar,commachar,comma-intervalB.

+ ~B binds *print-escape* to false, *print-radix* to false, *print-base* to 2, and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbd.htm new file mode 100644 index 00000000..186d3ddf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbd.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.3.2.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.2.4 Tilde O: Octal

+This is just like ~D but prints in octal radix (radix 8) instead of decimal. The full form is therefore ~mincol,padchar,commachar,comma-intervalO.

+ ~O binds *print-escape* to false, *print-radix* to false, *print-base* to 8, and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbe.htm new file mode 100644 index 00000000..c86efbb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cbe.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.3.2.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.2.5 Tilde X: Hexadecimal

+This is just like ~D but prints in hexadecimal radix (radix 16) instead of decimal. The full form is therefore ~mincol,padchar,commachar,comma-intervalX.

+ ~X binds *print-escape* to false, *print-radix* to false, *print-base* to 16, and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cc.htm new file mode 100644 index 00000000..c6e36b87 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cc.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 22.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.3 FORMAT Floating-Point Printers

+ + +

+22.3.3.1 Tilde F: Fixed-Format Floating-Point

+ +

+22.3.3.2 Tilde E: Exponential Floating-Point

+ +

+22.3.3.3 Tilde G: General Floating-Point

+ +

+22.3.3.4 Tilde Dollarsign: Monetary Floating-Point

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cca.htm new file mode 100644 index 00000000..4f01051c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cca.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 22.3.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.3.1 Tilde F: Fixed-Format Floating-Point

+The next arg is printed as a float.

+The full form is ~w,d,k,overflowchar,padcharF. The parameter w is the width of the field to be printed; d is the number of digits to print after the decimal point; k is a scale factor that defaults to zero.

+Exactly w characters will be output. First, leading copies of the character padchar (which defaults to a space) are printed, if necessary, to pad the field on the left. If the arg is negative, then a minus sign is printed; if the arg is not negative, then a plus sign is printed if and only if the @ modifier was supplied. Then a sequence of digits, containing a single embedded decimal point, is printed; this represents the magnitude of the value of arg times 10^k, rounded to d fractional digits. When rounding up and rounding down would produce printed values equidistant from the scaled value of arg, then the implementation is free to use either one. For example, printing the argument 6.375 using the format ~4,2F may correctly produce either 6.37 or 6.38. Leading zeros are not permitted, except that a single zero digit is output before the decimal point if the printed value is less than one, and this single zero digit is not output at all if w=d+1.

+If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. If the parameter overflowchar is supplied, then w copies of that parameter are printed instead of the scaled value of arg. If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.

+If the w parameter is omitted, then the field is of variable width. In effect, a value is chosen for w in such a way that no leading pad characters need to be printed and exactly d characters will follow the decimal point. For example, the directive ~,2F will print exactly two digits after the decimal point and as many as necessary before the decimal point.

+If the parameter d is omitted, then there is no constraint on the number of digits to appear after the decimal point. A value is chosen for d in such a way that as many digits as possible may be printed subject to the width constraint imposed by the parameter w and the constraint that no trailing zero digits may appear in the fraction, except that if the fraction to be printed is zero, then a single zero digit should appear after the decimal point if permitted by the width constraint.

+If both w and d are omitted, then the effect is to print the value using ordinary free-format output; prin1 uses this format for any number whose magnitude is either zero or between 10^-3 (inclusive) and 10^7 (exclusive).

+If w is omitted, then if the magnitude of arg is so large (or, if d is also omitted, so small) that more than 100 digits would have to be printed, then an implementation is free, at its discretion, to print the number using exponential notation instead, as if by the directive ~E (with all parameters to ~E defaulted, not taking their values from the ~F directive).

+If arg is a rational number, then it is coerced to be a single float and then printed. Alternatively, an implementation is permitted to process a rational number by any other method that has essentially the same behavior but avoids loss of precision or overflow because of the coercion. If w and d are not supplied and the number has no exact decimal representation, for example 1/3, some precision cutoff must be chosen by the implementation since only a finite number of digits may be printed.

+If arg is a complex number or some non-numeric object, then it is printed using the format directive ~wD, thereby printing it in decimal radix and a minimum field width of w.

+ ~F binds *print-escape* to false and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccb.htm new file mode 100644 index 00000000..f53edf3e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccb.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 22.3.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.3.2 Tilde E: Exponential Floating-Point

+The next arg is printed as a float in exponential notation.

+The full form is ~w,d,e,k,overflowchar,padchar,exponentcharE. The parameter w is the width of the field to be printed; d is the number of digits to print after the decimal point; e is the number of digits to use when printing the exponent; k is a scale factor that defaults to one (not zero).

+Exactly w characters will be output. First, leading copies of the character padchar (which defaults to a space) are printed, if necessary, to pad the field on the left. If the arg is negative, then a minus sign is printed; if the arg is not negative, then a plus sign is printed if and only if the @ modifier was supplied. Then a sequence of digits containing a single embedded decimal point is printed. The form of this sequence of digits depends on the scale factor k. If k is zero, then d digits are printed after the decimal point, and a single zero digit appears before the decimal point if the total field width will permit it. If k is positive, then it must be strictly less than d+2; k significant digits are printed before the decimal point, and d-k+1 digits are printed after the decimal point. If k is negative, then it must be strictly greater than -d; a single zero digit appears before the decimal point if the total field width will permit it, and after the decimal point are printed first -k zeros and then d+k significant digits. The printed fraction must be properly rounded. When rounding up and rounding down would produce printed values equidistant from the scaled value of arg, then the implementation is free to use either one. For example, printing the argument 637.5 using the format ~8,2E may correctly produce either 6.37E+2 or 6.38E+2.

+Following the digit sequence, the exponent is printed. First the character parameter exponentchar is printed; if this parameter is omitted, then the exponent marker that prin1 would use is printed, as determined from the type of the float and the current value of *read-default-float-format*. Next, either a plus sign or a minus sign is printed, followed by e digits representing the power of ten by which the printed fraction must be multiplied to properly represent the rounded value of arg.

+If it is impossible to print the value in the required format in a field of width w, possibly because k is too large or too small or because the exponent cannot be printed in e character positions, then one of two actions is taken. If the parameter overflowchar is supplied, then w copies of that parameter are printed instead of the scaled value of arg. If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed; if the problem is that d is too small for the supplied k or that e is too small, then a larger value is used for d or e as may be needed.

+If the w parameter is omitted, then the field is of variable width. In effect a value is chosen for w in such a way that no leading pad characters need to be printed.

+If the parameter d is omitted, then there is no constraint on the number of digits to appear. A value is chosen for d in such a way that as many digits as possible may be printed subject to the width constraint imposed by the parameter w, the constraint of the scale factor k, and the constraint that no trailing zero digits may appear in the fraction, except that if the fraction to be printed is zero then a single zero digit should appear after the decimal point.

+If the parameter e is omitted, then the exponent is printed using the smallest number of digits necessary to represent its value.

+If all of w, d, and e are omitted, then the effect is to print the value using ordinary free-format exponential-notation output; prin1 uses a similar format for any non-zero number whose magnitude is less than 10^-3 or greater than or equal to 10^7. The only difference is that the ~E directive always prints a plus or minus sign in front of the exponent, while prin1 omits the plus sign if the exponent is non-negative.

+If arg is a rational number, then it is coerced to be a single float and then printed. Alternatively, an implementation is permitted to process a rational number by any other method that has essentially the same behavior but avoids loss of precision or overflow because of the coercion. If w and d are unsupplied and the number has no exact decimal representation, for example 1/3, some precision cutoff must be chosen by the implementation since only a finite number of digits may be printed.

+If arg is a complex number or some non-numeric object, then it is printed using the format directive ~wD, thereby printing it in decimal radix and a minimum field width of w.

+ ~E binds *print-escape* to false and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccc.htm new file mode 100644 index 00000000..88784534 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccc.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 22.3.3.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.3.3 Tilde G: General Floating-Point

+The next arg is printed as a float in either fixed-format or exponential notation as appropriate.

+The full form is ~w,d,e,k,overflowchar,padchar,exponentcharG. The format in which to print arg depends on the magnitude (absolute value) of the arg. Let n be an integer such that 10^n-1 <= |arg| < 10^n. Let ee equal e+2, or 4 if e is omitted. Let ww equal w-ee, or nil if w is omitted. If d is omitted, first let q be the number of digits needed to print arg with no loss of information and without leading or trailing zeros; then let d equal (max q (min n 7)). Let dd equal d-n.

+If 0 <= dd <= d, then arg is printed as if by the format directives

+~ww,dd,,overflowchar,padcharF~ee@T

+Note that the scale factor k is not passed to the ~F directive. For all other values of dd, arg is printed as if by the format directive

+~w,d,e,k,overflowchar,padchar,exponentcharE

+In either case, an @ modifier is supplied to the ~F or ~E directive if and only if one was supplied to the ~G directive.

+ ~G binds *print-escape* to false and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccd.htm new file mode 100644 index 00000000..bd4993d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ccd.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 22.3.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.3.4 Tilde Dollarsign: Monetary Floating-Point

+The next arg is printed as a float in fixed-format notation.

+The full form is ~d,n,w,padchar$. The parameter d is the number of digits to print after the decimal point (default value 2); n is the minimum number of digits to print before the decimal point (default value 1); w is the minimum total width of the field to be printed (default value 0).

+First padding and the sign are output. If the arg is negative, then a minus sign is printed; if the arg is not negative, then a plus sign is printed if and only if the @ modifier was supplied. If the : modifier is used, the sign appears before any padding, and otherwise after the padding. If w is supplied and the number of other characters to be output is less than w, then copies of padchar (which defaults to a space) are output to make the total field width equal w. Then n digits are printed for the integer part of arg, with leading zeros if necessary; then a decimal point; then d digits of fraction, properly rounded.

+If the magnitude of arg is so large that more than m digits would have to be printed, where m is the larger of w and 100, then an implementation is free, at its discretion, to print the number using exponential notation instead, as if by the directive ~w,q,,,,padcharE, where w and padchar are present or omitted according to whether they were present or omitted in the ~$ directive, and where q=d+n-1, where d and n are the (possibly default) values given to the ~$ directive.

+If arg is a rational number, then it is coerced to be a single float and then printed. Alternatively, an implementation is permitted to process a rational number by any other method that has essentially the same behavior but avoids loss of precision or overflow because of the coercion.

+If arg is a complex number or some non-numeric object, then it is printed using the format directive ~wD, thereby printing it in decimal radix and a minimum field width of w.

+ ~$ binds *print-escape* to false and *print-readably* to false.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cd.htm new file mode 100644 index 00000000..5cb4d067 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cd.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 22.3.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.4 FORMAT Printer Operations

+ + +

+22.3.4.1 Tilde A: Aesthetic

+ +

+22.3.4.2 Tilde S: Standard

+ +

+22.3.4.3 Tilde W: Write

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cda.htm new file mode 100644 index 00000000..a5b2f04a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cda.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 22.3.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.4.1 Tilde A: Aesthetic

+An arg, any object, is printed without escape characters (as by princ). If arg is a string, its characters will be output verbatim. If arg is nil it will be printed as nil; the colon modifier (~:A) will cause an arg of nil to be printed as (), but if arg is a composite structure, such as a list or vector, any contained occurrences of nil will still be printed as nil.

+~mincolA inserts spaces on the right, if necessary, to make the width at least mincol columns. The @ modifier causes the spaces to be inserted on the left rather than the right.

+~mincol,colinc,minpad,padcharA is the full form of ~A, which allows control of the padding. The string is padded on the right (or on the left if the @ modifier is used) with at least minpad copies of padchar; padding characters are then inserted colinc characters at a time until the total width is at least mincol. The defaults are 0 for mincol and minpad, 1 for colinc, and the space character for padchar.

+ ~A binds *print-escape* to false, and *print-readably* to false.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdb.htm new file mode 100644 index 00000000..295dd08a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdb.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.3.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.4.2 Tilde S: Standard

+This is just like ~A, but arg is printed with escape characters (as by prin1 rather than princ). The output is therefore suitable for input to read. ~S accepts all the arguments and modifiers that ~A does.

+ ~S binds *print-escape* to t.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdc.htm new file mode 100644 index 00000000..4bbe10b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cdc.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.3.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.4.3 Tilde W: Write

+An argument, any object, is printed obeying every printer control variable (as by write). In addition, ~W interacts correctly with depth abbreviation, by not resetting the depth counter to zero. ~W does not accept parameters. If given the colon modifier, ~W binds *print-pretty* to true. If given the at-sign modifier, ~W binds *print-level* and *print-length* to nil.

+~W provides automatic support for the detection of circularity and sharing. If the value of *print-circle* is not nil and ~W is applied to an argument that is a circular (or shared) reference, an appropriate #n# marker is inserted in the output instead of printing the argument.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ce.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ce.htm new file mode 100644 index 00000000..5964c5ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ce.htm @@ -0,0 +1,42 @@ + + + +CLHS: Section 22.3.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.5 FORMAT Pretty Printer Operations

+

+The following constructs provide access to the pretty printer:

+ + +

+22.3.5.1 Tilde Underscore: Conditional Newline

+ +

+22.3.5.2 Tilde Less-Than-Sign: Logical Block

+ +

+22.3.5.3 Tilde I: Indent

+ +

+22.3.5.4 Tilde Slash: Call Function

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cea.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cea.htm new file mode 100644 index 00000000..c14b1136 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cea.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.5.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.5.1 Tilde Underscore: Conditional Newline

+Without any modifiers, ~_ is the same as (pprint-newline :linear). ~@_ is the same as (pprint-newline :miser). ~:_ is the same as (pprint-newline :fill). ~:@_ is the same as (pprint-newline :mandatory).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ceb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ceb.htm new file mode 100644 index 00000000..2d232e4d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ceb.htm @@ -0,0 +1,38 @@ + + + +CLHS: Section 22.3.5.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.5.2 Tilde Less-Than-Sign: Logical Block

+~<...~:>

+If ~:> is used to terminate a ~<...~>, the directive is equivalent to a call to pprint-logical-block. The argument corresponding to the ~<...~:> directive is treated in the same way as the list argument to pprint-logical-block, thereby providing automatic support for non-list arguments and the detection of circularity, sharing, and depth abbreviation. The portion of the control-string nested within the ~<...~:> specifies the :prefix (or :per-line-prefix), :suffix, and body of the pprint-logical-block.

+The control-string portion enclosed by ~<...~:> can be divided into segments ~<prefix~;body~;suffix~:> by ~; directives. If the first section is terminated by ~@;, it specifies a per-line prefix rather than a simple prefix. The prefix and suffix cannot contain format directives. An error is signaled if either the prefix or suffix fails to be a constant string or if the enclosed portion is divided into more than three segments.

+If the enclosed portion is divided into only two segments, the suffix defaults to the null string. If the enclosed portion consists of only a single segment, both the prefix and the suffix default to the null string. If the colon modifier is used (i.e., ~:<...~:>), the prefix and suffix default to "(" and ")" (respectively) instead of the null string.

+The body segment can be any arbitrary format string. This format string is applied to the elements of the list corresponding to the ~<...~:> directive as a whole. Elements are extracted from this list using pprint-pop, thereby providing automatic support for malformed lists, and the detection of circularity, sharing, and length abbreviation. Within the body segment, ~^ acts like pprint-exit-if-list-exhausted.

+~<...~:> supports a feature not supported by pprint-logical-block. If ~:@> is used to terminate the directive (i.e., ~<...~:@>), then a fill-style conditional newline is automatically inserted after each group of blanks immediately contained in the body (except for blanks after a <Newline> directive). This makes it easy to achieve the equivalent of paragraph filling.

+If the at-sign modifier is used with ~<...~:>, the entire remaining argument list is passed to the directive as its argument. All of the remaining arguments are always consumed by ~@<...~:>, even if they are not all used by the format string nested in the directive. Other than the difference in its argument, ~@<...~:> is exactly the same as ~<...~:> except that circularity detection is not applied if ~@<...~:> is encountered at top level in a format string. This ensures that circularity detection is applied only to data lists, not to format argument lists.

+" . #n#" is printed if circularity or sharing has to be indicated for its argument as a whole.

+To a considerable extent, the basic form of the directive ~<...~> is incompatible with the dynamic control of the arrangement of output by ~W, ~_, ~<...~:>, ~I, and ~:T. As a result, an error is signaled if any of these directives is nested within ~<...~>. Beyond this, an error is also signaled if the ~<...~:;...~> form of ~<...~> is used in the same format string with ~W, ~_, ~<...~:>, ~I, or ~:T.

+See also Section 22.3.6.2 (Tilde Less-Than-Sign: Justification).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cec.htm new file mode 100644 index 00000000..e1047e3a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cec.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 22.3.5.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.5.3 Tilde I: Indent

+~nI is the same as (pprint-indent :block n).

+~n:I is the same as (pprint-indent :current n). In both cases, n defaults to zero, if it is omitted.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ced.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ced.htm new file mode 100644 index 00000000..31521e77 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ced.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 22.3.5.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.5.4 Tilde Slash: Call Function

+~/name/

+User defined functions can be called from within a format string by using the directive ~/name/. The colon modifier, the at-sign modifier, and arbitrarily many parameters can be specified with the ~/name/ directive. name can be any arbitrary string that does not contain a "/". All of the characters in name are treated as if they were upper case. If name contains a single colon (:) or double colon (::), then everything up to but not including the first ":" or "::" is taken to be a string that names a package. Everything after the first ":" or "::" (if any) is taken to be a string that names a symbol. The function corresponding to a ~/name/ directive is obtained by looking up the symbol that has the indicated name in the indicated package. If name does not contain a ":" or "::", then the whole name string is looked up in the COMMON-LISP-USER package.

+When a ~/name/ directive is encountered, the indicated function is called with four or more arguments. The first four arguments are: the output stream, the format argument corresponding to the directive, a generalized boolean that is true if the colon modifier was used, and a generalized boolean that is true if the at-sign modifier was used. The remaining arguments consist of any parameters specified with the directive. The function should print the argument appropriately. Any values returned by the function are ignored.

+The three functions pprint-linear, pprint-fill, and pprint-tabular are specifically designed so that they can be called by ~/.../ (i.e., ~/pprint-linear/, ~/pprint-fill/, and ~/pprint-tabular/). In particular they take colon and at-sign arguments.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cf.htm new file mode 100644 index 00000000..3bcd52c5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cf.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 22.3.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.6 FORMAT Layout Control

+ + +

+22.3.6.1 Tilde T: Tabulate

+ +

+22.3.6.2 Tilde Less-Than-Sign: Justification

+ +

+22.3.6.3 Tilde Greater-Than-Sign: End of Justification

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfa.htm new file mode 100644 index 00000000..890d0192 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 22.3.6.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.6.1 Tilde T: Tabulate

+This spaces over to a given column. ~colnum,colincT will output sufficient spaces to move the cursor to column colnum. If the cursor is already at or beyond column colnum, it will output spaces to move it to column colnum+k*colinc for the smallest positive integer k possible, unless colinc is zero, in which case no spaces are output if the cursor is already at or beyond column colnum. colnum and colinc default to 1.

+If for some reason the current absolute column position cannot be determined by direct inquiry, format may be able to deduce the current column position by noting that certain directives (such as ~%, or ~&, or ~A with the argument being a string containing a newline) cause the column position to be reset to zero, and counting the number of characters emitted since that point. If that fails, format may attempt a similar deduction on the riskier assumption that the destination was at column zero when format was invoked. If even this heuristic fails or is implementationally inconvenient, at worst the ~T operation will simply output two spaces.

+~@T performs relative tabulation. ~colrel,colinc@T outputs colrel spaces and then outputs the smallest non-negative number of additional spaces necessary to move the cursor to a column that is a multiple of colinc. For example, the directive ~3,8@T outputs three spaces and then moves the cursor to a ``standard multiple-of-eight tab stop'' if not at one already. If the current output column cannot be determined, however, then colinc is ignored, and exactly colrel spaces are output.

+If the colon modifier is used with the ~T directive, the tabbing computation is done relative to the horizontal position where the section immediately containing the directive begins, rather than with respect to a horizontal position of zero. The numerical parameters are both interpreted as being in units of ems and both default to 1. ~n,m:T is the same as (pprint-tab :section n m). ~n,m:@T is the same as (pprint-tab :section-relative n m).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfb.htm new file mode 100644 index 00000000..58114290 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfb.htm @@ -0,0 +1,44 @@ + + + +CLHS: Section 22.3.6.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.6.2 Tilde Less-Than-Sign: Justification

+~mincol,colinc,minpad,padchar<str~>

+This justifies the text produced by processing str within a field at least mincol columns wide. str may be divided up into segments with ~;, in which case the spacing is evenly divided between the text segments.

+With no modifiers, the leftmost text segment is left justified in the field, and the rightmost text segment is right justified. If there is only one text element, as a special case, it is right justified. The : modifier causes spacing to be introduced before the first text segment; the @ modifier causes spacing to be added after the last. The minpad parameter (default 0) is the minimum number of padding characters to be output between each segment. The padding character is supplied by padchar, which defaults to the space character. If the total width needed to satisfy these constraints is greater than mincol, then the width used is mincol+k*colinc for the smallest possible non-negative integer value k. colinc defaults to 1, and mincol defaults to 0.

+Note that str may include format directives. All the clauses in str are processed in order; it is the resulting pieces of text that are justified.

+The ~^ directive may be used to terminate processing of the clauses prematurely, in which case only the completely processed clauses are justified.

+If the first clause of a ~< is terminated with ~:; instead of ~;, then it is used in a special way. All of the clauses are processed (subject to ~^, of course), but the first one is not used in performing the spacing and padding. When the padded result has been determined, then if it will fit on the current line of output, it is output, and the text for the first clause is discarded. If, however, the padded text will not fit on the current line, then the text segment for the first clause is output before the padded text. The first clause ought to contain a newline (such as a ~% directive). The first clause is always processed, and so any arguments it refers to will be used; the decision is whether to use the resulting segment of text, not whether to process the first clause. If the ~:; has a prefix parameter n, then the padded text must fit on the current line with n character positions to spare to avoid outputting the first clause's text. For example, the control string

+

+ "~%;; ~{ ~<~%;; ~1:; ~S~>~^ ,~} .~%"
+
+

+can be used to print a list of items separated by commas without breaking items over line boundaries, beginning each line with ;; . The prefix parameter 1 in ~1:; accounts for the width of the comma that will follow the justified item if it is not the last element in the list, or the period if it is. If ~:; has a second prefix parameter, then it is used as the width of the line, thus overriding the natural line width of the output stream. To make the preceding example use a line width of 50, one would write

+

+ "~%;; ~{ ~<~%;; ~1,50:; ~S~>~^ ,~}  .~%"
+
+ If the second argument is not supplied, then format uses the line width of the destination output stream. If this cannot be determined (for example, when producing a string result), then format uses 72 as the line length.

+See also Section 22.3.5.2 (Tilde Less-Than-Sign: Logical Block).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfc.htm new file mode 100644 index 00000000..107fff4b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cfc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.6.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.6.3 Tilde Greater-Than-Sign: End of Justification

+~> terminates a ~<. The consequences of using it elsewhere are undefined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cg.htm new file mode 100644 index 00000000..b4e0c611 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cg.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 22.3.7 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7 FORMAT Control-Flow Operations

+ + +

+22.3.7.1 Tilde Asterisk: Go-To

+ +

+22.3.7.2 Tilde Left-Bracket: Conditional Expression

+ +

+22.3.7.3 Tilde Right-Bracket: End of Conditional Expression

+ +

+22.3.7.4 Tilde Left-Brace: Iteration

+ +

+22.3.7.5 Tilde Right-Brace: End of Iteration

+ +

+22.3.7.6 Tilde Question-Mark: Recursive Processing

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cga.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cga.htm new file mode 100644 index 00000000..38f7a3e7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cga.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 22.3.7.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7.1 Tilde Asterisk: Go-To

+ The next arg is ignored. ~n* ignores the next n arguments.

+~:* backs up in the list of arguments so that the argument last processed will be processed again. ~n:* backs up n arguments.

+When within a ~{ construct (see below), the ignoring (in either direction) is relative to the list of arguments being processed by the iteration.

+~n@* goes to the nth arg, where 0 means the first one; n defaults to 0, so ~@* goes back to the first arg. Directives after a ~n@* will take arguments in sequence beginning with the one gone to. When within a ~{ construct, the ``goto'' is relative to the list of arguments being processed by the iteration.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgb.htm new file mode 100644 index 00000000..691c141b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgb.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section 22.3.7.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7.2 Tilde Left-Bracket: Conditional Expression

+~[str0~;str1~;...~;strn~]

+This is a set of control strings, called clauses, one of which is chosen and used. The clauses are separated by ~; and the construct is terminated by ~]. For example,

+"~[Siamese~;Manx~;Persian~] Cat"

+The argth clause is selected, where the first clause is number 0. If a prefix parameter is given (as ~n[), then the parameter is used instead of an argument. If arg is out of range then no clause is selected and no error is signaled. After the selected alternative has been processed, the control string continues after the ~].

+~[str0~;str1~;...~;strn~:;default~] has a default case. If the last ~; used to separate clauses is ~:; instead, then the last clause is an else clause that is performed if no other clause is selected. For example:

+"~[Siamese~;Manx~;Persian~:;Alley~] Cat"

+~:[alternative~;consequent~] selects the alternative control string if arg is false, and selects the consequent control string otherwise.

+~@[consequent~] tests the argument. If it is true, then the argument is not used up by the ~[ command but remains as the next one to be processed, and the one clause consequent is processed. If the arg is false, then the argument is used up, and the clause is not processed. The clause therefore should normally use exactly one argument, and may expect it to be non-nil. For example:

+

+ (setq *print-level* nil *print-length* 5)
+ (format nil
+        "~@[ print level = ~D~]~@[ print length = ~D~]"
+        *print-level* *print-length*)
+=>   " print length = 5"
+
+

+Note also that

+

+ (format stream "...~@[str~]..." ...)
+==  (format stream "...~:[~;~:*str~]..." ...)
+
+

+The combination of ~[ and # is useful, for example, for dealing with English conventions for printing lists:

+

+ (setq foo "Items:~#[ none~; ~S~; ~S and ~S~
+           ~:;~@{~#[~; and~] ~S~^ ,~}~].")
+ (format nil foo) =>   "Items: none."
+ (format nil foo 'foo) =>   "Items: FOO."
+ (format nil foo 'foo 'bar) =>   "Items: FOO and BAR."
+ (format nil foo 'foo 'bar 'baz) =>   "Items: FOO, BAR, and BAZ."
+ (format nil foo 'foo 'bar 'baz 'quux) =>   "Items: FOO, BAR, BAZ, and QUUX."
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgc.htm new file mode 100644 index 00000000..bfef6709 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.7.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7.3 Tilde Right-Bracket: End of Conditional Expression

+~] terminates a ~[. The consequences of using it elsewhere are undefined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgd.htm new file mode 100644 index 00000000..c5df39e2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgd.htm @@ -0,0 +1,68 @@ + + + +CLHS: Section 22.3.7.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7.4 Tilde Left-Brace: Iteration

+~{str~}

+This is an iteration construct. The argument should be a list, which is used as a set of arguments as if for a recursive call to format. The string str is used repeatedly as the control string. Each iteration can absorb as many elements of the list as it likes as arguments; if str uses up two arguments by itself, then two elements of the list will get used up each time around the loop. If before any iteration step the list is empty, then the iteration is terminated. Also, if a prefix parameter n is given, then there will be at most n repetitions of processing of str. Finally, the ~^ directive can be used to terminate the iteration prematurely.

+For example:

+

+ (format nil "The winners are:~{ ~S~}." 
+         '(fred harry jill)) 
+=>  "The winners are: FRED HARRY JILL."                           
+ (format nil "Pairs:~{ <~S,~S>~}." 
+         '(a 1 b 2 c 3))
+=>  "Pairs: <A,1> <B,2> <C,3>."
+
+

+~:{str~} is similar, but the argument should be a list of sublists. At each repetition step, one sublist is used as the set of arguments for processing str; on the next repetition, a new sublist is used, whether or not all of the last sublist had been processed. For example:

+ +

+ (format nil "Pairs:~:{ <~S,~S>~} ." 
+                 '((a 1) (b 2) (c 3)))
+=>  "Pairs: <A,1> <B,2> <C,3>."
+
+

+~@{str~} is similar to ~{str~}, but instead of using one argument that is a list, all the remaining arguments are used as the list of arguments for the iteration. Example:

+

+ (format nil "Pairs:~@{ <~S,~S>~} ." 'a 1 'b 2 'c 3)
+=>  "Pairs: <A,1> <B,2> <C,3>."
+
+ If the iteration is terminated before all the remaining arguments are consumed, then any arguments not processed by the iteration remain to be processed by any directives following the iteration construct.

+~:@{str~} combines the features of ~:{str~} and ~@{str~}. All the remaining arguments are used, and each one must be a list. On each iteration, the next argument is used as a list of arguments to str. Example:

+

+ (format nil "Pairs:~:@{ <~S,~S>~} ." 
+              '(a 1) '(b 2) '(c 3)) 
+=>  "Pairs: <A,1> <B,2> <C,3>."
+
+ Terminating the repetition construct with ~:} instead of ~} forces str to be processed at least once, even if the initial list of arguments is null. However, this will not override an explicit prefix parameter of zero.

+If str is empty, then an argument is used as str. It must be a format control and precede any arguments processed by the iteration. As an example, the following are equivalent:

+

+    (apply #'format stream string arguments)
+ ==  (format stream "~1{~:}" string arguments)
+
+

+This will use string as a formatting string. The ~1{ says it will be processed at most once, and the ~:} says it will be processed at least once. Therefore it is processed exactly once, using arguments as the arguments. This case may be handled more clearly by the ~? directive, but this general feature of ~{ is more powerful than ~?.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cge.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cge.htm new file mode 100644 index 00000000..8e7c17ca --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cge.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.7.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7.5 Tilde Right-Brace: End of Iteration

+ ~} terminates a ~{. The consequences of using it elsewhere are undefined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgf.htm new file mode 100644 index 00000000..a3ee0a63 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cgf.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 22.3.7.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.7.6 Tilde Question-Mark: Recursive Processing

+The next arg must be a format control, and the one after it a list; both are consumed by the ~? directive. The two are processed as a control-string, with the elements of the list as the arguments. Once the recursive processing has been finished, the processing of the control string containing the ~? directive is resumed. Example:

+

+ (format nil "~? ~D" "<~A ~D>" '("Foo" 5) 7) =>  "<Foo 5> 7"
+ (format nil "~? ~D" "<~A ~D>" '("Foo" 5 14) 7) =>  "<Foo 5> 7"
+
+ Note that in the second example three arguments are supplied to the format string "<~A ~D>", but only two are processed and the third is therefore ignored.

+With the @ modifier, only one arg is directly consumed. The arg must be a string; it is processed as part of the control string as if it had appeared in place of the ~@? construct, and any directives in the recursively processed control string may consume arguments of the control string containing the ~@? directive. Example:

+

+ (format nil "~@? ~D" "<~A ~D>" "Foo" 5 7) =>  "<Foo 5> 7"
+ (format nil "~@? ~D" "<~A ~D>" "Foo" 5 14 7) =>  "<Foo 5> 14"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ch.htm new file mode 100644 index 00000000..9fd9c686 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ch.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 22.3.8 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.8 FORMAT Miscellaneous Operations

+ + +

+22.3.8.1 Tilde Left-Paren: Case Conversion

+ +

+22.3.8.2 Tilde Right-Paren: End of Case Conversion

+ +

+22.3.8.3 Tilde P: Plural

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cha.htm new file mode 100644 index 00000000..29a081e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cha.htm @@ -0,0 +1,51 @@ + + + +CLHS: Section 22.3.8.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.8.1 Tilde Left-Paren: Case Conversion

+~(str~)

+The contained control string str is processed, and what it produces is subject to case conversion.

+With no flags, every uppercase character is converted to the corresponding lowercase character.

+~:( capitalizes all words, as if by string-capitalize.

+~@( capitalizes just the first word and forces the rest to lower case.

+~:@( converts every lowercase character to the corresponding uppercase character.

+In this example ~@( is used to cause the first word produced by ~@R to be capitalized:

+

+ (format nil "~@R ~(~@R~)" 14 14) 
+=>  "XIV xiv"
+ (defun f (n) (format nil "~@(~R~) error~:P detected." n)) =>  F
+ (f 0) =>  "Zero errors detected."
+ (f 1) =>  "One error detected."
+ (f 23) =>  "Twenty-three errors detected."
+
+

+When case conversions appear nested, the outer conversion dominates, as illustrated in the following example:

+

+ (format nil "~@(how is ~:(BOB SMITH~)?~)")
+ =>  "How is bob smith?"
+ NOT=>  "How is Bob Smith?"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chb.htm new file mode 100644 index 00000000..ea5937d3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.8.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.8.2 Tilde Right-Paren: End of Case Conversion

+~) terminates a ~(. The consequences of using it elsewhere are undefined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chc.htm new file mode 100644 index 00000000..1888432d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_chc.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 22.3.8.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.8.3 Tilde P: Plural

+If arg is not eql to the integer 1, a lowercase s is printed; if arg is eql to 1, nothing is printed. If arg is a floating-point 1.0, the s is printed.

+~:P does the same thing, after doing a ~:* to back up one argument; that is, it prints a lowercase s if the previous argument was not 1.

+~@P prints y if the argument is 1, or ies if it is not. ~:@P does the same thing, but backs up first.

+

+ (format nil "~D tr~:@P/~D win~:P" 7 1) =>  "7 tries/1 win"
+ (format nil "~D tr~:@P/~D win~:P" 1 0) =>  "1 try/0 wins"
+ (format nil "~D tr~:@P/~D win~:P" 1 3) =>  "1 try/3 wins"
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ci.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ci.htm new file mode 100644 index 00000000..8a4e5753 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ci.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 22.3.9 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.9 FORMAT Miscellaneous Pseudo-Operations

+ + +

+22.3.9.1 Tilde Semicolon: Clause Separator

+ +

+22.3.9.2 Tilde Circumflex: Escape Upward

+ +

+22.3.9.3 Tilde Newline: Ignored Newline

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cia.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cia.htm new file mode 100644 index 00000000..7f2320b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cia.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.9.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.9.1 Tilde Semicolon: Clause Separator

+This separates clauses in ~[ and ~< constructs. The consequences of using it elsewhere are undefined.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cib.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cib.htm new file mode 100644 index 00000000..d82936f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cib.htm @@ -0,0 +1,64 @@ + + + +CLHS: Section 22.3.9.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.9.2 Tilde Circumflex: Escape Upward

+~^

+This is an escape construct. If there are no more arguments remaining to be processed, then the immediately enclosing ~{ or ~< construct is terminated. If there is no such enclosing construct, then the entire formatting operation is terminated. In the ~< case, the formatting is performed, but no more segments are processed before doing the justification. ~^ may appear anywhere in a ~{ construct.

+

+ (setq donestr "Done.~^ ~D warning~:P.~^ ~D error~:P.")
+=>  "Done.~^ ~D warning~:P.~^ ~D error~:P."
+ (format nil donestr) =>  "Done."
+ (format nil donestr 3) =>  "Done. 3 warnings."
+ (format nil donestr 1 5) =>  "Done. 1 warning. 5 errors."
+
+

+If a prefix parameter is given, then termination occurs if the parameter is zero. (Hence ~^ is equivalent to ~#^.) If two parameters are given, termination occurs if they are equal. If three parameters are given, termination occurs if the first is less than or equal to the second and the second is less than or equal to the third. Of course, this is useless if all the prefix parameters are constants; at least one of them should be a # or a V parameter.

+If ~^ is used within a ~:{ construct, then it terminates the current iteration step because in the standard case it tests for remaining arguments of the current step only; the next iteration step commences immediately. ~:^ is used to terminate the iteration process. ~:^ may be used only if the command it would terminate is ~:{ or ~:@{. The entire iteration process is terminated if and only if the sublist that is supplying the arguments for the current iteration step is the last sublist in the case of ~:{, or the last format argument in the case of ~:@{. ~:^ is not equivalent to ~#:^; the latter terminates the entire iteration if and only if no arguments remain for the current iteration step. For example:

+

+ (format nil "~:{ ~@?~:^ ...~} " '(("a") ("b"))) =>  "a...b"
+
+

+If ~^ appears within a control string being processed under the control of a ~? directive, but not within any ~{ or ~< construct within that string, then the string being processed will be terminated, thereby ending processing of the ~? directive. Processing then continues within the string containing the ~? directive at the point following that directive.

+If ~^ appears within a ~[ or ~( construct, then all the commands up to the ~^ are properly selected or case-converted, the ~[ or ~( processing is terminated, and the outward search continues for a ~{ or ~< construct to be terminated. For example:

+

+ (setq tellstr "~@(~@[~R~]~^ ~A!~)")
+=>  "~@(~@[~R~]~^ ~A!~)"
+ (format nil tellstr 23) =>  "Twenty-three!"
+ (format nil tellstr nil "losers") =>  " Losers!"
+ (format nil tellstr 23 "losers") =>  "Twenty-three losers!"
+
+

+Following are examples of the use of ~^ within a ~< construct.

+

+ (format nil "~15<~S~;~^~S~;~^~S~>" 'foo)
+=>   "            FOO"
+ (format nil "~15<~S~;~^~S~;~^~S~>" 'foo 'bar)
+=>   "FOO         BAR"
+ (format nil "~15<~S~;~^~S~;~^~S~>" 'foo 'bar 'baz)
+=>   "FOO   BAR   BAZ"
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cic.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cic.htm new file mode 100644 index 00000000..b6337e06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cic.htm @@ -0,0 +1,46 @@ + + + +CLHS: Section 22.3.9.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.9.3 Tilde Newline: Ignored Newline

+Tilde immediately followed by a newline ignores the newline and any following non-newline whitespace[1] characters. With a :, the newline is ignored, but any following whitespace[1] is left in place. With an @, the newline is left in place, but any following whitespace[1] is ignored. For example:

+

+ (defun type-clash-error (fn nargs argnum right-type wrong-type)
+   (format *error-output*
+           "~&~S requires its ~:[~:R~;~*~]~ 
+           argument to be of type ~S,~%but it was called ~
+           with an argument of type ~S.~%"
+           fn (eql nargs 1) argnum right-type wrong-type))
+ (type-clash-error 'aref nil 2 'integer 'vector)  prints:
+AREF requires its second argument to be of type INTEGER,
+but it was called with an argument of type VECTOR.
+NIL
+ (type-clash-error 'car 1 1 'list 'short-float)  prints:
+CAR requires its argument to be of type LIST,
+but it was called with an argument of type SHORT-FLOAT.
+NIL
+
+ Note that in this example newlines appear in the output only as specified by the ~& and ~% directives; the actual newline characters in the control string are suppressed because each is preceded by a tilde.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cj.htm new file mode 100644 index 00000000..3682a12c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cj.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 22.3.10 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.10 Additional Information about FORMAT Operations

+ + +

+22.3.10.1 Nesting of FORMAT Operations

+ +

+22.3.10.2 Missing and Additional FORMAT Arguments

+ +

+22.3.10.3 Additional FORMAT Parameters

+ +

+22.3.10.4 Undefined FORMAT Modifier Combinations

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cja.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cja.htm new file mode 100644 index 00000000..e95eb161 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cja.htm @@ -0,0 +1,39 @@ + + + +CLHS: Section 22.3.10.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.10.1 Nesting of FORMAT Operations

+The case-conversion, conditional, iteration, and justification constructs can contain other formatting constructs by bracketing them. These constructs must nest properly with respect to each other. For example, it is not legitimate to put the start of a case-conversion construct in each arm of a conditional and the end of the case-conversion construct outside the conditional:

+

+ (format nil "~:[abc~:@(def~;ghi~
+:@(jkl~]mno~)" x) ;Invalid!
+
+ This notation is invalid because the ~[...~;...~] and ~(...~) constructs are not properly nested.

+The processing indirection caused by the ~? directive is also a kind of nesting for the purposes of this rule of proper nesting. It is not permitted to start a bracketing construct within a string processed under control of a ~? directive and end the construct at some point after the ~? construct in the string containing that construct, or vice versa. For example, this situation is invalid:

+

+ (format nil "~@?ghi~)" "abc~@(def") ;Invalid!
+
+ This notation is invalid because the ~? and ~(...~) constructs are not properly nested.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjb.htm new file mode 100644 index 00000000..024834f1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjb.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.10.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.10.2 Missing and Additional FORMAT Arguments

+The consequences are undefined if no arg remains for a directive requiring an argument. However, it is permissible for one or more args to remain unprocessed by a directive; such args are ignored.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjc.htm new file mode 100644 index 00000000..5104fbe7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjc.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.10.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.10.3 Additional FORMAT Parameters

+The consequences are undefined if a format directive is given more parameters than it is described here as accepting.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjd.htm new file mode 100644 index 00000000..e50f7479 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cjd.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 22.3.10.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.10.4 Undefined FORMAT Modifier Combinations

+The consequences are undefined if colon or at-sign modifiers are given to a directive in a combination not specifically described here as being meaningful.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ck.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ck.htm new file mode 100644 index 00000000..3b5d5d8a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_ck.htm @@ -0,0 +1,128 @@ + + + +CLHS: Section 22.3.11 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.11 Examples of FORMAT

+

+ (format nil "foo") =>  "foo"
+ (setq x 5) =>  5
+ (format nil "The answer is ~D." x) =>  "The answer is 5."
+ (format nil "The answer is ~3D." x) =>  "The answer is   5."
+ (format nil "The answer is ~3,'0D." x) =>  "The answer is 005."
+ (format nil "The answer is ~:D." (expt 47 x))
+=>  "The answer is 229,345,007."
+ (setq y "elephant") =>  "elephant"
+ (format nil "Look at the ~A!" y) =>  "Look at the elephant!"
+ (setq n 3) =>  3
+ (format nil "~D item~:P found." n) =>  "3 items found."
+ (format nil "~R dog~:[s are~; is~] here." n (= n 1))
+=>  "three dogs are here."
+ (format nil "~R dog~:*~[s are~; is~:;s are~] here." n)
+=>  "three dogs are here."
+ (format nil "Here ~[are~;is~:;are~] ~:*~R pupp~:@P." n)
+=>  "Here are three puppies."
+
+ +
+ (defun foo (x)
+   (format nil "~6,2F|~6,2,1,'*F|~6,2,,'?F|~6F|~,2F|~F"
+           x x x x x x)) =>  FOO
+ (foo 3.14159)  =>  "  3.14| 31.42|  3.14|3.1416|3.14|3.14159"
+ (foo -3.14159) =>  " -3.14|-31.42| -3.14|-3.142|-3.14|-3.14159"
+ (foo 100.0)    =>  "100.00|******|100.00| 100.0|100.00|100.0"
+ (foo 1234.0)   =>  "1234.00|******|??????|1234.0|1234.00|1234.0"
+ (foo 0.006)    =>  "  0.01|  0.06|  0.01| 0.006|0.01|0.006"
+
+ +
+ (defun foo (x)  
+    (format nil
+           "~9,2,1,,'*E|~10,3,2,2,'?,,'$E|~
+            ~9,3,2,-2,'%@E|~9,2E"
+           x x x x))
+ (foo 3.14159)  =>  "  3.14E+0| 31.42$-01|+.003E+03|  3.14E+0"
+ (foo -3.14159) =>  " -3.14E+0|-31.42$-01|-.003E+03| -3.14E+0"
+ (foo 1100.0)   =>  "  1.10E+3| 11.00$+02|+.001E+06|  1.10E+3"
+ (foo 1100.0L0) =>  "  1.10L+3| 11.00$+02|+.001L+06|  1.10L+3"
+ (foo 1.1E13)   =>  "*********| 11.00$+12|+.001E+16| 1.10E+13"
+ (foo 1.1L120)  =>  "*********|??????????|%%%%%%%%%|1.10L+120"
+ (foo 1.1L1200) =>  "*********|??????????|%%%%%%%%%|1.10L+1200"
+
+ As an example of the effects of varying the scale factor, the code

+

+ (dotimes (k 13)
+   (format t "~%Scale factor ~2D: |~13,6,2,VE|"
+           (- k 5) (- k 5) 3.14159))
+
+ produces the following output:

+

+Scale factor -5: | 0.000003E+06|
+Scale factor -4: | 0.000031E+05|
+Scale factor -3: | 0.000314E+04|
+Scale factor -2: | 0.003142E+03|
+Scale factor -1: | 0.031416E+02|
+Scale factor  0: | 0.314159E+01|
+Scale factor  1: | 3.141590E+00|
+Scale factor  2: | 31.41590E-01|
+Scale factor  3: | 314.1590E-02|
+Scale factor  4: | 3141.590E-03|
+Scale factor  5: | 31415.90E-04|
+Scale factor  6: | 314159.0E-05|
+Scale factor  7: | 3141590.E-06|
+
+

+

+ (defun foo (x)
+   (format nil "~9,2,1,,'*G|~9,3,2,3,'?,,'$G|~9,3,2,0,'%G|~9,2G"
+          x x x x))                                     
+ (foo 0.0314159) =>  "  3.14E-2|314.2$-04|0.314E-01|  3.14E-2"
+ (foo 0.314159)  =>  "  0.31   |0.314    |0.314    | 0.31    "
+ (foo 3.14159)   =>  "   3.1   | 3.14    | 3.14    |  3.1    "
+ (foo 31.4159)   =>  "   31.   | 31.4    | 31.4    |  31.    "
+ (foo 314.159)   =>  "  3.14E+2| 314.    | 314.    |  3.14E+2"
+ (foo 3141.59)   =>  "  3.14E+3|314.2$+01|0.314E+04|  3.14E+3"
+ (foo 3141.59L0) =>  "  3.14L+3|314.2$+01|0.314L+04|  3.14L+3"
+ (foo 3.14E12)   =>  "*********|314.0$+10|0.314E+13| 3.14E+12"
+ (foo 3.14L120)  =>  "*********|?????????|%%%%%%%%%|3.14L+120"
+ (foo 3.14L1200) =>  "*********|?????????|%%%%%%%%%|3.14L+1200"
+
+

+

+ (format nil "~10<foo~;bar~>")   =>  "foo    bar"
+ (format nil "~10:<foo~;bar~>")  =>  "  foo  bar"
+ (format nil "~10<foobar~>")     =>  "    foobar"
+ (format nil "~10:<foobar~>")    =>  "    foobar"
+ (format nil "~10:@<foo~;bar~>") =>  "  foo bar "
+ (format nil "~10@<foobar~>")    =>  "foobar    "
+ (format nil "~10:@<foobar~>")   =>  "  foobar  "
+
+

+ +

+  (FORMAT NIL "Written to ~A." #P"foo.bin")
+  =>  "Written to foo.bin."
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cl.htm new file mode 100644 index 00000000..921e41b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/22_cl.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section 22.3.12 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.3.12 Notes about FORMAT

+ Formatted output is performed not only by format, but by certain other functions that accept a format control the way format does. For example, error-signaling functions such as cerror accept format controls.

+Note that the meaning of nil and t as destinations to format are different than those of nil and t as stream designators.

+The ~^ should appear only at the beginning of a ~< clause, because it aborts the entire clause in which it appears (as well as all following clauses).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_.htm new file mode 100644 index 00000000..ea882563 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Chapter 23 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+23. Reader

+

+ + +

+23.1 Reader Concepts

+ +

+23.2 The Reader Dictionary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_a.htm new file mode 100644 index 00000000..60167650 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_a.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 23.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1 Reader Concepts

+ + +

+23.1.1 Dynamic Control of the Lisp Reader

+ +

+23.1.2 Effect of Readtable Case on the Lisp Reader

+ +

+23.1.3 Argument Conventions of Some Reader Functions

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aa.htm new file mode 100644 index 00000000..68d90064 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aa.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section 23.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1.1 Dynamic Control of the Lisp Reader

+Various aspects of the Lisp reader can be controlled dynamically. See Section 2.1.1 (Readtables) and Section 2.1.2 (Variables that affect the Lisp Reader).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ab.htm new file mode 100644 index 00000000..8a43389d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ab.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section 23.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1.2 Effect of Readtable Case on the Lisp Reader

+The readtable case of the current readtable affects the Lisp reader in the following ways:

+

:upcase

+ When the readtable case is :upcase, unescaped constituent characters are converted to uppercase, as specified in Section 2.2 (Reader Algorithm).

+

:downcase

+ When the readtable case is :downcase, unescaped constituent characters are converted to lowercase.

+

:preserve

+When the readtable case is :preserve, the case of all characters remains unchanged.

+

:invert

+When the readtable case is :invert, then if all of the unescaped letters in the extended token are of the same case, those (unescaped) letters are converted to the opposite case.

+

+ + +

+23.1.2.1 Examples of Effect of Readtable Case on the Lisp Reader

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aba.htm new file mode 100644 index 00000000..d921b0f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aba.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section 23.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1.2.1 Examples of Effect of Readtable Case on the Lisp Reader

+

+ (defun test-readtable-case-reading ()
+   (let ((*readtable* (copy-readtable nil)))
+     (format t "READTABLE-CASE  Input   Symbol-name~
+              ~%-----------------------------------~
+              ~%")
+     (dolist (readtable-case '(:upcase :downcase :preserve :invert))
+       (setf (readtable-case *readtable*) readtable-case)
+       (dolist (input '("ZEBRA" "Zebra" "zebra"))
+         (format t "~&:~A~16T~A~24T~A"
+                 (string-upcase readtable-case)
+                 input
+                 (symbol-name (read-from-string input)))))))
+
+

+The output from (test-readtable-case-reading) should be as follows:

+

+ READTABLE-CASE     Input Symbol-name
+ -------------------------------------
+    :UPCASE         ZEBRA   ZEBRA
+    :UPCASE         Zebra   ZEBRA
+    :UPCASE         zebra   ZEBRA
+    :DOWNCASE       ZEBRA   zebra
+    :DOWNCASE       Zebra   zebra
+    :DOWNCASE       zebra   zebra
+    :PRESERVE       ZEBRA   ZEBRA
+    :PRESERVE       Zebra   Zebra
+    :PRESERVE       zebra   zebra
+    :INVERT         ZEBRA   zebra
+    :INVERT         Zebra   Zebra
+    :INVERT         zebra   ZEBRA
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ac.htm new file mode 100644 index 00000000..fdc77f25 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_ac.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 23.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1.3 Argument Conventions of Some Reader Functions

+ + +

+23.1.3.1 The EOF-ERROR-P argument

+ +

+23.1.3.2 The RECURSIVE-P argument

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aca.htm new file mode 100644 index 00000000..8be4f024 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_aca.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section 23.1.3.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1.3.1 The EOF-ERROR-P argument

+Eof-error-p in input function calls controls what happens if input is from a file (or any other input source that has a definite end) and the end of the file is reached. If eof-error-p is true (the default), an error of type end-of-file is signaled at end of file. If it is false, then no error is signaled, and instead the function returns eof-value.

+Functions such as read that read the representation of an object rather than a single character always signals an error, regardless of eof-error-p, if the file ends in the middle of an object representation. For example, if a file does not contain enough right parentheses to balance the left parentheses in it, read signals an error. If a file ends in a symbol or a number immediately followed by end-of-file, read reads the symbol or number successfully and when called again will act according to eof-error-p. Similarly, the function read-line successfully reads the last line of a file even if that line is terminated by end-of-file rather than the newline character. Ignorable text, such as lines containing only whitespace[2] or comments, are not considered to begin an object; if read begins to read an expression but sees only such ignorable text, it does not consider the file to end in the middle of an object. Thus an eof-error-p argument controls what happens when the file ends between objects.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_acb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_acb.htm new file mode 100644 index 00000000..c97713ce --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/23_acb.htm @@ -0,0 +1,52 @@ + + + +CLHS: Section 23.1.3.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.1.3.2 The RECURSIVE-P argument

+If recursive-p is supplied and not nil, it specifies that this function call is not an outermost call to read but an embedded call, typically from a reader macro function. It is important to distinguish such recursive calls for three reasons.

+

1. An outermost call establishes the context within which the #n= and #n# syntax is scoped. Consider, for example, the expression

+
+ (cons '#3=(p q r) '(x y . #3#))
+
+ If the single-quote reader macro were defined in this way:

+

+ (set-macro-character #\'       ;incorrect
+    #'(lambda (stream char)
+         (declare (ignore char))
+         (list 'quote (read stream))))
+
+

+then each call to the single-quote reader macro function would establish independent contexts for the scope of read information, including the scope of identifications between markers like ``#3='' and ``#3#''. However, for this expression, the scope was clearly intended to be determined by the outer set of parentheses, so such a definition would be incorrect. The correct way to define the single-quote reader macro uses recursive-p:

+

+ (set-macro-character #\'       ;correct
+    #'(lambda (stream char)
+         (declare (ignore char))
+         (list 'quote (read stream t nil t))))
+
+

+

2. A recursive call does not alter whether the reading process is to preserve whitespace[2] or not (as determined by whether the outermost call was to read or read-preserving-whitespace). Suppose again that single-quote were to be defined as shown above in the incorrect definition. Then a call to read-preserving-whitespace that read the expression 'foo<Space> would fail to preserve the space character following the symbol foo because the single-quote reader macro function calls read, not read-preserving-whitespace, to read the following expression (in this case foo). The correct definition, which passes the value true for recursive-p to read, allows the outermost call to determine whether whitespace[2] is preserved.

+
3. When end-of-file is encountered and the eof-error-p argument is not nil, the kind of error that is signaled may depend on the value of recursive-p. If recursive-p is true, then the end-of-file is deemed to have occurred within the middle of a printed representation; if recursive-p is false, then the end-of-file may be deemed to have occurred between objects rather than within the middle of one.

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_.htm new file mode 100644 index 00000000..767d7114 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 24 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+24. System Construction

+

+ + +

+24.1 System Construction Concepts

+ +

+24.2 The System Construction Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_a.htm new file mode 100644 index 00000000..fa7dac95 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_a.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 24.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+24.1 System Construction Concepts

+ + +

+24.1.1 Loading

+ +

+24.1.2 Features

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aa.htm new file mode 100644 index 00000000..dc9a3f52 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aa.htm @@ -0,0 +1,32 @@ + + + +CLHS: Section 24.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+24.1.1 Loading

+To load a file is to treat its contents as code and execute that code. The file may contain source code or compiled code.

+A file containing source code is called a source file. Loading a source file is accomplished essentially by sequentially reading[2] the forms in the file, evaluating each immediately after it is read.

+A file containing compiled code is called a compiled file. Loading a compiled file is similar to loading a source file, except that the file does not contain text but rather an implementation-dependent representation of pre-digested expressions created by the compiler. Often, a compiled file can be loaded more quickly than a source file. See Section 3.2 (Compilation).

+The way in which a source file is distinguished from a compiled file is implementation-dependent.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_ab.htm new file mode 100644 index 00000000..8ab53317 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_ab.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 24.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+24.1.2 Features

+A feature is an aspect or attribute of Common Lisp, of the implementation, or of the environment. A feature is identified by a symbol.

+A feature is said to be present in a Lisp image if and only if the symbol naming it is an element of the list held by the variable *features*, which is called the features list.

+ + +

+24.1.2.1 Feature Expressions

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aba.htm new file mode 100644 index 00000000..481dd5fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_aba.htm @@ -0,0 +1,43 @@ + + + +CLHS: Section 24.1.2.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+24.1.2.1 Feature Expressions

+Boolean combinations of features, called feature expressions, are used by the #+ and #- reader macros in order to direct conditional reading of expressions by the Lisp reader.

+The rules for interpreting a feature expression are as follows:

+

+

feature

+If a symbol naming a feature is used as a feature expression, the feature expression succeeds if that feature is present; otherwise it fails.

+

(not feature-conditional)

+A not feature expression succeeds if its argument feature-conditional fails; otherwise, it succeeds.

+

(and feature-conditional*)

+An and feature expression succeeds if all of its argument feature-conditionals succeed; otherwise, it fails.

+

(or feature-conditional*)

+An or feature expression succeeds if any of its argument feature-conditionals succeed; otherwise, it fails.

+

+ + +

+24.1.2.1.1 Examples of Feature Expressions

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_abaa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_abaa.htm new file mode 100644 index 00000000..47dfa4fb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/24_abaa.htm @@ -0,0 +1,59 @@ + + + +CLHS: Section 24.1.2.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+24.1.2.1.1 Examples of Feature Expressions

For example, suppose that in implementation A, the features spice and perq are present, but the feature lispm is not present; in implementation B, the feature lispm is present, but the features spice and perq are not present; and in implementation C, none of the features spice, lispm, or perq are present. The next figure shows some sample expressions, and how they would be read[2] in these implementations.

+

+(cons #+spice "Spice" #-spice "Lispm" x)                             
+                                                      
+in implementation A ...  (CONS "Spice" X)             
+in implementation B ...  (CONS "Lispm" X)             
+in implementation C ...  (CONS "Lispm" X)             
+                                                      
+(cons #+spice "Spice" #+LispM "Lispm" x)                             
+                                                      
+in implementation A ...  (CONS "Spice" X)             
+in implementation B ...  (CONS "Lispm" X)             
+in implementation C ...  (CONS X)                     
+                                                      
+(setq a '(1 2 #+perq 43 #+(not perq) 27))                             
+                                                      
+in implementation A ...  (SETQ A '(1 2 43))           
+in implementation B ...  (SETQ A '(1 2 27))           
+in implementation C ...  (SETQ A '(1 2 27))           
+                                                      
+(let ((a 3) #+(or spice lispm) (b 3)) (foo a))                             
+                                                      
+in implementation A ...  (LET ((A 3) (B 3)) (FOO A))  
+in implementation B ...  (LET ((A 3) (B 3)) (FOO A))  
+in implementation C ...  (LET ((A 3)) (FOO A))        
+                                                      
+(cons #+Lispm "#+Spice" #+Spice "foo" #-(or Lispm Spice) 7 x)                             
+                                                      
+in implementation A ...  (CONS "foo" X)               
+in implementation B ...  (CONS "#+Spice" X)           
+in implementation C ...  (CONS 7 X)                   
+
+

Figure 24-1. Features examples

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_.htm new file mode 100644 index 00000000..b3d7cf0e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_.htm @@ -0,0 +1,39 @@ + + + +CLHS: Chapter 25 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+25. Environment

+

+ + +

+25.1 The External Environment

+ +

+25.2 The Environment Dictionary

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_a.htm new file mode 100644 index 00000000..16e11c17 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_a.htm @@ -0,0 +1,40 @@ + + + +CLHS: Section 25.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1 The External Environment

+ + +

+25.1.1 Top level loop

+ +

+25.1.2 Debugging Utilities

+ +

+25.1.3 Environment Inquiry

+ +

+25.1.4 Time

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_aa.htm new file mode 100644 index 00000000..0b36081e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_aa.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 25.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.1 Top level loop

The top level loop is the Common Lisp mechanism by which the user normally interacts with the Common Lisp system. This loop is sometimes referred to as the Lisp read-eval-print loop because it typically consists of an endless loop that reads an expression, evaluates it and prints the results.

+The top level loop is not completely specified; thus the user interface is implementation-defined. The top level loop prints all values resulting from the evaluation of a form. The next figure lists variables that are maintained by the Lisp read-eval-print loop.

+

+*    +    /    -  
+**   ++   //      
+***  +++  ///     
+
+

Figure 25-1. Variables maintained by the Read-Eval-Print Loop

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ab.htm new file mode 100644 index 00000000..589a5eb6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ab.htm @@ -0,0 +1,37 @@ + + + +CLHS: Section 25.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.2 Debugging Utilities

+The next figure shows defined names relating to debugging.

+

+*debugger-hook*  documentation    step     
+apropos          dribble          time     
+apropos-list     ed               trace    
+break            inspect          untrace  
+describe         invoke-debugger           
+
+

Figure 25-2. Defined names relating to debugging

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ac.htm new file mode 100644 index 00000000..0225386c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ac.htm @@ -0,0 +1,36 @@ + + + +CLHS: Section 25.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.3 Environment Inquiry

Environment inquiry defined names provide information about the hardware and software configuration on which a Common Lisp program is being executed.

+The next figure shows defined names relating to environment inquiry.

+

+*features*                   machine-instance  short-site-name   
+lisp-implementation-type     machine-type      software-type     
+lisp-implementation-version  machine-version   software-version  
+long-site-name               room                                
+
+

Figure 25-3. Defined names relating to environment inquiry.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ad.htm new file mode 100644 index 00000000..b376aba1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ad.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section 25.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.4 Time

+Time is represented in four different ways in Common Lisp: decoded time, universal time, internal time, and seconds. Decoded time and universal time are used primarily to represent calendar time, and are precise only to one second. Internal time is used primarily to represent measurements of computer time (such as run time) and is precise to some implementation-dependent fraction of a second called an internal time unit, as specified by internal-time-units-per-second. An internal time can be used for either absolute and relative time measurements. Both a universal time and a decoded time can be used only for absolute time measurements. In the case of one function, sleep, time intervals are represented as a non-negative real number of seconds.

+The next figure shows defined names relating to time.

+

+decode-universal-time   get-internal-run-time           
+encode-universal-time   get-universal-time              
+get-decoded-time        internal-time-units-per-second  
+get-internal-real-time  sleep                           
+
+

Figure 25-4. Defined names involving Time.

+ + +

+25.1.4.1 Decoded Time

+ +

+25.1.4.2 Universal Time

+ +

+25.1.4.3 Internal Time

+ +

+25.1.4.4 Seconds

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ada.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ada.htm new file mode 100644 index 00000000..75aea64a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_ada.htm @@ -0,0 +1,53 @@ + + + +CLHS: Section 25.1.4.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.4.1 Decoded Time

+A decoded time is an ordered series of nine values that, taken together, represent a point in calendar time (ignoring leap seconds):

+

Second

+An integer between 0 and 59, inclusive.

+

Minute

+An integer between 0 and 59, inclusive.

+

Hour

+An integer between 0 and 23, inclusive.

+

Date

+An integer between 1 and 31, inclusive (the upper limit actually depends on the month and year, of course).

+

Month

+An integer between 1 and 12, inclusive; 1 means January, 2 means February, and so on; 12 means December.

+

Year

+An integer indicating the year A.D. However, if this integer is between 0 and 99, the ``obvious'' year is used; more precisely, that year is assumed that is equal to the integer modulo 100 and within fifty years of the current year (inclusive backwards and exclusive forwards). Thus, in the year 1978, year 28 is 1928 but year 27 is 2027. (Functions that return time in this format always return a full year number.)

+

Day of week

+An integer between 0 and 6, inclusive; 0 means Monday, 1 means Tuesday, and so on; 6 means Sunday.

+

Daylight saving time flag

+A generalized boolean that, if true, indicates that daylight saving time is in effect.

+

Time zone

+A time zone.

+

+The next figure shows defined names relating to decoded time.

+

+decode-universal-time  get-decoded-time  
+
+

Figure 25-5. Defined names involving time in Decoded Time.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adb.htm new file mode 100644 index 00000000..8635b68b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adb.htm @@ -0,0 +1,34 @@ + + + +CLHS: Section 25.1.4.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.4.2 Universal Time

+Universal time is an absolute time represented as a single non-negative integer---the number of seconds since midnight, January 1, 1900 GMT (ignoring leap seconds). Thus the time 1 is 00:00:01 (that is, 12:00:01 a.m.) on January 1, 1900 GMT. Similarly, the time 2398291201 corresponds to time 00:00:01 on January 1, 1976 GMT. Recall that the year 1900 was not a leap year; for the purposes of Common Lisp, a year is a leap year if and only if its number is divisible by 4, except that years divisible by 100 are not leap years, except that years divisible by 400 are leap years. Therefore the year 2000 will be a leap year. Because universal time must be a non-negative integer, times before the base time of midnight, January 1, 1900 GMT cannot be processed by Common Lisp.

+

+decode-universal-time  get-universal-time  
+encode-universal-time                      
+
+

Figure 25-6. Defined names involving time in Universal Time.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adc.htm new file mode 100644 index 00000000..db8236b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_adc.htm @@ -0,0 +1,35 @@ + + + +CLHS: Section 25.1.4.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.4.3 Internal Time

+Internal time represents time as a single integer, in terms of an implementation-dependent unit called an internal time unit. Relative time is measured as a number of these units. Absolute time is relative to an arbitrary time base.

+The next figure shows defined names related to internal time.

+

+get-internal-real-time  internal-time-units-per-second  
+get-internal-run-time                                   
+
+

Figure 25-7. Defined names involving time in Internal Time.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_add.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_add.htm new file mode 100644 index 00000000..7a0dfab7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/25_add.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section 25.1.4.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.1.4.4 Seconds

+One function, sleep, takes its argument as a non-negative real number of seconds. Informally, it may be useful to think of this as a relative universal time, but it differs in one important way: universal times are always non-negative integers, whereas the argument to sleep can be any kind of non-negative real, in order to allow for the possibility of fractional seconds.

+

+sleep    
+
+

Figure 25-8. Defined names involving time in Seconds.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_.htm new file mode 100644 index 00000000..fca33af4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_.htm @@ -0,0 +1,35 @@ + + + +CLHS: Chapter 26 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+26. Glossary

+

+ + +

+26.1 Glossary

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_a.htm new file mode 100644 index 00000000..8b89ab28 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_a.htm @@ -0,0 +1,84 @@ + + + +CLHS: Section 26.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+26.1 Glossary

+

+

+

+

+ + +Glossary Notation

+

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Index of Glossary Tabs:

Non-alphabetic
A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V | W | Y

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_9.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_9.htm new file mode 100644 index 00000000..69a12286 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_9.htm @@ -0,0 +1,28 @@ + + + +CLHS: Glossary-Section Non-alphabetic + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Non-alphabetic

+

() ['nil], n. an alternative notation for writing the symbol nil, used to emphasize the use of nil as an empty list.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_a.htm new file mode 100644 index 00000000..6ae8dc10 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_a.htm @@ -0,0 +1,70 @@ + + + +CLHS: Glossary-Section A + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +A

+

absolute adj. 1. (of a time) representing a specific point in time. 2. (of a pathname) representing a specific position in a directory hierarchy. See relative.

+

access n., v.t. 1. v.t. (a place, or array) to read[1] or write[1] the value of the place or an element of the array. 2. n. (of a place) an attempt to access[1] the value of the place.

+

accessibility n. the state of being accessible.

+

accessible adj. 1. (of an object) capable of being referenced. 2. (of shared slots or local slots in an instance of a class) having been defined by the class of the instance or inherited from a superclass of that class. 3. (of a symbol in a package) capable of being referenced without a package prefix when that package is current, regardless of whether the symbol is present in that package or is inherited.

+

accessor n. an operator that performs an access. See reader and writer.

+

active adj. 1. (of a handler, a restart, or a catch tag) having been established but not yet disestablished. 2. (of an element of an array) having an index that is greater than or equal to zero, but less than the fill pointer (if any). For an array that has no fill pointer, all elements are considered active.

+

actual adjustability n. (of an array) a generalized boolean that is associated with the array, representing whether the array is actually adjustable. See also expressed adjustability and adjustable-array-p.

+

actual argument n. Trad. an argument.

+

actual array element type n. (of an array) the type for which the array is actually specialized, which is the upgraded array element type of the expressed array element type of the array. See the function array-element-type.

+

actual complex part type n. (of a complex) the type in which the real and imaginary parts of the complex are actually represented, which is the upgraded complex part type of the expressed complex part type of the complex.

+

actual parameter n. Trad. an argument.

+

actually adjustable adj. (of an array) such that adjust-array can adjust its characteristics by direct modification. A conforming program may depend on an array being actually adjustable only if either that array is known to have been expressly adjustable or if that array has been explicitly tested by adjustable-array-p.

+

adjustability n. (of an array) 1. expressed adjustability. 2. actual adjustability.

+

adjustable adj. (of an array) 1. expressly adjustable. 2. actually adjustable.

+

after method n. a method having the qualifier :after.

+

alist ['ay,list], n. an association list.

+

alphabetic n., adj. 1. adj. (of a character) being one of the standard characters A through Z or a through z, or being any implementation-defined character that has case, or being some other graphic character defined by the implementation to be alphabetic[1]. 2. a. n. one of several possible constituent traits of a character. For details, see Section 2.1.4.1 (Constituent Characters) and Section 2.2 (Reader Algorithm). b. adj. (of a character) being a character that has syntax type constituent in the current readtable and that has the constituent trait alphabetic[2a]. See Figure 2-8.

+

alphanumeric adj. (of a character) being either an alphabetic[1] character or a numeric character.

+

ampersand n. the standard character that is called ``ampersand'' (&). See Figure 2-5.

+

anonymous adj. 1. (of a class or function) having no name 2. (of a restart) having a name of nil.

+

apparently uninterned adj. having a home package of nil. (An apparently uninterned symbol might or might not be an uninterned symbol. Uninterned symbols have a home package of nil, but symbols which have been uninterned from their home package also have a home package of nil, even though they might still be interned in some other package.)

+

applicable adj. 1. (of a handler) being an applicable handler. 2. (of a method) being an applicable method. 3. (of a restart) being an applicable restart.

+

applicable handler n. (for a condition being signaled) an active handler for which the associated type contains the condition.

+

applicable method n. (of a generic function called with arguments) a method of the generic function for which the arguments satisfy the parameter specializers of that method. See Section 7.6.6.1.1 (Selecting the Applicable Methods).

+

applicable restart n. 1. (for a condition) an active handler for which the associated test returns true when given the condition as an argument. 2. (for no particular condition) an active handler for which the associated test returns true when given nil as an argument.

+

apply v.t. (a function to a list) to call the function with arguments that are the elements of the list. ``Applying the function + to a list of integers returns the sum of the elements of that list.''

+

argument n. 1. (of a function) an object which is offered as data to the function when it is called. 2. (of a format control) a format argument.

+

argument evaluation order n. the order in which arguments are evaluated in a function call. ``The argument evaluation order for Common Lisp is left to right.'' See Section 3.1 (Evaluation).

+

argument precedence order n. the order in which the arguments to a generic function are considered when sorting the applicable methods into precedence order.

+

around method n. a method having the qualifier :around.

+

array n. an object of type array, which serves as a container for other objects arranged in a Cartesian coordinate system.

+

array element type n. (of an array) 1. a type associated with the array, and of which all elements of the array are constrained to be members. 2. the actual array element type of the array. 3. the expressed array element type of the array.

+

array total size n. the total number of elements in an array, computed by taking the product of the dimensions of the array. (The size of a zero-dimensional array is therefore one.)

+

assign v.t. (a variable) to change the value of the variable in a binding that has already been established. See the special operator setq.

+

association list n. a list of conses representing an association of keys with values, where the car of each cons is the key and the cdr is the value associated with that key.

+

asterisk n. the standard character that is variously called ``asterisk'' or ``star'' (*). See Figure 2-5.

+

at-sign n. the standard character that is variously called ``commercial at'' or ``at sign'' (@). See Figure 2-5.

+

atom n. any object that is not a cons. ``A vector is an atom.''

+

atomic adj. being an atom. ``The number 3, the symbol foo, and nil are atomic.''

+

atomic type specifier n. a type specifier that is atomic. For every atomic type specifier, x, there is an equivalent compound type specifier with no arguments supplied, (x).

+

attribute n. (of a character) a program-visible aspect of the character. The only standardized attribute of a character is its code[2], but implementations are permitted to have additional implementation-defined attributes. See Section 13.1.3 (Character Attributes). ``An implementation that support fonts might make font information an attribute of a character, while others might represent font information separately from characters.''

+

aux variable n. a variable that occurs in the part of a lambda list that was introduced by &aux. Unlike all other variables introduced by a lambda-list, aux variables are not parameters.

+

auxiliary method n. a member of one of two sets of methods (the set of primary methods is the other) that form an exhaustive partition of the set of methods on the method's generic function. How these sets are determined is dependent on the method combination type; see Section 7.6.2 (Introduction to Methods).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_b.htm new file mode 100644 index 00000000..4e423ea1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_b.htm @@ -0,0 +1,57 @@ + + + +CLHS: Glossary-Section B + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +B

+

backquote n. the standard character that is variously called ``grave accent'' or ``backquote'' (`). See Figure 2-5.

+

backslash n. the standard character that is variously called ``reverse solidus'' or ``backslash'' (\). See Figure 2-5.

+

base character n. a character of type base-char.

+

base string n. a string of type base-string.

+

before method n. a method having the qualifier :before.

+

bidirectional adj. (of a stream) being both an input stream and an output stream.

+

binary adj. 1. (of a stream) being a stream that has an element type that is a subtype of type integer. The most fundamental operation on a binary input stream is read-byte and on a binary output stream is write-byte. See character. 2. (of a file) having been created by opening a binary stream. (It is implementation-dependent whether this is an detectable aspect of the file, or whether any given character file can be treated as a binary file.)

+

bind v.t. (a variable) to establish a binding for the variable.

+

binding n. an association between a name and that which the name denotes. ``A lexical binding is a lexical association between a name and its value.'' When the term binding is qualified by the name of a namespace, such as ``variable'' or ``function,'' it restricts the binding to the indicated namespace, as in: ``let establishes variable bindings.'' or ``let establishes bindings of variables.''

+

bit n. an object of type bit; that is, the integer 0 or the integer 1.

+

bit array n. a specialized array that is of type (array bit), and whose elements are of type bit.

+

bit vector n. a specialized vector that is of type bit-vector, and whose elements are of type bit.

+

bit-wise logical operation specifier n. an object which names one of the sixteen possible bit-wise logical operations that can be performed by the boole function, and which is the value of exactly one of the constant variables boole-clr, boole-set, boole-1, boole-2, boole-c1, boole-c2, boole-and, boole-ior, boole-xor, boole-eqv, boole-nand, boole-nor, boole-andc1, boole-andc2, boole-orc1, or boole-orc2.

+

block n. a named lexical exit point, established explicitly by block or implicitly by operators such as loop, do and prog, to which control and values may be transfered by using a return-from form with the name of the block.

+

block tag n. the symbol that, within the lexical scope of a block form, names the block established by that block form. See return or return-from.

+

boa lambda list n. a lambda list that is syntactically like an ordinary lambda list, but that is processed in ``by order of argument'' style. See Section 3.4.6 (Boa Lambda Lists).

+

body parameter n. a parameter available in certain lambda lists which from the point of view of conforming programs is like a rest parameter in every way except that it is introduced by &body instead of &rest. (Implementations are permitted to provide extensions which distinguish body parameters and rest parameters---e.g., the forms for operators which were defined using a body parameter might be pretty printed slightly differently than forms for operators which were defined using rest parameters.)

+

boolean n. an object of type boolean; that is, one of the following objects: the symbol t (representing true), or the symbol nil (representing false). See generalized boolean.

+

boolean equivalent n. (of an object O1) any object O2 that has the same truth value as O1 when both O1 and O2 are viewed as generalized booleans.

+

bound adj., v.t. 1. adj. having an associated denotation in a binding. ``The variables named by a let are bound within its body.'' See unbound. 2. adj. having a local binding which shadows[2] another. ``The variable *print-escape* is bound while in the princ function.'' 3. v.t. the past tense of bind.

+

bound declaration n. a declaration that refers to or is associated with a variable or function and that appears within the special form that establishes the variable or function, but before the body of that special form (specifically, at the head of that form's body). (If a bound declaration refers to a function binding or a lexical variable binding, the scope of the declaration is exactly the scope of that binding. If the declaration refers to a dynamic variable binding, the scope of the declaration is what the scope of the binding would have been if it were lexical rather than dynamic.)

+

bounded adj. (of a sequence S, by an ordered pair of bounding indices istart and iend) restricted to a subrange of the elements of S that includes each element beginning with (and including) the one indexed by istart and continuing up to (but not including) the one indexed by iend.

+

bounding index n. (of a sequence with length n) either of a conceptual pair of integers, istart and iend, respectively called the ``lower bounding index'' and ``upper bounding index'', such that 0 <=istart <=iend <=n, and which therefore delimit a subrange of the sequence bounded by istart and iend.

+

bounding index designator (for a sequence) one of two objects that, taken together as an ordered pair, behave as a designator for bounding indices of the sequence; that is, they denote bounding indices of the sequence, and are either: an integer (denoting itself) and nil (denoting the length of the sequence), or two integers (each denoting themselves).

+

break loop n. A variant of the normal Lisp read-eval-print loop that is recursively entered, usually because the ongoing evaluation of some other form has been suspended for the purpose of debugging. Often, a break loop provides the ability to exit in such a way as to continue the suspended computation. See the function break.

+

broadcast stream n. an output stream of type broadcast-stream.

+

built-in class n. a class that is a generalized instance of class built-in-class.

+

built-in type n. one of the types in Figure 4-2.

+

byte n. 1. adjacent bits within an integer. (The specific number of bits can vary from point to point in the program; see the function byte.) 2. an integer in a specified range. (The specific range can vary from point to point in the program; see the functions open and write-byte.)

+

byte specifier n. An object of implementation-dependent nature that is returned by the function byte and that specifies the range of bits in an integer to be used as a byte by functions such as ldb.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_c.htm new file mode 100644 index 00000000..33e755db --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_c.htm @@ -0,0 +1,108 @@ + + + +CLHS: Glossary-Section C + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +C

+

cadr ['ka,duhr], n. (of an object) the car of the cdr of that object.

+

call v.t., n. 1. v.t. (a function with arguments) to cause the code represented by that function to be executed in an environment where bindings for the values of its parameters have been established based on the arguments. ``Calling the function + with the arguments 5 and 1 yields a value of 6.'' 2. n. a situation in which a function is called.

+

captured initialization form n. an initialization form along with the lexical environment in which the form that defined the initialization form was evaluated. ``Each newly added shared slot is set to the result of evaluating the captured initialization form for the slot that was specified in the defclass form for the new class.''

+

car n. 1. a. (of a cons) the component of a cons corresponding to the first argument to cons; the other component is the cdr. ``The function rplaca modifies the car of a cons.'' b. (of a list) the first element of the list, or nil if the list is the empty list. 2. the object that is held in the car[1]. ``The function car returns the car of a cons.''

+

case n. (of a character) the property of being either uppercase or lowercase. Not all characters have case. ``The characters #\A and #\a have case, but the character #\$ has no case.'' See Section 13.1.4.3 (Characters With Case) and the function both-case-p.

+

case sensitivity mode n. one of the symbols :upcase, :downcase, :preserve, or :invert.

+

catch n. an exit point which is established by a catch form within the dynamic scope of its body, which is named by a catch tag, and to which control and values may be thrown.

+

catch tag n. an object which names an active catch. (If more than one catch is active with the same catch tag, it is only possible to throw to the innermost such catch because the outer one is shadowed[2].)

+

cddr ['kduh,duhr] or ['kuh,dduhr], n. (of an object) the cdr of the cdr of that object.

+

cdr ['k,duhr], n. 1. a. (of a cons) the component of a cons corresponding to the second argument to cons; the other component is the car. ``The function rplacd modifies the cdr of a cons.'' b. (of a list L1) either the list L2 that contains the elements of L1 that follow after the first, or else nil if L1 is the empty list. 2. the object that is held in the cdr[1]. ``The function cdr returns the cdr of a cons.''

+

cell n. Trad. (of an object) a conceptual slot of that object. The dynamic variable and global function bindings of a symbol are sometimes referred to as its value cell and function cell, respectively.

+

character n., adj. 1. n. an object of type character; that is, an object that represents a unitary token in an aggregate quantity of text; see Section 13.1 (Character Concepts). 2. adj. a. (of a stream) having an element type that is a subtype of type character. The most fundamental operation on a character input stream is read-char and on a character output stream is write-char. See binary. b. (of a file) having been created by opening a character stream. (It is implementation-dependent whether this is an inspectable aspect of the file, or whether any given binary file can be treated as a character file.)

+

character code n. 1. one of possibly several attributes of a character. 2. a non-negative integer less than the value of char-code-limit that is suitable for use as a character code[1].

+

character designator n. a designator for a character; that is, an object that denotes a character and that is one of: a designator for a string of length one (denoting the character that is its only element), or a character (denoting itself).

+

circular adj. 1. (of a list) a circular list. 2. (of an arbitrary object) having a component, element, constituent[2], or subexpression (as appropriate to the context) that is the object itself.

+

circular list n. a chain of conses that has no termination because some cons in the chain is the cdr of a later cons.

+

class n. 1. an object that uniquely determines the structure and behavior of a set of other objects called its direct instances, that contributes structure and behavior to a set of other objects called its indirect instances, and that acts as a type specifier for a set of objects called its generalized instances. ``The class integer is a subclass of the class number.'' (Note that the phrase ``the class foo'' is often substituted for the more precise phrase ``the class named foo''---in both cases, a class object (not a symbol) is denoted.) 2. (of an object) the uniquely determined class of which the object is a direct instance. See the function class-of. ``The class of the object returned by gensym is symbol.'' (Note that with this usage a phrase such as ``its class is foo'' is often substituted for the more precise phrase ``its class is the class named foo''---in both cases, a class object (not a symbol) is denoted.)

+

class designator n. a designator for a class; that is, an object that denotes a class and that is one of: a symbol (denoting the class named by that symbol; see the function find-class) or a class (denoting itself).

+

class precedence list n. a unique total ordering on a class and its superclasses that is consistent with the local precedence orders for the class and its superclasses. For detailed information, see Section 4.3.5 (Determining the Class Precedence List).

+

close v.t. (a stream) to terminate usage of the stream as a source or sink of data, permitting the implementation to reclaim its internal data structures, and to free any external resources which might have been locked by the stream when it was opened.

+

closed adj. (of a stream) having been closed (see <I>}</I>close). Some (but not all) operations that are valid on open streams are not valid on closed streams. See Section 21.1.1.1.2 (Open and Closed Streams).

+

closure n. a lexical closure.

+

coalesce v.t. (literal objects that are similar) to consolidate the identity of those objects, such that they become the same object. See Section 3.2.1 (Compiler Terminology).

+

code n. 1. Trad. any representation of actions to be performed, whether conceptual or as an actual object, such as forms, lambda expressions, objects of type function, text in a source file, or instruction sequences in a compiled file. This is a generic term; the specific nature of the representation depends on its context. 2. (of a character) a character code.

+

coerce v.t. (an object to a type) to produce an object from the given object, without modifying that object, by following some set of coercion rules that must be specifically stated for any context in which this term is used. The resulting object is necessarily of the indicated type, except when that type is a subtype of type complex; in that case, if a complex rational with an imaginary part of zero would result, the result is a rational rather than a complex---see Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals).

+

colon n. the standard character that is called ``colon'' (:). See Figure 2-5.

+

comma n. the standard character that is called ``comma'' (,). See Figure 2-5.

+

compilation n. the process of compiling code by the compiler.

+

compilation environment n. 1. An environment that represents information known by the compiler about a form that is being compiled. See Section 3.2.1 (Compiler Terminology). 2. An object that represents the compilation environment[1] and that is used as a second argument to a macro function (which supplies a value for any &environment parameter in the macro function's definition).

+

compilation unit n. an interval during which a single unit of compilation is occurring. See the macro with-compilation-unit.

+

compile v.t. 1. (code) to perform semantic preprocessing of the code, usually optimizing one or more qualities of the code, such as run-time speed of execution or run-time storage usage. The minimum semantic requirements of compilation are that it must remove all macro calls and arrange for all load time values to be resolved prior to run time. 2. (a function) to produce a new object of type compiled-function which represents the result of compiling the code represented by the function. See the function compile. 3. (a source file) to produce a compiled file from a source file. See the function compile-file.

+

compile time n. the duration of time that the compiler is processing source code.

+

compile-time definition n. a definition in the compilation environment.

+

compiled code n. 1. compiled functions. 2. code that represents compiled functions, such as the contents of a compiled file.

+

compiled file n. a file which represents the results of compiling the forms which appeared in a corresponding source file, and which can be loaded. See the function compile-file.

+

compiled function n. an object of type compiled-function, which is a function that has been compiled, which contains no references to macros that must be expanded at run time, and which contains no unresolved references to load time values.

+

compiler n. a facility that is part of Lisp and that translates code into an implementation-dependent form that might be represented or executed efficiently. The functions compile and compile-file permit programs to invoke the compiler.

+

compiler macro n. an auxiliary macro definition for a globally defined function or macro which might or might not be called by any given conforming implementation and which must preserve the semantics of the globally defined function or macro but which might perform some additional optimizations. (Unlike a macro, a compiler macro does not extend the syntax of Common Lisp; rather, it provides an alternate implementation strategy for some existing syntax or functionality.)

+

compiler macro expansion n. 1. the process of translating a form into another form by a compiler macro. 2. the form resulting from this process.

+

compiler macro form n. a function form or macro form whose operator has a definition as a compiler macro, or a funcall form whose first argument is a function form whose argument is the name of a function that has a definition as a compiler macro.

+

compiler macro function n. a function of two arguments, a form and an environment, that implements compiler macro expansion by producing either a form to be used in place of the original argument form or else nil, indicating that the original form should not be replaced. See Section 3.2.2.1 (Compiler Macros).

+

complex n. an object of type complex.

+

complex float n. an object of type complex which has a complex part type that is a subtype of float. A complex float is a complex, but it is not a float.

+

complex part type n. (of a complex) 1. the type which is used to represent both the real part and the imaginary part of the complex. 2. the actual complex part type of the complex. 3. the expressed complex part type of the complex.

+

complex rational n. an object of type complex which has a complex part type that is a subtype of rational. A complex rational is a complex, but it is not a rational. No complex rational has an imaginary part of zero because such a number is always represented by Common Lisp as an object of type rational; see Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals).

+

complex single float n. an object of type complex which has a complex part type that is a subtype of single-float. A complex single float is a complex, but it is not a single float.

+

composite stream n. a stream that is composed of one or more other streams. ``make-synonym-stream creates a composite stream.''

+

compound form n. a non-empty list which is a form: a special form, a lambda form, a macro form, or a function form.

+

compound type specifier n. a type specifier that is a cons; i.e., a type specifier that is not an atomic type specifier. ``(vector single-float) is a compound type specifier.''

+

concatenated stream n. an input stream of type concatenated-stream.

+

condition n. 1. an object which represents a situation---usually, but not necessarily, during signaling. 2. an object of type condition.

+

condition designator n. one or more objects that, taken together, denote either an existing condition object or a condition object to be implicitly created. For details, see Section 9.1.2.1 (Condition Designators).

+

condition handler n. a function that might be invoked by the act of signaling, that receives the condition being signaled as its only argument, and that is permitted to handle the condition or to decline. See Section 9.1.4.1 (Signaling).

+

condition reporter n. a function that describes how a condition is to be printed when the Lisp printer is invoked while *print-escape* is false. See Section 9.1.3 (Printing Conditions).

+

conditional newline n. a point in output where a newline might be inserted at the discretion of the pretty printer. There are four kinds of conditional newlines, called ``linear-style,'' ``fill-style,'' ``miser-style,'' and ``mandatory-style.'' See the function pprint-newline and Section 22.2.1.1 (Dynamic Control of the Arrangement of Output).

+

conformance n. a state achieved by proper and complete adherence to the requirements of this specification. See Section 1.5 (Conformance).

+

conforming code n. code that is all of part of a conforming program.

+

conforming implementation n. an implementation, used to emphasize complete and correct adherance to all conformance criteria. A conforming implementation is capable of accepting a conforming program as input, preparing that program for execution, and executing the prepared program in accordance with this specification. An implementation which has been extended may still be a conforming implementation provided that no extension interferes with the correct function of any conforming program.

+

conforming processor n. ANSI a conforming implementation.

+

conforming program n. a program, used to emphasize the fact that the program depends for its correctness only upon documented aspects of Common Lisp, and can therefore be expected to run correctly in any conforming implementation.

+

congruent n. conforming to the rules of lambda list congruency, as detailed in Section 7.6.4 (Congruent Lambda-lists for all Methods of a Generic Function).

+

cons n.v. 1. n. a compound data object having two components called the car and the cdr. 2. v. to create such an object. 3. v. Idiom. to create any object, or to allocate storage.

+

constant n. 1. a constant form. 2. a constant variable. 3. a constant object. 4. a self-evaluating object.

+

constant form n. any form for which evaluation always yields the same value, that neither affects nor is affected by the environment in which it is evaluated (except that it is permitted to refer to the names of constant variables defined in the environment), and that neither affects nor is affected by the state of any object except those objects that are otherwise inaccessible parts of objects created by the form itself. ``A car form in which the argument is a quote form is a constant form.''

+

constant object n. an object that is constrained (e.g., by its context in a program or by the source from which it was obtained) to be immutable. ``A literal object that has been processed by compile-file is a constant object.''

+

constant variable n. a variable, the value of which can never change; that is, a keyword[1] or a named constant. ``The symbols t, nil, :direction, and most-positive-fixnum are constant variables.''

+

constituent n., adj. 1. a. n. the syntax type of a character that is part of a token. For details, see Section 2.1.4.1 (Constituent Characters). b. adj. (of a character) having the constituent[1a] syntax type[2]. c. n. a constituent[1b] character. 2. n. (of a composite stream) one of possibly several objects that collectively comprise the source or sink of that stream.

+

constituent trait n. (of a character) one of several classifications of a constituent character in a readtable. See Section 2.1.4.1 (Constituent Characters).

+

constructed stream n. a stream whose source or sink is a Lisp object. Note that since a stream is another Lisp object, composite streams are considered constructed streams. ``A string stream is a constructed stream.''

+

contagion n. a process whereby operations on objects of differing types (e.g., arithmetic on mixed types of numbers) produce a result whose type is controlled by the dominance of one argument's type over the types of the other arguments. See Section 12.1.1.2 (Contagion in Numeric Operations).

+

continuable n. (of an error) an error that is correctable by the continue restart.

+

control form n. 1. a form that establishes one or more places to which control can be transferred. 2. a form that transfers control.

+

copy n. 1. (of a cons C) a fresh cons with the same car and cdr as C. 2. (of a list L) a fresh list with the same elements as L. (Only the list structure is fresh; the elements are the same.) See the function copy-list. 3. (of an association list A with elements Ai) a fresh list B with elements Bi, each of which is nil if Ai is nil, or else a copy of the cons Ai. See the function copy-alist. 4. (of a tree T) a fresh tree with the same leaves as T. See the function copy-tree. 5. (of a random state R) a fresh random state that, if used as an argument to to the function random would produce the same series of ``random'' values as R would produce. 6. (of a structure S) a fresh structure that has the same type as S, and that has slot values, each of which is the same as the corresponding slot value of S. (Note that since the difference between a cons, a list, and a tree is a matter of ``view'' or ``intention,'' there can be no general-purpose function which, based solely on the type of an object, can determine which of these distinct meanings is intended. The distinction rests solely on the basis of the text description within this document. For example, phrases like ``a copy of the given list'' or ``copy of the list x'' imply the second definition.)

+

correctable adj. (of an error) 1. (by a restart other than abort that has been associated with the error) capable of being corrected by invoking that restart. ``The function cerror signals an error that is correctable by the continue restart.'' (Note that correctability is not a property of an error object, but rather a property of the dynamic environment that is in effect when the error is signaled. Specifically, the restart is ``associated with'' the error condition object. See Section 9.1.4.2.4 (Associating a Restart with a Condition).) 2. (when no specific restart is mentioned) correctable[1] by at least one restart. ``import signals a correctable error of type package-error if any of the imported symbols has the same name as some distinct symbol already accessible in the package.''

+

current input base n. (in a dynamic environment) the radix that is the value of *read-base* in that environment, and that is the default radix employed by the Lisp reader and its related functions.

+

current logical block n. the context of the innermost lexically enclosing use of pprint-logical-block.

+

current output base n. (in a dynamic environment) the radix that is the value of *print-base* in that environment, and that is the default radix employed by the Lisp printer and its related functions.

+

current package n. (in a dynamic environment) the package that is the value of *package* in that environment, and that is the default package employed by the Lisp reader and Lisp printer, and their related functions.

+

current pprint dispatch table n. (in a dynamic environment) the pprint dispatch table that is the value of *print-pprint-dispatch* in that environment, and that is the default pprint dispatch table employed by the pretty printer.

+

current random state n. (in a dynamic environment) the random state that is the value of *random-state* in that environment, and that is the default random state employed by random.

+

current readtable n. (in a dynamic environment) the readtable that is the value of *readtable* in that environment, and that affects the way in which expressions[2] are parsed into objects by the Lisp reader.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_d.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_d.htm new file mode 100644 index 00000000..bbfc83c6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_d.htm @@ -0,0 +1,72 @@ + + + +CLHS: Glossary-Section D + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +D

+

data type n. Trad. a type.

+

debug I/O n. the bidirectional stream that is the value of the variable *debug-io*.

+

debugger n. a facility that allows the user to handle a condition interactively. For example, the debugger might permit interactive selection of a restart from among the active restarts, and it might perform additional implementation-defined services for the purposes of debugging.

+

declaration n. a global declaration or local declaration.

+

declaration identifier n. one of the symbols declaration, dynamic-extent, ftype, function, ignore, inline, notinline, optimize, special, or type; or a symbol which is the name of a type; or a symbol which has been declared to be a declaration identifier by using a declaration declaration.

+

declaration specifier n. an expression that can appear at top level of a declare expression or a declaim form, or as the argument to proclaim, and which has a car which is a declaration identifier, and which has a cdr that is data interpreted according to rules specific to the declaration identifier.

+

declare v. to establish a declaration. See declare, declaim, or proclaim.

+

decline v. (of a handler) to return normally without having handled the condition being signaled, permitting the signaling process to continue as if the handler had not been present.

+

decoded time n. absolute time, represented as an ordered series of nine objects which, taken together, form a description of a point in calendar time, accurate to the nearest second (except that leap seconds are ignored). See Section 25.1.4.1 (Decoded Time).

+

default method n. a method having no parameter specializers other than the class t. Such a method is always an applicable method but might be shadowed[2] by a more specific method.

+

defaulted initialization argument list n. a list of alternating initialization argument names and values in which unsupplied initialization arguments are defaulted, used in the protocol for initializing and reinitializing instances of classes.

+

define-method-combination arguments lambda list n. a lambda list used by the :arguments option to define-method-combination. See Section 3.4.10 (Define-method-combination Arguments Lambda Lists).

+

define-modify-macro lambda list n. a lambda list used by define-modify-macro. See Section 3.4.9 (Define-modify-macro Lambda Lists).

+

defined name n. a symbol the meaning of which is defined by Common Lisp.

+

defining form n. a form that has the side-effect of establishing a definition. ``defun and defparameter are defining forms.''

+

defsetf lambda list n. a lambda list that is like an ordinary lambda list except that it does not permit &aux and that it permits use of &environment. See Section 3.4.7 (Defsetf Lambda Lists).

+

deftype lambda list n. a lambda list that is like a macro lambda list except that the default value for unsupplied optional parameters and keyword parameters is the symbol * (rather than nil). See Section 3.4.8 (Deftype Lambda Lists).

+

denormalized adj., ANSI, IEEE (of a float) conforming to the description of ``denormalized'' as described by IEEE Standard for Binary Floating-Point Arithmetic. For example, in an implementation where the minimum possible exponent was -7 but where 0.001 was a valid mantissa, the number 1.0e-10 might be representable as 0.001e-7 internally even if the normalized representation would call for it to be represented instead as 1.0e-10 or 0.1e-9. By their nature, denormalized floats generally have less precision than normalized floats.

+

derived type n. a type specifier which is defined in terms of an expansion into another type specifier. deftype defines derived types, and there may be other implementation-defined operators which do so as well.

+

derived type specifier n. a type specifier for a derived type.

+

designator n. an object that denotes another object. In the dictionary entry for an operator if a parameter is described as a designator for a type, the description of the operator is written in a way that assumes that appropriate coercion to that type has already occurred; that is, that the parameter is already of the denoted type. For more detailed information, see Section 1.4.1.5 (Designators).

+

destructive adj. (of an operator) capable of modifying some program-visible aspect of one or more objects that are either explicit arguments to the operator or that can be obtained directly or indirectly from the global environment by the operator.

+

destructuring lambda list n. an extended lambda list used in destructuring-bind and nested within macro lambda lists. See Section 3.4.5 (Destructuring Lambda Lists).

+

different adj. not the same ``The strings "FOO" and "foo" are different under equal but not under equalp.''

+

digit n. (in a radix) a character that is among the possible digits (0 to 9, A to Z, and a to z) and that is defined to have an associated numeric weight as a digit in that radix. See Section 13.1.4.6 (Digits in a Radix).

+

dimension n. 1. a non-negative integer indicating the number of objects an array can hold along one axis. If the array is a vector with a fill pointer, the fill pointer is ignored. ``The second dimension of that array is 7.'' 2. an axis of an array. ``This array has six dimensions.''

+

direct instance n. (of a class C) an object whose class is C itself, rather than some subclass of C. ``The function make-instance always returns a direct instance of the class which is (or is named by) its first argument.''

+

direct subclass n. (of a class C1) a class C2, such that C1 is a direct superclass of C2.

+

direct superclass n. (of a class C1) a class C2 which was explicitly designated as a superclass of C1 in the definition of C1.

+

disestablish v.t. to withdraw the establishment of an object, a binding, an exit point, a tag, a handler, a restart, or an environment.

+

disjoint n. (of types) having no elements in common.

+

dispatching macro character n. a macro character that has an associated table that specifies the function to be called for each character that is seen following the dispatching macro character. See the function make-dispatch-macro-character.

+

displaced array n. an array which has no storage of its own, but which is instead indirected to the storage of another array, called its target, at a specified offset, in such a way that any attempt to access the displaced array implicitly references the target array.

+

distinct adj. not identical.

+

documentation string n. (in a defining form) A literal string which because of the context in which it appears (rather than because of some intrinsically observable aspect of the string) is taken as documentation. In some cases, the documentation string is saved in such a way that it can later be obtained by supplying either an object, or by supplying a name and a ``kind'' to the function documentation. ``The body of code in a defmacro form can be preceded by a documentation string of kind function.''

+

dot n. the standard character that is variously called ``full stop,'' ``period,'' or ``dot'' (.). See Figure 2-5.

+

dotted list n. a list which has a terminating atom that is not nil. (An atom by itself is not a dotted list, however.)

+

dotted pair n. 1. a cons whose cdr is a non-list. 2. any cons, used to emphasize the use of the cons as a symmetric data pair.

+

double float n. an object of type double-float.

+

double-quote n. the standard character that is variously called ``quotation mark'' or ``double quote'' ("). See Figure 2-5.

+

dynamic binding n. a binding in a dynamic environment.

+

dynamic environment n. that part of an environment that contains bindings with dynamic extent. A dynamic environment contains, among other things: exit points established by unwind-protect, and bindings of dynamic variables, exit points established by catch, condition handlers, and restarts.

+

dynamic extent n. an extent whose duration is bounded by points of establishment and disestablishment within the execution of a particular form. See indefinite extent. ``Dynamic variable bindings have dynamic extent.''

+

dynamic scope n. indefinite scope along with dynamic extent.

+

dynamic variable n. a variable the binding for which is in the dynamic environment. See special.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_e.htm new file mode 100644 index 00000000..e20deb8f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_e.htm @@ -0,0 +1,78 @@ + + + +CLHS: Glossary-Section E + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +E

+

echo stream n. a stream of type echo-stream.

+

effective method n. the combination of applicable methods that are executed when a generic function is invoked with a particular sequence of arguments.

+

element n. 1. (of a list) an object that is the car of one of the conses that comprise the list. 2. (of an array) an object that is stored in the array. 3. (of a sequence) an object that is an element of the list or array that is the sequence. 4. (of a type) an object that is a member of the set of objects designated by the type. 5. (of an input stream) a character or number (as appropriate to the element type of the stream) that is among the ordered series of objects that can be read from the stream (using read-char or read-byte, as appropriate to the stream). 6. (of an output stream) a character or number (as appropriate to the element type of the stream) that is among the ordered series of objects that has been or will be written to the stream (using write-char or write-byte, as appropriate to the stream). 7. (of a class) a generalized instance of the class.

+

element type n. 1. (of an array) the array element type of the array. 2. (of a stream) the stream element type of the stream.

+

em n. Trad. a context-dependent unit of measure commonly used in typesetting, equal to the displayed width of of a letter ``M'' in the current font. (The letter ``M'' is traditionally chosen because it is typically represented by the widest glyph in the font, and other characters' widths are typically fractions of an em. In implementations providing non-Roman characters with wider characters than ``M,'' it is permissible for another character to be the implementation-defined reference character for this measure, and for ``M'' to be only a fraction of an em wide.) In a fixed width font, a line with n characters is n ems wide; in a variable width font, n ems is the expected upper bound on the width of such a line.

+

empty list n. the list containing no elements. See ().

+

empty type n. the type that contains no elements, and that is a subtype of all types (including itself). See nil.

+

end of file n. 1. the point in an input stream beyond which there is no further data. Whether or not there is such a point on an interactive stream is implementation-defined. 2. a situation that occurs upon an attempt to obtain data from an input stream that is at the end of file[1].

+

environment n. 1. a set of bindings. See Section 3.1.1 (Introduction to Environments). 2. an environment object. ``macroexpand takes an optional environment argument.''

+

environment object n. an object representing a set of lexical bindings, used in the processing of a form to provide meanings for names within that form. ``macroexpand takes an optional environment argument.'' (The object nil when used as an environment object denotes the null lexical environment; the values of environment parameters to macro functions are objects of implementation-dependent nature which represent the environment[1] in which the corresponding macro form is to be expanded.) See Section 3.1.1.4 (Environment Objects).

+

environment parameter n. A parameter in a defining form f for which there is no corresponding argument; instead, this parameter receives as its value an environment object which corresponds to the lexical environment in which the defining form f appeared.

+

error n. 1. (only in the phrase ``is an error'') a situation in which the semantics of a program are not specified, and in which the consequences are undefined. 2. a condition which represents an error situation. See Section 1.4.2 (Error Terminology). 3. an object of type error.

+

error output n. the output stream which is the value of the dynamic variable *error-output*.

+

escape n., adj. 1. n. a single escape or a multiple escape. 2. adj. single escape or multiple escape.

+

establish v.t. to build or bring into being a binding, a declaration, an exit point, a tag, a handler, a restart, or an environment. ``let establishes lexical bindings.''

+

evaluate v.t. (a form or an implicit progn) to execute the code represented by the form (or the series of forms making up the implicit progn) by applying the rules of evaluation, returning zero or more values.

+

evaluation n. a model whereby forms are executed, returning zero or more values. Such execution might be implemented directly in one step by an interpreter or in two steps by first compiling the form and then executing the compiled code; this choice is dependent both on context and the nature of the implementation, but in any case is not in general detectable by any program. The evaluation model is designed in such a way that a conforming implementation might legitimately have only a compiler and no interpreter, or vice versa. See Section 3.1.2 (The Evaluation Model).

+

evaluation environment n. a run-time environment in which macro expanders and code specified by eval-when to be evaluated are evaluated. All evaluations initiated by the compiler take place in the evaluation environment.

+

execute v.t. Trad. (code) to perform the imperative actions represented by the code.

+

execution time n. the duration of time that compiled code is being executed.

+

exhaustive partition n. (of a type) a set of pairwise disjoint types that form an exhaustive union.

+

exhaustive union n. (of a type) a set of subtypes of the type, whose union contains all elements of that type.

+

exit point n. a point in a control form from which (e.g., block), through which (e.g., unwind-protect), or to which (e.g., tagbody) control and possibly values can be transferred both actively by using another control form and passively through the normal control and data flow of evaluation. ``catch and block establish bindings for exit points to which throw and return-from, respectively, can transfer control and values; tagbody establishes a binding for an exit point with lexical extent to which go can transfer control; and unwind-protect establishes an exit point through which control might be transferred by operators such as throw, return-from, and go.''

+

explicit return n. the act of transferring control (and possibly values) to a block by using return-from (or return).

+

explicit use n. (of a variable V in a form F) a reference to V that is directly apparent in the normal semantics of F; i.e., that does not expose any undocumented details of the macro expansion of the form itself. References to V exposed by expanding subforms of F are, however, considered to be explicit uses of V.

+

exponent marker n. a character that is used in the textual notation for a float to separate the mantissa from the exponent. The characters defined as exponent markers in the standard readtable are shown in the next figure. For more information, see Section 2.1 (Character Syntax). ``The exponent marker `d' in `3.0d7' indicates that this number is to be represented as a double float.''

+

+Marker  Meaning                                  
+D or d  double-float                             
+E or e  float (see *read-default-float-format*)  
+F or f  single-float                             
+L or l  long-float                               
+S or s  short-float                              
+
+

Figure 26-1. Exponent Markers

+

export v.t. (a symbol in a package) to add the symbol to the list of external symbols of the package.

+

exported adj. (of a symbol in a package) being an external symbol of the package.

+

expressed adjustability n. (of an array) a generalized boolean that is conceptually (but not necessarily actually) associated with the array, representing whether the array is expressly adjustable. See also actual adjustability.

+

expressed array element type n. (of an array) the type which is the array element type implied by a type declaration for the array, or which is the requested array element type at its time of creation, prior to any selection of an upgraded array element type. (Common Lisp does not provide a way of detecting this type directly at run time, but an implementation is permitted to make assumptions about the array's contents and the operations which may be performed on the array when this type is noted during code analysis, even if those assumptions would not be valid in general for the upgraded array element type of the expressed array element type.)

+

expressed complex part type n. (of a complex) the type which is implied as the complex part type by a type declaration for the complex, or which is the requested complex part type at its time of creation, prior to any selection of an upgraded complex part type. (Common Lisp does not provide a way of detecting this type directly at run time, but an implementation is permitted to make assumptions about the operations which may be performed on the complex when this type is noted during code analysis, even if those assumptions would not be valid in general for the upgraded complex part type of the expressed complex part type.)

+

expression n. 1. an object, often used to emphasize the use of the object to encode or represent information in a specialized format, such as program text. ``The second expression in a let form is a list of bindings.'' 2. the textual notation used to notate an object in a source file. ``The expression 'sample is equivalent to (quote sample).''

+

expressly adjustable adj. (of an array) being actually adjustable by virtue of an explicit request for this characteristic having been made at the time of its creation. All arrays that are expressly adjustable are actually adjustable, but not necessarily vice versa.

+

extended character n. a character of type extended-char: a character that is not a base character.

+

extended function designator n. a designator for a function; that is, an object that denotes a function and that is one of: a function name (denoting the function it names in the global environment), or a function (denoting itself). The consequences are undefined if a function name is used as an extended function designator but it does not have a global definition as a function, or if it is a symbol that has a global definition as a macro or a special form. See also function designator.

+

extended lambda list n. a list resembling an ordinary lambda list in form and purpose, but offering additional syntax or functionality not available in an ordinary lambda list. ``defmacro uses extended lambda lists.''

+

extension n. a facility in an implementation of Common Lisp that is not specified by this standard.

+

extent n. the interval of time during which a reference to an object, a binding, an exit point, a tag, a handler, a restart, or an environment is defined.

+

external file format n. an object of implementation-dependent nature which determines one of possibly several implementation-dependent ways in which characters are encoded externally in a character file.

+

external file format designator n. a designator for an external file format; that is, an object that denotes an external file format and that is one of: the symbol :default (denoting an implementation-dependent default external file format that can accomodate at least the base characters), some other object defined by the implementation to be an external file format designator (denoting an implementation-defined external file format), or some other object defined by the implementation to be an external file format (denoting itself).

+

external symbol n. (of a package) a symbol that is part of the `external interface' to the package and that are inherited[3] by any other package that uses the package. When using the Lisp reader, if a package prefix is used, the name of an external symbol is separated from the package name by a single package marker while the name of an internal symbol is separated from the package name by a double package marker; see Section 2.3.4 (Symbols as Tokens).

+

externalizable object n. an object that can be used as a literal object in code to be processed by the file compiler.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_f.htm new file mode 100644 index 00000000..df03d601 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_f.htm @@ -0,0 +1,65 @@ + + + +CLHS: Glossary-Section F + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +F

+

false n. the symbol nil, used to represent the failure of a predicate test.

+

fbound ['ef,band] adj. (of a function name) bound in the function namespace. (The names of macros and special operators are fbound, but the nature and type of the object which is their value is implementation-dependent. Further, defining a setf expander F does not cause the setf function (setf F) to become defined; as such, if there is a such a definition of a setf expander F, the function (setf F) can be fbound if and only if, by design or coincidence, a function binding for (setf F) has been independently established.) See the functions fboundp and symbol-function.

+

feature n. 1. an aspect or attribute of Common Lisp, of the implementation, or of the environment. 2. a symbol that names a feature[1]. See Section 24.1.2 (Features). ``The :ansi-cl feature is present in all conforming implementations.''

+

feature expression n. A boolean combination of features used by the #+ and #- reader macros in order to direct conditional reading of expressions by the Lisp reader. See Section 24.1.2.1 (Feature Expressions).

+

features list n. the list that is the value of *features*.

+

file n. a named entry in a file system, having an implementation-defined nature.

+

file compiler n. any compiler which compiles source code contained in a file, producing a compiled file as output. The compile-file function is the only interface to such a compiler provided by Common Lisp, but there might be other, implementation-defined mechanisms for invoking the file compiler.

+

file position n. (in a stream) a non-negative integer that represents a position in the stream. Not all streams are able to represent the notion of file position; in the description of any operator which manipulates file positions, the behavior for streams that don't have this notion must be explicitly stated. For binary streams, the file position represents the number of preceding bytes in the stream. For character streams, the constraint is more relaxed: file positions must increase monotonically, the amount of the increase between file positions corresponding to any two successive characters in the stream is implementation-dependent.

+

file position designator n. (in a stream) a designator for a file position in that stream; that is, the symbol :start (denoting 0, the first file position in that stream), the symbol :end (denoting the last file position in that stream; i.e., the position following the last element of the stream), or a file position (denoting itself).

+

file stream n. an object of type file-stream.

+

file system n. a facility which permits aggregations of data to be stored in named files on some medium that is external to the Lisp image and that therefore persists from session to session.

+

filename n. a handle, not necessarily ever directly represented as an object, that can be used to refer to a file in a file system. Pathnames and namestrings are two kinds of objects that substitute for filenames in Common Lisp.

+

fill pointer n. (of a vector) an integer associated with a vector that represents the index above which no elements are active. (A fill pointer is a non-negative integer no larger than the total number of elements in the vector. Not all vectors have fill pointers.)

+

finite adj. (of a type) having a finite number of elements. ``The type specifier (integer 0 5) denotes a finite type, but the type specifiers integer and (integer 0) do not.''

+

fixnum n. an integer of type fixnum.

+

float n. an object of type float.

+

for-value adj. (of a reference to a binding) being a reference that reads[1] the value of the binding.

+

form n. 1. any object meant to be evaluated. 2. a symbol, a compound form, or a self-evaluating object. 3. (for an operator, as in ``<<operator>> form'') a compound form having that operator as its first element. ``A quote form is a constant form.''

+

formal argument n. Trad. a parameter.

+

formal parameter n. Trad. a parameter.

+

format v.t. (a format control and format arguments) to perform output as if by format, using the format string and format arguments.

+

format argument n. an object which is used as data by functions such as format which interpret format controls.

+

format control n. a format string, or a function that obeys the argument conventions for a function returned by the formatter macro. See Section 22.2.1.3 (Compiling Format Strings).

+

format directive n. 1. a sequence of characters in a format string which is introduced by a tilde, and which is specially interpreted by code which processes format strings to mean that some special operation should be performed, possibly involving data supplied by the format arguments that accompanied the format string. See the function format. ``In "~D base 10 = ~8R", the character sequences `~D' and `~8R' are format directives.'' 2. the conceptual category of all format directives[1] which use the same dispatch character. ``Both "~3d" and "~3,'0D" are valid uses of the `~D' format directive.''

+

format string n. a string which can contain both ordinary text and format directives, and which is used in conjunction with format arguments to describe how text output should be formatted by certain functions, such as format.

+

free declaration n. a declaration that is not a bound declaration. See declare.

+

fresh adj. 1. (of an object yielded by a function) having been newly-allocated by that function. (The caller of a function that returns a fresh object may freely modify the object without fear that such modification will compromise the future correct behavior of that function.) 2. (of a binding for a name) newly-allocated; not shared with other bindings for that name.

+

freshline n. a conceptual operation on a stream, implemented by the function fresh-line and by the format directive ~&, which advances the display position to the beginning of the next line (as if a newline had been typed, or the function terpri had been called) unless the stream is already known to be positioned at the beginning of a line. Unlike newline, freshline is not a character.

+

funbound ['efunband] n. (of a function name) not fbound.

+

function n. 1. an object representing code, which can be called with zero or more arguments, and which produces zero or more values. 2. an object of type function.

+

function block name n. (of a function name) The symbol that would be used as the name of an implicit block which surrounds the body of a function having that function name. If the function name is a symbol, its function block name is the function name itself. If the function name is a list whose car is setf and whose cadr is a symbol, its function block name is the symbol that is the cadr of the function name. An implementation which supports additional kinds of function names must specify for each how the corresponding function block name is computed.

+

function cell n. Trad. (of a symbol) The place which holds the definition of the global function binding, if any, named by that symbol, and which is accessed by symbol-function. See cell.

+

function designator n. a designator for a function; that is, an object that denotes a function and that is one of: a symbol (denoting the function named by that symbol in the global environment), or a function (denoting itself). The consequences are undefined if a symbol is used as a function designator but it does not have a global definition as a function, or it has a global definition as a macro or a special form. See also extended function designator.

+

function form n. a form that is a list and that has a first element which is the name of a function to be called on arguments which are the result of evaluating subsequent elements of the function form.

+

function name n. 1. (in an environment) A symbol or a list (setf symbol) that is the name of a function in that environment. 2. A symbol or a list (setf symbol).

+

functional evaluation n. the process of extracting a functional value from a function name or a lambda expression. The evaluator performs functional evaluation implicitly when it encounters a function name or a lambda expression in the car of a compound form, or explicitly when it encounters a function special form. Neither a use of a symbol as a function designator nor a use of the function symbol-function to extract the functional value of a symbol is considered a functional evaluation.

+

functional value n. 1. (of a function name N in an environment E) The value of the binding named N in the function namespace for environment E; that is, the contents of the function cell named N in environment E. 2. (of an fbound symbol S) the contents of the symbol's function cell; that is, the value of the binding named S in the function namespace of the global environment. (A name that is a macro name in the global environment or is a special operator might or might not be fbound. But if S is such a name and is fbound, the specific nature of its functional value is implementation-dependent; in particular, it might or might not be a function.)

+

further compilation n. implementation-dependent compilation beyond minimal compilation. Further compilation is permitted to take place at run time. ``Block compilation and generation of machine-specific instructions are examples of further compilation.''

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_g.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_g.htm new file mode 100644 index 00000000..e1bad82b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_g.htm @@ -0,0 +1,42 @@ + + + +CLHS: Glossary-Section G + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +G

+

general adj. (of an array) having element type t, and consequently able to have any object as an element.

+

generalized boolean n. an object used as a truth value, where the symbol nil represents false and all other objects represent true. See boolean.

+

generalized instance n. (of a class) an object the class of which is either that class itself, or some subclass of that class. (Because of the correspondence between types and classes, the term ``generalized instance of X'' implies ``object of type X'' and in cases where X is a class (or class name) the reverse is also true. The former terminology emphasizes the view of X as a class while the latter emphasizes the view of X as a type specifier.)

+

generalized reference n. a reference to a location storing an object as if to a variable. (Such a reference can be either to read or write the location.) See Section 5.1 (Generalized Reference). See also place.

+

generalized synonym stream n. (with a synonym stream symbol) 1. (to a stream) a synonym stream to the stream, or a composite stream which has as a target a generalized synonym stream to the stream. 2. (to a symbol) a synonym stream to the symbol, or a composite stream which has as a target a generalized synonym stream to the symbol.

+

generic function n. a function whose behavior depends on the classes or identities of the arguments supplied to it and whose parts include, among other things, a set of methods, a lambda list, and a method combination type.

+

generic function lambda list n. A lambda list that is used to describe data flow into a generic function. See Section 3.4.2 (Generic Function Lambda Lists).

+

gensym n. Trad. an uninterned symbol. See the function gensym.

+

global declaration n. a form that makes certain kinds of information about code globally available; that is, a proclaim form or a declaim form.

+

global environment n. that part of an environment that contains bindings with indefinite scope and indefinite extent.

+

global variable n. a dynamic variable or a constant variable.

glyph n. a visual representation. ``Graphic characters have associated glyphs.''

+

go v. to transfer control to a go point. See the special operator go.

+

go point one of possibly several exit points that are established by tagbody (or other abstractions, such as prog, which are built from tagbody).

+

go tag n. the symbol or integer that, within the lexical scope of a tagbody form, names an exit point established by that tagbody form.

+

graphic adj. (of a character) being a ``printing'' or ``displayable'' character that has a standard visual representation as a single glyph, such as A or * or =. Space is defined to be graphic. Of the standard characters, all but newline are graphic. See non-graphic.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_h.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_h.htm new file mode 100644 index 00000000..c8202bb5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_h.htm @@ -0,0 +1,31 @@ + + + +CLHS: Glossary-Section H + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +H

+

handle v. (of a condition being signaled) to perform a non-local transfer of control, terminating the ongoing signaling of the condition.

+

handler n. a condition handler.

+

hash table n. an object of type hash-table, which provides a mapping from keys to values.

+

home package n. (of a symbol) the package, if any, which is contents of the package cell of the symbol, and which dictates how the Lisp printer prints the symbol when it is not accessible in the current package. (Symbols which have nil in their package cell are said to have no home package, and also to be apparently uninterned.)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_i.htm new file mode 100644 index 00000000..7b720d09 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_i.htm @@ -0,0 +1,78 @@ + + + +CLHS: Glossary-Section I + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +I

+

I/O customization variable n. one of the stream variables in the next figure, or some other (implementation-defined) stream variable that is defined by the implementation to be an I/O customization variable.

+

+*debug-io*        *error-io*         query-io*       
+*standard-input*  *standard-output*  *trace-output*  
+
+

Figure 26-2. Standardized I/O Customization Variables

+

identical adj. the same under eq.

+

identifier n. 1. a symbol used to identify or to distinguish names. 2. a string used the same way.

+

immutable adj. not subject to change, either because no operator is provided which is capable of effecting such change or because some constraint exists which prohibits the use of an operator that might otherwise be capable of effecting such a change. Except as explicitly indicated otherwise, implementations are not required to detect attempts to modify immutable objects or cells; the consequences of attempting to make such modification are undefined. ``Numbers are immutable.''

+

implementation n. a system, mechanism, or body of code that implements the semantics of Common Lisp.

+

implementation limit n. a restriction imposed by an implementation.

+

implementation-defined adj. implementation-dependent, but required by this specification to be defined by each conforming implementation and to be documented by the corresponding implementor.

+

implementation-dependent adj. describing a behavior or aspect of Common Lisp which has been deliberately left unspecified, that might be defined in some conforming implementations but not in others, and whose details may differ between implementations. A conforming implementation is encouraged (but not required) to document its treatment of each item in this specification which is marked implementation-dependent, although in some cases such documentation might simply identify the item as ``undefined.''

+

implementation-independent adj. used to identify or emphasize a behavior or aspect of Common Lisp which does not vary between conforming implementations.

+

implicit block n. a block introduced by a macro form rather than by an explicit block form.

+

implicit compilation n. compilation performed during evaluation.

+

implicit progn n. an ordered set of adjacent forms appearing in another form, and defined by their context in that form to be executed as if within a progn.

+

implicit tagbody n. an ordered set of adjacent forms and/or tags appearing in another form, and defined by their context in that form to be executed as if within a tagbody.

+

import v.t. (a symbol into a package) to make the symbol be present in the package.

+

improper list n. a list which is not a proper list: a circular list or a dotted list.

+

inaccessible adj. not accessible.

+

indefinite extent n. an extent whose duration is unlimited. ``Most Common Lisp objects have indefinite extent.''

+

indefinite scope n. scope that is unlimited.

+

indicator n. a property indicator.

+

indirect instance n. (of a class C1) an object of class C2, where C2 is a subclass of C1. ``An integer is an indirect instance of the class number.''

+

inherit v.t. 1. to receive or acquire a quality, trait, or characteristic; to gain access to a feature defined elsewhere. 2. (a class) to acquire the structure and behavior defined by a superclass. 3. (a package) to make symbols exported by another package accessible by using use-package.

+

initial pprint dispatch table n. the value of *print-pprint-dispatch* at the time the Lisp image is started.

+

initial readtable n. the value of *readtable* at the time the Lisp image is started.

+

initialization argument list n. a property list of initialization argument names and values used in the protocol for initializing and reinitializing instances of classes. See Section 7.1 (Object Creation and Initialization).

+

initialization form n. a form used to supply the initial value for a slot or variable. ``The initialization form for a slot in a defclass form is introduced by the keyword :initform.''

+

input adj. (of a stream) supporting input operations (i.e., being a ``data source''). An input stream might also be an output stream, in which case it is sometimes called a bidirectional stream. See the function input-stream-p.

+

instance n. 1. a direct instance. 2. a generalized instance. 3. an indirect instance.

+

integer n. an object of type integer, which represents a mathematical integer.

+

interactive stream n. a stream on which it makes sense to perform interactive querying. See Section 21.1.1.1.3 (Interactive Streams).

+

intern v.t. 1. (a string in a package) to look up the string in the package, returning either a symbol with that name which was already accessible in the package or a newly created internal symbol of the package with that name. 2. Idiom. generally, to observe a protocol whereby objects which are equivalent or have equivalent names under some predicate defined by the protocol are mapped to a single canonical object.

+

internal symbol n. (of a package) a symbol which is accessible in the package, but which is not an external symbol of the package.

+

internal time n. time, represented as an integer number of internal time units. Absolute internal time is measured as an offset from an arbitrarily chosen, implementation-dependent base. See Section 25.1.4.3 (Internal Time).

+

internal time unit n. a unit of time equal to 1/n of a second, for some implementation-defined integer value of n. See the variable internal-time-units-per-second.

+

interned adj. Trad. 1. (of a symbol) accessible[3] in any package. 2. (of a symbol in a specific package) present in that package.

+

interpreted function n. a function that is not a compiled function. (It is possible for there to be a conforming implementation which has no interpreted functions, but a conforming program must not assume that all functions are compiled functions.)

+

interpreted implementation n. an implementation that uses an execution strategy for interpreted functions that does not involve a one-time semantic analysis pre-pass, and instead uses ``lazy'' (and sometimes repetitious) semantic analysis of forms as they are encountered during execution.

+

interval designator n. (of type T) an ordered pair of objects that describe a subtype of T by delimiting an interval on the real number line. See Section 12.1.6 (Interval Designators).

+

invalid n., adj. 1. n. a possible constituent trait of a character which if present signifies that the character cannot ever appear in a token except under the control of a single escape character. For details, see Section 2.1.4.1 (Constituent Characters). 2. adj. (of a character) being a character that has syntax type constituent in the current readtable and that has the constituent trait invalid[1]. See Figure 2-8.

+

iteration form n. a compound form whose operator is named in the next figure, or a compound form that has an implementation-defined operator and that is defined by the implementation to be an iteration form.

+

+do              do-external-symbols  dotimes  
+do*             do-symbols           loop     
+do-all-symbols  dolist                        
+
+

Figure 26-3. Standardized Iteration Forms

+

iteration variable n. a variable V, the binding for which was created by an explicit use of V in an iteration form.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_k.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_k.htm new file mode 100644 index 00000000..8dd98d2c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_k.htm @@ -0,0 +1,31 @@ + + + +CLHS: Glossary-Section K + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +K

+

key n. an object used for selection during retrieval. See association list, property list, and hash table. Also, see Section 17.1 (Sequence Concepts).

+

keyword n. 1. a symbol the home package of which is the KEYWORD package. 2. any symbol, usually but not necessarily in the KEYWORD package, that is used as an identifying marker in keyword-style argument passing. See lambda. 3. Idiom. a lambda list keyword.

+

keyword parameter n. A parameter for which a corresponding keyword argument is optional. (There is no such thing as a required keyword argument.) If the argument is not supplied, a default value is used. See also supplied-p parameter.

+

keyword/value pair n. two successive elements (a keyword and a value, respectively) of a property list.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_l.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_l.htm new file mode 100644 index 00000000..46f67e26 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_l.htm @@ -0,0 +1,64 @@ + + + +CLHS: Glossary-Section L + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +L

+

lambda combination n. Trad. a lambda form.

+

lambda expression n. a list which can be used in place of a function name in certain contexts to denote a function by directly describing its behavior rather than indirectly by referring to the name of an established function; its name derives from the fact that its first element is the symbol lambda. See lambda.

+

lambda form n. a form that is a list and that has a first element which is a lambda expression representing a function to be called on arguments which are the result of evaluating subsequent elements of the lambda form.

+

lambda list n. a list that specifies a set of parameters (sometimes called lambda variables) and a protocol for receiving values for those parameters; that is, an ordinary lambda list, an extended lambda list, or a modified lambda list.

+

lambda list keyword n. a symbol whose name begins with ampersand and that is specially recognized in a lambda list. Note that no standardized lambda list keyword is in the KEYWORD package.

+

lambda variable n. a formal parameter, used to emphasize the variable's relation to the lambda list that established it.

+

leaf n. 1. an atom in a tree[1]. 2. a terminal node of a tree[2].

+

leap seconds n. additional one-second intervals of time that are occasionally inserted into the true calendar by official timekeepers as a correction similar to ``leap years.'' All Common Lisp time representations ignore leap seconds; every day is assumed to be exactly 86400 seconds long.

+

left-parenthesis n. the standard character ``('', that is variously called ``left parenthesis'' or ``open parenthesis'' See Figure 2-5.

+

length n. (of a sequence) the number of elements in the sequence. (Note that if the sequence is a vector with a fill pointer, its length is the same as the fill pointer even though the total allocated size of the vector might be larger.)

+

lexical binding n. a binding in a lexical environment.

+

lexical closure n. a function that, when invoked on arguments, executes the body of a lambda expression in the lexical environment that was captured at the time of the creation of the lexical closure, augmented by bindings of the function's parameters to the corresponding arguments.

+

lexical environment n. that part of the environment that contains bindings whose names have lexical scope. A lexical environment contains, among other things: ordinary bindings of variable names to values, lexically established bindings of function names to functions, macros, symbol macros, blocks, tags, and local declarations (see declare).

+

lexical scope n. scope that is limited to a spatial or textual region within the establishing form. ``The names of parameters to a function normally are lexically scoped.''

+

lexical variable n. a variable the binding for which is in the lexical environment.

+

Lisp image n. a running instantiation of a Common Lisp implementation. A Lisp image is characterized by a single address space in which any object can directly refer to any another in conformance with this specification, and by a single, common, global environment. (External operating systems sometimes call this a ``core image,'' ``fork,'' ``incarnation,'' ``job,'' or ``process.'' Note however, that the issue of a ``process'' in such an operating system is technically orthogonal to the issue of a Lisp image being defined here. Depending on the operating system, a single ``process'' might have multiple Lisp images, and multiple ``processes'' might reside in a single Lisp image. Hence, it is the idea of a fully shared address space for direct reference among all objects which is the defining characteristic. Note, too, that two ``processes'' which have a communication area that permits the sharing of some but not all objects are considered to be distinct Lisp images.)

+

Lisp printer n. Trad. the procedure that prints the character representation of an object onto a stream. (This procedure is implemented by the function write.)

+

Lisp read-eval-print loop n. Trad. an endless loop that reads[2] a form, evaluates it, and prints (i.e., writes[2]) the results. In many implementations, the default mode of interaction with Common Lisp during program development is through such a loop.

+

Lisp reader n. Trad. the procedure that parses character representations of objects from a stream, producing objects. (This procedure is implemented by the function read.)

+

list n. 1. a chain of conses in which the car of each cons is an element of the list, and the cdr of each cons is either the next link in the chain or a terminating atom. See also proper list, dotted list, or circular list. 2. the type that is the union of null and cons.

+

list designator n. a designator for a list of objects; that is, an object that denotes a list and that is one of: a non-nil atom (denoting a singleton list whose element is that non-nil atom) or a proper list (denoting itself).

+

list structure n. (of a list) the set of conses that make up the list. Note that while the car[1b] component of each such cons is part of the list structure, the objects that are elements of the list (i.e., the objects that are the cars[2] of each cons in the list) are not themselves part of its list structure, even if they are conses, except in the (circular[2]) case where the list actually contains one of its tails as an element. (The list structure of a list is sometimes redundantly referred to as its ``top-level list structure'' in order to emphasize that any conses that are elements of the list are not involved.)

+

literal adj. (of an object) referenced directly in a program rather than being computed by the program; that is, appearing as data in a quote form, or, if the object is a self-evaluating object, appearing as unquoted data. ``In the form (cons "one" '("two")), the expressions "one", ("two"), and "two" are literal objects.''

+

load v.t. (a file) to cause the code contained in the file to be executed. See the function load.

+

load time n. the duration of time that the loader is loading compiled code.

+

load time value n. an object referred to in code by a load-time-value form. The value of such a form is some specific object which can only be computed in the run-time environment. In the case of file compilation, the value is computed once as part of the process of loading the compiled file, and not again. See the special operator load-time-value.

+

loader n. a facility that is part of Lisp and that loads a file. See the function load.

+

local declaration n. an expression which may appear only in specially designated positions of certain forms, and which provides information about the code contained within the containing form; that is, a declare expression.

+

local precedence order n. (of a class) a list consisting of the class followed by its direct superclasses in the order mentioned in the defining form for the class.

+

local slot n. (of a class) a slot accessible in only one instance, namely the instance in which the slot is allocated.

+

logical block n. a conceptual grouping of related output used by the pretty printer. See the macro pprint-logical-block and Section 22.2.1.1 (Dynamic Control of the Arrangement of Output).

+

logical host n. an object of implementation-dependent nature that is used as the representation of a ``host'' in a logical pathname, and that has an associated set of translation rules for converting logical pathnames belonging to that host into physical pathnames. See Section 19.3 (Logical Pathnames).

+

logical host designator n. a designator for a logical host; that is, an object that denotes a logical host and that is one of: a string (denoting the logical host that it names), or a logical host (denoting itself). (Note that because the representation of a logical host is implementation-dependent, it is possible that an implementation might represent a logical host as the string that names it.)

+

logical pathname n. an object of type logical-pathname.

+

long float n. an object of type long-float.

+

loop keyword n. Trad. a symbol that is a specially recognized part of the syntax of an extended loop form. Such symbols are recognized by their name (using string=), not by their identity; as such, they may be in any package. A loop keyword is not a keyword.

+

lowercase adj. (of a character) being among standard characters corresponding to the small letters a through z, or being some other implementation-defined character that is defined by the implementation to be lowercase. See Section 13.1.4.3 (Characters With Case).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_m.htm new file mode 100644 index 00000000..0c39ef4b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_m.htm @@ -0,0 +1,47 @@ + + + +CLHS: Glossary-Section M + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +M

+

macro n. 1. a macro form 2. a macro function. 3. a macro name.

+

macro character n. a character which, when encountered by the Lisp reader in its main dispatch loop, introduces a reader macro[1]. (Macro characters have nothing to do with macros.)

+

macro expansion n. 1. the process of translating a macro form into another form. 2. the form resulting from this process.

+

macro form n. a form that stands for another form (e.g., for the purposes of abstraction, information hiding, or syntactic convenience); that is, either a compound form whose first element is a macro name, or a form that is a symbol that names a symbol macro.

+

macro function n. a function of two arguments, a form and an environment, that implements macro expansion by producing a form to be evaluated in place of the original argument form.

+

macro lambda list n. an extended lambda list used in forms that establish macro definitions, such as defmacro and macrolet. See Section 3.4.4 (Macro Lambda Lists).

+

macro name n. a name for which macro-function returns true and which when used as the first element of a compound form identifies that form as a macro form.

+

macroexpand hook n. the function that is the value of *macroexpand-hook*.

+

mapping n. 1. a type of iteration in which a function is successively applied to objects taken from corresponding entries in collections such as sequences or hash tables. 2. Math. a relation between two sets in which each element of the first set (the ``domain'') is assigned one element of the second set (the ``range'').

+

metaclass n. 1. a class whose instances are classes. 2. (of an object) the class of the class of the object.

+

Metaobject Protocol n. one of many possible descriptions of how a conforming implementation might implement various aspects of the object system. This description is beyond the scope of this document, and no conforming implementation is required to adhere to it except as noted explicitly in this specification. Nevertheless, its existence helps to establish normative practice, and implementors with no reason to diverge from it are encouraged to consider making their implementation adhere to it where possible. It is described in detail in The Art of the Metaobject Protocol.

+

method n. an object that is part of a generic function and which provides information about how that generic function should behave when its arguments are objects of certain classes or with certain identities.

+

method combination n. 1. generally, the composition of a set of methods to produce an effective method for a generic function. 2. an object of type method-combination, which represents the details of how the method combination[1] for one or more specific generic functions is to be performed.

+

method-defining form n. a form that defines a method for a generic function, whether explicitly or implicitly. See Section 7.6.1 (Introduction to Generic Functions).

+

method-defining operator n. an operator corresponding to a method-defining form. See Figure 7-1.

+

minimal compilation n. actions the compiler must take at compile time. See Section 3.2.2 (Compilation Semantics).

+

modified lambda list n. a list resembling an ordinary lambda list in form and purpose, but which deviates in syntax or functionality from the definition of an ordinary lambda list. See ordinary lambda list. ``deftype uses a modified lambda list.''

+

most recent adj. innermost; that is, having been established (and not yet disestablished) more recently than any other of its kind.

+

multiple escape n., adj. 1. n. the syntax type of a character that is used in pairs to indicate that the enclosed characters are to be treated as alphabetic[2] characters with their case preserved. For details, see Section 2.1.4.5 (Multiple Escape Characters). 2. adj. (of a character) having the multiple escape syntax type. 3. n. a multiple escape[2] character. (In the standard readtable, vertical-bar is a multiple escape character.)

+

multiple values n. 1. more than one value. ``The function truncate returns multiple values.'' 2. a variable number of values, possibly including zero or one. ``The function values returns multiple values.'' 3. a fixed number of values other than one. ``The macro multiple-value-bind is among the few operators in Common Lisp which can detect and manipulate multiple values.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_n.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_n.htm new file mode 100644 index 00000000..90e14dde --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_n.htm @@ -0,0 +1,54 @@ + + + +CLHS: Glossary-Section N + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +N

+

name n., v.t. 1. n. an identifier by which an object, a binding, or an exit point is referred to by association using a binding. 2. v.t. to give a name to. 3. n. (of an object having a name component) the object which is that component. ``The string which is a symbol's name is returned by symbol-name.'' 4. n. (of a pathname) a. the name component, returned by pathname-name. b. the entire namestring, returned by namestring. 5. n. (of a character) a string that names the character and that has length greater than one. (All non-graphic characters are required to have names unless they have some implementation-defined attribute which is not null. Whether or not other characters have names is implementation-dependent.)

+

named constant n. a variable that is defined by Common Lisp, by the implementation, or by user code (see the macro defconstant) to always yield the same value when evaluated. ``The value of a named constant may not be changed by assignment or by binding.''

+

namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.''

+

namestring n. a string that represents a filename using either the standardized notation for naming logical pathnames described in Section 19.3.1 (Syntax of Logical Pathname Namestrings), or some implementation-defined notation for naming a physical pathname.

+

newline n. the standard character <Newline>, notated for the Lisp reader as #\Newline.

+

next method n. the next method to be invoked with respect to a given method for a particular set of arguments or argument classes. See Section 7.6.6.1.3 (Applying method combination to the sorted list of applicable methods).

+

nickname n. (of a package) one of possibly several names that can be used to refer to the package but that is not the primary name of the package.

+

nil n. the object that is at once the symbol named "NIL" in the COMMON-LISP package, the empty list, the boolean (or generalized boolean) representing false, and the name of the empty type.

+

non-atomic adj. being other than an atom; i.e., being a cons.

+

non-constant variable n. a variable that is not a constant variable.

+

non-correctable adj. (of an error) not intentionally correctable. (Because of the dynamic nature of restarts, it is neither possible nor generally useful to completely prohibit an error from being correctable. This term is used in order to express an intent that no special effort should be made by code signaling an error to make that error correctable; however, there is no actual requirement on conforming programs or conforming implementations imposed by this term.)

+

non-empty adj. having at least one element.

+

non-generic function n. a function that is not a generic function.

+

non-graphic adj. (of a character) not graphic. See Section 13.1.4.1 (Graphic Characters).

+

non-list n., adj. other than a list; i.e., a non-nil atom.

+

non-local exit n. a transfer of control (and sometimes values) to an exit point for reasons other than a normal return. ``The operators go, throw, and return-from cause a non-local exit.''

+

non-nil n., adj. not nil. Technically, any object which is not nil can be referred to as true, but that would tend to imply a unique view of the object as a generalized boolean. Referring to such an object as non-nil avoids this implication.

+

non-null lexical environment n. a lexical environment that has additional information not present in the global environment, such as one or more bindings.

+

non-simple adj. not simple.

+

non-terminating adj. (of a macro character) being such that it is treated as a constituent character when it appears in the middle of an extended token. See Section 2.2 (Reader Algorithm).

+

non-top-level form n. a form that, by virtue of its position as a subform of another form, is not a top level form. See Section 3.2.3.1 (Processing of Top Level Forms).

+

normal return n. the natural transfer of control and values which occurs after the complete execution of a form.

+

normalized adj., ANSI, IEEE (of a float) conforming to the description of ``normalized'' as described by IEEE Standard for Binary Floating-Point Arithmetic. See denormalized.

+

null adj., n. 1. adj. a. (of a list) having no elements: empty. See empty list. b. (of a string) having a length of zero. (It is common, both within this document and in observed spoken behavior, to refer to an empty string by an apparent definite reference, as in ``the null string'' even though no attempt is made to intern[2] null strings. The phrase ``a null string'' is technically more correct, but is generally considered awkward by most Lisp programmers. As such, the phrase ``the null string'' should be treated as an indefinite reference in all cases except for anaphoric references.) c. (of an implementation-defined attribute of a character) An object to which the value of that attribute defaults if no specific value was requested. 2. n. an object of type null (the only such object being nil).

+

null lexical environment n. the lexical environment which has no bindings.

+

number n. an object of type number.

+

numeric adj. (of a character) being one of the standard characters 0 through 9, or being some other graphic character defined by the implementation to be numeric.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_o.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_o.htm new file mode 100644 index 00000000..20f6e4b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_o.htm @@ -0,0 +1,37 @@ + + + +CLHS: Glossary-Section O + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +O

+

object n. 1. any Lisp datum. ``The function cons creates an object which refers to two other objects.'' 2. (immediately following the name of a type) an object which is of that type, used to emphasize that the object is not just a name for an object of that type but really an element of the type in cases where objects of that type (such as function or class) are commonly referred to by name. ``The function symbol-function takes a function name and returns a function object.''

+

object-traversing adj. operating in succession on components of an object. ``The operators mapcar, maphash, with-package-iterator and count perform object-traversing operations.''

+

open adj., v.t. (a file) 1. v.t. to create and return a stream to the file. 2. adj. (of a stream) having been opened[1], but not yet closed.

+

operator n. 1. a function, macro, or special operator. 2. a symbol that names such a function, macro, or special operator. 3. (in a function special form) the cadr of the function special form, which might be either an operator[2] or a lambda expression. 4. (of a compound form) the car of the compound form, which might be either an operator[2] or a lambda expression, and which is never (setf symbol).

+

optimize quality n. one of several aspects of a program that might be optimizable by certain compilers. Since optimizing one such quality might conflict with optimizing another, relative priorities for qualities can be established in an optimize declaration. The standardized optimize qualities are compilation-speed (speed of the compilation process), debug (ease of debugging), safety (run-time error checking), space (both code size and run-time space), and speed (of the object code). Implementations may define additional optimize qualities.

+

optional parameter n. A parameter for which a corresponding positional argument is optional. If the argument is not supplied, a default value is used. See also supplied-p parameter.

+

ordinary function n. a function that is not a generic function.

+

ordinary lambda list n. the kind of lambda list used by lambda. See modified lambda list and extended lambda list. ``defun uses an ordinary lambda list.''

+

otherwise inaccessible part n. (of an object, O1) an object, O2, which would be made inaccessible if O1 were made inaccessible. (Every object is an otherwise inaccessible part of itself.)

+

output adj. (of a stream) supporting output operations (i.e., being a ``data sink''). An output stream might also be an input stream, in which case it is sometimes called a bidirectional stream. See the function output-stream-p.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_p.htm new file mode 100644 index 00000000..d1d903c5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_p.htm @@ -0,0 +1,78 @@ + + + +CLHS: Glossary-Section P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +P

+

package n. an object of type package.

+

package cell n. Trad. (of a symbol) The place in a symbol that holds one of possibly several packages in which the symbol is interned, called the home package, or which holds nil if no such package exists or is known. See the function symbol-package.

+

package designator n. a designator for a package; that is, an object that denotes a package and that is one of: a string designator (denoting the package that has the string that it designates as its name or as one of its nicknames), or a package (denoting itself).

+

package marker n. a character which is used in the textual notation for a symbol to separate the package name from the symbol name, and which is colon in the standard readtable. See Section 2.1 (Character Syntax).

+

package prefix n. a notation preceding the name of a symbol in text that is processed by the Lisp reader, which uses a package name followed by one or more package markers, and which indicates that the symbol is looked up in the indicated package.

+

package registry n. A mapping of names to package objects. It is possible for there to be a package object which is not in this mapping; such a package is called an unregistered package. Operators such as find-package consult this mapping in order to find a package from its name. Operators such as do-all-symbols, find-all-symbols, and list-all-packages operate only on packages that exist in the package registry.

+

pairwise adv. (of an adjective on a set) applying individually to all possible pairings of elements of the set. ``The types A, B, and C are pairwise disjoint if A and B are disjoint, B and C are disjoint, and A and C are disjoint.''

+

parallel adj. Trad. (of binding or assignment) done in the style of psetq, let, or do; that is, first evaluating all of the forms that produce values, and only then assigning or binding the variables (or places). Note that this does not imply traditional computational ``parallelism'' since the forms that produce values are evaluated sequentially. See sequential.

+

parameter n. 1. (of a function) a variable in the definition of a function which takes on the value of a corresponding argument (or of a list of corresponding arguments) to that function when it is called, or which in some cases is given a default value because there is no corresponding argument. 2. (of a format directive) an object received as data flow by a format directive due to a prefix notation within the format string at the format directive's point of use. See Section 22.3 (Formatted Output). ``In "~3,'0D", the number 3 and the character #\0 are parameters to the ~D format directive.''

+

parameter specializer n. 1. (of a method) an expression which constrains the method to be applicable only to argument sequences in which the corresponding argument matches the parameter specializer. 2. a class, or a list (eql object).

+

parameter specializer name n. 1. (of a method definition) an expression used in code to name a parameter specializer. See Section 7.6.2 (Introduction to Methods). 2. a class, a symbol naming a class, or a list (eql form).

+

pathname n. an object of type pathname, which is a structured representation of the name of a file. A pathname has six components: a ``host,'' a ``device,'' a ``directory,'' a ``name,'' a ``type,'' and a ``version.''

+

pathname designator n. a designator for a pathname; that is, an object that denotes a pathname and that is one of: a pathname namestring (denoting the corresponding pathname), a stream associated with a file (denoting the pathname used to open the file; this may be, but is not required to be, the actual name of the file), or a pathname (denoting itself). See Section 21.1.1.1.2 (Open and Closed Streams).

+

physical pathname n. a pathname that is not a logical pathname.

+

+

place n. 1. a form which is suitable for use as a generalized reference. 2. the conceptual location referred to by such a place[1].

+

plist ['pee,list] n. a property list.

+

portable adj. (of code) required to produce equivalent results and observable side effects in all conforming implementations.

+

potential copy n. (of an object O1 subject to constriants) an object O2 that if the specified constraints are satisfied by O1 without any modification might or might not be identical to O1, or else that must be a fresh object that resembles a copy of O1 except that it has been modified as necessary to satisfy the constraints.

+

potential number n. A textual notation that might be parsed by the Lisp reader in some conforming implementation as a number but is not required to be parsed as a number. No object is a potential number---either an object is a number or it is not. See Section 2.3.1.1 (Potential Numbers as Tokens).

+

pprint dispatch table n. an object that can be the value of *print-pprint-dispatch* and hence can control how objects are printed when *print-pretty* is true. See Section 22.2.1.4 (Pretty Print Dispatch Tables).

+

predicate n. a function that returns a generalized boolean as its first value.

+

present n. 1. (of a feature in a Lisp image) a state of being that is in effect if and only if the symbol naming the feature is an element of the features list. 2. (of a symbol in a package) being accessible in that package directly, rather than being inherited from another package.

+

pretty print v.t. (an object) to invoke the pretty printer on the object.

+

pretty printer n. the procedure that prints the character representation of an object onto a stream when the value of *print-pretty* is true, and that uses layout techniques (e.g., indentation) that tend to highlight the structure of the object in a way that makes it easier for human readers to parse visually. See the variable *print-pprint-dispatch* and Section 22.2 (The Lisp Pretty Printer).

+

pretty printing stream n. a stream that does pretty printing. Such streams are created by the function pprint-logical-block as a link between the output stream and the logical block.

+

primary method n. a member of one of two sets of methods (the set of auxiliary methods is the other) that form an exhaustive partition of the set of methods on the method's generic function. How these sets are determined is dependent on the method combination type; see Section 7.6.2 (Introduction to Methods).

+

primary value n. (of values resulting from the evaluation of a form) the first value, if any, or else nil if there are no values. ``The primary value returned by truncate is an integer quotient, truncated toward zero.''

+

principal adj. (of a value returned by a Common Lisp function that implements a mathematically irrational or transcendental function defined in the complex domain) of possibly many (sometimes an infinite number of) correct values for the mathematical function, being the particular value which the corresponding Common Lisp function has been defined to return.

+

print name n. Trad. (usually of a symbol) a name[3].

+

printer control variable n. a variable whose specific purpose is to control some action of the Lisp printer; that is, one of the variables in Figure 22-1, or else some implementation-defined variable which is defined by the implementation to be a printer control variable.

+

printer escaping n. The combined state of the printer control variables *print-escape* and *print-readably*. If the value of either *print-readably* or *print-escape* is true, then printer escaping is ``enabled''; otherwise (if the values of both *print-readably* and *print-escape* are false), then printer escaping is ``disabled''.

+

printing adj. (of a character) being a graphic character other than space.

+

process v.t. (a form by the compiler) to perform minimal compilation, determining the time of evaluation for a form, and possibly evaluating that form (if required).

+

processor n., ANSI an implementation.

+

proclaim v.t. (a proclamation) to establish that proclamation.

+

proclamation n. a global declaration.

+

prog tag n. Trad. a go tag.

+

program n. Trad. Common Lisp code.

+

programmer n. an active entity, typically a human, that writes a program, and that might or might not also be a user of the program.

+

programmer code n. code that is supplied by the programmer; that is, code that is not system code.

+

proper list n. A list terminated by the empty list. (The empty list is a proper list.) See improper list.

+

proper name n. (of a class) a symbol that names the class whose name is that symbol. See the functions class-name and find-class.

+

proper sequence n. a sequence which is not an improper list; that is, a vector or a proper list.

+

proper subtype n. (of a type) a subtype of the type which is not the same type as the type (i.e., its elements are a ``proper subset'' of the type).

+

property n. (of a property list) 1. a conceptual pairing of a property indicator and its associated property value on a property list. 2. a property value.

+

property indicator n. (of a property list) the name part of a property, used as a key when looking up a property value on a property list.

+

property list n. 1. a list containing an even number of elements that are alternating names (sometimes called indicators or keys) and values (sometimes called properties). When there is more than one name and value pair with the identical name in a property list, the first such pair determines the property. 2. (of a symbol) the component of the symbol containing a property list.

+

+

property value n. (of a property indicator on a property list) the object associated with the property indicator on the property list.

+

purports to conform v. makes a good-faith claim of conformance. This term expresses intention to conform, regardless of whether the goal of that intention is realized in practice. For example, language implementations have been known to have bugs, and while an implementation of this specification with bugs might not be a conforming implementation, it can still purport to conform. This is an important distinction in certain specific cases; e.g., see the variable *features*.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_q.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_q.htm new file mode 100644 index 00000000..9cda5172 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_q.htm @@ -0,0 +1,31 @@ + + + +CLHS: Glossary-Section Q + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Q

+

qualified method n. a method that has one or more qualifiers.

+

qualifier n. (of a method for a generic function) one of possibly several objects used to annotate the method in a way that identifies its role in the method combination. The method combination type determines how many qualifiers are permitted for each method, which qualifiers are permitted, and the semantics of those qualifiers.

+

query I/O n. the bidirectional stream that is the value of the variable *query-io*.

+

quoted object n. an object which is the second element of a quote form.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_r.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_r.htm new file mode 100644 index 00000000..dbd8fef1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_r.htm @@ -0,0 +1,66 @@ + + + +CLHS: Glossary-Section R + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +R

+

radix n. an integer between 2 and 36, inclusive, which can be used to designate a base with respect to which certain kinds of numeric input or output are performed. (There are n valid digit characters for any given radix n, and those digits are the first n digits in the sequence 0, 1, ..., 9, A, B, ..., Z, which have the weights 0, 1, ..., 9, 10, 11, ..., 35, respectively. Case is not significant in parsing numbers of radix greater than 10, so ``9b8a'' and ``9B8A'' denote the same radix 16 number.)

+

random state n. an object of type random-state.

+

rank n. a non-negative integer indicating the number of dimensions of an array.

+

ratio n. an object of type ratio.

+

ratio marker n. a character which is used in the textual notation for a ratio to separate the numerator from the denominator, and which is slash in the standard readtable. See Section 2.1 (Character Syntax).

+

rational n. an object of type rational.

+

read v.t. 1. (a binding or slot or component) to obtain the value of the binding or slot. 2. (an object from a stream) to parse an object from its representation on the stream.

+

readably adv. (of a manner of printing an object O1) in such a way as to permit the Lisp Reader to later parse the printed output into an object O2 that is similar to O1.

+

reader n. 1. a function that reads[1] a variable or slot. 2. the Lisp reader.

+

reader macro n. 1. a textual notation introduced by dispatch on one or two characters that defines special-purpose syntax for use by the Lisp reader, and that is implemented by a reader macro function. See Section 2.2 (Reader Algorithm). 2. the character or characters that introduce a reader macro[1]; that is, a macro character or the conceptual pairing of a dispatching macro character and the character that follows it. (A reader macro is not a kind of macro.)

+

reader macro function n. a function designator that denotes a function that implements a reader macro[2]. See the functions set-macro-character and set-dispatch-macro-character.

+

readtable n. an object of type readtable.

+

readtable case n. an attribute of a readtable whose value is a case sensitivity mode, and that selects the manner in which characters in a symbol's name are to be treated by the Lisp reader and the Lisp printer. See Section 23.1.2 (Effect of Readtable Case on the Lisp Reader) and Section 22.1.3.3.2 (Effect of Readtable Case on the Lisp Printer).

+

readtable designator n. a designator for a readtable; that is, an object that denotes a readtable and that is one of: nil (denoting the standard readtable), or a readtable (denoting itself).

+

recognizable subtype n. (of a type) a subtype of the type which can be reliably detected to be such by the implementation. See the function subtypep.

+

reference n., v.t. 1. n. an act or occurrence of referring to an object, a binding, an exit point, a tag, or an environment. 2. v.t. to refer to an object, a binding, an exit point, a tag, or an environment, usually by name.

+

registered package n. a package object that is installed in the package registry. (Every registered package has a name that is a string, as well as zero or more string nicknames. All packages that are initially specified by Common Lisp or created by make-package or defpackage are registered packages. Registered packages can be turned into unregistered packages by delete-package.)

+

relative adj. 1. (of a time) representing an offset from an absolute time in the units appropriate to that time. For example, a relative internal time is the difference between two absolute internal times, and is measured in internal time units. 2. (of a pathname) representing a position in a directory hierarchy by motion from a position other than the root, which might therefore vary. ``The notation #P"../foo.text" denotes a relative pathname if the host file system is Unix.'' See absolute.

+

repertoire n., ISO a subtype of character. See Section 13.1.2.2 (Character Repertoires).

+

report n. (of a condition) to call the function print-object on the condition in an environment where the value of *print-escape* is false.

+

report message n. the text that is output by a condition reporter.

+

required parameter n. A parameter for which a corresponding positional argument must be supplied when calling the function.

+

rest list n. (of a function having a rest parameter) The list to which the rest parameter is bound on some particular call to the function.

+

rest parameter n. A parameter which was introduced by &rest.

+

restart n. an object of type restart.

+

restart designator n. a designator for a restart; that is, an object that denotes a restart and that is one of: a non-nil symbol (denoting the most recently established active restart whose name is that symbol), or a restart (denoting itself).

+

restart function n. a function that invokes a restart, as if by invoke-restart. The primary purpose of a restart function is to provide an alternate interface. By convention, a restart function usually has the same name as the restart which it invokes. The next figure shows a list of the standardized restart functions.

+

+abort     muffle-warning  use-value  
+continue  store-value                
+
+

Figure 26-4. Standardized Restart Functions

+

return v.t. (of values) 1. (from a block) to transfer control and values from the block; that is, to cause the block to yield the values immediately without doing any further evaluation of the forms in its body. 2. (from a form) to yield the values.

+

return value n. Trad. a value[1]

+

right-parenthesis n. the standard character ``)'', that is variously called ``right parenthesis'' or ``close parenthesis'' See Figure 2-5.

+

run time n. 1. load time 2. execution time

+

run-time compiler n. refers to the compile function or to implicit compilation, for which the compilation and run-time environments are maintained in the same Lisp image.

+

run-time definition n. a definition in the run-time environment.

+

run-time environment n. the environment in which a program is executed.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_s.htm new file mode 100644 index 00000000..2f772f0b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_s.htm @@ -0,0 +1,130 @@ + + + +CLHS: Glossary-Section S + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +S

+

safe adj. 1. (of code) processed in a lexical environment where the the highest safety level (3) was in effect. See optimize. 2. (of a call) a safe call.

+

safe call n. a call in which the call, the function being called, and the point of functional evaluation are all safe[1] code. For more detailed information, see Section 3.5.1.1 (Safe and Unsafe Calls).

+

same adj. 1. (of objects under a specified predicate) indistinguishable by that predicate. ``The symbol car, the string "car", and the string "CAR" are the same under string-equal''. 2. (of objects if no predicate is implied by context) indistinguishable by eql. Note that eq might be capable of distinguishing some numbers and characters which eql cannot distinguish, but the nature of such, if any, is implementation-dependent. Since eq is used only rarely in this specification, eql is the default predicate when none is mentioned explicitly. ``The conses returned by two successive calls to cons are never the same.'' 3. (of types) having the same set of elements; that is, each type is a subtype of the others. ``The types specified by (integer 0 1), (unsigned-byte 1), and bit are the same.''

+

satisfy the test v. (of an object being considered by a sequence function) 1. (for a one argument test) to be in a state such that the function which is the predicate argument to the sequence function returns true when given a single argument that is the result of calling the sequence function's key argument on the object being considered. See Section 17.2.2 (Satisfying a One-Argument Test). 2. (for a two argument test) to be in a state such that the two-place predicate which is the sequence function's test argument returns true when given a first argument that is the object being considered, and when given a second argument that is the result of calling the sequence function's key argument on an element of the sequence function's sequence argument which is being tested for equality; or to be in a state such that the test-not function returns false given the same arguments. See Section 17.2.1 (Satisfying a Two-Argument Test).

+

scope n. the structural or textual region of code in which references to an object, a binding, an exit point, a tag, or an environment (usually by name) can occur.

+

script n. ISO one of possibly several sets that form an exhaustive partition of the type character. See Section 13.1.2.1 (Character Scripts).

+

secondary value n. (of values resulting from the evaluation of a form) the second value, if any, or else nil if there are fewer than two values. ``The secondary value returned by truncate is a remainder.''

+

section n. a partitioning of output by a conditional newline on a pretty printing stream. See Section 22.2.1.1 (Dynamic Control of the Arrangement of Output).

+

self-evaluating object n. an object that is neither a symbol nor a cons. If a self-evaluating object is evaluated, it yields itself as its only value. ``Strings are self-evaluating objects.''

+

semi-standard adj. (of a language feature) not required to be implemented by any conforming implementation, but nevertheless recommended as the canonical approach in situations where an implementation does plan to support such a feature. The presence of semi-standard aspects in the language is intended to lessen portability problems and reduce the risk of gratuitous divergence among implementations that might stand in the way of future standardization.

+

semicolon n. the standard character that is called ``semicolon'' (;). See Figure 2-5.

+

sequence n. 1. an ordered collection of elements 2. a vector or a list.

+

sequence function n. one of the functions in Figure 17-1, or an implementation-defined function that operates on one or more sequences. and that is defined by the implementation to be a sequence function.

+

sequential adj. Trad. (of binding or assignment) done in the style of setq, let*, or do*; that is, interleaving the evaluation of the forms that produce values with the assignments or bindings of the variables (or places). See parallel.

+

sequentially adv. in a sequential way.

+

serious condition n. a condition of type serious-condition, which represents a situation that is generally sufficiently severe that entry into the debugger should be expected if the condition is signaled but not handled.

+

session n. the conceptual aggregation of events in a Lisp image from the time it is started to the time it is terminated.

+

set v.t. Trad. (any variable or a symbol that is the name of a dynamic variable) to assign the variable.

+

setf expander n. a function used by setf to compute the setf expansion of a place.

+

setf expansion n. a set of five expressions[1] that, taken together, describe how to store into a place and which subforms of the macro call associated with the place are evaluated. See Section 5.1.1.2 (Setf Expansions).

+

setf function n. a function whose name is (setf symbol).

+

setf function name n. (of a symbol S) the list (setf S).

+

shadow v.t. 1. to override the meaning of. ``That binding of X shadows an outer one.'' 2. to hide the presence of. ``That macrolet of F shadows the outer flet of F.'' 3. to replace. ``That package shadows the symbol cl:car with its own symbol car.''

+

shadowing symbol n. (in a package) an element of the package's shadowing symbols list.

+

shadowing symbols list n. (of a package) a list, associated with the package, of symbols that are to be exempted from `symbol conflict errors' detected when packages are used. See the function package-shadowing-symbols.

+

shared slot n. (of a class) a slot accessible in more than one instance of a class; specifically, such a slot is accessible in all direct instances of the class and in those indirect instances whose class does not shadow[1] the slot.

+

sharpsign n. the standard character that is variously called ``number sign,'' ``sharp,'' or ``sharp sign'' (#). See Figure 2-5.

+

short float n. an object of type short-float.

+

sign n. one of the standard characters ``+'' or ``-''.

+

signal v. to announce, using a standard protocol, that a particular situation, represented by a condition, has been detected. See Section 9.1 (Condition System Concepts).

+

signature n. (of a method) a description of the parameters and parameter specializers for the method which determines the method's applicability for a given set of required arguments, and which also describes the argument conventions for its other, non-required arguments.

+

similar adj. (of two objects) defined to be equivalent under the similarity relationship.

+

similarity n. a two-place conceptual equivalence predicate, which is independent of the Lisp image so that two objects in different Lisp images can be understood to be equivalent under this predicate. See Section 3.2.4 (Literal Objects in Compiled Files).

+

simple adj. 1. (of an array) being of type simple-array. 2. (of a character) having no implementation-defined attributes, or else having implementation-defined attributes each of which has the null value for that attribute.

+

simple array n. an array of type simple-array.

+

simple bit array n. a bit array that is a simple array; that is, an object of type (simple-array bit).

+

simple bit vector n. a bit vector of type simple-bit-vector.

+

simple condition n. a condition of type simple-condition.

+

simple general vector n. a simple vector.

+

simple string n. a string of type simple-string.

+

simple vector n. a vector of type simple-vector, sometimes called a ``simple general vector.'' Not all vectors that are simple are simple vectors---only those that have element type t.

+

single escape n., adj. 1. n. the syntax type of a character that indicates that the next character is to be treated as an alphabetic[2] character with its case preserved. For details, see Section 2.1.4.6 (Single Escape Character). 2. adj. (of a character) having the single escape syntax type. 3. n. a single escape[2] character. (In the standard readtable, slash is the only single escape.)

+

single float n. an object of type single-float.

+

single-quote n. the standard character that is variously called ``apostrophe,'' ``acute accent,'' ``quote,'' or ``single quote'' ('). See Figure 2-5.

+

singleton adj. (of a sequence) having only one element. ``(list 'hello) returns a singleton list.''

+

situation n. the evaluation of a form in a specific environment.

+

slash n. the standard character that is variously called ``solidus'' or ``slash'' (/). See Figure 2-5.

+

slot n. a component of an object that can store a value.

+

slot specifier n. a representation of a slot that includes the name of the slot and zero or more slot options. A slot option pertains only to a single slot.

+

source code n. code representing objects suitable for evaluation (e.g., objects created by read, by macro expansion, or by compiler macro expansion).

+

source file n. a file which contains a textual representation of source code, that can be edited, loaded, or compiled.

+

space n. the standard character <Space>, notated for the Lisp reader as #\Space.

+

special form n. a list, other than a macro form, which is a form with special syntax or special evaluation rules or both, possibly manipulating the evaluation environment or control flow or both. The first element of a special form is a special operator.

+

special operator n. one of a fixed set of symbols, enumerated in Figure 3-2, that may appear in the car of a form in order to identify the form as a special form.

+

special variable n. Trad. a dynamic variable.

+

specialize v.t. (a generic function) to define a method for the generic function, or in other words, to refine the behavior of the generic function by giving it a specific meaning for a particular set of classes or arguments.

+

specialized adj. 1. (of a generic function) having methods which specialize the generic function. 2. (of an array) having an actual array element type that is a proper subtype of the type t; see Section 15.1.1 (Array Elements). ``(make-array 5 :element-type 'bit) makes an array of length five that is specialized for bits.''

+

specialized lambda list n. an extended lambda list used in forms that establish method definitions, such as defmethod. See Section 3.4.3 (Specialized Lambda Lists).

+

spreadable argument list designator n. a designator for a list of objects; that is, an object that denotes a list and that is a non-null list L1 of length n, whose last element is a list L2 of length m (denoting a list L3 of length m+n-1 whose elements are L1i for i < n-1 followed by L2j for j < m). ``The list (1 2 (3 4 5)) is a spreadable argument list designator for the list (1 2 3 4 5).''

+

stack allocate v.t. Trad. to allocate in a non-permanent way, such as on a stack. Stack-allocation is an optimization technique used in some implementations for allocating certain kinds of objects that have dynamic extent. Such objects are allocated on the stack rather than in the heap so that their storage can be freed as part of unwinding the stack rather than taking up space in the heap until the next garbage collection. What types (if any) can have dynamic extent can vary from implementation to implementation. No implementation is ever required to perform stack-allocation.

+

stack-allocated adj. Trad. having been stack allocated.

+

standard character n. a character of type standard-char, which is one of a fixed set of 96 such characters required to be present in all conforming implementations. See Section 2.1.3 (Standard Characters).

+

standard class n. a class that is a generalized instance of class standard-class.

+

standard generic function a function of type standard-generic-function.

+

standard input n. the input stream which is the value of the dynamic variable *standard-input*.

+

standard method combination n. the method combination named standard.

+

standard object n. an object that is a generalized instance of class standard-object.

+

standard output n. the output stream which is the value of the dynamic variable *standard-output*.

+

standard pprint dispatch table n. A pprint dispatch table that is different from the initial pprint dispatch table, that implements pretty printing as described in this specification, and that, unlike other pprint dispatch tables, must never be modified by any program. (Although the definite reference ``the standard pprint dispatch table'' is generally used within this document, it is actually implementation-dependent whether a single object fills the role of the standard pprint dispatch table, or whether there might be multiple such objects, any one of which could be used on any given occasion where ``the standard pprint dispatch table'' is called for. As such, this phrase should be seen as an indefinite reference in all cases except for anaphoric references.)

+

standard readtable n. A readtable that is different from the initial readtable, that implements the expression syntax defined in this specification, and that, unlike other readtables, must never be modified by any program. (Although the definite reference ``the standard readtable'' is generally used within this document, it is actually implementation-dependent whether a single object fills the role of the standard readtable, or whether there might be multiple such objects, any one of which could be used on any given occasion where ``the standard readtable'' is called for. As such, this phrase should be seen as an indefinite reference in all cases except for anaphoric references.)

+

standard syntax n. the syntax represented by the standard readtable and used as a reference syntax throughout this document. See Section 2.1 (Character Syntax).

+

standardized adj. (of a name, object, or definition) having been defined by Common Lisp. ``All standardized variables that are required to hold bidirectional streams have ``-io*'' in their name.''

+

startup environment n. the global environment of the running Lisp image from which the compiler was invoked.

+

step v.t., n. 1. v.t. (an iteration variable) to assign the variable a new value at the end of an iteration, in preparation for a new iteration. 2. n. the code that identifies how the next value in an iteration is to be computed. 3. v.t. (code) to specially execute the code, pausing at intervals to allow user confirmation or intervention, usually for debugging.

+

stream n. an object that can be used with an input or output function to identify an appropriate source or sink of characters or bytes for that operation.

+

stream associated with a file n. a file stream, or a synonym stream the target of which is a stream associated with a file. Such a stream cannot be created with make-two-way-stream, make-echo-stream, make-broadcast-stream, make-concatenated-stream, make-string-input-stream, or make-string-output-stream.

+

stream designator n. a designator for a stream; that is, an object that denotes a stream and that is one of: t (denoting the value of *terminal-io*), nil (denoting the value of *standard-input* for input stream designators or denoting the value of *standard-output* for output stream designators), or a stream (denoting itself).

+

stream element type n. (of a stream) the type of data for which the stream is specialized.

+

stream variable n. a variable whose value must be a stream.

+

stream variable designator n. a designator for a stream variable; that is, a symbol that denotes a stream variable and that is one of: t (denoting *terminal-io*), nil (denoting *standard-input* for input stream variable designators or denoting *standard-output* for output stream variable designators), or some other symbol (denoting itself).

+

string n. a specialized vector that is of type string, and whose elements are of type character or a subtype of type character.

+

string designator n. a designator for a string; that is, an object that denotes a string and that is one of: a character (denoting a singleton string that has the character as its only element), a symbol (denoting the string that is its name), or a string (denoting itself). The intent is that this term be consistent with the behavior of string; implementations that extend string must extend the meaning of this term in a compatible way.

+

string equal adj. the same under string-equal.

+

string stream n. a stream of type string-stream.

+

structure n. an object of type structure-object.

+

structure class n. a class that is a generalized instance of class structure-class.

+

structure name n. a name defined with defstruct. Usually, such a type is also a structure class, but there may be implementation-dependent situations in which this is not so, if the :type option to defstruct is used.

+

style warning n. a condition of type style-warning.

+

subclass n. a class that inherits from another class, called a superclass. (No class is a subclass of itself.)

+

subexpression n. (of an expression) an expression that is contained within the expression. (In fact, the state of being a subexpression is not an attribute of the subexpression, but really an attribute of the containing expression since the same object can at once be a subexpression in one context, and not in another.)

+

subform n. (of a form) an expression that is a subexpression of the form, and which by virtue of its position in that form is also a form. ``(f x) and x, but not exit, are subforms of (return-from exit (f x)).''

+

subrepertoire n. a subset of a repertoire.

+

subtype n. a type whose membership is the same as or a proper subset of the membership of another type, called a supertype. (Every type is a subtype of itself.)

+

superclass n. a class from which another class (called a subclass) inherits. (No class is a superclass of itself.) See subclass.

+

supertype n. a type whose membership is the same as or a proper superset of the membership of another type, called a subtype. (Every type is a supertype of itself.) See subtype.

+

supplied-p parameter n. a parameter which recieves its generalized boolean value implicitly due to the presence or absence of an argument corresponding to another parameter (such as an optional parameter or a rest parameter). See Section 3.4.1 (Ordinary Lambda Lists).

+

symbol n. an object of type symbol.

+

symbol macro n. a symbol that stands for another form. See the macro symbol-macrolet.

+

synonym stream n. 1. a stream of type synonym-stream, which is consequently a stream that is an alias for another stream, which is the value of a dynamic variable whose name is the synonym stream symbol of the synonym stream. See the function make-synonym-stream. 2. (to a stream) a synonym stream which has the stream as the value of its synonym stream symbol. 3. (to a symbol) a synonym stream which has the symbol as its synonym stream symbol.

+

synonym stream symbol n. (of a synonym stream) the symbol which names the dynamic variable which has as its value another stream for which the synonym stream is an alias.

+

syntax type n. (of a character) one of several classifications, enumerated in Figure 2-6, that are used for dispatch during parsing by the Lisp reader. See Section 2.1.4 (Character Syntax Types).

+

system class n. a class that may be of type built-in-class in a conforming implementation and hence cannot be inherited by classes defined by conforming programs.

+

system code n. code supplied by the implementation to implement this specification (e.g., the definition of mapcar) or generated automatically in support of this specification (e.g., during method combination); that is, code that is not programmer code.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_t.htm new file mode 100644 index 00000000..bd05f33c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_t.htm @@ -0,0 +1,51 @@ + + + +CLHS: Glossary-Section T + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +T

+

t n. 1. a. the boolean representing true. b. the canonical generalized boolean representing true. (Although any object other than nil is considered true as a generalized boolean, t is generally used when there is no special reason to prefer one such object over another.) 2. the name of the type to which all objects belong---the supertype of all types (including itself). 3. the name of the superclass of all classes except itself.

+

tag n. 1. a catch tag. 2. a go tag.

+

tail n. (of a list) an object that is the same as either some cons which makes up that list or the atom (if any) which terminates the list. ``The empty list is a tail of every proper list.''

+

target n. 1. (of a constructed stream) a constituent of the constructed stream. ``The target of a synonym stream is the value of its synonym stream symbol.'' 2. (of a displaced array) the array to which the displaced array is displaced. (In the case of a chain of constructed streams or displaced arrays, the unqualified term ``target'' always refers to the immediate target of the first item in the chain, not the immediate target of the last item.)

+

terminal I/O n. the bidirectional stream that is the value of the variable *terminal-io*.

+

terminating n. (of a macro character) being such that, if it appears while parsing a token, it terminates that token. See Section 2.2 (Reader Algorithm).

+

tertiary value n. (of values resulting from the evaluation of a form) the third value, if any, or else nil if there are fewer than three values.

+

throw v. to transfer control and values to a catch. See the special operator throw.

+

tilde n. the standard character that is called ``tilde'' (~). See Figure 2-5.

+

time a representation of a point (absolute time) or an interval (relative time) on a time line. See decoded time, internal time, and universal time.

+

time zone n. a rational multiple of 1/3600 between -24 (inclusive) and 24 (inclusive) that represents a time zone as a number of hours offset from Greenwich Mean Time. Time zone values increase with motion to the west, so Massachusetts, U.S.A. is in time zone 5, California, U.S.A. is time zone 8, and Moscow, Russia is time zone -3. (When ``daylight savings time'' is separately represented as an argument or return value, the time zone that accompanies it does not depend on whether daylight savings time is in effect.)

+

token n. a textual representation for a number or a symbol. See Section 2.3 (Interpretation of Tokens).

+

top level form n. a form which is processed specially by compile-file for the purposes of enabling compile time evaluation of that form. Top level forms include those forms which are not subforms of any other form, and certain other cases. See Section 3.2.3.1 (Processing of Top Level Forms).

+

trace output n. the output stream which is the value of the dynamic variable *trace-output*.

+

tree n. 1. a binary recursive data structure made up of conses and atoms: the conses are themselves also trees (sometimes called ``subtrees'' or ``branches''), and the atoms are terminal nodes (sometimes called leaves). Typically, the leaves represent data while the branches establish some relationship among that data. 2. in general, any recursive data structure that has some notion of ``branches'' and leaves.

+

tree structure n. (of a tree[1]) the set of conses that make up the tree. Note that while the car[1b] component of each such cons is part of the tree structure, the objects that are the cars[2] of each cons in the tree are not themselves part of its tree structure unless they are also conses.

+

true n. any object that is not false and that is used to represent the success of a predicate test. See t[1].

+

truename n. 1. the canonical filename of a file in the file system. See Section 20.1.3 (Truenames). 2. a pathname representing a truename[1].

+

two-way stream n. a stream of type two-way-stream, which is a bidirectional composite stream that receives its input from an associated input stream and sends its output to an associated output stream.

+

type n. 1. a set of objects, usually with common structure, behavior, or purpose. (Note that the expression ``X is of type Sa'' naturally implies that ``X is of type Sb'' if Sa is a subtype of Sb.) 2. (immediately following the name of a type) a subtype of that type. ``The type vector is an array type.''

+

type declaration n. a declaration that asserts that every reference to a specified binding within the scope of the declaration results in some object of the specified type.

+

type equivalent adj. (of two types X and Y) having the same elements; that is, X is a subtype of Y and Y is a subtype of X.

+

type expand n. to fully expand a type specifier, removing any references to derived types. (Common Lisp provides no program interface to cause this to occur, but the semantics of Common Lisp are such that every implementation must be able to do this internally, and some situations involving type specifiers are most easily described in terms of a fully expanded type specifier.)

+

type specifier n. an expression that denotes a type. ``The symbol random-state, the list (integer 3 5), the list (and list (not null)), and the class named standard-class are type specifiers.''

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_u.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_u.htm new file mode 100644 index 00000000..aae686b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_u.htm @@ -0,0 +1,44 @@ + + + +CLHS: Glossary-Section U + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +U

+

unbound adj. not having an associated denotation in a binding. See bound.

+

unbound variable n. a name that is syntactically plausible as the name of a variable but which is not bound in the variable namespace.

+

undefined function n. a name that is syntactically plausible as the name of a function but which is not bound in the function namespace.

+

unintern v.t. (a symbol in a package) to make the symbol not be present in that package. (The symbol might continue to be accessible by inheritance.)

+

uninterned adj. (of a symbol) not accessible in any package; i.e., not interned[1].

+

universal time n. time, represented as a non-negative integer number of seconds. Absolute universal time is measured as an offset from the beginning of the year 1900 (ignoring leap seconds). See Section 25.1.4.2 (Universal Time).

+

unqualified method n. a method with no qualifiers.

+

unregistered package n. a package object that is not present in the package registry. An unregistered package has no name; i.e., its name is nil. See the function delete-package.

+

unsafe adj. (of code) not safe. (Note that, unless explicitly specified otherwise, if a particular kind of error checking is guaranteed only in a safe context, the same checking might or might not occur in that context if it were unsafe; describing a context as unsafe means that certain kinds of error checking are not reliably enabled but does not guarantee that error checking is definitely disabled.)

+

unsafe call n. a call that is not a safe call. For more detailed information, see Section 3.5.1.1 (Safe and Unsafe Calls).

+

upgrade v.t. (a declared type to an actual type) 1. (when creating an array) to substitute an actual array element type for an expressed array element type when choosing an appropriately specialized array representation. See the function upgraded-array-element-type. 2. (when creating a complex) to substitute an actual complex part type for an expressed complex part type when choosing an appropriately specialized complex representation. See the function upgraded-complex-part-type.

+

upgraded array element type n. (of a type) a type that is a supertype of the type and that is used instead of the type whenever the type is used as an array element type for object creation or type discrimination. See Section 15.1.2.1 (Array Upgrading).

+

upgraded complex part type n. (of a type) a type that is a supertype of the type and that is used instead of the type whenever the type is used as a complex part type for object creation or type discrimination. See the function upgraded-complex-part-type.

+

uppercase adj. (of a character) being among standard characters corresponding to the capital letters A through Z, or being some other implementation-defined character that is defined by the implementation to be uppercase. See Section 13.1.4.3 (Characters With Case).

+

use v.t. (a package P1) to inherit the external symbols of P1. (If a package P2 uses P1, the external symbols of P1 become internal symbols of P2 unless they are explicitly exported.) ``The package CL-USER uses the package CL.''

+

use list n. (of a package) a (possibly empty) list associated with each package which determines what other packages are currently being used by that package.

+

user n. an active entity, typically a human, that invokes or interacts with a program at run time, but that is not necessarily a programmer.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_v.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_v.htm new file mode 100644 index 00000000..368454c3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_v.htm @@ -0,0 +1,47 @@ + + + +CLHS: Glossary-Section V + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +V

+

valid array dimension n. a fixnum suitable for use as an array dimension. Such a fixnum must be greater than or equal to zero, and less than the value of array-dimension-limit. When multiple array dimensions are to be used together to specify a multi-dimensional array, there is also an implied constraint that the product of all of the dimensions be less than the value of array-total-size-limit.

+

valid array index n. (of an array) a fixnum suitable for use as one of possibly several indices needed to name an element of the array according to a multi-dimensional Cartesian coordinate system. Such a fixnum must be greater than or equal to zero, and must be less than the corresponding dimension[1] of the array. (Unless otherwise explicitly specified, the phrase ``a list of valid array indices'' further implies that the length of the list must be the same as the rank of the array.) ``For a 2 by 3 array, valid array indices for the first dimension are 0 and 1, and valid array indices for the second dimension are 0, 1 and 2.''

+

valid array row-major index n. (of an array, which might have any number of dimensions[2]) a single fixnum suitable for use in naming any element of the array, by viewing the array's storage as a linear series of elements in row-major order. Such a fixnum must be greater than or equal to zero, and less than the array total size of the array.

+

valid fill pointer n. (of an array) a fixnum suitable for use as a fill pointer for the array. Such a fixnum must be greater than or equal to zero, and less than or equal to the array total size of the array.

+

+

valid logical pathname host n. a string that has been defined as the name of a logical host. See the function load-logical-pathname-translations.

+

valid pathname device n. a string, nil, :unspecific, or some other object defined by the implementation to be a valid pathname device.

+

valid pathname directory n. a string, a list of strings, nil, :wild, :unspecific, or some other object defined by the implementation to be a valid directory component.

+

valid pathname host n. a valid physical pathname host or a valid logical pathname host.

+

valid pathname name n. a string, nil, :wild, :unspecific, or some other object defined by the implementation to be a valid pathname name.

+

valid pathname type n. a string, nil, :wild, :unspecific.

+

valid pathname version n. a non-negative integer, or one of :wild, :newest, :unspecific, or nil. The symbols :oldest, :previous, and :installed are semi-standard special version symbols.

+

valid physical pathname host n. any of a string, a list of strings, or the symbol :unspecific, that is recognized by the implementation as the name of a host.

+

+

valid sequence index n. (of a sequence) an integer suitable for use to name an element of the sequence. Such an integer must be greater than or equal to zero, and must be less than the length of the sequence. (If the sequence is an array, the valid sequence index is further constrained to be a fixnum.)

+

value n. 1. a. one of possibly several objects that are the result of an evaluation. b. (in a situation where exactly one value is expected from the evaluation of a form) the primary value returned by the form. c. (of forms in an implicit progn) one of possibly several objects that result from the evaluation of the last form, or nil if there are no forms. 2. an object associated with a name in a binding. 3. (of a symbol) the value of the dynamic variable named by that symbol. 4. an object associated with a key in an association list, a property list, or a hash table.

+

value cell n. Trad. (of a symbol) The place which holds the value, if any, of the dynamic variable named by that symbol, and which is accessed by symbol-value. See cell.

+

variable n. a binding in the ``variable'' namespace. See Section 3.1.2.1.1 (Symbols as Forms).

+

vector n. a one-dimensional array.

+

vertical-bar n. the standard character that is called ``vertical bar'' (|). See Figure 2-5.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_w.htm new file mode 100644 index 00000000..6f05690f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_w.htm @@ -0,0 +1,31 @@ + + + +CLHS: Glossary-Section W + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +W

+

whitespace n. 1. one or more characters that are either the graphic character #\Space or else non-graphic characters such as #\Newline that only move the print position. 2. a. n. the syntax type of a character that is a token separator. For details, see Section 2.1.4.7 (Whitespace Characters). b. adj. (of a character) having the whitespace[2a] syntax type[2]. c. n. a whitespace[2b] character.

+

wild adj. 1. (of a namestring) using an implementation-defined syntax for naming files, which might ``match'' any of possibly several possible filenames, and which can therefore be used to refer to the aggregate of the files named by those filenames. 2. (of a pathname) a structured representation of a name which might ``match'' any of possibly several pathnames, and which can therefore be used to refer to the aggregate of the files named by those pathnames. The set of wild pathnames includes, but is not restricted to, pathnames which have a component which is :wild, or which have a directory component which contains :wild or :wild-inferors. See the function wild-pathname-p.

+

write v.t. 1. (a binding or slot or component) to change the value of the binding or slot. 2. (an object to a stream) to output a representation of the object to the stream.

+

writer n. a function that writes[1] a variable or slot.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_y.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_y.htm new file mode 100644 index 00000000..7761ff16 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/26_glo_y.htm @@ -0,0 +1,28 @@ + + + +CLHS: Glossary-Section Y + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Y

+

yield v.t. (values) to produce the values as the result of evaluation. ``The form (+ 2 3) yields 5.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_.htm new file mode 100644 index 00000000..04f7dcf3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_.htm @@ -0,0 +1,36 @@ + + + +CLHS: Appendix + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+

+

+A. Appendix

+

+ + +

+A.1 Removed Language Features

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_a.htm new file mode 100644 index 00000000..f9ba6849 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_a.htm @@ -0,0 +1,49 @@ + + + +CLHS: Section A.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1 Removed Language Features

+ + +

+A.1.1 Requirements for removed and deprecated features

+ +

+A.1.2 Removed Types

+ +

+A.1.3 Removed Operators

+ +

+A.1.4 Removed Argument Conventions

+ +

+A.1.5 Removed Variables

+ +

+A.1.6 Removed Reader Syntax

+ +

+A.1.7 Packages No Longer Required

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_aa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_aa.htm new file mode 100644 index 00000000..31294e15 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_aa.htm @@ -0,0 +1,31 @@ + + + +CLHS: Section A.1.1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1.1 Requirements for removed and deprecated features

+ For this standard, some features from the language described in Common Lisp: The Language have been removed, and others have been deprecated (and will most likely not appear in future Common Lisp standards). Which features were removed and which were deprecated was decided on a case-by-case basis by the X3J13 committee.

+Conforming implementations that wish to retain any removed features for compatibility must assure that such compatibility does not interfere with the correct function of conforming programs. For example, symbols corresponding to the names of removed functions may not appear in the the COMMON-LISP package. (Note, however, that this specification has been devised in such a way that there can be a package named LISP which can contain such symbols.)

+Conforming implementations must implement all deprecated features. For a list of deprecated features, see Section 1.8 (Deprecated Language Features).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ab.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ab.htm new file mode 100644 index 00000000..303e4194 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ab.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section A.1.2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1.2 Removed Types

+ The type string-char was removed.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ac.htm new file mode 100644 index 00000000..c7520a9e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ac.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section A.1.3 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1.3 Removed Operators

+The functions int-char, char-bits, char-font, make-char, char-bit, set-char-bit, string-char-p, and commonp were removed.

+ The special operator compiler-let was removed.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ad.htm new file mode 100644 index 00000000..c82787a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ad.htm @@ -0,0 +1,30 @@ + + + +CLHS: Section A.1.4 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1.4 Removed Argument Conventions

+ The font argument to digit-char was removed. The bits and font arguments to code-char were removed.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ae.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ae.htm new file mode 100644 index 00000000..3e8709b7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ae.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section A.1.5 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1.5 Removed Variables

+The variables char-font-limit, char-bits-limit, char-control-bit, char-meta-bit, char-super-bit, char-hyper-bit, and *break-on-warnings* were removed.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_af.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_af.htm new file mode 100644 index 00000000..3aefd75b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_af.htm @@ -0,0 +1,29 @@ + + + +CLHS: Section A.1.6 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+A.1.6 Removed Reader Syntax

+The ``#,'' reader macro in standard syntax was removed.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ag.htm new file mode 100644 index 00000000..c9a9b5d3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/27_ag.htm @@ -0,0 +1,28 @@ + + + +CLHS: Section A.1.7 + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][No Next]

+ +
+ +

+A.1.7 Packages No Longer Required

+The packages LISP, USER, and SYSTEM are no longer required. It is valid for packages with one or more of these names to be provided by a conforming implementation as extensions.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a__.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a__.htm new file mode 100644 index 00000000..0b70b7e2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a__.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for - + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

-

+Please select which reference to - you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_abort.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_abort.htm new file mode 100644 index 00000000..044337d8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_abort.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for ABORT + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

ABORT

+Please select which reference to ABORT you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_and.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_and.htm new file mode 100644 index 00000000..49bf6843 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_and.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for AND + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

AND

+Please select which reference to AND you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_atom.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_atom.htm new file mode 100644 index 00000000..1ae58480 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_atom.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for ATOM + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

ATOM

+Please select which reference to ATOM you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_bit.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_bit.htm new file mode 100644 index 00000000..645496c6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_bit.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for BIT + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

BIT

+Please select which reference to BIT you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ch.htm new file mode 100644 index 00000000..40c42cf3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ch.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for CHARACTER + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

CHARACTER

+Please select which reference to CHARACTER you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_comple.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_comple.htm new file mode 100644 index 00000000..d0473dd9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_comple.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for COMPLEX + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

COMPLEX

+Please select which reference to COMPLEX you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_cons.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_cons.htm new file mode 100644 index 00000000..4e4f8f4b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_cons.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for CONS + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

CONS

+Please select which reference to CONS you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_contin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_contin.htm new file mode 100644 index 00000000..3ebcc848 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_contin.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for CONTINUE + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

CONTINUE

+Please select which reference to CONTINUE you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_eql.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_eql.htm new file mode 100644 index 00000000..23e1f3cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_eql.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for EQL + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

EQL

+Please select which reference to EQL you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_error.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_error.htm new file mode 100644 index 00000000..45870569 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_error.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for ERROR + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

ERROR

+Please select which reference to ERROR you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_float.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_float.htm new file mode 100644 index 00000000..cfe21deb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_float.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for FLOAT + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

FLOAT

+Please select which reference to FLOAT you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_fn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_fn.htm new file mode 100644 index 00000000..90a3e689 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_fn.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for FUNCTION + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

FUNCTION

+Please select which reference to FUNCTION you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_lambda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_lambda.htm new file mode 100644 index 00000000..352f6039 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_lambda.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for LAMBDA + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

LAMBDA

+Please select which reference to LAMBDA you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_list.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_list.htm new file mode 100644 index 00000000..787a306d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_list.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for LIST + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

LIST

+Please select which reference to LIST you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_logica.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_logica.htm new file mode 100644 index 00000000..b045fa5d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_logica.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for LOGICAL-PATHNAME + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

LOGICAL-PATHNAME

+Please select which reference to LOGICAL-PATHNAME you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_member.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_member.htm new file mode 100644 index 00000000..347d710f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_member.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for MEMBER + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

MEMBER

+Please select which reference to MEMBER you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_method.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_method.htm new file mode 100644 index 00000000..33a27136 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_method.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for METHOD-COMBINATION + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

METHOD-COMBINATION

+Please select which reference to METHOD-COMBINATION you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_mod.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_mod.htm new file mode 100644 index 00000000..5fae8cd3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_mod.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for MOD + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

MOD

+Please select which reference to MOD you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_muffle.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_muffle.htm new file mode 100644 index 00000000..aa975ee6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_muffle.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for MUFFLE-WARNING + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

MUFFLE-WARNING

+Please select which reference to MUFFLE-WARNING you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_nil.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_nil.htm new file mode 100644 index 00000000..feb7ef5d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_nil.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for NIL + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

NIL

+Please select which reference to NIL you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_not.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_not.htm new file mode 100644 index 00000000..3598029a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_not.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for NOT + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

NOT

+Please select which reference to NOT you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_null.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_null.htm new file mode 100644 index 00000000..d1071e94 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_null.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for NULL + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

NULL

+Please select which reference to NULL you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_or.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_or.htm new file mode 100644 index 00000000..9d95a21c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_or.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for OR + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

OR

+Please select which reference to OR you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pl.htm new file mode 100644 index 00000000..a7e79ff7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pl.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

+

+Please select which reference to + you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pn.htm new file mode 100644 index 00000000..786c1962 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_pn.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for PATHNAME + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

PATHNAME

+Please select which reference to PATHNAME you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ration.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ration.htm new file mode 100644 index 00000000..fba519af --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_ration.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for RATIONAL + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

RATIONAL

+Please select which reference to RATIONAL you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_setf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_setf.htm new file mode 100644 index 00000000..80d04aa3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_setf.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for SETF + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

SETF

+Please select which reference to SETF you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_sl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_sl.htm new file mode 100644 index 00000000..fbd20bdc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_sl.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for / + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

/

+Please select which reference to / you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_st.htm new file mode 100644 index 00000000..03fd8cf8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_st.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for * + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

*

+Please select which reference to * you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_store_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_store_.htm new file mode 100644 index 00000000..9fa68d22 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_store_.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for STORE-VALUE + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

STORE-VALUE

+Please select which reference to STORE-VALUE you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_string.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_string.htm new file mode 100644 index 00000000..ac8691b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_string.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for STRING + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

STRING

+Please select which reference to STRING you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_t.htm new file mode 100644 index 00000000..57c95535 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_t.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for T + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

T

+Please select which reference to T you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_type.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_type.htm new file mode 100644 index 00000000..7c025b7b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_type.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for TYPE + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

TYPE

+Please select which reference to TYPE you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_use_va.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_use_va.htm new file mode 100644 index 00000000..320cd26d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_use_va.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for USE-VALUE + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

USE-VALUE

+Please select which reference to USE-VALUE you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_values.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_values.htm new file mode 100644 index 00000000..7fd83f2c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_values.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for VALUES + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

VALUES

+Please select which reference to VALUES you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_vector.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_vector.htm new file mode 100644 index 00000000..d926bf2a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/a_vector.htm @@ -0,0 +1,21 @@ + + + +CLHS: Meanings for VECTOR + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

+ +
+ +

VECTOR

+Please select which reference to VECTOR you intended: + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_arrays.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_arrays.htm new file mode 100644 index 00000000..98408c2d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_arrays.htm @@ -0,0 +1,130 @@ + + + +CLHS: Section The Arrays Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+15.2 The Arrays Dictionary

+ + +System Class ARRAY

+ +Type SIMPLE-ARRAY

+ +System Class VECTOR

+ +Type SIMPLE-VECTOR

+ +System Class BIT-VECTOR

+ +Type SIMPLE-BIT-VECTOR

+ + +Function MAKE-ARRAY

+ + +Function ADJUST-ARRAY

+ + +Function ADJUSTABLE-ARRAY-P

+ + +Accessor AREF

+ + +Function ARRAY-DIMENSION

+ + +Function ARRAY-DIMENSIONS

+ + +Function ARRAY-ELEMENT-TYPE

+ + +Function ARRAY-HAS-FILL-POINTER-P

+ + +Function ARRAY-DISPLACEMENT

+ + +Function ARRAY-IN-BOUNDS-P

+ + +Function ARRAY-RANK

+ + +Function ARRAY-ROW-MAJOR-INDEX

+ + +Function ARRAY-TOTAL-SIZE

+ + +Function ARRAYP

+ + +Accessor FILL-POINTER

+ + +Accessor ROW-MAJOR-AREF

+ + +Function UPGRADED-ARRAY-ELEMENT-TYPE

+ + +Constant Variable ARRAY-DIMENSION-LIMIT

+ + +Constant Variable ARRAY-RANK-LIMIT

+ + +Constant Variable ARRAY-TOTAL-SIZE-LIMIT

+ + +Function SIMPLE-VECTOR-P

+ + +Accessor SVREF

+ + +Function VECTOR

+ + +Function VECTOR-POP

+ + +Function VECTOR-PUSH, VECTOR-PUSH-EXTEND

+ + +Function VECTORP

+ + +Accessor BIT, SBIT

+ + +Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR

+ + +Function BIT-VECTOR-P

+ + +Function SIMPLE-BIT-VECTOR-P

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_charac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_charac.htm new file mode 100644 index 00000000..55f90422 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_charac.htm @@ -0,0 +1,87 @@ + + + +CLHS: Section The Characters Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+13.2 The Characters Dictionary

+ + +System Class CHARACTER

+ +Type BASE-CHAR

+ +Type STANDARD-CHAR

+ +Type EXTENDED-CHAR

+ + +Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP

+ + +Function CHARACTER

+ + +Function CHARACTERP

+ + +Function ALPHA-CHAR-P

+ + +Function ALPHANUMERICP

+ + +Function DIGIT-CHAR

+ + +Function DIGIT-CHAR-P

+ + +Function GRAPHIC-CHAR-P

+ + +Function STANDARD-CHAR-P

+ + +Function CHAR-UPCASE, CHAR-DOWNCASE

+ + +Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P

+ + +Function CHAR-CODE

+ + +Function CHAR-INT

+ + +Function CODE-CHAR

+ + +Constant Variable CHAR-CODE-LIMIT

+ + +Function CHAR-NAME

+ + +Function NAME-CHAR

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_condit.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_condit.htm new file mode 100644 index 00000000..8674fbd4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_condit.htm @@ -0,0 +1,153 @@ + + + +CLHS: Section The Conditions Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+9.2 The Conditions Dictionary

+ + +Condition Type CONDITION

+ +Condition Type WARNING

+ +Condition Type STYLE-WARNING

+ + +Condition Type SERIOUS-CONDITION

+ +Condition Type ERROR

+ +Condition Type CELL-ERROR

+ +Function CELL-ERROR-NAME

+ + +Condition Type PARSE-ERROR

+ +Condition Type STORAGE-CONDITION

+ + +Macro ASSERT

+ + +Function ERROR

+ + +Function CERROR

+ + +Macro CHECK-TYPE

+ + +Condition Type SIMPLE-ERROR

+ + +Function INVALID-METHOD-ERROR

+ + +Function METHOD-COMBINATION-ERROR

+ + +Function SIGNAL

+ + +Condition Type SIMPLE-CONDITION

+ +Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS

+ + +Function WARN

+ + +Condition Type SIMPLE-WARNING

+ + +Function INVOKE-DEBUGGER

+ + +Function BREAK

+ + +Variable *DEBUGGER-HOOK*

+ + +Variable *BREAK-ON-SIGNALS*

+ + +Macro HANDLER-BIND

+ + +Macro HANDLER-CASE

+ + +Macro IGNORE-ERRORS

+ + +Macro DEFINE-CONDITION

+ + +Function MAKE-CONDITION

+ + +System Class RESTART

+ +Function COMPUTE-RESTARTS

+ + +Function FIND-RESTART

+ + +Function INVOKE-RESTART

+ + +Function INVOKE-RESTART-INTERACTIVELY

+ + +Macro RESTART-BIND

+ + +Macro RESTART-CASE

+ + +Function RESTART-NAME

+ + +Macro WITH-CONDITION-RESTARTS

+ + +Macro WITH-SIMPLE-RESTART

+ + +Restart ABORT

+ +Restart CONTINUE

+ +Restart MUFFLE-WARNING

+ +Restart STORE-VALUE

+ + +Restart USE-VALUE

+ +Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_conses.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_conses.htm new file mode 100644 index 00000000..2496c176 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_conses.htm @@ -0,0 +1,172 @@ + + + +CLHS: Section The Conses Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+14.2 The Conses Dictionary

+

+ + +System Class LIST

+ +System Class NULL

+ +System Class CONS

+ +Type ATOM

+ + +Function CONS

+ + +Function CONSP

+ + +Function ATOM

+ + +Function RPLACA, RPLACD

+ + +Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR

+ + +Function COPY-TREE

+ + +Function SUBLIS, NSUBLIS

+ + +Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT

+ + +Function TREE-EQUAL

+ + +Function COPY-LIST

+ + +Function LIST, LIST*

+ + +Function LIST-LENGTH

+ + +Function LISTP

+ + +Function MAKE-LIST

+ + +Macro PUSH

+ + +Macro POP

+ + +Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH

+ + +Accessor NTH

+ + +Function ENDP

+ + +Function NULL

+ + +Function NCONC

+ + +Function APPEND

+ + +Function REVAPPEND, NRECONC

+ + +Function BUTLAST, NBUTLAST

+ + +Function LAST

+ + +Function LDIFF, TAILP

+ + +Function NTHCDR

+ + +Accessor REST

+ + +Function MEMBER, MEMBER-IF, MEMBER-IF-NOT

+ + +Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON

+ + +Function ACONS

+ + +Function ASSOC, ASSOC-IF, ASSOC-IF-NOT

+ + +Function COPY-ALIST

+ + +Function PAIRLIS

+ + +Function RASSOC, RASSOC-IF, RASSOC-IF-NOT

+ + +Function GET-PROPERTIES

+ + +Accessor GETF

+ + +Macro REMF

+ + +Function INTERSECTION, NINTERSECTION

+ + +Function ADJOIN

+ + +Macro PUSHNEW

+ + +Function SET-DIFFERENCE, NSET-DIFFERENCE

+ + +Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR

+ + +Function SUBSETP

+ + +Function UNION, NUNION

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_data_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_data_a.htm new file mode 100644 index 00000000..35d18da7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_data_a.htm @@ -0,0 +1,232 @@ + + + +CLHS: Section The Data and Control Flow Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+5.3 The Data and Control Flow Dictionary

+ + +Function APPLY

+ + +Macro DEFUN

+ + +Accessor FDEFINITION

+ + +Function FBOUNDP

+ + +Function FMAKUNBOUND

+ + +Special Operator FLET, LABELS, MACROLET

+ + +Function FUNCALL

+ + +Special Operator FUNCTION

+ + +Function FUNCTION-LAMBDA-EXPRESSION

+ + +Function FUNCTIONP

+ + +Function COMPILED-FUNCTION-P

+ + +Constant Variable CALL-ARGUMENTS-LIMIT

+ + +Constant Variable LAMBDA-LIST-KEYWORDS

+ + +Constant Variable LAMBDA-PARAMETERS-LIMIT

+ + +Macro DEFCONSTANT

+ + +Macro DEFPARAMETER, DEFVAR

+ + +Macro DESTRUCTURING-BIND

+ + +Special Operator LET, LET*

+ + +Special Operator PROGV

+ + +Special Form SETQ

+ + +Macro PSETQ

+ + +Special Operator BLOCK

+ + +Special Operator CATCH

+ + +Special Operator GO

+ + +Special Operator RETURN-FROM

+ + +Macro RETURN

+ + +Special Operator TAGBODY

+ + +Special Operator THROW

+ + +Special Operator UNWIND-PROTECT

+ + +Constant Variable NIL

+ + +Function NOT

+ + +Constant Variable T

+ + +Function EQ

+ + +Function EQL

+ + +Function EQUAL

+ + +Function EQUALP

+ + +Function IDENTITY

+ + +Function COMPLEMENT

+ + +Function CONSTANTLY

+ + +Function EVERY, SOME, NOTEVERY, NOTANY

+ + +Macro AND

+ + +Macro COND

+ + +Special Operator IF

+ + +Macro OR

+ + +Macro WHEN, UNLESS

+ + +Macro CASE, CCASE, ECASE

+ + +Macro TYPECASE, CTYPECASE, ETYPECASE

+ + +Macro MULTIPLE-VALUE-BIND

+ + +Special Operator MULTIPLE-VALUE-CALL

+ + +Macro MULTIPLE-VALUE-LIST

+ + +Special Operator MULTIPLE-VALUE-PROG1

+ + +Macro MULTIPLE-VALUE-SETQ

+ + +Accessor VALUES

+ + +Function VALUES-LIST

+ + +Constant Variable MULTIPLE-VALUES-LIMIT

+ + +Macro NTH-VALUE

+ + +Macro PROG, PROG*

+ + +Macro PROG1, PROG2

+ + +Special Operator PROGN

+ + +Macro DEFINE-MODIFY-MACRO

+ + +Macro DEFSETF

+ + +Macro DEFINE-SETF-EXPANDER

+ + +Function GET-SETF-EXPANSION

+ + +Macro SETF, PSETF

+ + +Macro SHIFTF

+ + +Macro ROTATEF

+ + +Condition Type CONTROL-ERROR

+ +Condition Type PROGRAM-ERROR

+ +Condition Type UNDEFINED-FUNCTION

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_enviro.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_enviro.htm new file mode 100644 index 00000000..a86eec21 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_enviro.htm @@ -0,0 +1,119 @@ + + + +CLHS: Section The Environment Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+25.2 The Environment Dictionary

+ + +Function DECODE-UNIVERSAL-TIME

+ + +function ENCODE-UNIVERSAL-TIME

+ + +Function GET-UNIVERSAL-TIME, GET-DECODED-TIME

+ + +Function SLEEP

+ + +Function APROPOS, APROPOS-LIST

+ + +Function DESCRIBE

+ + +Standard Generic Function DESCRIBE-OBJECT

+ + +Macro TRACE, UNTRACE

+ + +Macro STEP

+ + +Macro TIME

+ + +Constant Variable INTERNAL-TIME-UNITS-PER-SECOND

+ + +Function GET-INTERNAL-REAL-TIME

+ + +Function GET-INTERNAL-RUN-TIME

+ + +Function DISASSEMBLE

+

+ + +Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)

+

+ + +Function ROOM

+ + +Function ED

+ + +Function INSPECT

+ + +Function DRIBBLE

+ + +Variable -

+ + +Variable +, ++, +++

+ + +Variable *, **, ***

+ + +Variable /, //, ///

+ + +Function LISP-IMPLEMENTATION-TYPE, LISP-IMPLEMENTATION-VERSION

+ + +Function SHORT-SITE-NAME, LONG-SITE-NAME

+ + +Function MACHINE-INSTANCE

+ + +Function MACHINE-TYPE

+ + +Function MACHINE-VERSION

+ + +Function SOFTWARE-TYPE, SOFTWARE-VERSION

+ + +Function USER-HOMEDIR-PATHNAME

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_evalua.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_evalua.htm new file mode 100644 index 00000000..acda5b83 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_evalua.htm @@ -0,0 +1,118 @@ + + + +CLHS: Section The Evaluation and Compilation Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+3.8 The Evaluation and Compilation Dictionary

+ + +Symbol LAMBDA

+ + +Macro LAMBDA

+ + +Function COMPILE

+ + +Function EVAL

+ + +Special Operator EVAL-WHEN

+ + +Special Operator LOAD-TIME-VALUE

+ + +Special Operator QUOTE

+ + +Accessor COMPILER-MACRO-FUNCTION

+ + +Macro DEFINE-COMPILER-MACRO

+ + +Macro DEFMACRO

+ + +Accessor MACRO-FUNCTION

+ + +Function MACROEXPAND, MACROEXPAND-1

+ + +Macro DEFINE-SYMBOL-MACRO

+ + +Special Operator SYMBOL-MACROLET

+ + +Variable *MACROEXPAND-HOOK*

+ + +Function PROCLAIM

+ + +Macro DECLAIM

+ + +Symbol DECLARE

+ + +Declaration IGNORE, IGNORABLE

+ + +Declaration DYNAMIC-EXTENT

+ + +Declaration TYPE

+ + +Declaration INLINE, NOTINLINE

+ + +Declaration FTYPE

+ + +Declaration DECLARATION

+ + +Declaration OPTIMIZE

+ + +Declaration SPECIAL

+ + +Special Operator LOCALLY

+ + +Special Operator THE

+ + +Function SPECIAL-OPERATOR-P

+ + +Function CONSTANTP

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_filena.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_filena.htm new file mode 100644 index 00000000..4c8402eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_filena.htm @@ -0,0 +1,69 @@ + + + +CLHS: Section The Filenames Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+19.4 The Filenames Dictionary

+ + +System Class PATHNAME

+ +System Class LOGICAL-PATHNAME

+ + +Function PATHNAME

+ + +Function MAKE-PATHNAME

+ +Function PATHNAMEP

+ +Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION

+ + +Function LOAD-LOGICAL-PATHNAME-TRANSLATIONS

+ +Accessor LOGICAL-PATHNAME-TRANSLATIONS

+ +Function LOGICAL-PATHNAME

+ + +Variable *DEFAULT-PATHNAME-DEFAULTS*

+ + +Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING

+ +Function PARSE-NAMESTRING

+ + +Function WILD-PATHNAME-P

+ +Function PATHNAME-MATCH-P

+ +Function TRANSLATE-LOGICAL-PATHNAME

+ +Function TRANSLATE-PATHNAME

+ + +Function MERGE-PATHNAMES

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_files.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_files.htm new file mode 100644 index 00000000..840c5435 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_files.htm @@ -0,0 +1,56 @@ + + + +CLHS: Section The Files Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+20.2 The Files Dictionary

+ + +Function DIRECTORY

+ + +Function PROBE-FILE

+ + +Function ENSURE-DIRECTORIES-EXIST

+ + +Function TRUENAME

+ + +Function FILE-AUTHOR

+ + +Function FILE-WRITE-DATE

+ + +Function RENAME-FILE

+ + +Function DELETE-FILE

+ + +Condition Type FILE-ERROR

+ +Function FILE-ERROR-PATHNAME

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_hash_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_hash_t.htm new file mode 100644 index 00000000..3151be5a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_hash_t.htm @@ -0,0 +1,68 @@ + + + +CLHS: Section The Hash Tables Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+18.2 The Hash Tables Dictionary

+ + +System Class HASH-TABLE

+ +Function MAKE-HASH-TABLE

+ + +Function HASH-TABLE-P

+ + +Function HASH-TABLE-COUNT

+ + +Function HASH-TABLE-REHASH-SIZE

+ + +Function HASH-TABLE-REHASH-THRESHOLD

+ + +Function HASH-TABLE-SIZE

+ + +Function HASH-TABLE-TEST

+ + +Accessor GETHASH

+ + +Function REMHASH

+ + +Function MAPHASH

+ + +Macro WITH-HASH-TABLE-ITERATOR

+ + +Function CLRHASH

+ + +Function SXHASH

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_iterat.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_iterat.htm new file mode 100644 index 00000000..aa6bbf7e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_iterat.htm @@ -0,0 +1,41 @@ + + + +CLHS: Section The Iteration Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+6.2 The Iteration Dictionary

+ + +Macro DO, DO*

+ + +Macro DOTIMES

+ + +Macro DOLIST

+ + +Macro LOOP

+ +Local Macro LOOP-FINISH

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_number.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_number.htm new file mode 100644 index 00000000..cd9ecdd6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_number.htm @@ -0,0 +1,262 @@ + + + +CLHS: Section The Numbers Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+12.2 The Numbers Dictionary

+

+ + +System Class NUMBER

+ +System Class COMPLEX

+ +System Class REAL

+ +System Class FLOAT

+ +Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT

+ +System Class RATIONAL

+ +System Class RATIO

+ +System Class INTEGER

+ +Type SIGNED-BYTE

+ +Type UNSIGNED-BYTE

+ +Type Specifier MOD

+ +Type BIT

+ +Type FIXNUM

+ +Type BIGNUM

+ + +Function =, /=, <, >, <=, >=

+ + +Function MAX, MIN

+ + +Function MINUSP, PLUSP

+ + +Function ZEROP

+ + +Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND

+ + +Function SIN, COS, TAN

+ + +Function ASIN, ACOS, ATAN

+ + +Constant Variable PI

+ + +Function SINH, COSH, TANH, ASINH, ACOSH, ATANH

+ + +Function *

+ + +Function +

+ + +Function -

+ + +Function /

+ + +Function 1+, 1-

+ + +Function ABS

+ + +Function EVENP, ODDP

+ + +Function EXP, EXPT

+ + +Function GCD

+ + +Macro INCF, DECF

+ + +Function LCM

+ + +Function LOG

+ + +Function MOD, REM

+ + +Function SIGNUM

+ + +Function SQRT, ISQRT

+ + +System Class RANDOM-STATE

+ + +Function MAKE-RANDOM-STATE

+ + +Function RANDOM

+ + +Function RANDOM-STATE-P

+ + +Variable *RANDOM-STATE*

+ + +Function NUMBERP

+ + +Function CIS

+ + +Function COMPLEX

+ + +Function COMPLEXP

+ + +Function CONJUGATE

+ + +Function PHASE

+ + +Function REALPART, IMAGPART

+ + +Function UPGRADED-COMPLEX-PART-TYPE

+ + +Function REALP

+ + +Function NUMERATOR, DENOMINATOR

+ + +Function RATIONAL, RATIONALIZE

+ + +Function RATIONALP

+ + +Function ASH

+ + +Function INTEGER-LENGTH

+ + +Function INTEGERP

+ + +Function PARSE-INTEGER

+ + +Function BOOLE

+ + +Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR

+ + +Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR

+ + +Function LOGBITP

+ + +Function LOGCOUNT

+ + +Function LOGTEST

+ + +Function BYTE, BYTE-SIZE, BYTE-POSITION

+ + +Function DEPOSIT-FIELD

+ + +Function DPB

+ + +Accessor LDB

+ + +Function LDB-TEST

+ + +Accessor MASK-FIELD

+ + +Constant Variable MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM

+ + +Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT

+ + +Function FLOAT

+ + +Function FLOATP

+ + +Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT

+ + +Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON

+ + +Condition Type ARITHMETIC-ERROR

+ +Function ARITHMETIC-ERROR-OPERANDS, ARITHMETIC-ERROR-OPERATION

+ + +Condition Type DIVISION-BY-ZERO

+ +Condition Type FLOATING-POINT-INVALID-OPERATION

+ +Condition Type FLOATING-POINT-INEXACT

+ +Condition Type FLOATING-POINT-OVERFLOW

+ +Condition Type FLOATING-POINT-UNDERFLOW

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_object.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_object.htm new file mode 100644 index 00000000..7422c566 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_object.htm @@ -0,0 +1,151 @@ + + + +CLHS: Section The Objects Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+7.7 The Objects Dictionary

+

+ + +Standard Generic Function FUNCTION-KEYWORDS

+ + +Function ENSURE-GENERIC-FUNCTION

+ + +Standard Generic Function ALLOCATE-INSTANCE

+ + +Standard Generic Function REINITIALIZE-INSTANCE

+ + +Standard Generic Function SHARED-INITIALIZE

+ + +Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS

+ + +Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS

+ + +Standard Generic Function CHANGE-CLASS

+ + +Function SLOT-BOUNDP

+ + +Function SLOT-EXISTS-P

+ + +Function SLOT-MAKUNBOUND

+ + +Standard Generic Function SLOT-MISSING

+ + +Standard Generic Function SLOT-UNBOUND

+ + +Function SLOT-VALUE

+ + +Standard Generic Function METHOD-QUALIFIERS

+ + +Standard Generic Function NO-APPLICABLE-METHOD

+ + +Standard Generic Function NO-NEXT-METHOD

+ + +Standard Generic Function REMOVE-METHOD

+

+ + +Standard Generic Function MAKE-INSTANCE

+ + +Standard Generic Function MAKE-INSTANCES-OBSOLETE

+ + +Standard Generic Function MAKE-LOAD-FORM

+ + +Function MAKE-LOAD-FORM-SAVING-SLOTS

+ + +Macro WITH-ACCESSORS

+ + +Macro WITH-SLOTS

+ + +Macro DEFCLASS

+ + +Macro DEFGENERIC

+ + +Macro DEFMETHOD

+ + +Accessor FIND-CLASS

+ + +Local Function NEXT-METHOD-P

+ + +Local Macro CALL-METHOD, MAKE-METHOD

+ + +Local Function CALL-NEXT-METHOD

+ + +Standard Generic Function COMPUTE-APPLICABLE-METHODS

+ + +Macro DEFINE-METHOD-COMBINATION

+ + +Standard Generic Function FIND-METHOD

+ + +Standard Generic Function ADD-METHOD

+ + +Standard Generic Function INITIALIZE-INSTANCE

+ + +Standard Generic Function CLASS-NAME

+ + +Standard Generic Function (SETF CLASS-NAME)

+ + +Function CLASS-OF

+ + +Condition Type UNBOUND-SLOT

+ +Function UNBOUND-SLOT-INSTANCE

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_packag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_packag.htm new file mode 100644 index 00000000..dd81103a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_packag.htm @@ -0,0 +1,116 @@ + + + +CLHS: Section The Packages Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+11.2 The Packages Dictionary

+ + +System Class PACKAGE

+ + +Function EXPORT

+ + +Function FIND-SYMBOL

+ + +Function FIND-PACKAGE

+ + +Function FIND-ALL-SYMBOLS

+ + +Function IMPORT

+ + +Function LIST-ALL-PACKAGES

+ + +Function RENAME-PACKAGE

+ + +Function SHADOW

+ + +Function SHADOWING-IMPORT

+ + +Function DELETE-PACKAGE

+ + +Function MAKE-PACKAGE

+ + +Macro WITH-PACKAGE-ITERATOR

+ + +Function UNEXPORT

+ + +Function UNINTERN

+ + +Macro IN-PACKAGE

+ + +Function UNUSE-PACKAGE

+ + +Function USE-PACKAGE

+ + +Macro DEFPACKAGE

+ + +Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS

+ + +Function INTERN

+ + +Function PACKAGE-NAME

+ + +Function PACKAGE-NICKNAMES

+ + +Function PACKAGE-SHADOWING-SYMBOLS

+ + +Function PACKAGE-USE-LIST

+ + +Function PACKAGE-USED-BY-LIST

+ + +Function PACKAGEP

+ + +Variable *PACKAGE*

+ + +Condition Type PACKAGE-ERROR

+ +Function PACKAGE-ERROR-PACKAGE

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_printe.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_printe.htm new file mode 100644 index 00000000..616d16c6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_printe.htm @@ -0,0 +1,121 @@ + + + +CLHS: Section The Printer Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+22.4 The Printer Dictionary

+

+

+ + +Function COPY-PPRINT-DISPATCH

+ + +Macro FORMATTER

+ + +Function PPRINT-DISPATCH

+ + +Local Macro PPRINT-EXIT-IF-LIST-EXHAUSTED

+ + +Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR

+ + +Function PPRINT-INDENT

+ + +Macro PPRINT-LOGICAL-BLOCK

+ + +Function PPRINT-NEWLINE

+ + +Local Macro PPRINT-POP

+ + +Function PPRINT-TAB

+ + +Standard Generic Function PRINT-OBJECT

+ + +Macro PRINT-UNREADABLE-OBJECT

+ + +Function SET-PPRINT-DISPATCH

+ + +Function WRITE, PRIN1, PRINT, PPRINT, PRINC

+ + +Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING

+ + +Variable *PRINT-ARRAY*

+ + +Variable *PRINT-BASE*, *PRINT-RADIX*

+ + +Variable *PRINT-CASE*

+ + +Variable *PRINT-CIRCLE*

+ + +Variable *PRINT-ESCAPE*

+ + +Variable *PRINT-GENSYM*

+ + +Variable *PRINT-LEVEL*, *PRINT-LENGTH*

+ + +Variable *PRINT-LINES*

+ + +Variable *PRINT-MISER-WIDTH*

+ + +Variable *PRINT-PPRINT-DISPATCH*

+ + +Variable *PRINT-PRETTY*

+ + +Variable *PRINT-READABLY*

+ + +Variable *PRINT-RIGHT-MARGIN*

+ + +Condition Type PRINT-NOT-READABLE

+ +Function PRINT-NOT-READABLE-OBJECT

+ + +Function FORMAT

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_reader.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_reader.htm new file mode 100644 index 00000000..b9f432c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_reader.htm @@ -0,0 +1,81 @@ + + + +CLHS: Section The Reader Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+23.2 The Reader Dictionary

+ + +System Class READTABLE

+ + +Function COPY-READTABLE

+ + +Function MAKE-DISPATCH-MACRO-CHARACTER

+ + +Function READ, READ-PRESERVING-WHITESPACE

+ + +Function READ-DELIMITED-LIST

+ + +Function READ-FROM-STRING

+ + +Accessor READTABLE-CASE

+ + +Function READTABLEP

+ + +Function SET-DISPATCH-MACRO-CHARACTER, GET-DISPATCH-MACRO-CHARACTER

+ + +Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER

+ + +Function SET-SYNTAX-FROM-CHAR

+ + +Macro WITH-STANDARD-IO-SYNTAX

+ + +Variable *READ-BASE*

+ + +Variable *READ-DEFAULT-FLOAT-FORMAT*

+ + +Variable *READ-EVAL*

+ + +Variable *READ-SUPPRESS*

+ + +Variable *READTABLE*

+ + +Condition Type READER-ERROR

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_sequen.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_sequen.htm new file mode 100644 index 00000000..473c5c84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_sequen.htm @@ -0,0 +1,96 @@ + + + +CLHS: Section The Sequences Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+17.3 The Sequences Dictionary

+ + +System Class SEQUENCE

+ + +Function COPY-SEQ

+ + +Accessor ELT

+ + +Function FILL

+ + +Function MAKE-SEQUENCE

+ + +Accessor SUBSEQ

+ + +Function MAP

+ + +Function MAP-INTO

+ + +Function REDUCE

+ + +Function COUNT, COUNT-IF, COUNT-IF-NOT

+ + +Function LENGTH

+ + +Function REVERSE, NREVERSE

+ + +Function SORT, STABLE-SORT

+ + +Function FIND, FIND-IF, FIND-IF-NOT

+ + +Function POSITION, POSITION-IF, POSITION-IF-NOT

+ + +Function SEARCH

+ + +Function MISMATCH

+ + +Function REPLACE

+ + +Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT

+ + +Function CONCATENATE

+ + +Function MERGE

+ + +Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT

+ + +Function REMOVE-DUPLICATES, DELETE-DUPLICATES

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_stream.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_stream.htm new file mode 100644 index 00000000..7cb4d4a4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_stream.htm @@ -0,0 +1,193 @@ + + + +CLHS: Section The Streams Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+21.2 The Streams Dictionary

+

+ + +System Class STREAM

+ +System Class BROADCAST-STREAM

+ +System Class CONCATENATED-STREAM

+ +System Class ECHO-STREAM

+ +System Class FILE-STREAM

+ +System Class STRING-STREAM

+ +System Class SYNONYM-STREAM

+ +System Class TWO-WAY-STREAM

+ + +Function INPUT-STREAM-P, OUTPUT-STREAM-P

+ + +Function INTERACTIVE-STREAM-P

+ + +Function OPEN-STREAM-P

+ + +Function STREAM-ELEMENT-TYPE

+ + +Function STREAMP

+ + +Function READ-BYTE

+ + +Function WRITE-BYTE

+ + +Function PEEK-CHAR

+ + +Function READ-CHAR

+ + +Function READ-CHAR-NO-HANG

+ + +Function TERPRI, FRESH-LINE

+ + +Function UNREAD-CHAR

+ + +Function WRITE-CHAR

+ + +Function READ-LINE

+ + +Function WRITE-STRING, WRITE-LINE

+

+ + +Function READ-SEQUENCE

+ + +Function WRITE-SEQUENCE

+

+ + +Function FILE-LENGTH

+ + +Function FILE-POSITION

+ + +Function FILE-STRING-LENGTH

+ + +Function OPEN

+ + +Function STREAM-EXTERNAL-FORMAT

+ + +macro WITH-OPEN-FILE

+ + +Function CLOSE

+ + +Macro WITH-OPEN-STREAM

+ + +Function LISTEN

+ + +Function CLEAR-INPUT

+ + +Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT

+ + +Function Y-OR-N-P, YES-OR-NO-P

+ + +Function MAKE-SYNONYM-STREAM

+ + +Function SYNONYM-STREAM-SYMBOL

+ + +Function BROADCAST-STREAM-STREAMS

+ + +Function MAKE-BROADCAST-STREAM

+ + +Function MAKE-TWO-WAY-STREAM

+ + +Function TWO-WAY-STREAM-INPUT-STREAM, TWO-WAY-STREAM-OUTPUT-STREAM

+ + +Function ECHO-STREAM-INPUT-STREAM, ECHO-STREAM-OUTPUT-STREAM

+ + +Function MAKE-ECHO-STREAM

+ + +Function CONCATENATED-STREAM-STREAMS

+ + +Function MAKE-CONCATENATED-STREAM

+ + +Function GET-OUTPUT-STREAM-STRING

+ + +Function MAKE-STRING-INPUT-STREAM

+ + +Function MAKE-STRING-OUTPUT-STREAM

+ + +Macro WITH-INPUT-FROM-STRING

+ + +Macro WITH-OUTPUT-TO-STRING

+ + +Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*

+ + +Variable *TERMINAL-IO*

+ + +Condition Type STREAM-ERROR

+ +Function STREAM-ERROR-STREAM

+ + +Condition Type END-OF-FILE

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_string.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_string.htm new file mode 100644 index 00000000..9f94e780 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_string.htm @@ -0,0 +1,61 @@ + + + +CLHS: Section The Strings Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+16.2 The Strings Dictionary

+ + +System Class STRING

+ +Type BASE-STRING

+ +Type SIMPLE-STRING

+ +Type SIMPLE-BASE-STRING

+ + +Function SIMPLE-STRING-P

+ + +Accessor CHAR, SCHAR

+ + +Function STRING

+ + +Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE

+ + +Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM

+ + +Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP

+ + +Function STRINGP

+ + +Function MAKE-STRING

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_struct.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_struct.htm new file mode 100644 index 00000000..89d405aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_struct.htm @@ -0,0 +1,33 @@ + + + +CLHS: Section The Structures Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+8.1 The Structures Dictionary

+ + +Macro DEFSTRUCT

+ + +Function COPY-STRUCTURE

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_symbol.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_symbol.htm new file mode 100644 index 00000000..dac1ca68 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_symbol.htm @@ -0,0 +1,85 @@ + + + +CLHS: Section The Symbols Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+10.2 The Symbols Dictionary

+ + +System Class SYMBOL

+ +Type KEYWORD

+ +Function SYMBOLP

+ + +Function KEYWORDP

+ + +Function MAKE-SYMBOL

+ + +Function COPY-SYMBOL

+ + +Function GENSYM

+ + +Variable *GENSYM-COUNTER*

+ + +Function GENTEMP

+ + +Accessor SYMBOL-FUNCTION

+ + +Function SYMBOL-NAME

+ + +Function SYMBOL-PACKAGE

+ + +Accessor SYMBOL-PLIST

+ + +Accessor SYMBOL-VALUE

+ + +Accessor GET

+ + +Function REMPROP

+ + +Function BOUNDP

+ + +Function MAKUNBOUND

+ + +Function SET

+ + +Condition Type UNBOUND-VARIABLE

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_system.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_system.htm new file mode 100644 index 00000000..02a0f1c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_system.htm @@ -0,0 +1,60 @@ + + + +CLHS: Section The System Construction Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+24.2 The System Construction Dictionary

+ + +Function COMPILE-FILE

+ + +Function COMPILE-FILE-PATHNAME

+ + +Function LOAD

+ + +Macro WITH-COMPILATION-UNIT

+ + +Variable *FEATURES*

+ + +Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*

+ + +Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*

+ + +Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*

+ + +Variable *LOAD-PRINT*, *LOAD-VERBOSE*

+ + +Variable *MODULES*

+ + +Function PROVIDE, REQUIRE

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_types_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_types_.htm new file mode 100644 index 00000000..2d4fe223 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/c_types_.htm @@ -0,0 +1,98 @@ + + + +CLHS: Section The Types and Classes Dictionary + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

+4.4 The Types and Classes Dictionary

+ + +Type NIL

+ +Type BOOLEAN

+ + +System Class FUNCTION

+ +Type COMPILED-FUNCTION

+ +System Class GENERIC-FUNCTION

+ +System Class STANDARD-GENERIC-FUNCTION

+ + +System Class CLASS

+ +System Class BUILT-IN-CLASS

+ +System Class STRUCTURE-CLASS

+ +System Class STANDARD-CLASS

+ +System Class METHOD

+ +System Class STANDARD-METHOD

+ +Class STRUCTURE-OBJECT

+ +Class STANDARD-OBJECT

+ +System Class METHOD-COMBINATION

+ +System Class T

+ +Type Specifier SATISFIES

+ +Type Specifier MEMBER

+ +Type Specifier NOT

+ +Type Specifier AND

+ +Type Specifier OR

+ +Type Specifier VALUES

+ +Type Specifier EQL

+ +Function COERCE

+ + +Macro DEFTYPE

+ + +Function SUBTYPEP

+ + +Function TYPE-OF

+ + +Function TYPEP

+ + +Condition Type TYPE-ERROR

+ +Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE

+ + +Condition Type SIMPLE-TYPE-ERROR

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_declar.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_declar.htm new file mode 100644 index 00000000..36b8b2cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_declar.htm @@ -0,0 +1,55 @@ + + + +CLHS: Declaration DECLARATION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration DECLARATION

+

Syntax:

+

+(declaration name*)

+

Arguments:

+

+name---a symbol.

+

Binding Types Affected: None. +

+

Valid Context:

+

+proclamation only

+

Description:

+

+Advises the compiler that each name is a valid but potentially non-standard declaration name. The purpose of this is to tell one compiler not to issue warnings for declarations meant for another compiler or other program processor.

+

Examples:

+

+

+ (declaim (declaration author target-language target-machine))
+ (declaim (target-language ada))
+ (declaim (target-machine IBM-650))
+ (defun strangep (x)
+   (declare (author "Harry Tweeker"))
+   (member x '(strange weird odd peculiar)))
+
+

+

See Also:

+

+declaim, proclaim

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_dynami.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_dynami.htm new file mode 100644 index 00000000..c5781ca3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_dynami.htm @@ -0,0 +1,164 @@ + + + +CLHS: Declaration DYNAMIC-EXTENT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration DYNAMIC-EXTENT

+

Syntax:

+

+(dynamic-extent [[var* | (function fn)*]])

+

Arguments:

+

+var---a variable name.

+fn---a function name.

+

Valid Context:

+

+declaration

+

Binding Types Affected:

+

+variable, function

+

Description:

+

+

+In some containing form, F, this declaration asserts for each vari (which need not be bound by F), and for each value vij that vari takes on, and for each object xijk that is an otherwise inaccessible part of vij at any time when vij becomes the value of vari, that just after the execution of F terminates, xijk is either inaccessible (if F established a binding for vari) or still an otherwise inaccessible part of the current value of vari (if F did not establish a binding for vari). The same relation holds for each fni, except that the bindings are in the function namespace.

+The compiler is permitted to use this information in any way that is appropriate to the implementation and that does not conflict with the semantics of Common Lisp.

+dynamic-extent declarations can be free declarations or bound declarations.

+ The vars and fns named in a dynamic-extent declaration must not refer to symbol macro or macro bindings.

+

Examples:

+

+Since stack allocation of the initial value entails knowing at the object's creation time that the object can be stack-allocated, it is not generally useful to make a dynamic-extent declaration for variables which have no lexically apparent initial value. For example, it is probably useful to write:

+

+ (defun f ()
+   (let ((x (list 1 2 3)))
+     (declare (dynamic-extent x))
+         ...))
+
+

+This would permit those compilers that wish to do so to stack allocate the list held by the local variable x. It is permissible, but in practice probably not as useful, to write:

+

+ (defun g (x) (declare (dynamic-extent x)) ...)
+ (defun f () (g (list 1 2 3)))
+
+

+Most compilers would probably not stack allocate the argument to g in f because it would be a modularity violation for the compiler to assume facts about g from within f. Only an implementation that was willing to be responsible for recompiling f if the definition of g changed incompatibly could legitimately stack allocate the list argument to g in f.

+Here is another example:

+

+ (declaim (inline g))
+ (defun g (x) (declare (dynamic-extent x)) ...)
+ (defun f () (g (list 1 2 3)))
+ 
+ (defun f ()
+   (flet ((g (x) (declare (dynamic-extent x)) ...))
+     (g (list 1 2 3))))
+ 
+
+ In the previous example, some compilers might determine that optimization was possible and others might not.

+A variant of this is the so-called ``stack allocated rest list'' that can be achieved (in implementations supporting the optimization) by:

+

+ (defun f (&rest x)
+   (declare (dynamic-extent x))
+   ...)
+
+

+Note that although the initial value of x is not explicit, the f function is responsible for assembling the list x from the passed arguments, so the f function can be optimized by the compiler to construct a stack-allocated list instead of a heap-allocated list in implementations that support such.

+In the following example,

+

+ (let ((x (list 'a1 'b1 'c1))
+       (y (cons 'a2 (cons 'b2 (cons 'c2 nil)))))
+   (declare (dynamic-extent x y))
+   ...)
+
+ The otherwise inaccessible parts of x are three conses, and the otherwise inaccessible parts of y are three other conses. None of the symbols a1, b1, c1, a2, b2, c2, or nil is an otherwise inaccessible part of x or y because each is interned and hence accessible by the package (or packages) in which it is interned. However, if a freshly allocated uninterned symbol had been used, it would have been an otherwise inaccessible part of the list which contained it.

+

+;; In this example, the implementation is permitted to stack allocate
+;; the list that is bound to X.
+ (let ((x (list 1 2 3)))
+   (declare (dynamic-extent x))
+   (print x)
+   :done)
+>>  (1 2 3)
+=>  :DONE
+ 
+;; In this example, the list to be bound to L can be stack-allocated.
+ (defun zap (x y z)
+   (do ((l (list x y z) (cdr l)))
+       ((null l))
+     (declare (dynamic-extent l))
+     (prin1 (car l)))) =>  ZAP
+ (zap 1 2 3)
+>>  123
+=>  NIL
+
+;; Some implementations might open-code LIST-ALL-PACKAGES in a way
+;; that permits using stack allocation of the list to be bound to L.
+ (do ((l (list-all-packages) (cdr l)))
+     ((null l))
+   (declare (dynamic-extent l))
+   (let ((name (package-name (car l))))
+     (when (string-search "COMMON-LISP" name) (print name))))
+>>  "COMMON-LISP"
+>>  "COMMON-LISP-USER"
+=>  NIL
+
+;; Some implementations might have the ability to stack allocate 
+;; rest lists.  A declaration such as the following should be a cue
+;; to such implementations that stack-allocation of the rest list
+;; would be desirable.
+ (defun add (&rest x)
+   (declare (dynamic-extent x))
+   (apply #'+ x)) =>  ADD
+ (add 1 2 3) =>  6
+
+ (defun zap (n m)
+   ;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
+   ;; It may be slow, but with a good compiler at least it
+   ;; doesn't waste much heap storage.  :-}
+   (let ((a (make-array n)))
+     (declare (dynamic-extent a))
+     (dotimes (i n) 
+       (declare (dynamic-extent i))
+       (setf (aref a i) (random (+ i 1))))
+     (aref a m))) =>  ZAP
+ (< (zap 5 3) 3) =>  true
+
+

+The following are in error, since the value of x is used outside of its extent:

+

+ (length (list (let ((x (list 1 2 3)))  ; Invalid
+                (declare (dynamic-extent x))
+                x)))
+
+ (progn (let ((x (list 1 2 3)))  ; Invalid
+          (declare (dynamic-extent x))
+          x)
+        nil)
+
+

+

See Also:

+

+declare

+

Notes:

+

+The most common optimization is to stack allocate the initial value of the objects named by the vars.

+It is permissible for an implementation to simply ignore this declaration.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ftype.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ftype.htm new file mode 100644 index 00000000..f2fd9174 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ftype.htm @@ -0,0 +1,54 @@ + + + +CLHS: Declaration FTYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration FTYPE

+

Syntax:

+

+ (ftype type function-name*)

+

Arguments:

+

+function-name---a function name.

+type---a type specifier.

+

Valid Context:

+

+declaration or proclamation

+

Binding Types Affected:

+

+function

+

Description:

+

+Specifies that the functions named by function-names are of the functional type type. For example:

+

+ (declare (ftype (function (integer list) t) ith)
+          (ftype (function (number) float) sine cosine))
+
+ If one of the functions mentioned has a lexically apparent local definition (as made by flet or labels), then the declaration applies to that local definition and not to the global function definition. ftype declarations never apply to variable bindings (see type).

+ The lexically apparent bindings of function-names must not be macro definitions. (This is because ftype declares the functional definition of each function name to be of a particular subtype of function, and macros do not denote functions.)

+ftype declarations can be free declarations or bound declarations. ftype declarations of functions that appear before the body of a flet or labels form that defines that function are bound declarations. Such declarations in other contexts are free declarations.

+

+

See Also:

+

+declare, declaim, proclaim

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ignore.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ignore.htm new file mode 100644 index 00000000..6471976d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_ignore.htm @@ -0,0 +1,56 @@ + + + +CLHS: Declaration IGNORE, IGNORABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration IGNORE, IGNORABLE

+

+

Syntax:

+

+(ignore {var | (function fn)}*)

+(ignorable {var | (function fn)}*)

+

Arguments:

+

+var---a variable name.

+fn---a function name.

+

Valid Context:

+

+declaration

+

Binding Types Affected:

+

+variable, function

+

Description:

+

+ The ignore and ignorable declarations refer to for-value references to variable bindings for the vars and to function bindings for the fns.

+An ignore declaration specifies that for-value references to the indicated bindings will not occur within the scope of the declaration. Within the scope of such a declaration, it is desirable for a compiler to issue a warning about the presence of either a for-value reference to any var or fn, or a special declaration for any var.

+An ignorable declaration specifies that for-value references to the indicated bindings might or might not occur within the scope of the declaration. Within the scope of such a declaration, it is not desirable for a compiler to issue a warning about the presence or absence of either a for-value reference to any var or fn, or a special declaration for any var.

+When not within the scope of a ignore or ignorable declaration, it is desirable for a compiler to issue a warning about any var for which there is neither a for-value reference nor a special declaration, or about any fn for which there is no for-value reference.

+Any warning about a ``used'' or ``unused'' binding must be of type style-warning, and may not affect program semantics.

+

+The stream variables established by with-open-file, with-open-stream, with-input-from-string, and with-output-to-string, and all iteration variables are, by definition, always ``used''. Using (declare (ignore v)), for such a variable v has unspecified consequences.

+

+

+

See Also:

+

+declare

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_inline.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_inline.htm new file mode 100644 index 00000000..412f68bc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_inline.htm @@ -0,0 +1,83 @@ + + + +CLHS: Declaration INLINE, NOTINLINE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration INLINE, NOTINLINE

+

Syntax:

+

+(inline function-name*)

+(notinline function-name*)

+

Arguments:

+

+function-name---a function name.

+

Valid Context:

+

+declaration or proclamation

+

Binding Types Affected:

+

+function

+

Description:

+

+ inline specifies that it is desirable for the compiler to produce inline calls to the functions named by function-names; that is, the code for a specified function-name should be integrated into the calling routine, appearing ``in line'' in place of a procedure call. A compiler is free to ignore this declaration. inline declarations never apply to variable bindings.

+If one of the functions mentioned has a lexically apparent local definition (as made by flet or labels), then the declaration applies to that local definition and not to the global function definition.

+ While no conforming implementation is required to perform inline expansion of user-defined functions, those implementations that do attempt to recognize the following paradigm:

+To define a function f that is not inline by default but for which (declare (inline f)) will make f be locally inlined, the proper definition sequence is:

+

+ (declaim (inline f))
+ (defun f ...)
+ (declaim (notinline f))
+
+

+The inline proclamation preceding the defun form ensures that the compiler has the opportunity save the information necessary for inline expansion, and the notinline proclamation following the defun form prevents f from being expanded inline everywhere.

+ notinline specifies that it is undesirable to compile the functions named by function-names in-line. A compiler is not free to ignore this declaration; calls to the specified functions must be implemented as out-of-line subroutine calls.

+If one of the functions mentioned has a lexically apparent local definition (as made by flet or labels), then the declaration applies to that local definition and not to the global function definition.

+ In the presence of a compiler macro definition for function-name, a notinline declaration prevents that compiler macro from being used. An inline declaration may be used to encourage use of compiler macro definitions. inline and notinline declarations otherwise have no effect when the lexically visible definition of function-name is a macro definition.

+inline and notinline declarations can be free declarations or bound declarations. inline and notinline declarations of functions that appear before the body of a flet or labels form that defines that function are bound declarations. Such declarations in other contexts are free declarations.

+

Examples:

+

+

+ ;; The globally defined function DISPATCH should be open-coded,
+ ;; if the implementation supports inlining, unless a NOTINLINE 
+ ;; declaration overrides this effect.
+ (declaim (inline dispatch))
+ (defun dispatch (x) (funcall (get (car x) 'dispatch) x))
+ ;; Here is an example where inlining would be encouraged.
+ (defun top-level-1 () (dispatch (read-command)))
+ ;; Here is an example where inlining would be prohibited.
+ (defun top-level-2 ()
+   (declare (notinline dispatch))
+   (dispatch (read-command)))
+ ;; Here is an example where inlining would be prohibited.
+ (declaim (notinline dispatch))
+ (defun top-level-3 () (dispatch (read-command)))
+ ;; Here is an example where inlining would be encouraged.
+ (defun top-level-4 () 
+   (declare (inline dispatch))
+   (dispatch (read-command)))
+
+

+

See Also:

+

+declare, declaim, proclaim

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_optimi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_optimi.htm new file mode 100644 index 00000000..a179f41e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_optimi.htm @@ -0,0 +1,77 @@ + + + +CLHS: Declaration OPTIMIZE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration OPTIMIZE

+

Syntax:

+

+(optimize {quality | (quality value)}*)

+

Arguments:

+

+quality---an optimize quality.

+value---one of the integers 0, 1, 2, or 3.

+

Valid Context:

+

+declaration or proclamation

+

Binding Types Affected: None. +

+

Description:

+

+Advises the compiler that each quality should be given attention according to the specified corresponding value. Each quality must be a symbol naming an optimize quality; the names and meanings of the standard optimize qualities are shown in the next figure.

+ 

+Name               Meaning                            
+compilation-speed  speed of the compilation process   
+debug              ease of debugging                  
+safety             run-time error checking            
+space              both code size and run-time space  
+speed              speed of the object code           
+
+

Figure 3-25. Optimize qualities

+There may be other, implementation-defined optimize qualities.

+A value 0 means that the corresponding quality is totally unimportant, and 3 that the quality is extremely important; 1 and 2 are intermediate values, with 1 the neutral value. (quality 3) can be abbreviated to quality.

+Note that code which has the optimization (safety 3), or just safety, is called safe code.

+The consequences are unspecified if a quality appears more than once with different values.

+

Examples:

+

+

+ (defun often-used-subroutine (x y)
+   (declare (optimize (safety 2)))
+   (error-check x y)
+   (hairy-setup x)
+   (do ((i 0 (+ i 1))
+        (z x (cdr z)))
+       ((null z))
+     ;; This inner loop really needs to burn.
+     (declare (optimize speed))
+     (declare (fixnum i))
+     ))
+
+

+

See Also:

+

+declare, declaim, proclaim, Section 3.3.4 (Declaration Scope)

+

Notes:

+

+An optimize declaration never applies to either a variable or a function binding. An optimize declaration can only be a free declaration. For more information, see Section 3.3.4 (Declaration Scope).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_specia.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_specia.htm new file mode 100644 index 00000000..85e5cbf5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_specia.htm @@ -0,0 +1,132 @@ + + + +CLHS: Declaration SPECIAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration SPECIAL

+

Syntax:

+

+(special var*)

+

Arguments:

+

+var---a symbol.

+

Valid Context:

+

+declaration or proclamation

+

Binding Types Affected:

+

+variable

+

Description:

+

+Specifies that all of the vars named are dynamic. This specifier affects variable bindings and affects references. All variable bindings affected are made to be dynamic bindings, and affected variable references refer to the current dynamic binding. For example:

+

+ (defun hack (thing *mod*)    ;The binding of the parameter
+   (declare (special *mod*))  ; *mod* is visible to hack1,
+   (hack1 (car thing)))       ; but not that of thing.
+ (defun hack1 (arg)
+   (declare (special *mod*))  ;Declare references to *mod*
+                              ;within hack1 to be special.
+   (if (atom arg) *mod*
+       (cons (hack1 (car arg)) (hack1 (cdr arg)))))
+
+

+A special declaration does not affect inner bindings of a var; the inner bindings implicitly shadow a special declaration and must be explicitly re-declared to be special. special declarations never apply to function bindings.

+special declarations can be either bound declarations, affecting both a binding and references, or free declarations, affecting only references, depending on whether the declaration is attached to a variable binding.

+When used in a proclamation, a special declaration specifier applies to all bindings as well as to all references of the mentioned variables. For example, after

+

+ (declaim (special x))
+
+

+then in a function definition such as

+

+ (defun example (x) ...)
+
+

+the parameter x is bound as a dynamic variable rather than as a lexical variable.

+

Examples:

+

+

+(defun declare-eg (y)                 ;this y is special
+ (declare (special y))
+ (let ((y t))                         ;this y is lexical
+      (list y
+            (locally (declare (special y)) y)))) ;this y refers to the
+                                                 ;special binding of y
+=>  DECLARE-EG 
+ (declare-eg nil) =>  (T NIL) 
+
+

+

+(setf (symbol-value 'x) 6)
+(defun foo (x)                         ;a lexical binding of x
+  (print x)
+  (let ((x (1+ x)))                    ;a special binding of x
+    (declare (special x))              ;and a lexical reference
+    (bar))
+  (1+ x))
+(defun bar () 
+  (print (locally (declare (special x))
+           x)))
+(foo 10) 
+>>  10
+>>  11
+=>  11
+
+

+

+(setf (symbol-value 'x) 6)
+(defun bar (x y)            ;[1] 1st occurrence of x
+  (let ((old-x x)           ;[2] 2nd occurrence of x -- same as 1st occurrence
+        (x y))              ;[3] 3rd occurrence of x
+    (declare (special x))
+    (list old-x x)))
+(bar 'first 'second) =>  (FIRST SECOND)
+
+

+

+ (defun few (x &optional (y *foo*))
+   (declare (special *foo*))
+   ...)
+
+ The reference to *foo* in the first line of this example is not special even though there is a special declaration in the second line.

+

+ (declaim (special prosp)) =>  implementation-dependent
+ (setq prosp 1 reg 1) =>  1
+ (let ((prosp 2) (reg 2))         ;the binding of prosp is special
+    (set 'prosp 3) (set 'reg 3)   ;due to the preceding proclamation,
+    (list prosp reg))             ;whereas the variable reg is lexical
+=>  (3 2)
+ (list prosp reg) =>  (1 3)
+
+ (declaim (special x))          ;x is always special.
+ (defun example (x y)                                 
+   (declare (special y))
+   (let ((y 3) (x (* x 2)))
+     (print (+ y (locally (declare (special y)) y)))
+     (let ((y 4)) (declare (special y)) (foo x)))) =>  EXAMPLE
+
+ In the contorted code above, the outermost and innermost bindings of y are dynamic, but the middle binding is lexical. The two arguments to + are different, one being the value, which is 3, of the lexical variable y, and the other being the value of the dynamic variable named y (a binding of which happens, coincidentally, to lexically surround it at an outer level). All the bindings of x and references to x are dynamic, however, because of the proclamation that x is always special.

+

See Also:

+

+defparameter, defvar

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_type.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_type.htm new file mode 100644 index 00000000..f5861099 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/d_type.htm @@ -0,0 +1,146 @@ + + + +CLHS: Declaration TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Declaration TYPE

+

Syntax:

+

+(type typespec var*)

+(typespec var*)

+

Arguments:

+

+typespec---a type specifier.

+var---a variable name.

+

Valid Context:

+

+declaration or proclamation

+

Binding Types Affected:

+

+variable

+

Description:

+

+Affects only variable bindings and specifies that the vars take on values only of the specified typespec. In particular, values assigned to the variables by setq, as well as the initial values of the vars must be of the specified typespec. type declarations never apply to function bindings (see ftype).

+ A type declaration of a symbol defined by symbol-macrolet is equivalent to wrapping a the expression around the expansion of that symbol, although the symbol's macro expansion is not actually affected.

+

+The meaning of a type declaration is equivalent to changing each reference to a variable (var) within the scope of the declaration to (the typespec var), changing each expression assigned to the variable (new-value) within the scope of the declaration to (the typespec new-value), and executing (the typespec var) at the moment the scope of the declaration is entered.

+A type declaration is valid in all declarations. The interpretation of a type declaration is as follows:

1. During the execution of any reference to the declared variable within the scope of the declaration, the consequences are undefined if the value of the declared variable is not of the declared type.

+
2. During the execution of any setq of the declared variable within the scope of the declaration, the consequences are undefined if the newly assigned value of the declared variable is not of the declared type.

+
3. At the moment the scope of the declaration is entered, the consequences are undefined if the value of the declared variable is not of the declared type.

+A type declaration affects only variable references within its scope.

+If nested type declarations refer to the same variable, then the value of the variable must be a member of the intersection of the declared types.

+ If there is a local type declaration for a dynamic variable, and there is also a global type proclamation for that same variable, then the value of the variable within the scope of the local declaration must be a member of the intersection of the two declared types.

+type declarations can be free declarations or bound declarations.

+ A symbol cannot be both the name of a type and the name of a declaration. Defining a symbol as the name of a class, structure, condition, or type, when the symbol has been declared as a declaration name, or vice versa, signals an error.

+ Within the lexical scope of an array type declaration, all references to array elements are assumed to satisfy the expressed array element type (as opposed to the upgraded array element type). A compiler can treat the code within the scope of the array type declaration as if each access of an array element were surrounded by an appropriate the form.

+

Examples:

+

+

+ (defun f (x y)
+   (declare (type fixnum x y))
+   (let ((z (+ x y)))
+     (declare (type fixnum z))
+     z)) =>  F
+ (f 1 2) =>  3
+ ;; The previous definition of F is equivalent to
+ (defun f (x y)
+   ;; This declaration is a shorthand form of the TYPE declaration
+   (declare (fixnum x y))
+   ;; To declare the type of a return value, it's not necessary to
+   ;; create a named variable.  A THE special form can be used instead.
+   (the fixnum (+ x y))) =>  F
+ (f 1 2) =>  3
+
+

+

+

+ (defvar *one-array* (make-array 10 :element-type '(signed-byte 5)))
+ (defvar *another-array* (make-array 10 :element-type '(signed-byte 8)))
+  
+ (defun frob (an-array)
+   (declare (type (array (signed-byte 5) 1) an-array))
+   (setf (aref an-array 1) 31)
+   (setf (aref an-array 2) 127)
+   (setf (aref an-array 3) (* 2 (aref an-array 3)))
+   (let ((foo 0))
+     (declare (type (signed-byte 5) foo))
+     (setf foo (aref an-array 0))))
+  
+ (frob *one-array*)
+ (frob *another-array*)
+
+

+

+The above definition of frob is equivalent to:

+

+ (defun frob (an-array)
+   (setf (the (signed-byte 5) (aref an-array 1)) 31)
+   (setf (the (signed-byte 5) (aref an-array 2)) 127)
+   (setf (the (signed-byte 5) (aref an-array 3))
+         (* 2 (the (signed-byte 5) (aref an-array 3))))
+   (let ((foo 0))
+     (declare (type (signed-byte 5) foo))
+     (setf foo (the (signed-byte 5) (aref an-array 0)))))
+
+

+Given an implementation in which fixnums are 29 bits but fixnum arrays are upgraded to signed 32-bit arrays, the following could be compiled with all fixnum arithmetic:

+

+ (defun bump-counters (counters)
+   (declare (type (array fixnum *) bump-counters))
+   (dotimes (i (length counters))
+     (incf (aref counters i))))
+
+

+

See Also:

+

+declare, declaim, proclaim

+

Notes:

+

+(typespec var*) is an abbreviation for (type typespec var*).

+A type declaration for the arguments to a function does not necessarily imply anything about the type of the result. The following function is not permitted to be compiled using implementation-dependent fixnum-only arithmetic:

+

+ (defun f (x y) (declare (fixnum x y)) (+ x y))
+
+

+To see why, consider (f most-positive-fixnum 1). Common Lisp defines that F must return a bignum here, rather than signal an error or produce a mathematically incorrect result. If you have special knowledge such ``fixnum overflow'' cases will not come up, you can declare the result value to be in the fixnum range, enabling some compilers to use more efficient arithmetic:

+

+ (defun f (x y)
+   (declare (fixnum x y))
+   (the fixnum (+ x y)))
+
+

+Note, however, that in the three-argument case, because of the possibility of an implicit intermediate value growing too large, the following will not cause implementation-dependent fixnum-only arithmetic to be used:

+

+ (defun f (x y)
+   (declare (fixnum x y z))
+   (the fixnum (+ x y z)))
+
+

+To see why, consider (f most-positive-fixnum 1 -1). Although the arguments and the result are all fixnums, an intermediate value is not a fixnum. If it is important that implementation-dependent fixnum-only arithmetic be selected in implementations that provide it, consider writing something like this instead:

+

+ (defun f (x y)
+   (declare (fixnum x y z))
+   (the fixnum (+ (the fixnum (+ x y)) z)))
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_arithm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_arithm.htm new file mode 100644 index 00000000..55b0aefb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_arithm.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type ARITHMETIC-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type ARITHMETIC-ERROR

+

Class Precedence List:

+ arithmetic-error, error, serious-condition, condition, t

+

Description:

+

+The type arithmetic-error consists of error conditions that occur during arithmetic operations. The operation and operands are initialized with the initialization arguments named :operation and :operands to make-condition, and are accessed by the functions arithmetic-error-operation and arithmetic-error-operands.

+

See Also:

+

+arithmetic-error-operation, arithmetic-error-operands

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cell_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cell_e.htm new file mode 100644 index 00000000..afad83c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cell_e.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type CELL-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type CELL-ERROR

+

Class Precedence List:

+ cell-error, error, serious-condition, condition, t

+

Description:

+

+The type cell-error consists of error conditions that occur during a location access. The name of the offending cell is initialized by the :nameinitialization argument to make-condition, and is accessed by the function cell-error-name.

+

See Also:

+

+cell-error-name

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cnd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cnd.htm new file mode 100644 index 00000000..9c3d0f93 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_cnd.htm @@ -0,0 +1,40 @@ + + + +CLHS: Condition Type CONDITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type CONDITION

+

+

Class Precedence List:

+ condition, t

+

Description:

+

+All types of conditions, whether error or non-error, must inherit from this type.

+No additional subtype relationships among the specified subtypes of type condition are allowed, except when explicitly mentioned in the text; however implementations are permitted to introduce additional types and one of these types can be a subtype of any number of the subtypes of type condition.

+ Whether a user-defined condition type has slots that are accessible by with-slots is implementation-dependent. Furthermore, even in an implementation in which user-defined condition types would have slots, it is implementation-dependent whether any condition types defined in this document have such slots or, if they do, what their names might be; only the reader functions documented by this specification may be relied upon by portable code.

+ Conforming code must observe the following restrictions related to conditions:

+

* define-condition, not defclass, must be used to define new condition types.

+
* make-condition, not make-instance, must be used to create condition objects explicitly.

+
* The :report option of define-condition, not defmethod for print-object, must be used to define a condition reporter.

+
* slot-value, slot-boundp, slot-makunbound, and with-slots must not be used on condition objects. Instead, the appropriate accessor functions (defined by define-condition) should be used.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_contro.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_contro.htm new file mode 100644 index 00000000..6de1e055 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_contro.htm @@ -0,0 +1,32 @@ + + + +CLHS: Condition Type CONTROL-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type CONTROL-ERROR

+

Class Precedence List:

+ control-error, error, serious-condition, condition, t

+

Description:

+

+The type control-error consists of error conditions that result from invalid dynamic transfers of control in a program. The errors that result from giving throw a tag that is not active or from giving go or return-from a tag that is no longer dynamically available are of type control-error.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_divisi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_divisi.htm new file mode 100644 index 00000000..7738b020 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_divisi.htm @@ -0,0 +1,32 @@ + + + +CLHS: Condition Type DIVISION-BY-ZERO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type DIVISION-BY-ZERO

+

Class Precedence List:

+ division-by-zero, arithmetic-error, error, serious-condition, condition, t

+

Description:

+

+The type division-by-zero consists of error conditions that occur because of division by zero.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_end_of.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_end_of.htm new file mode 100644 index 00000000..e0b80e70 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_end_of.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type END-OF-FILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type END-OF-FILE

+

Class Precedence List:

+ end-of-file, stream-error, error, serious-condition, condition, t

+

Description:

+

+The type end-of-file consists of error conditions related to read operations that are done on streams that have no more data.

+

See Also:

+

+stream-error-stream

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_error.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_error.htm new file mode 100644 index 00000000..39691e97 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_error.htm @@ -0,0 +1,32 @@ + + + +CLHS: Condition Type ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type ERROR

+

Class Precedence List:

+ error, serious-condition, condition, t

+

Description:

+

+The type error consists of all conditions that represent errors.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_file_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_file_e.htm new file mode 100644 index 00000000..cc87349e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_file_e.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type FILE-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type FILE-ERROR

+

Class Precedence List:

+ file-error, error, serious-condition, condition, t

+

Description:

+

+The type file-error consists of error conditions that occur during an attempt to open or close a file, or during some low-level transactions with a file system. The ``offending pathname'' is initialized by the :pathnameinitialization argument to make-condition, and is accessed by the function file-error-pathname.

+

See Also:

+

+file-error-pathname, open, probe-file, directory, ensure-directories-exist

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_1.htm new file mode 100644 index 00000000..b649dab2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_1.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type FLOATING-POINT-INEXACT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type FLOATING-POINT-INEXACT

+

+

Class Precedence List:

+ floating-point-inexact, arithmetic-error, error, serious-condition, condition, t

+

Description:

+

+The type floating-point-inexact consists of error conditions that occur because of certain floating point traps.

+It is implementation-dependent whether floating point traps occur, and whether or how they may be enabled or disabled. Therefore, conforming code may establish handlers for this condition, but must not depend on its being signaled.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_2.htm new file mode 100644 index 00000000..1790241f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_2.htm @@ -0,0 +1,32 @@ + + + +CLHS: Condition Type FLOATING-POINT-OVERFLOW + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type FLOATING-POINT-OVERFLOW

+

Class Precedence List:

+ floating-point-overflow, arithmetic-error, error, serious-condition, condition, t

+

Description:

+

+The type floating-point-overflow consists of error conditions that occur because of floating-point overflow.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_3.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_3.htm new file mode 100644 index 00000000..10dad92c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floa_3.htm @@ -0,0 +1,32 @@ + + + +CLHS: Condition Type FLOATING-POINT-UNDERFLOW + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type FLOATING-POINT-UNDERFLOW

+

Class Precedence List:

+ floating-point-underflow, arithmetic-error, error, serious-condition, condition, t

+

Description:

+

+The type floating-point-underflow consists of error conditions that occur because of floating-point underflow.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floati.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floati.htm new file mode 100644 index 00000000..0055c4a2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_floati.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type FLOATING-POINT-INVALID-OPERATION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type FLOATING-POINT-INVALID-OPERATION

+

+

Class Precedence List:

+ floating-point-invalid-operation, arithmetic-error, error, serious-condition, condition, t

+

Description:

+

+The type floating-point-invalid-operation consists of error conditions that occur because of certain floating point traps.

+It is implementation-dependent whether floating point traps occur, and whether or how they may be enabled or disabled. Therefore, conforming code may establish handlers for this condition, but must not depend on its being signaled.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_parse_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_parse_.htm new file mode 100644 index 00000000..f579f036 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_parse_.htm @@ -0,0 +1,38 @@ + + + +CLHS: Condition Type PARSE-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type PARSE-ERROR

+

+

Class Precedence List:

+

+parse-error, error, serious-condition, condition, t

+

Description:

+

+The type parse-error consists of error conditions that are related to parsing.

+

See Also:

+

+parse-namestring, reader-error

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pkg_er.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pkg_er.htm new file mode 100644 index 00000000..973f2eb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pkg_er.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type PACKAGE-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type PACKAGE-ERROR

+

Class Precedence List:

+ package-error, error, serious-condition, condition, t

+

Description:

+

+The type package-error consists of error conditions related to operations on packages. The offending package (or package name) is initialized by the :packageinitialization argument to make-condition, and is accessed by the function package-error-package.

+

See Also:

+

+package-error-package, Section 9 (Conditions)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pr_not.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pr_not.htm new file mode 100644 index 00000000..44d565d2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_pr_not.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type PRINT-NOT-READABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type PRINT-NOT-READABLE

+

Class Precedence List:

+ print-not-readable, error, serious-condition, condition, t

+

Description:

+

+The type print-not-readable consists of error conditions that occur during output while *print-readably* is true, as a result of attempting to write a printed representation with the Lisp printer that would not be correctly read back with the Lisp reader. The object which could not be printed is initialized by the :objectinitialization argument to make-condition, and is accessed by the function print-not-readable-object.

+

See Also:

+

+print-not-readable-object

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_progra.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_progra.htm new file mode 100644 index 00000000..8e9d10f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_progra.htm @@ -0,0 +1,32 @@ + + + +CLHS: Condition Type PROGRAM-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type PROGRAM-ERROR

+

Class Precedence List:

+ program-error, error, serious-condition, condition, t

+

Description:

+

+The type program-error consists of error conditions related to incorrect program syntax. The errors that result from naming a go tag or a block tag that is not lexically apparent are of type program-error.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_rder_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_rder_e.htm new file mode 100644 index 00000000..df86b5bd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_rder_e.htm @@ -0,0 +1,37 @@ + + + +CLHS: Condition Type READER-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type READER-ERROR

+

+

Class Precedence List:

+ reader-error, parse-error, stream-error, error, serious-condition, condition, t

+

Description:

+

+The type reader-error consists of error conditions that are related to tokenization and parsing done by the Lisp reader.

+

See Also:

+

+read, stream-error-stream, Section 23.1 (Reader Concepts)

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_seriou.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_seriou.htm new file mode 100644 index 00000000..6f408fe8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_seriou.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type SERIOUS-CONDITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type SERIOUS-CONDITION

+

Class Precedence List:

+ serious-condition, condition, t

+

Description:

+

+All conditions serious enough to require interactive intervention if not handled should inherit from the type serious-condition. This condition type is provided primarily so that it may be included as a superclass of other condition types; it is not intended to be signaled directly.

+

Notes:

+

+Signaling a serious condition does not itself force entry into the debugger. However, except in the unusual situation where the programmer can assure that no harm will come from failing to handle a serious condition, such a condition is usually signaled with error rather than signal in order to assure that the program does not continue without handling the condition. (And conversely, it is conventional to use signal rather than error to signal conditions which are not serious conditions, since normally the failure to handle a non-serious condition is not reason enough for the debugger to be entered.)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_cn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_cn.htm new file mode 100644 index 00000000..8ff27d6c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_cn.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type SIMPLE-CONDITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type SIMPLE-CONDITION

+

Class Precedence List:

+ simple-condition, condition, t

+

Description:

+

+The type simple-condition represents conditions that are signaled by signal whenever a format-control is supplied as the function's first argument. The format control and format arguments are initialized with the initialization arguments named :format-control and :format-arguments to make-condition, and are accessed by the functions simple-condition-format-control and simple-condition-format-arguments. If format arguments are not supplied to make-condition, nil is used as a default.

+

See Also:

+

+ simple-condition-format-control, simple-condition-format-arguments

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_er.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_er.htm new file mode 100644 index 00000000..a7d15ad4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_er.htm @@ -0,0 +1,33 @@ + + + +CLHS: Condition Type SIMPLE-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type SIMPLE-ERROR

+

Class Precedence List:

+

+ simple-error, simple-condition, error, serious-condition, condition, t

+

Description:

+

+The type simple-error consists of conditions that are signaled by error or cerror when a format control is supplied as the function's first argument.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_tp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_tp.htm new file mode 100644 index 00000000..6ce09eec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_tp.htm @@ -0,0 +1,36 @@ + + + +CLHS: Condition Type SIMPLE-TYPE-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type SIMPLE-TYPE-ERROR

+

Class Precedence List:

+

+ simple-type-error, simple-condition, type-error, error, serious-condition, condition, t

+

Description:

+

+Conditions of type simple-type-error are like conditions of type type-error, except that they provide an alternate mechanism for specifying how the condition is to be reported; see the type simple-condition.

+

See Also:

+

+simple-condition, simple-condition-format-control, simple-condition-format-arguments, type-error-datum, type-error-expected-type

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_wa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_wa.htm new file mode 100644 index 00000000..57ec0ce0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_smp_wa.htm @@ -0,0 +1,33 @@ + + + +CLHS: Condition Type SIMPLE-WARNING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type SIMPLE-WARNING

+

Class Precedence List:

+

+ simple-warning, simple-condition, warning, condition, t

+

Description:

+

+The type simple-warning represents conditions that are signaled by warn whenever a format control is supplied as the function's first argument.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_stm_er.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_stm_er.htm new file mode 100644 index 00000000..5ff3e994 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_stm_er.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type STREAM-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type STREAM-ERROR

+

Class Precedence List:

+ stream-error, error, serious-condition, condition, t

+

Description:

+

+The type stream-error consists of error conditions that are related to receiving input from or sending output to a stream. The ``offending stream'' is initialized by the :streaminitialization argument to make-condition, and is accessed by the function stream-error-stream.

+

See Also:

+

+stream-error-stream

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_storag.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_storag.htm new file mode 100644 index 00000000..8dea7544 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_storag.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type STORAGE-CONDITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type STORAGE-CONDITION

+

Class Precedence List:

+ storage-condition, serious-condition, condition, t

+

Description:

+

+The type storage-condition consists of serious conditions that relate to problems with memory management that are potentially due to implementation-dependent limits rather than semantic errors in conforming programs, and that typically warrant entry to the debugger if not handled. Depending on the details of the implementation, these might include such problems as stack overflow, memory region overflow, and storage exhausted.

+

Notes:

+

+While some Common Lisp operations might signal storage-condition because they are defined to create objects, it is unspecified whether operations that are not defined to create objects create them anyway and so might also signal storage-condition. Likewise, the evaluator itself might create objects and so might signal storage-condition. (The natural assumption might be that such object creation is naturally inefficient, but even that is implementation-dependent.) In general, the entire question of how storage allocation is done is implementation-dependent, and so any operation might signal storage-condition at any time. Because such a condition is indicative of a limitation of the implementation or of the image rather than an error in a program, objects of type storage-condition are not of type error.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_style_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_style_.htm new file mode 100644 index 00000000..fa0c54c6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_style_.htm @@ -0,0 +1,40 @@ + + + +CLHS: Condition Type STYLE-WARNING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type STYLE-WARNING

+

Class Precedence List:

+ style-warning, warning, condition, t

+

Description:

+

+The type style-warning includes those conditions that represent situations involving code that is conforming code but that is nevertheless considered to be faulty or substandard.

+

See Also:

+

+muffle-warning

+

Notes:

+

+An implementation might signal such a condition if it encounters code that uses deprecated features or that appears unaesthetic or inefficient.

+An `unused variable' warning must be of type style-warning.

+In general, the question of whether code is faulty or substandard is a subjective decision to be made by the facility processing that code. The intent is that whenever such a facility wishes to complain about code on such subjective grounds, it should use this condition type so that any clients who wish to redirect or muffle superfluous warnings can do so without risking that they will be redirecting or muffling other, more serious warnings.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_tp_err.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_tp_err.htm new file mode 100644 index 00000000..206f55ef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_tp_err.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type TYPE-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type TYPE-ERROR

+

Class Precedence List:

+ type-error, error, serious-condition, condition, t

+

Description:

+

+The type type-error represents a situation in which an object is not of the expected type. The ``offending datum'' and ``expected type'' are initialized by the initialization arguments named :datum and :expected-type to make-condition, and are accessed by the functions type-error-datum and type-error-expected-type.

+

See Also:

+

+type-error-datum, type-error-expected-type

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unbo_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unbo_1.htm new file mode 100644 index 00000000..59fdbf50 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unbo_1.htm @@ -0,0 +1,36 @@ + + + +CLHS: Condition Type UNBOUND-VARIABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type UNBOUND-VARIABLE

+

Class Precedence List:

+ unbound-variable, cell-error, error, serious-condition, condition, t

+

Description:

+

+The type unbound-variable consists of error conditions that represent attempts to read the value of an unbound variable.

+The name of the cell (see cell-error) is the name of the variable that was unbound.

+

See Also:

+

+cell-error-name

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unboun.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unboun.htm new file mode 100644 index 00000000..d676ec86 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_unboun.htm @@ -0,0 +1,37 @@ + + + +CLHS: Condition Type UNBOUND-SLOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type UNBOUND-SLOT

+

+

Class Precedence List:

+ unbound-slot, cell-error, error, serious-condition, condition, t

+

Description:

+

+The object having the unbound slot is initialized by the :instanceinitialization argument to make-condition, and is accessed by the function unbound-slot-instance.

+The name of the cell (see cell-error) is the name of the slot.

+

See Also:

+

+cell-error-name, unbound-slot-object, Section 9.1 (Condition System Concepts)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_undefi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_undefi.htm new file mode 100644 index 00000000..f8c538b9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_undefi.htm @@ -0,0 +1,36 @@ + + + +CLHS: Condition Type UNDEFINED-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type UNDEFINED-FUNCTION

+

Class Precedence List:

+ undefined-function, cell-error, error, serious-condition, condition, t

+

Description:

+

+The type undefined-function consists of error conditions that represent attempts to read the definition of an undefined function.

+The name of the cell (see cell-error) is the function name which was funbound.

+

See Also:

+

+cell-error-name

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_warnin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_warnin.htm new file mode 100644 index 00000000..38a4aa58 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/e_warnin.htm @@ -0,0 +1,35 @@ + + + +CLHS: Condition Type WARNING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Condition Type WARNING

+

Class Precedence List:

+ warning, condition, t

+

Description:

+

+The type warning consists of all types of warnings.

+

See Also:

+

+style-warning

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_1pl_1_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_1pl_1_.htm new file mode 100644 index 00000000..e5b6d03c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_1pl_1_.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function 1+, 1- + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function 1+, 1-

+

Syntax:

+

+ +1+ number => successor

+ +1- number => predecessor

+

+

Arguments and Values:

+

+number---a number.

+successor, predecessor---a number.

+

Description:

+

+1+ returns a number that is one more than its argument number. 1- returns a number that is one less than its argument number.

+

Examples:

+

+

+ (1+ 99) =>  100 
+ (1- 100) =>  99 
+ (1+ (complex 0.0)) =>  #C(1.0 0.0) 
+ (1- 5/3) =>  2/3 
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Might signal type-error if its argument is not a number. Might signal arithmetic-error.

+

See Also:

+

+incf, decf

+

Notes:

+

+

+ (1+ number) ==  (+ number 1)
+ (1- number) ==  (- number 1)
+
+ Implementors are encouraged to make the performance of both the previous expressions be the same.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f__.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f__.htm new file mode 100644 index 00000000..cdfb9eab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f__.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function - + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function -

+

Syntax:

+

+ +- number => negation

+

+ +- minuend &rest subtrahends+ => difference

+

+

Arguments and Values:

+

+number, minuend, subtrahend---a number.

+negation, difference---a number.

+

Description:

+

+The function - performs arithmetic subtraction and negation.

+If only one number is supplied, the negation of that number is returned.

+If more than one argument is given, it subtracts all of the subtrahends from the minuend and returns the result.

+The function - performs necessary type conversions.

+

Examples:

+

+

+ (- 55.55) =>  -55.55
+ (- #c(3 -5)) =>  #C(-3 5)
+ (- 0) =>  0
+ (eql (- 0.0) -0.0) =>  true
+ (- #c(100 45) #c(0 45)) =>  100
+ (- 10 1 2 3 4) =>  0
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Might signal type-error if some argument is not a number. Might signal arithmetic-error.

+

See Also:

+

+Section 12.1.1 (Numeric Operations), Section 12.1.3 (Rational Computations), Section 12.1.4 (Floating-point Computations), Section 12.1.5 (Complex Computations)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abortc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abortc.htm new file mode 100644 index 00000000..00afe4a0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abortc.htm @@ -0,0 +1,186 @@ + + + +CLHS: Function ABORT, CONTINUE, MUFFLE-WARNING... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE

+

Syntax:

+

+ +abort &optional condition =>|

+ +continue &optional condition => nil

+ +muffle-warning &optional condition =>|

+ +store-value value &optional condition => nil

+ +use-value value &optional condition => nil

+

+

Arguments and Values:

+

+value---an object.

+ condition---a condition object, or nil.

+

Description:

+

+Transfers control to the most recently established applicable restart having the same name as the function. That is, the function abort searches for an applicable abort restart, the function continue searches for an applicable continue restart, and so on.

+If no such restart exists, the functions continue, store-value, and use-value return nil, and the functions abort and muffle-warning signal an error of type control-error.

+ When condition is non-nil, only those restarts are considered that are either explicitly associated with that condition, or not associated with any condition; that is, the excluded restarts are those that are associated with a non-empty set of conditions of which the given condition is not an element. If condition is nil, all restarts are considered.

+

Examples:

+

+

+;;; Example of the ABORT retart
+
+ (defmacro abort-on-error (&body forms)
+   `(handler-bind ((error #'abort))
+      ,@forms)) =>  ABORT-ON-ERROR
+ (abort-on-error (+ 3 5)) =>  8
+ (abort-on-error (error "You lose."))
+>>  Returned to Lisp Top Level.
+
+;;; Example of the CONTINUE restart
+
+ (defun real-sqrt (n)
+   (when (minusp n)
+     (setq n (- n))
+     (cerror "Return sqrt(~D) instead." "Tried to take sqrt(-~D)." n))
+   (sqrt n))
+
+ (real-sqrt 4) =>  2
+ (real-sqrt -9)
+>>  Error: Tried to take sqrt(-9).
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Return sqrt(9) instead.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> (continue)
+>>  Return sqrt(9) instead.
+=>  3
+ 
+ (handler-bind ((error #'(lambda (c) (continue))))
+   (real-sqrt -9)) =>  3
+
+;;; Example of the MUFFLE-WARNING restart
+
+ (defun count-down (x)
+   (do ((counter x (1- counter)))
+       ((= counter 0) 'done)
+     (when (= counter 1)
+       (warn "Almost done"))
+     (format t "~&~D~%" counter)))
+=>  COUNT-DOWN
+ (count-down 3)
+>>  3
+>>  2
+>>  Warning: Almost done
+>>  1
+=>  DONE
+ (defun ignore-warnings-while-counting (x)
+   (handler-bind ((warning #'ignore-warning))
+     (count-down x)))
+=>  IGNORE-WARNINGS-WHILE-COUNTING
+ (defun ignore-warning (condition)
+   (declare (ignore condition))
+   (muffle-warning))
+=>  IGNORE-WARNING
+ (ignore-warnings-while-counting 3)
+>>  3
+>>  2
+>>  1
+=>  DONE
+
+;;; Example of the STORE-VALUE and USE-VALUE restarts
+
+ (defun careful-symbol-value (symbol)
+   (check-type symbol symbol)
+   (restart-case (if (boundp symbol)
+                     (return-from careful-symbol-value 
+                                  (symbol-value symbol))
+                     (error 'unbound-variable
+                            :name symbol))
+     (use-value (value)
+       :report "Specify a value to use this time."
+       value)
+     (store-value (value)
+       :report "Specify a value to store and use in the future."
+       (setf (symbol-value symbol) value))))
+ (setq a 1234) =>  1234
+ (careful-symbol-value 'a) =>  1234
+ (makunbound 'a) =>  A
+ (careful-symbol-value 'a)
+>>  Error: A is not bound.
+>>  To continue, type :CONTINUE followed by an option number.
+>>   1: Specify a value to use this time.
+>>   2: Specify a value to store and use in the future.
+>>   3: Return to Lisp Toplevel.
+>>  Debug> (use-value 12)
+=>  12
+ (careful-symbol-value 'a)
+>>  Error: A is not bound.
+>>  To continue, type :CONTINUE followed by an option number.
+>>    1: Specify a value to use this time.
+>>    2: Specify a value to store and use in the future.
+>>    3: Return to Lisp Toplevel.
+>>  Debug> (store-value 24)
+=>  24
+ (careful-symbol-value 'a)
+=>  24
+
+;;; Example of the USE-VALUE restart
+
+ (defun add-symbols-with-default (default &rest symbols)
+   (handler-bind ((sys:unbound-symbol
+                    #'(lambda (c)
+                        (declare (ignore c)) 
+                        (use-value default))))
+     (apply #'+ (mapcar #'careful-symbol-value symbols))))
+=>  ADD-SYMBOLS-WITH-DEFAULT
+ (setq x 1 y 2) =>  2
+ (add-symbols-with-default 3 'x 'y 'z) =>  6
+
+
+
+

+

Side Effects:

+

+A transfer of control may occur if an appropriate restart is available, or (in the case of the function abort or the function muffle-warning) execution may be stopped.

+

Affected By:

+

+Each of these functions can be affected by the presence of a restart having the same name.

+

Exceptional Situations:

+

+If an appropriate abort restart is not available for the function abort, or an appropriate muffle-warning restart is not available for the function muffle-warning, an error of type control-error is signaled.

+

See Also:

+

+invoke-restart, Section 9.1.4.2 (Restarts), Section 9.1.4.2.2 (Interfaces to Restarts), assert, ccase, cerror, check-type, ctypecase, use-value, warn

+

Notes:

+

+

+ (abort condition) ==  (invoke-restart 'abort)
+ (muffle-warning)  ==  (invoke-restart 'muffle-warning)
+ (continue)        ==  (let ((r (find-restart 'continue))) (if r (invoke-restart r)))
+ (use-value x) ==  (let ((r (find-restart 'use-value))) (if r (invoke-restart r x)))
+ (store-value x) ==  (let ((r (find-restart 'store-value))) (if r (invoke-restart r x)))
+
+

+No functions defined in this specification are required to provide a use-value restart.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abs.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abs.htm new file mode 100644 index 00000000..6c429b27 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_abs.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function ABS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ABS

+

Syntax:

+

+ +abs number => absolute-value

+

+

Arguments and Values:

+

+number---a number.

+absolute-value---a non-negative real.

+

Description:

+

+abs returns the absolute value of number.

+If number is a real, the result is of the same type as number.

+If number is a complex, the result is a positive real with the same magnitude as number. The result can be a float even if number's components are rationals and an exact rational result would have been possible. Thus the result of (abs #c(3 4)) can be either 5 or 5.0, depending on the implementation.

+

Examples:

+

+ +

+ (abs 0) =>  0
+ (abs 12/13) =>  12/13
+ (abs -1.09) =>  1.09
+ (abs #c(5.0 -5.0)) =>  7.071068
+ (abs #c(5 5)) =>  7.071068
+ (abs #c(3/5 4/5)) =>  1 or approximately 1.0
+ (eql (abs -0.0) -0.0) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes:

+

+If number is a complex, the result is equivalent to the following:

+(sqrt (+ (expt (realpart number) 2) (expt (imagpart number) 2)))

+An implementation should not use this formula directly for all complexes but should handle very large or very small components specially to avoid intermediate overflow or underflow.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_acons.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_acons.htm new file mode 100644 index 00000000..0eb8b529 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_acons.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function ACONS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ACONS

+

Syntax:

+

+ +acons key datum alist => new-alist

+

+

Arguments and Values:

+

+key---an object.

+datum---an object.

+alist---an association list.

+new-alist---an association list.

+

Description:

+

+Creates a fresh cons, the cdr of which is alist and the car of which is another fresh cons, the car of which is key and the cdr of which is datum.

+

Examples:

+

+

+ (setq alist '()) =>  NIL
+ (acons 1 "one" alist) =>  ((1 . "one"))
+ alist =>  NIL
+ (setq alist (acons 1 "one" (acons 2 "two" alist))) =>  ((1 . "one") (2 . "two"))
+ (assoc 1 alist) =>  (1 . "one")
+ (setq alist (acons 1 "uno" alist)) =>  ((1 . "uno") (1 . "one") (2 . "two"))
+ (assoc 1 alist) =>  (1 . "uno")
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+assoc, pairlis

+

Notes:

+

+

+(acons key datum alist) ==  (cons (cons key datum) alist)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_add_me.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_add_me.htm new file mode 100644 index 00000000..db0d7c60 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_add_me.htm @@ -0,0 +1,58 @@ + + + +CLHS: Standard Generic Function ADD-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function ADD-METHOD

+

Syntax:

+

+ +add-method generic-function method => generic-function

+

+

Method Signatures:

+

+ +add-method (generic-function standard-generic-function) (method method)

+

+

Arguments and Values:

+

+generic-function---a generic function object.

+method---a method object.

+

Description:

+

+The generic function add-method adds a method to a generic function.

+If method agrees with an existing method of generic-function on parameter specializers and qualifiers, the existing method is replaced.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The lambda list of the method function of method must be congruent with the lambda list of generic-function, or an error of type error is signaled.

+If method is a method object of another generic function, an error of type error is signaled.

+

See Also:

+

+defmethod, defgeneric, find-method, remove-method, Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjoin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjoin.htm new file mode 100644 index 00000000..61e89c9e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjoin.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function ADJOIN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ADJOIN

+

Syntax:

+

+ +adjoin item list &key key test test-not => new-list

+

+

Arguments and Values:

+

+item---an object.

+list---a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+new-list---a list.

+

Description:

+

+Tests whether item is the same as an existing element of list. If the item is not an existing element, adjoin adds it to list (as if by cons) and returns the resulting list; otherwise, nothing is added and the original list is returned.

+The test, test-not, and key affect how it is determined whether item is the same as an element of list. For details, see Section 17.2.1 (Satisfying a Two-Argument Test).

+

+

Examples:

+

+

+ (setq slist '()) =>  NIL 
+ (adjoin 'a slist) =>  (A) 
+ slist =>  NIL 
+ (setq slist (adjoin '(test-item 1) slist)) =>  ((TEST-ITEM 1)) 
+ (adjoin '(test-item 1) slist) =>  ((TEST-ITEM 1) (TEST-ITEM 1)) 
+ (adjoin '(test-item 1) slist :test 'equal) =>  ((TEST-ITEM 1)) 
+ (adjoin '(new-test-item 1) slist :key #'cadr) =>  ((TEST-ITEM 1)) 
+ (adjoin '(new-test-item 1) slist) =>  ((NEW-TEST-ITEM 1) (TEST-ITEM 1)) 
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list is not a proper list.

+

See Also:

+

+pushnew, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+

+ (adjoin item list :key fn)
+   ==  (if (member (fn item) list :key fn) list (cons item list))
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adju_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adju_1.htm new file mode 100644 index 00000000..8971f8d1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adju_1.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function ADJUSTABLE-ARRAY-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ADJUSTABLE-ARRAY-P

+

Syntax:

+

+ +adjustable-array-p array => generalized-boolean

+

+

Arguments and Values:

+

+array---an array.

+generalized-boolean---a generalized boolean.

+

Description:

+

+

+Returns true if and only if adjust-array could return a value which is identical to array when given that array as its first argument.

+

Examples:

+

+

+ (adjustable-array-p 
+   (make-array 5
+               :element-type 'character 
+               :adjustable t 
+               :fill-pointer 3)) =>  true
+ (adjustable-array-p (make-array 4)) =>  implementation-dependent
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if its argument is not an array.

+

See Also:

+

+adjust-array, make-array

+

Notes: None. +

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjust.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjust.htm new file mode 100644 index 00000000..da3801e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_adjust.htm @@ -0,0 +1,135 @@ + + + +CLHS: Function ADJUST-ARRAY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ADJUST-ARRAY

+

Syntax:

+

+ +adjust-array array new-dimensions &key element-type initial-element initial-contents fill-pointer displaced-to displaced-index-offset

=> adjusted-array

+

+

Arguments and Values:

+

+array---an array.

+new-dimensions---a valid array dimension or a list of valid array dimensions.

+element-type---a type specifier.

+initial-element---an object. Initial-element must not be supplied if either initial-contents or displaced-to is supplied.

+initial-contents---an object. If array has rank greater than zero, then initial-contents is composed of nested sequences, the depth of which must equal the rank of array. Otherwise, array is zero-dimensional and initial-contents supplies the single element. initial-contents must not be supplied if either initial-element or displaced-to is given.

+fill-pointer---a valid fill pointer for the array to be created, or t, or nil. The default is nil.

+displaced-to---an array or nil. initial-elements and initial-contents must not be supplied if displaced-to is supplied.

+ displaced-index-offset---an object of type (fixnum 0 n) where n is (array-total-size displaced-to). displaced-index-offset may be supplied only if displaced-to is supplied.

+adjusted-array---an array.

+

Description:

+

+adjust-array changes the dimensions or elements of array. The result is an array of the same type and rank as array, that is either the modified array, or a newly created array to which array can be displaced, and that has the given new-dimensions.

+New-dimensions specify the size of each dimension of array.

+Element-type specifies the type of the elements of the resulting array. If element-type is supplied, the consequences are unspecified if the upgraded array element type of element-type is not the same as the actual array element type of array.

+If initial-contents is supplied, it is treated as for make-array. In this case none of the original contents of array appears in the resulting array.

+ If fill-pointer is an integer, it becomes the fill pointer for the resulting array. If fill-pointer is the symbol t, it indicates that the size of the resulting array should be used as the fill pointer. If fill-pointer is nil, it indicates that the fill pointer should be left as it is.

+If displaced-to non-nil, a displaced array is created. The resulting array shares its contents with the array given by displaced-to. The resulting array cannot contain more elements than the array it is displaced to. If displaced-to is not supplied or nil, the resulting array is not a displaced array. If array A is created displaced to array B and subsequently array B is given to adjust-array, array A will still be displaced to array B. Although array might be a displaced array, the resulting array is not a displaced array unless displaced-to is supplied and not nil. The interaction between adjust-array and displaced arrays is as follows given three arrays, A, B, and C:

+

A is not displaced before or after the call

+
+ (adjust-array A ...)
+
+

+The dimensions of A are altered, and the contents rearranged as appropriate. Additional elements of A are taken from initial-element. The use of initial-contents causes all old contents to be discarded.

+

A is not displaced before, but is displaced to C after the call

+
+ (adjust-array A ... :displaced-to C)
+
+

+None of the original contents of A appears in A afterwards; A now contains the contents of C, without any rearrangement of C.

+

A is displaced to B before the call, and is displaced to C after the call

+
+ (adjust-array A ... :displaced-to B)
+ (adjust-array A ... :displaced-to C)
+
+

+B and C might be the same. The contents of B do not appear in A afterward unless such contents also happen to be in C If displaced-index-offset is not supplied in the adjust-array call, it defaults to zero; the old offset into B is not retained.

+

A is displaced to B before the call, but not displaced afterward.

+
+ (adjust-array A ... :displaced-to B)
+ (adjust-array A ... :displaced-to nil)
+
+ A gets a new ``data region,'' and contents of B are copied into it as appropriate to maintain the existing old contents; additional elements of A are taken from initial-element if supplied. However, the use of initial-contents causes all old contents to be discarded.

+If displaced-index-offset is supplied, it specifies the offset of the resulting array from the beginning of the array that it is displaced to. If displaced-index-offset is not supplied, the offset is 0. The size of the resulting array plus the offset value cannot exceed the size of the array that it is displaced to.

+If only new-dimensions and an initial-element argument are supplied, those elements of array that are still in bounds appear in the resulting array. The elements of the resulting array that are not in the bounds of array are initialized to initial-element; if initial-element is not provided, the consequences of later reading any such new element of new-array before it has been initialized are undefined.

+If initial-contents or displaced-to is supplied, then none of the original contents of array appears in the new array.

+

+ The consequences are unspecified if array is adjusted to a size smaller than its fill pointer without supplying the fill-pointer argument so that its fill-pointer is properly adjusted in the process.

+If A is displaced to B, the consequences are unspecified if B is adjusted in such a way that it no longer has enough elements to satisfy A.

+

+If adjust-array is applied to an array that is actually adjustable, the array returned is identical to array. If the array returned by adjust-array is distinct from array, then the argument array is unchanged.

+Note that if an array A is displaced to another array B, and B is displaced to another array C, and B is altered by adjust-array, A must now refer to the adjust contents of B. This means that an implementation cannot collapse the chain to make A refer to C directly and forget that the chain of reference passes through B. However, caching techniques are permitted as long as they preserve the semantics specified here.

+

Examples:

+

+

+ (adjustable-array-p
+  (setq ada (adjust-array
+              (make-array '(2 3)
+                          :adjustable t
+                          :initial-contents '((a b c) (1 2 3)))
+              '(4 6)))) =>  T 
+ (array-dimensions ada) =>  (4 6) 
+ (aref ada 1 1) =>  2 
+ (setq beta (make-array '(2 3) :adjustable t))
+=>  #2A((NIL NIL NIL) (NIL NIL NIL)) 
+ (adjust-array beta '(4 6) :displaced-to ada)
+=>  #2A((A B C NIL NIL NIL)
+       (1 2 3 NIL NIL NIL)
+       (NIL NIL NIL NIL NIL NIL) 
+       (NIL NIL NIL NIL NIL NIL))
+ (array-dimensions beta) =>  (4 6)
+ (aref beta 1 1) =>  2 
+
+

+Suppose that the 4-by-4 array in m looks like this:

+

+#2A(( alpha     beta      gamma     delta )
+    ( epsilon   zeta      eta       theta )
+    ( iota      kappa     lambda    mu    )
+    ( nu        xi        omicron   pi    ))
+
+ Then the result of

+

+ (adjust-array m '(3 5) :initial-element 'baz)
+
+ is a 3-by-5 array with contents

+

+#2A(( alpha     beta      gamma     delta     baz )
+    ( epsilon   zeta      eta       theta     baz )
+    ( iota      kappa     lambda    mu        baz ))
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+An error of type error is signaled if fill-pointer is supplied and non-nil but array has no fill pointer.

+

See Also:

+

+adjustable-array-p, make-array, array-dimension-limit, array-total-size-limit, array

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alloca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alloca.htm new file mode 100644 index 00000000..11a327d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alloca.htm @@ -0,0 +1,60 @@ + + + +CLHS: Standard Generic Function ALLOCATE-INSTANCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function ALLOCATE-INSTANCE

+

+

Syntax:

+

+ +allocate-instance class &rest initargs &key &allow-other-keys => new-instance

+

+

Method Signatures:

+

+ +allocate-instance (class standard-class) &rest initargs

+

+ +allocate-instance (class structure-class) &rest initargs

+

+

Arguments and Values:

+

+class---a class.

+initargs---a list of keyword/value pairs (initialization argument names and values).

+new-instance---an object whose class is class.

+

Description:

+

+The generic function allocate-instance creates and returns a new instance of the class, without initializing it. When the class is a standard class, this means that the slots are unbound; when the class is a structure class, this means the slots' values are unspecified.

+The caller of allocate-instance is expected to have already checked the initialization arguments.

+The generic function allocate-instance is called by make-instance, as described in Section 7.1 (Object Creation and Initialization).

+

Affected By: None. +

Exceptional Situations: None. +

See Also:

+

+defclass, make-instance, class-of, Section 7.1 (Object Creation and Initialization)

+

Notes:

+

+The consequences of adding methods to allocate-instance is unspecified. This capability might be added by the Metaobject Protocol.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alpha_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alpha_.htm new file mode 100644 index 00000000..2c0e7d69 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alpha_.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function ALPHA-CHAR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ALPHA-CHAR-P

+

Syntax:

+

+ +alpha-char-p character => generalized-boolean

+

+

Arguments and Values:

+

+character---a character.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if character is an alphabetic[1] character; otherwise, returns false.

+

Examples:

+

+ +

+ (alpha-char-p #\a) =>  true
+ (alpha-char-p #\5) =>  false
+ (alpha-char-p #\Newline) =>  false
+ ;; This next example presupposes an implementation
+ ;; in which #\<ALPHA> is a defined character.
+ (alpha-char-p #\<ALPHA>) =>  implementation-dependent
+
+

+

Affected By:

+

+None. (In particular, the results of this predicate are independent of any special syntax which might have been enabled in the current readtable.)

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+alphanumericp, Section 13.1.10 (Documentation of Implementation-Defined Scripts)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alphan.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alphan.htm new file mode 100644 index 00000000..de0a9cf4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_alphan.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function ALPHANUMERICP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ALPHANUMERICP

+

Syntax:

+

+ +alphanumericp character => generalized-boolean

+

+

Arguments and Values:

+

+character---a character.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if character is an alphabetic[1] character or a numeric character; otherwise, returns false.

+

Examples:

+

+

+ (alphanumericp #\Z) =>  true
+ (alphanumericp #\9) =>  true
+ (alphanumericp #\Newline) =>  false
+ (alphanumericp #\#) =>  false
+
+

+

Affected By:

+

+None. (In particular, the results of this predicate are independent of any special syntax which might have been enabled in the current readtable.)

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+alpha-char-p, graphic-char-p, digit-char-p

+

Notes:

+

+Alphanumeric characters are graphic as defined by graphic-char-p. The alphanumeric characters are a subset of the graphic characters. The standard characters A through Z, a through z, and 0 through 9 are alphanumeric characters.

+

+ (alphanumericp x)
+   ==  (or (alpha-char-p x) (not (null (digit-char-p x))))
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_append.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_append.htm new file mode 100644 index 00000000..eccc91dc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_append.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function APPEND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function APPEND

+

Syntax:

+

+ +append &rest lists => result

+

+

Arguments and Values:

+

+ list---each must be a proper list except the last, which may be any object.

+result---an object. This will be a list unless the last list was not a list and all preceding lists were null.

+

Description:

+

+append returns a new list that is the concatenation of the copies. lists are left unchanged; the list structure of each of lists except the last is copied. The last argument is not copied; it becomes the cdr of the final dotted pair of the concatenation of the preceding lists, or is returned directly if there are no preceding non-empty lists.

+

Examples:

+

+

+ (append '(a b c) '(d e f) '() '(g)) =>  (A B C D E F G)
+ (append '(a b c) 'd) =>  (A B C . D)
+ (setq lst '(a b c)) =>  (A B C)
+ (append lst '(d)) =>  (A B C D)
+ lst =>  (A B C)
+ (append) =>  NIL
+ (append 'a) =>  A
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+nconc, concatenate

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apply.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apply.htm new file mode 100644 index 00000000..a5584b57 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apply.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function APPLY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function APPLY

+

Syntax:

+

+ +apply function &rest args+ => result*

+

+

Arguments and Values:

+

+ function---a function designator.

+args---a spreadable argument list designator.

+results---the values returned by function.

+

Description:

+

+Applies the function to the args.

+ When the function receives its arguments via &rest, it is permissible (but not required) for the implementation to bind the rest parameter to an object that shares structure with the last argument to apply. Because a function can neither detect whether it was called via apply nor whether (if so) the last argument to apply was a constant, conforming programs must neither rely on the list structure of a rest list to be freshly consed, nor modify that list structure.

+setf can be used with apply in certain circumstances; see Section 5.1.2.5 (APPLY Forms as Places).

+

Examples:

+

+ +

+ (setq f '+) =>  +
+ (apply f '(1 2)) =>  3
+ (setq f #'-) =>  #<FUNCTION ->
+ (apply f '(1 2)) =>  -1
+ (apply #'max 3 5 '(2 7 3)) =>  7
+ (apply 'cons '((+ 2 3) 4)) =>  ((+ 2 3) . 4)
+ (apply #'+ '()) =>  0
+
+ (defparameter *some-list* '(a b c))
+ (defun strange-test (&rest x) (eq x *some-list*))
+ (apply #'strange-test *some-list*) =>  implementation-dependent
+
+ (defun bad-boy (&rest x) (rplacd x 'y))
+ (bad-boy 'a 'b 'c) has undefined consequences.
+ (apply #'bad-boy *some-list*) has undefined consequences.
+
+

+

+ (defun foo (size &rest keys &key double &allow-other-keys)
+   (let ((v (apply #'make-array size :allow-other-keys t keys)))
+     (if double (concatenate (type-of v) v v) v)))
+ (foo 4 :initial-contents '(a b c d) :double t)
+    =>  #(A B C D A B C D)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+funcall, fdefinition, function, Section 3.1 (Evaluation), Section 5.1.2.5 (APPLY Forms as Places)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apropo.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apropo.htm new file mode 100644 index 00000000..c0d79f29 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_apropo.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function APROPOS, APROPOS-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function APROPOS, APROPOS-LIST

+

Syntax:

+

+ +apropos string &optional package => <no values>

+

+ +apropos-list string &optional package => symbols

+

+

Arguments and Values:

+

+string---a string designator.

+package---a package designator or nil. The default is nil.

+symbols---a list of symbols.

+

Description:

+

+These functions search for interned symbols whose names contain the substring string.

+For apropos, as each such symbol is found, its name is printed on standard output. In addition, if such a symbol is defined as a function or dynamic variable, information about those definitions might also be printed.

+For apropos-list, no output occurs as the search proceeds; instead a list of the matching symbols is returned when the search is complete.

+If package is non-nil, only the symbols accessible in that package are searched; otherwise all symbols accessible in any package are searched.

+Because a symbol might be available by way of more than one inheritance path, apropos might print information about the same symbol more than once, or apropos-list might return a list containing duplicate symbols.

+Whether or not the search is case-sensitive is implementation-defined.

+

Examples: None. +

+

Affected By:

+

+The set of symbols which are currently interned in any packages being searched.

+apropos is also affected by *standard-output*.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_d_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_d_1.htm new file mode 100644 index 00000000..bc199c1f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_d_1.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function ARRAY-DIMENSIONS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-DIMENSIONS

+

Syntax:

+

+ +array-dimensions array => dimensions

+

+

Arguments and Values:

+

+array---an array.

+dimensions---a list of integers.

+

Description:

+

+Returns a list of the dimensions of array. (If array is a vector with a fill pointer, that fill pointer is ignored.)

+

Examples:

+

+

+ (array-dimensions (make-array 4)) =>  (4)
+ (array-dimensions (make-array '(2 3))) =>  (2 3)
+ (array-dimensions (make-array 4 :fill-pointer 2)) =>  (4)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if its argument is not an array.

+

See Also:

+

+array-dimension

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dim.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dim.htm new file mode 100644 index 00000000..b83dfa48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dim.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function ARRAY-DIMENSION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-DIMENSION

+

Syntax:

+

+ +array-dimension array axis-number => dimension

+

+

Arguments and Values:

+

+array---an array.

+axis-number---an integer greater than or equal to zero and less than the rank of the array.

+dimension---a non-negative integer.

+

Description:

+

+array-dimension returns the axis-number dimension[1] of array. (Any fill pointer is ignored.)

+

Examples:

+

+

+ (array-dimension (make-array 4) 0) =>  4
+ (array-dimension (make-array '(2 3)) 1) =>  3
+
+

+

Affected By:

+ None.

Exceptional Situations: None. +

+

See Also:

+

+array-dimensions, length

+

Notes:

+ +

+ (array-dimension array n) ==  (nth n (array-dimensions array))
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dis.htm new file mode 100644 index 00000000..d02bf524 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_dis.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function ARRAY-DISPLACEMENT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-DISPLACEMENT

+

+

Syntax:

+

+ +array-displacement array => displaced-to, displaced-index-offset

+

+

Arguments and Values:

+

+array---an array.

+displaced-to---an array or nil.

+displaced-index-offset---a non-negative fixnum.

+

Description:

+

+If the array is a displaced array, returns the values of the :displaced-to and :displaced-index-offset options for the array (see the functions make-array and adjust-array). If the array is not a displaced array, nil and 0 are returned.

+If array-displacement is called on an array for which a non-nil object was provided as the :displaced-to argument to make-array or adjust-array, it must return that object as its first value. It is implementation-dependent whether array-displacement returns a non-nil primary value for any other array.

+

Examples:

+

+

+ (setq a1 (make-array 5)) =>  #<ARRAY 5 simple 46115576>
+ (setq a2 (make-array 4 :displaced-to a1
+                        :displaced-index-offset 1))
+=>  #<ARRAY 4 indirect 46117134>
+ (array-displacement a2)
+=>  #<ARRAY 5 simple 46115576>, 1
+ (setq a3 (make-array 2 :displaced-to a2
+                        :displaced-index-offset 2))
+=>  #<ARRAY 2 indirect 46122527>
+ (array-displacement a3)
+=>  #<ARRAY 4 indirect 46117134>, 2
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if array is not an array.

+

See Also:

+

+make-array

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ele.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ele.htm new file mode 100644 index 00000000..9a872512 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ele.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function ARRAY-ELEMENT-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-ELEMENT-TYPE

+

Syntax:

+

+ +array-element-type array => typespec

+

+

Arguments and Values:

+

+array---an array.

+typespec---a type specifier.

+

Description:

+

+ Returns a type specifier which represents the actual array element type of the array, which is the set of objects that such an array can hold. (Because of array upgrading, this type specifier can in some cases denote a supertype of the expressed array element type of the array.)

+

Examples:

+

+

+ (array-element-type (make-array 4)) =>  T
+ (array-element-type (make-array 12 :element-type '(unsigned-byte 8))) 
+=>  implementation-dependent
+ (array-element-type (make-array 12 :element-type '(unsigned-byte 5)))
+=>  implementation-dependent
+
+

+

+ (array-element-type (make-array 5 :element-type '(mod 5)))
+
+ could be (mod 5), (mod 8), fixnum, t, or any other type of which (mod 5) is a subtype.

+

Affected By:

+

+The implementation.

+

Exceptional Situations:

+

+Should signal an error of type type-error if its argument is not an array.

+

See Also:

+

+array, make-array, subtypep, upgraded-array-element-type

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_has.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_has.htm new file mode 100644 index 00000000..35031f6c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_has.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function ARRAY-HAS-FILL-POINTER-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-HAS-FILL-POINTER-P

+

Syntax:

+

+ +array-has-fill-pointer-p array => generalized-boolean

+

+

Arguments and Values:

+

+array---an array.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if array has a fill pointer; otherwise returns false.

+

Examples:

+

+

+ (array-has-fill-pointer-p (make-array 4)) =>  implementation-dependent
+ (array-has-fill-pointer-p (make-array '(2 3))) =>  false
+ (array-has-fill-pointer-p
+   (make-array 8 
+               :fill-pointer 2 
+               :initial-element 'filler)) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if its argument is not an array.

+

See Also:

+

+make-array, fill-pointer

+

Notes:

+

+Since arrays of rank other than one cannot have a fill pointer, array-has-fill-pointer-p always returns nil when its argument is such an array.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_in_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_in_.htm new file mode 100644 index 00000000..0751dbb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_in_.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function ARRAY-IN-BOUNDS-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-IN-BOUNDS-P

+

Syntax:

+

+ +array-in-bounds-p array &rest subscripts => generalized-boolean

+

+

Arguments and Values:

+

+array---an array.

+subscripts---a list of integers of length equal to the rank of the array.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if the subscripts are all in bounds for array; otherwise returns false. (If array is a vector with a fill pointer, that fill pointer is ignored.)

+

Examples:

+ +

+ (setq a (make-array '(7 11) :element-type 'string-char))
+ (array-in-bounds-p a 0  0) =>  true
+ (array-in-bounds-p a 6 10) =>  true
+ (array-in-bounds-p a 0 -1) =>  false
+ (array-in-bounds-p a 0 11) =>  false
+ (array-in-bounds-p a 7  0) =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+array-dimensions

+

Notes:

+ +

+ (array-in-bounds-p array subscripts)   
+ ==  (and (not (some #'minusp (list subscripts)))
+         (every #'< (list subscripts) (array-dimensions array)))
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ran.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ran.htm new file mode 100644 index 00000000..d12aedc8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_ran.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function ARRAY-RANK + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-RANK

+

Syntax:

+

+ +array-rank array => rank

+

+

Arguments and Values:

+

+array---an array.

+rank---a non-negative integer.

+

Description:

+

+Returns the number of dimensions of array.

+

Examples:

+

+

+ (array-rank (make-array '())) =>  0
+ (array-rank (make-array 4)) =>  1
+ (array-rank (make-array '(4))) =>  1
+ (array-rank (make-array '(2 3))) =>  2
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if its argument is not an array.

+

See Also:

+

+array-rank-limit, make-array

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_row.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_row.htm new file mode 100644 index 00000000..bb0c7be8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_row.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function ARRAY-ROW-MAJOR-INDEX + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-ROW-MAJOR-INDEX

+

Syntax:

+

+ +array-row-major-index array &rest subscripts => index

+

+

Arguments and Values:

+

+array---an array.

+subscripts---a list of valid array indices for the array.

+index---a valid array row-major index for the array.

+

Description:

+

+Computes the position according to the row-major ordering of array for the element that is specified by subscripts, and returns the offset of the element in the computed position from the beginning of array.

+For a one-dimensional array, the result of array-row-major-index equals subscript.

+array-row-major-index ignores fill pointers.

+

Examples:

+

+

+ (setq a (make-array '(4 7) :element-type '(unsigned-byte 8)))
+ (array-row-major-index a 1 2) =>  9
+ (array-row-major-index 
+    (make-array '(2 3 4) 
+                :element-type '(unsigned-byte 8)
+                :displaced-to a
+                :displaced-index-offset 4)
+    0 2 1) =>  9
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+A possible definition of array-row-major-index, with no error-checking, is

+

+ (defun array-row-major-index (a &rest subscripts)
+   (apply #'+ (maplist #'(lambda (x y)
+                            (* (car x) (apply #'* (cdr y))))
+                       subscripts
+                       (array-dimensions a))))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_tot.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_tot.htm new file mode 100644 index 00000000..29bc58d3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ar_tot.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function ARRAY-TOTAL-SIZE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAY-TOTAL-SIZE

+

Syntax:

+

+ +array-total-size array => size

+

+

Arguments and Values:

+

+array---an array.

+size---a non-negative integer.

+

Description:

+

+Returns the array total size of the array.

+

Examples:

+

+

+ (array-total-size (make-array 4)) =>  4
+ (array-total-size (make-array 4 :fill-pointer 2)) =>  4
+ (array-total-size (make-array 0)) =>  0
+ (array-total-size (make-array '(4 2))) =>  8
+ (array-total-size (make-array '(4 0))) =>  0
+ (array-total-size (make-array '())) =>  1
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if its argument is not an array.

+

See Also:

+

+make-array, array-dimensions

+

Notes:

+

+If the array is a vector with a fill pointer, the fill pointer is ignored when calculating the array total size.

+Since the product of no arguments is one, the array total size of a zero-dimensional array is one.

+

+ (array-total-size x)
+    ==  (apply #'* (array-dimensions x))
+    ==  (reduce #'* (array-dimensions x))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_aref.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_aref.htm new file mode 100644 index 00000000..42a0b7c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_aref.htm @@ -0,0 +1,70 @@ + + + +CLHS: Accessor AREF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor AREF

+

Syntax:

+

+ +aref array &rest subscripts => element

+ +(setf (aref array &rest subscripts) new-element)

+

+

Arguments and Values:

+

+array---an array.

+ subscripts---a list of valid array indices for the array.

+element, new-element---an object.

+

Description:

+

+Accesses the array element specified by the subscripts. If no subscripts are supplied and array is zero rank, aref accesses the sole element of array.

+aref ignores fill pointers. It is permissible to use aref to access any array element, whether active or not.

+

Examples:

+

+If the variable foo names a 3-by-5 array, then the first index could be 0, 1, or 2, and then second index could be 0, 1, 2, 3, or 4. The array elements can be referred to by using the function aref; for example, (aref foo 2 1) refers to element (2, 1) of the array.

+

+ (aref (setq alpha (make-array 4)) 3) =>  implementation-dependent
+ (setf (aref alpha 3) 'sirens) =>  SIRENS
+ (aref alpha 3) =>  SIRENS
+ (aref (setq beta (make-array '(2 4) 
+                    :element-type '(unsigned-byte 2)
+                    :initial-contents '((0 1 2 3) (3 2 1 0))))
+        1 2) =>  1
+ (setq gamma '(0 2))
+ (apply #'aref beta gamma) =>  2
+ (setf (apply #'aref beta gamma) 3) =>  3
+ (apply #'aref beta gamma) =>  3
+ (aref beta 0 2) =>  3
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+bit, char, elt, row-major-aref, svref, Section 3.2.1 (Compiler Terminology)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arithm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arithm.htm new file mode 100644 index 00000000..d315c01f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arithm.htm @@ -0,0 +1,56 @@ + + + +CLHS: Function ARITHMETIC-ERROR-OPERANDS... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARITHMETIC-ERROR-OPERANDS, ARITHMETIC-ERROR-OPERATION

+

Syntax:

+

+ +arithmetic-error-operands condition => operands

+ +arithmetic-error-operation condition => operation

+

+

Arguments and Values:

+

+condition---a condition of type arithmetic-error.

+operands---a list.

+operation---a function designator.

+

Description:

+

+arithmetic-error-operands returns a list of the operands which were used in the offending call to the operation that signaled the condition.

+arithmetic-error-operation returns a list of the offending operation in the offending call that signaled the condition.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+arithmetic-error, Section 9 (Conditions)

+

Notes:

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arrayp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arrayp.htm new file mode 100644 index 00000000..ea0b3279 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_arrayp.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function ARRAYP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ARRAYP

+

Syntax:

+

+ +arrayp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type array; otherwise, returns false.

+

Examples:

+

+

+ (arrayp (make-array '(2 3 4) :adjustable t)) =>  true
+ (arrayp (make-array 6)) =>  true
+ (arrayp #*1011) =>  true
+ (arrayp "hi") =>  true
+ (arrayp 'hi) =>  false
+ (arrayp 12) =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+typep

+

Notes:

+

+

+ (arrayp object) ==  (typep object 'array)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ash.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ash.htm new file mode 100644 index 00000000..31f3b11e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ash.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function ASH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ASH

+

Syntax:

+

+ +ash integer count => shifted-integer

+

+

Arguments and Values:

+

+integer---an integer.

+count---an integer.

+shifted-integer---an integer.

+

Description:

+

+ash performs the arithmetic shift operation on the binary representation of integer, which is treated as if it were binary.

+ash shifts integer arithmetically left by count bit positions if count is positive, or right count bit positions if count is negative. The shifted value of the same sign as integer is returned.

+Mathematically speaking, ash performs the computation floor(integer*2^count). Logically, ash moves all of the bits in integer to the left, adding zero-bits at the right, or moves them to the right, discarding bits.

+ash is defined to behave as if integer were represented in two's complement form, regardless of how integers are represented internally.

Examples:

+ +

+ (ash 16 1) =>  32
+ (ash 16 0) =>  16
+ (ash 16 -1) =>  8
+ (ash -100000000000000000000000000000000 -100) =>  -79
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if integer is not an integer. Should signal an error of type type-error if count is not an integer. Might signal arithmetic-error.

+

See Also: None. +

+

Notes:

+

+

+ (logbitp j (ash n k))
+ ==  (and (>= j k) (logbitp (- j k) n))
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_asin_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_asin_.htm new file mode 100644 index 00000000..790d8a80 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_asin_.htm @@ -0,0 +1,113 @@ + + + +CLHS: Function ASIN, ACOS, ATAN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ASIN, ACOS, ATAN

+

Syntax:

+

+ +asin number => radians

+ +acos number => radians

+ +atan number1 &optional number2 => radians

+

+

Arguments and Values:

+

+number---a number.

+number1---a number if number2 is not supplied, or a real if number2 is supplied.

+number2---a real.

+radians---a number (of radians).

+

Description:

+

+asin, acos, and atan compute the arc sine, arc cosine, and arc tangent respectively.

+The arc sine, arc cosine, and arc tangent (with only number1 supplied) functions can be defined mathematically for number or number1 specified as x as in the next figure.

+ 

+Function     Definition                         
+Arc sine     -i log  (ix+ sqrt(1-x^2) )         
+Arc cosine   (<PI>/2) - arcsin  x               
+Arc tangent  -i log  ((1+ix) sqrt(1/(1+x^2)) )  
+
+

Figure 12-14. Mathematical definition of arc sine, arc cosine, and arc tangent

+These formulae are mathematically correct, assuming completely accurate computation. They are not necessarily the simplest ones for real-valued computations.

+If both number1 and number2 are supplied for atan, the result is the arc tangent of number1/number2. The value of atan is always between -<PI> (exclusive) and <PI> (inclusive) when minus zero is not supported. The range of the two-argument arc tangent when minus zero is supported includes -<PI>.

+For a real number1, the result is a real and lies between -<PI>/2 and <PI>/2 (both exclusive). number1 can be a complex if number2 is not supplied. If both are supplied, number2 can be zero provided number1 is not zero.

+The following definition for arc sine determines the range and branch cuts:

+

arcsin z = -i log (iz+sqrt(1-z^2))

+The branch cut for the arc sine function is in two pieces: one along the negative real axis to the left of -1 (inclusive), continuous with quadrant II, and one along the positive real axis to the right of 1 (inclusive), continuous with quadrant IV. The range is that strip of the complex plane containing numbers whose real part is between -<PI>/2 and <PI>/2. A number with real part equal to -<PI>/2 is in the range if and only if its imaginary part is non-negative; a number with real part equal to <PI>/2 is in the range if and only if its imaginary part is non-positive.

+The following definition for arc cosine determines the range and branch cuts:

+

+

arccos z = <PI>/2- arcsin z

+or, which are equivalent,

+

arccos z = -i log (z+i sqrt(1-z^2))

+

arccos z = 2 log (sqrt((1+z)/2) + i sqrt((1-z)/2))/i

+The branch cut for the arc cosine function is in two pieces: one along the negative real axis to the left of -1 (inclusive), continuous with quadrant II, and one along the positive real axis to the right of 1 (inclusive), continuous with quadrant IV. This is the same branch cut as for arc sine. The range is that strip of the complex plane containing numbers whose real part is between 0 and <PI>. A number with real part equal to 0 is in the range if and only if its imaginary part is non-negative; a number with real part equal to <PI> is in the range if and only if its imaginary part is non-positive.

+The following definition for (one-argument) arc tangent determines the range and branch cuts:

+

arctan z = log (1+iz) - log (1-iz)/(2i)

+Beware of simplifying this formula; ``obvious'' simplifications are likely to alter the branch cuts or the values on the branch cuts incorrectly. The branch cut for the arc tangent function is in two pieces: one along the positive imaginary axis above i (exclusive), continuous with quadrant II, and one along the negative imaginary axis below -i (exclusive), continuous with quadrant IV. The points i and -i are excluded from the domain. The range is that strip of the complex plane containing numbers whose real part is between -<PI>/2 and <PI>/2. A number with real part equal to -<PI>/2 is in the range if and only if its imaginary part is strictly positive; a number with real part equal to <PI>/2 is in the range if and only if its imaginary part is strictly negative. Thus the range of arc tangent is identical to that of arc sine with the points -<PI>/2 and <PI>/2 excluded.

+For atan, the signs of number1 (indicated as x) and number2 (indicated as y) are used to derive quadrant information. The next figure details various special cases. The asterisk (*) indicates that the entry in the figure applies to implementations that support minus zero.

+ 

+y Condition  x Condition  Cartesian locus  Range of result         
+y = 0        x > 0        Positive x-axis  0                       
+* y = +0     x > 0        Positive x-axis  +0                      
+* y = -0     x > 0        Positive x-axis  -0                      
+y > 0        x > 0        Quadrant I       0 < result< <PI>/2      
+y > 0        x = 0        Positive y-axis  <PI>/2                  
+y > 0        x < 0        Quadrant II      <PI>/2 < result< <PI>   
+y = 0        x < 0        Negative x-axis  <PI>                    
+* y = +0     x < 0        Negative x-axis  +<PI>                   
+* y = -0     x < 0        Negative x-axis  -<PI>                   
+y < 0        x < 0        Quadrant III     -<PI>< result< -<PI>/2  
+y < 0        x = 0        Negative y-axis  -<PI>/2                 
+y < 0        x > 0        Quadrant IV      -<PI>/2 < result< 0     
+y = 0        x = 0        Origin           undefined consequences  
+* y = +0     x = +0       Origin           +0                      
+* y = -0     x = +0       Origin           -0                      
+* y = +0     x = -0       Origin           +<PI>                   
+* y = -0     x = -0       Origin           -<PI>                   
+
+

Figure 12-15. Quadrant information for arc tangent

+

Examples:

+

+ +

+ (asin 0) =>  0.0 
+ (acos #c(0 1))  =>  #C(1.5707963267948966 -0.8813735870195432)
+ (/ (atan 1 (sqrt 3)) 6)  =>  0.087266 
+ (atan #c(0 2)) =>  #C(-1.5707964 0.54930615)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+acos and asin should signal an error of type type-error if number is not a number. atan should signal type-error if one argument is supplied and that argument is not a number, or if two arguments are supplied and both of those arguments are not reals.

+acos, asin, and atan might signal arithmetic-error.

+

See Also:

+

+log, sqrt, Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes:

+

+The result of either asin or acos can be a complex even if number is not a complex; this occurs when the absolute value of number is greater than one.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_assocc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_assocc.htm new file mode 100644 index 00000000..8ab0c764 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_assocc.htm @@ -0,0 +1,101 @@ + + + +CLHS: Function ASSOC, ASSOC-IF, ASSOC-IF-NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ASSOC, ASSOC-IF, ASSOC-IF-NOT

+

Syntax:

+

+ +assoc item alist &key key test test-not => entry

+

+

+ +assoc-if predicate alist &key key => entry

+ +assoc-if-not predicate alist &key key => entry

+

+

+

Arguments and Values:

+

+item---an object.

+alist---an association list.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+entry---a cons that is an element of alist, or nil.

+

Description:

+

+ assoc, assoc-if, and assoc-if-not return the first cons in alist whose car satisfies the test, or nil if no such cons is found.

+For assoc, assoc-if, and assoc-if-not, if nil appears in alist in place of a pair, it is ignored.

+

Examples:

+

+ +

+ (setq values '((x . 100) (y . 200) (z . 50))) =>  ((X . 100) (Y . 200) (Z . 50))
+ (assoc 'y values) =>  (Y . 200)
+ (rplacd (assoc 'y values) 201) =>  (Y . 201)
+ (assoc 'y values) =>  (Y . 201)
+ (setq alist '((1 . "one")(2 . "two")(3 . "three"))) 
+=>  ((1 . "one") (2 . "two") (3 . "three"))
+ (assoc 2 alist) =>  (2 . "two")
+ (assoc-if #'evenp alist) =>  (2 . "two")
+ (assoc-if-not #'(lambda(x) (< x 3)) alist) =>  (3 . "three")
+ (setq alist '(("one" . 1)("two" . 2))) =>  (("one" . 1) ("two" . 2))
+ (assoc "one" alist) =>  NIL
+ (assoc "one" alist :test #'equalp) =>  ("one" . 1)
+ (assoc "two" alist :key #'(lambda(x) (char x 2))) =>  NIL 
+ (assoc #\o alist :key #'(lambda(x) (char x 2))) =>  ("two" . 2)
+ (assoc 'r '((a . b) (c . d) (r . x) (s . y) (r . z))) =>   (R . X)
+ (assoc 'goo '((foo . bar) (zoo . goo))) =>  NIL
+ (assoc '2 '((1 a b c) (2 b c d) (-7 x y z))) =>  (2 B C D)
+ (setq alist '(("one" . 1) ("2" . 2) ("three" . 3)))
+=>  (("one" . 1) ("2" . 2) ("three" . 3))
+ (assoc-if-not #'alpha-char-p alist
+               :key #'(lambda (x) (char x 0))) =>  ("2" . 2)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if alist is not an association list.

+

See Also:

+

+rassoc, find, member, position, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+ The function assoc-if-not is deprecated.

+It is possible to rplacd the result of assoc, provided that it is not nil, in order to ``update'' alist.

+The two expressions

+

+ (assoc item list :test fn)
+
+ and

+

+ (find item list :test fn :key #'car)
+
+ are equivalent in meaning with one exception: if nil appears in alist in place of a pair, and item is nil, find will compute the car of the nil in alist, find that it is equal to item, and return nil, whereas assoc will ignore the nil in alist and continue to search for an actual cons whose car is nil.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_atom.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_atom.htm new file mode 100644 index 00000000..f12833b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_atom.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function ATOM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ATOM

+

Syntax:

+

+ +atom object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type atom; otherwise, returns false.

+

Examples:

+ +

+ (atom 'sss) =>  true
+ (atom (cons 1 2)) =>  false
+ (atom nil) =>  true
+ (atom '()) =>  true
+ (atom 3) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (atom object) ==  (typep object 'atom) ==  (not (consp object))
+ ==  (not (typep object 'cons)) ==  (typep object '(not cons))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boole.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boole.htm new file mode 100644 index 00000000..9b08fc00 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boole.htm @@ -0,0 +1,141 @@ + + + +CLHS: Function BOOLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BOOLE

+

Syntax:

+

+ +boole op integer-1 integer-2 => result-integer

+

+

Arguments and Values:

+

+Op---a bit-wise logical operation specifier.

+integer-1---an integer.

+integer-2---an integer.

+result-integer---an integer.

+

Description:

+

+boole performs bit-wise logical operations on integer-1 and integer-2, which are treated as if they were binary and in two's complement representation.

+The operation to be performed and the return value are determined by op.

+boole returns the values specified for any op in the next figure.

+

+

+Op           Result                                      
+boole-1      integer-1                                   
+boole-2      integer-2                                   
+boole-andc1  and complement of integer-1 with integer-2  
+boole-andc2  and integer-1 with complement of integer-2  
+boole-and    and                                         
+boole-c1     complement of integer-1                     
+boole-c2     complement of integer-2                     
+boole-clr    always 0 (all zero bits)                    
+boole-eqv    equivalence (exclusive nor)                 
+boole-ior    inclusive or                                
+boole-nand   not-and                                     
+boole-nor    not-or                                      
+boole-orc1   or complement of integer-1 with integer-2   
+boole-orc2   or integer-1 with complement of integer-2   
+boole-set    always -1 (all one bits)                    
+boole-xor    exclusive or                                
+
+

Figure 12-17. Bit-Wise Logical Operations

+

Examples:

+

+

+ (boole boole-ior 1 16) =>  17
+ (boole boole-and -2 5) =>  4
+ (boole boole-eqv 17 15) =>  -31
+
+;;; These examples illustrate the result of applying BOOLE and each
+;;; of the possible values of OP to each possible combination of bits.
+ (progn
+   (format t "~&Results of (BOOLE <op> #b0011 #b0101) ...~
+           ~%---Op-------Decimal-----Binary----Bits---~%")
+   (dolist (symbol '(boole-1     boole-2    boole-and  boole-andc1
+                     boole-andc2 boole-c1   boole-c2   boole-clr
+                     boole-eqv   boole-ior  boole-nand boole-nor
+                     boole-orc1  boole-orc2 boole-set  boole-xor))
+     (let ((result (boole (symbol-value symbol) #b0011 #b0101)))
+       (format t "~& ~A~13T~3,' D~23T~:*~5,' B~31T ...~4,'0B~%" 
+               symbol result (logand result #b1111)))))
+>>  Results of (BOOLE <op> #b0011 #b0101) ...
+>>  ---Op-------Decimal-----Binary----Bits---
+>>   BOOLE-1       3          11    ...0011
+>>   BOOLE-2       5         101    ...0101
+>>   BOOLE-AND     1           1    ...0001
+>>   BOOLE-ANDC1   4         100    ...0100
+>>   BOOLE-ANDC2   2          10    ...0010
+>>   BOOLE-C1     -4        -100    ...1100
+>>   BOOLE-C2     -6        -110    ...1010
+>>   BOOLE-CLR     0           0    ...0000
+>>   BOOLE-EQV    -7        -111    ...1001
+>>   BOOLE-IOR     7         111    ...0111
+>>   BOOLE-NAND   -2         -10    ...1110
+>>   BOOLE-NOR    -8       -1000    ...1000
+>>   BOOLE-ORC1   -3         -11    ...1101
+>>   BOOLE-ORC2   -5        -101    ...1011
+>>   BOOLE-SET    -1          -1    ...1111
+>>   BOOLE-XOR     6         110    ...0110
+=>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its first argument is not a bit-wise logical operation specifier or if any subsequent argument is not an integer.

+

See Also:

+

+logand

+

Notes:

+

+In general,

+

+ (boole boole-and x y) ==  (logand x y)
+
+

+Programmers who would prefer to use numeric indices rather than bit-wise logical operation specifiers can get an equivalent effect by a technique such as the following:

+

+;; The order of the values in this `table' are such that
+;; (logand (boole (elt boole-n-vector n) #b0101 #b0011) #b1111) => n
+ (defconstant boole-n-vector
+    (vector boole-clr   boole-and  boole-andc1 boole-2
+            boole-andc2 boole-1    boole-xor   boole-ior
+            boole-nor   boole-eqv  boole-c1    boole-orc1
+            boole-c2    boole-orc2 boole-nand  boole-set))
+=>  BOOLE-N-VECTOR
+ (proclaim '(inline boole-n))
+=>  implementation-dependent
+ (defun boole-n (n integer &rest more-integers)
+   (apply #'boole (elt boole-n-vector n) integer more-integers))
+=>  BOOLE-N
+ (boole-n #b0111 5 3) =>  7
+ (boole-n #b0001 5 3) =>  1
+ (boole-n #b1101 5 3) =>  -3
+ (loop for n from #b0000 to #b1111 collect (boole-n n 5 3))
+=>  (0 1 2 3 4 5 6 7 -8 -7 -6 -5 -4 -3 -2 -1)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boundp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boundp.htm new file mode 100644 index 00000000..956b0e32 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_boundp.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function BOUNDP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BOUNDP

+

Syntax:

+

+ +boundp symbol => generalized-boolean

+

+

Arguments and Values:

+

+symbol---a symbol.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if symbol is bound; otherwise, returns false.

+

Examples:

+

+

+ (setq x 1) =>  1
+ (boundp 'x) =>  true
+ (makunbound 'x) =>  X
+ (boundp 'x) =>  false
+ (let ((x 2)) (boundp 'x)) =>  false
+ (let ((x 2)) (declare (special x)) (boundp 'x)) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+set, setq, symbol-value, makunbound

+

Notes:

+

+The function bound determines only whether a symbol has a value in the global environment; any lexical bindings are ignored.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_break.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_break.htm new file mode 100644 index 00000000..82b20b65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_break.htm @@ -0,0 +1,83 @@ + + + +CLHS: Function BREAK + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BREAK

+

Syntax:

+

+ +break &optional format-control &rest format-arguments => nil

+

+

Arguments and Values:

+

+ format-control---a format control. The default is implementation-dependent.

+format-arguments---format arguments for the format-control.

+

Description:

+

+break formats format-control and format-arguments and then goes directly into the debugger without allowing any possibility of interception by programmed error-handling facilities.

+If the continue restart is used while in the debugger, break immediately returns nil without taking any unusual recovery action.

+ break binds *debugger-hook* to nil before attempting to enter the debugger.

+

Examples:

+

+

+ (break "You got here with arguments: ~:S." '(FOO 37 A))
+>>  BREAK: You got here with these arguments: FOO, 37, A.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Return from BREAK.
+>>   2: Top level.
+>>  Debug> :CONTINUE 1
+>>  Return from BREAK.
+=>  NIL
+ 
+
+

+

Side Effects:

+

+The debugger is entered.

+

Affected By:

+

+*debug-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+error, invoke-debugger.

+

Notes:

+

+break is used as a way of inserting temporary debugging ``breakpoints'' in a program, not as a way of signaling errors. For this reason, break does not take the continue-format-control argument that cerror takes. This and the lack of any possibility of interception by condition handling are the only program-visible differences between break and cerror.

+The user interface aspects of break and cerror are permitted to vary more widely, in order to accomodate the interface needs of the implementation. For example, it is permissible for a Lisp read-eval-print loop to be entered by break rather than the conventional debugger.

+break could be defined by:

+ +

+ (defun break (&optional (format-control "Break") &rest format-arguments)
+   (with-simple-restart (continue "Return from BREAK.")
+     (let ((*debugger-hook* nil))
+       (invoke-debugger
+           (make-condition 'simple-condition
+                           :format-control format-control
+                           :format-arguments format-arguments))))
+   nil)
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_broadc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_broadc.htm new file mode 100644 index 00000000..30b84a64 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_broadc.htm @@ -0,0 +1,51 @@ + + + +CLHS: Function BROADCAST-STREAM-STREAMS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BROADCAST-STREAM-STREAMS

+

+

Syntax:

+

+ +broadcast-stream-streams broadcast-stream => streams

+

+

Arguments and Values:

+

+broadcast-stream---a broadcast stream.

+streams---a list of streams.

+

Description:

+

+Returns a list of output streams that constitute all the streams to which the broadcast-stream is broadcasting.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_and.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_and.htm new file mode 100644 index 00000000..0fee731d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_and.htm @@ -0,0 +1,112 @@ + + + +CLHS: Function BIT-AND, BIT-ANDC1, BIT-ANDC2... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR

+

Syntax:

+

+ +bit-and bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-andc1 bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-andc2 bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-eqv bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-ior bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-nand bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-nor bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-orc1 bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-orc2 bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+ +bit-xor bit-array1 bit-array2 &optional opt-arg => resulting-bit-array

+

+ +bit-not bit-array &optional opt-arg => resulting-bit-array

+

+

Arguments and Values:

+

+bit-array, bit-array1, bit-array2---a bit array.

+Opt-arg---a bit array, or t, or nil. The default is nil.

+Bit-array, bit-array1, bit-array2, and opt-arg (if an array) must all be of the same rank and dimensions.

+resulting-bit-array---a bit array.

+

Description:

+

+These functions perform bit-wise logical operations on bit-array1 and bit-array2 and return an array of matching rank and dimensions, such that any given bit of the result is produced by operating on corresponding bits from each of the arguments.

+In the case of bit-not, an array of rank and dimensions matching bit-array is returned that contains a copy of bit-array with all the bits inverted.

+If opt-arg is of type (array bit) the contents of the result are destructively placed into opt-arg. If opt-arg is the symbol t, bit-array or bit-array1 is replaced with the result; if opt-arg is nil or omitted, a new array is created to contain the result.

+The next figure indicates the logical operation performed by each of the functions.

+ 

+                                                                                                       
+Function                                                 Operation                                     
+----------
+                                                                                                       
+                                                         
+bit-and                                                  and                                           
+bit-eqv                                                  equivalence (exclusive nor)                   
+bit-not                                                  complement                                    
+bit-ior                                                  inclusive or                                  
+bit-xor                                                  exclusive or                                  
+bit-nand                                                 complement of bit-array1 and bit-array2       
+bit-nor                                                  complement of bit-array1 or bit-array2        
+bit-andc1                                                and complement of bit-array1 with bit-array2  
+bit-andc2                                                and bit-array1 with complement of bit-array2  
+bit-orc1                                                 or complement of bit-array1 with bit-array2   
+bit-orc2                                                 or bit-array1 with complement of bit-array2   
+                                                                                                       
+Figure 15-4.  Bit-wise Logical Operations on Bit Arrays  
+
+

+

Examples:

+ +

+ (bit-and (setq ba #*11101010) #*01101011) =>  #*01101010
+ (bit-and #*1100 #*1010) =>  #*1000      
+ (bit-andc1 #*1100 #*1010) =>  #*0010
+ (setq rba (bit-andc2 ba #*00110011 t)) =>  #*11001000
+ (eq rba ba) =>  true
+ (bit-not (setq ba #*11101010)) =>  #*00010101
+ (setq rba (bit-not ba 
+                     (setq tba (make-array 8 
+                                           :element-type 'bit))))
+=>  #*00010101
+ (equal rba tba) =>  true
+ (bit-xor #*1100 #*1010) =>  #*0110
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+lognot, logand

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_sb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_sb.htm new file mode 100644 index 00000000..52ff2c46 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_sb.htm @@ -0,0 +1,72 @@ + + + +CLHS: Accessor BIT, SBIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor BIT, SBIT

+

Syntax:

+

+ +bit bit-array &rest subscripts => bit

+ +sbit bit-array &rest subscripts => bit

+ +(setf (bit bit-array &rest subscripts) new-bit)

+ +(setf (sbit bit-array &rest subscripts) new-bit)

+

+

Arguments and Values:

+

+bit-array---for bit, a bit array; for sbit, a simple bit array.

+subscripts---a list of valid array indices for the bit-array.

+bit---a bit.

+

Description:

+

+bit and sbit access the bit-array element specified by subscripts.

+These functions ignore the fill pointer when accessing elements.

+

Examples:

+

+

+ (bit (setq ba (make-array 8 
+                            :element-type 'bit 
+                            :initial-element 1))
+       3) =>  1
+ (setf (bit ba 3) 0) =>  0
+ (bit ba 3) =>  0
+ (sbit ba 5) =>  1
+ (setf (sbit ba 5) 1) =>  1
+ (sbit ba 5) =>  1
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+aref, Section 3.2.1 (Compiler Terminology)

+

Notes:

+

+bit and sbit are like aref except that they require arrays to be a bit array and a simple bit array, respectively.

+bit and sbit, unlike char and schar, allow the first argument to be an array of any rank.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_vec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_vec.htm new file mode 100644 index 00000000..c330ffa2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_bt_vec.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function BIT-VECTOR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BIT-VECTOR-P

+

Syntax:

+

+ +bit-vector-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type bit-vector; otherwise, returns false.

+

Examples:

+

+

+ (bit-vector-p (make-array 6 
+                           :element-type 'bit 
+                           :fill-pointer t)) =>  true
+ (bit-vector-p #*) =>  true
+ (bit-vector-p (make-array 6)) =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+typep

+

Notes:

+

+

+ (bit-vector-p object) ==  (typep object 'bit-vector)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_butlas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_butlas.htm new file mode 100644 index 00000000..9a1e61af --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_butlas.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function BUTLAST, NBUTLAST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BUTLAST, NBUTLAST

+

Syntax:

+

+ +butlast list &optional n => result-list

+ +nbutlast list &optional n => result-list

+

+

Arguments and Values:

+

+list---a list, which might be a dotted list but must not be a circular list.

+ n---a non-negative integer.

+result-list---a list.

+

Description:

+

+butlast returns a copy of list from which the last n conses have been omitted. If n is not supplied, its value is 1. If there are fewer than n conses in list, nil is returned and, in the case of nbutlast, list is not modified.

+nbutlast is like butlast, but nbutlast may modify list. It changes the cdr of the cons n+1 from the end of the list to nil.

+

Examples:

+ +

+ (setq lst '(1 2 3 4 5 6 7 8 9)) =>  (1 2 3 4 5 6 7 8 9)
+ (butlast lst) =>  (1 2 3 4 5 6 7 8)
+ (butlast lst 5) =>  (1 2 3 4)
+ (butlast lst (+ 5 5)) =>  NIL
+ lst =>  (1 2 3 4 5 6 7 8 9)
+ (nbutlast lst 3) =>  (1 2 3 4 5 6)
+ lst =>  (1 2 3 4 5 6)
+ (nbutlast lst 99) =>  NIL
+ lst =>  (1 2 3 4 5 6)
+ (butlast '(a b c d)) =>  (A B C)
+ (butlast '((a b) (c d))) =>  ((A B))
+ (butlast '(a)) =>  NIL
+ (butlast nil) =>  NIL
+ (setq foo (list 'a 'b 'c 'd)) =>  (A B C D)
+ (nbutlast foo) =>  (A B C)
+ foo =>  (A B C)
+ (nbutlast (list 'a)) =>  NIL
+ (nbutlast '()) =>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+ Should signal an error of type type-error if list is not a proper list or a dotted list. Should signal an error of type type-error if n is not a non-negative integer.

+

See Also: None. +

+

Notes:

+

+ +

+ (butlast list n) ==  (ldiff list (last list n))
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_by_by.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_by_by.htm new file mode 100644 index 00000000..bb30338e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_by_by.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function BYTE, BYTE-SIZE, BYTE-POSITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function BYTE, BYTE-SIZE, BYTE-POSITION

+

Syntax:

+

+ +byte size position => bytespec

+

+ +byte-size bytespec => size

+ +byte-position bytespec => position

+

+

Arguments and Values:

+

+size, position---a non-negative integer.

+bytespec---a byte specifier.

+

Description:

+

+byte returns a byte specifier that indicates a byte of width size and whose bits have weights 2^position + size - 1 through 2^position, and whose representation is implementation-dependent.

+byte-size returns the number of bits specified by bytespec.

+byte-position returns the position specified by bytespec.

+

Examples:

+

+

+ (setq b (byte 100 200)) =>  #<BYTE-SPECIFIER size 100 position 200>
+ (byte-size b) =>  100
+ (byte-position b) =>  200
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ldb, dpb

+

Notes:

+

+

+ (byte-size (byte j k)) ==  j
+ (byte-position (byte j k)) ==  k
+
+

+A byte of size of 0 is permissible; it refers to a byte of width zero. For example,

+

+ (ldb (byte 0 3) #o7777) =>  0
+ (dpb #o7777 (byte 0 3) 0) =>  0
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_call_n.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_call_n.htm new file mode 100644 index 00000000..a5003e19 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_call_n.htm @@ -0,0 +1,60 @@ + + + +CLHS: Local Function CALL-NEXT-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Local Function CALL-NEXT-METHOD

+

Syntax:

+

+ +call-next-method &rest args => result*

+

+

Arguments and Values:

+

+arg---an object.

+results---the values returned by the method it calls.

+

Description:

+

+The function call-next-method can be used within the body forms (but not the lambda list) of a method defined by a method-defining form to call the next method.

+If there is no next method, the generic function no-next-method is called.

+The type of method combination used determines which methods can invoke call-next-method. The standard method combination type allows call-next-method to be used within primary methods and around methods. For generic functions using a type of method combination defined by the short form of define-method-combination, call-next-method can be used in around methods only.

+When call-next-method is called with no arguments, it passes the current method's original arguments to the next method. Neither argument defaulting, nor using setq, nor rebinding variables with the same names as parameters of the method affects the values call-next-method passes to the method it calls.

+ When call-next-method is called with arguments, the next method is called with those arguments.

+If call-next-method is called with arguments but omits optional arguments, the next method called defaults those arguments.

+The function call-next-method returns any values that are returned by the next method.

+The function call-next-method has lexical scope and indefinite extent and can only be used within the body of a method defined by a method-defining form.

+ Whether or not call-next-method is fbound in the global environment is implementation-dependent; however, the restrictions on redefinition and shadowing of call-next-method are the same as for symbols in the COMMON-LISP package which are fbound in the global environment. The consequences of attempting to use call-next-method outside of a method-defining form are undefined.

+

Examples: None. +

+

Affected By:

+

+defmethod, call-method, define-method-combination.

+

Exceptional Situations:

+

+ When providing arguments to call-next-method, the following rule must be satisfied or an error of type error should be signaled: the ordered set of applicable methods for a changed set of arguments for call-next-method must be the same as the ordered set of applicable methods for the original arguments to the generic function. Optimizations of the error checking are possible, but they must not change the semantics of call-next-method.

+

See Also:

+

+define-method-combination, defmethod, next-method-p, no-next-method, call-method, Section 7.6.6 (Method Selection and Combination), Section 7.6.6.2 (Standard Method Combination), Section 7.6.6.4 (Built-in Method Combination Types)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_car_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_car_c.htm new file mode 100644 index 00000000..0fb031d3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_car_c.htm @@ -0,0 +1,229 @@ + + + +CLHS: Accessor CAR, CDR, CAAR, CADR, CDAR... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR

+

Syntax:

+

+ +car x => object

+ +cdr x => object

+ +caar x => object

+ +cadr x => object

+ +cdar x => object

+ +cddr x => object

+ +caaar x => object

+ +caadr x => object

+ +cadar x => object

+ +caddr x => object

+ +cdaar x => object

+ +cdadr x => object

+ +cddar x => object

+ +cdddr x => object

+ +caaaar x => object

+ +caaadr x => object

+ +caadar x => object

+ +caaddr x => object

+ +cadaar x => object

+ +cadadr x => object

+ +caddar x => object

+ +cadddr x => object

+ +cdaaar x => object

+ +cdaadr x => object

+ +cdadar x => object

+ +cdaddr x => object

+ +cddaar x => object

+ +cddadr x => object

+ +cdddar x => object

+ +cddddr x => object

+ +(setf (car x) new-object)

+ +(setf (cdr x) new-object)

+ +(setf (caar x) new-object)

+ +(setf (cadr x) new-object)

+ +(setf (cdar x) new-object)

+ +(setf (cddr x) new-object)

+ +(setf (caaar x) new-object)

+ +(setf (caadr x) new-object)

+ +(setf (cadar x) new-object)

+ +(setf (caddr x) new-object)

+ +(setf (cdaar x) new-object)

+ +(setf (cdadr x) new-object)

+ +(setf (cddar x) new-object)

+ +(setf (cdddr x) new-object)

+ +(setf (caaaar x) new-object)

+ +(setf (caaadr x) new-object)

+ +(setf (caadar x) new-object)

+ +(setf (caaddr x) new-object)

+ +(setf (cadaar x) new-object)

+ +(setf (cadadr x) new-object)

+ +(setf (caddar x) new-object)

+ +(setf (cadddr x) new-object)

+ +(setf (cdaaar x) new-object)

+ +(setf (cdaadr x) new-object)

+ +(setf (cdadar x) new-object)

+ +(setf (cdaddr x) new-object)

+ +(setf (cddaar x) new-object)

+ +(setf (cddadr x) new-object)

+ +(setf (cdddar x) new-object)

+ +(setf (cddddr x) new-object)

+

+

Pronunciation:

+

+cadr: ['ka,duhr]

+caddr: ['kaduh,duhr] or ['ka,dduhr]

+cdr: ['k,duhr]

+cddr: ['kduh,duhr] or ['kuh,dduhr]

+

Arguments and Values:

+

+x---a list.

+object---an object.

+new-object---an object.

+

Description:

+

+If x is a cons, car returns the car of that cons. If x is nil, car returns nil.

+If x is a cons, cdr returns the cdr of that cons. If x is nil, cdr returns nil.

+Functions are provided which perform compositions of up to four car and cdr operations. Their names consist of a C, followed by two, three, or four occurrences of A or D, and finally an R. The series of A's and D's in each function's name is chosen to identify the series of car and cdr operations that is performed by the function. The order in which the A's and D's appear is the inverse of the order in which the corresponding operations are performed. The next figure defines the relationships precisely.

+

+This place ...  Is equivalent to this place ...  
+(caar x)        (car (car x))                    
+(cadr x)        (car (cdr x))                    
+(cdar x)        (cdr (car x))                    
+(cddr x)        (cdr (cdr x))                    
+(caaar x)       (car (car (car x)))              
+(caadr x)       (car (car (cdr x)))              
+(cadar x)       (car (cdr (car x)))              
+(caddr x)       (car (cdr (cdr x)))              
+(cdaar x)       (cdr (car (car x)))              
+(cdadr x)       (cdr (car (cdr x)))              
+(cddar x)       (cdr (cdr (car x)))              
+(cdddr x)       (cdr (cdr (cdr x)))              
+(caaaar x)      (car (car (car (car x))))        
+(caaadr x)      (car (car (car (cdr x))))        
+(caadar x)      (car (car (cdr (car x))))        
+(caaddr x)      (car (car (cdr (cdr x))))        
+(cadaar x)      (car (cdr (car (car x))))        
+(cadadr x)      (car (cdr (car (cdr x))))        
+(caddar x)      (car (cdr (cdr (car x))))        
+(cadddr x)      (car (cdr (cdr (cdr x))))        
+(cdaaar x)      (cdr (car (car (car x))))        
+(cdaadr x)      (cdr (car (car (cdr x))))        
+(cdadar x)      (cdr (car (cdr (car x))))        
+(cdaddr x)      (cdr (car (cdr (cdr x))))        
+(cddaar x)      (cdr (cdr (car (car x))))        
+(cddadr x)      (cdr (cdr (car (cdr x))))        
+(cdddar x)      (cdr (cdr (cdr (car x))))        
+(cddddr x)      (cdr (cdr (cdr (cdr x))))        
+
+

Figure 14-6. CAR and CDR variants

+setf can also be used with any of these functions to change an existing component of x, but setf will not make new components. So, for example, the car of a cons can be assigned with setf of car, but the car of nil cannot be assigned with setf of car. Similarly, the car of the car of a cons whose car is a cons can be assigned with setf of caar, but neither nilnor a cons whose car is nil can be assigned with setf of caar.

+ The argument x is permitted to be a dotted list or a circular list.

+

Examples:

+

+

+ (car nil) =>  NIL  
+ (cdr '(1 . 2)) =>  2
+ (cdr '(1 2)) =>  (2)
+ (cadr '(1 2)) =>  2 
+ (car '(a b c)) =>  A
+ (cdr '(a b c)) =>  (B C)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+The functions car and cdr should signal type-error if they receive an argument which is not a list. The other functions (caar, cadr, ... cddddr) should behave for the purpose of error checking as if defined by appropriate calls to car and cdr.

+

See Also:

+

+rplaca, first, rest

+

Notes:

+

+The car of a cons can also be altered by using rplaca, and the cdr of a cons can be altered by using rplacd.

+

+(car x)    ==  (first x)
+(cadr x)   ==  (second x) ==  (car (cdr x))
+(caddr x)  ==  (third x)  ==  (car (cdr (cdr x)))
+(cadddr x) ==  (fourth x) ==  (car (cdr (cdr (cdr x))))
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cell_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cell_e.htm new file mode 100644 index 00000000..5f64ff71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cell_e.htm @@ -0,0 +1,53 @@ + + + +CLHS: Function CELL-ERROR-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CELL-ERROR-NAME

+

+

Syntax:

+

+ +cell-error-name condition => name

+

+

Arguments and Values:

+

+condition---a condition of type cell-error.

+name---an object.

+

Description:

+

+Returns the name of the offending cell involved in the situation represented by condition.

+The nature of the result depends on the specific type of condition. For example, if the condition is of type unbound-variable, the result is the name of the unbound variable which was being accessed, if the condition is of type undefined-function, this is the name of the undefined function which was being accessed, and if the condition is of type unbound-slot, this is the name of the slot which was being accessed.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+cell-error, unbound-slot, unbound-variable, undefined-function, Section 9.1 (Condition System Concepts)

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cerror.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cerror.htm new file mode 100644 index 00000000..e04ad15a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cerror.htm @@ -0,0 +1,170 @@ + + + +CLHS: Function CERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CERROR

+

Syntax:

+

+ +cerror continue-format-control datum &rest arguments => nil

+

+

Arguments and Values:

+

+ Continue-format-control---a format control.

+

+datum, arguments---designators for a condition of default type simple-error.

+

Description:

+

+cerror effectively invokes error on the condition named by datum. As with any function that implicitly calls error, if the condition is not handled, (invoke-debugger condition) is executed. While signaling is going on, and while in the debugger if it is reached, it is possible to continue code execution (i.e., to return from cerror) using the continue restart.

+If datum is a condition, arguments can be supplied, but are used only in conjunction with the continue-format-control.

+

Examples:

+

+

+ (defun real-sqrt (n)
+   (when (minusp n)
+     (setq n (- n))
+     (cerror "Return sqrt(~D) instead." "Tried to take sqrt(-~D)." n))
+   (sqrt n))
+
+ (real-sqrt 4)
+=>  2.0
+
+ (real-sqrt -9)
+>>  Correctable error in REAL-SQRT: Tried to take sqrt(-9).
+>>  Restart options:
+>>   1: Return sqrt(9) instead.
+>>   2: Top level.
+>>  Debug> :continue 1
+=>  3.0
+ 
+ (define-condition not-a-number (error)
+   ((argument :reader not-a-number-argument :initarg :argument))
+   (:report (lambda (condition stream)
+              (format stream "~S is not a number." 
+                      (not-a-number-argument condition)))))
+ 
+ (defun assure-number (n)
+   (loop (when (numberp n) (return n))
+         (cerror "Enter a number."
+                 'not-a-number :argument n)
+         (format t "~&Type a number: ")
+         (setq n (read))
+         (fresh-line)))
+
+ (assure-number 'a)
+>>  Correctable error in ASSURE-NUMBER: A is not a number.
+>>  Restart options:
+>>   1: Enter a number.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Type a number: 1/2
+=>  1/2
+
+ (defun assure-large-number (n)
+   (loop (when (and (numberp n) (> n 73)) (return n))
+         (cerror "Enter a number~:[~; a bit larger than ~D~]."
+                 "~*~A is not a large number." 
+                 (numberp n) n)
+         (format t "~&Type a large number: ")
+         (setq n (read))
+         (fresh-line)))
+ 
+ (assure-large-number 10000)
+=>  10000
+
+ (assure-large-number 'a)
+>>  Correctable error in ASSURE-LARGE-NUMBER: A is not a large number.
+>>  Restart options:
+>>   1: Enter a number.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Type a large number: 88
+=>  88
+
+ (assure-large-number 37)
+>>  Correctable error in ASSURE-LARGE-NUMBER: 37 is not a large number.
+>>  Restart options:
+>>   1: Enter a number a bit larger than 37.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Type a large number: 259
+=>  259
+ 
+ (define-condition not-a-large-number (error)
+   ((argument :reader not-a-large-number-argument :initarg :argument))
+   (:report (lambda (condition stream)
+              (format stream "~S is not a large number." 
+                      (not-a-large-number-argument condition)))))
+ 
+ (defun assure-large-number (n)
+   (loop (when (and (numberp n) (> n 73)) (return n))
+         (cerror "Enter a number~3*~:[~; a bit larger than ~*~D~]."
+                 'not-a-large-number
+                 :argument n 
+                 :ignore (numberp n)
+                 :ignore n
+                 :allow-other-keys t)
+         (format t "~&Type a large number: ")
+         (setq n (read))
+         (fresh-line)))
+ 
+
+ (assure-large-number 'a)
+>>  Correctable error in ASSURE-LARGE-NUMBER: A is not a large number.
+>>  Restart options:
+>>   1: Enter a number.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Type a large number: 88
+=>  88
+ 
+ (assure-large-number 37)
+>>  Correctable error in ASSURE-LARGE-NUMBER: A is not a large number.
+>>  Restart options:
+>>   1: Enter a number a bit larger than 37.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Type a large number: 259
+=>  259
+
+

+

Affected By:

+

+*break-on-signals*.

+Existing handler bindings.

+

Exceptional Situations: None. +

+

See Also:

+

+error, format, handler-bind, *break-on-signals*, simple-type-error

+

Notes:

+

+If datum is a condition type rather than a string, the format directive ~* may be especially useful in the continue-format-control in order to ignore the keywords in the initialization argument list. For example:

+

+(cerror "enter a new value to replace ~*~s" 
+        'not-a-number
+        :argument a)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ch.htm new file mode 100644 index 00000000..baa1cf5a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ch.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function CHARACTER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHARACTER

+

Syntax:

+

+ +character character => denoted-character

+

+

Arguments and Values:

+

+ character---a character designator.

+denoted-character---a character.

+

Description:

+

+Returns the character denoted by the character designator.

+

Examples:

+

+

+ (character #\a) =>  #\a
+ (character "a") =>  #\a
+ (character 'a) =>  #\A
+ (character '\a) =>  #\a
+ (character 65.) is an error.
+ (character 'apple) is an error.
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if object is not a character designator.

+

See Also:

+

+coerce

+

Notes:

+

+

+ (character object) ==  (coerce object 'character)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_.htm new file mode 100644 index 00000000..a8b0b7c1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_.htm @@ -0,0 +1,81 @@ + + + +CLHS: Accessor CHAR, SCHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor CHAR, SCHAR

+

Syntax:

+

+ +char string index => character

+ +schar string index => character

+

+ +(setf (char string index) new-character)

+ +(setf (schar string index) new-character)

+

+

Arguments and Values:

+

+string---for char, a string; for schar, a simple string.

+index---a valid array index for the string.

+character, new-character---a character.

+

Description:

+

+char and schar access the element of string specified by index.

+char ignores fill pointers when accessing elements.

+

Examples:

+

+

+ (setq my-simple-string (make-string 6 :initial-element #\A)) =>  "AAAAAA"
+ (schar my-simple-string 4) =>  #\A
+ (setf (schar my-simple-string 4) #\B) =>  #\B
+ my-simple-string =>  "AAAABA"
+ (setq my-filled-string
+       (make-array 6 :element-type 'character
+                     :fill-pointer 5
+                     :initial-contents my-simple-string))
+=>  "AAAAB"
+ (char my-filled-string 4) =>  #\B
+ (char my-filled-string 5) =>  #\A
+ (setf (char my-filled-string 3) #\C) =>  #\C
+ (setf (char my-filled-string 5) #\D) =>  #\D
+ (setf (fill-pointer my-filled-string) 6) =>  6
+ my-filled-string =>  "AAACBD"
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+aref, elt, Section 3.2.1 (Compiler Terminology)

+

Notes:

+

+

+ (char s j) ==  (aref (the string s) j)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_c.htm new file mode 100644 index 00000000..b72b6625 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_c.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function CHAR-CODE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHAR-CODE

+

Syntax:

+

+ +char-code character => code

+

+

Arguments and Values:

+

+character---a character.

+code---a character code.

+

Description:

+

+char-code returns the code attribute of character.

+

Examples:

+

+

+;; An implementation using ASCII character encoding 
+;; might return these values:
+(char-code #\$) =>  36
+(char-code #\a) =>  97
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+char-code-limit

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_i.htm new file mode 100644 index 00000000..6357090f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_i.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function CHAR-INT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHAR-INT

+

Syntax:

+

+ +char-int character => integer

+

+

Arguments and Values:

+

+character---a character.

+integer---a non-negative integer.

+

Description:

+

+ Returns a non-negative integer encoding the character object. The manner in which the integer is computed is implementation-dependent. In contrast to sxhash, the result is not guaranteed to be independent of the particular Lisp image.

+If character has no implementation-defined attributes, the results of char-int and char-code are the same.

+

+ (char= c1 c2) ==  (= (char-int c1) (char-int c2))
+
+ for characters c1 and c2.

+

Examples:

+

+

+ (char-int #\A) =>  65       ; implementation A
+ (char-int #\A) =>  577      ; implementation B
+ (char-int #\A) =>  262145   ; implementation C
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+char-code

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_n.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_n.htm new file mode 100644 index 00000000..5fd8d8b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_n.htm @@ -0,0 +1,76 @@ + + + +CLHS: Function CHAR-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHAR-NAME

+

Syntax:

+

+ +char-name character => name

+

+

Arguments and Values:

+

+character---a character.

+name---a string or nil.

+

Description:

+

+Returns a string that is the name of the character, or nil if the character has no name.

+All non-graphic characters are required to have names unless they have some implementation-defined attribute which is not null. Whether or not other characters have names is implementation-dependent.

+ The standard characters <Newline> and <Space> have the respective names "Newline" and "Space". The semi-standard characters <Tab>, <Page>, <Rubout>, <Linefeed>, <Return>, and <Backspace> (if they are supported by the implementation) have the respective names "Tab", "Page", "Rubout", "Linefeed", "Return", and "Backspace" (in the indicated case, even though name lookup by ``#\'' and by the function name-char is not case sensitive).

+

Examples:

+

+

+ (char-name #\ ) =>  "Space"
+ (char-name #\Space) =>  "Space"
+ (char-name #\Page) =>  "Page"
+
+ (char-name #\a)
+=>  NIL
+OR=>  "LOWERCASE-a"
+OR=>  "Small-A"
+OR=>  "LA01"
+
+ (char-name #\A)
+=>  NIL
+OR=>  "UPPERCASE-A"
+OR=>  "Capital-A"
+OR=>  "LA02"
+
+ ;; Even though its CHAR-NAME can vary, #\A prints as #\A
+ (prin1-to-string (read-from-string (format nil "#\\~A" (or (char-name #\A) "A"))))
+=>  "#\\A"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+name-char, Section 22.1.3.2 (Printing Characters)

+

Notes:

+

+Non-graphic characters having names are written by the Lisp printer as ``#\'' followed by the their name; see Section 22.1.3.2 (Printing Characters).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_u.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_u.htm new file mode 100644 index 00000000..f3137de0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_char_u.htm @@ -0,0 +1,79 @@ + + + +CLHS: Function CHAR-UPCASE, CHAR-DOWNCASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHAR-UPCASE, CHAR-DOWNCASE

+

Syntax:

+

+ +char-upcase character => corresponding-character

+ +char-downcase character => corresponding-character

+

+

Arguments and Values:

+

+character, corresponding-character---a character.

+

Description:

+

+If character is a lowercase character, char-upcase returns the corresponding uppercase character. Otherwise, char-upcase just returns the given character.

+If character is an uppercase character, char-downcase returns the corresponding lowercase character. Otherwise, char-downcase just returns the given character.

+ The result only ever differs from character in its code attribute; all implementation-defined attributes are preserved.

+

Examples:

+

+

+ (char-upcase #\a) =>  #\A
+ (char-upcase #\A) =>  #\A
+ (char-downcase #\a) =>  #\a
+ (char-downcase #\A) =>  #\a
+ (char-upcase #\9) =>  #\9
+ (char-downcase #\9) =>  #\9
+ (char-upcase #\@) =>  #\@
+ (char-downcase #\@) =>  #\@
+ ;; Note that this next example might run for a very long time in 
+ ;; some implementations if CHAR-CODE-LIMIT happens to be very large
+ ;; for that implementation.
+ (dotimes (code char-code-limit)
+   (let ((char (code-char code)))
+     (when char
+       (unless (cond ((upper-case-p char) (char= (char-upcase (char-downcase char)) char))
+                     ((lower-case-p char) (char= (char-downcase (char-upcase char)) char))
+                     (t (and (char= (char-upcase (char-downcase char)) char)
+                             (char= (char-downcase (char-upcase char)) char))))
+         (return char)))))
+=>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+upper-case-p, alpha-char-p, Section 13.1.4.3 (Characters With Case), Section 13.1.10 (Documentation of Implementation-Defined Scripts)

+

Notes:

+

+If the corresponding-char is different than character, then both the character and the corresponding-char have case.

+Since char-equal ignores the case of the characters it compares, the corresponding-character is always the same as character under char-equal.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chareq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chareq.htm new file mode 100644 index 00000000..a67233cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chareq.htm @@ -0,0 +1,129 @@ + + + +CLHS: Function CHAR=, CHAR/=, CHAR<, CHAR>... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP

+

Syntax:

+

+ +char= &rest characters+ => generalized-boolean

+ +char/= &rest characters+ => generalized-boolean

+ +char< &rest characters+ => generalized-boolean

+ +char> &rest characters+ => generalized-boolean

+ +char<= &rest characters+ => generalized-boolean

+ +char>= &rest characters+ => generalized-boolean

+ +char-equal &rest characters+ => generalized-boolean

+ +char-not-equal &rest characters+ => generalized-boolean

+ +char-lessp &rest characters+ => generalized-boolean

+ +char-greaterp &rest characters+ => generalized-boolean

+ +char-not-greaterp &rest characters+ => generalized-boolean

+ +char-not-lessp &rest characters+ => generalized-boolean

+

+

Arguments and Values:

+

+character---a character.

+generalized-boolean---a generalized boolean.

+

Description:

+

+These predicates compare characters.

+char= returns true if all characters are the same; otherwise, it returns false. If two characters differ in any implementation-defined attributes, then they are not char=.

+char/= returns true if all characters are different; otherwise, it returns false.

+char< returns true if the characters are monotonically increasing; otherwise, it returns false. If two characters have identical implementation-defined attributes, then their ordering by char< is consistent with the numerical ordering by the predicate < on their codes.

+char> returns true if the characters are monotonically decreasing; otherwise, it returns false. If two characters have identical implementation-defined attributes, then their ordering by char> is consistent with the numerical ordering by the predicate > on their codes.

+char<= returns true if the characters are monotonically nondecreasing; otherwise, it returns false. If two characters have identical implementation-defined attributes, then their ordering by char<= is consistent with the numerical ordering by the predicate <= on their codes.

+char>= returns true if the characters are monotonically nonincreasing; otherwise, it returns false. If two characters have identical implementation-defined attributes, then their ordering by char>= is consistent with the numerical ordering by the predicate >= on their codes.

+ char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp, and char-not-lessp are similar to char=, char/=, char<, char>, char<=, char>=, respectively, except that they ignore differences in case and might have an implementation-defined behavior for non-simple characters. For example, an implementation might define that char-equal, etc. ignore certain implementation-defined attributes. The effect, if any, of each implementation-defined attribute upon these functions must be specified as part of the definition of that attribute.

+

Examples:

+

+ +

+ (char= #\d #\d) =>  true
+ (char= #\A #\a) =>  false
+ (char= #\d #\x) =>  false
+ (char= #\d #\D) =>  false
+ (char/= #\d #\d) =>  false
+ (char/= #\d #\x) =>  true
+ (char/= #\d #\D) =>  true
+ (char= #\d #\d #\d #\d) =>  true
+ (char/= #\d #\d #\d #\d) =>  false
+ (char= #\d #\d #\x #\d) =>  false
+ (char/= #\d #\d #\x #\d) =>  false
+ (char= #\d #\y #\x #\c) =>  false
+ (char/= #\d #\y #\x #\c) =>  true
+ (char= #\d #\c #\d) =>  false
+ (char/= #\d #\c #\d) =>  false
+ (char< #\d #\x) =>  true
+ (char<= #\d #\x) =>  true
+ (char< #\d #\d) =>  false
+ (char<= #\d #\d) =>  true
+ (char< #\a #\e #\y #\z) =>  true
+ (char<= #\a #\e #\y #\z) =>  true
+ (char< #\a #\e #\e #\y) =>  false
+ (char<= #\a #\e #\e #\y) =>  true
+ (char> #\e #\d) =>  true
+ (char>= #\e #\d) =>  true
+ (char> #\d #\c #\b #\a) =>  true
+ (char>= #\d #\c #\b #\a) =>  true
+ (char> #\d #\d #\c #\a) =>  false
+ (char>= #\d #\d #\c #\a) =>  true
+ (char> #\e #\d #\b #\c #\a) =>  false
+ (char>= #\e #\d #\b #\c #\a) =>  false
+ (char> #\z #\A) =>  implementation-dependent
+ (char> #\Z #\a) =>  implementation-dependent
+ (char-equal #\A #\a) =>  true
+ (stable-sort (list #\b #\A #\B #\a #\c #\C) #'char-lessp)
+=>  (#\A #\a #\b #\B #\c #\C)
+ (stable-sort (list #\b #\A #\B #\a #\c #\C) #'char<)
+=>  (#\A #\B #\C #\a #\b #\c) ;Implementation A
+=>  (#\a #\b #\c #\A #\B #\C) ;Implementation B
+=>  (#\a #\A #\b #\B #\c #\C) ;Implementation C
+=>  (#\A #\a #\B #\b #\C #\c) ;Implementation D
+=>  (#\A #\B #\a #\b #\C #\c) ;Implementation E
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type program-error if at least one character is not supplied.

+

See Also:

+

+Section 2.1 (Character Syntax), Section 13.1.10 (Documentation of Implementation-Defined Scripts)

+

Notes:

+

+If characters differ in their code attribute or any implementation-defined attribute, they are considered to be different by char=.

+There is no requirement that (eq c1 c2) be true merely because (char= c1 c2) is true. While eq can distinguish two characters that char= does not, it is distinguishing them not as characters, but in some sense on the basis of a lower level implementation characteristic. If (eq c1 c2) is true, then (char= c1 c2) is also true. eql and equal compare characters in the same way that char= does.

+The manner in which case is used by char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp, and char-not-lessp implies an ordering for standard characters such that A=a, B=b, and so on, up to Z=z, and furthermore either 9<A or Z<0.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chg_cl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chg_cl.htm new file mode 100644 index 00000000..94eca467 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chg_cl.htm @@ -0,0 +1,103 @@ + + + +CLHS: Standard Generic Function CHANGE-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function CHANGE-CLASS

+

Syntax:

+

+ +change-class instance new-class &key &allow-other-keys => instance

+

+

Method Signatures:

+

+ +change-class (instance standard-object) (new-class standard-class) &rest initargs

+

+ +change-class (instance t) (new-class symbol) &rest initargs

+

+

Arguments and Values:

+

+instance---an object.

+new-class---a class designator.

+ initargs---an initialization argument list.

+

Description:

+

+The generic function change-class changes the class of an instance to new-class. It destructively modifies and returns the instance.

+If in the old class there is any slot of the same name as a local slot in the new-class, the value of that slot is retained. This means that if the slot has a value, the value returned by slot-value after change-class is invoked is eql to the value returned by slot-value before change-class is invoked. Similarly, if the slot was unbound, it remains unbound. The other slots are initialized as described in Section 7.2 (Changing the Class of an Instance).

+After completing all other actions, change-class invokes update-instance-for-different-class. The generic function update-instance-for-different-class can be used to assign values to slots in the transformed instance. See Section 7.2.2 (Initializing Newly Added Local Slots).

+ If the second of the above methods is selected, that method invokes change-class on instance, (find-class new-class), and the initargs.

+

Examples:

+

+

+ 
+ (defclass position () ())
+  
+ (defclass x-y-position (position)
+     ((x :initform 0 :initarg :x)
+      (y :initform 0 :initarg :y)))
+  
+ (defclass rho-theta-position (position)
+     ((rho :initform 0)
+      (theta :initform 0)))
+  
+ (defmethod update-instance-for-different-class :before ((old x-y-position) 
+                                                         (new rho-theta-position)
+                                                         &key)
+   ;; Copy the position information from old to new to make new
+   ;; be a rho-theta-position at the same position as old.
+   (let ((x (slot-value old 'x))
+         (y (slot-value old 'y)))
+     (setf (slot-value new 'rho) (sqrt (+ (* x x) (* y y)))
+           (slot-value new 'theta) (atan y x))))
+  
+;;; At this point an instance of the class x-y-position can be
+;;; changed to be an instance of the class rho-theta-position using
+;;; change-class:
+ 
+ (setq p1 (make-instance 'x-y-position :x 2 :y 0))
+  
+ (change-class p1 'rho-theta-position)
+  
+;;; The result is that the instance bound to p1 is now an instance of
+;;; the class rho-theta-position.   The update-instance-for-different-class
+;;; method performed the initialization of the rho and theta slots based
+;;; on the value of the x and y slots, which were maintained by
+;;; the old instance.
+ 
+
+

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+update-instance-for-different-class, Section 7.2 (Changing the Class of an Instance)

+

Notes:

+

+The generic function change-class has several semantic difficulties. First, it performs a destructive operation that can be invoked within a method on an instance that was used to select that method. When multiple methods are involved because methods are being combined, the methods currently executing or about to be executed may no longer be applicable. Second, some implementations might use compiler optimizations of slot access, and when the class of an instance is changed the assumptions the compiler made might be violated. This implies that a programmer must not use change-class inside a method if any methods for that generic function access any slots, or the results are undefined.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chp.htm new file mode 100644 index 00000000..0ccf05be --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_chp.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function CHARACTERP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CHARACTERP

+

Syntax:

+

+ +characterp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type character; otherwise, returns false.

+

Examples:

+

+

+ (characterp #\a) =>  true
+ (characterp 'a) =>  false
+ (characterp "a") =>  false
+ (characterp 65.) =>  false
+ (characterp #\Newline) =>  true
+ ;; This next example presupposes an implementation 
+ ;; in which #\Rubout is an implementation-defined character.
+ (characterp #\Rubout) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+character (type and function), typep

+

Notes:

+

+

+ (characterp object) ==  (typep object 'character)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cis.htm new file mode 100644 index 00000000..bb4f3767 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cis.htm @@ -0,0 +1,56 @@ + + + +CLHS: Function CIS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CIS

+

Syntax:

+

+ +cis radians => number

+

+

Arguments and Values:

+

+radians---a real.

+number---a complex.

+

Description:

+

+cis returns the value of e^i* radians, which is a complex in which the real part is equal to the cosine of radians, and the imaginary part is equal to the sine of radians.

+

Examples:

+ +

+ (cis 0) =>  #C(1.0 0.0)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clas_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clas_1.htm new file mode 100644 index 00000000..914e19b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clas_1.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function CLASS-OF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CLASS-OF

+

Syntax:

+

+ +class-of object => class

+

+

Arguments and Values:

+

+object---an object.

+class---a class object.

+

Description:

+

+Returns the class of which the object is a direct instance.

+

Examples:

+

+

+ (class-of 'fred) =>  #<BUILT-IN-CLASS SYMBOL 610327300>
+ (class-of 2/3) =>  #<BUILT-IN-CLASS RATIO 610326642>
+ 
+ (defclass book () ()) =>  #<STANDARD-CLASS BOOK 33424745>
+ (class-of (make-instance 'book)) =>  #<STANDARD-CLASS BOOK 33424745>
+ 
+ (defclass novel (book) ()) =>  #<STANDARD-CLASS NOVEL 33424764>
+ (class-of (make-instance 'novel)) =>  #<STANDARD-CLASS NOVEL 33424764>
+
+ (defstruct kons kar kdr) =>  KONS
+ (class-of (make-kons :kar 3 :kdr 4)) =>  #<STRUCTURE-CLASS KONS 250020317>
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-instance, type-of

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_class_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_class_.htm new file mode 100644 index 00000000..75e70ef1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_class_.htm @@ -0,0 +1,57 @@ + + + +CLHS: Standard Generic Function CLASS-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function CLASS-NAME

+

Syntax:

+

+ +class-name class => name

+

+

Method Signatures:

+

+ +class-name (class class)

+

+

Arguments and Values:

+

+class---a class object.

+name---a symbol.

+

Description:

+

+Returns the name of the given class.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+find-class, Section 4.3 (Classes)

+

Notes:

+

+If S is a symbol such that S =(class-name C) and C =(find-class S), then S is the proper name of C. For further discussion, see Section 4.3 (Classes).

+The name of an anonymous class is nil.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clear_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clear_.htm new file mode 100644 index 00000000..391b3a57 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clear_.htm @@ -0,0 +1,90 @@ + + + +CLHS: Function CLEAR-INPUT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CLEAR-INPUT

+

Syntax:

+

+ +clear-input &optional input-stream => nil

+

+

Arguments and Values:

+

+input-stream---an input stream designator. The default is standard input.

+

Description:

+

+Clears any available input from input-stream.

+If clear-input does not make sense for input-stream, then clear-input does nothing.

+

Examples:

+ +

+;; The exact I/O behavior of this example might vary from implementation
+;; to implementation depending on the kind of interactive buffering that
+;; occurs.  (The call to SLEEP here is intended to help even out the 
+;; differences in implementations which do not do line-at-a-time buffering.)
+
+(defun read-sleepily (&optional (clear-p nil) (zzz 0))
+  (list (progn (print '>) (read))
+        ;; Note that input typed within the first ZZZ seconds 
+        ;; will be discarded.
+        (progn (print '>) 
+               (if zzz (sleep zzz))
+               (print '>>)
+               (if clear-p (clear-input))
+               (read))))
+
+(read-sleepily)
+>>  > 10
+>>  >
+>>  >> 20
+=>  (10 20)
+
+(read-sleepily t)
+>>  > 10
+>>  >
+>>  >> 20
+=>  (10 20)
+
+(read-sleepily t 10)
+>>  > 10
+>>  > 20  ; Some implementations won't echo typeahead here.
+>>  >> 30
+=>  (10 30)
+
+

+

Side Effects:

+

+The input-stream is modified.

+

Affected By:

+

+*standard-input*

+

Exceptional Situations:

+

+Should signal an error of type type-error if input-stream is not a stream designator.

+

See Also:

+

+clear-output

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_close.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_close.htm new file mode 100644 index 00000000..8dc34bdf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_close.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function CLOSE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CLOSE

+

Syntax:

+

+ +close stream &key abort => result

+

+

Arguments and Values:

+

+stream---a stream (either open or closed).

+abort---a generalized boolean. The default is false.

+ result---t if the stream was open at the time it was received as an argument, or implementation-dependent otherwise.

+

Description:

+

+close closes stream. Closing a stream means that it may no longer be used in input or output operations. The act of closing a file stream ends the association between the stream and its associated file; the transaction with the file system is terminated, and input/output may no longer be performed on the stream.

+If abort is true, an attempt is made to clean up any side effects of having created stream. If stream performs output to a file that was created when the stream was created, the file is deleted and any previously existing file is not superseded.

+It is permissible to close an already closed stream, but in that case the result is implementation-dependent.

+After stream is closed, it is still possible to perform the following query operations upon it: streamp, pathname, truename, merge-pathnames, pathname-host, pathname-device, pathname-directory,pathname-name, pathname-type, pathname-version, namestring, file-namestring, directory-namestring, host-namestring, enough-namestring, open, probe-file, and directory.

+ The effect of close on a constructed stream is to close the argument stream only. There is no effect on the constituents of composite streams.

+For a stream created with make-string-output-stream, the result of get-output-stream-string is unspecified after close.

+

Examples:

+

+

+ (setq s (make-broadcast-stream)) =>  #<BROADCAST-STREAM>
+ (close s) =>  T
+ (output-stream-p s) =>  true
+
+

+

Side Effects:

+

+The stream is closed (if necessary). If abort is true and the stream is an output file stream, its associated file might be deleted.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+open

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clrhas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clrhas.htm new file mode 100644 index 00000000..dc511130 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_clrhas.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function CLRHASH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CLRHASH

+

Syntax:

+

+ +clrhash hash-table => hash-table

+

+

Arguments and Values:

+

+hash-table---a hash table.

+

Description:

+

+Removes all entries from hash-table, and then returns that empty hash table.

+

Examples:

+

+

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32004073>
+ (dotimes (i 100) (setf (gethash i table) (format nil "~R" i))) =>  NIL
+ (hash-table-count table) =>  100
+ (gethash 57 table) =>  "fifty-seven", true
+ (clrhash table) =>  #<HASH-TABLE EQL 0/120 32004073>
+ (hash-table-count table) =>  0
+ (gethash 57 table) =>  NIL, false
+
+

+

Side Effects:

+

+The hash-table is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp.htm new file mode 100644 index 00000000..c8d45c36 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function COMPILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPILE

+

+

Syntax:

+

+ +compile name &optional definition => function, warnings-p, failure-p

+

+

Arguments and Values:

+

+name---a function name, or nil.

+definition---a lambda expression or a function. The default is the function definition of name if it names a function, or the macro function of name if it names a macro. The consequences are undefined if no definition is supplied when the name is nil.

+function---the function-name, or a compiled function.

+warnings-p---a generalized boolean.

+failure-p---a generalized boolean.

+

Description:

+

+Compiles an interpreted function.

+compile produces a compiled function from definition. If the definition is a lambda expression, it is coerced to a function. If the definition is already a compiled function, compile either produces that function itself (i.e., is an identity operation) or an equivalent function.

+If the name is nil, the resulting compiled function is returned directly as the primary value. If a non-nil name is given, then the resulting compiled function replaces the existing function definition of name and the name is returned as the primary value; if name is a symbol that names a macro, its macro function is updated and the name is returned as the primary value.

+ Literal objects appearing in code processed by the compile function are neither copied nor coalesced. The code resulting from the execution of compile references objects that are eql to the corresponding objects in the source code.

+ compile is permitted, but not required, to establish a handler for conditions of type error. For example, the handler might issue a warning and restart compilation from some implementation-dependent point in order to let the compilation proceed without manual intervention.

+The secondary value, warnings-p, is false if no conditions of type error or warning were detected by the compiler, and true otherwise.

+The tertiary value, failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler, and true otherwise.

+

Examples:

+

+

+ (defun foo () "bar") =>  FOO
+ (compiled-function-p #'foo) =>  implementation-dependent
+ (compile 'foo) =>  FOO 
+ (compiled-function-p #'foo) =>  true
+ (setf (symbol-function 'foo)
+       (compile nil '(lambda () "replaced"))) =>  #<Compiled-Function>
+ (foo) =>  "replaced"
+
+

+

Affected By:

+

+ *error-output*, *macroexpand-hook*.

+The presence of macro definitions and proclamations.

+

Exceptional Situations:

+

+ The consequences are undefined if the lexical environment surrounding the function to be compiled contains any bindings other than those for macros, symbol macros, or declarations.

+

+For information about errors detected during the compilation process, see Section 3.2.5 (Exceptional Situations in the Compiler).

+

See Also:

+

+compile-file

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp__1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp__1.htm new file mode 100644 index 00000000..c56cf06e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp__1.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function COMPILE-FILE-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPILE-FILE-PATHNAME

+

+

Syntax:

+

+ +compile-file-pathname input-file &key output-file &allow-other-keys => pathname

+

+

Arguments and Values:

+

+input-file---a pathname designator. (Default fillers for unspecified components are taken from *default-pathname-defaults*.)

+output-file---a pathname designator. The default is implementation-defined.

+pathname---a pathname.

+

Description:

+

+Returns the pathname that compile-file would write into, if given the same arguments.

+ The defaults for the output-file are taken from the pathname that results from merging the input-file with the value of *default-pathname-defaults*, except that the type component should default to the appropriate implementation-defined default type for compiled files.

+If input-file is a logical pathname and output-file is unsupplied, the result is a logical pathname. If input-file is a logical pathname, it is translated into a physical pathname as if by calling translate-logical-pathname. If input-file is a stream, the stream can be either open or closed. compile-file-pathname returns the same pathname after a file is closed as it did when the file was open. It is an error if input-file is a stream that is created with make-two-way-stream, make-echo-stream, make-broadcast-stream, make-concatenated-stream, make-string-input-stream, make-string-output-stream.

+If an implementation supports additional keyword arguments to compile-file, compile-file-pathname must accept the same arguments.

+

Examples:

+

+See logical-pathname-translations.

+

Affected By: None. +

+

Exceptional Situations:

+

+ An error of type file-error might be signaled if either input-file or output-file is wild.

+

See Also:

+

+ compile-file, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_fi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_fi.htm new file mode 100644 index 00000000..d4618e7b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_fi.htm @@ -0,0 +1,76 @@ + + + +CLHS: Function COMPILE-FILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPILE-FILE

+

Syntax:

+

+ +compile-file input-file &key output-file verbose print external-format

=> output-truename, warnings-p, failure-p

+

+

Arguments and Values:

+

+input-file---a pathname designator. (Default fillers for unspecified components are taken from *default-pathname-defaults*.)

+output-file---a pathname designator. The default is implementation-defined.

+ verbose---a generalized boolean. The default is the value of *compile-verbose*.

+print---a generalized boolean. The default is the value of *compile-print*.

+

+ external-format---an external file format designator. The default is :default.

+output-truename---a pathname (the truename of the output file), or nil.

+warnings-p---a generalized boolean.

+failure-p---a generalized boolean.

+

+

Description:

+

+compile-file transforms the contents of the file specified by input-file into implementation-dependent binary data which are placed in the file specified by output-file.

+The file to which input-file refers should be a source file. output-file can be used to specify an output pathname; the actual pathname of the compiled file to which compiled code will be output is computed as if by calling compile-file-pathname.

+ If input-file or output-file is a logical pathname, it is translated into a physical pathname as if by calling translate-logical-pathname.

+ If verbose is true, compile-file prints a message in the form of a comment (i.e., with a leading semicolon) to standard output indicating what file is being compiled and other useful information. If verbose is false, compile-file does not print this information.

+If print is true, information about top level forms in the file being compiled is printed to standard output. Exactly what is printed is implementation-dependent, but nevertheless some information is printed. If print is nil, no information is printed.

+ The external-format specifies the external file format to be used when opening the file; see the function open. compile-file and load must cooperate in such a way that the resulting compiled file can be loaded without specifying an external file format anew; see the function load.

+ compile-file binds *readtable* and *package* to the values they held before processing the file.

+ *compile-file-truename* is bound by compile-file to hold the truename of the pathname of the file being compiled.

+ *compile-file-pathname* is bound by compile-file to hold a pathname denoted by the first argument to compile-file, merged against the defaults; that is, (pathname (merge-pathnames input-file)).

+The compiled functions contained in the compiled file become available for use when the compiled file is loaded into Lisp. Any function definition that is processed by the compiler, including #'(lambda ...) forms and local function definitions made by flet, labels and defun forms, result in an object of type compiled-function.

+ The primary value returned by compile-file, output-truename, is the truename of the output file, or nil if the file could not be created.

+The secondary value, warnings-p, is false if no conditions of type error or warning were detected by the compiler, and true otherwise.

+The tertiary value, failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler, and true otherwise.

+For general information about how files are processed by the file compiler, see Section 3.2.3 (File Compilation).

+ Programs to be compiled by the file compiler must only contain externalizable objects; for details on such objects, see Section 3.2.4 (Literal Objects in Compiled Files). For information on how to extend the set of externalizable objects, see the function make-load-form and Section 3.2.4.4 (Additional Constraints on Externalizable Objects).

+

Examples: None. +

+

Affected By:

+ *error-output*, *standard-output*, *compile-verbose*, *compile-print*

+The computer's file system.

Exceptional Situations:

+

+For information about errors detected during the compilation process, see Section 3.2.5 (Exceptional Situations in the Compiler).

+ An error of type file-error might be signaled if (wild-pathname-p input-file) returns true.

+ If either the attempt to open the source file for input or the attempt to open the compiled file for output fails, an error of type file-error is signaled.

+

See Also:

+

+ compile, declare, eval-when, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_ma.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_ma.htm new file mode 100644 index 00000000..78076532 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmp_ma.htm @@ -0,0 +1,57 @@ + + + +CLHS: Accessor COMPILER-MACRO-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor COMPILER-MACRO-FUNCTION

+

+

Syntax:

+

+ +compiler-macro-function name &optional environment => function

+ +(setf (compiler-macro-function name &optional environment) new-function)

+

+

Arguments and Values:

+

+name---a function name.

+environment---an environment object.

+function, new-function---a compiler macro function, or nil.

+

Description:

+

+Accesses the compiler macro function named name, if any, in the environment.

+A value of nil denotes the absence of a compiler macro function named name.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+ The consequences are undefined if environment is non-nil in a use of setf of compiler-macro-function.

+

See Also:

+

+define-compiler-macro, Section 3.2.2.1 (Compiler Macros)

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmpd_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmpd_f.htm new file mode 100644 index 00000000..b991c836 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cmpd_f.htm @@ -0,0 +1,73 @@ + + + +CLHS: Function COMPILED-FUNCTION-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPILED-FUNCTION-P

+

Syntax:

+

+ +compiled-function-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type compiled-function; otherwise, returns false.

+

Examples:

+

+

+ (defun f (x) x) =>  F
+ (compiled-function-p #'f)
+=>  false
+OR=>  true
+ (compiled-function-p 'f) =>  false
+ (compile 'f) =>  F
+ (compiled-function-p #'f) =>  true
+ (compiled-function-p 'f) =>  false
+ (compiled-function-p (compile nil '(lambda (x) x)))
+=>  true
+ (compiled-function-p #'(lambda (x) x))
+=>  false
+OR=>  true
+ (compiled-function-p '(lambda (x) x)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+compile, compile-file, compiled-function

+

Notes:

+

+

+ (compiled-function-p object) ==  (typep object 'compiled-function)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_code_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_code_c.htm new file mode 100644 index 00000000..70feefa9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_code_c.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function CODE-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CODE-CHAR

+

+

Syntax:

+

+ +code-char code => char-p

+

+

Arguments and Values:

+

+code---a character code.

+char-p---a character or nil.

+

Description:

+

+Returns a character with the code attribute given by code. If no such character exists and one cannot be created, nil is returned.

+

Examples:

+

+

+(code-char 65.) =>  #\A  ;in an implementation using ASCII codes
+(code-char (char-code #\Space)) =>  #\Space  ;in any implementation
+
+

+

Affected By:

+

+The implementation's character encoding.

+

Exceptional Situations: None. +

+

See Also:

+

+char-code

+

Notes:

+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_coerce.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_coerce.htm new file mode 100644 index 00000000..b7b8d394 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_coerce.htm @@ -0,0 +1,104 @@ + + + +CLHS: Function COERCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COERCE

+

Syntax:

+

+ +coerce object result-type => result

+

+

Arguments and Values:

+

+object---an object.

+result-type---a type specifier.

+result---an object, of type result-type except in situations described in Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals).

+

Description:

+

+Coerces the object to type result-type.

+If object is already of type result-type, the object itself is returned, regardless of whether it would have been possible in general to coerce an object of some other type to result-type.

+Otherwise, the object is coerced to type result-type according to the following rules:

+

+

sequence

+

+If the result-type is a recognizable subtype of list, and the object is a sequence, then the result is a list that has the same elements as object.

+If the result-type is a recognizable subtype of vector, and the object is a sequence, then the result is a vector that has the same elements as object. If result-type is a specialized type, the result has an actual array element type that is the result of upgrading the element type part of that specialized type. If no element type is specified, the element type defaults to t. If the implementation cannot determine the element type, an error is signaled.

+

+

character

+If the result-type is character and the object is a character designator, the result is the character it denotes.

+

+

complex

+If the result-type is complex and the object is a real, then the result is obtained by constructing a complex whose real part is the object and whose imaginary part is the result of coercing an integer zero to the type of the object (using coerce). (If the real part is a rational, however, then the result must be represented as a rational rather than a complex; see Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals). So, for example, (coerce 3 'complex) is permissible, but will return 3, which is not a complex.)

+

float

+If the result-type is any of float, short-float, single-float, double-float, long-float, and the object is a real, then the result is a float of type result-type which is equal in sign and magnitude to the object to whatever degree of representational precision is permitted by that float representation. (If the result-type is float and object is not already a float, then the result is a single float.)

+

function

+If the result-type is function, and object is any function name that is fbound but that is globally defined neither as a macro name nor as a special operator, then the result is the functional value of object.

+If the result-type is function, and object is a lambda expression, then the result is a closure of object in the null lexical environment.

+

t

+Any object can be coerced to an object of type t. In this case, the object is simply returned.

+

+

Examples:

+

+

+ (coerce '(a b c) 'vector) =>  #(A B C)
+ (coerce 'a 'character) =>  #\A
+ (coerce 4.56 'complex) =>  #C(4.56 0.0)
+ (coerce 4.5s0 'complex) =>  #C(4.5s0 0.0s0)
+ (coerce 7/2 'complex) =>  7/2
+ (coerce 0 'short-float) =>  0.0s0
+ (coerce 3.5L0 'float) =>  3.5L0
+ (coerce 7/2 'float) =>  3.5
+ (coerce (cons 1 2) t) =>  (1 . 2)
+
+

+ All the following forms should signal an error:

+

+ (coerce '(a b c) '(vector * 4))
+ (coerce #(a b c) '(vector * 4))
+ (coerce '(a b c) '(vector * 2))
+ (coerce #(a b c) '(vector * 2))
+ (coerce "foo" '(string 2))
+ (coerce #(#\a #\b #\c) '(string 2))
+ (coerce '(0 1) '(simple-bit-vector 3))
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If a coercion is not possible, an error of type type-error is signaled.

+(coerce x 'nil) always signals an error of type type-error.

+An error of type error is signaled if the result-type is function but object is a symbol that is not fbound or if the symbol names a macro or a special operator.

+ An error of type type-error should be signaled if result-type specifies the number of elements and object is of a different length.

+

See Also:

+

+rational, floor, char-code, char-int

+

Notes:

+

+Coercions from floats to rationals and from ratios to integers are not provided because of rounding problems.

+

+ (coerce x 't) ==  (identity x) ==  x
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_1.htm new file mode 100644 index 00000000..3a2e49df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_1.htm @@ -0,0 +1,93 @@ + + + +CLHS: Function COMPUTE-RESTARTS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPUTE-RESTARTS

+

Syntax:

+

+ +compute-restarts &optional condition => restarts

+

+

Arguments and Values:

+

+ condition---a condition object, or nil.

+restarts---a list of restarts.

+

Description:

+

+compute-restarts uses the dynamic state of the program to compute a list of the restarts which are currently active.

+The resulting list is ordered so that the innermost (more-recently established) restarts are nearer the head of the list.

+ When condition is non-nil, only those restarts are considered that are either explicitly associated with that condition, or not associated with any condition; that is, the excluded restarts are those that are associated with a non-empty set of conditions of which the given condition is not an element. If condition is nil, all restarts are considered.

+compute-restarts returns all applicable restarts, including anonymous ones, even if some of them have the same name as others and would therefore not be found by find-restart when given a symbol argument.

+Implementations are permitted, but not required, to return distinct lists from repeated calls to compute-restarts while in the same dynamic environment. The consequences are undefined if the list returned by compute-restarts is every modified.

+

Examples:

+

+

+ ;; One possible way in which an interactive debugger might present
+ ;; restarts to the user.
+ (defun invoke-a-restart ()
+   (let ((restarts (compute-restarts)))
+     (do ((i 0 (+ i 1)) (r restarts (cdr r))) ((null r))
+       (format t "~&~D: ~A~%" i (car r)))
+     (let ((n nil) (k (length restarts)))
+       (loop (when (and (typep n 'integer) (>= n 0) (< n k))
+               (return t))
+             (format t "~&Option: ")
+             (setq n (read))
+             (fresh-line))
+       (invoke-restart-interactively (nth n restarts)))))
+
+ (restart-case (invoke-a-restart)
+   (one () 1)
+   (two () 2)
+   (nil () :report "Who knows?" 'anonymous)
+   (one () 'I)
+   (two () 'II))
+>>  0: ONE
+>>  1: TWO
+>>  2: Who knows?
+>>  3: ONE
+>>  4: TWO
+>>  5: Return to Lisp Toplevel.
+>>  Option: 4
+=>  II
+ 
+ ;; Note that in addition to user-defined restart points, COMPUTE-RESTARTS
+ ;; also returns information about any system-supplied restarts, such as
+ ;; the "Return to Lisp Toplevel" restart offered above.
+ 
+
+

+

Side Effects: None. +

+

Affected By:

+

+Existing restarts.

+

Exceptional Situations: None. +

+

See Also:

+

+find-restart, invoke-restart, restart-bind

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_2.htm new file mode 100644 index 00000000..31fc1ce5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_2.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function COMPLEX + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPLEX

+

Syntax:

+

+ +complex realpart &optional imagpart => complex

+

+

Arguments and Values:

+

+realpart---a real.

+imagpart---a real.

+complex---a rational or a complex.

+

Description:

+

+complex returns a number whose real part is realpart and whose imaginary part is imagpart.

+If realpart is a rational and imagpart is the rational number zero, the result of complex is realpart, a rational. Otherwise, the result is a complex.

+If either realpart or imagpart is a float, the non-float is converted to a float before the complex is created. If imagpart is not supplied, the imaginary part is a zero of the same type as realpart; i.e., (coerce 0 (type-of realpart)) is effectively used.

+

+Type upgrading implies a movement upwards in the type hierarchy lattice. In the case of complexes, the type-specifier must be a subtype of (upgraded-complex-part-type type-specifier). If type-specifier1 is a subtype of type-specifier2, then (upgraded-complex-element-type 'type-specifier1) must also be a subtype of (upgraded-complex-element-type 'type-specifier2). Two disjoint types can be upgraded into the same thing.

+

+

Examples:

+ +

+ (complex 0) =>  0
+ (complex 0.0) =>  #C(0.0 0.0)
+ (complex 1 1/2) =>  #C(1 1/2)
+ (complex 1 .99) =>  #C(1.0 0.99)
+ (complex 3/2 0.0) =>  #C(1.5 0.0)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+realpart, imagpart, Section 2.4.8.11 (Sharpsign C)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_3.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_3.htm new file mode 100644 index 00000000..3e24d809 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comp_3.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function COMPLEXP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPLEXP

+

Syntax:

+

+ +complexp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type complex; otherwise, returns false.

+

Examples:

+ +

+ (complexp 1.2d2) =>  false
+ (complexp #c(5/3 7.2)) =>  true
+
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+complex (function and type), typep

+

Notes:

+

+

+ (complexp object) ==  (typep object 'complex)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comple.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comple.htm new file mode 100644 index 00000000..0beb34f8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comple.htm @@ -0,0 +1,76 @@ + + + +CLHS: Function COMPLEMENT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COMPLEMENT

+

+

Syntax:

+

+ +complement function => complement-function

+

+

Arguments and Values:

+

+function---a function.

+complement-function---a function.

+

Description:

+

+Returns a function that takes the same arguments as function, and has the same side-effect behavior as function, but returns only a single value: a generalized boolean with the opposite truth value of that which would be returned as the primary value of function. That is, when the function would have returned true as its primary value the complement-function returns false, and when the function would have returned false as its primary value the complement-function returns true.

+

Examples:

+

+

+ (funcall (complement #'zerop) 1) =>  true
+ (funcall (complement #'characterp) #\A) =>  false
+ (funcall (complement #'member) 'a '(a b c)) =>  false
+ (funcall (complement #'member) 'd '(a b c)) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+not

+

Notes:

+

+

+ (complement x) ==  #'(lambda (&rest arguments) (not (apply x arguments)))
+
+

+In Common Lisp, functions with names like ``xxx-if-not'' are related to functions with names like ``xxx-if'' in that

+

+(xxx-if-not f . arguments) ==  (xxx-if (complement f) . arguments)
+
+

+For example,

+

+ (find-if-not #'zerop '(0 0 3)) == 
+ (find-if (complement #'zerop) '(0 0 3)) =>  3
+
+

+Note that since the ``xxx-if-not'' functions and the :test-not arguments have been deprecated, uses of ``xxx-if'' functions or :test arguments with complement are preferred.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comput.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comput.htm new file mode 100644 index 00000000..b773cfed --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_comput.htm @@ -0,0 +1,57 @@ + + + +CLHS: Standard Generic Function COMPUTE-APPLICABLE-METHODS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function COMPUTE-APPLICABLE-METHODS

+

+

Syntax:

+

+ +compute-applicable-methods generic-function function-arguments => methods

+

+

Method Signatures:

+

+ +compute-applicable-methods (generic-function standard-generic-function)

+

+

+

Arguments and Values:

+

+generic-function---a generic function.

+function-arguments---a list of arguments for the generic-function.

+methods---a list of method objects.

+

Description:

+

+Given a generic-function and a set of function-arguments, the function compute-applicable-methods returns the set of methods that are applicable for those arguments sorted according to precedence order. See Section 7.6.6 (Method Selection and Combination).

+

Affected By:

+

+defmethod

+

Exceptional Situations: None. +

+

See Also:

+

+Section 7.6.6 (Method Selection and Combination)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conc_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conc_1.htm new file mode 100644 index 00000000..053a1dc6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conc_1.htm @@ -0,0 +1,54 @@ + + + +CLHS: Function CONCATENATED-STREAM-STREAMS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONCATENATED-STREAM-STREAMS

+

+

Syntax:

+

+ +concatenated-stream-streams concatenated-stream => streams

+

+

Arguments and Values:

+

+concatenated-stream -- a concatenated stream.

+streams---a list of input streams.

+

Description:

+

+Returns a list of input streams that constitute the ordered set of streams the concatenated-stream still has to read from, starting with the current one it is reading from. The list may be empty if no more streams remain to be read.

+The consequences are undefined if the list structure of the streams is ever modified.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_concat.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_concat.htm new file mode 100644 index 00000000..dc458ae7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_concat.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function CONCATENATE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONCATENATE

+

Syntax:

+

+ +concatenate result-type &rest sequences => result-sequence

+

+

Arguments and Values:

+

+ result-type---a sequence type specifier.

+sequences---a sequence.

+result-sequence---a proper sequence of type result-type.

+

Description:

+

+concatenate returns a sequence that contains all the individual elements of all the sequences in the order that they are supplied. The sequence is of type result-type, which must be a subtype of type sequence.

+All of the sequences are copied from; the result does not share any structure with any of the sequences. Therefore, if only one sequence is provided and it is of type result-type, concatenate is required to copy sequence rather than simply returning it.

+It is an error if any element of the sequences cannot be an element of the sequence result. If the result-type is a subtype of list, the result will be a list.

+If the result-type is a subtype of vector, then if the implementation can determine the element type specified for the result-type, the element type of the resulting array is the result of upgrading that element type; or, if the implementation can determine that the element type is unspecified (or *), the element type of the resulting array is t; otherwise, an error is signaled.

+

Examples:

+

+

+(concatenate 'string "all" " " "together" " " "now") =>  "all together now"
+(concatenate 'list "ABC" '(d e f) #(1 2 3) #*1011)
+=>  (#\A #\B #\C D E F 1 2 3 1 0 1 1)
+(concatenate 'list) =>  NIL
+
+

+ +

+  (concatenate '(vector * 2) "a" "bc") should signal an error
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+ An error is signaled if the result-type is neither a recognizable subtype of list, nor a recognizable subtype of vector.

+ An error of type type-error should be signaled if result-type specifies the number of elements and the sum of sequences is different from that number.

+

See Also:

+

+append

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conjug.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conjug.htm new file mode 100644 index 00000000..97ea3560 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_conjug.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function CONJUGATE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONJUGATE

+

Syntax:

+

+ +conjugate number => conjugate

+

+

Arguments and Values:

+

+number---a number.

+conjugate---a number.

+

Description:

+

+Returns the complex conjugate of number. The conjugate of a real number is itself.

+

Examples:

+

+

+ (conjugate #c(0 -1)) =>  #C(0 1)
+ (conjugate #c(1 1)) =>  #C(1 -1)
+ (conjugate 1.5) =>  1.5
+ (conjugate #C(3/5 4/5)) =>  #C(3/5 -4/5)
+ (conjugate #C(0.0D0 -1.0D0)) =>  #C(0.0D0 1.0D0)
+ (conjugate 3.7) =>  3.7
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+For a complex number z,

+

+ (conjugate z) ==  (complex (realpart z) (- (imagpart z)))
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons.htm new file mode 100644 index 00000000..0274b0eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function CONS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONS

+

Syntax:

+

+ +cons object-1 object-2 => cons

+

+

Arguments and Values:

+

+object-1---an object.

+object-2---an object.

+cons---a cons.

+

Description:

+

+Creates a fresh cons, the car of which is object-1 and the cdr of which is object-2.

+

Examples:

+

+

+ (cons 1 2) =>  (1 . 2)
+ (cons 1 nil) =>  (1)
+ (cons nil 2) =>  (NIL . 2)
+ (cons nil nil) =>  (NIL)
+ (cons 1 (cons 2 (cons 3 (cons 4 nil)))) =>  (1 2 3 4)
+ (cons 'a 'b) =>  (A . B)
+ (cons 'a (cons 'b (cons 'c '()))) =>  (A B C)
+ (cons 'a '(b c d)) =>  (A B C D)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+list

+

Notes:

+ If object-2 is a list, cons can be thought of as producing a new list which is like it but has object-1 prepended.

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons_1.htm new file mode 100644 index 00000000..d2a02620 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cons_1.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function CONSTANTLY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONSTANTLY

+

+

Syntax:

+

+ +constantly value => function

+

+

Arguments and Values:

+

+value---an object.

+function---a function.

+

Description:

+

+constantly returns a function that accepts any number of arguments, that has no side-effects, and that always returns value.

+

Examples:

+

+

+ (mapcar (constantly 3) '(a b c d)) =>  (3 3 3 3)
+ (defmacro with-vars (vars &body forms)
+   `((lambda ,vars ,@forms) ,@(mapcar (constantly nil) vars)))
+=>  WITH-VARS
+ (macroexpand '(with-vars (a b) (setq a 3 b (* a a)) (list a b)))
+=>  ((LAMBDA (A B) (SETQ A 3 B (* A A)) (LIST A B)) NIL NIL), true
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+identity

+

Notes:

+

+constantly could be defined by:

+

+ (defun constantly (object)
+   #'(lambda (&rest arguments) object))
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consp.htm new file mode 100644 index 00000000..181cd3c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consp.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function CONSP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONSP

+

Syntax:

+

+ +consp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type cons; otherwise, returns false.

+

Examples:

+ +

+ (consp nil) =>  false
+ (consp (cons 1 2)) =>  true
+
+

+The empty list is not a cons, so

+

+ (consp '()) ==  (consp 'nil) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+listp

+

Notes:

+

+

+ (consp object) ==  (typep object 'cons) ==  (not (typep object 'atom)) ==  (typep object '(not atom))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consta.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consta.htm new file mode 100644 index 00000000..d70f3716 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_consta.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function CONSTANTP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function CONSTANTP

+

+

Syntax:

+

+ +constantp form &optional environment => generalized-boolean

+

+

Arguments and Values:

+

+form---a form.

+environment---an environment object. The default is nil.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if form can be determined by the implementation to be a constant form in the indicated environment; otherwise, it returns false indicating either that the form is not a constant form or that it cannot be determined whether or not form is a constant form.

+The following kinds of forms are considered constant forms:

* Self-evaluating objects (such as numbers, characters, and the various kinds of arrays) are always considered constant forms and must be recognized as such by constantp.

+
* Constant variables, such as keywords, symbols defined by Common Lisp as constant (such as nil, t, and pi), and symbols declared as constant by the user in the indicated environment using defconstant are always considered constant forms and must be recognized as such by constantp.

+
* quote forms are always considered constant forms and must be recognized as such by constantp.

+
* An implementation is permitted, but not required, to detect additional constant forms. If it does, it is also permitted, but not required, to make use of information in the environment. Examples of constant forms for which constantp might or might not return true are: (sqrt pi), (+ 3 2), (length '(a b c)), and (let ((x 7)) (zerop x)).

+If an implementation chooses to make use of the environment information, such actions as expanding macros or performing function inlining are permitted to be used, but not required; however, expanding compiler macros is not permitted.

+

Examples:

+

+

+ (constantp 1) =>  true
+ (constantp 'temp) =>  false
+ (constantp ''temp)) =>  true
+ (defconstant this-is-a-constant 'never-changing) =>  THIS-IS-A-CONSTANT 
+ (constantp 'this-is-a-constant) =>  true
+ (constantp "temp") =>  true
+ (setq a 6) =>  6 
+ (constantp a) =>  true
+ (constantp '(sin pi)) =>  implementation-dependent
+ (constantp '(car '(x))) =>  implementation-dependent
+ (constantp '(eql x x)) =>  implementation-dependent
+ (constantp '(typep x 'nil)) =>  implementation-dependent
+ (constantp '(typep x 't)) =>  implementation-dependent
+ (constantp '(values this-is-a-constant)) =>  implementation-dependent
+ (constantp '(values 'x 'y)) =>  implementation-dependent
+ (constantp '(let ((a '(a b c))) (+ (length a) 6))) =>  implementation-dependent
+
+

+

Side Effects: None. +

+

Affected By:

+

+The state of the global environment (e.g., which symbols have been declared to be the names of constant variables).

+

Exceptional Situations: None. +

+

See Also:

+

+defconstant

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_countc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_countc.htm new file mode 100644 index 00000000..255c638f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_countc.htm @@ -0,0 +1,73 @@ + + + +CLHS: Function COUNT, COUNT-IF, COUNT-IF-NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COUNT, COUNT-IF, COUNT-IF-NOT

+

Syntax:

+

+ +count item sequence &key from-end start end key test test-not => n

+ +count-if predicate sequence &key from-end start end key => n

+ +count-if-not predicate sequence &key from-end start end key => n

+

+

Arguments and Values:

+

+item---an object.

+sequence---a proper sequence.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+key---a designator for a function of one argument, or nil.

+n---a non-negative integer less than or equal to the length of sequence.

+

Description:

+

+count, count-if, and count-if-not count and return the number of elements in the sequence bounded by start and end that satisfy the test.

+The from-end has no direct effect on the result. However, if from-end is true, the elements of sequence will be supplied as arguments to the test, test-not, and key in reverse order, which may change the side-effects, if any, of those functions.

+

Examples:

+

+

+ (count #\a "how many A's are there in here?") =>  2
+ (count-if-not #'oddp '((1) (2) (3) (4)) :key #'car) =>  2
+ (count-if #'upper-case-p "The Crying of Lot 49" :start 4) =>  2 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+Section 17.2 (Rules about Test Functions), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not argument is deprecated.

+ The function count-if-not is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ali.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ali.htm new file mode 100644 index 00000000..ad8a23ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ali.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function COPY-ALIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-ALIST

+

Syntax:

+

+ +copy-alist alist => new-alist

+

+

Arguments and Values:

+

+alist---an association list.

+new-alist---an association list.

+

Description:

+

+copy-alist returns a copy of alist.

+The list structure of alist is copied, and the elements of alist which are conses are also copied (as conses only). Any other objects which are referred to, whether directly or indirectly, by the alist continue to be shared.

+

Examples:

+

+

+(defparameter *alist* (acons 1 "one" (acons 2 "two" '())))
+*alist* =>  ((1 . "one") (2 . "two"))
+(defparameter *list-copy* (copy-list *alist*))
+*list-copy* =>  ((1 . "one") (2 . "two"))
+(defparameter *alist-copy* (copy-alist *alist*))
+*alist-copy* =>  ((1 . "one") (2 . "two"))
+(setf (cdr (assoc 2 *alist-copy*)) "deux") =>  "deux"
+*alist-copy* =>  ((1 . "one") (2 . "deux"))
+*alist* =>  ((1 . "one") (2 . "two"))
+(setf (cdr (assoc 1 *list-copy*)) "uno") =>  "uno"
+*list-copy* =>  ((1 . "uno") (2 . "two"))
+*alist* =>  ((1 . "uno") (2 . "two"))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+copy-list

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_lis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_lis.htm new file mode 100644 index 00000000..e516aec8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_lis.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function COPY-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-LIST

+

Syntax:

+

+ +copy-list list => copy

+

+

Arguments and Values:

+

+list---a proper list or a dotted list.

+copy---a list.

+

Description:

+

+Returns a copy of list. If list is a dotted list, the resulting list will also be a dotted list.

+Only the list structure of list is copied; the elements of the resulting list are the same as the corresponding elements of the given list.

+

Examples:

+

+

+ (setq lst (list 1 (list 2 3))) =>  (1 (2 3))
+ (setq slst lst) =>  (1 (2 3))
+ (setq clst (copy-list lst)) =>  (1 (2 3))
+ (eq slst lst) =>  true
+ (eq clst lst) =>  false
+ (equal clst lst) =>  true
+ (rplaca lst "one") =>  ("one" (2 3))
+ slst =>  ("one" (2 3))
+ clst =>  (1 (2 3))
+ (setf (caadr lst) "two") =>  "two"
+ lst =>  ("one" ("two" 3))
+ slst =>  ("one" ("two" 3))
+ clst =>  (1 ("two" 3))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences are undefined if list is a circular list.

+

See Also:

+

+copy-alist, copy-seq, copy-tree

+

Notes:

+

+The copy created is equal to list, but not eq.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ppr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ppr.htm new file mode 100644 index 00000000..2820467d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_ppr.htm @@ -0,0 +1,54 @@ + + + +CLHS: Function COPY-PPRINT-DISPATCH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-PPRINT-DISPATCH

+

+

Syntax:

+

+ +copy-pprint-dispatch &optional table => new-table

+

+

Arguments and Values:

+

+table---a pprint dispatch table, or nil.

+new-table---a fresh pprint dispatch table.

+

Description:

+

+Creates and returns a copy of the specified table, or of the value of *print-pprint-dispatch* if no table is specified, or of the initial value of *print-pprint-dispatch* if nil is specified.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if table is not a pprint dispatch table.

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_rdt.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_rdt.htm new file mode 100644 index 00000000..06e449d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_rdt.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function COPY-READTABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-READTABLE

+

Syntax:

+

+ +copy-readtable &optional from-readtable to-readtable => readtable

+

+

Arguments and Values:

+

+from-readtable---a readtable designator. The default is the current readtable.

+to-readtable---a readtable or nil. The default is nil.

+readtable---the to-readtable if it is non-nil, or else a fresh readtable.

+

Description:

+

+copy-readtable copies from-readtable.

+If to-readtable is nil, a new readtable is created and returned. Otherwise the readtable specified by to-readtable is modified and returned.

+ copy-readtable copies the setting of readtable-case.

+

Examples:

+

+

+ (setq zvar 123) =>  123
+ (set-syntax-from-char #\z #\' (setq table2 (copy-readtable))) =>  T
+ zvar =>  123
+ (copy-readtable table2 *readtable*) =>  #<READTABLE 614000277>
+ zvar =>  VAR
+ (setq *readtable* (copy-readtable)) =>  #<READTABLE 46210223>
+ zvar =>  VAR
+ (setq *readtable* (copy-readtable nil)) =>  #<READTABLE 46302670>
+ zvar =>  123
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+readtable, *readtable*

+

Notes:

+

+

+(setq *readtable* (copy-readtable nil))
+
+ restores the input syntax to standard Common Lisp syntax, even if the initial readtable has been clobbered (assuming it is not so badly clobbered that you cannot type in the above expression).

+On the other hand,

+

+(setq *readtable* (copy-readtable))
+
+ replaces the current readtable with a copy of itself. This is useful if you want to save a copy of a readtable for later use, protected from alteration in the meantime. It is also useful if you want to locally bind the readtable to a copy of itself, as in:

+

+(let ((*readtable* (copy-readtable))) ...)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_seq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_seq.htm new file mode 100644 index 00000000..4cb8a06f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_seq.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function COPY-SEQ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-SEQ

+

Syntax:

+

+ +copy-seq sequence => copied-sequence

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+copied-sequence---a proper sequence.

+

Description:

+

+Creates a copy of sequence. The elements of the new sequence are the same as the corresponding elements of the given sequence.

+If sequence is a vector, the result is a fresh simple array of rank one that has the same actual array element type as sequence. If sequence is a list, the result is a fresh list.

+

Examples:

+ +

+ (setq str "a string") =>  "a string"
+ (equalp str (copy-seq str)) =>  true
+ (eql str (copy-seq str)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+copy-list

+

Notes:

+

+From a functional standpoint, +

+ (copy-seq x) ==  (subseq x 0)
+
+ However, the programmer intent is typically very different in these two cases.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_stu.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_stu.htm new file mode 100644 index 00000000..6ee40161 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_stu.htm @@ -0,0 +1,56 @@ + + + +CLHS: Function COPY-STRUCTURE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-STRUCTURE

+

+

Syntax:

+

+ +copy-structure structure => copy

+

+

Arguments and Values:

+

+structure---a structure.

+copy---a copy of the structure.

+

Description:

+

+Returns a copy[6] of the structure.

+Only the structure itself is copied; not the values of the slots.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+the :copier option to defstruct

+

Notes:

+

+The copy is the same as the given structure under equalp, but not under equal.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_sym.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_sym.htm new file mode 100644 index 00000000..ec486834 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_sym.htm @@ -0,0 +1,81 @@ + + + +CLHS: Function COPY-SYMBOL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-SYMBOL

+

Syntax:

+

+ +copy-symbol symbol &optional copy-properties => new-symbol

+

+

Arguments and Values:

+

+symbol---a symbol.

+copy-properties---a generalized boolean. The default is false.

+new-symbol---a fresh, uninterned symbol.

+

Description:

+

+ copy-symbol returns a fresh, uninterned symbol, the name of which is string= to and possibly the same as the name of the given symbol.

+If copy-properties is false, the new-symbol is neither bound nor fbound and has a null property list. If copy-properties is true, then the initial value of new-symbol is the value of symbol, the initial function definition of new-symbol is the functional value of symbol, and the property list of new-symbol is a copy[2] of the property list of symbol.

+

Examples:

+

+

+ (setq fred 'fred-smith) =>  FRED-SMITH
+ (setf (symbol-value fred) 3) =>  3
+ (setq fred-clone-1a (copy-symbol fred nil)) =>  #:FRED-SMITH
+ (setq fred-clone-1b (copy-symbol fred nil)) =>  #:FRED-SMITH
+ (setq fred-clone-2a (copy-symbol fred t))   =>  #:FRED-SMITH
+ (setq fred-clone-2b (copy-symbol fred t))   =>  #:FRED-SMITH
+ (eq fred fred-clone-1a) =>  false
+ (eq fred-clone-1a fred-clone-1b) =>  false
+ (eq fred-clone-2a fred-clone-2b) =>  false
+ (eq fred-clone-1a fred-clone-2a) =>  false
+ (symbol-value fred) =>  3
+ (boundp fred-clone-1a) =>  false
+ (symbol-value fred-clone-2a) =>  3
+ (setf (symbol-value fred-clone-2a) 4) =>  4
+ (symbol-value fred) =>  3
+ (symbol-value fred-clone-2a) =>  4
+ (symbol-value fred-clone-2b) =>  3
+ (boundp fred-clone-1a) =>  false
+ (setf (symbol-function fred) #'(lambda (x) x)) =>  #<FUNCTION anonymous>
+ (fboundp fred) =>  true
+ (fboundp fred-clone-1a) =>  false
+ (fboundp fred-clone-2a) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+make-symbol

+

Notes:

+

+Implementors are encouraged not to copy the string which is the symbol's name unnecessarily. Unless there is a good reason to do so, the normal implementation strategy is for the new-symbol's name to be identical to the given symbol's name.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_tre.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_tre.htm new file mode 100644 index 00000000..b6e52e2a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_cp_tre.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function COPY-TREE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function COPY-TREE

+

+

Syntax:

+

+ +copy-tree tree => new-tree

+

+

Arguments and Values:

+

+tree---a tree.

+new-tree---a tree.

+

Description:

+

+Creates a copy of a tree of conses.

+If tree is not a cons, it is returned; otherwise, the result is a new cons of the results of calling copy-tree on the car and cdr of tree. In other words, all conses in the tree represented by tree are copied recursively, stopping only when non-conses are encountered.

+copy-tree does not preserve circularities and the sharing of substructure.

+

Examples:

+

+

+ (setq object (list (cons 1 "one")
+                    (cons 2 (list 'a 'b 'c))))
+=>  ((1 . "one") (2 A B C))
+ (setq object-too object) =>  ((1 . "one") (2 A B C))
+ (setq copy-as-list (copy-list object))
+ (setq copy-as-alist (copy-alist object))
+ (setq copy-as-tree (copy-tree object))
+ (eq object object-too) =>  true
+ (eq copy-as-tree object) =>  false
+ (eql copy-as-tree object) =>  false
+ (equal copy-as-tree object) =>  true
+ (setf (first (cdr (second object))) "a"
+       (car (second object)) "two"
+       (car object) '(one . 1)) =>  (ONE . 1)
+ object =>  ((ONE . 1) ("two" "a" B C))
+ object-too =>  ((ONE . 1) ("two" "a" B C))
+ copy-as-list =>  ((1 . "one") ("two" "a" B C))
+ copy-as-alist =>  ((1 . "one") (2 "a" B C))
+ copy-as-tree =>  ((1 . "one") (2 A B C)) 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+tree-equal

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_fl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_fl.htm new file mode 100644 index 00000000..6e83d0fe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_fl.htm @@ -0,0 +1,135 @@ + + + +CLHS: Function DECODE-FLOAT, SCALE-FLOAT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT

+

Syntax:

+

+ +decode-float float => significand, exponent, sign

+

+ +scale-float float integer => scaled-float

+

+ +float-radix float => float-radix

+

+ +float-sign float-1 &optional float-2 => signed-float

+

+ +float-digits float => digits1

+

+ +float-precision float => digits2

+

+ +integer-decode-float float => significand, exponent, integer-sign

+

+

Arguments and Values:

+

+digits1---a non-negative integer.

+digits2---a non-negative integer.

+exponent---an integer.

+float---a float.

+float-1---a float.

+float-2---a float.

+float-radix---an integer.

+integer---a non-negative integer.

+integer-sign---the integer -1, or the integer 1.

+scaled-float---a float.

+sign---A float of the same type as float but numerically equal to 1.0 or -1.0.

+signed-float---a float.

+significand---a float.

+

Description:

+

+decode-float computes three values that characterize float. The first value is of the same type as float and represents the significand. The second value represents the exponent to which the radix (notated in this description by b) must be raised to obtain the value that, when multiplied with the first result, produces the absolute value of float. If float is zero, any integer value may be returned, provided that the identity shown for scale-float holds. The third value is of the same type as float and is 1.0 if float is greater than or equal to zero or -1.0 otherwise.

+decode-float divides float by an integral power of b so as to bring its value between 1/b (inclusive) and 1 (exclusive), and returns the quotient as the first value. If float is zero, however, the result equals the absolute value of float (that is, if there is a negative zero, its significand is considered to be a positive zero).

+scale-float returns (* float (expt (float b float) integer)), where b is the radix of the floating-point representation. float is not necessarily between 1/b and 1.

+float-radix returns the radix of float.

+float-sign returns a number z such that z and float-1 have the same sign and also such that z and float-2 have the same absolute value. If float-2 is not supplied, its value is (float 1 float-1). If an implementation has distinct representations for negative zero and positive zero, then (float-sign -0.0) => -1.0.

+float-digits returns the number of radix b digits used in the representation of float (including any implicit digits, such as a ``hidden bit'').

+float-precision returns the number of significant radix b digits present in float; if float is a float zero, then the result is an integer zero.

+For normalized floats, the results of float-digits and float-precision are the same, but the precision is less than the number of representation digits for a denormalized or zero number.

+integer-decode-float computes three values that characterize float - the significand scaled so as to be an integer, and the same last two values that are returned by decode-float. If float is zero, integer-decode-float returns zero as the first value. The second value bears the same relationship to the first value as for decode-float:

+

+ (multiple-value-bind (signif expon sign)
+                      (integer-decode-float f)
+   (scale-float (float signif f) expon)) ==  (abs f)
+
+

+

Examples:

+

+

+ ;; Note that since the purpose of this functionality is to expose
+ ;; details of the implementation, all of these examples are necessarily
+ ;; very implementation-dependent.  Results may vary widely.
+ ;; Values shown here are chosen consistently from one particular implementation.
+ (decode-float .5) =>  0.5, 0, 1.0
+ (decode-float 1.0) =>  0.5, 1, 1.0
+ (scale-float 1.0 1) =>  2.0
+ (scale-float 10.01 -2) =>  2.5025
+ (scale-float 23.0 0) =>  23.0
+ (float-radix 1.0) =>  2
+ (float-sign 5.0) =>  1.0
+ (float-sign -5.0) =>  -1.0
+ (float-sign 0.0) =>  1.0
+ (float-sign 1.0 0.0) =>  0.0
+ (float-sign 1.0 -10.0) =>  10.0
+ (float-sign -1.0 10.0) =>  -10.0
+ (float-digits 1.0) =>  24
+ (float-precision 1.0) =>  24
+ (float-precision least-positive-single-float) =>  1
+ (integer-decode-float 1.0) =>  8388608, -23, 1
+
+

+

Side Effects: None. +

+

Affected By:

+

+The implementation's representation for floats.

+

Exceptional Situations:

+

+The functions decode-float, float-radix, float-digits, float-precision, and integer-decode-float should signal an error if their only argument is not a float.

+The function scale-float should signal an error if its first argument is not a float or if its second argument is not an integer.

+The function float-sign should signal an error if its first argument is not a float or if its second argument is supplied but is not a float.

+

See Also: None. +

+

Notes:

+

+The product of the first result of decode-float or integer-decode-float, of the radix raised to the power of the second result, and of the third result is exactly equal to the value of float.

+

+ (multiple-value-bind (signif expon sign)
+                      (decode-float f)
+   (scale-float signif expon))
+==  (abs f)
+
+ and

+

+ (multiple-value-bind (signif expon sign)
+                      (decode-float f)
+   (* (scale-float signif expon) sign))
+==  f
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_un.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_un.htm new file mode 100644 index 00000000..ba809faf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dec_un.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function DECODE-UNIVERSAL-TIME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DECODE-UNIVERSAL-TIME

+

Syntax:

+

+ +decode-universal-time universal-time &optional time-zone

=> second, minute, hour, date, month, year, day, daylight-p, zone

+

+

Arguments and Values:

+

+universal-time---a universal time.

+ time-zone---a time zone.

+second, minute, hour, date, month, year, day, daylight-p, zone---a decoded time.

+

Description:

+

+Returns the decoded time represented by the given universal time.

+If time-zone is not supplied, it defaults to the current time zone adjusted for daylight saving time. If time-zone is supplied, daylight saving time information is ignored. The daylight saving time flag is nil if time-zone is supplied.

+

Examples:

+

+ +

+ (decode-universal-time 0 0) =>  0, 0, 0, 1, 1, 1900, 0, false, 0
+
+;; The next two examples assume Eastern Daylight Time.
+ (decode-universal-time 2414296800 5) =>  0, 0, 1, 4, 7, 1976, 6, false, 5
+ (decode-universal-time 2414293200) =>  0, 0, 1, 4, 7, 1976, 6, true, 5
+
+;; This example assumes that the time zone is Eastern Daylight Time
+;; (and that the time zone is constant throughout the example).
+ (let* ((here (nth 8 (multiple-value-list (get-decoded-time)))) ;Time zone
+        (recently (get-universal-time))
+        (a (nthcdr 7 (multiple-value-list (decode-universal-time recently))))
+        (b (nthcdr 7 (multiple-value-list (decode-universal-time recently here)))))
+   (list a b (equal a b))) =>  ((T 5) (NIL 5) NIL)
+
+

+

Affected By:

+

+Implementation-dependent mechanisms for calculating when or if daylight savings time is in effect for any given session.

+

Exceptional Situations: None. +

+

See Also:

+

+encode-universal-time, get-universal-time, Section 25.1.4 (Time)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_fi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_fi.htm new file mode 100644 index 00000000..246dac17 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_fi.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function DELETE-FILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DELETE-FILE

+

Syntax:

+

+ +delete-file filespec => t

+

+

Arguments and Values:

+

+ filespec---a pathname designator.

+

Description:

+

+Deletes the file specified by filespec.

+If the filespec designator is an open stream, then filespec and the file associated with it are affected (if the file system permits), in which case filespec might be closed immediately, and the deletion might be immediate or delayed until filespec is explicitly closed, depending on the requirements of the file system.

+It is implementation-dependent whether an attempt to delete a nonexistent file is considered to be successful.

+delete-file returns true if it succeeds, or signals an error of type file-error if it does not.

+The consequences are undefined if filespec has a wild component, or if filespec has a nil component and the file system does not permit a nil component.

+

Examples:

+

+

+ (with-open-file (s "delete-me.text" :direction :output :if-exists :error))
+=>  NIL
+ (setq p (probe-file "delete-me.text")) =>  #P"R:>fred>delete-me.text.1"
+ (delete-file p) =>  T
+ (probe-file "delete-me.text") =>  false
+ (with-open-file (s "delete-me.text" :direction :output :if-exists :error)
+   (delete-file s))
+=>  T
+ (probe-file "delete-me.text") =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If the deletion operation is not successful, an error of type file-error is signaled.

+ An error of type file-error might be signaled if filespec is wild.

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_pk.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_pk.htm new file mode 100644 index 00000000..597ad482 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_del_pk.htm @@ -0,0 +1,131 @@ + + + +CLHS: Function DELETE-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DELETE-PACKAGE

+

+

Syntax:

+

+ +delete-package package => generalized-boolean

+

+

Arguments and Values:

+

+ package---a package designator.

+generalized-boolean---a generalized boolean.

+

Description:

+

+delete-package deletes package from all package system data structures. If the operation is successful, delete-package returns true, otherwise nil. The effect of delete-package is that the name and nicknames of package cease to be recognized package names. The package object is still a package (i.e., packagep is true of it) but package-name returns nil. The consequences of deleting the COMMON-LISP package or the KEYWORD package are undefined. The consequences of invoking any other package operation on package once it has been deleted are unspecified. In particular, the consequences of invoking find-symbol, intern and other functions that look for a symbol name in a package are unspecified if they are called with *package* bound to the deleted package or with the deleted package as an argument.

+If package is a package object that has already been deleted, delete-package immediately returns nil.

+After this operation completes, the home package of any symbol whose home package had previously been package is implementation-dependent. Except for this, symbols accessible in package are not modified in any other way; symbols whose home package is not package remain unchanged.

+

Examples:

+

+

+ (setq *foo-package* (make-package "FOO" :use nil))
+ (setq *foo-symbol*  (intern "FOO" *foo-package*))
+ (export *foo-symbol* *foo-package*)
+
+ (setq *bar-package* (make-package "BAR" :use '("FOO")))
+ (setq *bar-symbol*  (intern "BAR" *bar-package*))
+ (export *foo-symbol* *bar-package*)
+ (export *bar-symbol* *bar-package*)
+
+ (setq *baz-package* (make-package "BAZ" :use '("BAR")))
+
+ (symbol-package *foo-symbol*) =>  #<PACKAGE "FOO">
+ (symbol-package *bar-symbol*) =>  #<PACKAGE "BAR">
+
+ (prin1-to-string *foo-symbol*) =>  "FOO:FOO"
+ (prin1-to-string *bar-symbol*) =>  "BAR:BAR"
+
+ (find-symbol "FOO" *bar-package*) =>  FOO:FOO, :EXTERNAL
+
+ (find-symbol "FOO" *baz-package*) =>  FOO:FOO, :INHERITED
+ (find-symbol "BAR" *baz-package*) =>  BAR:BAR, :INHERITED
+
+ (packagep *foo-package*) =>  true
+ (packagep *bar-package*) =>  true
+ (packagep *baz-package*) =>  true
+
+ (package-name *foo-package*) =>  "FOO"
+ (package-name *bar-package*) =>  "BAR"
+ (package-name *baz-package*) =>  "BAZ"
+
+ (package-use-list *foo-package*) =>  ()
+ (package-use-list *bar-package*) =>  (#<PACKAGE "FOO">)
+ (package-use-list *baz-package*) =>  (#<PACKAGE "BAR">)
+
+ (package-used-by-list *foo-package*) =>  (#<PACKAGE "BAR">)
+ (package-used-by-list *bar-package*) =>  (#<PACKAGE "BAZ">)
+ (package-used-by-list *baz-package*) =>  ()
+
+ (delete-package *bar-package*)
+>>  Error: Package BAZ uses package BAR.
+>>  If continued, BAZ will be made to unuse-package BAR,
+>>  and then BAR will be deleted.
+>>  Type :CONTINUE to continue.
+>>  Debug> :CONTINUE
+=>  T
+
+ (symbol-package *foo-symbol*) =>  #<PACKAGE "FOO">
+ (symbol-package *bar-symbol*) is unspecified
+
+ (prin1-to-string *foo-symbol*) =>  "FOO:FOO"
+ (prin1-to-string *bar-symbol*) is unspecified
+
+ (find-symbol "FOO" *bar-package*) is unspecified
+
+ (find-symbol "FOO" *baz-package*) =>  NIL, NIL
+ (find-symbol "BAR" *baz-package*) =>  NIL, NIL
+
+ (packagep *foo-package*) =>  T
+ (packagep *bar-package*) =>  T
+ (packagep *baz-package*) =>  T
+
+ (package-name *foo-package*) =>  "FOO"
+ (package-name *bar-package*) =>  NIL
+ (package-name *baz-package*) =>  "BAZ"
+
+ (package-use-list *foo-package*) =>  ()
+ (package-use-list *bar-package*) is unspecified
+ (package-use-list *baz-package*) =>  ()
+
+ (package-used-by-list *foo-package*) =>  ()
+ (package-used-by-list *bar-package*) is unspecified
+ (package-used-by-list *baz-package*) =>  ()
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If the package designator is a name that does not currently name a package, a correctable error of type package-error is signaled. If correction is attempted, no deletion action is attempted; instead, delete-package immediately returns nil.

+If package is used by other packages, a correctable error of type package-error is signaled. If correction is attempted, unuse-package is effectively called to remove any dependencies, causing package's external symbols to cease being accessible to those packages that use package. delete-package then deletes package just as it would have had there been no packages that used it.

+

See Also:

+

+unuse-package

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_deposi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_deposi.htm new file mode 100644 index 00000000..f813aca6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_deposi.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function DEPOSIT-FIELD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DEPOSIT-FIELD

+

Syntax:

+

+ +deposit-field newbyte bytespec integer => result-integer

+

+

Arguments and Values:

+

+newbyte---an integer.

+bytespec---a byte specifier.

+integer---an integer.

+result-integer---an integer.

+

Description:

+

+Replaces a field of bits within integer; specifically, returns an integer that contains the bits of newbyte within the byte specified by bytespec, and elsewhere contains the bits of integer.

+

Examples:

+

+

+ (deposit-field 7 (byte 2 1) 0) =>  6
+ (deposit-field -1 (byte 4 0) 0) =>  15
+ (deposit-field 0 (byte 2 1) -3) =>  -7
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+byte, dpb

+

Notes:

+

+

+ (logbitp j (deposit-field m (byte s p) n))
+ ==  (if (and (>= j p) (< j (+ p s)))
+        (logbitp j m)
+        (logbitp j n))
+
+

+ deposit-field is to mask-field as dpb is to ldb.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_desc_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_desc_1.htm new file mode 100644 index 00000000..244b6f39 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_desc_1.htm @@ -0,0 +1,87 @@ + + + +CLHS: Standard Generic Function DESCRIBE-OBJECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function DESCRIBE-OBJECT

+

+

Syntax:

+

+ +describe-object object stream => implementation-dependent

+

+

Method Signatures:

+

+ +describe-object (object standard-object) stream

+

+

Arguments and Values:

+

+object---an object.

+stream---a stream.

+

Description:

+

+The generic function describe-object prints a description of object to a stream. describe-object is called by describe; it must not be called by the user.

+Each implementation is required to provide a method on the class standard-object and methods on enough other classes so as to ensure that there is always an applicable method. Implementations are free to add methods for other classes. Users can write methods for describe-object for their own classes if they do not wish to inherit an implementation-supplied method.

+Methods on describe-object can recursively call describe. Indentation, depth limits, and circularity detection are all taken care of automatically, provided that each method handles exactly one level of structure and calls describe recursively if there are more structural levels. The consequences are undefined if this rule is not obeyed.

+In some implementations the stream argument passed to a describe-object method is not the original stream, but is an intermediate stream that implements parts of describe. Methods should therefore not depend on the identity of this stream.

+

Examples:

+

+

+ (defclass spaceship ()
+   ((captain :initarg :captain :accessor spaceship-captain)
+    (serial# :initarg :serial-number :accessor spaceship-serial-number)))
+
+ (defclass federation-starship (spaceship) ())
+
+ (defmethod describe-object ((s spaceship) stream)
+   (with-slots (captain serial#) s
+     (format stream "~&~S is a spaceship of type ~S,~
+                     ~%with ~A at the helm ~
+                       and with serial number ~D.~%"
+             s (type-of s) captain serial#)))
+
+ (make-instance 'federation-starship
+                :captain "Rachel Garrett"
+                :serial-number "NCC-1701-C")
+=>  #<FEDERATION-STARSHIP 26312465>
+
+ (describe *)
+>>  #<FEDERATION-STARSHIP 26312465> is a spaceship of type FEDERATION-STARSHIP,
+>>  with Rachel Garrett at the helm and with serial number NCC-1701-C.
+=>  <no values>
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+describe

+

Notes:

+

+The same implementation techniques that are applicable to print-object are applicable to describe-object.

+The reason for making the return values for describe-object unspecified is to avoid forcing users to include explicit (values) in all of their methods. describe takes care of that.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_descri.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_descri.htm new file mode 100644 index 00000000..80d02b0b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_descri.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function DESCRIBE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DESCRIBE

+

Syntax:

+

+ +describe object &optional stream => <no values>

+

+

Arguments and Values:

+

+object---an object.

+ stream---an output stream designator. The default is standard output.

+

Description:

+

+describe displays information about object to stream.

+For example, describe of a symbol might show the symbol's value, its definition, and each of its properties. describe of a float might show the number's internal representation in a way that is useful for tracking down round-off errors. In all cases, however, the nature and format of the output of describe is implementation-dependent.

+describe can describe something that it finds inside the object; in such cases, a notational device such as increased indentation or positioning in a table is typically used in order to visually distinguish such recursive descriptions from descriptions of the argument object.

+ The actual act of describing the object is implemented by describe-object. describe exists as an interface primarily to manage argument defaulting (including conversion of arguments t and nil into stream objects) and to inhibit any return values from describe-object.

+ describe is not intended to be an interactive function. In a conforming implementation, describe must not, by default, prompt for user input. User-defined methods for describe-object are likewise restricted.

+

Examples: None. +

+

Side Effects:

+

+Output to standard output or terminal I/O.

+

Affected By:

+

+*standard-output* and *terminal-io*, methods on describe-object and print-object for objects having user-defined classes.

+

Exceptional Situations: None. +

+

See Also:

+

+inspect, describe-object

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digi_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digi_1.htm new file mode 100644 index 00000000..a69dc6c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digi_1.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function DIGIT-CHAR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DIGIT-CHAR-P

+

Syntax:

+

+ +digit-char-p char &optional radix => weight

+

+

Arguments and Values:

+

+char---a character.

+radix---a radix. The default is 10.

+weight---either a non-negative integer less than radix, or false.

+

Description:

+

+Tests whether char is a digit in the specified radix (i.e., with a weight less than radix). If it is a digit in that radix, its weight is returned as an integer; otherwise nil is returned.

+

Examples:

+

+

+ (digit-char-p #\5)    =>  5
+ (digit-char-p #\5 2)  =>  false
+ (digit-char-p #\A)    =>  false
+ (digit-char-p #\a)    =>  false
+ (digit-char-p #\A 11) =>  10
+ (digit-char-p #\a 11) =>  10
+ (mapcar #'(lambda (radix) 
+             (map 'list #'(lambda (x) (digit-char-p x radix)) 
+                  "059AaFGZ"))
+         '(2 8 10 16 36))
+ =>  ((0 NIL NIL NIL NIL NIL NIL NIL)
+     (0 5 NIL NIL NIL NIL NIL NIL)
+     (0 5 9 NIL NIL NIL NIL NIL)
+     (0 5 9 10 10 15 NIL NIL)
+     (0 5 9 10 10 15 16 35))
+
+

+

Affected By:

+

+None. (In particular, the results of this predicate are independent of any special syntax which might have been enabled in the current readtable.)

+

Exceptional Situations: None. +

+

See Also:

+

+alphanumericp

+

Notes:

+

+Digits are graphic characters.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digit_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digit_.htm new file mode 100644 index 00000000..9fe53cfc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_digit_.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function DIGIT-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DIGIT-CHAR

+

+

Syntax:

+

+ +digit-char weight &optional radix => char

+

+

Arguments and Values:

+

+weight---a non-negative integer.

+radix---a radix. The default is 10.

+char---a character or false.

+

Description:

+

+If weight is less than radix, digit-char returns a character which has that weight when considered as a digit in the specified radix. If the resulting character is to be an alphabetic[1] character, it will be an uppercase character.

+If weight is greater than or equal to radix, digit-char returns false.

+

Examples:

+

+

+ (digit-char 0) =>  #\0
+ (digit-char 10 11) =>  #\A
+ (digit-char 10 10) =>  false
+ (digit-char 7) =>  #\7
+ (digit-char 12) =>  false
+ (digit-char 12 16) =>  #\C  ;not #\c
+ (digit-char 6 2) =>  false
+ (digit-char 1 2) =>  #\1
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+digit-char-p, graphic-char-p, Section 2.1 (Character Syntax)

+

Notes:

+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dir.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dir.htm new file mode 100644 index 00000000..4ce666b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dir.htm @@ -0,0 +1,55 @@ + + + +CLHS: Function DIRECTORY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DIRECTORY

+

Syntax:

+

+ +directory pathspec &key => pathnames

+

+

Arguments and Values:

+

+ pathspec---a pathname designator, which may contain wild components.

+pathnames---a list of physical pathnames.

+

Description:

+

+Determines which, if any, files that are present in the file system have names matching pathspec, and returns a fresh list of pathnames corresponding to the truenames of those files.

+An implementation may be extended to accept implementation-defined keyword arguments to directory.

+

Examples: None. +

+

Affected By:

+

+The host computer's file system.

+

Exceptional Situations:

+

+ If the attempt to obtain a directory listing is not successful, an error of type file-error is signaled.

+

See Also:

+

+pathname, logical-pathname, ensure-directories-exist, Section 20.1 (File System Concepts), Section 20.1.2 (File Operations on Open and Closed Streams), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+If the pathspec is not wild, the resulting list will contain either zero or one elements.

+Common Lisp specifies ``&key'' in the argument list to directory even though no standardized keyword arguments to directory are defined. ``:allow-other-keys t'' may be used in conforming programs in order to quietly ignore any additional keywords which are passed by the program but not supported by the implementation.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_disass.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_disass.htm new file mode 100644 index 00000000..aeb9d74c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_disass.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function DISASSEMBLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DISASSEMBLE

+

Syntax:

+

+ +disassemble fn => nil

+

+

Arguments and Values:

+

+ fn---an extended function designator or a lambda expression.

+

Description:

+

+The function disassemble is a debugging aid that composes symbolic instructions or expressions in some implementation-dependent language which represent the code used to produce the function which is or is named by the argument fn. The result is displayed to standard output in an implementation-dependent format.

+If fn is a lambda expression or interpreted function, it is compiled first and the result is disassembled.

+If the fn designator is a function name, the function that it names is disassembled. (If that function is an interpreted function, it is first compiled but the result of this implicit compilation is not installed.)

+

Examples:

+ +

+ (defun f (a) (1+ a)) =>  F
+ (eq (symbol-function 'f)
+     (progn (disassemble 'f)
+            (symbol-function 'f))) =>  true
+
+

+

Side Effects: None. +

+

Affected By:

+

+*standard-output*.

+

Exceptional Situations:

+

+Should signal an error of type type-error if fn is not an extended function designator or a lambda expression.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_docume.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_docume.htm new file mode 100644 index 00000000..b52bc610 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_docume.htm @@ -0,0 +1,225 @@ + + + +CLHS: Standard Generic Function DOCUMENTATION... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)

+

Syntax:

+

+ +documentation x doc-type => documentation

+

+ +(setf documentation) new-value x doc-type => new-value

+

+

Argument Precedence Order:

+

+doc-type, object

+

Method Signatures:

+

+

+

+Functions, Macros, and Special Forms:

+ +documentation (x function) (doc-type (eql 't))

+

+ +documentation (x function) (doc-type (eql 'function))

+

+ +documentation (x list) (doc-type (eql 'function))

+

+ +documentation (x list) (doc-type (eql 'compiler-macro))

+

+ +documentation (x symbol) (doc-type (eql 'function))

+

+ +documentation (x symbol) (doc-type (eql 'compiler-macro))

+

+ +documentation (x symbol) (doc-type (eql 'setf))

+

+

+ +(setf documentation) new-value (x function) (doc-type (eql 't))

+

+ +(setf documentation) new-value (x function) (doc-type (eql 'function))

+

+ +(setf documentation) new-value (x list) (doc-type (eql 'function))

+

+ +(setf documentation) new-value (x list) (doc-type (eql 'compiler-macro))

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'function))

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'compiler-macro))

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'setf))

+

+

+

+Method Combinations:

+ +documentation (x method-combination) (doc-type (eql 't))

+

+ +documentation (x method-combination) (doc-type (eql 'method-combination))

+

+ +documentation (x symbol) (doc-type (eql 'method-combination))

+

+

+ +(setf documentation) new-value (x method-combination) (doc-type (eql 't))

+

+ +(setf documentation) new-value (x method-combination) (doc-type (eql 'method-combination))

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'method-combination))

+

+

+

+Methods:

+ +documentation (x standard-method) (doc-type (eql 't))

+

+

+ +(setf documentation) new-value (x standard-method) (doc-type (eql 't))

+

+

+

+Packages:

+ +documentation (x package) (doc-type (eql 't))

+

+

+ +(setf documentation) new-value (x package) (doc-type (eql 't))

+

+

+

+Types, Classes, and Structure Names:

+ +documentation (x standard-class) (doc-type (eql 't))

+

+ +documentation (x standard-class) (doc-type (eql 'type))

+

+ +documentation (x structure-class) (doc-type (eql 't))

+

+ +documentation (x structure-class) (doc-type (eql 'type))

+

+ +documentation (x symbol) (doc-type (eql 'type))

+

+ +documentation (x symbol) (doc-type (eql 'structure))

+

+

+ +(setf documentation) new-value (x standard-class) (doc-type (eql 't))

+

+ +(setf documentation) new-value (x standard-class) (doc-type (eql 'type))

+

+ +(setf documentation) new-value (x structure-class) (doc-type (eql 't))

+

+ +(setf documentation) new-value (x structure-class) (doc-type (eql 'type))

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'type))

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'structure))

+

+

+

+Variables:

+ +documentation (x symbol) (doc-type (eql 'variable))

+

+

+ +(setf documentation) new-value (x symbol) (doc-type (eql 'variable))

+

+

+

+

Arguments and Values:

+

+ x---an object.

+doc-type---a symbol.

+documentation---a string, or nil.

+new-value---a string.

+

Description:

+

+The generic function documentation returns the documentation string associated with the given object if it is available; otherwise it returns nil.

+The generic function (setf documentation) updates the documentation string associated with x to new-value. If x is a list, it must be of the form (setf symbol).

+Documentation strings are made available for debugging purposes. Conforming programs are permitted to use documentation strings when they are present, but should not depend for their correct behavior on the presence of those documentation strings. An implementation is permitted to discard documentation strings at any time for implementation-defined reasons.

+The nature of the documentation string returned depends on the doc-type, as follows:

+

+

compiler-macro

+Returns the documentation string of the compiler macro whose name is the function name x.

+

function

+If x is a function name, returns the documentation string of the function, macro, or special operator whose name is x.

+If x is a function, returns the documentation string associated with x.

+

method-combination

+If x is a symbol, returns the documentation string of the method combination whose name is x.

+If x is a method combination, returns the documentation string associated with x.

+

setf

+Returns the documentation string of the setf expander whose name is the symbol x.

+

structure

+Returns the documentation string associated with the structure name x.

+

t

+Returns a documentation string specialized on the class of the argument x itself. For example, if x is a function, the documentation string associated with the function x is returned.

+

type

+If x is a symbol, returns the documentation string of the class whose name is the symbol x, if there is such a class. Otherwise, it returns the documentation string of the type which is the type specifier symbol x.

+If x is a structure class or standard class, returns the documentation string associated with the class x.

+

variable

+Returns the documentation string of the dynamic variable or constant variable whose name is the symbol x.

+

+A conforming implementation or a conforming program may extend the set of symbols that are acceptable as the doc-type.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+ This standard prescribes no means to retrieve the documentation strings for individual slots specified in a defclass form, but implementations might still provide debugging tools and/or programming language extensions which manipulate this information. Implementors wishing to provide such support are encouraged to consult the Metaobject Protocol for suggestions about how this might be done.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dpb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dpb.htm new file mode 100644 index 00000000..1878c485 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dpb.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function DPB + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DPB

+

Syntax:

+

+ +dpb newbyte bytespec integer => result-integer

+

+

Pronunciation:

+

+ [,duh'pib] or [,duh'puhb] or ['dee'pee'bee]

+

Arguments and Values:

+

+newbyte---an integer.

+bytespec---a byte specifier.

+integer---an integer.

+result-integer---an integer.

+

Description:

+

+dpb (deposit byte) is used to replace a field of bits within integer. dpb returns an integer that is the same as integer except in the bits specified by bytespec.

+Let s be the size specified by bytespec; then the low s bits of newbyte appear in the result in the byte specified by bytespec. Newbyte is interpreted as being right-justified, as if it were the result of ldb.

+

Examples:

+

+

+ (dpb 1 (byte 1 10) 0) =>  1024
+ (dpb -2 (byte 2 10) 0) =>  2048
+ (dpb 1 (byte 2 10) 2048) =>  1024
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+byte, deposit-field, ldb

+

Notes:

+

+

+ (logbitp j (dpb m (byte s p) n))
+ ==  (if (and (>= j p) (< j (+ p s)))
+        (logbitp (- j p) m)
+        (logbitp j n))
+
+

+In general,

+

+ (dpb x (byte 0 y) z) =>  z
+
+

+for all valid values of x, y, and z.

+Historically, the name ``dpb'' comes from a DEC PDP-10 assembly language instruction meaning ``deposit byte.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dribbl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dribbl.htm new file mode 100644 index 00000000..8e2ad627 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_dribbl.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function DRIBBLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function DRIBBLE

+

Syntax:

+

+ +dribble &optional pathname => implementation-dependent

+

+

Arguments and Values:

+

+pathname---a pathname designator.

+

Description:

+

+Either binds *standard-input* and *standard-output* or takes other appropriate action, so as to send a record of the input/output interaction to a file named by pathname. dribble is intended to create a readable record of an interactive session.

+ If pathname is a logical pathname, it is translated into a physical pathname as if by calling translate-logical-pathname.

+(dribble) terminates the recording of input and output and closes the dribble file.

+ If dribble is called while a stream to a ``dribble file'' is still open from a previous call to dribble, the effect is implementation-defined. For example, the already-open stream might be closed, or dribbling might occur both to the old stream and to a new one, or the old stream might stay open but not receive any further output, or the new request might be ignored, or some other action might be taken.

+

Examples: None. +

+

Affected By:

+

+The implementation.

+

Exceptional Situations:

+

+ If a failure occurs when performing some operation on the file system while creating the dribble file, an error of type file-error is signaled.

+ An error of type file-error might be signaled if pathname is a designator for a wild pathname.

+

See Also:

+

+ Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+

+dribble can return before subsequent forms are executed. It also can enter a recursive interaction loop, returning only when (dribble) is done.

+ dribble is intended primarily for interactive debugging; its effect cannot be relied upon when used in a program.

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_echo_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_echo_s.htm new file mode 100644 index 00000000..1b9881e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_echo_s.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function ECHO-STREAM-INPUT-STREAM... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ECHO-STREAM-INPUT-STREAM, ECHO-STREAM-OUTPUT-STREAM

+

+

Syntax:

+

+ +echo-stream-input-stream echo-stream => input-stream

+ +echo-stream-output-stream echo-stream => output-stream

+

+

Arguments and Values:

+

+echo-stream---an echo stream.

+input-stream---an input stream.

+output-stream---an output stream.

+

Description:

+

+echo-stream-input-stream returns the input stream from which echo-stream receives input.

+echo-stream-output-stream returns the output stream to which echo-stream sends output.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ed.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ed.htm new file mode 100644 index 00000000..3f0880b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ed.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function ED + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ED

+

Syntax:

+

+ +ed &optional x => implementation-dependent

+

+

Arguments and Values:

+

+ x---nil, a pathname, a string, or a function name. The default is nil.

+

Description:

+

+ed invokes the editor if the implementation provides a resident editor.

+If x is nil, the editor is entered. If the editor had been previously entered, its prior state is resumed, if possible.

+If x is a pathname or string, it is taken as the pathname designator for a file to be edited.

+If x is a function name, the text of its definition is edited. The means by which the function text is obtained is implementation-defined.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences are undefined if the implementation does not provide a resident editor.

+Might signal type-error if its argument is supplied but is not a symbol, a pathname, or nil.

+ If a failure occurs when performing some operation on the file system while attempting to edit a file, an error of type file-error is signaled.

+ An error of type file-error might be signaled if x is a designator for a wild pathname.

+Implementation-dependent additional conditions might be signaled as well.

+

See Also:

+

+pathname, logical-pathname, compile-file, load, Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_elt.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_elt.htm new file mode 100644 index 00000000..bcaa3944 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_elt.htm @@ -0,0 +1,65 @@ + + + +CLHS: Accessor ELT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor ELT

+

Syntax:

+

+ +elt sequence index => object

+ +(setf (elt sequence index) new-object)

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+index---a valid sequence index for sequence.

+object---an object.

+new-object---an object.

+

Description:

+

+Accesses the element of sequence specified by index.

+

Examples:

+

+

+ (setq str (copy-seq "0123456789")) =>  "0123456789"
+ (elt str 6) =>  #\6
+ (setf (elt str 0) #\#) =>  #\#
+ str =>  "#123456789"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence. Should signal an error of type type-error if index is not a valid sequence index for sequence.

+

See Also:

+

+aref, nth, Section 3.2.1 (Compiler Terminology)

+

Notes:

+

+aref may be used to access vector elements that are beyond the vector's fill pointer.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_encode.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_encode.htm new file mode 100644 index 00000000..1ab110c2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_encode.htm @@ -0,0 +1,58 @@ + + + +CLHS: function ENCODE-UNIVERSAL-TIME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +function ENCODE-UNIVERSAL-TIME

+

Syntax:

+

+ +encode-universal-time second minute hour date month year &optional time-zone

=> universal-time

+

+

Arguments and Values:

+

+second, minute, hour, date, month, year, time-zone---the corresponding parts of a decoded time. (Note that some of the nine values in a full decoded time are redundant, and so are not used as inputs to this function.)

+universal-time---a universal time.

+

Description:

+

+encode-universal-time converts a time from Decoded Time format to a universal time.

+If time-zone is supplied, no adjustment for daylight savings time is performed.

+

Examples:

+

+

+ (encode-universal-time 0 0 0 1 1 1900 0) =>  0
+ (encode-universal-time 0 0 1 4 7 1976 5) =>  2414296800
+;; The next example assumes Eastern Daylight Time.
+ (encode-universal-time 0 0 1 4 7 1976) =>  2414293200
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+decode-universal-time, get-decoded-time

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_endp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_endp.htm new file mode 100644 index 00000000..e23f39c1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_endp.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function ENDP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ENDP

+

Syntax:

+

+ +endp list => generalized-boolean

+

+

Arguments and Values:

+

+list---a list, which might be a dotted list or a circular list.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if list is the empty list. Returns false if list is a cons.

+

Examples:

+

+

+ (endp nil) =>  true
+ (endp '(1 2)) =>  false
+ (endp (cddr '(1 2))) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if list is not a list.

+

See Also: None. +

+

Notes:

+

+The purpose of endp is to test for the end of proper list. Since endp does not descend into a cons, it is well-defined to pass it a dotted list. However, if shorter ``lists'' are iteratively produced by calling cdr on such a dotted list and those ``lists'' are tested with endp, a situation that has undefined consequences will eventually result when the non-nil atom (which is not in fact a list) finally becomes the argument to endp. Since this is the usual way in which endp is used, it is conservative programming style and consistent with the intent of endp to treat endp as simply a function on proper lists which happens not to enforce an argument type of proper list except when the argument is atomic.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensu_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensu_1.htm new file mode 100644 index 00000000..fb9a91e3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensu_1.htm @@ -0,0 +1,56 @@ + + + +CLHS: Function ENSURE-DIRECTORIES-EXIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ENSURE-DIRECTORIES-EXIST

+

Syntax:

+

+ +ensure-directories-exist pathspec &key verbose => pathspec, created

+

+

Arguments and Values:

+

+pathspec---a pathname designator.

+verbose---a generalized boolean.

+created---a generalized boolean.

+

Description:

+

+Tests whether the directories containing the specified file actually exist, and attempts to create them if they do not.

+If the containing directories do not exist and if verbose is true, then the implementation is permitted (but not required) to perform output to standard output saying what directories were created. If the containing directories exist, or if verbose is false, this function performs no output.

+The primary value is the given pathspec so that this operation can be straightforwardly composed with other file manipulation expressions. The secondary value, created, is true if any directories were created.

+

Examples: None. +

+

Affected By:

+

+The host computer's file system.

+

Exceptional Situations:

+

+ An error of type file-error is signaled if the host, device, or directory part of pathspec is wild.

+ If the directory creation attempt is not successful, an error of type file-error is signaled; if this occurs, it might be the case that none, some, or all of the requested creations have actually occurred within the file system.

+

See Also:

+

+probe-file, open, Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensure.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensure.htm new file mode 100644 index 00000000..2e716c5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ensure.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function ENSURE-GENERIC-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ENSURE-GENERIC-FUNCTION

+

Syntax:

+

+ +ensure-generic-function function-name &key argument-precedence-order declare documentation environment generic-function-class lambda-list method-class method-combination

=> generic-function

+

+

Arguments and Values:

+

+function-name---a function name.

+The keyword arguments correspond to the option arguments of defgeneric, except that the :method-class and :generic-function-class arguments can be class objects as well as names.

+Method-combination -- method combination object.

+Environment -- the same as the &environment argument to macro expansion functions and is used to distinguish between compile-time and run-time environments.

+ generic-function---a generic function object.

+

Description:

+

+The function ensure-generic-function is used to define a globally named generic function with no methods or to specify or modify options and declarations that pertain to a globally named generic function as a whole.

+If function-name is not fbound in the global environment, a new generic function is created. If (fdefinition function-name) is an ordinary function, a macro, or a special operator, an error is signaled.

+If function-name is a list, it must be of the form (setf symbol). If function-name specifies a generic function that has a different value for any of the following arguments, the generic function is modified to have the new value: :argument-precedence-order, :declare, :documentation, :method-combination.

+If function-name specifies a generic function that has a different value for the :lambda-list argument, and the new value is congruent with the lambda lists of all existing methods or there are no methods, the value is changed; otherwise an error is signaled.

+If function-name specifies a generic function that has a different value for the :generic-function-class argument and if the new generic function class is compatible with the old, change-class is called to change the class of the generic function; otherwise an error is signaled.

+If function-name specifies a generic function that has a different value for the :method-class argument, the value is changed, but any existing methods are not changed.

+

Examples: None. +

+

Affected By:

+

+Existing function binding of function-name.

+

Exceptional Situations:

+

+If (fdefinition function-name) is an ordinary function, a macro, or a special operator, an error of type error is signaled.

+If function-name specifies a generic function that has a different value for the :lambda-list argument, and the new value is not congruent with the lambda list of any existing method, an error of type error is signaled.

+If function-name specifies a generic function that has a different value for the :generic-function-class argument and if the new generic function class not is compatible with the old, an error of type error is signaled.

+

See Also:

+

+defgeneric

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq.htm new file mode 100644 index 00000000..22128460 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq.htm @@ -0,0 +1,97 @@ + + + +CLHS: Function EQ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EQ

+

Syntax:

+

+ +eq x y => generalized-boolean

+

+

Arguments and Values:

+

+x---an object.

+y---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if its arguments are the same, identical object; otherwise, returns false.

+

Examples:

+ +

+ (eq 'a 'b) =>  false
+ (eq 'a 'a) =>  true
+ (eq 3 3)
+=>  true
+OR=>  false
+ (eq 3 3.0) =>  false
+ (eq 3.0 3.0)
+=>  true
+OR=>  false
+ (eq #c(3 -4) #c(3 -4))
+=>  true
+OR=>  false
+ (eq #c(3 -4.0) #c(3 -4)) =>  false
+ (eq (cons 'a 'b) (cons 'a 'c)) =>  false
+ (eq (cons 'a 'b) (cons 'a 'b)) =>  false
+ (eq '(a . b) '(a . b))
+=>  true
+OR=>  false
+ (progn (setq x (cons 'a 'b)) (eq x x)) =>  true
+ (progn (setq x '(a . b)) (eq x x)) =>  true
+ (eq #\A #\A)
+=>  true
+OR=>  false
+ (let ((x "Foo")) (eq x x)) =>  true
+ (eq "Foo" "Foo")
+=>  true
+OR=>  false
+ (eq "Foo" (copy-seq "Foo")) =>  false
+ (eq "FOO" "foo") =>  false
+ (eq "string-seq" (copy-seq "string-seq")) =>  false
+ (let ((x 5)) (eq x x))
+=>  true
+OR=>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+eql, equal, equalp, =, Section 3.2 (Compilation)

+

Notes:

+ Objects that appear the same when printed are not necessarily eq to each other. Symbols that print the same usually are eq to each other because of the use of the intern function. However, numbers with the same value need not be eq, and two similar lists are usually not identical.

+An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number.

+Most Common Lisp operators use eql rather than eq to compare objects, or else they default to eql and only use eq if specifically requested to do so. However, the following operators are defined to use eq rather than eql in a way that cannot be overridden by the code which employs them:

+

+catch           getf     throw  
+get             remf            
+get-properties  remprop  
+
+

Figure 5-11. Operators that always prefer EQ over EQL

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq_sle.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq_sle.htm new file mode 100644 index 00000000..9033fb40 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eq_sle.htm @@ -0,0 +1,102 @@ + + + +CLHS: Function =, /=, <, >, <=, >= + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function =, /=, <, >, <=, >=

+

Syntax:

+

+ += &rest numbers+ => generalized-boolean

+ +/= &rest numbers+ => generalized-boolean

+ +< &rest numbers+ => generalized-boolean

+ +> &rest numbers+ => generalized-boolean

+ +<= &rest numbers+ => generalized-boolean

+ +>= &rest numbers+ => generalized-boolean

+

+

Arguments and Values:

+

+number---for <, >, <=, >=: a real; for =, /=: a number.

+generalized-boolean---a generalized boolean.

+

Description:

+

+=, /=, <, >, <=, and >= perform arithmetic comparisons on their arguments as follows:

+

=

+The value of = is true if all numbers are the same in value; otherwise it is false. Two complexes are considered equal by = if their real and imaginary parts are equal according to =.

+

/=

+The value of /= is true if no two numbers are the same in value; otherwise it is false.

+

<

+The value of < is true if the numbers are in monotonically increasing order; otherwise it is false.

+

>

+The value of > is true if the numbers are in monotonically decreasing order; otherwise it is false.

+

<=

+The value of <= is true if the numbers are in monotonically nondecreasing order; otherwise it is false.

+

>=

+The value of >= is true if the numbers are in monotonically nonincreasing order; otherwise it is false.

+=, /=, <, >, <=, and >= perform necessary type conversions.

+

Examples:

+

+The uses of these functions are illustrated in the next figure.

+

+(= 3 3) is true.              (/= 3 3) is false.             
+(= 3 5) is false.             (/= 3 5) is true.              
+(= 3 3 3 3) is true.          (/= 3 3 3 3) is false.         
+(= 3 3 5 3) is false.         (/= 3 3 5 3) is false.         
+(= 3 6 5 2) is false.         (/= 3 6 5 2) is true.          
+(= 3 2 3) is false.           (/= 3 2 3) is false.           
+(< 3 5) is true.              (<= 3 5) is true.              
+(< 3 -5) is false.            (<= 3 -5) is false.            
+(< 3 3) is false.             (<= 3 3) is true.              
+(< 0 3 4 6 7) is true.        (<= 0 3 4 6 7) is true.        
+(< 0 3 4 4 6) is false.       (<= 0 3 4 4 6) is true.        
+(> 4 3) is true.              (>= 4 3) is true.              
+(> 4 3 2 1 0) is true.        (>= 4 3 2 1 0) is true.        
+(> 4 3 3 2 0) is false.       (>= 4 3 3 2 0) is true.        
+(> 4 3 1 2 0) is false.       (>= 4 3 1 2 0) is false.       
+(= 3) is true.                (/= 3) is true.                
+(< 3) is true.                (<= 3) is true.                
+(= 3.0 #c(3.0 0.0)) is true.  (/= 3.0 #c(3.0 1.0)) is true.  
+(= 3 3.0) is true.            (= 3.0s0 3.0d0) is true.       
+(= 0.0 -0.0) is true.         (= 5/2 2.5) is true.           
+(> 0.0 -0.0) is false.        (= 0 -0.0) is true.            
+(<= 0 x 9) is true if x is between 0 and 9, inclusive                               
+(< 0.0 x 1.0) is true if x is between 0.0 and 1.0, exclusive                               
+(< -1 j (length v)) is true if j is a valid array index for a vector v                               
+
+

Figure 12-13. Uses of /=, =, <, >, <=, and >=

+

Affected By: None. +

+

Exceptional Situations:

+

+Might signal type-error if some argument is not a real. Might signal arithmetic-error if otherwise unable to fulfill its contract.

+

See Also: None. +

+

Notes:

+

+= differs from eql in that (= 0.0 -0.0) is always true, because = compares the mathematical values of its operands, whereas eql compares the representational values, so to speak.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eql.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eql.htm new file mode 100644 index 00000000..47c80ceb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eql.htm @@ -0,0 +1,82 @@ + + + +CLHS: Function EQL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EQL

+

Syntax:

+

+ +eql x y => generalized-boolean

+

+

Arguments and Values:

+

+x---an object.

+y---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+The value of eql is true of two objects, x and y, in the folowing cases:

1. If x and y are eq.
2. If x and y are both numbers of the same type and the same value.
3. If they are both characters that represent the same character.

+Otherwise the value of eql is false.

+If an implementation supports positive and negative zeros as distinct values, then (eql 0.0 -0.0) returns false. Otherwise, when the syntax -0.0 is read it is interpreted as the value 0.0, and so (eql 0.0 -0.0) returns true.

+

Examples:

+

+

+ (eql 'a 'b) =>  false
+ (eql 'a 'a) =>  true
+ (eql 3 3) =>  true
+ (eql 3 3.0) =>  false
+ (eql 3.0 3.0) =>  true
+ (eql #c(3 -4) #c(3 -4)) =>  true
+ (eql #c(3 -4.0) #c(3 -4)) =>  false
+ (eql (cons 'a 'b) (cons 'a 'c)) =>  false
+ (eql (cons 'a 'b) (cons 'a 'b)) =>  false
+ (eql '(a . b) '(a . b))
+=>  true
+OR=>  false
+ (progn (setq x (cons 'a 'b)) (eql x x)) =>  true
+ (progn (setq x '(a . b)) (eql x x)) =>  true
+ (eql #\A #\A) =>  true
+ (eql "Foo" "Foo")
+=>  true
+OR=>  false
+ (eql "Foo" (copy-seq "Foo")) =>  false
+ (eql "FOO" "foo") =>  false
+
+

+Normally (eql 1.0s0 1.0d0) is false, under the assumption that 1.0s0 and 1.0d0 are of distinct data types. However, implementations that do not provide four distinct floating-point formats are permitted to ``collapse'' the four formats into some smaller number of them; in such an implementation (eql 1.0s0 1.0d0) might be true.

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+eq, equal, equalp, =, char=

+

Notes:

+

+eql is the same as eq, except that if the arguments are characters or numbers of the same type then their values are compared. Thus eql tells whether two objects are conceptually the same, whereas eq tells whether two objects are implementationally identical. It is for this reason that eql, not eq, is the default comparison predicate for operators that take sequences as arguments.

+eql may not be true of two floats even when they represent the same value. = is used to compare mathematical values.

+Two complex numbers are considered to be eql if their real parts are eql and their imaginary parts are eql. For example, (eql #C(4 5) #C(4 5)) is true and (eql #C(4 5) #C(4.0 5.0)) is false. Note that while (eql #C(5.0 0.0) 5.0) is false, (eql #C(5 0) 5) is true. In the case of (eql #C(5.0 0.0) 5.0) the two arguments are of different types, and so cannot satisfy eql. In the case of (eql #C(5 0) 5), #C(5 0) is not a complex number, but is automatically reduced to the integer 5.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equal.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equal.htm new file mode 100644 index 00000000..ce9bd3b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equal.htm @@ -0,0 +1,103 @@ + + + +CLHS: Function EQUAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EQUAL

+

Syntax:

+

+ +equal x y => generalized-boolean

+

+

Arguments and Values:

+

+x---an object.

+y---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if x and y are structurally similar (isomorphic) objects. Objects are treated as follows by equal.

+

Symbols, Numbers, and Characters

+equal is true of two objects if they are symbols that are eq, if they are numbers that are eql, or if they are characters that are eql.

+

Conses

+For conses, equal is defined recursively as the two cars being equal and the two cdrs being equal.

+

Arrays

+Two arrays are equal only if they are eq, with one exception: strings and bit vectors are compared element-by-element (using eql). If either x or y has a fill pointer, the fill pointer limits the number of elements examined by equal. Uppercase and lowercase letters in strings are considered by equal to be different.

+

Pathnames

+Two pathnames are equal if and only if all the corresponding components (host, device, and so on) are equivalent. Whether or not uppercase and lowercase letters are considered equivalent in strings appearing in components is implementation-dependent. pathnames that are equal should be functionally equivalent.

+

Other (Structures, hash-tables, instances, ...)

+Two other objects are equal only if they are eq.

+

+

+ equal does not descend any objects other than the ones explicitly specified above. The next figure summarizes the information given in the previous list. In addition, the figure specifies the priority of the behavior of equal, with upper entries taking priority over lower ones.

+

+Type          Behavior                     
+number        uses eql                     
+character     uses eql                     
+cons          descends                     
+bit vector    descends                     
+string        descends                     
+pathname      ``functionally equivalent''  
+structure     uses eq                      
+Other array   uses eq                      
+hash table    uses eq                      
+Other object  uses eq                      
+
+

Figure 5-12. Summary and priorities of behavior of equal

+Any two objects that are eql are also equal.

+equal may fail to terminate if x or y is circular.

+

Examples:

+

+

+ (equal 'a 'b) =>  false
+ (equal 'a 'a) =>  true
+ (equal 3 3) =>  true
+ (equal 3 3.0) =>  false
+ (equal 3.0 3.0) =>  true
+ (equal #c(3 -4) #c(3 -4)) =>  true
+ (equal #c(3 -4.0) #c(3 -4)) =>  false
+ (equal (cons 'a 'b) (cons 'a 'c)) =>  false
+ (equal (cons 'a 'b) (cons 'a 'b)) =>  true
+ (equal #\A #\A) =>  true
+ (equal #\A #\a) =>  false
+ (equal "Foo" "Foo") =>  true
+ (equal "Foo" (copy-seq "Foo")) =>  true
+ (equal "FOO" "foo") =>  false
+ (equal "This-string" "This-string") =>  true
+ (equal "This-string" "this-string") =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+eq, eql, equalp, =, string=, string-equal, char=, char-equal, tree-equal

+

Notes:

+

+ Object equality is not a concept for which there is a uniquely determined correct algorithm. The appropriateness of an equality predicate can be judged only in the context of the needs of some particular program. Although these functions take any type of argument and their names sound very generic, equal and equalp are not appropriate for every application.

+A rough rule of thumb is that two objects are equal if and only if their printed representations are the same.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equalp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equalp.htm new file mode 100644 index 00000000..aa523d24 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_equalp.htm @@ -0,0 +1,111 @@ + + + +CLHS: Function EQUALP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EQUALP

+

Syntax:

+

+ +equalp x y => generalized-boolean

+

+

Arguments and Values:

+

+x---an object.

+y---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if x and y are equal, or if they have components that are of the same type as each other and if those components are equalp; specifically, equalp returns true in the following cases:

Characters

+If two characters are char-equal.

+

Numbers

+If two numbers are the same under =.

+

Conses

+If the two cars in the conses are equalp and the two cdrs in the conses are equalp.

+

Arrays

+If two arrays have the same number of dimensions, the dimensions match, and the corresponding active elements are equalp. The types for which the arrays are specialized need not match; for example, a string and a general array that happens to contain the same characters are equalp. Because equalp performs element-by-element comparisons of strings and ignores the case of characters, case distinctions are ignored when equalp compares strings.

+

Structures

+If two structures S1 and S2 have the same class and the value of each slot in S1 is the same under equalp as the value of the corresponding slot in S2.

+

Hash Tables

+equalp descends hash-tables by first comparing the count of entries and the :test function; if those are the same, it compares the keys of the tables using the :test function and then the values of the matching keys using equalp recursively.

+

+ equalp does not descend any objects other than the ones explicitly specified above. The next figure summarizes the information given in the previous list. In addition, the figure specifies the priority of the behavior of equalp, with upper entries taking priority over lower ones.

+

+Type          Behavior                      
+number        uses =                        
+character     uses char-equal               
+cons          descends                      
+bit vector    descends                      
+string        descends                      
+pathname      same as equal                 
+structure     descends, as described above  
+Other array   descends                      
+hash table    descends, as described above  
+Other object  uses eq                       
+
+

Figure 5-13. Summary and priorities of behavior of equalp

+

Examples:

+

+

+ (equalp 'a 'b) =>  false
+ (equalp 'a 'a) =>  true
+ (equalp 3 3) =>  true
+ (equalp 3 3.0) =>  true
+ (equalp 3.0 3.0) =>  true
+ (equalp #c(3 -4) #c(3 -4)) =>  true
+ (equalp #c(3 -4.0) #c(3 -4)) =>  true
+ (equalp (cons 'a 'b) (cons 'a 'c)) =>  false
+ (equalp (cons 'a 'b) (cons 'a 'b)) =>  true
+ (equalp #\A #\A) =>  true
+ (equalp #\A #\a) =>  true
+ (equalp "Foo" "Foo") =>  true
+ (equalp "Foo" (copy-seq "Foo")) =>  true
+ (equalp "FOO" "foo") =>  true
+
+ +
+ (setq array1 (make-array 6 :element-type 'integer
+                            :initial-contents '(1 1 1 3 5 7))) 
+=>  #(1 1 1 3 5 7)
+ (setq array2 (make-array 8 :element-type 'integer
+                            :initial-contents '(1 1 1 3 5 7 2 6)
+                            :fill-pointer 6))
+=>  #(1 1 1 3 5 7)
+ (equalp array1 array2) =>  true
+ (setq vector1 (vector 1 1 1 3 5 7)) =>  #(1 1 1 3 5 7)
+ (equalp array1 vector1) =>  true 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+eq, eql, equal, =, string=, string-equal, char=, char-equal

+

Notes:

+

+ Object equality is not a concept for which there is a uniquely determined correct algorithm. The appropriateness of an equality predicate can be judged only in the context of the needs of some particular program. Although these functions take any type of argument and their names sound very generic, equal and equalp are not appropriate for every application.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_error.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_error.htm new file mode 100644 index 00000000..e6a0ea3e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_error.htm @@ -0,0 +1,105 @@ + + + +CLHS: Function ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ERROR

+

Syntax:

+

+ +error datum &rest arguments =>|

+

+

Arguments and Values:

+

+datum, arguments---designators for a condition of default type simple-error.

+

Description:

+

+error effectively invokes signal on the denoted condition.

+If the condition is not handled, (invoke-debugger condition) is done. As a consequence of calling invoke-debugger, error cannot directly return; the only exit from error can come by non-local transfer of control in a handler or by use of an interactive debugging command.

+

Examples:

+

+

+ (defun factorial (x)
+   (cond ((or (not (typep x 'integer)) (minusp x))
+          (error "~S is not a valid argument to FACTORIAL." x))
+         ((zerop x) 1)
+         (t (* x (factorial (- x 1))))))
+=>  FACTORIAL
+(factorial 20)
+=>  2432902008176640000
+(factorial -1)
+>>  Error: -1 is not a valid argument to FACTORIAL.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Return to Lisp Toplevel.
+>>  Debug> 
+
+

+

+ (setq a 'fred)
+=>  FRED
+ (if (numberp a) (1+ a) (error "~S is not a number." A))
+>>  Error: FRED is not a number.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Return to Lisp Toplevel.
+>>  Debug> :Continue 1
+>>  Return to Lisp Toplevel.
+ 
+ (define-condition not-a-number (error) 
+                   ((argument :reader not-a-number-argument :initarg :argument))
+   (:report (lambda (condition stream)
+              (format stream "~S is not a number."
+                      (not-a-number-argument condition)))))
+=>  NOT-A-NUMBER
+ 
+ (if (numberp a) (1+ a) (error 'not-a-number :argument a))
+>>  Error: FRED is not a number.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Return to Lisp Toplevel.
+>>  Debug> :Continue 1
+>>  Return to Lisp Toplevel.
+
+

+

Side Effects:

+

+Handlers for the specified condition, if any, are invoked and might have side effects. Program execution might stop, and the debugger might be entered.

+

Affected By:

+

+Existing handler bindings.

+*break-on-signals*

+

Exceptional Situations: None. +

+Signals an error of type type-error if datum and arguments are not designators for a condition.

+

See Also:

+

+cerror, signal, format, ignore-errors, *break-on-signals*, handler-bind, Section 9.1 (Condition System Concepts)

+

Notes:

+

+Some implementations may provide debugger commands for interactively returning from individual stack frames. However, it should be possible for the programmer to feel confident about writing code like:

+

+ (defun wargames:no-win-scenario ()
+   (if (error "pushing the button would be stupid."))
+   (push-the-button))
+
+ In this scenario, there should be no chance that error will return and the button will get pushed.

+While the meaning of this program is clear and it might be proven `safe' by a formal theorem prover, such a proof is no guarantee that the program is safe to execute. Compilers have been known to have bugs, computers to have signal glitches, and human beings to manually intervene in ways that are not always possible to predict. Those kinds of errors, while beyond the scope of the condition system to formally model, are not beyond the scope of things that should seriously be considered when writing code that could have the kinds of sweeping effects hinted at by this example.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eval.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eval.htm new file mode 100644 index 00000000..1d481848 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_eval.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function EVAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EVAL

+

Syntax:

+

+ +eval form => result*

+

+

Arguments and Values:

+

+form---a form.

+results---the values yielded by the evaluation of form.

+

Description:

+

+Evaluates form in the current dynamic environment and the null lexical environment.

+eval is a user interface to the evaluator.

+The evaluator expands macro calls as if through the use of macroexpand-1.

+ Constants appearing in code processed by eval are not copied nor coalesced. The code resulting from the execution of eval references objects that are eql to the corresponding objects in the source code.

+

Examples:

+

+

+ (setq form '(1+ a) a 999) =>  999
+ (eval form) =>  1000
+ (eval 'form) =>  (1+ A)
+ (let ((a '(this would break if eval used local value))) (eval form))
+=>  1000
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ macroexpand-1, Section 3.1.2 (The Evaluation Model)

+

Notes:

+

+To obtain the current dynamic value of a symbol, use of symbol-value is equivalent (and usually preferable) to use of eval.

+Note that an eval form involves two levels of evaluation for its argument. First, form is evaluated by the normal argument evaluation mechanism as would occur with any call. The object that results from this normal argument evaluation becomes the value of the form parameter, and is then evaluated as part of the eval form. For example:

+

+ (eval (list 'cdr (car '((quote (a . b)) c)))) =>  b
+
+ The argument form (list 'cdr (car '((quote (a . b)) c))) is evaluated in the usual way to produce the argument (cdr (quote (a . b))); eval then evaluates its argument, (cdr (quote (a . b))), to produce b. Since a single evaluation already occurs for any argument form in any function form, eval is sometimes said to perform ``an extra level of evaluation.''

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_evenpc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_evenpc.htm new file mode 100644 index 00000000..c4c7d0f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_evenpc.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function EVENP, ODDP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EVENP, ODDP

+

Syntax:

+

+ +evenp integer => generalized-boolean

+ +oddp integer => generalized-boolean

+

+

Arguments and Values:

+

+integer---an integer.

+generalized-boolean---a generalized boolean.

+

Description:

+

+evenp returns true if integer is even (divisible by two); otherwise, returns false.

+oddp returns true if integer is odd (not divisible by two); otherwise, returns false.

+

Examples:

+

+

+ (evenp 0) =>  true
+ (oddp 10000000000000000000000) =>  false
+ (oddp -1) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if integer is not an integer.

+

See Also: None. +

+

Notes:

+

+

+ (evenp integer) ==  (not (oddp integer))
+ (oddp integer)  ==  (not (evenp integer))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_everyc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_everyc.htm new file mode 100644 index 00000000..5b9f9ea7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_everyc.htm @@ -0,0 +1,77 @@ + + + +CLHS: Function EVERY, SOME, NOTEVERY, NOTANY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EVERY, SOME, NOTEVERY, NOTANY

+

Syntax:

+

+ +every predicate &rest sequences+ => generalized-boolean

+ +some predicate &rest sequences+ => result

+ +notevery predicate &rest sequences+ => generalized-boolean

+ +notany predicate &rest sequences+ => generalized-boolean

+

+

Arguments and Values:

+

+predicate---a designator for a function of as many arguments as there are sequences.

+sequence---a sequence.

+result---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+every, some, notevery, and notany test elements of sequences for satisfaction of a given predicate. The first argument to predicate is an element of the first sequence; each succeeding argument is an element of a succeeding sequence.

+Predicate is first applied to the elements with index 0 in each of the sequences, and possibly then to the elements with index 1, and so on, until a termination criterion is met or the end of the shortest of the sequences is reached.

+every returns false as soon as any invocation of predicate returns false. If the end of a sequence is reached, every returns true. Thus, every returns true if and only if every invocation of predicate returns true.

+some returns the first non-nil value which is returned by an invocation of predicate. If the end of a sequence is reached without any invocation of the predicate returning true, some returns false. Thus, some returns true if and only if some invocation of predicate returns true.

+notany returns false as soon as any invocation of predicate returns true. If the end of a sequence is reached, notany returns true. Thus, notany returns true if and only if it is not the case that any invocation of predicate returns true.

+notevery returns true as soon as any invocation of predicate returns false. If the end of a sequence is reached, notevery returns false. Thus, notevery returns true if and only if it is not the case that every invocation of predicate returns true.

+

Examples:

+

+

+ (every #'characterp "abc") =>  true
+ (some #'= '(1 2 3 4 5) '(5 4 3 2 1)) =>  true
+ (notevery #'< '(1 2 3 4) '(5 6 7 8) '(9 10 11 12)) =>  false
+ (notany #'> '(1 2 3 4) '(5 6 7 8) '(9 10 11 12)) =>  true 
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its first argument is neither a symbol nor a function or if any subsequent argument is not a proper sequence.

+Other exceptional situations are possible, depending on the nature of the predicate.

+

See Also:

+

+and, or, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+

+ (notany predicate sequence*) ==  (not (some predicate sequence*))
+ (notevery predicate sequence*) ==  (not (every predicate sequence*))
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_exp_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_exp_e.htm new file mode 100644 index 00000000..8e3cd87b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_exp_e.htm @@ -0,0 +1,85 @@ + + + +CLHS: Function EXP, EXPT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EXP, EXPT

+

Syntax:

+

+ +exp number => result

+ +expt base-number power-number => result

+

+

Arguments and Values:

+

+number---a number.

+base-number---a number.

+power-number---a number.

+result---a number.

+

Description:

+

+exp and expt perform exponentiation.

+exp returns e raised to the power number, where e is the base of the natural logarithms. exp has no branch cut.

+expt returns base-number raised to the power power-number. If the base-number is a rational and power-number is an integer, the calculation is exact and the result will be of type rational; otherwise a floating-point approximation might result. For expt of a complex rational to an integer power, the calculation must be exact and the result is of type (or rational (complex rational)).

+The result of expt can be a complex, even when neither argument is a complex, if base-number is negative and power-number is not an integer. The result is always the principal complex value. For example, (expt -8 1/3) is not permitted to return -2, even though -2 is one of the cube roots of -8. The principal cube root is a complex approximately equal to #C(1.0 1.73205), not -2.

+expt is defined as b^x = e^x log b. This defines the principal values precisely. The range of expt is the entire complex plane. Regarded as a function of x, with b fixed, there is no branch cut. Regarded as a function of b, with x fixed, there is in general a branch cut along the negative real axis, continuous with quadrant II. The domain excludes the origin. By definition, 0^0=1. If b=0 and the real part of x is strictly positive, then b^x=0. For all other values of x, 0^x is an error.

+When power-number is an integer 0, then the result is always the value one in the type of base-number, even if the base-number is zero (of any type). That is:

+

+ (expt x 0) ==  (coerce 1 (type-of x))
+
+ If power-number is a zero of any other type, then the result is also the value one, in the type of the arguments after the application of the contagion rules in Section 12.1.1.2 (Contagion in Numeric Operations), with one exception: the consequences are undefined if base-number is zero when power-number is zero and not of type integer.

+

Examples:

+

+ +

+ (exp 0) =>  1.0
+ (exp 1) =>  2.718282
+ (exp (log 5)) =>  5.0 
+ (expt 2 8) =>  256
+ (expt 4 .5) =>  2.0
+ (expt #c(0 1) 2) =>  -1
+ (expt #c(2 2) 3) =>  #C(-16 16)
+ (expt #c(2 2) 4) =>  -64 
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+log, Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes:

+

+Implementations of expt are permitted to use different algorithms for the cases of a power-number of type rational and a power-number of type float.

+

+ Note that by the following logic, (sqrt (expt x 3)) is not equivalent to (expt x 3/2).

+

+ (setq x (exp (/ (* 2 pi #c(0 1)) 3)))         ;exp(2.pi.i/3)
+ (expt x 3) =>  1 ;except for round-off error
+ (sqrt (expt x 3)) =>  1 ;except for round-off error
+ (expt x 3/2) =>  -1 ;except for round-off error
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_export.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_export.htm new file mode 100644 index 00000000..97202a29 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_export.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function EXPORT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function EXPORT

+

Syntax:

+

+ +export symbols &optional package => t

+

+

Arguments and Values:

+

+symbols---a designator for a list of symbols.

+ package---a package designator. The default is the current package.

+

Description:

+

+export makes one or more symbols that are accessible in package (whether directly or by inheritance) be external symbols of that package.

+If any of the symbols is already accessible as an external symbol of package, export has no effect on that symbol. If the symbol is present in package as an internal symbol, it is simply changed to external status. If it is accessible as an internal symbol via use-package, it is first imported into package, then exported. (The symbol is then present in the package whether or not package continues to use the package through which the symbol was originally inherited.)

+export makes each symbol accessible to all the packages that use package. All of these packages are checked for name conflicts: (export s p) does (find-symbol (symbol-name s) q) for each package q in (package-used-by-list p). Note that in the usual case of an export during the initial definition of a package, the result of package-used-by-list is nil and the name-conflict checking takes negligible time. When multiple changes are to be made, for example when export is given a list of symbols, it is permissible for the implementation to process each change separately, so that aborting from a name conflict caused by any but the first symbol in the list does not unexport the first symbol in the list. However, aborting from a name-conflict error caused by export of one of symbols does not leave that symbol accessible to some packages and inaccessible to others; with respect to each of symbols processed, export behaves as if it were as an atomic operation.

+A name conflict in export between one of symbols being exported and a symbol already present in a package that would inherit the newly-exported symbol may be resolved in favor of the exported symbol by uninterning the other one, or in favor of the already-present symbol by making it a shadowing symbol.

+

Examples:

+

+

+ (make-package 'temp :use nil) =>  #<PACKAGE "TEMP">
+ (use-package 'temp) =>  T
+ (intern "TEMP-SYM" 'temp) =>  TEMP::TEMP-SYM, NIL
+ (find-symbol "TEMP-SYM") =>  NIL, NIL
+ (export (find-symbol "TEMP-SYM" 'temp) 'temp) =>  T
+ (find-symbol "TEMP-SYM") =>  TEMP-SYM, :INHERITED
+
+

+

Side Effects:

+

+The package system is modified.

+

Affected By:

+

+Accessible symbols.

+

Exceptional Situations:

+

+If any of the symbols is not accessible at all in package, an error of type package-error is signaled that is correctable by permitting the user to interactively specify whether that symbol should be imported.

+

See Also:

+

+import, unexport, Section 11.1 (Package Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fbound.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fbound.htm new file mode 100644 index 00000000..9e56452c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fbound.htm @@ -0,0 +1,84 @@ + + + +CLHS: Function FBOUNDP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FBOUNDP

+

Syntax:

+

+ +fboundp name => generalized-boolean

+

+

Pronunciation:

+

+[,ef'bandpee]

+

Arguments and Values:

+

+ name---a function name.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if name is fbound; otherwise, returns false.

+

Examples:

+

+

+ (fboundp 'car) =>  true
+ (fboundp 'nth-value) =>  false
+ (fboundp 'with-open-file) =>  true
+ (fboundp 'unwind-protect) =>  true
+ (defun my-function (x) x) =>  MY-FUNCTION
+ (fboundp 'my-function) =>  true
+ (let ((saved-definition (symbol-function 'my-function)))
+   (unwind-protect (progn (fmakunbound 'my-function)
+                          (fboundp 'my-function))
+     (setf (symbol-function 'my-function) saved-definition)))
+=>  false
+ (fboundp 'my-function) =>  true
+ (defmacro my-macro (x) `',x) =>  MY-MACRO
+ (fboundp 'my-macro) =>  true
+ (fmakunbound 'my-function) =>  MY-FUNCTION
+ (fboundp 'my-function) =>  false
+ (flet ((my-function (x) x))
+   (fboundp 'my-function)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if name is not a function name.

+

See Also:

+

+symbol-function, fmakunbound, fdefinition

+

Notes:

+

+It is permissible to call symbol-function on any symbol that is fbound.

+fboundp is sometimes used to ``guard'' an access to the function cell, as in: +

+(if (fboundp x) (symbol-function x))
+
+

+ Defining a setf expander F does not cause the setf function (setf F) to become defined.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fdefin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fdefin.htm new file mode 100644 index 00000000..407a02cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fdefin.htm @@ -0,0 +1,60 @@ + + + +CLHS: Accessor FDEFINITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor FDEFINITION

+

+

Syntax:

+

+ +fdefinition function-name => definition

+ +(setf (fdefinition function-name) new-definition)

+

+

Arguments and Values:

+

+function-name---a function name. In the non-setf case, the name must be fbound in the global environment.

+definition---Current global function definition named by function-name.

+new-definition---a function.

+

Description:

+

+fdefinition accesses the current global function definition named by function-name. The definition may be a function or may be an object representing a special form or macro. The value returned by fdefinition when fboundp returns true but the function-name denotes a macro or special form is not well-defined, but fdefinition does not signal an error.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if function-name is not a function name.

+An error of type undefined-function is signaled in the non-setf case if function-name is not fbound.

+

See Also:

+

+fboundp, fmakunbound, macro-function, special-operator-p, symbol-function

+

Notes:

+

+fdefinition cannot access the value of a lexical function name produced by flet or labels; it can access only the global function value.

+setf can be used with fdefinition to replace a global function definition when the function-name's function definition does not represent a special form. setf of fdefinition requires a function as the new value. It is an error to set the fdefinition of a function-name to a symbol, a list, or the value returned by fdefinition on the name of a macro or special form.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_a.htm new file mode 100644 index 00000000..b25f6d37 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_a.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function FILE-AUTHOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILE-AUTHOR

+

Syntax:

+

+ +file-author pathspec => author

+

+

Arguments and Values:

+

+ pathspec---a pathname designator.

+author---a string or nil.

+

Description:

+

+Returns a string naming the author of the file specified by pathspec, or nil if the author's name cannot be determined.

+

Examples:

+

+

+ (with-open-file (stream ">relativity>general.text")
+   (file-author s))
+=>  "albert"
+
+

+

Affected By:

+ The host computer's file system.

+Other users of the file named by pathspec.

Exceptional Situations:

+

+ An error of type file-error is signaled if pathspec is wild.

+ An error of type file-error is signaled if the file system cannot perform the requested operation.

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_e.htm new file mode 100644 index 00000000..6f711239 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_e.htm @@ -0,0 +1,52 @@ + + + +CLHS: Function FILE-ERROR-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILE-ERROR-PATHNAME

+

Syntax:

+

+ +file-error-pathname condition => pathspec

+

+

Arguments and Values:

+

+condition---a condition of type file-error.

+pathspec---a pathname designator.

+

Description:

+

+Returns the ``offending pathname'' of a condition of type file-error.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+

See Also:

+

+file-error, Section 9 (Conditions)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_l.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_l.htm new file mode 100644 index 00000000..db105f0b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_l.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function FILE-LENGTH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILE-LENGTH

+

Syntax:

+

+ +file-length stream => length

+

+

Arguments and Values:

+

+stream---a stream associated with a file.

+length---a non-negative integer or nil.

+

Description:

+

+file-length returns the length of stream, or nil if the length cannot be determined.

+For a binary file, the length is measured in units of the element type of the stream.

+

Examples:

+

+

+ (with-open-file (s "decimal-digits.text" 
+                    :direction :output :if-exists :error)
+   (princ "0123456789" s)
+   (truename s))
+=>  #P"A:>Joe>decimal-digits.text.1"
+ (with-open-file (s "decimal-digits.text")
+   (file-length s))
+=>  10
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream associated with a file.

+

See Also:

+

+open

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_p.htm new file mode 100644 index 00000000..8a4be700 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_p.htm @@ -0,0 +1,98 @@ + + + +CLHS: Function FILE-POSITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILE-POSITION

+

Syntax:

+

+ +file-position stream => position

+ +file-position stream position-spec => success-p

+

+

Arguments and Values:

+

+stream---a stream.

+position-spec---a file position designator.

+position---a file position or nil.

+success-p---a generalized boolean.

+

Description:

+

+Returns or changes the current position within a stream.

+When position-spec is not supplied, file-position returns the current file position in the stream, or nil if this cannot be determined.

+When position-spec is supplied, the file position in stream is set to that file position (if possible). file-position returns true if the repositioning is performed successfully, or false if it is not.

+An integer returned by file-position of one argument should be acceptable as position-spec for use with the same file.

+For a character file, performing a single read-char or write-char operation may cause the file position to be increased by more than 1 because of character-set translations (such as translating between the Common Lisp f#\Newline character and an external ASCII carriage-return/line-feed sequence) and other aspects of the implementation. For a binary file, every read-byte or write-byte operation increases the file position by 1.

+

Examples:

+

+

+ (defun tester ()
+   (let ((noticed '()) file-written)
+     (flet ((notice (x) (push x noticed) x))
+       (with-open-file (s "test.bin" 
+                          :element-type '(unsigned-byte 8)
+                          :direction :output
+                          :if-exists :error)
+          (notice (file-position s)) ;1
+          (write-byte 5 s) 
+          (write-byte 6 s)
+          (let ((p (file-position s)))
+            (notice p) ;2
+            (notice (when p (file-position s (1- p))))) ;3
+          (write-byte 7 s)
+          (notice (file-position s)) ;4
+          (setq file-written (truename s)))
+        (with-open-file (s file-written
+                           :element-type '(unsigned-byte 8)
+                           :direction :input)
+          (notice (file-position s)) ;5
+          (let ((length (file-length s)))
+            (notice length) ;6
+            (when length
+              (dotimes (i length)
+                (notice (read-byte s)))))) ;7,...
+        (nreverse noticed))))
+=>  tester
+ (tester)
+=>  (0 2 T 2 0 2 5 7)
+OR=>  (0 2 NIL 3 0 3 5 6 7)
+OR=>  (NIL NIL NIL NIL NIL NIL)
+
+

+

Side Effects:

+

+When the position-spec argument is supplied, the file position in the stream might be moved.

+

Affected By:

+

+The value returned by file-position increases monotonically as input or output operations are performed.

+

Exceptional Situations:

+

+If position-spec is supplied, but is too large or otherwise inappropriate, an error is signaled.

+

See Also:

+

+file-length, file-string-length, open

+

Notes:

+

+Implementations that have character files represented as a sequence of records of bounded size might choose to encode the file position as, for example, <<record-number>>*<<max-record-size>>+<<character-within-record>>. This is a valid encoding because it increases monotonically as each character is read or written, though not necessarily by 1 at each step. An integer might then be considered ``inappropriate'' as position-spec to file-position if, when decoded into record number and character number, it turned out that the supplied record was too short for the specified character number.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_s.htm new file mode 100644 index 00000000..5bde4d23 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_s.htm @@ -0,0 +1,53 @@ + + + +CLHS: Function FILE-STRING-LENGTH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILE-STRING-LENGTH

+

+

Syntax:

+

+ +file-string-length stream object => length

+

+

Arguments and Values:

+

+stream---an output character file stream.

+object---a string or a character.

+length---a non-negative integer, or nil.

+

Description:

+

+file-string-length returns the difference between what (file-position stream) would be after writing object and its current value, or nil if this cannot be determined.

+The returned value corresponds to the current state of stream at the time of the call and might not be the same if it is called again when the state of the stream has changed.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_w.htm new file mode 100644 index 00000000..55deaa2c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_file_w.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function FILE-WRITE-DATE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILE-WRITE-DATE

+

Syntax:

+

+ +file-write-date pathspec => date

+

+

Arguments and Values:

+

+ pathspec---a pathname designator.

+date---a universal time or nil.

+

Description:

+

+Returns a universal time representing the time at which the file specified by pathspec was last written (or created), or returns nil if such a time cannot be determined.

+

Examples:

+

+

+ (with-open-file (s "noel.text" 
+                    :direction :output :if-exists :error)
+   (format s "~&Dear Santa,~2%I was good this year.  ~
+                Please leave lots of toys.~2%Love, Sue~
+             ~2%attachments: milk, cookies~%")
+   (truename s))
+=>  #P"CUPID:/susan/noel.text"
+ (with-open-file (s "noel.text")
+   (file-write-date s))
+=>  2902600800
+
+

+

Affected By:

+

+The host computer's file system.

+

Exceptional Situations:

+

+ An error of type file-error is signaled if pathspec is wild.

+ An error of type file-error is signaled if the file system cannot perform the requested operation.

+

See Also:

+

+Section 25.1.4.2 (Universal Time), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill.htm new file mode 100644 index 00000000..e2a437e4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function FILL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FILL

+

Syntax:

+

+ +fill sequence item &key start end => sequence

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+item---a sequence.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+

Description:

+

+Replaces the elements of sequence bounded by start and end with item.

+

Examples:

+

+

+ (fill (list 0 1 2 3 4 5) '(444)) =>  ((444) (444) (444) (444) (444) (444))
+ (fill (copy-seq "01234") #\e :start 3) =>  "012ee"
+ (setq x (vector 'a 'b 'c 'd 'e)) =>  #(A B C D E)
+ (fill x 'z :start 1 :end 3) =>  #(A Z Z D E)
+ x =>  #(A Z Z D E)
+ (fill x 'p) =>  #(P P P P P)
+ x =>  #(P P P P P)
+
+

+

Side Effects:

+

+Sequence is destructively modified.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence. Should signal an error of type type-error if start is not a non-negative integer. Should signal an error of type type-error if end is not a non-negative integer or nil.

+

See Also:

+

+replace, nsubstitute

+

Notes:

+

+(fill sequence item) == (nsubstitute-if item (constantly t) sequence)

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill_p.htm new file mode 100644 index 00000000..d88607f8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fill_p.htm @@ -0,0 +1,68 @@ + + + +CLHS: Accessor FILL-POINTER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor FILL-POINTER

+

Syntax:

+

+ +fill-pointer vector => fill-pointer

+ +(setf (fill-pointer vector) new-fill-pointer)

+

+

Arguments and Values:

+

+vector---a vector with a fill pointer.

+fill-pointer, new-fill-pointer---a valid fill pointer for the vector.

+

Description:

+

+Accesses the fill pointer of vector.

+

Examples:

+

+

+ (setq a (make-array 8 :fill-pointer 4)) =>  #(NIL NIL NIL NIL)
+ (fill-pointer a) =>  4
+ (dotimes (i (length a)) (setf (aref a i) (* i i))) =>  NIL
+ a =>  #(0 1 4 9)
+ (setf (fill-pointer a) 3) =>  3
+ (fill-pointer a) =>  3
+ a =>  #(0 1 4)
+ (setf (fill-pointer a) 8) =>  8
+ a =>  #(0 1 4 9 NIL NIL NIL NIL)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if vector is not a vector with a fill pointer.

+

See Also:

+

+make-array, length

+

Notes:

+

+There is no operator that will remove a vector's fill pointer.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_.htm new file mode 100644 index 00000000..805f8939 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_.htm @@ -0,0 +1,77 @@ + + + +CLHS: Function FIND, FIND-IF, FIND-IF-NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FIND, FIND-IF, FIND-IF-NOT

+

Syntax:

+

+ +find item sequence &key from-end test test-not start end key => element

+ +find-if predicate sequence &key from-end start end key => element

+ +find-if-not predicate sequence &key from-end start end key => element

+

+

Arguments and Values:

+

+item---an object.

+sequence---a proper sequence.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+key---a designator for a function of one argument, or nil.

+element---an element of the sequence, or nil.

+

Description:

+

+find, find-if, and find-if-not each search for an element of the sequence bounded by start and end that satisfies the predicate predicate or that satisfies the test test or test-not, as appropriate.

+If from-end is true, then the result is the rightmost element that satisfies the test.

+If the sequence contains an element that satisfies the test, then the leftmost or rightmost sequence element, depending on from-end, is returned; otherwise nil is returned.

+

Examples:

+

+

+ (find #\d "here are some letters that can be looked at" :test #'char>)
+=>  #\Space 
+ (find-if #'oddp '(1 2 3 4 5) :end 3 :from-end t) =>  3
+ (find-if-not #'complexp                                    
+             '#(3.5 2 #C(1.0 0.0) #C(0.0 1.0))
+             :start 2) =>  NIL 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+position, Section 17.2 (Rules about Test Functions), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not argument is deprecated.

+ The function find-if-not is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_a.htm new file mode 100644 index 00000000..70cc66ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_a.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function FIND-ALL-SYMBOLS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FIND-ALL-SYMBOLS

+

Syntax:

+

+ +find-all-symbols string => symbols

+

+

Arguments and Values:

+

+string---a string designator.

+symbols---a list of symbols.

+

Description:

+

+find-all-symbols searches every registered package for symbols that have a name that is the same (under string=) as string. A list of all such symbols is returned. Whether or how the list is ordered is implementation-dependent.

+

Examples:

+

+

+ (find-all-symbols 'car)
+=>  (CAR)
+OR=>  (CAR VEHICLES:CAR)
+OR=>  (VEHICLES:CAR CAR)
+ (intern "CAR" (make-package 'temp :use nil)) =>  TEMP::CAR, NIL
+ (find-all-symbols 'car)
+=>  (TEMP::CAR CAR)
+OR=>  (CAR TEMP::CAR)
+OR=>  (TEMP::CAR CAR VEHICLES:CAR)
+OR=>  (CAR TEMP::CAR VEHICLES:CAR)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+find-symbol

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_c.htm new file mode 100644 index 00000000..de35433e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_c.htm @@ -0,0 +1,58 @@ + + + +CLHS: Accessor FIND-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor FIND-CLASS

+

Syntax:

+

+ +find-class symbol &optional errorp environment => class

+ +(setf (find-class symbol &optional errorp environment) new-class)

+

+

Arguments and Values:

+

+symbol---a symbol.

+errorp---a generalized boolean. The default is true.

+environment -- same as the &environment argument to macro expansion functions and is used to distinguish between compile-time and run-time environments. The &environment argument has dynamic extent; the consequences are undefined if the &environment argument is referred to outside the dynamic extent of the macro expansion function.

+class---a class object, or nil.

+

Description:

+

+Returns the class object named by the symbol in the environment. If there is no such class, nil is returned if errorp is false; otherwise, if errorp is true, an error is signaled.

+The class associated with a particular symbol can be changed by using setf with find-class; or, if the new class given to setf is nil, the class association is removed (but the class object itself is not affected). The results are undefined if the user attempts to change or remove the class associated with a symbol that is defined as a type specifier in this standard. See Section 4.3.7 (Integrating Types and Classes).

+When using setf of find-class, any errorp argument is evaluated for effect, but any values it returns are ignored; the errorp parameter is permitted primarily so that the environment parameter can be used.

+The environment might be used to distinguish between a compile-time and a run-time environment.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If there is no such class and errorp is true, find-class signals an error of type error.

+

See Also:

+

+defmacro, Section 4.3.7 (Integrating Types and Classes)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_m.htm new file mode 100644 index 00000000..ed6ed171 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_m.htm @@ -0,0 +1,74 @@ + + + +CLHS: Standard Generic Function FIND-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function FIND-METHOD

+

Syntax:

+

+ +find-method generic-function method-qualifiers specializers &optional errorp

=> method

+

+

Method Signatures:

+

+ +find-method (generic-function standard-generic-function) method-qualifiers specializers &optional errorp

+

+

Arguments and Values:

+

+generic-function---a generic function.

+method-qualifiers---a list.

+specializers---a list.

+errorp---a generalized boolean. The default is true.

+method---a method object, or nil.

+

Description:

+

+The generic function find-method takes a generic function and returns the method object that agrees on qualifiers and parameter specializers with the method-qualifiers and specializers arguments of find-method. Method-qualifiers contains the method qualifiers for the method. The order of the method qualifiers is significant. For a definition of agreement in this context, see Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers).

+The specializers argument contains the parameter specializers for the method. It must correspond in length to the number of required arguments of the generic function, or an error is signaled. This means that to obtain the default method on a given generic-function, a list whose elements are the class t must be given.

+If there is no such method and errorp is true, find-method signals an error. If there is no such method and errorp is false, find-method returns nil.

+

Examples:

+

+

+ (defmethod some-operation ((a integer) (b float)) (list a b))
+=>  #<STANDARD-METHOD SOME-OPERATION (INTEGER FLOAT) 26723357>
+ (find-method #'some-operation '() (mapcar #'find-class '(integer float)))
+=>  #<STANDARD-METHOD SOME-OPERATION (INTEGER FLOAT) 26723357>
+ (find-method #'some-operation '() (mapcar #'find-class '(integer integer)))
+>>  Error: No matching method
+ (find-method #'some-operation '() (mapcar #'find-class '(integer integer)) nil)
+=>  NIL
+
+

+

Affected By:

+

+add-method, defclass, defgeneric, defmethod

+

Exceptional Situations:

+

+If the specializers argument does not correspond in length to the number of required arguments of the generic-function, an an error of type error is signaled.

+If there is no such method and errorp is true, find-method signals an error of type error.

+

See Also:

+

+Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_p.htm new file mode 100644 index 00000000..895a043e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_p.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function FIND-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FIND-PACKAGE

+

Syntax:

+

+ +find-package name => package

+

+

Arguments and Values:

+

+ name---a string designator or a package object.

+package---a package object or nil.

+

Description:

+

+If name is a string designator, find-package locates and returns the package whose name or nickname is name. This search is case sensitive. If there is no such package, find-package returns nil.

+ If name is a package object, that package object is returned.

+

Examples:

+

+

+ (find-package 'common-lisp) =>  #<PACKAGE "COMMON-LISP">
+ (find-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (find-package 'not-there) =>  NIL
+
+

+

Side Effects: None. +

+

Affected By:

+

+The set of packages created by the implementation.

+defpackage, delete-package, make-package, rename-package

+

Exceptional Situations: None. +

+

See Also:

+

+make-package

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_r.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_r.htm new file mode 100644 index 00000000..c0fef38c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_r.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function FIND-RESTART + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FIND-RESTART

+

Syntax:

+

+ +find-restart identifier &optional condition

+ restart

+

Arguments and Values:

+

+identifier---a non-nil symbol, or a restart.

+ condition---a condition object, or nil.

+restart---a restart or nil.

+

Description:

+

+find-restart searches for a particular restart in the current dynamic environment.

+ When condition is non-nil, only those restarts are considered that are either explicitly associated with that condition, or not associated with any condition; that is, the excluded restarts are those that are associated with a non-empty set of conditions of which the given condition is not an element. If condition is nil, all restarts are considered.

+If identifier is a symbol, then the innermost (most recently established) applicable restart with that name is returned. nil is returned if no such restart is found.

+If identifier is a currently active restart, then it is returned. Otherwise, nil is returned.

+

Examples:

+

+

+ (restart-case
+     (let ((r (find-restart 'my-restart)))
+       (format t "~S is named ~S" r (restart-name r)))
+   (my-restart () nil))
+>>  #<RESTART 32307325> is named MY-RESTART
+=>  NIL
+ (find-restart 'my-restart)
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By:

+

+Existing restarts.

+restart-case, restart-bind, with-condition-restarts.

+

Exceptional Situations: None. +

+

See Also:

+

+compute-restarts

+

Notes:

+

+

+ (find-restart identifier)
+ ==  (find identifier (compute-restarts) :key :restart-name)
+
+

+Although anonymous restarts have a name of nil, the consequences are unspecified if nil is given as an identifier. Occasionally, programmers lament that nil is not permissible as an identifier argument. In most such cases, compute-restarts can probably be used to simulate the desired effect.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_s.htm new file mode 100644 index 00000000..511088bb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_find_s.htm @@ -0,0 +1,86 @@ + + + +CLHS: Function FIND-SYMBOL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FIND-SYMBOL

+

Syntax:

+

+ +find-symbol string &optional package => symbol, status

+

+

Arguments and Values:

+

+string---a string.

+ package---a package designator. The default is the current package.

+symbol---a symbol accessible in the package, or nil.

+status---one of :inherited, :external, :internal, or nil.

+

Description:

+

+find-symbol locates a symbol whose name is string in a package. If a symbol named string is found in package, directly or by inheritance, the symbol found is returned as the first value; the second value is as follows:

+

:internal

+If the symbol is present in package as an internal symbol.

+

:external

+If the symbol is present in package as an external symbol.

+

:inherited

+If the symbol is inherited by package through use-package, but is not present in package.

+

+If no such symbol is accessible in package, both values are nil.

+

Examples:

+

+

+ (find-symbol "NEVER-BEFORE-USED") =>  NIL, NIL
+ (find-symbol "NEVER-BEFORE-USED") =>  NIL, NIL
+ (intern "NEVER-BEFORE-USED") =>  NEVER-BEFORE-USED, NIL
+ (intern "NEVER-BEFORE-USED") =>  NEVER-BEFORE-USED, :INTERNAL
+ (find-symbol "NEVER-BEFORE-USED") =>  NEVER-BEFORE-USED, :INTERNAL
+ (find-symbol "never-before-used") =>  NIL, NIL
+ (find-symbol "CAR" 'common-lisp-user) =>  CAR, :INHERITED
+ (find-symbol "CAR" 'common-lisp) =>  CAR, :EXTERNAL
+ (find-symbol "NIL" 'common-lisp-user) =>  NIL, :INHERITED
+ (find-symbol "NIL" 'common-lisp) =>  NIL, :EXTERNAL
+ (find-symbol "NIL" (prog1 (make-package "JUST-TESTING" :use '())
+                           (intern "NIL" "JUST-TESTING")))
+=>  JUST-TESTING::NIL, :INTERNAL
+ (export 'just-testing::nil 'just-testing)
+ (find-symbol "NIL" 'just-testing) =>  JUST-TESTING:NIL, :EXTERNAL
+ (find-symbol "NIL" "KEYWORD")
+=>  NIL, NIL
+OR=>  :NIL, :EXTERNAL
+ (find-symbol (symbol-name :nil) "KEYWORD") =>  :NIL, :EXTERNAL
+
+

+

Side Effects: None. +

+

Affected By:

+

+intern, import, export, use-package, unintern, unexport, unuse-package

+

Exceptional Situations: None. +

+

See Also:

+

+intern, find-all-symbols

+

Notes:

+

+find-symbol is operationally equivalent to intern, except that it never creates a new symbol.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_finish.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_finish.htm new file mode 100644 index 00000000..372d13e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_finish.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function FINISH-OUTPUT, FORCE-OUTPUT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT

+

Syntax:

+

+ +finish-output &optional output-stream => nil

+ +force-output &optional output-stream => nil

+ +clear-output &optional output-stream => nil

+

+

Arguments and Values:

+

+output-stream---an output stream designator. The default is standard output.

+

Description:

+

+finish-output, force-output, and clear-output exercise control over the internal handling of buffered stream output.

+finish-output attempts to ensure that any buffered output sent to output-stream has reached its destination, and then returns.

+force-output initiates the emptying of any internal buffers but does not wait for completion or acknowledgment to return.

+clear-output attempts to abort any outstanding output operation in progress in order to allow as little output as possible to continue to the destination.

+If any of these operations does not make sense for output-stream, then it does nothing. The precise actions of these functions are implementation-dependent.

+

Examples:

+ +

+;; Implementation A
+ (progn (princ "am i seen?") (clear-output))
+=>  NIL
+
+;; Implementation B
+ (progn (princ "am i seen?") (clear-output))
+>>  am i seen?
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By:

+

+*standard-output*

+

Exceptional Situations:

+

+Should signal an error of type type-error if output-stream is not a stream designator.

+

See Also:

+

+clear-input

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_firstc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_firstc.htm new file mode 100644 index 00000000..e0cb9f3c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_firstc.htm @@ -0,0 +1,126 @@ + + + +CLHS: Accessor FIRST, SECOND, THIRD, FOURTH... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH

+

Syntax:

+

+ +first list => object

+ +second list => object

+ +third list => object

+ +fourth list => object

+ +fifth list => object

+ +sixth list => object

+ +seventh list => object

+ +eighth list => object

+ +ninth list => object

+ +tenth list => object

+ +(setf (first list) new-object)

+ +(setf (second list) new-object)

+ +(setf (third list) new-object)

+ +(setf (fourth list) new-object)

+ +(setf (fifth list) new-object)

+ +(setf (sixth list) new-object)

+ +(setf (seventh list) new-object)

+ +(setf (eighth list) new-object)

+ +(setf (ninth list) new-object)

+ +(setf (tenth list) new-object)

+

+

Arguments and Values:

+

+list---a list, which might be a dotted list or a circular list.

+object, new-object---an object.

+

Description:

+

+The functions first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, and tenth access the first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, and tenth elements of list, respectively. Specifically,

+

+ (first list)    ==   (car list)
+ (second list)   ==   (car (cdr list))
+ (third list)    ==   (car (cddr list))
+ (fourth list)   ==   (car (cdddr list))
+ (fifth list)    ==   (car (cddddr list))
+ (sixth list)    ==   (car (cdr (cddddr list)))
+ (seventh list)  ==   (car (cddr (cddddr list)))
+ (eighth list)   ==   (car (cdddr (cddddr list)))
+ (ninth list)    ==   (car (cddddr (cddddr list)))
+ (tenth list)    ==   (car (cdr (cddddr (cddddr list))))
+
+

+setf can also be used with any of these functions to change an existing component. The same equivalences apply. For example:

+

+ (setf (fifth list) new-object) ==  (setf (car (cddddr list)) new-object)
+
+

+

Examples:

+

+

+ (setq lst '(1 2 3 (4 5 6) ((V)) vi 7 8 9 10)) 
+=>  (1 2 3 (4 5 6) ((V)) VI 7 8 9 10)
+ (first lst) =>  1
+ (tenth lst) =>  10
+ (fifth lst) =>  ((V))
+ (second (fourth lst)) =>  5
+ (sixth '(1 2 3)) =>  NIL
+ (setf (fourth lst) "four") =>  "four"
+ lst =>  (1 2 3 "four" ((V)) VI 7 8 9 10)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+car, nth

+

Notes:

+

+first is functionally equivalent to car, second is functionally equivalent to cadr, third is functionally equivalent to caddr, and fourth is functionally equivalent to cadddr.

+The ordinal numbering used here is one-origin, as opposed to the zero-origin numbering used by nth:

+

+ (fifth x) ==  (nth 4 x)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_float.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_float.htm new file mode 100644 index 00000000..d6f24461 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_float.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function FLOAT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FLOAT

+

Syntax:

+

+ +float number &optional prototype => float

+

+

Arguments and Values:

+

+number---a real.

+prototype---a float.

+float---a float.

+

Description:

+

+float converts a real number to a float.

+If a prototype is supplied, a float is returned that is mathematically equal to number but has the same format as prototype.

+If prototype is not supplied, then if the number is already a float, it is returned; otherwise, a float is returned that is mathematically equal to number but is a single float.

+

Examples:

+

+

+ (float 0) =>  0.0
+ (float 1 .5) =>  1.0
+ (float 1.0) =>  1.0
+ (float 1/2) =>  0.5
+=>  1.0d0
+OR=>  1.0
+ (eql (float 1.0 1.0d0) 1.0d0) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+coerce

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floatp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floatp.htm new file mode 100644 index 00000000..e5d47092 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floatp.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function FLOATP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FLOATP

+

Syntax:

+

+ +floatp object

+ generalized-boolean

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type float; otherwise, returns false.

+

Examples:

+

+

+ (floatp 1.2d2) =>  true
+ (floatp 1.212) =>  true
+ (floatp 1.2s2) =>  true
+ (floatp (expt 2 130)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (floatp object) ==  (typep object 'float)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floorc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floorc.htm new file mode 100644 index 00000000..872d18b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_floorc.htm @@ -0,0 +1,118 @@ + + + +CLHS: Function FLOOR, FFLOOR, CEILING, FCEILING... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND

+

Syntax:

+

+ +floor number &optional divisor => quotient, remainder

+ +ffloor number &optional divisor => quotient, remainder

+ +ceiling number &optional divisor => quotient, remainder

+ +fceiling number &optional divisor => quotient, remainder

+ +truncate number &optional divisor => quotient, remainder

+ +ftruncate number &optional divisor => quotient, remainder

+ +round number &optional divisor => quotient, remainder

+ +fround number &optional divisor => quotient, remainder

+

+

Arguments and Values:

+

+number---a real.

+divisor---a non-zero real. The default is the integer 1.

+quotient---for floor, ceiling, truncate, and round: an integer; for ffloor, fceiling, ftruncate, and fround: a float.

+remainder---a real.

+

Description:

+

+These functions divide number by divisor, returning a quotient and remainder, such that

+ quotient*divisor+remainder=number

+The quotient always represents a mathematical integer. When more than one mathematical integer might be possible (i.e., when the remainder is not zero), the kind of rounding or truncation depends on the operator:

+

+

floor, ffloor

+floor and ffloor produce a quotient that has been truncated toward negative infinity; that is, the quotient represents the largest mathematical integer that is not larger than the mathematical quotient.

+

ceiling, fceiling

+ceiling and fceiling produce a quotient that has been truncated toward positive infinity; that is, the quotient represents the smallest mathematical integer that is not smaller than the mathematical result.

+

truncate, ftruncate

+truncate and ftruncate produce a quotient that has been truncated towards zero; that is, the quotient represents the mathematical integer of the same sign as the mathematical quotient, and that has the greatest integral magnitude not greater than that of the mathematical quotient.

+

round, fround

+round and fround produce a quotient that has been rounded to the nearest mathematical integer; if the mathematical quotient is exactly halfway between two integers, (that is, it has the form integer+1/2), then the quotient has been rounded to the even (divisible by two) integer.

+

+All of these functions perform type conversion operations on numbers.

+The remainder is an integer if both x and y are integers, is a rational if both x and y are rationals, and is a float if either x or y is a float.

+ffloor, fceiling, ftruncate, and fround handle arguments of different types in the following way: If number is a float, and divisor is not a float of longer format, then the first result is a float of the same type as number. Otherwise, the first result is of the type determined by contagion rules; see Section 12.1.1.2 (Contagion in Numeric Operations).

+

Examples:

+

+

+ (floor 3/2) =>  1, 1/2
+ (ceiling 3 2) =>  2, -1
+ (ffloor 3 2) =>  1.0, 1
+ (ffloor -4.7) =>  -5.0, 0.3
+ (ffloor 3.5d0) =>  3.0d0, 0.5d0
+ (fceiling 3/2) =>  2.0, -1/2
+ (truncate 1) =>  1, 0
+ (truncate .5) =>  0, 0.5
+ (round .5) =>  0, 0.5
+ (ftruncate -7 2) =>  -3.0, -1
+ (fround -7 2) =>  -4.0, 1
+ (dolist (n '(2.6 2.5 2.4 0.7 0.3 -0.3 -0.7 -2.4 -2.5 -2.6))
+   (format t "~&~4,1@F ~2,' D ~2,' D ~2,' D ~2,' D"
+           n (floor n) (ceiling n) (truncate n) (round n)))
+>>  +2.6  2  3  2  3
+>>  +2.5  2  3  2  2
+>>  +2.4  2  3  2  2
+>>  +0.7  0  1  0  1
+>>  +0.3  0  1  0  0
+>>  -0.3 -1  0  0  0
+>>  -0.7 -1  0  0 -1
+>>  -2.4 -3 -2 -2 -2
+>>  -2.5 -3 -2 -2 -2
+>>  -2.6 -3 -2 -2 -3
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+When only number is given, the two results are exact; the mathematical sum of the two results is always equal to the mathematical value of number.

+(function number divisor) and (function (/ number divisor)) (where function is any of one of floor, ceiling, ffloor, fceiling, truncate, round, ftruncate, and fround) return the same first value, but they return different remainders as the second value. For example:

+

+ (floor 5 2) =>  2, 1
+ (floor (/ 5 2)) =>  2, 1/2
+
+

+If an effect is desired that is similar to round, but that always rounds up or down (rather than toward the nearest even integer) if the mathematical quotient is exactly halfway between two integers, the programmer should consider a construction such as (floor (+ x 1/2)) or (ceiling (- x 1/2)).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fmakun.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fmakun.htm new file mode 100644 index 00000000..c2031253 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fmakun.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function FMAKUNBOUND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FMAKUNBOUND

+

Syntax:

+

+ +fmakunbound name => name

+

+

Pronunciation:

+

+ [,ef'makuhn,band] or [,ef'maykuhn,band]

+

Arguments and Values:

+

+ name---a function name.

+

Description:

+

+Removes the function or macro definition, if any, of name in the global environment.

+

Examples:

+

+

+(defun add-some (x) (+ x 19)) =>  ADD-SOME
+ (fboundp 'add-some) =>  true
+ (flet ((add-some (x) (+ x 37)))
+    (fmakunbound 'add-some)
+    (add-some 1)) =>  38
+ (fboundp 'add-some) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if name is not a function name.

+The consequences are undefined if name is a special operator.

+

See Also:

+

+fboundp, makunbound

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_kwd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_kwd.htm new file mode 100644 index 00000000..053a081b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_kwd.htm @@ -0,0 +1,78 @@ + + + +CLHS: Standard Generic Function FUNCTION-KEYWORDS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function FUNCTION-KEYWORDS

+

Syntax:

+

+ +function-keywords method => keys, allow-other-keys-p

+

+

Method Signatures:

+

+ +function-keywords (method standard-method)

+

+

Arguments and Values:

+

+method---a method.

+keys---a list.

+allow-other-keys-p---a generalized boolean.

+

Description:

+

+Returns the keyword parameter specifiers for a method.

+Two values are returned: a list of the explicitly named keywords and a generalized boolean that states whether &allow-other-keys had been specified in the method definition.

+

Examples:

+

+

+ (defmethod gf1 ((a integer) &optional (b 2)
+                 &key (c 3) ((:dee d) 4) e ((eff f)))
+   (list a b c d e f))
+=>  #<STANDARD-METHOD GF1 (INTEGER) 36324653>
+ (find-method #'gf1 '() (list (find-class 'integer))) 
+=>  #<STANDARD-METHOD GF1 (INTEGER) 36324653>
+ (function-keywords *)
+=>  (:C :DEE :E EFF), false
+ (defmethod gf2 ((a integer))
+   (list a b c d e f))
+=>  #<STANDARD-METHOD GF2 (INTEGER) 42701775>
+ (function-keywords (find-method #'gf1 '() (list (find-class 'integer))))
+=>  (), false
+ (defmethod gf3 ((a integer) &key b c d &allow-other-keys)
+   (list a b c d e f))
+ (function-keywords *)
+=>  (:B :C :D), true
+
+

+

Affected By:

+

+defmethod

+

Exceptional Situations: None. +

+

See Also:

+

+defmethod

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_lam.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_lam.htm new file mode 100644 index 00000000..b2140b89 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fn_lam.htm @@ -0,0 +1,101 @@ + + + +CLHS: Function FUNCTION-LAMBDA-EXPRESSION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FUNCTION-LAMBDA-EXPRESSION

+

+

Syntax:

+

+ +function-lambda-expression function

=> lambda-expression, closure-p, name

+

+

Arguments and Values:

+

+function---a function.

+lambda-expression---a lambda expression or nil.

+closure-p---a generalized boolean.

+name---an object.

+

Description:

+

+Returns information about function as follows:

+The primary value, lambda-expression, is function's defining lambda expression, or nil if the information is not available. The lambda expression may have been pre-processed in some ways, but it should remain a suitable argument to compile or function. Any implementation may legitimately return nil as the lambda-expression of any function.

+The secondary value, closure-p, is nil if function's definition was enclosed in the null lexical environment or something non-nil if function's definition might have been enclosed in some non-null lexical environment. Any implementation may legitimately return true as the closure-p of any function.

+The tertiary value, name, is the ``name'' of function. The name is intended for debugging only and is not necessarily one that would be valid for use as a name in defun or function, for example. By convention, nil is used to mean that function has no name. Any implementation may legitimately return nil as the name of any function.

+

Examples:

+

+The following examples illustrate some possible return values, but are not intended to be exhaustive:

+

+ (function-lambda-expression #'(lambda (x) x))
+=>  NIL, false, NIL
+OR=>  NIL, true, NIL
+OR=>  (LAMBDA (X) X), true, NIL
+OR=>  (LAMBDA (X) X), false, NIL
+
+ (function-lambda-expression
+    (funcall #'(lambda () #'(lambda (x) x))))
+=>  NIL, false, NIL
+OR=>  NIL, true, NIL
+OR=>  (LAMBDA (X) X), true, NIL
+OR=>  (LAMBDA (X) X), false, NIL
+ 
+ (function-lambda-expression 
+    (funcall #'(lambda (x) #'(lambda () x)) nil))
+=>  NIL, true, NIL
+OR=>  (LAMBDA () X), true, NIL
+NOT=>  NIL, false, NIL
+NOT=>  (LAMBDA () X), false, NIL
+  
+ (flet ((foo (x) x))
+   (setf (symbol-function 'bar) #'foo)
+   (function-lambda-expression #'bar))
+=>  NIL, false, NIL
+OR=>  NIL, true, NIL
+OR=>  (LAMBDA (X) (BLOCK FOO X)), true, NIL
+OR=>  (LAMBDA (X) (BLOCK FOO X)), false, FOO
+OR=>  (SI::BLOCK-LAMBDA FOO (X) X), false, FOO
+ 
+ (defun foo ()
+   (flet ((bar (x) x))
+     #'bar))
+ (function-lambda-expression (foo))
+=>  NIL, false, NIL
+OR=>  NIL, true, NIL
+OR=>  (LAMBDA (X) (BLOCK BAR X)), true, NIL
+OR=>  (LAMBDA (X) (BLOCK BAR X)), true, (:INTERNAL FOO 0 BAR)
+OR=>  (LAMBDA (X) (BLOCK BAR X)), false, "BAR in FOO"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+Although implementations are free to return ``nil, true, nil'' in all cases, they are encouraged to return a lambda expression as the primary value in the case where the argument was created by a call to compile or eval (as opposed to being created by loading a compiled file).

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fnp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fnp.htm new file mode 100644 index 00000000..48ea1996 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_fnp.htm @@ -0,0 +1,69 @@ + + + +CLHS: Function FUNCTIONP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FUNCTIONP

+

+

Syntax:

+

+ +functionp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type function; otherwise, returns false.

+

Examples:

+

+

+ (functionp 'append) =>  false
+ (functionp #'append) =>  true
+ (functionp (symbol-function 'append)) =>  true
+ (flet ((f () 1)) (functionp #'f)) =>  true
+ (functionp (compile nil '(lambda () 259))) =>  true
+ (functionp nil) =>  false
+ (functionp 12) =>  false
+ (functionp '(lambda (x) (* x x))) =>  false
+ (functionp #'(lambda (x) (* x x))) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (functionp object) ==  (typep object 'function)
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_format.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_format.htm new file mode 100644 index 00000000..68f854da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_format.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function FORMAT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FORMAT

+

Syntax:

+

+ +format destination control-string &rest args => result

+

+

Arguments and Values:

+

+destination---nil, t, a stream, or a string with a fill pointer.

+ control-string---a format control.

+args---format arguments for control-string.

+result---if destination is non-nil, then nil; otherwise, a string.

+

Description:

+

+format produces formatted output by outputting the characters of control-string and observing that a tilde introduces a directive. The character after the tilde, possibly preceded by prefix parameters and modifiers, specifies what kind of formatting is desired. Most directives use one or more elements of args to create their output.

+If destination is a string, a stream, or t, then the result is nil. Otherwise, the result is a string containing the `output.'

+format is useful for producing nicely formatted text, producing good-looking messages, and so on. format can generate and return a string or output to destination.

+For details on how the control-string is interpreted, see Section 22.3 (Formatted Output).

+

Examples: None. +

+

Affected By:

+

+*standard-output*, *print-escape*, *print-radix*, *print-base*, *print-circle*, *print-pretty*, *print-level*, *print-length*, *print-case*, *print-gensym*, *print-array*.

+

Exceptional Situations:

+

+ If destination is a string with a fill pointer, the consequences are undefined if destructive modifications are performed directly on the string during the dynamic extent of the call.

+

See Also:

+

+write, Section 13.1.10 (Documentation of Implementation-Defined Scripts)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_funcal.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_funcal.htm new file mode 100644 index 00000000..a206a239 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_funcal.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function FUNCALL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function FUNCALL

+

Syntax:

+

+ +funcall function &rest args => result*

+

+

Arguments and Values:

+

+function---a function designator.

+args---arguments to the function.

+results---the values returned by the function.

+

Description:

+

+funcall applies function to args. If function is a symbol, it is coerced to a function as if by finding its functional value in the global environment.

+

Examples:

+

+

+ (funcall #'+ 1 2 3) =>  6
+ (funcall 'car '(1 2 3)) =>  1
+ (funcall 'position 1 '(1 2 3 2 1) :start 1) =>  4
+ (cons 1 2) =>  (1 . 2)
+ (flet ((cons (x y) `(kons ,x ,y)))
+   (let ((cons (symbol-function '+)))
+     (funcall #'cons
+              (funcall 'cons 1 2)
+              (funcall cons 1 2))))
+=>  (KONS (1 . 2) 3)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+An error of type undefined-function should be signaled if function is a symbol that does not have a global definition as a function or that has a global definition as a macro or a special operator.

+

See Also:

+

+apply, function, Section 3.1 (Evaluation)

+

Notes:

+

+

+ (funcall function arg1 arg2 ...)
+ ==  (apply function arg1 arg2 ... nil)
+ ==  (apply function (list arg1 arg2 ...))
+
+

+The difference between funcall and an ordinary function call is that in the former case the function is obtained by ordinary evaluation of a form, and in the latter case it is obtained by the special interpretation of the function position that normally occurs.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gcd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gcd.htm new file mode 100644 index 00000000..c513f8c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gcd.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function GCD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GCD

+

Syntax:

+

+ +gcd &rest integers => greatest-common-denominator

+

+

Arguments and Values:

+

+integer---an integer.

+greatest-common-denominator---a non-negative integer.

+

Description:

+

+Returns the greatest common divisor of integers. If only one integer is supplied, its absolute value is returned. If no integers are given, gcd returns 0, which is an identity for this operation.

+

Examples:

+

+

+ (gcd) =>  0
+ (gcd 60 42) =>  6
+ (gcd 3333 -33 101) =>  1
+ (gcd 3333 -33 1002001) =>  11
+ (gcd 91 -49) =>  7
+ (gcd 63 -42 35) =>  7
+ (gcd 5) =>  5
+ (gcd -4) =>  4
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if any integer is not an integer.

+

See Also:

+

+lcm

+

Notes:

+ For three or more arguments,

+

+ (gcd b c ... z) ==  (gcd (gcd a b) c ... z)
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gensym.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gensym.htm new file mode 100644 index 00000000..442da7f5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gensym.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function GENSYM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GENSYM

+

Syntax:

+

+ +gensym &optional x => new-symbol

+

+

Arguments and Values:

+

+x---a string or a non-negative integer. Complicated defaulting behavior; see below.

+new-symbol---a fresh, uninterned symbol.

+

Description:

+

+Creates and returns a fresh, uninterned symbol, as if by calling make-symbol. (The only difference between gensym and make-symbol is in how the new-symbol's name is determined.)

+The name of the new-symbol is the concatenation of a prefix, which defaults to "G", and a suffix, which is the decimal representation of a number that defaults to the value of *gensym-counter*.

+If x is supplied, and is a string, then that string is used as a prefix instead of "G" for this call to gensym only.

+If x is supplied, and is an integer, then that integer, instead of the value of *gensym-counter*, is used as the suffix for this call to gensym only.

+If and only if no explicit suffix is supplied, *gensym-counter* is incremented after it is used.

+

Examples:

+

+

+ (setq sym1 (gensym)) =>  #:G3142
+ (symbol-package sym1) =>  NIL
+ (setq sym2 (gensym 100)) =>  #:G100
+ (setq sym3 (gensym 100)) =>  #:G100
+ (eq sym2 sym3) =>  false
+ (find-symbol "G100") =>  NIL, NIL
+ (gensym "T") =>  #:T3143
+ (gensym) =>  #:G3144
+
+

+

Side Effects:

+

+Might increment *gensym-counter*.

+

Affected By:

+

+*gensym-counter*

+

Exceptional Situations:

+

+Should signal an error of type type-error if x is not a string or a non-negative integer.

+

See Also:

+

+gentemp, *gensym-counter*

+

Notes:

+

+The ability to pass a numeric argument to gensym has been deprecated; explicitly binding *gensym-counter* is now stylistically preferred. (The somewhat baroque conventions for the optional argument are historical in nature, and supported primarily for compatibility with older dialects of Lisp. In modern code, it is recommended that the only kind of argument used be a string prefix. In general, though, to obtain more flexible control of the new-symbol's name, consider using make-symbol instead.)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gentem.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gentem.htm new file mode 100644 index 00000000..d2b48588 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gentem.htm @@ -0,0 +1,73 @@ + + + +CLHS: Function GENTEMP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GENTEMP

+

Syntax:

+

+ +gentemp &optional prefix package => new-symbol

+

+

Arguments and Values:

+

+prefix---a string. The default is "T".

+package---a package designator. The default is the current package.

+new-symbol---a fresh, interned symbol.

+

Description:

+

+gentemp creates and returns a fresh symbol, interned in the indicated package. The symbol is guaranteed to be one that was not previously accessible in package. It is neither bound nor fbound, and has a null property list.

+The name of the new-symbol is the concatenation of the prefix and a suffix, which is taken from an internal counter used only by gentemp. (If a symbol by that name is already accessible in package, the counter is incremented as many times as is necessary to produce a name that is not already the name of a symbol accessible in package.)

+

Examples:

+

+

+ (gentemp) =>  T1298
+ (gentemp "FOO") =>  FOO1299
+ (find-symbol "FOO1300") =>  NIL, NIL
+ (gentemp "FOO") =>  FOO1300
+ (find-symbol "FOO1300") =>  FOO1300, :INTERNAL
+ (intern "FOO1301") =>  FOO1301, :INTERNAL
+ (gentemp "FOO") =>  FOO1302
+ (gentemp) =>  T1303
+
+

+

Side Effects:

+

+Its internal counter is incremented one or more times.

+Interns the new-symbol in package.

+

Affected By:

+

+The current state of its internal counter, and the current state of the package.

+

Exceptional Situations:

+

+Should signal an error of type type-error if prefix is not a string. Should signal an error of type type-error if package is not a package designator.

+

See Also:

+

+gensym

+

Notes:

+

+The function gentemp is deprecated.

+If package is the KEYWORD package, the result is an external symbol of package. Otherwise, the result is an internal symbol of package.

+The gentemp internal counter is independent of *gensym-counter*, the counter used by gensym. There is no provision for accessing the gentemp internal counter.

+Just because gentemp creates a symbol which did not previously exist does not mean that such a symbol might not be seen in the future (e.g., in a data file---perhaps even created by the same program in another session). As such, this symbol is not truly unique in the same sense as a gensym would be. In particular, programs which do automatic code generation should be careful not to attach global attributes to such generated symbols (e.g., special declarations) and then write them into a file because such global attributes might, in a different session, end up applying to other symbols that were automatically generated on another day for some other purpose.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get.htm new file mode 100644 index 00000000..d65411df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get.htm @@ -0,0 +1,96 @@ + + + +CLHS: Accessor GET + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor GET

+

Syntax:

+

+ +get symbol indicator &optional default => value

+ +(setf (get symbol indicator &optional default) new-value)

+

+

Arguments and Values:

+

+symbol---a symbol.

+indicator---an object.

+default---an object. The default is nil.

+value---if the indicated property exists, the object that is its value; otherwise, the specified default.

+new-value---an object.

+

Description:

+

+get finds a property on the property list[2] of symbol whose property indicator is identical to indicator, and returns its corresponding property value. If there are multiple properties[1] with that property indicator, get uses the first such property. If there is no property with that property indicator, default is returned.

+setf of get may be used to associate a new object with an existing indicator already on the symbol's property list, or to create a new assocation if none exists. If there are multiple properties[1] with that property indicator, setf of get associates the new-value with the first such property. When a get form is used as a setf place, any default which is supplied is evaluated according to normal left-to-right evaluation rules, but its value is ignored.

+

Examples:

+

+

+ (defun make-person (first-name last-name)
+   (let ((person (gensym "PERSON")))
+     (setf (get person 'first-name) first-name)
+     (setf (get person 'last-name) last-name)
+     person)) =>  MAKE-PERSON
+ (defvar *john* (make-person "John" "Dow")) =>  *JOHN*
+ *john* =>  #:PERSON4603
+ (defvar *sally* (make-person "Sally" "Jones")) =>  *SALLY*
+ (get *john* 'first-name) =>  "John"
+ (get *sally* 'last-name) =>  "Jones"
+ (defun marry (man woman married-name)
+   (setf (get man 'wife) woman)
+   (setf (get woman 'husband) man)
+   (setf (get man 'last-name) married-name)
+   (setf (get woman 'last-name) married-name)
+   married-name) =>  MARRY
+ (marry *john* *sally* "Dow-Jones") =>  "Dow-Jones"
+ (get *john* 'last-name) =>  "Dow-Jones"
+ (get (get *john* 'wife) 'first-name) =>  "Sally"
+ (symbol-plist *john*)
+=>  (WIFE #:PERSON4604 LAST-NAME "Dow-Jones" FIRST-NAME "John")
+ (defmacro age (person &optional (default ''thirty-something)) 
+   `(get ,person 'age ,default)) =>  AGE
+ (age *john*) =>  THIRTY-SOMETHING
+ (age *john* 20) =>  20
+ (setf (age *john*) 25) =>  25
+ (age *john*) =>  25
+ (age *john* 20) =>  25
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+getf, symbol-plist, remprop

+

Notes:

+

+

+ (get x y) ==  (getf (symbol-plist x) y)
+
+

+Numbers and characters are not recommended for use as indicators in portable code since get tests with eq rather than eql, and consequently the effect of using such indicators is implementation-dependent.

+There is no way using get to distinguish an absent property from one whose value is default. However, see get-properties.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get__1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get__1.htm new file mode 100644 index 00000000..d626be2f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get__1.htm @@ -0,0 +1,53 @@ + + + +CLHS: Function GET-INTERNAL-RUN-TIME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GET-INTERNAL-RUN-TIME

+

Syntax:

+

+ +get-internal-run-time <no arguments> => internal-time

+

+

Arguments and Values:

+

+internal-time---a non-negative integer.

+

Description:

+

+Returns as an integer the current run time in internal time units. The precise meaning of this quantity is implementation-defined; it may measure real time, run time, CPU cycles, or some other quantity. The intent is that the difference between the values of two calls to this function be the amount of time between the two calls during which computational effort was expended on behalf of the executing program.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By:

+

+The implementation, the time of day (i.e., the passage of time).

+

Exceptional Situations: None. +

+

See Also:

+

+internal-time-units-per-second

+

Notes:

+

+Depending on the implementation, paging time and garbage collection time might be included in this measurement. Also, in a multitasking environment, it might not be possible to show the time for just the running process, so in some implementations, time taken by other processes during the same time interval might be included in this measurement as well.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_in.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_in.htm new file mode 100644 index 00000000..ee009ccd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_in.htm @@ -0,0 +1,52 @@ + + + +CLHS: Function GET-INTERNAL-REAL-TIME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GET-INTERNAL-REAL-TIME

+

Syntax:

+

+ +get-internal-real-time <no arguments> => internal-time

+

+

Arguments and Values:

+

+internal-time---a non-negative integer.

+

Description:

+

+get-internal-real-time returns as an integer the current time in internal time units, relative to an arbitrary time base. The difference between the values of two calls to this function is the amount of elapsed real time (i.e., clock time) between the two calls.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By:

+

+Time of day (i.e., the passage of time). The time base affects the result magnitude.

+

Exceptional Situations: None. +

+

See Also:

+

+internal-time-units-per-second

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_ou.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_ou.htm new file mode 100644 index 00000000..d16ae4ab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_ou.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function GET-OUTPUT-STREAM-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GET-OUTPUT-STREAM-STRING

+

Syntax:

+

+ +get-output-stream-string string-output-stream => string

+

+

Arguments and Values:

+

+string-output-stream---a stream.

+string---a string.

+

Description:

+

+Returns a string containing, in order, all the characters that have been output to string-output-stream. This operation clears any characters on string-output-stream, so the string contains only those characters which have been output since the last call to get-output-stream-string or since the creation of the string-output-stream, whichever occurred most recently.

+

Examples:

+ +

+ (setq a-stream (make-string-output-stream)
+        a-string "abcdefghijklm") =>  "abcdefghijklm"
+ (write-string a-string a-stream) =>  "abcdefghijklm"
+ (get-output-stream-string a-stream) =>  "abcdefghijklm"
+ (get-output-stream-string a-stream) =>  ""
+
+

+

Side Effects:

+

+The string-output-stream is cleared.

+

Affected By: None. +

+

Exceptional Situations:

+

+ The consequences are undefined if stream-output-string is closed.

+The consequences are undefined if string-output-stream is a stream that was not produced by make-string-output-stream. The consequences are undefined if string-output-stream was created implicitly by with-output-to-string or format.

+

+

See Also:

+

+make-string-output-stream

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_pr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_pr.htm new file mode 100644 index 00000000..4bbb23e4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_pr.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function GET-PROPERTIES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GET-PROPERTIES

+

Syntax:

+

+ +get-properties plist indicator-list => indicator, value, tail

+

+

Arguments and Values:

+

+ plist---a property list.

+indicator-list---a proper list (of indicators).

+indicator---an object that is an element of indicator-list.

+value---an object.

+tail---a list.

+

Description:

+

+get-properties is used to look up any of several property list entries all at once.

+It searches the plist for the first entry whose indicator is identical to one of the objects in indicator-list. If such an entry is found, the indicator and value returned are the property indicator and its associated property value, and the tail returned is the tail of the plist that begins with the found entry (i.e., whose car is the indicator). If no such entry is found, the indicator, value, and tail are all nil.

+

Examples:

+

+

+ (setq x '()) =>  NIL
+ (setq *indicator-list* '(prop1 prop2)) =>  (PROP1 PROP2)
+ (getf x 'prop1) =>  NIL
+ (setf (getf x 'prop1) 'val1) =>  VAL1
+ (eq (getf x 'prop1) 'val1) =>  true
+ (get-properties x *indicator-list*) =>  PROP1, VAL1, (PROP1 VAL1)
+ x =>  (PROP1 VAL1)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+get, getf

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_se.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_se.htm new file mode 100644 index 00000000..00fe2941 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_se.htm @@ -0,0 +1,81 @@ + + + +CLHS: Function GET-SETF-EXPANSION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GET-SETF-EXPANSION

+

+

Syntax:

+

+ +get-setf-expansion place &optional environment

=> vars, vals, store-vars, writer-form, reader-form

+

+

Arguments and Values:

+

+place---a place.

+ environment---an environment object.

+vars, vals, store-vars, writer-form, reader-form---a setf expansion.

+

Description:

+

+Determines five values constituting the setf expansion for place in environment; see Section 5.1.1.2 (Setf Expansions).

+ If environment is not supplied or nil, the environment is the null lexical environment.

+

Examples:

+

+

+ (get-setf-expansion 'x)
+=>  NIL, NIL, (#:G0001), (SETQ X #:G0001), X 
+
+

+ +

+;;; This macro is like POP 
+
+ (defmacro xpop (place &environment env)
+   (multiple-value-bind (dummies vals new setter getter)
+                        (get-setf-expansion place env)
+      `(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
+         (if (cdr new) (error "Can't expand this."))
+         (prog1 (car ,(car new))
+                (setq ,(car new) (cdr ,(car new)))
+                ,setter))))
+ 
+ (defsetf frob (x) (value) 
+     `(setf (car ,x) ,value)) =>  FROB
+;;; The following is an error; an error might be signaled at macro expansion time
+ (flet ((frob (x) (cdr x)))  ;Invalid
+   (xpop (frob z)))
+ 
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+defsetf, define-setf-expander, setf

+

Notes:

+

+Any compound form is a valid place, since any compound form whose operator f has no setf expander are expanded into a call to (setf f).

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_un.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_un.htm new file mode 100644 index 00000000..fdcf9fa8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_get_un.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function GET-UNIVERSAL-TIME, GET-DECODED-TIME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GET-UNIVERSAL-TIME, GET-DECODED-TIME

+

Syntax:

+

+ +get-universal-time <no arguments> => universal-time

+

+ +get-decoded-time <no arguments>

=> second, minute, hour, date, month, year, day, daylight-p, zone

+

+

Arguments and Values:

+

+universal-time---a universal time.

+second, minute, hour, date, month, year, day, daylight-p, zone---a decoded time.

+

Description:

+

+get-universal-time returns the current time, represented as a universal time.

+get-decoded-time returns the current time, represented as a decoded time.

+

Examples:

+

+

+;; At noon on July 4, 1976 in Eastern Daylight Time.
+ (get-decoded-time) =>  0, 0, 12, 4, 7, 1976, 6, true, 5
+;; At exactly the same instant.
+ (get-universal-time) =>  2414332800
+;; Exactly five minutes later.
+ (get-universal-time) =>  2414333100
+;; The difference is 300 seconds (five minutes)
+ (- * **) =>  300
+
+

+

Side Effects: None. +

+

Affected By:

+

+The time of day (i.e., the passage of time), the system clock's ability to keep accurate time, and the accuracy of the system clock's initial setting.

+

Exceptional Situations:

+

+An error of type error might be signaled if the current time cannot be determined.

+

See Also:

+

+decode-universal-time, encode-universal-time, Section 25.1.4 (Time)

+

Notes:

+

+

+ (get-decoded-time) ==  (decode-universal-time (get-universal-time))
+
+

+No implementation is required to have a way to verify that the time returned is correct. However, if an implementation provides a validity check (e.g., the failure to have properly initialized the system clock can be reliably detected) and that validity check fails, the implementation is strongly encouraged (but not required) to signal an error of type error (rather than, for example, returning a known-to-be-wrong value) that is correctable by allowing the user to interactively set the correct time.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_getf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_getf.htm new file mode 100644 index 00000000..f0f8c273 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_getf.htm @@ -0,0 +1,92 @@ + + + +CLHS: Accessor GETF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor GETF

+

Syntax:

+

+ +getf plist indicator &optional default => value

+ +(setf (getf place indicator &optional default) new-value)

+

+

Arguments and Values:

+

+plist---a property list.

+place---a place, the value of which is a property list.

+indicator---an object.

+default---an object. The default is nil.

+value---an object.

+new-value---an object.

+

Description:

+

+getf finds a property on the plist whose property indicator is identical to indicator, and returns its corresponding property value. If there are multiple properties[1] with that property indicator, getf uses the first such property. If there is no property with that property indicator, default is returned.

+setf of getf may be used to associate a new object with an existing indicator in the property list held by place, or to create a new assocation if none exists. If there are multiple properties[1] with that property indicator, setf of getf associates the new-value with the first such property. When a getf form is used as a setf place, any default which is supplied is evaluated according to normal left-to-right evaluation rules, but its value is ignored.

+ setf of getf is permitted to either write the value of place itself, or modify of any part, car or cdr, of the list structure held by place.

Examples:

+

+ +

+ (setq x '()) =>  NIL
+ (getf x 'prop1) =>  NIL
+ (getf x 'prop1 7) =>  7
+ (getf x 'prop1) =>  NIL
+ (setf (getf x 'prop1) 'val1) =>  VAL1
+ (eq (getf x 'prop1) 'val1) =>  true
+ (getf x 'prop1) =>  VAL1
+ (getf x 'prop1 7) =>  VAL1
+ x =>  (PROP1 VAL1)
+
+;; Examples of implementation variation permitted.
+ (setq foo (list 'a 'b 'c 'd 'e 'f)) =>  (A B C D E F)
+ (setq bar (cddr foo)) =>  (C D E F)
+ (remf foo 'c) =>  true
+ foo =>  (A B E F)
+ bar
+=>  (C D E F)
+OR=>  (C)
+OR=>  (NIL)
+OR=>  (C NIL)
+OR=>  (C D)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+get, get-properties, setf, Section 5.1.2.2 (Function Call Forms as Places)

+

Notes:

+

+There is no way (using getf) to distinguish an absent property from one whose value is default; but see get-properties.

+Note that while supplying a default argument to getf in a setf situation is sometimes not very interesting, it is still important because some macros, such as push and incf, require a place argument which data is both read from and written to. In such a context, if a default argument is to be supplied for the read situation, it must be syntactically valid for the write situation as well. For example,

+

+ (let ((plist '()))
+   (incf (getf plist 'count 0))
+   plist) =>  (COUNT 1)
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gethas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gethas.htm new file mode 100644 index 00000000..681d7f98 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_gethas.htm @@ -0,0 +1,82 @@ + + + +CLHS: Accessor GETHASH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor GETHASH

+

Syntax:

+

+ +gethash key hash-table &optional default => value, present-p

+ +(setf (gethash key hash-table &optional default) new-value)

+

+

Arguments and Values:

+

+key---an object.

+hash-table---a hash table.

+default---an object. The default is nil.

+value---an object.

+present-p---a generalized boolean.

+

Description:

+

+Value is the object in hash-table whose key is the same as key under the hash-table's equivalence test. If there is no such entry, value is the default.

+Present-p is true if an entry is found; otherwise, it is false.

+setf may be used with gethash to modify the value associated with a given key, or to add a new entry. When a gethash form is used as a setf place, any default which is supplied is evaluated according to normal left-to-right evaluation rules, but its value is ignored.

+

Examples:

+

+

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32206334>
+ (gethash 1 table) =>  NIL, false
+ (gethash 1 table 2) =>  2, false
+ (setf (gethash 1 table) "one") =>  "one"
+ (setf (gethash 2 table "two") "two") =>  "two"
+ (gethash 1 table) =>  "one", true
+ (gethash 2 table) =>  "two", true
+ (gethash nil table) =>  NIL, false
+ (setf (gethash nil table) nil) =>  NIL 
+ (gethash nil table) =>  NIL, true
+ (defvar *counters* (make-hash-table)) =>  *COUNTERS*
+ (gethash 'foo *counters*) =>  NIL, false
+ (gethash 'foo *counters* 0) =>  0, false
+ (defmacro how-many (obj) `(values (gethash ,obj *counters* 0))) =>  HOW-MANY
+ (defun count-it (obj) (incf (how-many obj))) =>  COUNT-IT
+ (dolist (x '(bar foo foo bar bar baz)) (count-it x))
+ (how-many 'foo) =>  2
+ (how-many 'bar) =>  3
+ (how-many 'quux) =>  0
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+remhash

+

Notes:

+

+The secondary value, present-p, can be used to distinguish the absence of an entry from the presence of an entry that has a value of default.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_graphi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_graphi.htm new file mode 100644 index 00000000..38806c14 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_graphi.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function GRAPHIC-CHAR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function GRAPHIC-CHAR-P

+

Syntax:

+

+ +graphic-char-p char => generalized-boolean

+

+

Arguments and Values:

+

+char---a character.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if character is a graphic character; otherwise, returns false.

+

Examples:

+

+

+ (graphic-char-p #\G) =>  true
+ (graphic-char-p #\#) =>  true
+ (graphic-char-p #\Space) =>  true
+ (graphic-char-p #\Newline) =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+read, Section 2.1 (Character Syntax), Section 13.1.10 (Documentation of Implementation-Defined Scripts)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_1.htm new file mode 100644 index 00000000..1b2efe89 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_1.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function HASH-TABLE-COUNT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function HASH-TABLE-COUNT

+

Syntax:

+

+ +hash-table-count hash-table => count

+

+

Arguments and Values:

+

+hash-table---a hash table.

+count---a non-negative integer.

+

Description:

+

+Returns the number of entries in the hash-table. If hash-table has just been created or newly cleared (see clrhash) the entry count is 0.

+

Examples:

+

+

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32115135>
+ (hash-table-count table) =>  0
+ (setf (gethash 57 table) "fifty-seven") =>  "fifty-seven"
+ (hash-table-count table) =>  1
+ (dotimes (i 100) (setf (gethash i table) i)) =>  NIL
+ (hash-table-count table) =>  100
+
+

+

Side Effects: None. +

+

Affected By:

+

+clrhash, remhash, setf of gethash

+

Exceptional Situations: None. +

+

See Also:

+

+hash-table-size

+

Notes:

+

+The following relationships are functionally correct, although in practice using hash-table-count is probably much faster:

+

+ (hash-table-count table) == 
+ (loop for value being the hash-values of table count t) == 
+ (let ((total 0))
+   (maphash #'(lambda (key value)
+                (declare (ignore key value))
+                (incf total))
+            table)
+   total)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_2.htm new file mode 100644 index 00000000..ef1bc6db --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_2.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function HASH-TABLE-REHASH-SIZE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function HASH-TABLE-REHASH-SIZE

+

+

Syntax:

+

+ +hash-table-rehash-size hash-table => rehash-size

+

+

Arguments and Values:

+

+hash-table---a hash table.

+rehash-size---a real of type (or (integer 1 *) (float (1.0) *)).

+

Description:

+

+Returns the current rehash size of hash-table, suitable for use in a call to make-hash-table in order to produce a hash table with state corresponding to the current state of the hash-table.

+

Examples:

+

+

+ (setq table (make-hash-table :size 100 :rehash-size 1.4))
+=>  #<HASH-TABLE EQL 0/100 2556371>
+ (hash-table-rehash-size table) =>  1.4
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if hash-table is not a hash table.

+

See Also:

+

+make-hash-table, hash-table-rehash-threshold

+

Notes:

+

+ If the hash table was created with an integer rehash size, the result is an integer, indicating that the rate of growth of the hash-table when rehashed is intended to be additive; otherwise, the result is a float, indicating that the rate of growth of the hash-table when rehashed is intended to be multiplicative. However, this value is only advice to the implementation; the actual amount by which the hash-table will grow upon rehash is implementation-dependent.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_3.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_3.htm new file mode 100644 index 00000000..8d6f2f5b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_3.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function HASH-TABLE-REHASH-THRESHOLD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function HASH-TABLE-REHASH-THRESHOLD

+

+

Syntax:

+

+ +hash-table-rehash-threshold hash-table => rehash-threshold

+

+

Arguments and Values:

+

+hash-table---a hash table.

+ rehash-threshold---a real of type (real 0 1).

+

Description:

+

+Returns the current rehash threshold of hash-table, which is suitable for use in a call to make-hash-table in order to produce a hash table with state corresponding to the current state of the hash-table.

+

Examples:

+

+

+ (setq table (make-hash-table :size 100 :rehash-threshold 0.5))
+=>  #<HASH-TABLE EQL 0/100 2562446>
+ (hash-table-rehash-threshold table) =>  0.5
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if hash-table is not a hash table.

+

See Also:

+

+make-hash-table, hash-table-rehash-size

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_4.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_4.htm new file mode 100644 index 00000000..c3607b9f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_4.htm @@ -0,0 +1,55 @@ + + + +CLHS: Function HASH-TABLE-SIZE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function HASH-TABLE-SIZE

+

+

Syntax:

+

+ +hash-table-size hash-table => size

+

+

Arguments and Values:

+

+hash-table---a hash table.

+size---a non-negative integer.

+

Description:

+

+Returns the current size of hash-table, which is suitable for use in a call to make-hash-table in order to produce a hash table with state corresponding to the current state of the hash-table.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if hash-table is not a hash table.

+

See Also:

+

+hash-table-count, make-hash-table

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_5.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_5.htm new file mode 100644 index 00000000..f606949d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_5.htm @@ -0,0 +1,55 @@ + + + +CLHS: Function HASH-TABLE-TEST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function HASH-TABLE-TEST

+

+

Syntax:

+

+ +hash-table-test hash-table => test

+

+

Arguments and Values:

+

+hash-table---a hash table.

+test---a function designator. For the four standardized hash table test functions (see make-hash-table), the test value returned is always a symbol. If an implementation permits additional tests, it is implementation-dependent whether such tests are returned as function objects or function names.

+

Description:

+

+Returns the test used for comparing keys in hash-table.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if hash-table is not a hash table.

+

See Also:

+

+make-hash-table

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_t.htm new file mode 100644 index 00000000..d2531467 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_hash_t.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function HASH-TABLE-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function HASH-TABLE-P

+

Syntax:

+

+ +hash-table-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type hash-table; otherwise, returns false.

+

Examples:

+

+

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32511220>
+ (hash-table-p table) =>  true
+ (hash-table-p 37) =>  false
+ (hash-table-p '((a . 1) (b . 2))) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (hash-table-p object) ==  (typep object 'hash-table)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_identi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_identi.htm new file mode 100644 index 00000000..51b55fe8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_identi.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function IDENTITY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function IDENTITY

+

Syntax:

+

+ +identity object => object

+

+

Arguments and Values:

+

+object---an object.

+

Description:

+

+Returns its argument object.

+

Examples:

+

+

+ (identity 101) =>  101
+ (mapcan #'identity (list (list 1 2 3) '(4 5 6))) =>  (1 2 3 4 5 6)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+identity is intended for use with functions that require a function as an argument.

+(eql x (identity x)) returns true for all possible values of x, but (eq x (identity x)) might return false when x is a number or character.

+identity could be defined by

+

+(defun identity (x) x)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_import.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_import.htm new file mode 100644 index 00000000..0e9b9a6f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_import.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function IMPORT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function IMPORT

+

Syntax:

+

+ +import symbols &optional package => t

+

+

Arguments and Values:

+

+symbols---a designator for a list of symbols.

+ package---a package designator. The default is the current package.

+

Description:

+

+import adds symbol or symbols to the internals of package, checking for name conflicts with existing symbols either present in package or accessible to it. Once the symbols have been imported, they may be referenced in the importing package without the use of a package prefix when using the Lisp reader.

+A name conflict in import between the symbol being imported and a symbol inherited from some other package can be resolved in favor of the symbol being imported by making it a shadowing symbol, or in favor of the symbol already accessible by not doing the import. A name conflict in import with a symbol already present in the package may be resolved by uninterning that symbol, or by not doing the import.

+The imported symbol is not automatically exported from the current package, but if it is already present and external, then the fact that it is external is not changed. If any symbol to be imported has no home package (i.e., (symbol-package symbol) => nil), import sets the home package of the symbol to package.

+If the symbol is already present in the importing package, import has no effect.

+

Examples:

+

+

+ (import 'common-lisp::car (make-package 'temp :use nil)) =>  T
+ (find-symbol "CAR" 'temp) =>  CAR, :INTERNAL
+ (find-symbol "CDR" 'temp) =>  NIL, NIL 
+
+

+The form (import 'editor:buffer) takes the external symbol named buffer in the EDITOR package (this symbol was located when the form was read by the Lisp reader) and adds it to the current package as an internal symbol. The symbol buffer is then present in the current package.

+

Side Effects:

+

+The package system is modified.

+

Affected By:

+

+Current state of the package system.

+

Exceptional Situations:

+

+import signals a correctable error of type package-error if any of the symbols to be imported has the same name (under string=) as some distinct symbol (under eql) already accessible in the package, even if the conflict is with a shadowing symbol of the package.

+

See Also:

+

+shadow, export

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_in_stm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_in_stm.htm new file mode 100644 index 00000000..e85406fe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_in_stm.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function INPUT-STREAM-P, OUTPUT-STREAM-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INPUT-STREAM-P, OUTPUT-STREAM-P

+

Syntax:

+

+ +input-stream-p stream => generalized-boolean

+ +output-stream-p stream => generalized-boolean

+

+

Arguments and Values:

+

+stream---a stream.

+generalized-boolean---a generalized boolean.

+

Description:

+

+input-stream-p returns true if stream is an input stream; otherwise, returns false.

+output-stream-p returns true if stream is an output stream; otherwise, returns false.

+

Examples:

+

+

+ (input-stream-p *standard-input*) =>  true
+ (input-stream-p *terminal-io*) =>  true
+ (input-stream-p (make-string-output-stream)) =>  false
+
+ (output-stream-p *standard-output*) =>  true
+ (output-stream-p *terminal-io*) =>  true
+ (output-stream-p (make-string-input-stream "jr")) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_init_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_init_i.htm new file mode 100644 index 00000000..8a1b6b55 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_init_i.htm @@ -0,0 +1,57 @@ + + + +CLHS: Standard Generic Function INITIALIZE-INSTANCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function INITIALIZE-INSTANCE

+

Syntax:

+

+ +initialize-instance instance &rest initargs &key &allow-other-keys => instance

+

+

Method Signatures:

+

+ +initialize-instance (instance standard-object) &rest initargs

+

+

Arguments and Values:

+

+instance---an object.

+initargs---a defaulted initialization argument list.

+

Description:

+

+Called by make-instance to initialize a newly created instance. The generic function is called with the new instance and the defaulted initialization argument list.

+The system-supplied primary method on initialize-instance initializes the slots of the instance with values according to the initargs and the :initform forms of the slots. It does this by calling the generic function shared-initialize with the following arguments: the instance, t (this indicates that all slots for which no initialization arguments are provided should be initialized according to their :initform forms), and the initargs.

+Programmers can define methods for initialize-instance to specify actions to be taken when an instance is initialized. If only after methods are defined, they will be run after the system-supplied primary method for initialization and therefore will not interfere with the default behavior of initialize-instance.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+shared-initialize, make-instance, slot-boundp, slot-makunbound, Section 7.1 (Object Creation and Initialization), Section 7.1.4 (Rules for Initialization Arguments), Section 7.1.2 (Declaring the Validity of Initialization Arguments)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inspec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inspec.htm new file mode 100644 index 00000000..913eb6da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inspec.htm @@ -0,0 +1,55 @@ + + + +CLHS: Function INSPECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INSPECT

+

Syntax:

+

+ +inspect object => implementation-dependent

+

+

Arguments and Values:

+

+object---an object.

+

Description:

+

+inspect is an interactive version of describe. The nature of the interaction is implementation-dependent, but the purpose of inspect is to make it easy to wander through a data structure, examining and modifying parts of it.

+

Examples: None. +

+

Side Effects:

+

+implementation-dependent.

+

Affected By:

+

+implementation-dependent.

+

Exceptional Situations:

+

+implementation-dependent.

+

See Also:

+

+describe

+

Notes:

+

+Implementations are encouraged to respond to the typing of ? or a ``help key'' by providing help, including a list of commands.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inte_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inte_1.htm new file mode 100644 index 00000000..790d3623 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_inte_1.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function INTEGERP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INTEGERP

+

Syntax:

+

+ +integerp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type integer; otherwise, returns false.

+

Examples:

+ +

+ (integerp 1) =>  true
+ (integerp (expt 2 130)) =>  true
+ (integerp 6/5) =>  false
+ (integerp nil) =>  false
+
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (integerp object) ==  (typep object 'integer)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intege.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intege.htm new file mode 100644 index 00000000..c0209447 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intege.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function INTEGER-LENGTH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INTEGER-LENGTH

+

Syntax:

+

+ +integer-length integer => number-of-bits

+

+

Arguments and Values:

+

+integer---an integer.

+number-of-bits---a non-negative integer.

+

Description:

+

+Returns the number of bits needed to represent integer in binary two's-complement format.

+

Examples:

+

+

+ (integer-length 0) =>  0
+ (integer-length 1) =>  1
+ (integer-length 3) =>  2
+ (integer-length 4) =>  3
+ (integer-length 7) =>  3
+ (integer-length -1) =>  0
+ (integer-length -4) =>  2
+ (integer-length -7) =>  3
+ (integer-length -8) =>  3
+ (integer-length (expt 2 9)) =>  10
+ (integer-length (1- (expt 2 9))) =>  9
+ (integer-length (- (expt 2 9))) =>  9
+ (integer-length (- (1+ (expt 2 9)))) =>  10
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if integer is not an integer.

+

See Also: None. +

+

Notes:

+

+This function could have been defined by:

+

+(defun integer-length (integer)
+  (ceiling (log (if (minusp integer)
+                    (- integer)
+                    (1+ integer))
+                2)))
+
+

+If integer is non-negative, then its value can be represented in unsigned binary form in a field whose width in bits is no smaller than (integer-length integer). Regardless of the sign of integer, its value can be represented in signed binary two's-complement form in a field whose width in bits is no smaller than (+ (integer-length integer) 1).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intera.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intera.htm new file mode 100644 index 00000000..e607dce2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intera.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function INTERACTIVE-STREAM-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INTERACTIVE-STREAM-P

+

+

Syntax:

+

+ +interactive-stream-p stream => generalized-boolean

+

+

Arguments and Values:

+

+stream---a stream.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if stream is an interactive stream; otherwise, returns false.

+

Examples:

+

+

+ (when (> measured limit)
+   (let ((error (round (* (- measured limit) 100)
+                       limit)))
+     (unless (if (interactive-stream-p *query-io*)
+                 (yes-or-no-p "The frammis is out of tolerance by ~D%.~@
+                               Is it safe to proceed? " error)
+                 (< error 15))  ;15% is acceptable
+       (error "The frammis is out of tolerance by ~D%." error))))
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream.

+

See Also:

+

+Section 21.1 (Stream Concepts)

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intern.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intern.htm new file mode 100644 index 00000000..2615fc86 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_intern.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function INTERN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INTERN

+

Syntax:

+

+ +intern string &optional package => symbol, status

+

+

Arguments and Values:

+

+string---a string.

+ package---a package designator. The default is the current package.

+symbol---a symbol.

+status---one of :inherited, :external, :internal, or nil.

+

Description:

+

+intern enters a symbol named string into package. If a symbol whose name is the same as string is already accessible in package, it is returned. If no such symbol is accessible in package, a new symbol with the given name is created and entered into package as an internal symbol, or as an external symbol if the package is the KEYWORD package; package becomes the home package of the created symbol.

+The first value returned by intern, symbol, is the symbol that was found or created. The meaning of the secondary value, status, is as follows:

:internal

+The symbol was found and is present in package as an internal symbol.

+

:external

+The symbol was found and is present as an external symbol.

+

:inherited

+The symbol was found and is inherited via use-package (which implies that the symbol is internal).

+

nil

+No pre-existing symbol was found, so one was created.

+It is implementation-dependent whether the string that becomes the new symbol's name is the given string or a copy of it. Once a string has been given as the string argument to intern in this situation where a new symbol is created, the consequences are undefined if a subsequent attempt is made to alter that string.

+

+

Examples:

+

+ +

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (intern "Never-Before") =>  |Never-Before|, NIL
+ (intern "Never-Before") =>  |Never-Before|, :INTERNAL 
+ (intern "NEVER-BEFORE" "KEYWORD") =>  :NEVER-BEFORE, NIL
+ (intern "NEVER-BEFORE" "KEYWORD") =>  :NEVER-BEFORE, :EXTERNAL
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+find-symbol, read, symbol, unintern, Section 2.3.4 (Symbols as Tokens)

+

Notes:

+

+intern does not need to do any name conflict checking because it never creates a new symbol if there is already an accessible symbol with the name given.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invali.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invali.htm new file mode 100644 index 00000000..7c06b981 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invali.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function INVALID-METHOD-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INVALID-METHOD-ERROR

+

Syntax:

+

+ +invalid-method-error method format-control &rest args => implementation-dependent

+

+

Arguments and Values:

+

+method---a method.

+ format-control---a format control.

+args---format arguments for the format-control.

+

Description:

+

+The function invalid-method-error is used to signal an error of type error when there is an applicable method whose qualifiers are not valid for the method combination type. The error message is constructed by using the format-control suitable for format and any args to it. Because an implementation may need to add additional contextual information to the error message, invalid-method-error should be called only within the dynamic extent of a method combination function.

+The function invalid-method-error is called automatically when a method fails to satisfy every qualifier pattern and predicate in a define-method-combination form. A method combination function that imposes additional restrictions should call invalid-method-error explicitly if it encounters a method it cannot accept.

+Whether invalid-method-error returns to its caller or exits via throw is implementation-dependent.

+

Examples: None. +

+

Side Effects:

+

+The debugger might be entered.

+

Affected By:

+

+*break-on-signals*

+

Exceptional Situations: None. +

+

See Also:

+

+define-method-combination

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_1.htm new file mode 100644 index 00000000..9fd80b43 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_1.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function INVOKE-RESTART + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INVOKE-RESTART

+

Syntax:

+

+ +invoke-restart restart &rest arguments => result*

+

+

Arguments and Values:

+

+restart---a restart designator.

+argument---an object.

+results---the values returned by the function associated with restart, if that function returns.

+

Description:

+

+Calls the function associated with restart, passing arguments to it. Restart must be valid in the current dynamic environment.

+

Examples:

+ +

+ (defun add3 (x) (check-type x number) (+ x 3))
+ 
+ (foo 'seven)
+>>  Error: The value SEVEN was not of type NUMBER.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a different value to use.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> (invoke-restart 'store-value 7)
+=>  10
+
+

+

Side Effects:

+

+A non-local transfer of control might be done by the restart.

+

Affected By:

+

+Existing restarts.

+

Exceptional Situations:

+

+If restart is not valid, an error of type control-error is signaled.

+

See Also:

+

+find-restart, restart-bind, restart-case, invoke-restart-interactively

+

Notes:

+

+The most common use for invoke-restart is in a handler. It might be used explicitly, or implicitly through invoke-restart-interactively or a restart function.

+Restart functions call invoke-restart, not vice versa. That is, invoke-restart provides primitive functionality, and restart functions are non-essential ``syntactic sugar.''

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_2.htm new file mode 100644 index 00000000..3e448222 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invo_2.htm @@ -0,0 +1,77 @@ + + + +CLHS: Function INVOKE-RESTART-INTERACTIVELY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INVOKE-RESTART-INTERACTIVELY

+

Syntax:

+

+ +invoke-restart-interactively restart => result*

+

+

Arguments and Values:

+

+restart---a restart designator.

+results---the values returned by the function associated with restart, if that function returns.

+

Description:

+

+invoke-restart-interactively calls the function associated with restart, prompting for any necessary arguments. If restart is a name, it must be valid in the current dynamic environment.

+ invoke-restart-interactively prompts for arguments by executing the code provided in the :interactive keyword to restart-case or :interactive-function keyword to restart-bind.

+If no such options have been supplied in the corresponding restart-bind or restart-case, then the consequences are undefined if the restart takes required arguments. If the arguments are optional, an argument list of nil is used.

+ Once the arguments have been determined, invoke-restart-interactively executes the following:

+

+ (apply #'invoke-restart restart arguments)
+
+

+

Examples:

+

+

+ (defun add3 (x) (check-type x number) (+ x 3))
+ 
+ (add3 'seven)
+>>  Error: The value SEVEN was not of type NUMBER.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a different value to use.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> (invoke-restart-interactively 'store-value)
+>>  Type a form to evaluate and use: 7
+=>  10
+
+

+

Side Effects:

+

+If prompting for arguments is necesary, some typeout may occur (on query I/O).

+A non-local transfer of control might be done by the restart.

+

Affected By:

+

+*query-io*, active restarts

+

Exceptional Situations:

+

+If restart is not valid, an error of type control-error is signaled.

+

See Also:

+

+find-restart, invoke-restart, restart-case, restart-bind

+

Notes:

+

+invoke-restart-interactively is used internally by the debugger and may also be useful in implementing other portable, interactive debugging tools.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invoke.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invoke.htm new file mode 100644 index 00000000..0d83d2f2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_invoke.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function INVOKE-DEBUGGER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INVOKE-DEBUGGER

+

Syntax:

+

+ +invoke-debugger condition =>|

+

+

Arguments and Values:

+

+condition---a condition object.

+

Description:

+

+invoke-debugger attempts to enter the debugger with condition.

+If *debugger-hook* is not nil, it should be a function (or the name of a function) to be called prior to entry to the standard debugger. The function is called with *debugger-hook* bound to nil, and the function must accept two arguments: the condition and the value of *debugger-hook* prior to binding it to nil. If the function returns normally, the standard debugger is entered.

+The standard debugger never directly returns. Return can occur only by a non-local transfer of control, such as the use of a restart function.

+

Examples:

+

+

+ (ignore-errors ;Normally, this would suppress debugger entry
+   (handler-bind ((error #'invoke-debugger)) ;But this forces debugger entry
+     (error "Foo.")))
+Debug: Foo.
+To continue, type :CONTINUE followed by an option number:
+ 1: Return to Lisp Toplevel.
+Debug>
+
+

+

Side Effects:

+

+*debugger-hook* is bound to nil, program execution is discontinued, and the debugger is entered.

+

Affected By:

+

+*debug-io* and *debugger-hook*.

+

Exceptional Situations: None. +

+

See Also:

+

+error, break

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_isec_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_isec_.htm new file mode 100644 index 00000000..f648ec86 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_isec_.htm @@ -0,0 +1,85 @@ + + + +CLHS: Function INTERSECTION, NINTERSECTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function INTERSECTION, NINTERSECTION

+

Syntax:

+

+ +intersection list-1 list-2 &key key test test-not => result-list

+ +nintersection list-1 list-2 &key key test test-not => result-list

+

+

Arguments and Values:

+

+list-1---a proper list.

+list-2---a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+result-list---a list.

+

Description:

+

+intersection and nintersection return a list that contains every element that occurs in both list-1 and list-2.

+nintersection is the destructive version of intersection. It performs the same operation, but may destroy list-1 using its cells to construct the result. list-2 is not destroyed.

+The intersection operation is described as follows. For all possible ordered pairs consisting of one element from list-1 and one element from list-2, :test or :test-not are used to determine whether they satisfy the test. The first argument to the :test or :test-not function is an element of list-1; the second argument is an element of list-2. If :test or :test-not is not supplied, eql is used. It is an error if :test and :test-not are supplied in the same function call.

+If :key is supplied (and not nil), it is used to extract the part to be tested from the list element. The argument to the :key function is an element of either list-1 or list-2; the :key function typically returns part of the supplied element. If :key is not supplied or nil, the list-1 and list-2 elements are used.

+For every pair that satifies the test, exactly one of the two elements of the pair will be put in the result. No element from either list appears in the result that does not satisfy the test for an element from the other list. If one of the lists contains duplicate elements, there may be duplication in the result.

+There is no guarantee that the order of elements in the result will reflect the ordering of the arguments in any particular way. The result list may share cells with, or be eq to, either list-1 or list-2 if appropriate.

+

Examples:

+

+

+ (setq list1 (list 1 1 2 3 4 a b c "A" "B" "C" "d")
+       list2 (list 1 4 5 b c d "a" "B" "c" "D")) 
+  =>  (1 4 5 B C D "a" "B" "c" "D")
+ (intersection list1 list2) =>  (C B 4 1 1)
+ (intersection list1 list2 :test 'equal) =>  ("B" C B 4 1 1)
+ (intersection list1 list2 :test #'equalp) =>  ("d" "C" "B" "A" C B 4 1 1) 
+ (nintersection list1 list2) =>  (1 1 4 B C)
+ list1 =>  implementation-dependent ;e.g.,  (1 1 4 B C)
+ list2 =>  implementation-dependent ;e.g.,  (1 4 5 B C D "a" "B" "c" "D")
+ (setq list1 (copy-list '((1 . 2) (2 . 3) (3 . 4) (4 . 5))))
+=>  ((1 . 2) (2 . 3) (3 . 4) (4 . 5)) 
+ (setq list2 (copy-list '((1 . 3) (2 . 4) (3 . 6) (4 . 8))))
+=>  ((1 . 3) (2 . 4) (3 . 6) (4 . 8)) 
+ (nintersection list1 list2 :key #'cdr) =>  ((2 . 3) (3 . 4)) 
+ list1 =>  implementation-dependent ;e.g.,  ((1 . 2) (2 . 3) (3 . 4)) 
+ list2 =>  implementation-dependent ;e.g.,  ((1 . 3) (2 . 4) (3 . 6) (4 . 8)) 
+
+

+

Side Effects:

+

+ nintersection can modify list-1, but not list-2.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list-1 and list-2 are not proper lists.

+

See Also:

+

+union, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+ Since the nintersection side effect is not required, it should not be used in for-effect-only positions in portable code.

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_kwdp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_kwdp.htm new file mode 100644 index 00000000..029480aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_kwdp.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function KEYWORDP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function KEYWORDP

+

Syntax:

+

+ +keywordp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is a keyword[1]; otherwise, returns false.

+

Examples:

+

+

+ (keywordp 'elephant) =>  false
+ (keywordp 12) =>  false
+ (keywordp :test) =>  true
+ (keywordp ':test) =>  true
+ (keywordp nil) =>  false
+ (keywordp :nil) =>  true
+ (keywordp '(:test)) =>  false
+ (keywordp "hello") =>  false
+ (keywordp ":hello") =>  false
+ (keywordp '&optional) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+constantp, keyword, symbolp, symbol-package

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_last.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_last.htm new file mode 100644 index 00000000..dc066da0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_last.htm @@ -0,0 +1,88 @@ + + + +CLHS: Function LAST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LAST

+

Syntax:

+

+ +last list &optional n => tail

+

+

Arguments and Values:

+

+list---a list, which might be a dotted list but must not be a circular list.

+ n---a non-negative integer. The default is 1.

+tail---an object.

+

Description:

+

+ last returns the last n conses (not the last n elements) of list). If list is (), last returns ().

+If n is zero, the atom that terminates list is returned. If n is greater than or equal to the number of cons cells in list, the result is list.

+

Examples:

+

+ +

+ (last nil) =>  NIL
+ (last '(1 2 3)) =>  (3)
+ (last '(1 2 . 3)) =>  (2 . 3)
+ (setq x (list 'a 'b 'c 'd)) =>  (A B C D)
+ (last x) =>  (D)
+ (rplacd (last x) (list 'e 'f)) x =>  (A B C D E F)
+ (last x) =>  (F)
+
+ (last '(a b c))   =>  (C)
+
+ (last '(a b c) 0) =>  ()
+ (last '(a b c) 1) =>  (C)
+ (last '(a b c) 2) =>  (B C)
+ (last '(a b c) 3) =>  (A B C)
+ (last '(a b c) 4) =>  (A B C)
+
+ (last '(a . b) 0) =>  B
+ (last '(a . b) 1) =>  (A . B)
+ (last '(a . b) 2) =>  (A . B)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+ The consequences are undefined if list is a circular list. Should signal an error of type type-error if n is not a non-negative integer.

+

See Also:

+

+butlast, nth

+

Notes:

+

+ The following code could be used to define last.

+

+ (defun last (list &optional (n 1))
+   (check-type n (integer 0))
+   (do ((l list (cdr l))
+        (r list)
+        (i 0 (+ i 1)))
+       ((atom l) r)
+     (if (>= i n) (pop r))))
+
+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lcm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lcm.htm new file mode 100644 index 00000000..9d89e6b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lcm.htm @@ -0,0 +1,79 @@ + + + +CLHS: Function LCM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LCM

+

Syntax:

+

+ +lcm &rest integers => least-common-multiple

+

+

Arguments and Values:

+

+integer---an integer.

+least-common-multiple---a non-negative integer.

+

Description:

+

+lcm returns the least common multiple of the integers.

+ If no integer is supplied, the integer 1 is returned.

+If only one integer is supplied, the absolute value of that integer is returned.

+For two arguments that are not both zero,

+

+ (lcm a b) ==  (/ (abs (* a b)) (gcd a b))
+
+

+If one or both arguments are zero,

+

+ (lcm a 0) ==  (lcm 0 a) ==  0
+
+

+For three or more arguments,

+

+ (lcm a b c ... z) ==  (lcm (lcm a b) c ... z)
+
+

+

Examples:

+ +

+ (lcm 10) =>  10
+ (lcm 25 30) =>  150
+ (lcm -24 18 10) =>  360
+ (lcm 14 35) =>  70
+ (lcm 0 5) =>  0
+ (lcm 1 2 3 4 5 6) =>  60
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if any argument is not an integer.

+

See Also:

+

+gcd

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ld_log.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ld_log.htm new file mode 100644 index 00000000..4ab82661 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ld_log.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function LOAD-LOGICAL-PATHNAME-TRANSLATIONS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOAD-LOGICAL-PATHNAME-TRANSLATIONS

+

+

Syntax:

+

+ +load-logical-pathname-translations host => just-loaded

+

+

Arguments and Values:

+

+host---a string.

+just-loaded---a generalized boolean.

+

Description:

+

+Searches for and loads the definition of a logical host named host, if it is not already defined. The specific nature of the search is implementation-defined.

+If the host is already defined, no attempt to find or load a definition is attempted, and false is returned. If the host is not already defined, but a definition is successfully found and loaded, true is returned. Otherwise, an error is signaled.

+

Examples:

+

+

+ (translate-logical-pathname "hacks:weather;barometer.lisp.newest")
+>>  Error: The logical host HACKS is not defined.
+ (load-logical-pathname-translations "HACKS")
+>>  ;; Loading SYS:SITE;HACKS.TRANSLATIONS
+>>  ;; Loading done.
+=>  true
+ (translate-logical-pathname "hacks:weather;barometer.lisp.newest")
+=>  #P"HELIUM:[SHARED.HACKS.WEATHER]BAROMETER.LSP;0"
+ (load-logical-pathname-translations "HACKS")
+=>  false
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If no definition is found, an error of type error is signaled.

+

See Also:

+

+logical-pathname

+

Notes:

+

+Logical pathname definitions will be created not just by implementors but also by programmers. As such, it is important that the search strategy be documented. For example, an implementation might define that the definition of a host is to be found in a file called ``host.translations'' in some specifically named directory.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb.htm new file mode 100644 index 00000000..04354ed7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb.htm @@ -0,0 +1,80 @@ + + + +CLHS: Accessor LDB + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor LDB

+

Syntax:

+

+ +ldb bytespec integer => byte

+

+ +(setf (ldb bytespec place) new-byte)

+

+

Pronunciation:

+

+ ['lidib] or ['liduhb] or ['el'dee'bee]

+

Arguments and Values:

+

+bytespec---a byte specifier.

+integer---an integer.

+byte, new-byte---a non-negative integer.

+

Description:

+

+ldb extracts and returns the byte of integer specified by bytespec.

+ldb returns an integer in which the bits with weights 2^(s-1) through 2^0 are the same as those in integer with weights 2^(p+s-1) through 2^p, and all other bits zero; s is (byte-size bytespec) and p is (byte-position bytespec).

+setf may be used with ldb to modify a byte within the integer that is stored in a given place. The order of evaluation, when an ldb form is supplied to setf, is exactly left-to-right. The effect is to perform a dpb operation and then store the result back into the place.

+

Examples:

+

+

+ (ldb (byte 2 1) 10) =>  1
+ (setq a (list 8)) =>  (8)
+ (setf (ldb (byte 2 1) (car a)) 1) =>  1
+ a =>  (10)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+byte, byte-position, byte-size, dpb

+

Notes:

+

+

+ (logbitp j (ldb (byte s p) n))
+    ==  (and (< j s) (logbitp (+ j p) n))
+
+

+In general,

+

+ (ldb (byte 0 x) y) =>  0
+
+

+for all valid values of x and y.

+Historically, the name ``ldb'' comes from a DEC PDP-10 assembly language instruction meaning ``load byte.''

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb_te.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb_te.htm new file mode 100644 index 00000000..77b77388 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldb_te.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function LDB-TEST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LDB-TEST

+

Syntax:

+

+ +ldb-test bytespec integer => generalized-boolean

+

+

Arguments and Values:

+

+bytespec---a byte specifier.

+integer---an integer.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if any of the bits of the byte in integer specified by bytespec is non-zero; otherwise returns false.

+

Examples:

+

+

+ (ldb-test (byte 4 1) 16) =>  true
+ (ldb-test (byte 3 1) 16) =>  false
+ (ldb-test (byte 3 2) 16) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+byte, ldb, zerop

+

Notes:

+ +

+ (ldb-test bytespec n) == 
+ (not (zerop (ldb bytespec n))) == 
+ (logtest (ldb bytespec -1) n)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldiffc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldiffc.htm new file mode 100644 index 00000000..8f38462d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ldiffc.htm @@ -0,0 +1,117 @@ + + + +CLHS: Function LDIFF, TAILP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LDIFF, TAILP

+

Syntax:

+

+ +ldiff list object => result-list

+ +tailp object list => generalized-boolean

+

+

Arguments and Values:

+

+list---a list, which might be a dotted list.

+object---an object.

+result-list---a list.

+generalized-boolean---a generalized boolean.

+

Description:

+

+ If object is the same as some tail of list, tailp returns true; otherwise, it returns false.

+If object is the same as some tail of list, ldiff returns a fresh list of the elements of list that precede object in the list structure of list; otherwise, it returns a copy[2] of list.

+

Examples:

+

+ +

+ (let ((lists '#((a b c) (a b c . d))))
+   (dotimes (i (length lists)) ()
+     (let ((list (aref lists i)))
+       (format t "~2&list=~S ~21T(tailp object list)~
+                  ~44T(ldiff list object)~%" list)
+         (let ((objects (vector list (cddr list) (copy-list (cddr list))
+                                '(f g h) '() 'd 'x)))
+           (dotimes (j (length objects)) ()
+             (let ((object (aref objects j)))
+               (format t "~& object=~S ~21T~S ~44T~S"
+                       object (tailp object list) (ldiff list object))))))))
+>>  
+>>  list=(A B C)         (tailp object list)    (ldiff list object)
+>>   object=(A B C)      T                      NIL
+>>   object=(C)          T                      (A B)
+>>   object=(C)          NIL                    (A B C)
+>>   object=(F G H)      NIL                    (A B C)
+>>   object=NIL          T                      (A B C)
+>>   object=D            NIL                    (A B C)
+>>   object=X            NIL                    (A B C)
+>>  
+>>  list=(A B C . D)     (tailp object list)    (ldiff list object)
+>>   object=(A B C . D)  T                      NIL
+>>   object=(C . D)      T                      (A B)
+>>   object=(C . D)      NIL                    (A B C . D)
+>>   object=(F G H)      NIL                    (A B C . D)
+>>   object=NIL          NIL                    (A B C . D)
+>>   object=D            T                      (A B C)
+>>   object=X            NIL                    (A B C . D)
+=>  NIL
+
+

+

Side Effects:

+

+Neither ldiff nor tailp modifies either of its arguments.

+

Affected By: None. +

+

Exceptional Situations:

+

+ Should be prepared to signal an error of type type-error if list is not a proper list or a dotted list.

+

See Also:

+

+set-difference

+

Notes:

+

+If the list is a circular list, tailp will reliably yield a value only if the given object is in fact a tail of list. Otherwise, the consequences are unspecified: a given implementation which detects the circularity must return false, but since an implementation is not obliged to detect such a situation, tailp might just loop indefinitely without returning in that case.

+

+tailp could be defined as follows:

+

+ (defun tailp (object list)
+   (do ((list list (cdr list)))
+       ((atom list) (eql list object))
+      (if (eql object list)
+          (return t))))
+
+

+and ldiff could be defined by:

+

+(defun ldiff (list object)
+  (do ((list list (cdr list))
+       (r '() (cons (car list) r)))
+      ((atom list)
+       (if (eql list object) (nreverse r) (nreconc r list)))
+    (when (eql object list)
+      (return (nreverse r)))))
+
+

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_length.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_length.htm new file mode 100644 index 00000000..bfcc58b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_length.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function LENGTH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LENGTH

+

Syntax:

+

+ +length sequence => n

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+n---a non-negative integer.

+

Description:

+

+Returns the number of elements in sequence.

+If sequence is a vector with a fill pointer, the active length as specified by the fill pointer is returned.

+

Examples:

+

+

+ (length "abc") =>  3
+ (setq str (make-array '(3) :element-type 'character 
+                            :initial-contents "abc"
+                            :fill-pointer t)) =>  "abc"
+ (length str) =>  3
+ (setf (fill-pointer str) 2) =>  2
+ (length str) =>  2
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+list-length, sequence

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lisp_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lisp_i.htm new file mode 100644 index 00000000..8019b3b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_lisp_i.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function LISP-IMPLEMENTATION-TYPE... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LISP-IMPLEMENTATION-TYPE, LISP-IMPLEMENTATION-VERSION

+

Syntax:

+

+ +lisp-implementation-type <no arguments> => description

+

+ +lisp-implementation-version <no arguments> => description

+

+

Arguments and Values:

+

+description---a string or nil.

+

Description:

+

+lisp-implementation-type and lisp-implementation-version identify the current implementation of Common Lisp.

+lisp-implementation-type returns a string that identifies the generic name of the particular Common Lisp implementation.

+lisp-implementation-version returns a string that identifies the version of the particular Common Lisp implementation.

+If no appropriate and relevant result can be produced, nil is returned instead of a string.

+

Examples:

+

+

+ (lisp-implementation-type)
+=>  "ACME Lisp"
+OR=>  "Joe's Common Lisp"
+ (lisp-implementation-version)
+=>  "1.3a"
+=>  "V2"
+OR=>  "Release 17.3, ECO #6"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_.htm new file mode 100644 index 00000000..9bbbcc8f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function LIST, LIST* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LIST, LIST*

+

Syntax:

+

+ +list &rest objects => list

+ +list* &rest objects+ => result

+

+

Arguments and Values:

+

+object---an object.

+list---a list.

+result---an object.

+

Description:

+

+list returns a list containing the supplied objects.

+list* is like list except that the last argument to list becomes the car of the last cons constructed, while the last argument to list* becomes the cdr of the last cons constructed. Hence, any given call to list* always produces one fewer conses than a call to list with the same number of arguments.

+If the last argument to list* is a list, the effect is to construct a new list which is similar, but which has additional elements added to the front corresponding to the preceding arguments of list*.

+If list* receives only one object, that object is returned, regardless of whether or not it is a list.

+

Examples:

+

+

+ (list 1) =>  (1)
+ (list* 1) =>  1
+ (setq a 1) =>  1
+ (list a 2) =>  (1 2)
+ '(a 2) =>  (A 2)
+ (list 'a 2) =>  (A 2)
+ (list* a 2) =>  (1 . 2)
+ (list) =>  NIL ;i.e.,  ()
+ (setq a '(1 2)) =>  (1 2)
+ (eq a (list* a)) =>  true
+ (list 3 4 'a (car '(b . c)) (+ 6 -2)) =>  (3 4 A B 4)
+ (list* 'a 'b 'c 'd) ==  (cons 'a (cons 'b (cons 'c 'd))) =>  (A B C . D)
+ (list* 'a 'b 'c '(d e f)) =>  (A B C D E F)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+cons

+

Notes:

+

+

+ (list* x) ==  x
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_a.htm new file mode 100644 index 00000000..24522239 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_a.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function LIST-ALL-PACKAGES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LIST-ALL-PACKAGES

+

Syntax:

+

+ +list-all-packages <no arguments> => packages

+

+

Arguments and Values:

+

+packages---a list of package objects.

+

Description:

+

+list-all-packages returns a fresh list of all registered packages.

+

Examples:

+

+

+ (let ((before (list-all-packages)))
+    (make-package 'temp)
+    (set-difference (list-all-packages) before)) =>  (#<PACKAGE "TEMP">)
+
+

+

Side Effects: None. +

+

Affected By:

+

+defpackage, delete-package, make-package

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_l.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_l.htm new file mode 100644 index 00000000..8ce25746 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_list_l.htm @@ -0,0 +1,86 @@ + + + +CLHS: Function LIST-LENGTH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LIST-LENGTH

+

Syntax:

+

+ +list-length list => length

+

+

Arguments and Values:

+

+list---a proper list or a circular list.

+length---a non-negative integer, or nil.

+

Description:

+

+Returns the length of list if list is a proper list. Returns nil if list is a circular list.

+

Examples:

+

+

+ (list-length '(a b c d)) =>  4
+ (list-length '(a (b c) d)) =>  3
+ (list-length '()) =>  0
+ (list-length nil) =>  0
+ (defun circular-list (&rest elements)
+   (let ((cycle (copy-list elements))) 
+     (nconc cycle cycle)))
+ (list-length (circular-list 'a 'b)) =>  NIL
+ (list-length (circular-list 'a)) =>  NIL
+ (list-length (circular-list)) =>  0
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if list is not a proper list or a circular list.

+

See Also:

+

+length

+

Notes:

+

+list-length could be implemented as follows:

+

+ (defun list-length (x)  
+   (do ((n 0 (+ n 2))           ;Counter.
+        (fast x (cddr fast))    ;Fast pointer: leaps by 2.
+        (slow x (cdr slow)))    ;Slow pointer: leaps by 1.
+       (nil)
+     ;; If fast pointer hits the end, return the count.
+     (when (endp fast) (return n))
+     (when (endp (cdr fast)) (return (+ n 1)))
+     ;; If fast pointer eventually equals slow pointer,
+     ;;  then we must be stuck in a circular list.
+     ;; (A deeper property is the converse: if we are
+     ;;  stuck in a circular list, then eventually the
+     ;;  fast pointer will equal the slow pointer.
+     ;;  That fact justifies this implementation.)
+     (when (and (eq fast slow) (> n 0)) (return nil))))
+ 
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listen.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listen.htm new file mode 100644 index 00000000..ac10ba49 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listen.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function LISTEN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LISTEN

+

Syntax:

+

+ +listen &optional input-stream => generalized-boolean

+

+

Arguments and Values:

+

+input-stream---an input stream designator. The default is standard input.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if there is a character immediately available from input-stream; otherwise, returns false. On a non-interactive input-stream, listen returns true except when at end of file[1]. If an end of file is encountered, listen returns false. listen is intended to be used when input-stream obtains characters from an interactive device such as a keyboard.

+

Examples:

+

+

+ (progn (unread-char (read-char)) (list (listen) (read-char)))
+>>  1
+=>  (T #\1)
+ (progn (clear-input) (listen))
+=>  NIL ;Unless you're a very fast typist!
+
+

+

Side Effects: None. +

+

Affected By:

+

+*standard-input*

+

Exceptional Situations: None. +

+

See Also:

+

+interactive-stream-p, read-char-no-hang

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listp.htm new file mode 100644 index 00000000..aae07a40 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_listp.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function LISTP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LISTP

+

Syntax:

+

+ +listp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type list; otherwise, returns false.

+

Examples:

+ +

+ (listp nil) =>  true
+ (listp (cons 1 2)) =>  true
+ (listp (make-array 6)) =>  false
+ (listp t) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+consp

+

Notes:

+

+If object is a cons, listp does not check whether object is a proper list; it returns true for any kind of list.

+

+ (listp object) ==  (typep object 'list) ==  (typep object '(or cons null))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_load.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_load.htm new file mode 100644 index 00000000..ef4e2883 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_load.htm @@ -0,0 +1,106 @@ + + + +CLHS: Function LOAD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOAD

+

Syntax:

+

+ +load filespec &key verbose print if-does-not-exist external-format

=> generalized-boolean

+

+

Arguments and Values:

+

+filespec---a stream, or a pathname designator. The default is taken from *default-pathname-defaults*.

+verbose---a generalized boolean. The default is the value of *load-verbose*.

+print---a generalized boolean. The default is the value of *load-print*.

+if-does-not-exist---a generalized boolean. The default is true.

+ external-format---an external file format designator. The default is :default.

+generalized-boolean---a generalized boolean.

+

Description:

+

+load loads the file named by filespec into the Lisp environment.

+The manner in which a source file is distinguished from a compiled file is implementation-dependent. If the file specification is not complete and both a source file and a compiled file exist which might match, then which of those files load selects is implementation-dependent.

+If filespec is a stream, load determines what kind of stream it is and loads directly from the stream. If filespec is a logical pathname, it is translated into a physical pathname as if by calling translate-logical-pathname.

+ load sequentially executes each form it encounters in the file named by filespec. If the file is a source file and the implementation chooses to perform implicit compilation, load must recognize top level forms as described in Section 3.2.3.1 (Processing of Top Level Forms) and arrange for each top level form to be executed before beginning implicit compilation of the next. (Note, however, that processing of eval-when forms by load is controlled by the :execute situation.)

+ If verbose is true, load prints a message in the form of a comment (i.e., with a leading semicolon) to standard output indicating what file is being loaded and other useful information. If verbose is false, load does not print this information.

+If print is true, load incrementally prints information to standard output showing the progress of the loading process. For a source file, this information might mean printing the values yielded by each form in the file as soon as those values are returned. For a compiled file, what is printed might not reflect precisely the contents of the source file, but some information is generally printed. If print is false, load does not print this information.

+If the file named by filespec is successfully loaded, load returns true.

+

+If the file does not exist, the specific action taken depends on if-does-not-exist: if it is nil, load returns nil; otherwise, load signals an error.

+ The external-format specifies the external file format to be used when opening the file (see the function open), except that when the file named by filespec is a compiled file, the external-format is ignored. compile-file and load cooperate in an implementation-dependent way to assure the preservation of the similarity of characters referred to in the source file at the time the source file was processed by the file compiler under a given external file format, regardless of the value of external-format at the time the compiled file is loaded.

+ load binds *readtable* and *package* to the values they held before loading the file.

+ *load-truename* is bound by load to hold the truename of the pathname of the file being loaded.

+*load-pathname* is bound by load to hold a pathname that represents filespec merged against the defaults. That is, (pathname (merge-pathnames filespec)).

+

Examples:

+

+

+;Establish a data file...
+ (with-open-file (str "data.in" :direction :output :if-exists :error)
+   (print 1 str) (print '(setq a 888) str) t)
+=>  T
+ (load "data.in") =>  true
+ a =>  888
+ (load (setq p (merge-pathnames "data.in")) :verbose t)
+; Loading contents of file /fred/data.in
+; Finished loading /fred/data.in
+=>  true
+ (load p :print t) 
+; Loading contents of file /fred/data.in
+;  1
+;  888
+; Finished loading /fred/data.in
+=>  true
+
+

+ +

+ ;----[Begin file SETUP]----
+ (in-package "MY-STUFF")
+ (defmacro compile-truename () `',*compile-file-truename*)
+ (defvar *my-compile-truename* (compile-truename) "Just for debugging.")
+ (defvar *my-load-pathname* *load-pathname*)
+ (defun load-my-system ()
+   (dolist (module-name '("FOO" "BAR" "BAZ"))
+     (load (merge-pathnames module-name *my-load-pathname*))))
+ ;----[End of file SETUP]----
+
+ 
+ (load "SETUP")
+ (load-my-system)
+
+

+

Affected By:

+

+The implementation, and the host computer's file system.

+

Exceptional Situations:

+

+If :if-does-not-exist is supplied and is true, or is not supplied, load signals an error of type file-error if the file named by filespec does not exist, or if the file system cannot perform the requested operation.

+ An error of type file-error might be signaled if (wild-pathname-p filespec) returns true.

+

See Also:

+

+ error, merge-pathnames, *load-verbose*, *default-pathname-defaults*, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_log.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_log.htm new file mode 100644 index 00000000..0a1c0f22 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_log.htm @@ -0,0 +1,90 @@ + + + +CLHS: Function LOG + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOG

+

Syntax:

+

+ +log number &optional base => logarithm

+

+

Arguments and Values:

+

+number---a non-zero number.

+base---a number.

+logarithm---a number.

+

Description:

+

+log returns the logarithm of number in base base. If base is not supplied its value is e, the base of the natural logarithms.

+log may return a complex when given a real negative number.

+

+ (log -1.0) ==  (complex 0.0 (float pi 0.0))
+
+

+If base is zero, log returns zero.

+The result of (log 8 2) may be either 3 or 3.0, depending on the implementation. An implementation can use floating-point calculations even if an exact integer result is possible.

+The branch cut for the logarithm function of one argument (natural logarithm) lies along the negative real axis, continuous with quadrant II. The domain excludes the origin.

+ The mathematical definition of a complex logarithm is as follows, whether or not minus zero is supported by the implementation:

+

+(log x) ==  (complex (log (abs x)) (phase x))
+
+

+Therefore the range of the one-argument logarithm function is that strip of the complex plane containing numbers with imaginary parts between -<PI> (exclusive) and <PI> (inclusive) if minus zero is not supported, or -<PI> (inclusive) and <PI> (inclusive) if minus zero is supported.

+The two-argument logarithm function is defined as

+

+ (log base number)
+ ==  (/ (log number) (log base))
+
+

+This defines the principal values precisely. The range of the two-argument logarithm function is the entire complex plane.

+

Examples:

+

+

+ (log 100 10)
+=>  2.0
+=>  2
+ (log 100.0 10) =>  2.0
+ (log #c(0 1) #c(0 -1))
+=>  #C(-1.0 0.0)
+OR=>  #C(-1 0)
+ (log 8.0 2) =>  3.0
+
+

+ +

+ (log #c(-16 16) #c(2 2)) =>  3 or approximately #c(3.0 0.0)
+                               or approximately 3.0 (unlikely)
+
+

+

Affected By:

+

+The implementation.

+

Exceptional Situations: None. +

+

See Also:

+

+exp, expt, Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logand.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logand.htm new file mode 100644 index 00000000..eacf38ef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logand.htm @@ -0,0 +1,140 @@ + + + +CLHS: Function LOGAND, LOGANDC1, LOGANDC2... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR

+

Syntax:

+

+ +logand &rest integers => result-integer

+ +logandc1 integer-1 integer-2 => result-integer

+ +logandc2 integer-1 integer-2 => result-integer

+ +logeqv &rest integers => result-integer

+ +logior &rest integers => result-integer

+ +lognand integer-1 integer-2 => result-integer

+ +lognor integer-1 integer-2 => result-integer

+ +lognot integer => result-integer

+ +logorc1 integer-1 integer-2 => result-integer

+ +logorc2 integer-1 integer-2 => result-integer

+ +logxor &rest integers => result-integer

+

+

Arguments and Values:

+

+integers---integers.

+integer---an integer.

+integer-1---an integer.

+integer-2---an integer.

+result-integer---an integer.

+

Description:

+

+The functions logandc1, logandc2, logand, logeqv, logior, lognand, lognor, lognot, logorc1, logorc2, and logxor perform bit-wise logical operations on their arguments, that are treated as if they were binary.

+The next figure lists the meaning of each of the functions. Where an `identity' is shown, it indicates the value yielded by the function when no arguments are supplied.

+

+Function  Identity  Operation performed                         
+logandc1  ---       and complement of integer-1 with integer-2  
+logandc2  ---       and integer-1 with complement of integer-2  
+logand    -1        and                                         
+logeqv    -1        equivalence (exclusive nor)                 
+logior    0         inclusive or                                
+lognand   ---       complement of integer-1 and integer-2       
+lognor    ---       complement of integer-1 or integer-2        
+lognot    ---       complement                                  
+logorc1   ---       or complement of integer-1 with integer-2   
+logorc2   ---       or integer-1 with complement of integer-2   
+logxor    0         exclusive or                                
+
+

Figure 12-18. Bit-wise Logical Operations on Integers

+Negative integers are treated as if they were in two's-complement notation.

+

Examples:

+

+

+ (logior 1 2 4 8) =>  15
+ (logxor 1 3 7 15) =>  10
+ (logeqv) =>  -1
+ (logand 16 31) =>  16
+ (lognot 0) =>  -1
+ (lognot 1) =>  -2
+ (lognot -1) =>  0
+ (lognot (1+ (lognot 1000))) =>  999
+
+;;; In the following example, m is a mask.  For each bit in
+;;; the mask that is a 1, the corresponding bits in x and y are
+;;; exchanged.  For each bit in the mask that is a 0, the 
+;;; corresponding bits of x and y are left unchanged.
+ (flet ((show (m x y)
+          (format t "~%m = #o~6,'0O~%x = #o~6,'0O~%y = #o~6,'0O~%"
+                  m x y)))
+   (let ((m #o007750)
+         (x #o452576)
+         (y #o317407))
+     (show m x y)
+     (let ((z (logand (logxor x y) m)))
+       (setq x (logxor z x))
+       (setq y (logxor z y))
+       (show m x y))))
+>>  m = #o007750
+>>  x = #o452576
+>>  y = #o317407
+>>  
+>>  m = #o007750
+>>  x = #o457426
+>>  y = #o312557
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if any argument is not an integer.

+

See Also:

+

+boole

+

Notes:

+

+(logbitp k -1) returns true for all values of k.

+Because the following functions are not associative, they take exactly two arguments rather than any number of arguments.

+

+ (lognand n1 n2) ==  (lognot (logand n1 n2))
+ (lognor n1 n2) ==  (lognot (logior n1 n2))
+ (logandc1 n1 n2) ==  (logand (lognot n1) n2)
+ (logandc2 n1 n2) ==  (logand n1 (lognot n2))
+ (logiorc1 n1 n2) ==  (logior (lognot n1) n2)
+ (logiorc2 n1 n2) ==  (logior n1 (lognot n2))
+ (logbitp j (lognot x)) ==  (not (logbitp j x))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logbtp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logbtp.htm new file mode 100644 index 00000000..11ff53b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logbtp.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function LOGBITP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOGBITP

+

Syntax:

+

+ +logbitp index integer => generalized-boolean

+

+

Arguments and Values:

+

+ index---a non-negative integer.

+integer---an integer.

+generalized-boolean---a generalized boolean.

+

Description:

+

+logbitp is used to test the value of a particular bit in integer, that is treated as if it were binary. The value of logbitp is true if the bit in integer whose index is index (that is, its weight is 2^index) is a one-bit; otherwise it is false.

+Negative integers are treated as if they were in two's-complement notation.

+

Examples:

+ +

+ (logbitp 1 1) =>  false
+ (logbitp 0 1) =>  true
+ (logbitp 3 10) =>  true
+ (logbitp 1000000 -1) =>  true
+ (logbitp 2 6) =>  true
+ (logbitp 0 6) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if index is not a non-negative integer. Should signal an error of type type-error if integer is not an integer.

+

See Also: None. +

+

Notes:

+

+

+ (logbitp k n) ==  (ldb-test (byte 1 k) n)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logcou.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logcou.htm new file mode 100644 index 00000000..a8b0bec0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logcou.htm @@ -0,0 +1,73 @@ + + + +CLHS: Function LOGCOUNT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOGCOUNT

+

Syntax:

+

+ +logcount integer => number-of-on-bits

+

+

Arguments and Values:

+

+integer---an integer.

+number-of-on-bits---a non-negative integer.

+

Description:

+

+Computes and returns the number of bits in the two's-complement binary representation of integer that are `on' or `set'. If integer is negative, the 0 bits are counted; otherwise, the 1 bits are counted.

+

Examples:

+

+

+ (logcount 0) =>  0
+ (logcount -1) =>  0
+ (logcount 7) =>  3
+ (logcount  13) =>  3 ;Two's-complement binary: ...0001101
+ (logcount -13) =>  2 ;Two's-complement binary: ...1110011
+ (logcount  30) =>  4 ;Two's-complement binary: ...0011110
+ (logcount -30) =>  4 ;Two's-complement binary: ...1100010
+ (logcount (expt 2 100)) =>  1
+ (logcount (- (expt 2 100))) =>  100
+ (logcount (- (1+ (expt 2 100)))) =>  1
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its argument is not an integer.

+

See Also: None. +

+

Notes:

+

+Even if the implementation does not represent integers internally in two's complement binary, logcount behaves as if it did.

+The following identity always holds:

+

+    (logcount x)
+ ==  (logcount (- (+ x 1)))
+ ==  (logcount (lognot x))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logi_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logi_1.htm new file mode 100644 index 00000000..177cb0ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logi_1.htm @@ -0,0 +1,54 @@ + + + +CLHS: Function LOGICAL-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOGICAL-PATHNAME

+

+

Syntax:

+

+ +logical-pathname pathspec => logical-pathname

+

+

Arguments and Values:

+

+pathspec---a logical pathname, a logical pathname namestring, or a stream.

+logical-pathname---a logical pathname.

+

Description:

+

+logical-pathname converts pathspec to a logical pathname and returns the new logical pathname. If pathspec is a logical pathname namestring, it should contain a host component and its following colon. If pathspec is a stream, it should be one for which pathname returns a logical pathname.

+ If pathspec is a stream, the stream can be either open or closed. logical-pathname returns the same logical pathname after a file is closed as it did when the file was open. It is an error if pathspec is a stream that is created with make-two-way-stream, make-echo-stream, make-broadcast-stream, make-concatenated-stream, make-string-input-stream, or make-string-output-stream.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Signals an error of type type-error if pathspec isn't supplied correctly.

+

See Also:

+

+logical-pathname, translate-logical-pathname, Section 19.3 (Logical Pathnames)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logica.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logica.htm new file mode 100644 index 00000000..9a7cdfa1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logica.htm @@ -0,0 +1,171 @@ + + + +CLHS: Accessor LOGICAL-PATHNAME-TRANSLATIONS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor LOGICAL-PATHNAME-TRANSLATIONS

+

+

Syntax:

+

+ +logical-pathname-translations host => translations

+ +(setf (logical-pathname-translations host) new-translations)

+

+

Arguments and Values:

+

+host--a logical host designator.

+translations, new-translations---a list.

+

Description:

+

+Returns the host's list of translations. Each translation is a list of at least two elements: from-wildcard and to-wildcard. Any additional elements are implementation-defined. From-wildcard is a logical pathname whose host is host. To-wildcard is a pathname.

+(setf (logical-pathname-translations host) translations) sets a logical pathname host's list of translations. If host is a string that has not been previously used as a logical pathname host, a new logical pathname host is defined; otherwise an existing host's translations are replaced. logical pathname host names are compared with string-equal.

+ When setting the translations list, each from-wildcard can be a logical pathname whose host is host or a logical pathname namestring parseable by (parse-namestring string host), where host represents the appropriate object as defined by parse-namestring. Each to-wildcard can be anything coercible to a pathname by (pathname to-wildcard). If to-wildcard coerces to a logical pathname, translate-logical-pathname will perform repeated translation steps when it uses it.

+host is either the host component of a logical pathname or a string that has been defined as a logical pathname host name by setf of logical-pathname-translations.

+

Examples:

+

+

+

+ ;;;A very simple example of setting up a logical pathname host.  No
+ ;;;translations are necessary to get around file system restrictions, so
+ ;;;all that is necessary is to specify the root of the physical directory
+ ;;;tree that contains the logical file system.
+ ;;;The namestring syntax on the right-hand side is implementation-dependent.
+ (setf (logical-pathname-translations "foo")
+       '(("**;*.*.*"              "MY-LISPM:>library>foo>**>")))
+ 
+ ;;;Sample use of that logical pathname.  The return value
+ ;;;is implementation-dependent.          
+ (translate-logical-pathname "foo:bar;baz;mum.quux.3")
+=>  #P"MY-LISPM:>library>foo>bar>baz>mum.quux.3"
+ 
+ ;;;A more complex example, dividing the files among two file servers
+ ;;;and several different directories.  This Unix doesn't support
+ ;;;:WILD-INFERIORS in the directory, so each directory level must
+ ;;;be translated individually.  No file name or type translations
+ ;;;are required except for .MAIL to .MBX.
+ ;;;The namestring syntax on the right-hand side is implementation-dependent.
+ (setf (logical-pathname-translations "prog")
+       '(("RELEASED;*.*.*"        "MY-UNIX:/sys/bin/my-prog/")
+         ("RELEASED;*;*.*.*"      "MY-UNIX:/sys/bin/my-prog/*/")
+         ("EXPERIMENTAL;*.*.*"    "MY-UNIX:/usr/Joe/development/prog/")
+         ("EXPERIMENTAL;DOCUMENTATION;*.*.*"
+                                  "MY-VAX:SYS$DISK:[JOE.DOC]")
+         ("EXPERIMENTAL;*;*.*.*"  "MY-UNIX:/usr/Joe/development/prog/*/")
+         ("MAIL;**;*.MAIL"        "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))
+
+ ;;;Sample use of that logical pathname.  The return value
+ ;;;is implementation-dependent.          
+ (translate-logical-pathname "prog:mail;save;ideas.mail.3")
+=>  #P"MY-VAX:SYS$DISK:[JOE.MAIL.PROG.SAVE]IDEAS.MBX.3"
+
+ ;;;Example translations for a program that uses three files main.lisp,
+ ;;;auxiliary.lisp, and documentation.lisp.  These translations might be
+ ;;;supplied by a software supplier as examples.
+
+ ;;;For Unix with long file names
+ (setf (logical-pathname-translations "prog")
+       '(("CODE;*.*.*"             "/lib/prog/")))
+
+ ;;;Sample use of that logical pathname.  The return value
+ ;;;is implementation-dependent.          
+ (translate-logical-pathname "prog:code;documentation.lisp")
+=>  #P"/lib/prog/documentation.lisp"
+
+ ;;;For Unix with 14-character file names, using .lisp as the type
+ (setf (logical-pathname-translations "prog")
+       '(("CODE;DOCUMENTATION.*.*" "/lib/prog/docum.*")
+         ("CODE;*.*.*"             "/lib/prog/")))
+
+ ;;;Sample use of that logical pathname.  The return value
+ ;;;is implementation-dependent.          
+ (translate-logical-pathname "prog:code;documentation.lisp")
+=>  #P"/lib/prog/docum.lisp"
+
+ ;;;For Unix with 14-character file names, using .l as the type
+ ;;;The second translation shortens the compiled file type to .b
+ (setf (logical-pathname-translations "prog")
+       `(("**;*.LISP.*"            ,(logical-pathname "PROG:**;*.L.*"))
+         (,(compile-file-pathname (logical-pathname "PROG:**;*.LISP.*"))
+                                   ,(logical-pathname "PROG:**;*.B.*"))
+         ("CODE;DOCUMENTATION.*.*" "/lib/prog/documentatio.*")
+         ("CODE;*.*.*"             "/lib/prog/")))
+
+ ;;;Sample use of that logical pathname.  The return value
+ ;;;is implementation-dependent.          
+ (translate-logical-pathname "prog:code;documentation.lisp")
+=>  #P"/lib/prog/documentatio.l"
+
+ ;;;For a Cray with 6 character names and no directories, types, or versions.
+ (setf (logical-pathname-translations "prog")
+       (let ((l '(("MAIN" "PGMN")
+                  ("AUXILIARY" "PGAUX")
+                  ("DOCUMENTATION" "PGDOC")))
+             (logpath (logical-pathname "prog:code;"))
+             (phypath (pathname "XXX")))
+         (append
+           ;; Translations for source files
+           (mapcar #'(lambda (x)
+                       (let ((log (first x))
+                             (phy (second x)))
+                         (list (make-pathname :name log
+                                              :type "LISP"
+                                              :version :wild
+                                              :defaults logpath)
+                               (make-pathname :name phy
+                                              :defaults phypath))))
+                   l)
+           ;; Translations for compiled files
+           (mapcar #'(lambda (x)
+                       (let* ((log (first x))
+                              (phy (second x))
+                              (com (compile-file-pathname
+                                     (make-pathname :name log
+                                                    :type "LISP"
+                                                    :version :wild
+                                                    :defaults logpath))))
+                         (setq phy (concatenate 'string phy "B"))
+                         (list com
+                               (make-pathname :name phy
+                                              :defaults phypath))))
+                   l))))
+
+ ;;;Sample use of that logical pathname.  The return value
+ ;;;is implementation-dependent.          
+ (translate-logical-pathname "prog:code;documentation.lisp")
+=>  #P"PGDOC"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If host is incorrectly supplied, an error of type type-error is signaled.

+

See Also:

+

+logical-pathname, Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+Implementations can define additional functions that operate on logical pathname hosts, for example to specify additional translation rules or options.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logtes.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logtes.htm new file mode 100644 index 00000000..687a02d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_logtes.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function LOGTEST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function LOGTEST

+

Syntax:

+

+ +logtest integer-1 integer-2 => generalized-boolean

+

+

Arguments and Values:

+

+integer-1---an integer.

+integer-2---an integer.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if any of the bits designated by the 1's in integer-1 is 1 in integer-2; otherwise it is false. integer-1 and integer-2 are treated as if they were binary.

+Negative integer-1 and integer-2 are treated as if they were represented in two's-complement binary.

+

Examples:

+

+

+ (logtest 1 7) =>  true
+ (logtest 1 2) =>  false
+ (logtest -2 -1) =>  true
+ (logtest 0 -1) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if integer-1 is not an integer. Should signal an error of type type-error if integer-2 is not an integer.

+

See Also: None. +

+

Notes:

+

+

+ (logtest x y) ==  (not (zerop (logand x y)))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_i.htm new file mode 100644 index 00000000..1a1f5618 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_i.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function MACHINE-INSTANCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MACHINE-INSTANCE

+

Syntax:

+

+ +machine-instance <no arguments> => description

+

+

Arguments and Values:

+

+description---a string or nil.

+

Description:

+

+Returns a string that identifies the particular instance of the computer hardware on which Common Lisp is running, or nil if no such string can be computed.

+

Examples:

+

+

+ (machine-instance)
+=>  "ACME.COM"
+OR=>  "S/N 123231"
+OR=>  "18.26.0.179"
+OR=>  "AA-00-04-00-A7-A4"
+
+

+

Side Effects: None. +

+

Affected By:

+

+The machine instance, and the implementation.

+

Exceptional Situations: None. +

+

See Also:

+

+machine-type, machine-version

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_t.htm new file mode 100644 index 00000000..68964ccc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_t.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function MACHINE-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MACHINE-TYPE

+

Syntax:

+

+ +machine-type <no arguments> => description

+

+

Arguments and Values:

+

+description---a string or nil.

+

Description:

+

+Returns a string that identifies the generic name of the computer hardware on which Common Lisp is running.

+

Examples:

+

+

+ (machine-type)
+=>  "DEC PDP-10"
+OR=>  "Symbolics LM-2"
+
+

+

Side Effects: None. +

+

Affected By:

+

+The machine type. The implementation.

+

Exceptional Situations: None. +

+

See Also:

+

+machine-version

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_v.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_v.htm new file mode 100644 index 00000000..dad0fff0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mach_v.htm @@ -0,0 +1,56 @@ + + + +CLHS: Function MACHINE-VERSION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MACHINE-VERSION

+

Syntax:

+

+ +machine-version <no arguments> => description

+

+

Arguments and Values:

+

+description---a string or nil.

+

Description:

+

+Returns a string that identifies the version of the computer hardware on which Common Lisp is running, or nil if no such value can be computed.

+

Examples:

+

+

+ (machine-version) =>  "KL-10, microcode 9"
+
+

+

Side Effects: None. +

+

Affected By:

+

+The machine version, and the implementation.

+

Exceptional Situations: None. +

+

See Also:

+

+machine-type, machine-instance

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_macro_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_macro_.htm new file mode 100644 index 00000000..14eb0111 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_macro_.htm @@ -0,0 +1,81 @@ + + + +CLHS: Accessor MACRO-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor MACRO-FUNCTION

+

Syntax:

+

+ +macro-function symbol &optional environment => function

+ +(setf (macro-function symbol &optional environment) new-function)

+

+

Arguments and Values:

+

+symbol---a symbol.

+ environment---an environment object.

+function---a macro function or nil.

+new-function---a macro function.

+

Description:

+

+Determines whether symbol has a function definition as a macro in the specified environment.

+If so, the macro expansion function, a function of two arguments, is returned. If symbol has no function definition in the lexical environment environment, or its definition is not a macro, macro-function returns nil.

+

+

+It is possible for both macro-function and special-operator-p to return true of symbol. The macro definition must be available for use by programs that understand only the standard Common Lisp special forms.

+

Examples:

+ +

+ (defmacro macfun (x) '(macro-function 'macfun)) =>  MACFUN 
+ (not (macro-function 'macfun)) =>  false 
+
+ +
+ (macrolet ((foo (&environment env)
+               (if (macro-function 'bar env)
+                  ''yes
+                  ''no)))
+    (list (foo)
+          (macrolet ((bar () :beep))
+             (foo))))
+ 
+=>  (NO YES)
+
+

+

Affected By:

+ (setf macro-function), defmacro, and macrolet.

+

Exceptional Situations:

+

+ The consequences are undefined if environment is non-nil in a use of setf of macro-function.

+

See Also:

+

+defmacro, Section 3.1 (Evaluation)

+

Notes:

+

+setf can be used with macro-function to install a macro as a symbol's global function definition:

+

+ (setf (macro-function symbol) fn)
+
+ The value installed must be a function that accepts two arguments, the entire macro call and an environment, and computes the expansion for that call. Performing this operation causes symbol to have only that macro definition as its global function definition; any previous definition, whether as a macro or as a function, is lost.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_makunb.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_makunb.htm new file mode 100644 index 00000000..2b644372 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_makunb.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function MAKUNBOUND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKUNBOUND

+

Syntax:

+

+ +makunbound symbol => symbol

+

+

Arguments and Values:

+

+symbol---a symbol

+

Description:

+

+Makes the symbol be unbound, regardless of whether it was previously bound.

+

Examples:

+

+

+ (setf (symbol-value 'a) 1)
+ (boundp 'a) =>  true
+ a =>  1
+ (makunbound 'a) =>  A
+ (boundp 'a) =>  false
+
+

+

Side Effects:

+

+The value cell of symbol is modified.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+boundp, fmakunbound

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map.htm new file mode 100644 index 00000000..b9480d4d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map.htm @@ -0,0 +1,77 @@ + + + +CLHS: Function MAP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAP

+

Syntax:

+

+ +map result-type function &rest sequences+ => result

+

+

Arguments and Values:

+

+ result-type -- a sequence type specifier, or nil.

+ function---a function designator. function must take as many arguments as there are sequences.

+sequence---a proper sequence.

+result---if result-type is a type specifier other than nil, then a sequence of the type it denotes; otherwise (if the result-type is nil), nil.

+

Description:

+

+Applies function to successive sets of arguments in which one argument is obtained from each sequence. The function is called first on all the elements with index 0, then on all those with index 1, and so on. The result-type specifies the type of the resulting sequence.

+map returns nil if result-type is nil. Otherwise, map returns a sequence such that element j is the result of applying function to element j of each of the sequences. The result sequence is as long as the shortest of the sequences. The consequences are undefined if the result of applying function to the successive elements of the sequences cannot be contained in a sequence of the type given by result-type.

+ If the result-type is a subtype of list, the result will be a list.

+If the result-type is a subtype of vector, then if the implementation can determine the element type specified for the result-type, the element type of the resulting array is the result of upgrading that element type; or, if the implementation can determine that the element type is unspecified (or *), the element type of the resulting array is t; otherwise, an error is signaled.

+

Examples:

+

+

+ (map 'string #'(lambda (x y)
+                  (char "01234567890ABCDEF" (mod (+ x y) 16)))
+       '(1 2 3 4)
+       '(10 9 8 7)) =>  "AAAA"
+ (setq seq '("lower" "UPPER" "" "123")) =>  ("lower" "UPPER" "" "123")
+ (map nil #'nstring-upcase seq) =>  NIL
+ seq =>  ("LOWER" "UPPER" "" "123")
+ (map 'list #'- '(1 2 3 4)) =>  (-1 -2 -3 -4)
+ (map 'string
+      #'(lambda (x) (if (oddp x) #\1 #\0))
+      '(1 2 3 4)) =>  "1010"
+
+

+ +

+ (map '(vector * 4) #'cons "abc" "de") should signal an error
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+ An error of type type-error must be signaled if the result-type is not a recognizable subtype of list, not a recognizable subtype of vector, and not nil.

+Should be prepared to signal an error of type type-error if any sequence is not a proper sequence.

+ An error of type type-error should be signaled if result-type specifies the number of elements and the minimum length of the sequences is different from that number.

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map_in.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map_in.htm new file mode 100644 index 00000000..71fb452b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_map_in.htm @@ -0,0 +1,79 @@ + + + +CLHS: Function MAP-INTO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAP-INTO

+

+

Syntax:

+

+ +map-into result-sequence function &rest sequences => result-sequence

+

+

Arguments and Values:

+

+result-sequence---a proper sequence.

+function---a designator for a function of as many arguments as there are sequences.

+sequence---a proper sequence.

+

Description:

+

+Destructively modifies result-sequence to contain the results of applying function to each element in the argument sequences in turn.

+result-sequence and each element of sequences can each be either a list or a vector. If result-sequence and each element of sequences are not all the same length, the iteration terminates when the shortest sequence (of any of the sequences or the result-sequence) is exhausted. If result-sequence is a vector with a fill pointer, the fill pointer is ignored when deciding how many iterations to perform, and afterwards the fill pointer is set to the number of times function was applied. If result-sequence is longer than the shortest element of sequences, extra elements at the end of result-sequence are left unchanged. If result-sequence is nil, map-into immediately returns nil, since nil is a sequence of length zero.

+If function has side effects, it can count on being called first on all of the elements with index 0, then on all of those numbered 1, and so on.

+

Examples:

+

+

+ (setq a (list 1 2 3 4) b (list 10 10 10 10)) =>  (10 10 10 10)
+ (map-into a #'+ a b) =>  (11 12 13 14)
+ a =>  (11 12 13 14)
+ b =>  (10 10 10 10)
+ (setq k '(one two three)) =>  (ONE TWO THREE)
+ (map-into a #'cons k a) =>  ((ONE . 11) (TWO . 12) (THREE . 13) 14)
+ (map-into a #'gensym) =>  (#:G9090 #:G9091 #:G9092 #:G9093)
+ a =>  (#:G9090 #:G9091 #:G9092 #:G9093)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if result-sequence is not a proper sequence. Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also: None. +

+

Notes:

+

+map-into differs from map in that it modifies an existing sequence rather than creating a new one. In addition, map-into can be called with only two arguments, while map requires at least three arguments.

+map-into could be defined by:

+

+ (defun map-into (result-sequence function &rest sequences)
+   (loop for index below (apply #'min 
+                                (length result-sequence)
+                                (mapcar #'length sequences))
+         do (setf (elt result-sequence index)
+                  (apply function
+                         (mapcar #'(lambda (seq) (elt seq index))
+                                 sequences))))
+   result-sequence)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mapc_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mapc_.htm new file mode 100644 index 00000000..43efb71e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mapc_.htm @@ -0,0 +1,112 @@ + + + +CLHS: Function MAPC, MAPCAR, MAPCAN, MAPL... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON

+

Syntax:

+

+ +mapc function &rest lists+ => list-1

+ +mapcar function &rest lists+ => result-list

+ +mapcan function &rest lists+ => concatenated-results

+ +mapl function &rest lists+ => list-1

+ +maplist function &rest lists+ => result-list

+ +mapcon function &rest lists+ => concatenated-results

+

+

Arguments and Values:

+

+function---a designator for a function that must take as many arguments as there are lists.

+ list---a proper list.

+list-1---the first list (which must be a proper list).

+result-list---a list.

+concatenated-results---a list.

+

Description:

+

+The mapping operation involves applying function to successive sets of arguments in which one argument is obtained from each sequence. Except for mapc and mapl, the result contains the results returned by function. In the cases of mapc and mapl, the resulting sequence is list.

+function is called first on all the elements with index 0, then on all those with index 1, and so on. result-type specifies the type of the resulting sequence. If function is a symbol, it is coerced to a function as if by symbol-function.

+mapcar operates on successive elements of the lists. function is applied to the first element of each list, then to the second element of each list, and so on. The iteration terminates when the shortest list runs out, and excess elements in other lists are ignored. The value returned by mapcar is a list of the results of successive calls to function.

+mapc is like mapcar except that the results of applying function are not accumulated. The list argument is returned.

+maplist is like mapcar except that function is applied to successive sublists of the lists. function is first applied to the lists themselves, and then to the cdr of each list, and then to the cdr of the cdr of each list, and so on.

+mapl is like maplist except that the results of applying function are not accumulated; list-1 is returned.

+mapcan and mapcon are like mapcar and maplist respectively, except that the results of applying function are combined into a list by the use of nconc rather than list. That is,

+

+ (mapcon f x1 ... xn)
+   ==  (apply #'nconc (maplist f x1 ... xn))
+
+ and similarly for the relationship between mapcan and mapcar.

+

Examples:

+

+

+ (mapcar #'car '((1 a) (2 b) (3 c))) =>  (1 2 3) 
+ (mapcar #'abs '(3 -4 2 -5 -6)) =>  (3 4 2 5 6)
+ (mapcar #'cons '(a b c) '(1 2 3)) =>  ((A . 1) (B . 2) (C . 3))
+
+ (maplist #'append '(1 2 3 4) '(1 2) '(1 2 3)) 
+=>  ((1 2 3 4 1 2 1 2 3) (2 3 4 2 2 3)) 
+ (maplist #'(lambda (x) (cons 'foo x)) '(a b c d))
+=>  ((FOO A B C D) (FOO B C D) (FOO C D) (FOO D))
+ (maplist #'(lambda (x) (if (member (car x) (cdr x)) 0 1)) '(a b a c d b c))
+=>  (0 0 1 0 1 1 1)
+;An entry is 1 if the corresponding element of the input
+;  list was the last instance of that element in the input list.
+
+ (setq dummy nil) =>  NIL 
+ (mapc #'(lambda (&rest x) (setq dummy (append dummy x)))
+        '(1 2 3 4)
+        '(a b c d e)
+        '(x y z)) =>  (1 2 3 4) 
+ dummy =>  (1 A X 2 B Y 3 C Z)                   
+
+ (setq dummy nil) =>  NIL 
+ (mapl #'(lambda (x) (push x dummy)) '(1 2 3 4)) =>  (1 2 3 4) 
+ dummy =>  ((4) (3 4) (2 3 4) (1 2 3 4)) 
+
+ (mapcan #'(lambda (x y) (if (null x) nil (list x y)))
+          '(nil nil nil d e)
+          '(1 2 3 4 5 6)) =>  (D 4 E 5) 
+ (mapcan #'(lambda (x) (and (numberp x) (list x)))
+          '(a 1 b c 3 4 d 5))
+=>  (1 3 4 5)
+
+ In this case the function serves as a filter; this is a standard Lisp idiom using mapcan.

+

+ (mapcon #'list '(1 2 3 4)) =>  ((1 2 3 4) (2 3 4) (3 4) (4)) 
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if any list is not a proper list.

+

See Also:

+

+dolist, map, Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_maphas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_maphas.htm new file mode 100644 index 00000000..7181f6db --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_maphas.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function MAPHASH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAPHASH

+

Syntax:

+

+ +maphash function hash-table => nil

+

+

Arguments and Values:

+

+function---a designator for a function of two arguments, the key and the value.

+hash-table---a hash table.

+

Description:

+

+Iterates over all entries in the hash-table. For each entry, the function is called with two arguments--the key and the value of that entry.

+The consequences are unspecified if any attempt is made to add or remove an entry from the hash-table while a maphash is in progress, with two exceptions: the function can use can use setf of gethash to change the value part of the entry currently being processed, or it can use remhash to remove that entry.

+

Examples:

+

+

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32304110>
+ (dotimes (i 10) (setf (gethash i table) i)) =>  NIL
+ (let ((sum-of-squares 0))
+    (maphash #'(lambda (key val) 
+                 (let ((square (* val val)))
+                   (incf sum-of-squares square)
+                   (setf (gethash key table) square)))
+             table)
+    sum-of-squares) =>  285
+ (hash-table-count table) =>  10
+ (maphash #'(lambda (key val)
+               (when (oddp val) (remhash key table)))
+           table) =>  NIL
+ (hash-table-count table) =>  5
+ (maphash #'(lambda (k v) (print (list k v))) table)
+(0 0) 
+(8 64) 
+(2 4) 
+(6 36) 
+(4 16) 
+=>  NIL
+
+

+

Side Effects:

+

+None, other than any which might be done by the function.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+loop, with-hash-table-iterator, Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mask_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mask_f.htm new file mode 100644 index 00000000..502ce386 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mask_f.htm @@ -0,0 +1,72 @@ + + + +CLHS: Accessor MASK-FIELD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor MASK-FIELD

+

Syntax:

+

+ +mask-field bytespec integer => masked-integer

+ +(setf (mask-field bytespec place) new-masked-integer)

+

+

Arguments and Values:

+

+bytespec---a byte specifier.

+integer---an integer.

+masked-integer, new-masked-integer---a non-negative integer.

+

Description:

+

+mask-field performs a ``mask'' operation on integer. It returns an integer that has the same bits as integer in the byte specified by bytespec, but that has zero-bits everywhere else.

+setf may be used with mask-field to modify a byte within the integer that is stored in a given place. The effect is to perform a deposit-field operation and then store the result back into the place.

+

Examples:

+

+

+ (mask-field (byte 1 5) -1) =>  32
+ (setq a 15) =>  15
+ (mask-field (byte 2 0) a) =>  3
+ a =>  15
+ (setf (mask-field (byte 2 0) a) 1) =>  1
+ a =>  13
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+byte, ldb

+

Notes:

+

+

+ (ldb bs (mask-field bs n)) ==  (ldb bs n)
+ (logbitp j (mask-field (byte s p) n))
+   ==  (and (>= j p) (< j s) (logbitp j n))
+ (mask-field bs n) ==  (logand n (dpb -1 bs 0))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_max_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_max_m.htm new file mode 100644 index 00000000..e64f33e8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_max_m.htm @@ -0,0 +1,89 @@ + + + +CLHS: Function MAX, MIN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAX, MIN

+

Syntax:

+

+ +max &rest reals+ => max-real

+ +min &rest reals+ => min-real

+

+

Arguments and Values:

+

+real---a real.

+max-real, min-real---a real.

+

Description:

+

+max returns the real that is greatest (closest to positive infinity). min returns the real that is least (closest to negative infinity).

+For max, the implementation has the choice of returning the largest argument as is or applying the rules of floating-point contagion, taking all the arguments into consideration for contagion purposes. Also, if one or more of the arguments are =, then any one of them may be chosen as the value to return. For example, if the reals are a mixture of rationals and floats, and the largest argument is a rational, then the implementation is free to produce either that rational or its float approximation; if the largest argument is a float of a smaller format than the largest format of any float argument, then the implementation is free to return the argument in its given format or expanded to the larger format. Similar remarks apply to min (replacing ``largest argument'' by ``smallest argument'').

+

Examples:

+

+

+ (max 3) =>  3 
+ (min 3) =>  3
+ (max 6 12) =>  12 
+ (min 6 12) =>  6
+ (max -6 -12) =>  -6 
+ (min -6 -12) =>  -12
+ (max 1 3 2 -7) =>  3 
+ (min 1 3 2 -7) =>  -7
+ (max -2 3 0 7) =>  7 
+ (min -2 3 0 7) =>  -2
+ (max 5.0 2) =>  5.0 
+ (min 5.0 2)
+=>  2
+OR=>  2.0
+ (max 3.0 7 1)
+=>  7
+OR=>  7.0 
+ (min 3.0 7 1)
+=>  1
+OR=>  1.0
+ (max 1.0s0 7.0d0) =>  7.0d0
+ (min 1.0s0 7.0d0)
+=>  1.0s0
+OR=>  1.0d0
+ (max 3 1 1.0s0 1.0d0)
+=>  3
+OR=>  3.0d0
+ (min 3 1 1.0s0 1.0d0)
+=>  1
+OR=>  1.0s0 
+OR=>  1.0d0
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if any number is not a real.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mem_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mem_m.htm new file mode 100644 index 00000000..9198dfb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mem_m.htm @@ -0,0 +1,86 @@ + + + +CLHS: Function MEMBER, MEMBER-IF, MEMBER-IF-NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MEMBER, MEMBER-IF, MEMBER-IF-NOT

+

Syntax:

+

+ +member item list &key key test test-not => tail

+ +member-if predicate list &key key => tail

+ +member-if-not predicate list &key key => tail

+

+

Arguments and Values:

+

+item---an object.

+list---a proper list.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+tail---a list.

+

Description:

+

+member, member-if, and member-if-not each search list for item or for a top-level element that satisfies the test. The argument to the predicate function is an element of list.

+If some element satisfies the test, the tail of list beginning with this element is returned; otherwise nil is returned.

+list is searched on the top level only.

+

Examples:

+

+

+ (member 2 '(1 2 3)) =>  (2 3)                                 
+ (member 2 '((1 . 2) (3 . 4)) :test-not #'= :key #'cdr) =>  ((3 . 4))
+ (member 'e '(a b c d)) =>  NIL
+
+

+

+ (member-if #'listp '(a b nil c d)) =>  (NIL C D)
+ (member-if #'numberp '(a #\Space 5/3 foo)) =>  (5/3 FOO)
+ (member-if-not #'zerop 
+                 '(3 6 9 11 . 12)
+                 :key #'(lambda (x) (mod x 3))) =>  (11 . 12)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list is not a proper list.

+

See Also:

+

+find, position, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+ The function member-if-not is deprecated.

+In the following

+

+ (member 'a '(g (a y) c a d e a f)) =>  (A D E A F)
+
+

+the value returned by member is identical to the portion of the list beginning with a. Thus rplaca on the result of member can be used to alter the part of the list where a was found (assuming a check has been made that member did not return nil).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge.htm new file mode 100644 index 00000000..5a90323b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge.htm @@ -0,0 +1,81 @@ + + + +CLHS: Function MERGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MERGE

+

Syntax:

+

+ +merge result-type sequence-1 sequence-2 predicate &key key => result-sequence

+

+

Arguments and Values:

+

+ result-type---a sequence type specifier.

+sequence-1---a sequence.

+sequence-2---a sequence.

+predicate---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+result-sequence---a proper sequence of type result-type.

+

Description:

+

+Destructively merges sequence-1 with sequence-2 according to an order determined by the predicate. merge determines the relationship between two elements by giving keys extracted from the sequence elements to the predicate.

+The first argument to the predicate function is an element of sequence-1 as returned by the key (if supplied); the second argument is an element of sequence-2 as returned by the key (if supplied). Predicate should return true if and only if its first argument is strictly less than the second (in some appropriate sense). If the first argument is greater than or equal to the second (in the appropriate sense), then predicate should return false. merge considers two elements x and y to be equal if (funcall predicate x y) and (funcall predicate y x) both yield false.

+The argument to the key is the sequence element. Typically, the return value of the key becomes the argument to predicate. If key is not supplied or nil, the sequence element itself is used. The key may be executed more than once for each sequence element, and its side effects may occur in any order.

+If key and predicate return, then the merging operation will terminate. The result of merging two sequences x and y is a new sequence of type result-type z, such that the length of z is the sum of the lengths of x and y, and z contains all the elements of x and y. If x1 and x2 are two elements of x, and x1 precedes x2 in x, then x1 precedes x2 in z, and similarly for elements of y. In short, z is an interleaving of x and y.

+If x and y were correctly sorted according to the predicate, then z will also be correctly sorted. If x or y is not so sorted, then z will not be sorted, but will nevertheless be an interleaving of x and y.

+The merging operation is guaranteed stable; if two or more elements are considered equal by the predicate, then the elements from sequence-1 will precede those from sequence-2 in the result.

+sequence-1 and/or sequence-2 may be destroyed.

+ If the result-type is a subtype of list, the result will be a list.

+If the result-type is a subtype of vector, then if the implementation can determine the element type specified for the result-type, the element type of the resulting array is the result of upgrading that element type; or, if the implementation can determine that the element type is unspecified (or *), the element type of the resulting array is t; otherwise, an error is signaled.

+

Examples:

+ +

+ (setq test1 (list 1 3 4 6 7))
+ (setq test2 (list 2 5 8))
+ (merge 'list test1 test2 #'<) =>  (1 2 3 4 5 6 7 8)
+ (setq test1 (copy-seq "BOY"))
+ (setq test2 (copy-seq :nosy"))
+ (merge 'string test1 test2 #'char-lessp) =>  "BnOosYy"
+ (setq test1 (vector ((red . 1) (blue . 4))))
+ (setq test2 (vector ((yellow . 2) (green . 7))))
+ (merge 'vector test1 test2 #'< :key #'cdr) 
+=>  #((RED . 1) (YELLOW . 2) (BLUE . 4) (GREEN . 7)) 
+
+ +
+ (merge '(vector * 4) '(1 5) '(2 4 6) #'<) should signal an error
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+ An error must be signaled if the result-type is neither a recognizable subtype of list, nor a recognizable subtype of vector.

+ An error of type type-error should be signaled if result-type specifies the number of elements and the sum of the lengths of sequence-1 and sequence-2 is different from that number.

+

See Also:

+

+sort, stable-sort, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge_.htm new file mode 100644 index 00000000..7da94311 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_merge_.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function MERGE-PATHNAMES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MERGE-PATHNAMES

+

Syntax:

+

+ +merge-pathnames pathname &optional default-pathname default-version

=> merged-pathname

+

+

Arguments and Values:

+

+ pathname---a pathname designator.

+ default-pathname---a pathname designator. The default is the value of *default-pathname-defaults*.

+ default-version---a valid pathname version. The default is :newest.

+merged-pathname---a pathname.

+

Description:

+

+Constructs a pathname from pathname by filling in any unsupplied components with the corresponding values from default-pathname and default-version.

+Defaulting of pathname components is done by filling in components taken from another pathname. This is especially useful for cases such as a program that has an input file and an output file. Unspecified components of the output pathname will come from the input pathname, except that the type should not default to the type of the input pathname but rather to the appropriate default type for output from the program; for example, see the function compile-file-pathname.

+If no version is supplied, default-version is used. If default-version is nil, the version component will remain unchanged.

+If pathname explicitly specifies a host and not a device, and if the host component of default-pathname matches the host component of pathname, then the device is taken from the default-pathname; otherwise the device will be the default file device for that host. If pathname does not specify a host, device, directory, name, or type, each such component is copied from default-pathname. If pathname does not specify a name, then the version, if not provided, will come from default-pathname, just like the other components. If pathname does specify a name, then the version is not affected by default-pathname. If this process leaves the version missing, the default-version is used. If the host's file name syntax provides a way to input a version without a name or type, the user can let the name and type default but supply a version different from the one in default-pathname.

+ If pathname is a stream, pathname effectively becomes (pathname pathname). merge-pathnames can be used on either an open or a closed stream.

+If pathname is a pathname it represents the name used to open the file. This may be, but is not required to be, the actual name of the file.

+ merge-pathnames recognizes a logical pathname namestring when default-pathname is a logical pathname, or when the namestring begins with the name of a defined logical host followed by a colon. In the first of these two cases, the host portion of the logical pathname namestring and its following colon are optional.

+ merge-pathnames returns a logical pathname if and only if its first argument is a logical pathname, or its first argument is a logical pathname namestring with an explicit host, or its first argument does not specify a host and the default-pathname is a logical pathname.

+ Pathname merging treats a relative directory specially. If (pathname-directory pathname) is a list whose car is :relative, and (pathname-directory default-pathname) is a list, then the merged directory is the value of

+

+ (append (pathname-directory default-pathname)
+         (cdr  ;remove :relative from the front
+           (pathname-directory pathname)))
+
+ except that if the resulting list contains a string or :wild immediately followed by :back, both of them are removed. This removal of redundant :back keywords is repeated as many times as possible. If (pathname-directory default-pathname) is not a list or (pathname-directory pathname) is not a list whose car is :relative, the merged directory is (or (pathname-directory pathname) (pathname-directory default-pathname))

+ merge-pathnames maps customary case in pathname into customary case in the output pathname.

+

Examples:

+ +

+ (merge-pathnames "CMUC::FORMAT"
+                  "CMUC::PS:<LISPIO>.FASL")
+=>  #P"CMUC::PS:<LISPIO>FORMAT.FASL.0"
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ *default-pathname-defaults*, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+The net effect is that if just a name is supplied, the host, device, directory, and type will come from default-pathname, but the version will come from default-version. If nothing or just a directory is supplied, the name, type, and version will come from default-pathname together.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_meth_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_meth_1.htm new file mode 100644 index 00000000..35d1bdbf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_meth_1.htm @@ -0,0 +1,56 @@ + + + +CLHS: Function METHOD-COMBINATION-ERROR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function METHOD-COMBINATION-ERROR

+

Syntax:

+

+ +method-combination-error format-control &rest args => implementation-dependent

+

+

Arguments and Values:

+

+ format-control---a format control.

+args---format arguments for format-control.

+

Description:

+

+The function method-combination-error is used to signal an error in method combination.

+The error message is constructed by using a format-control suitable for format and any args to it. Because an implementation may need to add additional contextual information to the error message, method-combination-error should be called only within the dynamic extent of a method combination function.

+Whether method-combination-error returns to its caller or exits via throw is implementation-dependent.

+

Examples: None. +

+

Side Effects:

+

+The debugger might be entered.

+

Affected By:

+

+*break-on-signals*

+

Exceptional Situations: None. +

+

See Also:

+

+define-method-combination

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_method.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_method.htm new file mode 100644 index 00000000..fe83fd61 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_method.htm @@ -0,0 +1,61 @@ + + + +CLHS: Standard Generic Function METHOD-QUALIFIERS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function METHOD-QUALIFIERS

+

Syntax:

+

+ +method-qualifiers method => qualifiers

+

+

Method Signatures:

+

+ +method-qualifiers (method standard-method)

+

+

Arguments and Values:

+

+method---a method.

+qualifiers---a proper list.

+

Description:

+

+Returns a list of the qualifiers of the method.

+

Examples:

+

+

+ (defmethod some-gf :before ((a integer)) a)
+=>  #<STANDARD-METHOD SOME-GF (:BEFORE) (INTEGER) 42736540>
+ (method-qualifiers *) =>  (:BEFORE)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+define-method-combination

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mexp_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mexp_.htm new file mode 100644 index 00000000..9962dbb6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mexp_.htm @@ -0,0 +1,124 @@ + + + +CLHS: Function MACROEXPAND, MACROEXPAND-1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MACROEXPAND, MACROEXPAND-1

+

Syntax:

+

+ +macroexpand form &optional env => expansion, expanded-p

+ +macroexpand-1 form &optional env => expansion, expanded-p

+

+

Arguments and Values:

+

+form---a form.

+env---an environment object. The default is nil.

+expansion---a form.

+ expanded-p---a generalized boolean.

+

Description:

+

+macroexpand and macroexpand-1 expand macros.

+If form is a macro form, then macroexpand-1 expands the macro form call once.

+macroexpand repeatedly expands form until it is no longer a macro form. In effect, macroexpand calls macroexpand-1 repeatedly until the secondary value it returns is nil.

+If form is a macro form, then the expansion is a macro expansion and expanded-p is true. Otherwise, the expansion is the given form and expanded-p is false.

+Macro expansion is carried out as follows. Once macroexpand-1 has determined that the form is a macro form, it obtains an appropriate expansion function for the macro or symbol macro. The value of *macroexpand-hook* is coerced to a function and then called as a function of three arguments: the expansion function, the form, and the env. The value returned from this call is taken to be the expansion of the form.

+In addition to macro definitions in the global environment, any local macro definitions established within env by macrolet or symbol-macrolet are considered. If only form is supplied as an argument, then the environment is effectively null, and only global macro definitions as established by defmacro are considered. Macro definitions are shadowed by local function definitions.

+

Examples:

+

+

+ (defmacro alpha (x y) `(beta ,x ,y)) =>  ALPHA
+ (defmacro beta (x y) `(gamma ,x ,y)) =>  BETA
+ (defmacro delta (x y) `(gamma ,x ,y)) =>  EPSILON
+ (defmacro expand (form &environment env)
+   (multiple-value-bind (expansion expanded-p)
+       (macroexpand form env)
+     `(values ',expansion ',expanded-p))) =>  EXPAND
+ (defmacro expand-1 (form &environment env)
+   (multiple-value-bind (expansion expanded-p)
+       (macroexpand-1 form env)
+     `(values ',expansion ',expanded-p))) =>  EXPAND-1
+
+;; Simple examples involving just the global environment
+ (macroexpand-1 '(alpha a b)) =>  (BETA A B), true
+ (expand-1 (alpha a b)) =>  (BETA A B), true
+ (macroexpand '(alpha a b)) =>  (GAMMA A B), true
+ (expand (alpha a b)) =>  (GAMMA A B), true
+ (macroexpand-1 'not-a-macro) =>  NOT-A-MACRO, false
+ (expand-1 not-a-macro) =>  NOT-A-MACRO, false
+ (macroexpand '(not-a-macro a b)) =>  (NOT-A-MACRO A B), false
+ (expand (not-a-macro a b)) =>  (NOT-A-MACRO A B), false
+
+;; Examples involving lexical environments
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (macroexpand-1 '(alpha a b))) =>  (BETA A B), true
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (expand-1 (alpha a b))) =>  (DELTA A B), true
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (macroexpand '(alpha a b))) =>  (GAMMA A B), true
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (expand (alpha a b))) =>  (GAMMA A B), true
+ (macrolet ((beta (x y) `(epsilon ,x ,y)))
+   (expand (alpha a b))) =>  (EPSILON A B), true
+ (let ((x (list 1 2 3)))
+   (symbol-macrolet ((a (first x)))
+     (expand a))) =>  (FIRST X), true
+ (let ((x (list 1 2 3)))
+   (symbol-macrolet ((a (first x)))
+     (macroexpand 'a))) =>  A, false
+ (symbol-macrolet ((b (alpha x y)))
+   (expand-1 b)) =>  (ALPHA X Y), true
+ (symbol-macrolet ((b (alpha x y)))
+   (expand b)) =>  (GAMMA X Y), true
+ (symbol-macrolet ((b (alpha x y))
+                   (a b))
+   (expand-1 a)) =>  B, true
+ (symbol-macrolet ((b (alpha x y))
+                   (a b))
+   (expand a)) =>  (GAMMA X Y), true
+
+;; Examples of shadowing behavior
+ (flet ((beta (x y) (+ x y)))
+   (expand (alpha a b))) =>  (BETA A B), true
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (flet ((alpha (x y) (+ x y)))
+     (expand (alpha a b)))) =>  (ALPHA A B), false
+ (let ((x (list 1 2 3)))
+   (symbol-macrolet ((a (first x)))
+     (let ((a x))
+       (expand a)))) =>  A, false
+
+

+

Affected By:

+

+defmacro, setf of macro-function, macrolet, symbol-macrolet

+

Exceptional Situations: None. +

+

See Also:

+

+*macroexpand-hook*, defmacro, setf of macro-function, macrolet, symbol-macrolet, Section 3.1 (Evaluation)

+

Notes:

+

+Neither macroexpand nor macroexpand-1 makes any explicit attempt to expand macro forms that are either subforms of the form or subforms of the expansion. Such expansion might occur implicitly, however, due to the semantics or implementation of the macro function.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_minusp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_minusp.htm new file mode 100644 index 00000000..19552111 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_minusp.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function MINUSP, PLUSP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MINUSP, PLUSP

+

Syntax:

+

+ +minusp real => generalized-boolean

+

+ +plusp real => generalized-boolean

+

+

Arguments and Values:

+

+real---a real.

+generalized-boolean---a generalized boolean.

+

Description:

+

+minusp returns true if real is less than zero; otherwise, returns false.

+plusp returns true if real is greater than zero; otherwise, returns false.

+Regardless of whether an implementation provides distinct representations for positive and negative float zeros, (minusp -0.0) always returns false.

+

Examples:

+ +

+ (minusp -1) =>  true
+ (plusp 0) =>  false
+ (plusp least-positive-single-float) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if real is not a real.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mismat.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mismat.htm new file mode 100644 index 00000000..bbecc946 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mismat.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function MISMATCH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MISMATCH

+

Syntax:

+

+ +mismatch sequence-1 sequence-2 &key from-end test test-not key start1 start2 end1 end2

=> position

+

+

Arguments and Values:

+

+Sequence-1---a sequence.

+Sequence-2---a sequence.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start1, end1---bounding index designators of sequence-1. The defaults for start1 and end1 are 0 and nil, respectively.

+start2, end2---bounding index designators of sequence-2. The defaults for start2 and end2 are 0 and nil, respectively.

+key---a designator for a function of one argument, or nil.

+position---a bounding index of sequence-1, or nil.

+

Description:

+

+The specified subsequences of sequence-1 and sequence-2 are compared element-wise.

+The key argument is used for both the sequence-1 and the sequence-2.

+If sequence-1 and sequence-2 are of equal length and match in every element, the result is false. Otherwise, the result is a non-negative integer, the index within sequence-1 of the leftmost or rightmost position, depending on from-end, at which the two subsequences fail to match. If one subsequence is shorter than and a matching prefix of the other, the result is the index relative to sequence-1 beyond the last position tested.

+If from-end is true, then one plus the index of the rightmost position in which the sequences differ is returned. In effect, the subsequences are aligned at their right-hand ends; then, the last elements are compared, the penultimate elements, and so on. The index returned is an index relative to sequence-1.

+

Examples:

+ +

+ (mismatch "abcd" "ABCDE" :test #'char-equal) =>  4
+ (mismatch '(3 2 1 1 2 3) '(1 2 3) :from-end t) =>  3
+ (mismatch '(1 2 3) '(2 3 4) :test-not #'eq :key #'oddp) =>  NIL
+ (mismatch '(1 2 3 4 5 6) '(3 4 5 6 7) :start1 2 :end2 4) =>  NIL 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not argument is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ar.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ar.htm new file mode 100644 index 00000000..58d4fc0a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ar.htm @@ -0,0 +1,145 @@ + + + +CLHS: Function MAKE-ARRAY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-ARRAY

+

Syntax:

+

+ +make-array dimensions &key element-type initial-element initial-contents adjustable fill-pointer displaced-to displaced-index-offset

=> new-array

+

+

Arguments and Values:

+

+dimensions---a designator for a list of valid array dimensions.

+element-type---a type specifier. The default is t.

+initial-element---an object.

+initial-contents---an object.

+adjustable---a generalized boolean. The default is nil.

+fill-pointer---a valid fill pointer for the array to be created, or t or nil. The default is nil.

+displaced-to---an array or nil. The default is nil. This option must not be supplied if either initial-element or initial-contents is supplied.

+displaced-index-offset---a valid array row-major index for displaced-to. The default is 0. This option must not be supplied unless a non-nil displaced-to is supplied.

+new-array---an array.

+

Description:

+

+Creates and returns an array constructed of the most specialized type that can accommodate elements of type given by element-type. If dimensions is nil then a zero-dimensional array is created.

+Dimensions represents the dimensionality of the new array.

+element-type indicates the type of the elements intended to be stored in the new-array. The new-array can actually store any objects of the type which results from upgrading element-type; see Section 15.1.2.1 (Array Upgrading).

+If initial-element is supplied, it is used to initialize each element of new-array. If initial-element is supplied, it must be of the type given by element-type. initial-element cannot be supplied if either the :initial-contents option is supplied or displaced-to is non-nil. If initial-element is not supplied, the consequences of later reading an uninitialized element of new-array are undefined unless either initial-contents is supplied or displaced-to is non-nil.

+initial-contents is used to initialize the contents of array. For example:

+

+ (make-array '(4 2 3) :initial-contents
+             '(((a b c) (1 2 3))
+              ((d e f) (3 1 2))
+              ((g h i) (2 3 1))
+              ((j k l) (0 0 0))))
+
+

+initial-contents is composed of a nested structure of sequences. The numbers of levels in the structure must equal the rank of array. Each leaf of the nested structure must be of the type given by element-type. If array is zero-dimensional, then initial-contents specifies the single element. Otherwise, initial-contents must be a sequence whose length is equal to the first dimension; each element must be a nested structure for an array whose dimensions are the remaining dimensions, and so on. Initial-contents cannot be supplied if either initial-element is supplied or displaced-to is non-nil. If initial-contents is not supplied, the consequences of later reading an uninitialized element of new-array are undefined unless either initial-element is supplied or displaced-to is non-nil.

+If adjustable is non-nil, the array is expressly adjustable (and so actually adjustable); otherwise, the array is not expressly adjustable (and it is implementation-dependent whether the array is actually adjustable).

+If fill-pointer is non-nil, the array must be one-dimensional; that is, the array must be a vector. If fill-pointer is t, the length of the vector is used to initialize the fill pointer. If fill-pointer is an integer, it becomes the initial fill pointer for the vector.

+If displaced-to is non-nil, make-array will create a displaced array and displaced-to is the target of that displaced array. In that case, the consequences are undefined if the actual array element type of displaced-to is not type equivalent to the actual array element type of the array being created. If displaced-to is nil, the array is not a displaced array.

+The displaced-index-offset is made to be the index offset of the array. When an array A is given as the :displaced-to argument to make-array when creating array B, then array B is said to be displaced to array A. The total number of elements in an array, called the total size of the array, is calculated as the product of all the dimensions. It is required that the total size of A be no smaller than the sum of the total size of B plus the offset n supplied by the displaced-index-offset. The effect of displacing is that array B does not have any elements of its own, but instead maps accesses to itself into accesses to array A. The mapping treats both arrays as if they were one-dimensional by taking the elements in row-major order, and then maps an access to element k of array B to an access to element k+n of array A.

+If make-array is called with adjustable, fill-pointer, and displaced-to each nil, then the result is a simple array. If make-array is called with one or more of adjustable, fill-pointer, or displaced-to being true, whether the resulting array is a simple array is implementation-dependent.

+ When an array A is given as the :displaced-to argument to make-array when creating array B, then array B is said to be displaced to array A. The total number of elements in an array, called the total size of the array, is calculated as the product of all the dimensions. The consequences are unspecified if the total size of A is smaller than the sum of the total size of B plus the offset n supplied by the displaced-index-offset. The effect of displacing is that array B does not have any elements of its own, but instead maps accesses to itself into accesses to array A. The mapping treats both arrays as if they were one-dimensional by taking the elements in row-major order, and then maps an access to element k of array B to an access to element k+n of array A.

+

Examples:

+ +

+
+ (make-array 5) ;; Creates a one-dimensional array of five elements.
+ (make-array '(3 4) :element-type '(mod 16)) ;; Creates a 
+                ;;two-dimensional array, 3 by 4, with four-bit elements.
+ (make-array 5 :element-type 'single-float) ;; Creates an array of single-floats.
+
+

+

+ (make-array nil :initial-element nil) =>  #0ANIL
+ (make-array 4 :initial-element nil) =>  #(NIL NIL NIL NIL)
+ (make-array '(2 4) 
+              :element-type '(unsigned-byte 2) 
+              :initial-contents '((0 1 2 3) (3 2 1 0)))
+=>  #2A((0 1 2 3) (3 2 1 0))
+ (make-array 6
+              :element-type 'character 
+              :initial-element #\a 
+              :fill-pointer 3) =>  "aaa"
+
+

+The following is an example of making a displaced array.

+

+ (setq a (make-array '(4 3))) 
+=>  #<ARRAY 4x3 simple 32546632>
+ (dotimes (i 4)
+   (dotimes (j 3)
+     (setf (aref a i j) (list i 'x j '= (* i j)))))
+=>  NIL
+ (setq b (make-array 8 :displaced-to a
+                       :displaced-index-offset 2))
+=>  #<ARRAY 8 indirect 32550757>
+ (dotimes (i 8)
+   (print (list i (aref b i))))
+>>  (0 (0 X 2 = 0)) 
+>>  (1 (1 X 0 = 0)) 
+>>  (2 (1 X 1 = 1)) 
+>>  (3 (1 X 2 = 2)) 
+>>  (4 (2 X 0 = 0)) 
+>>  (5 (2 X 1 = 2)) 
+>>  (6 (2 X 2 = 4)) 
+>>  (7 (3 X 0 = 0)) 
+=>  NIL
+
+ The last example depends on the fact that arrays are, in effect, stored in row-major order.

+

+ (setq a1 (make-array 50))
+=>  #<ARRAY 50 simple 32562043>
+ (setq b1 (make-array 20 :displaced-to a1 :displaced-index-offset 10))
+=>  #<ARRAY 20 indirect 32563346>
+ (length b1) =>  20
+
+ (setq a2 (make-array 50 :fill-pointer 10))
+=>  #<ARRAY 50 fill-pointer 10 46100216>
+ (setq b2 (make-array 20 :displaced-to a2 :displaced-index-offset 10))
+=>  #<ARRAY 20 indirect 46104010>
+ (length a2) =>  10
+ (length b2) =>  20
+
+ (setq a3 (make-array 50 :fill-pointer 10))
+=>  #<ARRAY 50 fill-pointer 10 46105663>
+ (setq b3 (make-array 20 :displaced-to a3 :displaced-index-offset 10
+                         :fill-pointer 5))
+=>  #<ARRAY 20 indirect, fill-pointer 5 46107432>
+ (length a3) =>  10
+ (length b3) =>  5
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+adjustable-array-p, aref, arrayp, array-element-type, array-rank-limit, array-dimension-limit, fill-pointer, upgraded-array-element-type

+

Notes:

+

+ There is no specified way to create an array for which adjustable-array-p definitely returns false. There is no specified way to create an array that is not a simple array.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_bro.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_bro.htm new file mode 100644 index 00000000..1c384bee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_bro.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function MAKE-BROADCAST-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-BROADCAST-STREAM

+

Syntax:

+

+ +make-broadcast-stream &rest streams => broadcast-stream

+

+

Arguments and Values:

+

+stream---an output stream.

+

+broadcast-stream---a broadcast stream.

+

Description:

+

+Returns a broadcast stream.

+

Examples:

+

+

+ (setq a-stream (make-string-output-stream)
+        b-stream (make-string-output-stream)) =>  #<String Output Stream>
+ (format (make-broadcast-stream a-stream b-stream)
+          "this will go to both streams") =>  NIL
+ (get-output-stream-string a-stream) =>  "this will go to both streams"
+ (get-output-stream-string b-stream) =>  "this will go to both streams"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if any stream is not an output stream.

+

See Also:

+

+broadcast-stream-streams

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_cnd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_cnd.htm new file mode 100644 index 00000000..32a047e0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_cnd.htm @@ -0,0 +1,73 @@ + + + +CLHS: Function MAKE-CONDITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-CONDITION

+

Syntax:

+

+ +make-condition type &rest slot-initializations => condition

+

+

Arguments and Values:

+

+type---a type specifier (for a subtype of condition).

+slot-initializations---an initialization argument list.

+condition---a condition.

+

Description:

+

+Constructs and returns a condition of type type using slot-initializations for the initial values of the slots. The newly created condition is returned.

+

Examples:

+ +

+ (defvar *oops-count* 0)
+
+ (setq a (make-condition 'simple-error
+                         :format-control "This is your ~:R error."
+                         :format-arguments (list (incf *oops-count*))))
+=>  #<SIMPLE-ERROR 32245104>
+ 
+ (format t "~&~A~%" a)
+>>  This is your first error.
+=>  NIL
+ 
+ (error a)
+>>  Error: This is your first error.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Return to Lisp Toplevel.
+>>  Debug> 
+
+

+

Side Effects: None. +

+

Affected By:

+

+The set of defined condition types.

+

Exceptional Situations: None. +

+

See Also:

+

+define-condition, Section 9.1 (Condition System Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_con.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_con.htm new file mode 100644 index 00000000..f4bb21f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_con.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function MAKE-CONCATENATED-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-CONCATENATED-STREAM

+

Syntax:

+

+ +make-concatenated-stream &rest input-streams => concatenated-stream

+

+

Arguments and Values:

+

+input-stream---an input stream.

+

+concatenated-stream---a concatenated stream.

+

Description:

+

+Returns a concatenated stream that has the indicated input-streams initially associated with it.

+

+

Examples:

+ +

+ (read (make-concatenated-stream
+         (make-string-input-stream "1")
+         (make-string-input-stream "2"))) =>  12
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if any argument is not an input stream.

+

See Also:

+

+concatenated-stream-streams

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_dis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_dis.htm new file mode 100644 index 00000000..01f10eca --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_dis.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function MAKE-DISPATCH-MACRO-CHARACTER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-DISPATCH-MACRO-CHARACTER

+

Syntax:

+

+ +make-dispatch-macro-character char &optional non-terminating-p readtable => t

+

+

Arguments and Values:

+

+ char---a character.

+non-terminating-p---a generalized boolean. The default is false.

+readtable---a readtable. The default is the current readtable.

+

Description:

+

+make-dispatch-macro-character makes char be a dispatching macro character in readtable.

+Initially, every character in the dispatch table associated with the char has an associated function that signals an error of type reader-error.

+If non-terminating-p is true, the dispatching macro character is made a non-terminating macro character; if non-terminating-p is false, the dispatching macro character is made a terminating macro character.

+

Examples:

+

+

+ (get-macro-character #\{) =>  NIL, false
+ (make-dispatch-macro-character #\{) =>  T
+ (not (get-macro-character #\{)) =>  false
+
+

+

Side Effects: None. +

+The readtable is altered.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+*readtable*, set-dispatch-macro-character

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ech.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ech.htm new file mode 100644 index 00000000..e489f9c0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ech.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function MAKE-ECHO-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-ECHO-STREAM

+

Syntax:

+

+

+ +make-echo-stream input-stream output-stream => echo-stream

+

+

Arguments and Values:

+

+input-stream---an input stream.

+output-stream---an output stream.

+echo-stream---an echo stream.

+

Description:

+

+Creates and returns an echo stream that takes input from input-stream and sends output to output-stream.

+

+

Examples:

+ +

+ (let ((out (make-string-output-stream)))
+    (with-open-stream 
+        (s (make-echo-stream
+            (make-string-input-stream "this-is-read-and-echoed")
+            out))
+      (read s)
+      (format s " * this-is-direct-output")
+      (get-output-stream-string out)))
+=>  "this-is-read-and-echoed * this-is-direct-output"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+echo-stream-input-stream, echo-stream-output-stream, make-two-way-stream

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_has.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_has.htm new file mode 100644 index 00000000..86299da3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_has.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function MAKE-HASH-TABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-HASH-TABLE

+

Syntax:

+

+ +make-hash-table &key test size rehash-size rehash-threshold => hash-table

+

+

Arguments and Values:

+

+test---a designator for one of the functions eq, eql, equal, or equalp. The default is eql.

+ size---a non-negative integer. The default is implementation-dependent.

+rehash-size---a real of type (or (integer 1 *) (float (1.0) *)). The default is implementation-dependent.

+ rehash-threshold---a real of type (real 0 1). The default is implementation-dependent.

+hash-table---a hash table.

+

Description:

+

+Creates and returns a new hash table.

+test determines how keys are compared. An object is said to be present in the hash-table if that object is the same under the test as the key for some entry in the hash-table.

+size is a hint to the implementation about how much initial space to allocate in the hash-table. This information, taken together with the rehash-threshold, controls the approximate number of entries which it should be possible to insert before the table has to grow. The actual size might be rounded up from size to the next `good' size; for example, some implementations might round to the next prime number.

+rehash-size specifies a minimum amount to increase the size of the hash-table when it becomes full enough to require rehashing; see rehash-theshold below. If rehash-size is an integer, the expected growth rate for the table is additive and the integer is the number of entries to add; if it is a float, the expected growth rate for the table is multiplicative and the float is the ratio of the new size to the old size. As with size, the actual size of the increase might be rounded up.

+rehash-threshold specifies how full the hash-table can get before it must grow. It specifies the maximum desired hash-table occupancy level.

+ The values of rehash-size and rehash-threshold do not constrain the implementation to use any particular method for computing when and by how much the size of hash-table should be enlarged. Such decisions are implementation-dependent, and these values only hints from the programmer to the implementation, and the implementation is permitted to ignore them.

+

Examples:

+

+

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 46142754>
+ (setf (gethash "one" table) 1) =>  1
+ (gethash "one" table) =>  NIL, false
+ (setq table (make-hash-table :test 'equal)) =>  #<HASH-TABLE EQUAL 0/139 46145547>
+ (setf (gethash "one" table) 1) =>  1
+ (gethash "one" table) =>  1, T
+ (make-hash-table :rehash-size 1.5 :rehash-threshold 0.7) 
+=>  #<HASH-TABLE EQL 0/120 46156620>
+
+

+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+gethash, hash-table

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_i_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_i_1.htm new file mode 100644 index 00000000..583099bd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_i_1.htm @@ -0,0 +1,59 @@ + + + +CLHS: Standard Generic Function MAKE-INSTANCES-OBSOLETE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function MAKE-INSTANCES-OBSOLETE

+

Syntax:

+

+ +make-instances-obsolete class => class

+

+

Method Signatures:

+

+ +make-instances-obsolete (class standard-class)

+

+ +make-instances-obsolete (class symbol)

+

+

Arguments and Values:

+

+class---a class designator.

+

Description:

+

+The function make-instances-obsolete has the effect of initiating the process of updating the instances of the class. During updating, the generic function update-instance-for-redefined-class will be invoked.

+The generic function make-instances-obsolete is invoked automatically by the system when defclass has been used to redefine an existing standard class and the set of local slots accessible in an instance is changed or the order of slots in storage is changed. It can also be explicitly invoked by the user.

+If the second of the above methods is selected, that method invokes make-instances-obsolete on (find-class class).

+

Examples:

+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+update-instance-for-redefined-class, Section 4.3.6 (Redefining Classes)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ins.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ins.htm new file mode 100644 index 00000000..f79f28f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ins.htm @@ -0,0 +1,61 @@ + + + +CLHS: Standard Generic Function MAKE-INSTANCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function MAKE-INSTANCE

+

Syntax:

+

+ +make-instance class &rest initargs &key &allow-other-keys => instance

+

+

Method Signatures:

+

+ +make-instance (class standard-class) &rest initargs

+

+ +make-instance (class symbol) &rest initargs

+

+

Arguments and Values:

+

+class---a class, or a symbol that names a class.

+initargs---an initialization argument list.

+instance---a fresh instance of class class.

+

Description:

+

+The generic function make-instance creates and returns a new instance of the given class.

+If the second of the above methods is selected, that method invokes make-instance on the arguments (find-class class) and initargs.

+The initialization arguments are checked within make-instance.

+The generic function make-instance may be used as described in Section 7.1 (Object Creation and Initialization).

+

Affected By: None. +

+

Exceptional Situations:

+

+If any of the initialization arguments has not been declared as valid, an error of type error is signaled.

+

See Also:

+

+defclass, class-of, allocate-instance, initialize-instance, Section 7.1 (Object Creation and Initialization)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_l_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_l_1.htm new file mode 100644 index 00000000..c524ab20 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_l_1.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function MAKE-LOAD-FORM-SAVING-SLOTS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-LOAD-FORM-SAVING-SLOTS

+

+

Syntax:

+

+ +make-load-form-saving-slots object &key slot-names environment

=> creation-form, initialization-form

+

+

Arguments and Values:

+

+object---an object.

+slot-names---a list.

+environment---an environment object.

+creation-form---a form.

+initialization-form---a form.

+

Description:

+

+ Returns forms that, when evaluated, will construct an object equivalent to object, without executing initialization forms. The slots in the new object that correspond to initialized slots in object are initialized using the values from object. Uninitialized slots in object are not initialized in the new object. make-load-form-saving-slots works for any instance of standard-object or structure-object.

+Slot-names is a list of the names of the slots to preserve. If slot-names is not supplied, its value is all of the local slots.

+make-load-form-saving-slots returns two values, thus it can deal with circular structures. Whether the result is useful in an application depends on whether the object's type and slot contents fully capture the application's idea of the object's state.

+Environment is the environment in which the forms will be processed.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-load-form, make-instance, setf, slot-value, slot-makunbound

+

Notes:

+

+make-load-form-saving-slots can be useful in user-written make-load-form methods.

+

+ When the object is an instance of standard-object, make-load-form-saving-slots could return a creation form that calls allocate-instance and an initialization form that contains calls to setf of slot-value and slot-makunbound, though other functions of similar effect might actually be used.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ld_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ld_.htm new file mode 100644 index 00000000..4ab3311c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_ld_.htm @@ -0,0 +1,150 @@ + + + +CLHS: Standard Generic Function MAKE-LOAD-FORM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function MAKE-LOAD-FORM

+

Syntax:

+

+ +make-load-form object &optional environment => creation-form[, initialization-form]

+

+

Method Signatures:

+

+ +make-load-form (object standard-object) &optional environment

+ +make-load-form (object structure-object) &optional environment

+ +make-load-form (object condition) &optional environment

+ +make-load-form (object class) &optional environment

+

+

Arguments and Values:

+

+object---an object.

+environment---an environment object.

+creation-form---a form.

+initialization-form---a form.

+

Description:

+

+The generic function make-load-form creates and returns one or two forms, a creation-form and an initialization-form, that enable load to construct an object equivalent to object. Environment is an environment object corresponding to the lexical environment in which the forms will be processed.

+The file compiler calls make-load-form to process certain classes of literal objects; see Section 3.2.4.4 (Additional Constraints on Externalizable Objects).

+Conforming programs may call make-load-form directly, providing object is a generalized instance of standard-object, structure-object, or condition.

+The creation form is a form that, when evaluated at load time, should return an object that is equivalent to object. The exact meaning of equivalent depends on the type of object and is up to the programmer who defines a method for make-load-form; see Section 3.2.4 (Literal Objects in Compiled Files).

+The initialization form is a form that, when evaluated at load time, should perform further initialization of the object. The value returned by the initialization form is ignored. If make-load-form returns only one value, the initialization form is nil, which has no effect. If object appears as a constant in the initialization form, at load time it will be replaced by the equivalent object constructed by the creation form; this is how the further initialization gains access to the object.

+Both the creation-form and the initialization-form may contain references to any externalizable object. However, there must not be any circular dependencies in creation forms. An example of a circular dependency is when the creation form for the object X contains a reference to the object Y, and the creation form for the object Y contains a reference to the object X. Initialization forms are not subject to any restriction against circular dependencies, which is the reason that initialization forms exist; see the example of circular data structures below.

+The creation form for an object is always evaluated before the initialization form for that object. When either the creation form or the initialization form references other objects that have not been referenced earlier in the file being compiled, the compiler ensures that all of the referenced objects have been created before evaluating the referencing form. When the referenced object is of a type which the file compiler processes using make-load-form, this involves evaluating the creation form returned for it. (This is the reason for the prohibition against circular references among creation forms).

+Each initialization form is evaluated as soon as possible after its associated creation form, as determined by data flow. If the initialization form for an object does not reference any other objects not referenced earlier in the file and processed by the file compiler using make-load-form, the initialization form is evaluated immediately after the creation form. If a creation or initialization form F does contain references to such objects, the creation forms for those other objects are evaluated before F, and the initialization forms for those other objects are also evaluated before F whenever they do not depend on the object created or initialized by F. Where these rules do not uniquely determine an order of evaluation between two creation/initialization forms, the order of evaluation is unspecified.

+ While these creation and initialization forms are being evaluated, the objects are possibly in an uninitialized state, analogous to the state of an object between the time it has been created by allocate-instance and it has been processed fully by initialize-instance. Programmers writing methods for make-load-form must take care in manipulating objects not to depend on slots that have not yet been initialized.

+ It is implementation-dependent whether load calls eval on the forms or does some other operation that has an equivalent effect. For example, the forms might be translated into different but equivalent forms and then evaluated, they might be compiled and the resulting functions called by load, or they might be interpreted by a special-purpose function different from eval. All that is required is that the effect be equivalent to evaluating the forms.

+The method specialized on class returns a creation form using the name of the class if the class has a proper name in environment, signaling an error of type error if it does not have a proper name. Evaluation of the creation form uses the name to find the class with that name, as if by calling find-class. If a class with that name has not been defined, then a class may be computed in an implementation-defined manner. If a class cannot be returned as the result of evaluating the creation form, then an error of type error is signaled.

+Both conforming implementations and conforming programs may further specialize make-load-form.

+

Examples:

+

+

+ (defclass obj ()
+    ((x :initarg :x :reader obj-x)
+     (y :initarg :y :reader obj-y)
+     (dist :accessor obj-dist)))
+=>  #<STANDARD-CLASS OBJ 250020030>
+ (defmethod shared-initialize :after ((self obj) slot-names &rest keys)
+   (declare (ignore slot-names keys))
+   (unless (slot-boundp self 'dist)
+     (setf (obj-dist self)
+           (sqrt (+ (expt (obj-x self) 2) (expt (obj-y self) 2))))))
+=>  #<STANDARD-METHOD SHARED-INITIALIZE (:AFTER) (OBJ T) 26266714>
+ (defmethod make-load-form ((self obj) &optional environment)
+   (declare (ignore environment))
+   ;; Note that this definition only works because X and Y do not
+   ;; contain information which refers back to the object itself.
+   ;; For a more general solution to this problem, see revised example below.
+   `(make-instance ',(class-of self)
+                   :x ',(obj-x self) :y ',(obj-y self)))
+=>  #<STANDARD-METHOD MAKE-LOAD-FORM (OBJ) 26267532>
+ (setq obj1 (make-instance 'obj :x 3.0 :y 4.0)) =>  #<OBJ 26274136>
+ (obj-dist obj1) =>  5.0
+ (make-load-form obj1) =>  (MAKE-INSTANCE 'OBJ :X '3.0 :Y '4.0)
+
+

+In the above example, an equivalent instance of obj is reconstructed by using the values of two of its slots. The value of the third slot is derived from those two values.

+Another way to write the make-load-form method in that example is to use make-load-form-saving-slots. The code it generates might yield a slightly different result from the make-load-form method shown above, but the operational effect will be the same. For example:

+

+ ;; Redefine method defined above.
+ (defmethod make-load-form ((self obj) &optional environment)
+    (make-load-form-saving-slots self
+                                 :slot-names '(x y)
+                                 :environment environment))
+=>  #<STANDARD-METHOD MAKE-LOAD-FORM (OBJ) 42755655>
+ ;; Try MAKE-LOAD-FORM on object created above.
+ (make-load-form obj1)
+=>  (ALLOCATE-INSTANCE '#<STANDARD-CLASS OBJ 250020030>),
+    (PROGN
+      (SETF (SLOT-VALUE '#<OBJ 26274136> 'X) '3.0)
+      (SETF (SLOT-VALUE '#<OBJ 26274136> 'Y) '4.0)
+      (INITIALIZE-INSTANCE '#<OBJ 26274136>))
+
+

+In the following example, instances of my-frob are ``interned'' in some way. An equivalent instance is reconstructed by using the value of the name slot as a key for searching existing objects. In this case the programmer has chosen to create a new object if no existing object is found; alternatively an error could have been signaled in that case.

+

+ (defclass my-frob ()
+    ((name :initarg :name :reader my-name)))
+ (defmethod make-load-form ((self my-frob) &optional environment)
+   (declare (ignore environment))
+   `(find-my-frob ',(my-name self) :if-does-not-exist :create))
+
+

+In the following example, the data structure to be dumped is circular, because each parent has a list of its children and each child has a reference back to its parent. If make-load-form is called on one object in such a structure, the creation form creates an equivalent object and fills in the children slot, which forces creation of equivalent objects for all of its children, grandchildren, etc. At this point none of the parent slots have been filled in. The initialization form fills in the parent slot, which forces creation of an equivalent object for the parent if it was not already created. Thus the entire tree is recreated at load time. At compile time, make-load-form is called once for each object in the tree. All of the creation forms are evaluated, in implementation-dependent order, and then all of the initialization forms are evaluated, also in implementation-dependent order.

+

+ (defclass tree-with-parent () ((parent :accessor tree-parent)
+                                (children :initarg :children)))
+ (defmethod make-load-form ((x tree-with-parent) &optional environment)
+   (declare (ignore environment))
+   (values
+     ;; creation form
+     `(make-instance ',(class-of x) :children ',(slot-value x 'children))
+     ;; initialization form
+     `(setf (tree-parent ',x) ',(slot-value x 'parent))))
+
+

+In the following example, the data structure to be dumped has no special properties and an equivalent structure can be reconstructed simply by reconstructing the slots' contents.

+

+ (defstruct my-struct a b c)
+ (defmethod make-load-form ((s my-struct) &optional environment)
+    (make-load-form-saving-slots s :environment environment))
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+The methods specialized on standard-object, structure-object, and condition all signal an error of type error.

+It is implementation-dependent whether calling make-load-form on a generalized instance of a system class signals an error or returns creation and initialization forms.

+

See Also:

+

+compile-file, make-load-form-saving-slots, Section 3.2.4.4 (Additional Constraints on Externalizable Objects) Section 3.1 (Evaluation), Section 3.2 (Compilation)

+

Notes:

+

+The file compiler calls make-load-form in specific circumstances detailed in Section 3.2.4.4 (Additional Constraints on Externalizable Objects).

+Some implementations may provide facilities for defining new subclasses of classes which are specified as system classes. (Some likely candidates include generic-function, method, and stream). Such implementations should document how the file compiler processes instances of such classes when encountered as literal objects, and should document any relevant methods for make-load-form.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_lis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_lis.htm new file mode 100644 index 00000000..6bab0635 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_lis.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function MAKE-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-LIST

+

Syntax:

+

+ +make-list size &key initial-element => list

+

+

Arguments and Values:

+

+size---a non-negative integer.

+initial-element---an object. The default is nil.

+list---a list.

+

Description:

+

+Returns a list of length given by size, each of the elements of which is initial-element.

+

Examples:

+ +

+ (make-list 5) =>  (NIL NIL NIL NIL NIL)
+ (make-list 3 :initial-element 'rah) =>  (RAH RAH RAH)
+ (make-list 2 :initial-element '(1 2 3)) =>  ((1 2 3) (1 2 3))
+ (make-list 0) =>  NIL ;i.e.,  ()
+ (make-list 0 :initial-element 'new-element) =>  NIL 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if size is not a non-negative integer.

+

See Also:

+

+cons, list

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pkg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pkg.htm new file mode 100644 index 00000000..2fd53742 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pkg.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function MAKE-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-PACKAGE

+

Syntax:

+

+ +make-package package-name &key nicknames use => package

+

+

Arguments and Values:

+

+package-name---a string designator.

+nicknames---a list of string designators. The default is the empty list.

+ use---a list of package designators. The default is implementation-defined.

+package---a package.

+

Description:

+

+Creates a new package with the name package-name.

+Nicknames are additional names which may be used to refer to the new package.

+use specifies zero or more packages the external symbols of which are to be inherited by the new package. See the function use-package.

+

Examples:

+

+

+ (make-package 'temporary :nicknames '("TEMP" "temp")) =>  #<PACKAGE "TEMPORARY">
+ (make-package "OWNER" :use '("temp")) =>  #<PACKAGE "OWNER">
+ (package-used-by-list 'temp) =>  (#<PACKAGE "OWNER">)
+ (package-use-list 'owner) =>  (#<PACKAGE "TEMPORARY">)
+
+

+

Side Effects: None. +

+

Affected By:

+

+The existence of other packages in the system.

+

Exceptional Situations:

+

+The consequences are unspecified if packages denoted by use do not exist.

+A correctable error is signaled if the package-name or any of the nicknames is already the name or nickname of an existing package.

+

See Also:

+

+defpackage, use-package

+

Notes:

+

+In situations where the packages to be used contain symbols which would conflict, it is necessary to first create the package with :use '(), then to use shadow or shadowing-import to address the conflicts, and then after that to use use-package once the conflicts have been addressed.

+When packages are being created as part of the static definition of a program rather than dynamically by the program, it is generally considered more stylistically appropriate to use defpackage rather than make-package.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pn.htm new file mode 100644 index 00000000..9aaf0e3c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_pn.htm @@ -0,0 +1,103 @@ + + + +CLHS: Function MAKE-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-PATHNAME

+

Syntax:

+

+ +make-pathname &key host device directory name type version defaults case

=> pathname

+

+

Arguments and Values:

+

+ host---a valid physical pathname host. Complicated defaulting behavior; see below.

+device---a valid pathname device. Complicated defaulting behavior; see below.

+directory---a valid pathname directory. Complicated defaulting behavior; see below.

+name---a valid pathname name. Complicated defaulting behavior; see below.

+type---a valid pathname type. Complicated defaulting behavior; see below.

+version---a valid pathname version. Complicated defaulting behavior; see below.

+defaults---a pathname designator. The default is a pathname whose host component is the same as the host component of the value of *default-pathname-defaults*, and whose other components are all nil.

+ case---one of :common or :local. The default is :local.

+pathname---a pathname.

+

Description:

+

+Constructs and returns a pathname from the supplied keyword arguments.

+After the components supplied explicitly by host, device, directory, name, type, and version are filled in, the merging rules used by merge-pathnames are used to fill in any unsupplied components from the defaults supplied by defaults.

+Whenever a pathname is constructed the components may be canonicalized if appropriate. For the explanation of the arguments that can be supplied for each component, see Section 19.2.1 (Pathname Components).

+ If case is supplied, it is treated as described in Section 19.2.2.1.2 (Case in Pathname Components).

+ The resulting pathname is a logical pathname if and only its host component is a logical host or a string that names a defined logical host.

+ If the directory is a string, it should be the name of a top level directory, and should not contain any punctuation characters; that is, specifying a string, str, is equivalent to specifying the list (:absolute str). Specifying the symbol :wild is equivalent to specifying the list (:absolute :wild-inferiors), or (:absolute :wild) in a file system that does not support :wild-inferiors.

+

Examples:

+

+

+ ;; Implementation A -- an implementation with access to a single
+ ;;  Unix file system.  This implementation happens to never display
+ ;;  the `host' information in a namestring, since there is only one host. 
+ (make-pathname :directory '(:absolute "public" "games")
+                :name "chess" :type "db")
+=>  #P"/public/games/chess.db" 
+
+ ;; Implementation B -- an implementation with access to one or more
+ ;;  VMS file systems.  This implementation displays `host' information
+ ;;  in the namestring only when the host is not the local host.
+ ;;  It uses a double colon to separate a host name from the host's local
+ ;;  file name.
+ (make-pathname :directory '(:absolute "PUBLIC" "GAMES")
+                :name "CHESS" :type "DB")
+=>  #P"SYS$DISK:[PUBLIC.GAMES]CHESS.DB" 
+ (make-pathname :host "BOBBY"
+                :directory '(:absolute "PUBLIC" "GAMES")
+                :name "CHESS" :type "DB")
+=>  #P"BOBBY::SYS$DISK:[PUBLIC.GAMES]CHESS.DB" 
+
+ ;; Implementation C -- an implementation with simultaneous access to
+ ;;  multiple file systems from the same Lisp image.  In this 
+ ;;  implementation, there is a convention that any text preceding the
+ ;;  first colon in a pathname namestring is a host name.
+ (dolist (case '(:common :local))
+   (dolist (host '("MY-LISPM" "MY-VAX" "MY-UNIX"))
+     (print (make-pathname :host host :case case
+                           :directory '(:absolute "PUBLIC" "GAMES")
+                           :name "CHESS" :type "DB"))))
+>>  #P"MY-LISPM:>public>games>chess.db"
+>>  #P"MY-VAX:SYS$DISK:[PUBLIC.GAMES]CHESS.DB"
+>>  #P"MY-UNIX:/public/games/chess.db"
+>>  #P"MY-LISPM:>public>games>chess.db" 
+>>  #P"MY-VAX:SYS$DISK:[PUBLIC.GAMES]CHESS.DB" 
+>>  #P"MY-UNIX:/PUBLIC/GAMES/CHESS.DB" 
+=>  NIL
+
+

+

Affected By:

+

+The file system.

+

Exceptional Situations: None. +

+

See Also:

+

+ merge-pathnames, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+Portable programs should not supply :unspecific for any component. See Section 19.2.2.2.3 (:UNSPECIFIC as a Component Value).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_rnd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_rnd.htm new file mode 100644 index 00000000..68299a3d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_rnd.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function MAKE-RANDOM-STATE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-RANDOM-STATE

+

Syntax:

+

+ +make-random-state &optional state => new-state

+

+

Arguments and Values:

+

+state---a random state, or nil, or t. The default is nil.

+new-state---a random state object.

+

Description:

+

+Creates a fresh object of type random-state suitable for use as the value of *random-state*.

+If state is a random state object, the new-state is a copy[5] of that object. If state is nil, the new-state is a copy[5] of the current random state. If state is t, the new-state is a fresh random state object that has been randomly initialized by some means.

+

Examples:

+

+

+ (let* ((rs1 (make-random-state nil))
+        (rs2 (make-random-state t))
+        (rs3 (make-random-state rs2))
+        (rs4 nil))
+   (list (loop for i from 1 to 10 
+               collect (random 100)
+               when (= i 5)
+                do (setq rs4 (make-random-state)))
+         (loop for i from 1 to 10 collect (random 100 rs1))
+         (loop for i from 1 to 10 collect (random 100 rs2))
+         (loop for i from 1 to 10 collect (random 100 rs3))
+         (loop for i from 1 to 10 collect (random 100 rs4))))
+=>  ((29 25 72 57 55 68 24 35 54 65)
+    (29 25 72 57 55 68 24 35 54 65)
+    (93 85 53 99 58 62 2 23 23 59)
+    (93 85 53 99 58 62 2 23 23 59)
+    (68 24 35 54 65 54 55 50 59 49))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if state is not a random state, or nil, or t.

+

See Also:

+

+random, *random-state*

+

Notes:

+

+One important use of make-random-state is to allow the same series of pseudo-random numbers to be generated many times within a single program.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_1.htm new file mode 100644 index 00000000..6c4651f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_1.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function MAKE-STRING-INPUT-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-STRING-INPUT-STREAM

+

Syntax:

+

+ +make-string-input-stream string &optional start end => string-stream

+

+

Arguments and Values:

+

+string---a string.

+ start, end---bounding index designators of string. The defaults for start and end are 0 and nil, respectively.

+ string-stream---an input string stream.

+

Description:

+

+Returns an input string stream. This stream will supply, in order, the characters in the substring of string bounded by start and end. After the last character has been supplied, the string stream will then be at end of file.

+

Examples:

+

+

+ (let ((string-stream (make-string-input-stream "1 one ")))
+   (list (read string-stream nil nil)
+         (read string-stream nil nil)
+         (read string-stream nil nil)))
+=>  (1 ONE NIL)
+
+ (read (make-string-input-stream "prefixtargetsuffix" 6 12)) =>  TARGET
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+with-input-from-string

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_2.htm new file mode 100644 index 00000000..866bc55e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_s_2.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function MAKE-STRING-OUTPUT-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-STRING-OUTPUT-STREAM

+

Syntax:

+

+ +make-string-output-stream &key element-type => string-stream

+

+

Arguments and Values:

+

+ element-type---a type specifier. The default is character.

+ string-stream---an output string stream.

+

Description:

+

+Returns an output string stream that accepts characters and makes available (via get-output-stream-string) a string that contains the characters that were actually output.

+The element-type names the type of the elements of the string; a string is constructed of the most specialized type that can accommodate elements of that element-type.

+

Examples:

+

+

+ (let ((s (make-string-output-stream)))
+   (write-string "testing... " s)
+   (prin1 1234 s)
+   (get-output-stream-string s))
+=>  "testing... 1234"
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

+

See Also:

+

+get-output-stream-string, with-output-to-string

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_seq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_seq.htm new file mode 100644 index 00000000..27e4d360 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_seq.htm @@ -0,0 +1,76 @@ + + + +CLHS: Function MAKE-SEQUENCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-SEQUENCE

+

Syntax:

+

+ +make-sequence result-type size &key initial-element => sequence

+

+

Arguments and Values:

+

+ result-type---a sequence type specifier.

+ size---a non-negative integer.

+initial-element---an object. The default is implementation-dependent.

+sequence---a proper sequence.

+

Description:

+

+Returns a sequence of the type result-type and of length size, each of the elements of which has been initialized to initial-element.

+ If the result-type is a subtype of list, the result will be a list.

+If the result-type is a subtype of vector, then if the implementation can determine the element type specified for the result-type, the element type of the resulting array is the result of upgrading that element type; or, if the implementation can determine that the element type is unspecified (or *), the element type of the resulting array is t; otherwise, an error is signaled.

+

Examples:

+

+

+ (make-sequence 'list 0) =>  ()
+ (make-sequence 'string 26 :initial-element #\.) 
+=>  ".........................."
+ (make-sequence '(vector double-float) 2
+                :initial-element 1d0)
+=>  #(1.0d0 1.0d0)
+
+

+ +

+ (make-sequence '(vector * 2) 3) should signal an error
+ (make-sequence '(vector * 4) 3) should signal an error
+
+

+

Affected By:

+

+The implementation.

+

Exceptional Situations:

+

+The consequences are unspecified if initial-element is not an object which can be stored in the resulting sequence.

+ An error of type type-error must be signaled if the result-type is neither a recognizable subtype of list, nor a recognizable subtype of vector.

+ An error of type type-error should be signaled if result-type specifies the number of elements and size is different from that number.

+

See Also:

+

+make-array, make-list

+

Notes:

+ +

+ (make-sequence 'string 5) ==  (make-string 5)               
+
+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_stg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_stg.htm new file mode 100644 index 00000000..27e1b38b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_stg.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function MAKE-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-STRING

+

Syntax:

+

+ +make-string size &key initial-element element-type => string

+

+

Arguments and Values:

+

+ size---a valid array dimension.

+ initial-element---a character. The default is implementation-dependent.

+ element-type---a type specifier. The default is character.

+string---a simple string.

+

Description:

+

+make-string returns a simple string of length size whose elements have been initialized to initial-element.

+ The element-type names the type of the elements of the string; a string is constructed of the most specialized type that can accommodate elements of the given type.

+

Examples:

+

+

+ (make-string 10 :initial-element #\5) =>  "5555555555"
+ (length (make-string 10)) =>  10
+
+

+

Affected By:

+

+The implementation.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_sym.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_sym.htm new file mode 100644 index 00000000..4adc1181 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_sym.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function MAKE-SYMBOL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-SYMBOL

+

Syntax:

+

+ +make-symbol name => new-symbol

+

+

Arguments and Values:

+

+name---a string.

+new-symbol---a fresh, uninterned symbol.

+

Description:

+

+make-symbol creates and returns a fresh, uninterned symbol whose name is the given name. The new-symbol is neither bound nor fbound and has a null property list.

+It is implementation-dependent whether the string that becomes the new-symbol's name is the given name or a copy of it. Once a string has been given as the name argument to make-symbol, the consequences are undefined if a subsequent attempt is made to alter that string.

+

Examples:

+

+

+ (setq temp-string "temp") =>  "temp"
+ (setq temp-symbol (make-symbol temp-string)) =>  #:|temp|
+ (symbol-name temp-symbol) =>  "temp"
+ (eq (symbol-name temp-symbol) temp-string) =>  implementation-dependent
+ (find-symbol "temp") =>  NIL, NIL
+ (eq (make-symbol temp-string) (make-symbol temp-string)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if name is not a string.

+

See Also:

+

+copy-symbol

+

Notes:

+

+No attempt is made by make-symbol to convert the case of the name to uppercase. The only case conversion which ever occurs for symbols is done by the Lisp reader. The program interface to symbol creation retains case, and the program interface to interning symbols is case-sensitive.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_syn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_syn.htm new file mode 100644 index 00000000..37763c8a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_syn.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function MAKE-SYNONYM-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-SYNONYM-STREAM

+

Syntax:

+

+ +make-synonym-stream symbol => synonym-stream

+

+

Arguments and Values:

+

+symbol---a symbol that names a dynamic variable.

+ synonym-stream---a synonym stream.

+

Description:

+

+Returns a synonym stream whose synonym stream symbol is symbol.

+

Examples:

+

+

+ (setq a-stream (make-string-input-stream "a-stream")
+        b-stream (make-string-input-stream "b-stream"))
+=>  #<String Input Stream> 
+ (setq s-stream (make-synonym-stream 'c-stream))
+=>  #<SYNONYM-STREAM for C-STREAM> 
+ (setq c-stream a-stream)
+=>  #<String Input Stream> 
+ (read s-stream) =>  A-STREAM
+ (setq c-stream b-stream)
+=>  #<String Input Stream> 
+ (read s-stream) =>  B-STREAM
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its argument is not a symbol.

+

See Also:

+

+Section 21.1 (Stream Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_two.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_two.htm new file mode 100644 index 00000000..20a604db --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mk_two.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function MAKE-TWO-WAY-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MAKE-TWO-WAY-STREAM

+

Syntax:

+

+ +make-two-way-stream input-stream output-stream => two-way-stream

+

+

Arguments and Values:

+

+input-stream---a stream.

+output-stream---a stream.

+ two-way-stream---a two-way stream.

+

Description:

+

+Returns a two-way stream that gets its input from input-stream and sends its output to output-stream.

+

Examples:

+

+

+ (with-output-to-string (out)
+    (with-input-from-string (in "input...")
+      (let ((two (make-two-way-stream in out)))
+        (format two "output...")
+        (setq what-is-read (read two))))) =>  "output..."
+ what-is-read =>  INPUT... 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if input-stream is not an input stream. Should signal an error of type type-error if output-stream is not an output stream.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mod_r.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mod_r.htm new file mode 100644 index 00000000..96e44487 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_mod_r.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function MOD, REM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function MOD, REM

+

Syntax:

+

+ +mod number divisor => modulus

+ +rem number divisor => remainder

+

+

Arguments and Values:

+

+number---a real.

+divisor---a real.

+modulus, remainder---a real.

+

Description:

+

+mod and rem are generalizations of the modulus and remainder functions respectively.

+mod performs the operation floor on number and divisor and returns the remainder of the floor operation.

+rem performs the operation truncate on number and divisor and returns the remainder of the truncate operation.

+mod and rem are the modulus and remainder functions when number and divisor are integers.

+

Examples:

+ +

+ (rem -1 5) =>  -1
+ (mod -1 5) =>  4
+ (mod 13 4) =>  1
+ (rem 13 4) =>  1
+ (mod -13 4) =>  3
+ (rem -13 4) =>  -1
+ (mod 13 -4) =>  -3
+ (rem 13 -4) =>  1
+ (mod -13 -4) =>  -1
+ (rem -13 -4) =>  -1
+ (mod 13.4 1) =>  0.4
+ (rem 13.4 1) =>  0.4
+ (mod -13.4 1) =>  0.6
+ (rem -13.4 1) =>  -0.4
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+floor, truncate

+

Notes:

+

+The result of mod is either zero or a real with the same sign as divisor.

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_name_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_name_c.htm new file mode 100644 index 00000000..36608766 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_name_c.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function NAME-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NAME-CHAR

+

Syntax:

+

+ +name-char name => char-p

+

+

Arguments and Values:

+

+name---a string designator.

+char-p---a character or nil.

+

Description:

+

+Returns the character object whose name is name (as determined by string-equal---i.e., lookup is not case sensitive). If such a character does not exist, nil is returned.

+

Examples:

+

+

+(name-char 'space) =>  #\Space
+(name-char "space") =>  #\Space
+(name-char "Space") =>  #\Space
+(let ((x (char-name #\a)))
+  (or (not x) (eql (name-char x) #\a))) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if name is not a string designator.

+

See Also:

+

+char-name

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_namest.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_namest.htm new file mode 100644 index 00000000..0ee17125 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_namest.htm @@ -0,0 +1,115 @@ + + + +CLHS: Function NAMESTRING, FILE-NAMESTRING... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING

+

Syntax:

+

+ +namestring pathname => namestring

+

+ +file-namestring pathname => namestring

+ +directory-namestring pathname => namestring

+ +host-namestring pathname => namestring

+

+ +enough-namestring pathname &optional defaults => namestring

+

+

Arguments and Values:

+

+ pathname---a pathname designator.

+ defaults---a pathname designator. The default is the value of *default-pathname-defaults*.

+namestring---a string or nil.

Description:

+

+

+These functions convert pathname into a namestring. The name represented by pathname is returned as a namestring in an implementation-dependent canonical form.

+namestring returns the full form of pathname.

+file-namestring returns just the name, type, and version components of pathname.

+directory-namestring returns the directory name portion.

+host-namestring returns the host name.

+enough-namestring returns an abbreviated namestring that is just sufficient to identify the file named by pathname when considered relative to the defaults. It is required that

+

+ (merge-pathnames (enough-namestring pathname defaults) defaults)
+==  (merge-pathnames (parse-namestring pathname nil defaults) defaults)
+
+ in all cases, and the result of enough-namestring is the shortest reasonable string that will satisfy this criterion.

+It is not necessarily possible to construct a valid namestring by concatenating some of the three shorter namestrings in some order.

+

Examples:

+

+

+ (namestring "getty")            
+=>  "getty"
+ (setq q (make-pathname :host "kathy" 
+                         :directory 
+                           (pathname-directory *default-pathname-defaults*)
+                         :name "getty")) 
+=>  #S(PATHNAME :HOST "kathy" :DEVICE NIL :DIRECTORY directory-name 
+       :NAME "getty" :TYPE NIL :VERSION NIL)
+ (file-namestring q) =>  "getty"
+ (directory-namestring q) =>  directory-name
+ (host-namestring q) =>  "kathy" 
+
+ +
+ ;;;Using Unix syntax and the wildcard conventions used by the
+ ;;;particular version of Unix on which this example was created:
+ (namestring
+   (translate-pathname "/usr/dmr/hacks/frob.l"
+                       "/usr/d*/hacks/*.l"
+                       "/usr/d*/backup/hacks/backup-*.*"))
+=>  "/usr/dmr/backup/hacks/backup-frob.l"
+ (namestring
+   (translate-pathname "/usr/dmr/hacks/frob.l"
+                       "/usr/d*/hacks/fr*.l"
+                       "/usr/d*/backup/hacks/backup-*.*"))
+=>  "/usr/dmr/backup/hacks/backup-ob.l"
+ 
+ ;;;This is similar to the above example but uses two different hosts,
+ ;;;U: which is a Unix and V: which is a VMS.  Note the translation
+ ;;;of file type and alphabetic case conventions.
+ (namestring
+   (translate-pathname "U:/usr/dmr/hacks/frob.l"
+                       "U:/usr/d*/hacks/*.l"
+                       "V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
+=>  "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-FROB.LSP"
+ (namestring
+   (translate-pathname "U:/usr/dmr/hacks/frob.l"
+                       "U:/usr/d*/hacks/fr*.l"
+                       "V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
+=>  "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-OB.LSP"
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ truename, merge-pathnames, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nconc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nconc.htm new file mode 100644 index 00000000..6937a786 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nconc.htm @@ -0,0 +1,89 @@ + + + +CLHS: Function NCONC + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NCONC

+

Syntax:

+

+ +nconc &rest lists => concatenated-list

+

+

Arguments and Values:

+

+ list---each but the last must be a list (which might be a dotted list but must not be a circular list); the last list may be any object.

+concatenated-list---a list.

+

Description:

+

+Returns a list that is the concatenation of lists. If no lists are supplied, (nconc) returns nil. nconc is defined using the following recursive relationship:

+

+ (nconc) =>  ()
+ (nconc nil . lists) ==  (nconc . lists)
+ (nconc list) =>  list
+ (nconc list-1 list-2) ==  (progn (rplacd (last list-1) list-2) list-1)
+ (nconc list-1 list-2 . lists) ==  (nconc (nconc list-1 list-2) . lists)
+
+

+

Examples:

+

+

+ (nconc) =>  NIL
+ (setq x '(a b c)) =>  (A B C)
+ (setq y '(d e f)) =>  (D E F)
+ (nconc x y) =>  (A B C D E F)
+ x =>  (A B C D E F)
+
+ Note, in the example, that the value of x is now different, since its last cons has been rplacd'd to the value of y. If (nconc x y) were evaluated again, it would yield a piece of a circular list, whose printed representation would be (A B C D E F D E F D E F ...), repeating forever; if the *print-circle* switch were non-nil, it would be printed as (A B C . #1=(D E F . #1#)).

+ +

+ (setq foo (list 'a 'b 'c 'd 'e)
+       bar (list 'f 'g 'h 'i 'j)
+       baz (list 'k 'l 'm)) =>  (K L M)
+ (setq foo (nconc foo bar baz)) =>  (A B C D E F G H I J K L M)
+ foo =>  (A B C D E F G H I J K L M)
+ bar =>  (F G H I J K L M)
+ baz =>  (K L M)
+
+ (setq foo (list 'a 'b 'c 'd 'e)
+       bar (list 'f 'g 'h 'i 'j)
+       baz (list 'k 'l 'm)) =>  (K L M)
+ (setq foo (nconc nil foo bar nil baz)) =>  (A B C D E F G H I J K L M) 
+ foo =>  (A B C D E F G H I J K L M)
+ bar =>  (F G H I J K L M)
+ baz =>  (K L M)
+
+

+

+

Side Effects:

+

+The lists are modified rather than copied.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+append, concatenate

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_next_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_next_m.htm new file mode 100644 index 00000000..c3fa4495 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_next_m.htm @@ -0,0 +1,51 @@ + + + +CLHS: Local Function NEXT-METHOD-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Local Function NEXT-METHOD-P

+

Syntax:

+

+ +next-method-p <no arguments> => generalized-boolean

+

+

Arguments and Values:

+

+generalized-boolean---a generalized boolean.

+

Description:

+

+The locally defined function next-method-p can be used within the body forms (but not the lambda list) defined by a method-defining form to determine whether a next method exists.

+The function next-method-p has lexical scope and indefinite extent.

+ Whether or not next-method-p is fbound in the global environment is implementation-dependent; however, the restrictions on redefinition and shadowing of next-method-p are the same as for symbols in the COMMON-LISP package which are fbound in the global environment. The consequences of attempting to use next-method-p outside of a method-defining form are undefined.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+call-next-method, defmethod, call-method

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_app.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_app.htm new file mode 100644 index 00000000..59c9346e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_app.htm @@ -0,0 +1,57 @@ + + + +CLHS: Standard Generic Function NO-APPLICABLE-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function NO-APPLICABLE-METHOD

+

Syntax:

+

+ +no-applicable-method generic-function &rest function-arguments => result*

+

+

Method Signatures:

+

+ +no-applicable-method (generic-function t) &rest function-arguments

+

+

Arguments and Values:

+

+generic-function---a generic function on which no applicable method was found.

+function-arguments---arguments to the generic-function.

+result---an object.

+

Description:

+

+The generic function no-applicable-method is called when a generic function is invoked and no method on that generic function is applicable. The default method signals an error.

+The generic function no-applicable-method is not intended to be called by programmers. Programmers may write methods for it.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The default method signals an error of type error.

+

See Also:

+

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_nex.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_nex.htm new file mode 100644 index 00000000..4a7f19a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_no_nex.htm @@ -0,0 +1,59 @@ + + + +CLHS: Standard Generic Function NO-NEXT-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function NO-NEXT-METHOD

+

Syntax:

+

+ +no-next-method generic-function method &rest args => result*

+

+

Method Signatures:

+

+ +no-next-method (generic-function standard-generic-function) (method standard-method) &rest args

+

+

Arguments and Values:

+

+generic-function -- generic function to which method belongs.

+method -- method that contained the call to call-next-method for which there is no next method.

+args -- arguments to call-next-method.

+result---an object.

+

Description:

+

+The generic function no-next-method is called by call-next-method when there is no next method.

+The generic function no-next-method is not intended to be called by programmers. Programmers may write methods for it.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The system-supplied method on no-next-method signals an error of type error.

+

See Also:

+

+call-next-method

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_not.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_not.htm new file mode 100644 index 00000000..d9d30b2c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_not.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NOT

+

+

Syntax:

+

+ +not x => boolean

+

+

Arguments and Values:

+

+x---a generalized boolean (i.e., any object).

+boolean---a boolean.

+

Description:

+

+Returns t if x is false; otherwise, returns nil.

+

Examples:

+

+

+ (not nil) =>  T
+ (not '()) =>  T
+ (not (integerp 'sss)) =>  T
+ (not (integerp 1)) =>  NIL
+ (not 3.7) =>  NIL
+ (not 'apple) =>  NIL
+
+

+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+null

+

Notes:

+

+not is intended to be used to invert the `truth value' of a boolean (or generalized boolean) whereas null is intended to be used to test for the empty list. Operationally, not and null compute the same result; which to use is a matter of style.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nth.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nth.htm new file mode 100644 index 00000000..0fed7330 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nth.htm @@ -0,0 +1,74 @@ + + + +CLHS: Accessor NTH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor NTH

+

Syntax:

+

+ +nth n list => object

+ +(setf (nth n list) new-object)

+

+

Arguments and Values:

+

+n---a non-negative integer.

+list---a list, which might be a dotted list or a circular list.

+object---an object.

+new-object---an object.

+

Description:

+

+nth locates the nth element of list, where the car of the list is the ``zeroth'' element. Specifically,

+

+ (nth n list) ==  (car (nthcdr n list))
+
+

+nth may be used to specify a place to setf. Specifically,

+

+ (setf (nth n list) new-object) ==  (setf (car (nthcdr n list)) new-object)
+
+

+

Examples:

+

+

+ (nth 0 '(foo bar baz)) =>  FOO
+ (nth 1 '(foo bar baz)) =>  BAR
+ (nth 3 '(foo bar baz)) =>  NIL
+ (setq 0-to-3 (list 0 1 2 3)) =>  (0 1 2 3)
+ (setf (nth 2 0-to-3) "two") =>  "two"
+ 0-to-3 =>  (0 1 "two" 3)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+elt, first, nthcdr

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nthcdr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nthcdr.htm new file mode 100644 index 00000000..c0dd03cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nthcdr.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function NTHCDR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NTHCDR

+

Syntax:

+

+ +nthcdr n list => tail

+

+

Arguments and Values:

+

+ n---a non-negative integer.

+list---a list, which might be a dotted list or a circular list.

+tail---an object.

+

Description:

+

+Returns the tail of list that would be obtained by calling cdr n times in succession.

+

Examples:

+

+

+ (nthcdr 0 '()) =>  NIL
+ (nthcdr 3 '()) =>  NIL
+ (nthcdr 0 '(a b c)) =>  (A B C)
+ (nthcdr 2 '(a b c)) =>  (C)
+ (nthcdr 4 '(a b c)) =>  ()
+ (nthcdr 1 '(0 . 1)) =>  1
+
+ (locally (declare (optimize (safety 3)))
+   (nthcdr 3 '(0 . 1)))
+ Error: Attempted to take CDR of 1.
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if n is not a non-negative integer.

+For n being an integer greater than 1, the error checking done by (nthcdr n list) is the same as for (nthcdr (- n 1) (cdr list)); see the function cdr.

+

See Also:

+

+cdr, nth, rest

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_null.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_null.htm new file mode 100644 index 00000000..5e39553f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_null.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function NULL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NULL

+

+

Syntax:

+

+ +null object => boolean

+

+

Arguments and Values:

+

+object---an object.

+boolean---a boolean.

+

Description:

+

+Returns t if object is the empty list; otherwise, returns nil.

+

Examples:

+

+

+ (null '()) =>  T
+ (null nil) =>  T
+ (null t) =>  NIL
+ (null 1) =>  NIL
+
+

+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+not

+

Notes:

+

+null is intended to be used to test for the empty list whereas not is intended to be used to invert a boolean (or generalized boolean). Operationally, null and not compute the same result; which to use is a matter of style.

+

+ (null object) ==  (typep object 'null) ==  (eq object '())
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_numera.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_numera.htm new file mode 100644 index 00000000..ed16a70a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_numera.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function NUMERATOR, DENOMINATOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NUMERATOR, DENOMINATOR

+

Syntax:

+

+ +numerator rational => numerator

+ +denominator rational => denominator

+

+

Arguments and Values:

+

+rational---a rational.

+numerator---an integer.

+denominator---a positive integer.

+

Description:

+

+numerator and denominator reduce rational to canonical form and compute the numerator or denominator of that number.

+numerator and denominator return the numerator or denominator of the canonical form of rational.

+If rational is an integer, numerator returns rational and denominator returns 1.

+

Examples:

+ +

+ (numerator 1/2) =>  1
+ (denominator 12/36) =>  3
+ (numerator -1) =>  -1
+ (denominator (/ -33)) =>  33
+ (numerator (/ 8 -6)) =>  -4
+ (denominator (/ 8 -6)) =>  3
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+/

+

Notes:

+ +

+ (gcd (numerator x) (denominator x)) =>  1
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nump.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nump.htm new file mode 100644 index 00000000..b97e1749 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_nump.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function NUMBERP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function NUMBERP

+

Syntax:

+

+ +numberp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type number; otherwise, returns false.

+

Examples:

+

+

+ (numberp 12) =>  true
+ (numberp (expt 2 130)) =>  true
+ (numberp #c(5/3 7.2)) =>  true
+ (numberp nil) =>  false
+ (numberp (cons 1 2)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (numberp object) ==  (typep object 'number)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open.htm new file mode 100644 index 00000000..9e3b233a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open.htm @@ -0,0 +1,135 @@ + + + +CLHS: Function OPEN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function OPEN

+

Syntax:

+

+ +open filespec &key direction element-type if-exists if-does-not-exist external-format

=> stream

+

+

Arguments and Values:

+

+filespec---a pathname designator.

+direction---one of :input, :output, :io, or :probe. The default is :input.

+element-type---a type specifier for recognizable subtype of character; or a type specifier for a finite recognizable subtype of integer; or one of the symbols signed-byte, unsigned-byte, or :default. The default is character.

+if-exists---one of :error, :new-version, :rename, :rename-and-delete, :overwrite, :append, :supersede, or nil. The default is :new-version if the version component of filespec is :newest, or :error otherwise.

+if-does-not-exist---one of :error, :create, or nil. The default is :error if direction is :input or if-exists is :overwrite or :append; :create if direction is :output or :io, and if-exists is neither :overwrite nor :append; or nil when direction is :probe.

+ external-format---an external file format designator. The default is :default.

+ stream---a file stream or nil.

+

Description:

+

+open creates, opens, and returns a file stream that is connected to the file specified by filespec. Filespec is the name of the file to be opened. If the filespec designator is a stream, that stream is not closed first or otherwise affected.

+The keyword arguments to open specify the characteristics of the file stream that is returned, and how to handle errors.

+If direction is :input or :probe, or if if-exists is not :new-version and the version component of the filespec is :newest, then the file opened is that file already existing in the file system that has a version greater than that of any other file in the file system whose other pathname components are the same as those of filespec.

+An implementation is required to recognize all of the open keyword options and to do something reasonable in the context of the host operating system. For example, if a file system does not support distinct file versions and does not distinguish the notions of deletion and expunging, :new-version might be treated the same as :rename or :supersede, and :rename-and-delete might be treated the same as :supersede.

+

+

:direction

+These are the possible values for direction, and how they affect the nature of the stream that is created:

+

:input

+Causes the creation of an input file stream.

+

:output

+Causes the creation of an output file stream.

+

:io

+Causes the creation of a bidirectional file stream.

+

:probe

+Causes the creation of a ``no-directional'' file stream; in effect, the file stream is created and then closed prior to being returned by open.

+

+

:element-type

+The element-type specifies the unit of transaction for the file stream. If it is :default, the unit is determined by file system, possibly based on the file.

+

:if-exists

+if-exists specifies the action to be taken if direction is :output or :io and a file of the name filespec already exists. If direction is :input, not supplied, or :probe, if-exists is ignored. These are the results of open as modified by if-exists:

+

+

:error

+An error of type file-error is signaled.

+

:new-version

+A new file is created with a larger version number.

+

:rename

+The existing file is renamed to some other name and then a new file is created.

+

:rename-and-delete

+The existing file is renamed to some other name, then it is deleted but not expunged, and then a new file is created.

+

:overwrite

+Output operations on the stream destructively modify the existing file. If direction is :io the file is opened in a bidirectional mode that allows both reading and writing. The file pointer is initially positioned at the beginning of the file; however, the file is not truncated back to length zero when it is opened.

+

:append

+Output operations on the stream destructively modify the existing file. The file pointer is initially positioned at the end of the file.

+If direction is :io, the file is opened in a bidirectional mode that allows both reading and writing.

+

:supersede

+The existing file is superseded; that is, a new file with the same name as the old one is created. If possible, the implementation should not destroy the old file until the new stream is closed.

+

nil

+No file or stream is created; instead, nil is returned to indicate failure.

+

+

:if-does-not-exist

+if-does-not-exist specifies the action to be taken if a file of name filespec does not already exist. These are the results of open as modified by if-does-not-exist:

+

+

:error

+An error of type file-error is signaled.

+

:create

+An empty file is created. Processing continues as if the file had already existed but no processing as directed by if-exists is performed.

+

nil

+No file or stream is created; instead, nil is returned to indicate failure.

+

+

:external-format

+This option selects an external file format for the file: The only standardized value for this option is :default, although implementations are permitted to define additional external file formats and implementation-dependent values returned by stream-external-format can also be used by conforming programs.

+The external-format is meaningful for any kind of file stream whose element type is a subtype of character. This option is ignored for streams for which it is not meaningful; however, implementations may define other element types for which it is meaningful. The consequences are unspecified if a character is written that cannot be represented by the given external file format.

+

+When a file is opened, a file stream is constructed to serve as the file system's ambassador to the Lisp environment; operations on the file stream are reflected by operations on the file in the file system.

+A file can be deleted, renamed, or destructively modified by open.

+For information about opening relative pathnames, see Section 19.2.3 (Merging Pathnames).

+

Examples:

+

+

+ (open filespec :direction :probe)  =>  #<Closed Probe File Stream...>
+ (setq q (merge-pathnames (user-homedir-pathname) "test"))
+=>  #<PATHNAME :HOST NIL :DEVICE device-name :DIRECTORY directory-name
+    :NAME "test" :TYPE NIL :VERSION :NEWEST>
+ (open filespec :if-does-not-exist :create) =>  #<Input File Stream...>
+ (setq s (open filespec :direction :probe)) =>  #<Closed Probe File Stream...>
+ (truename s) =>  #<PATHNAME :HOST NIL :DEVICE device-name :DIRECTORY
+    directory-name :NAME filespec :TYPE extension :VERSION 1>
+ (open s :direction :output :if-exists nil) =>  NIL 
+
+

+

Affected By:

+

+The nature and state of the host computer's file system.

+

Exceptional Situations:

+

+If if-exists is :error, (subject to the constraints on the meaning of if-exists listed above), an error of type file-error is signaled.

+If if-does-not-exist is :error (subject to the constraints on the meaning of if-does-not-exist listed above), an error of type file-error is signaled.

+If it is impossible for an implementation to handle some option in a manner close to what is specified here, an error of type error might be signaled.

+ An error of type file-error is signaled if (wild-pathname-p filespec) returns true.

+ An error of type error is signaled if the external-format is not understood by the implementation.

+The various file systems in existence today have widely differing capabilities, and some aspects of the file system are beyond the scope of this specification to define. A given implementation might not be able to support all of these options in exactly the manner stated. An implementation is required to recognize all of these option keywords and to try to do something ``reasonable'' in the context of the host file system. Where necessary to accomodate the file system, an implementation deviate slightly from the semantics specified here without being disqualified for consideration as a conforming implementation. If it is utterly impossible for an implementation to handle some option in a manner similar to what is specified here, it may simply signal an error.

+With regard to the :element-type option, if a type is requested that is not supported by the file system, a substitution of types such as that which goes on in upgrading is permissible. As a minimum requirement, it should be the case that opening an output stream to a file in a given element type and later opening an input stream to the same file in the same element type should work compatibly.

+

See Also:

+

+ with-open-file, close, pathname, logical-pathname, Section 19.2.3 (Merging Pathnames), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+

+open does not automatically close the file when an abnormal exit occurs.

+When element-type is a subtype of character, read-char and/or write-char can be used on the resulting file stream.

+When element-type is a subtype of integer, read-byte and/or write-byte can be used on the resulting file stream.

+When element-type is :default, the type can be determined by using stream-element-type.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open_s.htm new file mode 100644 index 00000000..870c9f9e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_open_s.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function OPEN-STREAM-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function OPEN-STREAM-P

+

+

Syntax:

+

+ +open-stream-p stream => generalized-boolean

+

+

Arguments and Values:

+

+stream---a stream.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if stream is an open stream; otherwise, returns false.

+Streams are open until they have been explicitly closed with close, or until they are implicitly closed due to exit from a with-output-to-string, with-open-file, with-input-from-string, or with-open-stream form.

+

Examples:

+

+

+ (open-stream-p *standard-input*) =>  true
+
+

+

Side Effects: None. +

+

Affected By:

+

+close.

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream.

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_opsetf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_opsetf.htm new file mode 100644 index 00000000..0e2c27b8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_opsetf.htm @@ -0,0 +1,55 @@ + + + +CLHS: Standard Generic Function (SETF CLASS-NAME) + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function (SETF CLASS-NAME)

+

Syntax:

+

+ +(setf class-name) new-value class => new-value

+

+

Method Signatures:

+

+ +(setf class-name) new-value (class class)

+

+

Arguments and Values:

+

+new-value---a symbol.

+class---a class.

+

Description:

+

+The generic function (setf class-name) sets the name of a class object.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+find-class, proper name, Section 4.3 (Classes)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pairli.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pairli.htm new file mode 100644 index 00000000..eef157ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pairli.htm @@ -0,0 +1,78 @@ + + + +CLHS: Function PAIRLIS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PAIRLIS

+

Syntax:

+

+ +pairlis keys data &optional alist => new-alist

+

+

Arguments and Values:

+

+keys---a proper list.

+data---a proper list.

+alist---an association list. The default is the empty list.

+new-alist---an association list.

+

Description:

+

+Returns an association list that associates elements of keys to corresponding elements of data. The consequences are undefined if keys and data are not of the same length.

+If alist is supplied, pairlis returns a modified alist with the new pairs prepended to it. The new pairs may appear in the resulting association list in either forward or backward order. The result of

+

+ (pairlis '(one two) '(1 2) '((three . 3) (four . 19)))
+
+ might be

+

+ ((one . 1) (two . 2) (three . 3) (four . 19))
+
+ or

+

+ ((two . 2) (one . 1) (three . 3) (four . 19))
+
+

+

Examples:

+ +

+ (setq keys '(1 2 3)
+        data '("one" "two" "three")
+        alist '((4 . "four"))) =>  ((4 . "four"))
+ (pairlis keys data) =>  ((3 . "three") (2 . "two") (1 . "one"))
+ (pairlis keys data alist)
+=>  ((3 . "three") (2 . "two") (1 . "one") (4 . "four"))
+ alist =>  ((4 . "four"))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if keys and data are not proper lists.

+

See Also:

+

+acons

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pars_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pars_1.htm new file mode 100644 index 00000000..fd7e63c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pars_1.htm @@ -0,0 +1,95 @@ + + + +CLHS: Function PARSE-NAMESTRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PARSE-NAMESTRING

+

Syntax:

+

+ +parse-namestring thing &optional host default-pathname &key start end junk-allowed

=> pathname, position

+

+

Arguments and Values:

+

+ thing---a string, a pathname, or a stream associated with a file.

+ host---a valid pathname host, a logical host, or nil.

+default-pathname---a pathname designator. The default is the value of *default-pathname-defaults*.

+ start, end---bounding index designators of thing. The defaults for start and end are 0 and nil, respectively.

+junk-allowed---a generalized boolean. The default is false.

+pathname---a pathname, or nil.

+position---a bounding index designator for thing.

+

Description:

+

+Converts thing into a pathname.

+The host supplies a host name with respect to which the parsing occurs.

+ If thing is a stream associated with a file, processing proceeds as if the pathname used to open that file had been supplied instead.

+If thing is a pathname, the host and the host component of thing are compared. If they match, two values are immediately returned: thing and start; otherwise (if they do not match), an error is signaled.

+

+Otherwise (if thing is a string), parse-namestring parses the name of a file within the substring of thing bounded by start and end.

+ If thing is a string then the substring of thing bounded by start and end is parsed into a pathname as follows:

+

+

* If host is a logical host then thing is parsed as a logical pathname namestring on the host.

+
* If host is nil and thing is a syntactically valid logical pathname namestring containing an explicit host, then it is parsed as a logical pathname namestring.

+
* If host is nil, default-pathname is a logical pathname, and thing is a syntactically valid logical pathname namestring without an explicit host, then it is parsed as a logical pathname namestring on the host that is the host component of default-pathname.

+
* Otherwise, the parsing of thing is implementation-defined.

+

+In the first of these cases, the host portion of the logical pathname namestring and its following colon are optional.

+If the host portion of the namestring and host are both present and do not match, an error is signaled.

+If junk-allowed is true, then the primary value is the pathname parsed or, if no syntactically correct pathname was seen, nil. If junk-allowed is false, then the entire substring is scanned, and the primary value is the pathname parsed.

+In either case, the secondary value is the index into thing of the delimiter that terminated the parse, or the index beyond the substring if the parse terminated at the end of the substring (as will always be the case if junk-allowed is false).

+Parsing a null string always succeeds, producing a pathname with all components (except the host) equal to nil.

+If thing contains an explicit host name and no explicit device name, then it is implementation-defined whether parse-namestring will supply the standard default device for that host as the device component of the resulting pathname.

+

Examples:

+

+ +

+ (setq q (parse-namestring "test"))  
+=>  #S(PATHNAME :HOST NIL :DEVICE NIL :DIRECTORY NIL :NAME "test" 
+       :TYPE NIL :VERSION NIL)
+ (pathnamep q) =>  true
+ (parse-namestring "test") 
+=>  #S(PATHNAME :HOST NIL :DEVICE NIL :DIRECTORY NIL :NAME "test"
+       :TYPE NIL :VERSION NIL), 4
+ (setq s (open xxx)) =>  #<Input File Stream...>
+ (parse-namestring s) 
+=>  #S(PATHNAME :HOST NIL :DEVICE NIL :DIRECTORY NIL :NAME xxx 
+       :TYPE NIL :VERSION NIL), 0
+ (parse-namestring "test" nil nil :start 2 :end 4 )
+ =>  #S(PATHNAME ...), 15
+ (parse-namestring "foo.lisp")
+=>  #P"foo.lisp"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If junk-allowed is false, an error of type parse-error is signaled if thing does not consist entirely of the representation of a pathname, possibly surrounded on either side by whitespace[1] characters if that is appropriate to the cultural conventions of the implementation.

+If host is supplied and not nil, and thing contains a manifest host name, an error of type error is signaled if the hosts do not match.

+ If thing is a logical pathname namestring and if the host portion of the namestring and host are both present and do not match, an error of type error is signaled.

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.2.2.2.3 (:UNSPECIFIC as a Component Value), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_parse_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_parse_.htm new file mode 100644 index 00000000..197892f7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_parse_.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function PARSE-INTEGER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PARSE-INTEGER

+

Syntax:

+

+ +parse-integer string &key start end radix junk-allowed => integer, pos

+

+

Arguments and Values:

+

+string---a string.

+ start, end---bounding index designators of string. The defaults for start and end are 0 and nil, respectively.

+radix---a radix. The default is 10.

+junk-allowed---a generalized boolean. The default is false.

+integer---an integer or false.

+pos---a bounding index of string.

+

Description:

+

+parse-integer parses an integer in the specified radix from the substring of string delimited by start and end.

+parse-integer expects an optional sign (+ or -) followed by a a non-empty sequence of digits to be interpreted in the specified radix. Optional leading and trailing whitespace[1] is ignored.

+parse-integer does not recognize the syntactic radix-specifier prefixes #O, #B, #X, and #nR, nor does it recognize a trailing decimal point.

+If junk-allowed is false, an error of type parse-error is signaled if substring does not consist entirely of the representation of a signed integer, possibly surrounded on either side by whitespace[1] characters.

+The first value returned is either the integer that was parsed, or else nil if no syntactically correct integer was seen but junk-allowed was true.

+The second value is either the index into the string of the delimiter that terminated the parse, or the upper bounding index of the substring if the parse terminated at the end of the substring (as is always the case if junk-allowed is false).

+

Examples:

+ +

+ (parse-integer "123") =>  123, 3
+ (parse-integer "123" :start 1 :radix 5) =>  13, 3
+ (parse-integer "no-integer" :junk-allowed t) =>  NIL, 0
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If junk-allowed is false, an error is signaled if substring does not consist entirely of the representation of an integer, possibly surrounded on either side by whitespace[1] characters.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_peek_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_peek_c.htm new file mode 100644 index 00000000..3a638b53 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_peek_c.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function PEEK-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PEEK-CHAR

+

Syntax:

+

+ +peek-char &optional peek-type input-stream eof-error-p eof-value recursive-p => char

+

+

Arguments and Values:

+

+peek-type---a character or t or nil.

+input-stream---input stream designator. The default is standard input.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+recursive-p---a generalized boolean. The default is false.

+char---a character or the eof-value.

+

Description:

+

+peek-char obtains the next character in input-stream without actually reading it, thus leaving the character to be read at a later time. It can also be used to skip over and discard intervening characters in the input-stream until a particular character is found.

+If peek-type is not supplied or nil, peek-char returns the next character to be read from input-stream, without actually removing it from input-stream. The next time input is done from input-stream, the character will still be there. If peek-type is t, then peek-char skips over whitespace[2] characters, but not comments, and then performs the peeking operation on the next character. The last character examined, the one that starts an object, is not removed from input-stream. If peek-type is a character, then peek-char skips over input characters until a character that is char= to that character is found; that character is left in input-stream.

+If an end of file[2] occurs and eof-error-p is false, eof-value is returned.

+ If recursive-p is true, this call is expected to be embedded in a higher-level call to read or a similar function used by the Lisp reader.

+ When input-stream is an echo stream, characters that are only peeked at are not echoed. In the case that peek-type is not nil, the characters that are passed by peek-char are treated as if by read-char, and so are echoed unless they have been marked otherwise by unread-char.

+

Examples:

+ +

+ (with-input-from-string (input-stream "    1 2 3 4 5")
+    (format t "~S ~S ~S" 
+            (peek-char t input-stream)
+            (peek-char #\4 input-stream)
+            (peek-char nil input-stream)))
+>>  #\1 #\4 #\4
+=>  NIL
+
+

+

Affected By:

+

+*readtable*, *standard-input*, *terminal-io*.

+

Exceptional Situations:

+

+If eof-error-p is true and an end of file[2] occurs an error of type end-of-file is signaled.

+If peek-type is a character, an end of file[2] occurs, and eof-error-p is true, an error of type end-of-file is signaled.

+If recursive-p is true and an end of file[2] occurs, an error of type end-of-file is signaled.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_phase.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_phase.htm new file mode 100644 index 00000000..f272588c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_phase.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function PHASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PHASE

+

Syntax:

+

+ +phase number => phase

+

+

Arguments and Values:

+

+number---a number.

+phase---a number.

+

Description:

+

+phase returns the phase of number (the angle part of its polar representation) in radians, in the range -<PI> (exclusive) if minus zero is not supported, or -<PI> (inclusive) if minus zero is supported, to <PI> (inclusive). The phase of a positive real number is zero; that of a negative real number is <PI>. The phase of zero is defined to be zero.

+If number is a complex float, the result is a float of the same type as the components of number. If number is a float, the result is a float of the same type. If number is a rational or a complex rational, the result is a single float.

+The branch cut for phase lies along the negative real axis, continuous with quadrant II. The range consists of that portion of the real axis between -<PI> (exclusive) and <PI> (inclusive).

+ The mathematical definition of phase is as follows:

+(phase x) = (atan (imagpart x) (realpart x))

+

Examples:

+

+

+ (phase 1) =>  0.0s0
+ (phase 0) =>  0.0s0
+ (phase (cis 30)) =>  -1.4159266
+ (phase #c(0 1)) =>  1.5707964
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its argument is not a number. Might signal arithmetic-error.

+

See Also:

+

+Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg__1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg__1.htm new file mode 100644 index 00000000..90a85b8f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg__1.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function PACKAGE-USED-BY-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGE-USED-BY-LIST

+

Syntax:

+

+ +package-used-by-list package => used-by-list

+

+

Arguments and Values:

+

+ package---a package designator.

+used-by-list---a list of package objects.

+

Description:

+

+package-used-by-list returns a list of other packages that use package.

+

Examples:

+

+

+ (package-used-by-list (make-package 'temp)) =>  ()
+ (make-package 'trash :use '(temp)) =>  #<PACKAGE "TRASH">
+ (package-used-by-list 'temp) =>  (#<PACKAGE "TRASH">)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if package is not a package.

+

See Also:

+

+use-package, unuse-package

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_er.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_er.htm new file mode 100644 index 00000000..b09ab20e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_er.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function PACKAGE-ERROR-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGE-ERROR-PACKAGE

+

Syntax:

+

+ +package-error-package condition => package

+

+

Arguments and Values:

+

+condition---a condition of type package-error.

+package---a package designator.

+

Description:

+

+Returns a designator for the offending package in the situation represented by the condition.

+

Examples:

+

+

+ (package-error-package 
+   (make-condition 'package-error
+     :package (find-package "COMMON-LISP")))
+=>  #<Package "COMMON-LISP">
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+package-error

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_na.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_na.htm new file mode 100644 index 00000000..f84cacba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_na.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function PACKAGE-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGE-NAME

+

Syntax:

+

+ +package-name package => name

+

+

Arguments and Values:

+

+ package---a package designator.

+name---a string or nil.

+

Description:

+

+package-name returns the string that names package, or nil if the package designator is a package object that has no name (see the function delete-package).

+

Examples:

+

+

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (package-name *package*) =>  "COMMON-LISP-USER"
+ (package-name (symbol-package :test)) =>  "KEYWORD"
+ (package-name (find-package 'common-lisp)) =>  "COMMON-LISP"
+
+

+ +

+ (defvar *foo-package* (make-package "FOO"))
+ (rename-package "FOO" "FOO0")
+ (package-name *foo-package*) =>  "FOO0"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if package is not a package designator.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_ni.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_ni.htm new file mode 100644 index 00000000..2bd6a8e1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_ni.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function PACKAGE-NICKNAMES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGE-NICKNAMES

+

Syntax:

+

+ +package-nicknames package => nicknames

+

+

Arguments and Values:

+

+ package---a package designator.

+nicknames---a list of strings.

+

Description:

+

+Returns the list of nickname strings for package, not including the name of package.

+

Examples:

+

+

+ (package-nicknames (make-package 'temporary
+                                   :nicknames '("TEMP" "temp")))
+=>  ("temp" "TEMP") 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if package is not a package designator.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_sh.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_sh.htm new file mode 100644 index 00000000..fa83f7f7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_sh.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function PACKAGE-SHADOWING-SYMBOLS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGE-SHADOWING-SYMBOLS

+

Syntax:

+

+ +package-shadowing-symbols package => symbols

+

+

Arguments and Values:

+

+package---a package designator.

+symbols---a list of symbols.

+

Description:

+

+Returns a list of symbols that have been declared as shadowing symbols in package by shadow or shadowing-import (or the equivalent defpackage options). All symbols on this list are present in package.

+

Examples:

+

+

+ (package-shadowing-symbols (make-package 'temp)) =>  ()
+ (shadow 'cdr 'temp) =>  T
+ (package-shadowing-symbols 'temp) =>  (TEMP::CDR)
+ (intern "PILL" 'temp) =>  TEMP::PILL, NIL
+ (shadowing-import 'pill 'temp) =>  T
+ (package-shadowing-symbols 'temp) =>  (PILL TEMP::CDR)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if package is not a package designator.

+

See Also:

+

+shadow, shadowing-import

+

Notes:

+

+Whether the list of symbols is fresh is implementation-dependent.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_us.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_us.htm new file mode 100644 index 00000000..0139837a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkg_us.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function PACKAGE-USE-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGE-USE-LIST

+

Syntax:

+

+ +package-use-list package => use-list

+

+

Arguments and Values:

+

+ package---a package designator.

+use-list---a list of package objects.

+

Description:

+

+Returns a list of other packages used by package.

+

Examples:

+

+

+ (package-use-list (make-package 'temp)) =>  (#<PACKAGE "COMMON-LISP">)
+ (use-package 'common-lisp-user 'temp) =>  T
+ (package-use-list 'temp) =>  (#<PACKAGE "COMMON-LISP"> #<PACKAGE "COMMON-LISP-USER">)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if package is not a package designator.

+

See Also:

+

+use-package, unuse-package

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkgp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkgp.htm new file mode 100644 index 00000000..e96338fa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pkgp.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function PACKAGEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PACKAGEP

+

Syntax:

+

+ +packagep object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type package; otherwise, returns false.

+

Examples:

+ +

+ (packagep *package*) =>  true 
+ (packagep 'common-lisp) =>  false 
+ (packagep (find-package 'common-lisp)) =>  true 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (packagep object) ==  (typep object 'package)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pl.htm new file mode 100644 index 00000000..66a7d6fe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pl.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function + + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function +

+

Syntax:

+

+ ++ &rest numbers => sum

+

+

Arguments and Values:

+

+number---a number.

+sum---a number.

+

Description:

+

+Returns the sum of numbers, performing any necessary type conversions in the process. If no numbers are supplied, 0 is returned.

+

Examples:

+ +

+ (+) =>  0
+ (+ 1) =>  1
+ (+ 31/100 69/100) =>  1
+ (+ 1/5 0.8) =>  1.0
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Might signal type-error if some argument is not a number. Might signal arithmetic-error.

+

See Also:

+

+Section 12.1.1 (Numeric Operations), Section 12.1.3 (Rational Computations), Section 12.1.4 (Floating-point Computations), Section 12.1.5 (Complex Computations)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn.htm new file mode 100644 index 00000000..17b36e5c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn.htm @@ -0,0 +1,89 @@ + + + +CLHS: Function PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PATHNAME

+

Syntax:

+

+ +pathname pathspec => pathname

+

+

Arguments and Values:

+

+ pathspec---a pathname designator.

+pathname---a pathname.

+

Description:

+

+Returns the pathname denoted by pathspec.

+ If the pathspec designator is a stream, the stream can be either open or closed; in both cases, the pathname returned corresponds to the filename used to open the file. pathname returns the same pathname for a file stream after it is closed as it did when it was open.

+ If the pathspec designator is a file stream created by opening a logical pathname, a logical pathname is returned.

+

Examples:

+

+

+ ;; There is a great degree of variability permitted here.  The next
+ ;; several examples are intended to illustrate just a few of the many
+ ;; possibilities.  Whether the name is canonicalized to a particular
+ ;; case (either upper or lower) depends on both the file system and the
+ ;; implementation since two different implementations using the same
+ ;; file system might differ on many issues.  How information is stored
+ ;; internally (and possibly presented in #S notation) might vary,
+ ;; possibly requiring `accessors' such as PATHNAME-NAME to perform case
+ ;; conversion upon access.  The format of a namestring is dependent both
+ ;; on the file system and the implementation since, for example, one
+ ;; implementation might include the host name in a namestring, and
+ ;; another might not.  #S notation would generally only be used in a
+ ;; situation where no appropriate namestring could be constructed for use
+ ;; with #P.
+ (setq p1 (pathname "test"))
+=>  #P"CHOCOLATE:TEST" ; with case canonicalization (e.g., VMS)
+OR=>  #P"VANILLA:test"   ; without case canonicalization (e.g., Unix)
+OR=>  #P"test"
+OR=>  #S(PATHNAME :HOST "STRAWBERRY" :NAME "TEST")
+OR=>  #S(PATHNAME :HOST "BELGIAN-CHOCOLATE" :NAME "test")
+ (setq p2 (pathname "test"))
+=>  #P"CHOCOLATE:TEST"
+OR=>  #P"VANILLA:test"
+OR=>  #P"test"
+OR=>  #S(PATHNAME :HOST "STRAWBERRY" :NAME "TEST")
+OR=>  #S(PATHNAME :HOST "BELGIAN-CHOCOLATE" :NAME "test")
+ (pathnamep p1) =>  true
+ (eq p1 (pathname p1)) =>  true
+ (eq p1 p2)
+=>  true
+OR=>  false
+ (with-open-file (stream "test" :direction :output)
+   (pathname stream))
+=>  #P"ORANGE-CHOCOLATE:>Gus>test.lisp.newest"
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_hos.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_hos.htm new file mode 100644 index 00000000..93e2c99e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_hos.htm @@ -0,0 +1,142 @@ + + + +CLHS: Function PATHNAME-HOST, PATHNAME-DEVICE... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION

+

Syntax:

+

+

+ +pathname-host pathname &key case => host

+

+ +pathname-device pathname &key case => device

+

+ +pathname-directory pathname &key case => directory

+

+ +pathname-name pathname &key case => name

+

+ +pathname-type pathname &key case => type

+

+

+ +pathname-version pathname => version

+

+

Arguments and Values:

+

+ pathname---a pathname designator.

+ case---one of :local or :common. The default is :local.

+ host---a valid pathname host.

+device---a valid pathname device.

+ directory---a valid pathname directory.

+name---a valid pathname name.

+type---a valid pathname type.

+version---a valid pathname version.

+

+

Description:

+

+These functions return the components of pathname.

+If the pathname designator is a pathname, it represents the name used to open the file. This may be, but is not required to be, the actual name of the file.

+ If case is supplied, it is treated as described in Section 19.2.2.1.2 (Case in Pathname Components).

+

Examples:

+

+ +

+ (setq q (make-pathname :host "KATHY"
+                        :directory "CHAPMAN" 
+                        :name "LOGIN" :type "COM"))
+=>  #P"KATHY::[CHAPMAN]LOGIN.COM"
+ (pathname-host q) =>  "KATHY"
+ (pathname-name q) =>  "LOGIN"
+ (pathname-type q) =>  "COM"
+
+ ;; Because namestrings are used, the results shown in the remaining
+ ;; examples are not necessarily the only possible results.  Mappings
+ ;; from namestring representation to pathname representation are 
+ ;; dependent both on the file system involved and on the implementation
+ ;; (since there may be several implementations which can manipulate the
+ ;; the same file system, and those implementations are not constrained
+ ;; to agree on all details). Consult the documentation for each
+ ;; implementation for specific information on how namestrings are treated
+ ;; that implementation.
+
+ ;; VMS
+ (pathname-directory (parse-namestring "[FOO.*.BAR]BAZ.LSP"))
+=>  (:ABSOLUTE "FOO" "BAR")
+ (pathname-directory (parse-namestring "[FOO.*.BAR]BAZ.LSP") :case :common)
+=>  (:ABSOLUTE "FOO" "BAR")
+
+ ;; Unix
+ (pathname-directory "foo.l") =>  NIL
+ (pathname-device "foo.l") =>  :UNSPECIFIC
+ (pathname-name "foo.l") =>  "foo"
+ (pathname-name "foo.l" :case :local) =>  "foo"
+ (pathname-name "foo.l" :case :common) =>  "FOO"
+ (pathname-type "foo.l") =>  "l"
+ (pathname-type "foo.l" :case :local) =>  "l"
+ (pathname-type "foo.l" :case :common) =>  "L"
+ (pathname-type "foo") =>  :UNSPECIFIC
+ (pathname-type "foo" :case :common) =>  :UNSPECIFIC
+ (pathname-type "foo.") =>  ""
+ (pathname-type "foo." :case :common) =>  ""
+ (pathname-directory (parse-namestring "/foo/bar/baz.lisp") :case :local)
+=>  (:ABSOLUTE "foo" "bar")
+ (pathname-directory (parse-namestring "/foo/bar/baz.lisp") :case :local)
+=>  (:ABSOLUTE "FOO" "BAR")
+ (pathname-directory (parse-namestring "../baz.lisp"))
+=>  (:RELATIVE :UP)
+ (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/BAR/../Mum/baz"))
+=>  (:ABSOLUTE "foo" "BAR" :UP "Mum")
+ (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/BAR/../Mum/baz") :case :common)
+=>  (:ABSOLUTE "FOO" "bar" :UP "Mum")
+ (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/*/bar/baz.l"))
+=>  (:ABSOLUTE "foo" :WILD "bar")
+ (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/*/bar/baz.l") :case :common)
+=>  (:ABSOLUTE "FOO" :WILD "BAR")
+
+ ;; Symbolics LMFS
+ (pathname-directory (parse-namestring ">foo>**>bar>baz.lisp"))
+=>  (:ABSOLUTE "foo" :WILD-INFERIORS "bar")
+ (pathname-directory (parse-namestring ">foo>*>bar>baz.lisp"))
+=>  (:ABSOLUTE "foo" :WILD "bar")
+ (pathname-directory (parse-namestring ">foo>*>bar>baz.lisp") :case :common)
+=>  (:ABSOLUTE "FOO" :WILD "BAR")
+ (pathname-device (parse-namestring ">foo>baz.lisp")) =>  :UNSPECIFIC
+
+

+

Affected By:

+

+The implementation and the host file system.

+

Exceptional Situations:

+

+Should signal an error of type type-error if its first argument is not a pathname.

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_mat.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_mat.htm new file mode 100644 index 00000000..5474bdd0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pn_mat.htm @@ -0,0 +1,54 @@ + + + +CLHS: Function PATHNAME-MATCH-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PATHNAME-MATCH-P

+

+

Syntax:

+

+ +pathname-match-p pathname wildcard => generalized-boolean

+

+

Arguments and Values:

+

+ pathname---a pathname designator.

+wildcard---a designator for a wild pathname.

+generalized-boolean---a generalized boolean.

+

Description:

+

+pathname-match-p returns true if pathname matches wildcard, otherwise nil. The matching rules are implementation-defined but should be consistent with directory. Missing components of wildcard default to :wild.

+It is valid for pathname to be a wild pathname; a wildcard field in pathname only matches a wildcard field in wildcard (i.e., pathname-match-p is not commutative). It is valid for wildcard to be a non-wild pathname.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If pathname or wildcard is not a pathname, string, or stream associated with a file an error of type type-error is signaled.

+

See Also:

+

+ directory, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pnp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pnp.htm new file mode 100644 index 00000000..20a1ddaa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pnp.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function PATHNAMEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PATHNAMEP

+

Syntax:

+

+ +pathnamep object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type pathname; otherwise, returns false.

+

Examples:

+

+

+ (setq q "test")  =>  "test"
+ (pathnamep q) =>  false
+ (setq q (pathname "test"))
+=>  #S(PATHNAME :HOST NIL :DEVICE NIL :DIRECTORY NIL :NAME "test" :TYPE NIL
+       :VERSION NIL)
+ (pathnamep q) =>  true 
+ (setq q (logical-pathname "SYS:SITE;FOO.SYSTEM"))
+=>  #P"SYS:SITE;FOO.SYSTEM"
+ (pathnamep q) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (pathnamep object) ==  (typep object 'pathname)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pos_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pos_p.htm new file mode 100644 index 00000000..34195b96 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pos_p.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function POSITION, POSITION-IF, POSITION-IF-NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function POSITION, POSITION-IF, POSITION-IF-NOT

+

Syntax:

+

+ +position item sequence &key from-end test test-not start end key => position

+

+ +position-if predicate sequence &key from-end start end key => position

+ +position-if-not predicate sequence &key from-end start end key => position

+

+

Arguments and Values:

+

+item---an object.

+sequence---a proper sequence.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+key---a designator for a function of one argument, or nil.

+position---a bounding index of sequence, or nil.

+

Description:

+

+position, position-if, and position-if-not each search sequence for an element that satisfies the test.

+The position returned is the index within sequence of the leftmost (if from-end is true) or of the rightmost (if from-end is false) element that satisfies the test; otherwise nil is returned. The index returned is relative to the left-hand end of the entire sequence, regardless of the value of start, end, or from-end.

+

Examples:

+

+

+ (position #\a "baobab" :from-end t) =>  4
+ (position-if #'oddp '((1) (2) (3) (4)) :start 1 :key #'car) =>  2
+ (position 595 '()) =>  NIL
+ (position-if-not #'integerp '(1 2 3 4 5.0)) =>  4 
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+find, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not argument is deprecated.

+ The function position-if-not is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_di.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_di.htm new file mode 100644 index 00000000..72a7c67d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_di.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function PPRINT-DISPATCH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PPRINT-DISPATCH

+

+

Syntax:

+

+ +pprint-dispatch object &optional table => function, found-p

+

+

Arguments and Values:

+

+object---an object.

+table---a pprint dispatch table, or nil. The default is the value of *print-pprint-dispatch*.

+function---a function designator.

+found-p---a generalized boolean.

+

Description:

+

+Retrieves the highest priority function in table that is associated with a type specifier that matches object. The function is chosen by finding all of the type specifiers in table that match the object and selecting the highest priority function associated with any of these type specifiers. If there is more than one highest priority function, an arbitrary choice is made. If no type specifiers match the object, a function is returned that prints object using print-object.

+The secondary value, found-p, is true if a matching type specifier was found in table, or false otherwise.

+If table is nil, retrieval is done in the initial pprint dispatch table.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By:

+

+The state of the table.

+

Exceptional Situations:

+

+Should signal an error of type type-error if table is neither a pprint-dispatch-table nor nil.

+

See Also: None. +

+

Notes:

+

+

+(let ((*print-pretty* t))
+  (write object :stream s))
+==  (funcall (pprint-dispatch object) s object)
+
+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_fi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_fi.htm new file mode 100644 index 00000000..c3931170 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_fi.htm @@ -0,0 +1,92 @@ + + + +CLHS: Function PPRINT-FILL, PPRINT-LINEAR... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR

+

+

Syntax:

+

+ +pprint-fill stream object &optional colon-p at-sign-p => nil

+ +pprint-linear stream object &optional colon-p at-sign-p => nil

+ +pprint-tabular stream object &optional colon-p at-sign-p tabsize => nil

+

+

Arguments and Values:

+

+stream---an output stream designator.

+object---an object.

+colon-p---a generalized boolean. The default is true.

+at-sign-p---a generalized boolean. The default is implementation-dependent.

+tabsize---a non-negative integer. The default is 16.

+

Description:

+

+The functions pprint-fill, pprint-linear, and pprint-tabular specify particular ways of pretty printing a list to stream. Each function prints parentheses around the output if and only if colon-p is true. Each function ignores its at-sign-p argument. (Both arguments are included even though only one is needed so that these functions can be used via ~/.../ and as set-pprint-dispatch functions, as well as directly.) Each function handles abbreviation and the detection of circularity and sharing correctly, and uses write to print object when it is a non-list.

+ If object is a list and if the value of *print-pretty* is false, each of these functions prints object using a minimum of whitespace, as described in Section 22.1.3.5 (Printing Lists and Conses). Otherwise (if object is a list and if the value of *print-pretty* is true):

+

+

+

Examples:

+

+Evaluating the following with a line length of 25 produces the output shown.

+

+(progn (princ "Roads ") 
+       (pprint-tabular *standard-output* '(elm main maple center) nil nil 8))
+Roads ELM     MAIN
+      MAPLE   CENTER
+
+

+

Side Effects:

+

+Performs output to the indicated stream.

+

Affected By:

+

+The cursor position on the indicated stream, if it can be determined.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+The function pprint-tabular could be defined as follows:

+

+(defun pprint-tabular (s list &optional (colon-p t) at-sign-p (tabsize nil))
+  (declare (ignore at-sign-p))
+  (when (null tabsize) (setq tabsize 16))
+  (pprint-logical-block (s list :prefix (if colon-p "(" "")
+                                :suffix (if colon-p ")" ""))
+    (pprint-exit-if-list-exhausted)
+    (loop (write (pprint-pop) :stream s)
+          (pprint-exit-if-list-exhausted)
+          (write-char #\Space s)
+          (pprint-tab :section-relative 0 tabsize s)
+          (pprint-newline :fill s))))
+
+

+Note that it would have been inconvenient to specify this function using format, because of the need to pass its tabsize argument through to a ~:T format directive nested within an iteration over a list.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_in.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_in.htm new file mode 100644 index 00000000..69d741bb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_in.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function PPRINT-INDENT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PPRINT-INDENT

+

+

Syntax:

+

+ +pprint-indent relative-to n &optional stream => nil

+

+

Arguments and Values:

+

+relative-to---either :block or :current.

+n---a real.

+stream---an output stream designator. The default is standard output.

+

Description:

+

+pprint-indent specifies the indentation to use in a logical block on stream. If stream is a pretty printing stream and the value of *print-pretty* is true, pprint-indent sets the indentation in the innermost dynamically enclosing logical block; otherwise, pprint-indent has no effect.

+N specifies the indentation in ems. If relative-to is :block, the indentation is set to the horizontal position of the first character in the dynamically current logical block plus n ems. If relative-to is :current, the indentation is set to the current output position plus n ems. (For robustness in the face of variable-width fonts, it is advisable to use :current with an n of zero whenever possible.)

+N can be negative; however, the total indentation cannot be moved left of the beginning of the line or left of the end of the rightmost per-line prefix---an attempt to move beyond one of these limits is treated the same as an attempt to move to that limit. Changes in indentation caused by pprint-indent do not take effect until after the next line break. In addition, in miser mode all calls to pprint-indent are ignored, forcing the lines corresponding to the logical block to line up under the first character in the block.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+An error is signaled if relative-to is any object other than :block or :current.

+

See Also:

+

+Section 22.3.5.3 (Tilde I: Indent)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_nl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_nl.htm new file mode 100644 index 00000000..92bf4efe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_nl.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function PPRINT-NEWLINE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PPRINT-NEWLINE

+

+

Syntax:

+

+ +pprint-newline kind &optional stream => nil

+

+

Arguments and Values:

+

+kind---one of :linear, :fill, :miser, or :mandatory.

+stream---a stream designator. The default is standard output.

+

Description:

+

+ If stream is a pretty printing stream and the value of *print-pretty* is true, a line break is inserted in the output when the appropriate condition below is satisfied; otherwise, pprint-newline has no effect.

+Kind specifies the style of conditional newline. This parameter is treated as follows:

+

+

:linear

+This specifies a ``linear-style'' conditional newline. A line break is inserted if and only if the immediately containing section cannot be printed on one line. The effect of this is that line breaks are either inserted at every linear-style conditional newline in a logical block or at none of them.

+

:miser

+This specifies a ``miser-style'' conditional newline. A line break is inserted if and only if the immediately containing section cannot be printed on one line and miser style is in effect in the immediately containing logical block. The effect of this is that miser-style conditional newlines act like linear-style conditional newlines, but only when miser style is in effect. Miser style is in effect for a logical block if and only if the starting position of the logical block is less than or equal to *print-miser-width* ems from the right margin.

+

:fill

+This specifies a ``fill-style'' conditional newline. A line break is inserted if and only if either (a) the following section cannot be printed on the end of the current line, (b) the preceding section was not printed on a single line, or (c) the immediately containing section cannot be printed on one line and miser style is in effect in the immediately containing logical block. If a logical block is broken up into a number of subsections by fill-style conditional newlines, the basic effect is that the logical block is printed with as many subsections as possible on each line. However, if miser style is in effect, fill-style conditional newlines act like linear-style conditional newlines.

+

:mandatory

+This specifies a ``mandatory-style'' conditional newline. A line break is always inserted. This implies that none of the containing sections can be printed on a single line and will therefore trigger the insertion of line breaks at linear-style conditional newlines in these sections.

+

+When a line break is inserted by any type of conditional newline, any blanks that immediately precede the conditional newline are omitted from the output and indentation is introduced at the beginning of the next line. By default, the indentation causes the following line to begin in the same horizontal position as the first character in the immediately containing logical block. (The indentation can be changed via pprint-indent.)

+There are a variety of ways unconditional newlines can be introduced into the output (i.e., via terpri or by printing a string containing a newline character). As with mandatory conditional newlines, this prevents any of the containing sections from being printed on one line. In general, when an unconditional newline is encountered, it is printed out without suppression of the preceding blanks and without any indentation following it. However, if a per-line prefix has been specified (see pprint-logical-block), this prefix will always be printed no matter how a newline originates.

+

Examples:

+

+See Section 22.2.2 (Examples of using the Pretty Printer).

+

Side Effects:

+

+Output to stream.

+

Affected By:

+

+*print-pretty*, *print-miser*. The presence of containing logical blocks. The placement of newlines and conditional newlines.

+

Exceptional Situations:

+

+An error of type type-error is signaled if kind is not one of :linear, :fill, :miser, or :mandatory.

+

See Also:

+

+Section 22.3.5.1 (Tilde Underscore: Conditional Newline), Section 22.2.2 (Examples of using the Pretty Printer)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_ta.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_ta.htm new file mode 100644 index 00000000..69b6be37 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ppr_ta.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function PPRINT-TAB + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PPRINT-TAB

+

+

Syntax:

+

+ +pprint-tab kind colnum colinc &optional stream => nil

+

+

Arguments and Values:

+

+kind---one of :line, :section, :line-relative, or :section-relative.

+colnum---a non-negative integer.

+colinc---a non-negative integer.

+stream---an output stream designator.

+

Description:

+

+Specifies tabbing to stream as performed by the standard ~T format directive. If stream is a pretty printing stream and the value of *print-pretty* is true, tabbing is performed; otherwise, pprint-tab has no effect.

+The arguments colnum and colinc correspond to the two parameters to ~T and are in terms of ems. The kind argument specifies the style of tabbing. It must be one of :line (tab as by ~T), :section (tab as by ~:T, but measuring horizontal positions relative to the start of the dynamically enclosing section), :line-relative (tab as by ~@T), or :section-relative (tab as by ~:@T, but measuring horizontal positions relative to the start of the dynamically enclosing section).

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+An error is signaled if kind is not one of :line, :section, :line-relative, or :section-relative.

+

See Also:

+

+pprint-logical-block

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_not.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_not.htm new file mode 100644 index 00000000..e8c15a48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_not.htm @@ -0,0 +1,49 @@ + + + +CLHS: Function PRINT-NOT-READABLE-OBJECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PRINT-NOT-READABLE-OBJECT

Syntax:

+

+ +print-not-readable-object condition => object

+

+

Arguments and Values:

+

+condition---a condition of type print-not-readable.

+object---an object.

+

Description:

+

+Returns the object that could not be printed readably in the situation represented by condition.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+print-not-readable, Section 9 (Conditions)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_obj.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_obj.htm new file mode 100644 index 00000000..875d439e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_pr_obj.htm @@ -0,0 +1,81 @@ + + + +CLHS: Standard Generic Function PRINT-OBJECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function PRINT-OBJECT

+

Syntax:

+

+ +print-object object stream => object

+

+

Method Signatures:

+

+ +print-object (object standard-object) stream

+ +print-object (object structure-object) stream

+

+

Arguments and Values:

+

+object---an object.

+stream---a stream.

+

Description:

+

+The generic function print-object writes the printed representation of object to stream. The function print-object is called by the Lisp printer; it should not be called by the user.

+ Each implementation is required to provide a method on the class standard-object and on the class structure-object. In addition, each implementation must provide methods on enough other classes so as to ensure that there is always an applicable method. Implementations are free to add methods for other classes. Users may write methods for print-object for their own classes if they do not wish to inherit an implementation-dependent method.

+The method on the class structure-object prints the object in the default #S notation; see Section 22.1.3.12 (Printing Structures).

+Methods on print-object are responsible for implementing their part of the semantics of the printer control variables, as follows:

+

+

+

*print-readably*

+All methods for print-object must obey *print-readably*. This includes both user-defined methods and implementation-defined methods. Readable printing of structures and standard objects is controlled by their print-object method, not by their make-load-form method. Similarity for these objects is application dependent and hence is defined to be whatever these methods do; see Section 3.2.4.2 (Similarity of Literal Objects).

+

+

*print-escape*

+Each method must implement *print-escape*.

+

*print-pretty*

+ The method may wish to perform specialized line breaking or other output conditional on the value of *print-pretty*. For further information, see (for example) the macro pprint-fill. See also Section 22.2.1.4 (Pretty Print Dispatch Tables) and Section 22.2.2 (Examples of using the Pretty Printer).

+

*print-length*

+Methods that produce output of indefinite length must obey *print-length*. For further information, see (for example) the macros pprint-logical-block and pprint-pop. See also Section 22.2.1.4 (Pretty Print Dispatch Tables) and Section 22.2.2 (Examples of using the Pretty Printer).

+

*print-level*

+The printer takes care of *print-level* automatically, provided that each method handles exactly one level of structure and calls write (or an equivalent function) recursively if there are more structural levels. The printer's decision of whether an object has components (and therefore should not be printed when the printing depth is not less than *print-level*) is implementation-dependent. In some implementations its print-object method is not called; in others the method is called, and the determination that the object has components is based on what it tries to write to the stream.

+

*print-circle*

+ When the value of *print-circle* is true, a user-defined print-object method can print objects to the supplied stream using write, prin1, princ, or format and expect circularities to be detected and printed using the #n# syntax. If a user-defined print-object method prints to a stream other than the one that was supplied, then circularity detection starts over for that stream. See *print-circle*.

+

*print-base*, *print-radix*, *print-case*, *print-gensym*, and *print-array*

+These printer control variables apply to specific types of objects and are handled by the methods for those objects.

+

+If these rules are not obeyed, the results are undefined.

+In general, the printer and the print-object methods should not rebind the print control variables as they operate recursively through the structure, but this is implementation-dependent.

+In some implementations the stream argument passed to a print-object method is not the original stream, but is an intermediate stream that implements part of the printer. methods should therefore not depend on the identity of this stream.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+pprint-fill, pprint-logical-block, pprint-pop, write, *print-readably*, *print-escape*, *print-pretty*, *print-length*, Section 22.1.3 (Default Print-Object Methods), Section 22.1.3.12 (Printing Structures), Section 22.2.1.4 (Pretty Print Dispatch Tables), Section 22.2.2 (Examples of using the Pretty Printer)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_probe_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_probe_.htm new file mode 100644 index 00000000..0b7fb41c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_probe_.htm @@ -0,0 +1,55 @@ + + + +CLHS: Function PROBE-FILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PROBE-FILE

+

Syntax:

+

+ +probe-file pathspec => truename

+

+

Arguments and Values:

+

+ pathspec---a pathname designator.

+ truename---a physical pathname or nil.

+

Description:

+

+probe-file tests whether a file exists.

+probe-file returns false if there is no file named pathspec, and otherwise returns the truename of pathspec.

+If the pathspec designator is an open stream, then probe-file produces the truename of its associated file. If pathspec is a stream, whether open or closed, it is coerced to a pathname as if by the function pathname.

+

Examples: None. +

+

Affected By:

+

+The host computer's file system.

+

Exceptional Situations:

+

+ An error of type file-error is signaled if pathspec is wild.

+ An error of type file-error is signaled if the file system cannot perform the requested operation.

+

See Also:

+

+truename, open, ensure-directories-exist, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 20.1.2 (File Operations on Open and Closed Streams), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_procla.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_procla.htm new file mode 100644 index 00000000..fd67fcd0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_procla.htm @@ -0,0 +1,82 @@ + + + +CLHS: Function PROCLAIM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PROCLAIM

+

Syntax:

+

+ +proclaim declaration-specifier => implementation-dependent

+

+

Arguments and Values:

+

+declaration-specifier---a declaration specifier.

+

Description:

+

+Establishes the declaration specified by declaration-specifier in the global environment.

+Such a declaration, sometimes called a global declaration or a proclamation, is always in force unless locally shadowed.

+Names of variables and functions within declaration-specifier refer to dynamic variables and global function definitions, respectively.

+The next figure shows a list of declaration identifiers that can be used with proclaim.

+ 

+declaration  inline     optimize  type  
+ftype        notinline  special         
+
+

Figure 3-22. Global Declaration Specifiers

+An implementation is free to support other (implementation-defined) declaration identifiers as well.

+

Examples:

+

+

+ (defun declare-variable-types-globally (type vars)
+   (proclaim `(type ,type ,@vars))
+   type)
+
+ ;; Once this form is executed, the dynamic variable *TOLERANCE*
+ ;; must always contain a float.
+ (declare-variable-types-globally 'float '(*tolerance*))
+=>  FLOAT
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+declaim, declare, Section 3.2 (Compilation)

+

Notes:

+

+Although the execution of a proclaim form has effects that might affect compilation, the compiler does not make any attempt to recognize and specially process proclaim forms. A proclamation such as the following, even if a top level form, does not have any effect until it is executed:

+

+(proclaim '(special *x*))
+
+

+If compile time side effects are desired, eval-when may be useful. For example:

+

+ (eval-when (:execute :compile-toplevel :load-toplevel)
+   (proclaim '(special *x*)))
+
+

+In most such cases, however, it is preferrable to use declaim for this purpose.

+ Since proclaim forms are ordinary function forms, macro forms can expand into them.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_provid.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_provid.htm new file mode 100644 index 00000000..7bcf92a9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_provid.htm @@ -0,0 +1,89 @@ + + + +CLHS: Function PROVIDE, REQUIRE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function PROVIDE, REQUIRE

+

+

Syntax:

+

+ +provide module-name => implementation-dependent

+ +require module-name &optional pathname-list => implementation-dependent

+

+

Arguments and Values:

+

+module-name---a string designator.

+ pathname-list---nil, or a designator for a non-empty list of pathname designators. The default is nil.

+

Description:

+

+provide adds the module-name to the list held by *modules*, if such a name is not already present.

+require tests for the presence of the module-name in the list held by *modules*. If it is present, require immediately returns. Otherwise, an attempt is made to load an appropriate set of files as follows: The pathname-list argument, if non-nil, specifies a list of pathnames to be loaded in order, from left to right. If the pathname-list is nil, an implementation-dependent mechanism will be invoked in an attempt to load the module named module-name; if no such module can be loaded, an error of type error is signaled.

+Both functions use string= to test for the presence of a module-name.

+

Examples:

+

+

+

+;;; This illustrates a nonportable use of REQUIRE, because it
+;;; depends on the implementation-dependent file-loading mechanism.
+
+(require "CALCULUS")
+
+;;; This use of REQUIRE is nonportable because of the literal 
+;;; physical pathname.  
+
+(require "CALCULUS" "/usr/lib/lisp/calculus")
+
+;;; One form of portable usage involves supplying a logical pathname,
+;;; with appropriate translations defined elsewhere.
+
+(require "CALCULUS" "lib:calculus")
+
+;;; Another form of portable usage involves using a variable or
+;;; table lookup function to determine the pathname, which again
+;;; must be initialized elsewhere.
+
+(require "CALCULUS" *calculus-module-pathname*)
+
+

+

Side Effects:

+

+provide modifies *modules*.

+

Affected By:

+

+The specific action taken by require is affected by calls to provide (or, in general, any changes to the value of *modules*).

+

Exceptional Situations:

+

+Should signal an error of type type-error if module-name is not a string designator.

+ If require fails to perform the requested operation due to a problem while interacting with the file system, an error of type file-error is signaled.

+ An error of type file-error might be signaled if any pathname in pathname-list is a designator for a wild pathname.

+

See Also:

+

+*modules*, Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+The functions provide and require are deprecated.

+If a module consists of a single package, it is customary for the package and module names to be the same.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_random.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_random.htm new file mode 100644 index 00000000..814db873 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_random.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function RANDOM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RANDOM

+

Syntax:

+

+ +random limit &optional random-state => random-number

+

+

Arguments and Values:

+

+limit---a positive integer, or a positive float.

+random-state---a random state. The default is the current random state.

+random-number---a non-negative number less than limit and of the same type as limit.

+

Description:

+

+Returns a pseudo-random number that is a non-negative number less than limit and of the same type as limit.

+The random-state, which is modified by this function, encodes the internal state maintained by the random number generator.

+An approximately uniform choice distribution is used. If limit is an integer, each of the possible results occurs with (approximate) probability 1/limit.

+

Examples:

+

+

+ (<= 0 (random 1000) 1000) =>  true
+ (let ((state1 (make-random-state))
+       (state2 (make-random-state)))
+   (= (random 1000 state1) (random 1000 state2))) =>  true
+
+

+

Side Effects:

+

+The random-state is modified.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if limit is not a positive integer or a positive real.

+

See Also:

+

+make-random-state, *random-state*

+

Notes:

+

+See Common Lisp: The Language for information about generating random numbers.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rassoc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rassoc.htm new file mode 100644 index 00000000..ec469ee4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rassoc.htm @@ -0,0 +1,90 @@ + + + +CLHS: Function RASSOC, RASSOC-IF, RASSOC-IF-NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RASSOC, RASSOC-IF, RASSOC-IF-NOT

+

Syntax:

+

+ +rassoc item alist &key key test test-not => entry

+

+

+ +rassoc-if predicate alist &key key => entry

+ +rassoc-if-not predicate alist &key key => entry

+

+

+

Arguments and Values:

+

+item---an object.

+alist---an association list.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+entry---a cons that is an element of the alist, or nil.

+

Description:

+

+rassoc, rassoc-if, and rassoc-if-not return the first cons whose cdr satisfies the test. If no such cons is found, nil s returned.

+

+If nil appears in alist in place of a pair, it is ignored.

+

Examples:

+

+

+ (setq alist '((1 . "one") (2 . "two") (3 . 3))) 
+=>  ((1 . "one") (2 . "two") (3 . 3))
+ (rassoc 3 alist) =>  (3 . 3)
+ (rassoc "two" alist) =>  NIL
+ (rassoc "two" alist :test 'equal) =>  (2 . "two")
+ (rassoc 1 alist :key #'(lambda (x) (if (numberp x) (/ x 3)))) =>  (3 . 3)
+ (rassoc 'a '((a . b) (b . c) (c . a) (z . a))) =>  (C . A)
+ (rassoc-if #'stringp alist) =>  (1 . "one")
+ (rassoc-if-not #'vectorp alist) =>  (3 . 3)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+assoc, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+ The function rassoc-if-not is deprecated.

+It is possible to rplaca the result of rassoc, provided that it is not nil, in order to ``update'' alist.

+The expressions

+

+ (rassoc item list :test fn)
+
+ and

+

+ (find item list :test fn :key #'cdr)
+
+ are equivalent in meaning, except when the item is nil nd nil appears in place of a pair in the alist. See the function assoc.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rati_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rati_1.htm new file mode 100644 index 00000000..28d4e5f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rati_1.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function RATIONALP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RATIONALP

+

Syntax:

+

+ +rationalp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type rational; otherwise, returns false.

+

Examples:

+

+

+ (rationalp 12) =>  true
+ (rationalp 6/5) =>  true
+ (rationalp 1.212) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+rational

+

Notes:

+ +

+ (rationalp object) ==  (typep object 'rational)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ration.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ration.htm new file mode 100644 index 00000000..e34070cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_ration.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function RATIONAL, RATIONALIZE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RATIONAL, RATIONALIZE

+

Syntax:

+

+ +rational number => rational

+ +rationalize number => rational

+

+

Arguments and Values:

+

+number---a real.

+rational---a rational.

+

Description:

+

+rational and rationalize convert reals to rationals.

+If number is already rational, it is returned.

+If number is a float, rational returns a rational that is mathematically equal in value to the float. rationalize returns a rational that approximates the float to the accuracy of the underlying floating-point representation.

+rational assumes that the float is completely accurate.

+rationalize assumes that the float is accurate only to the precision of the floating-point representation.

+

Examples:

+ +

+ (rational 0) =>  0
+ (rationalize -11/100) =>  -11/100
+ (rational .1) =>  13421773/134217728 ;implementation-dependent
+ (rationalize .1) =>  1/10
+
+

+

Side Effects: None. +

+

Affected By:

+

+The implementation.

+

Exceptional Situations:

+

+Should signal an error of type type-error if number is not a real. Might signal arithmetic-error.

+

See Also: None. +

+

Notes:

+

+It is always the case that

+

+ (float (rational x) x) ==  x
+
+ and

+

+ (float (rationalize x) x) ==  x
+
+ That is, rationalizing a float by either method and then converting it back to a float of the same format produces the original number.

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_by.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_by.htm new file mode 100644 index 00000000..42de7d78 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_by.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function READ-BYTE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-BYTE

+

Syntax:

+

+ +read-byte stream &optional eof-error-p eof-value => byte

+

+

Arguments and Values:

+

+stream---a binary input stream.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+byte---an integer, or the eof-value.

+

Description:

+

+read-byte reads and returns one byte from stream.

+If an end of file[2] occurs and eof-error-p is false, the eof-value is returned.

+

Examples:

+ +

+ (with-open-file (s "temp-bytes" 
+                     :direction :output
+                     :element-type 'unsigned-byte)
+    (write-byte 101 s)) =>  101
+ (with-open-file (s "temp-bytes" :element-type 'unsigned-byte)
+    (format t "~S ~S" (read-byte s) (read-byte s nil 'eof)))
+>>  101 EOF
+=>  NIL
+
+

+

Side Effects:

+

+Modifies stream.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream.

+Should signal an error of type error if stream is not a binary input stream.

+If there are no bytes remaining in the stream and eof-error-p is true, an error of type end-of-file is signaled.

+

See Also:

+

+read-char, read-sequence, write-byte

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_c_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_c_1.htm new file mode 100644 index 00000000..3f8e022a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_c_1.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function READ-CHAR-NO-HANG + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-CHAR-NO-HANG

+

Syntax:

+

+ +read-char-no-hang &optional input-stream eof-error-p eof-value recursive-p => char

+

+

Arguments and Values:

+

+input-stream -- an input stream designator. The default is standard input.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+recursive-p---a generalized boolean. The default is false.

+char---a character or nil or the eof-value.

+

Description:

+

+read-char-no-hang returns a character from input-stream if such a character is available. If no character is available, read-char-no-hang returns nil.

+ If recursive-p is true, this call is expected to be embedded in a higher-level call to read or a similar function used by the Lisp reader.

+If an end of file[2] occurs and eof-error-p is false, eof-value is returned.

+

Examples:

+

+

+;; This code assumes an implementation in which a newline is not
+;; required to terminate input from the console.
+ (defun test-it ()
+   (unread-char (read-char))
+   (list (read-char-no-hang) 
+         (read-char-no-hang) 
+         (read-char-no-hang)))
+=>  TEST-IT
+;; Implementation A, where a Newline is not required to terminate
+;; interactive input on the console.
+ (test-it)
+>>  a
+=>  (#\a NIL NIL)
+;; Implementation B, where a Newline is required to terminate
+;; interactive input on the console, and where that Newline remains
+;; on the input stream.
+ (test-it)
+>>  a<NEWLINE>
+=>  (#\a #\Newline NIL)
+
+

+

Affected By:

+

+*standard-input*, *terminal-io*.

+

Exceptional Situations:

+

+If an end of file[2] occurs when eof-error-p is true, an error of type end-of-file is signaled .

+

See Also:

+

+listen

+

Notes:

+

+read-char-no-hang is exactly like read-char, except that if it would be necessary to wait in order to get a character (as from a keyboard), nil is immediately returned without waiting.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_cha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_cha.htm new file mode 100644 index 00000000..f092114b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_cha.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function READ-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-CHAR

+

Syntax:

+

+ +read-char &optional input-stream eof-error-p eof-value recursive-p => char

+

+

Arguments and Values:

+

+input-stream---an input stream designator. The default is standard input.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+recursive-p---a generalized boolean. The default is false.

+char---a character or the eof-value.

+

Description:

+

+read-char returns the next character from input-stream.

+ When input-stream is an echo stream, the character is echoed on input-stream the first time the character is seen. Characters that are not echoed by read-char are those that were put there by unread-char and hence are assumed to have been echoed already by a previous call to read-char.

+ If recursive-p is true, this call is expected to be embedded in a higher-level call to read or a similar function used by the Lisp reader.

+If an end of file[2] occurs and eof-error-p is false, eof-value is returned.

+

Examples:

+ +

+ (with-input-from-string (is "0123")
+    (do ((c (read-char is) (read-char is nil 'the-end)))
+        ((not (characterp c)))
+     (format t "~S " c)))
+>>  #\0 #\1 #\2 #\3
+=>  NIL
+
+

+

Affected By:

+

+*standard-input*, *terminal-io*.

+

Exceptional Situations:

+

+If an end of file[2] occurs before a character can be read, and eof-error-p is true, an error of type end-of-file is signaled.

+

See Also:

+

+read-byte, read-sequence, write-char, read

+

Notes:

+ The corresponding output function is write-char.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_del.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_del.htm new file mode 100644 index 00000000..356dd00d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_del.htm @@ -0,0 +1,88 @@ + + + +CLHS: Function READ-DELIMITED-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-DELIMITED-LIST

+

Syntax:

+

+ +read-delimited-list char &optional input-stream recursive-p => list

+

+

Arguments and Values:

+

+char---a character.

+input-stream---an input stream designator. The default is standard input.

+recursive-p---a generalized boolean. The default is false.

+list---a list of the objects read.

+

Description:

+

+read-delimited-list reads objects from input-stream until the next character after an object's representation (ignoring whitespace[2] characters and comments) is char.

+read-delimited-list looks ahead at each step for the next non-whitespace[2] character and peeks at it as if with peek-char. If it is char, then the character is consumed and the list of objects is returned. If it is a constituent or escape character, then read is used to read an object, which is added to the end of the list. If it is a macro character, its reader macro function is called; if the function returns a value, that value is added to the list. The peek-ahead process is then repeated.

+If recursive-p is true, this call is expected to be embedded in a higher-level call to read or a similar function.

+It is an error to reach end-of-file during the operation of read-delimited-list.

+The consequences are undefined if char has a syntax type of whitespace[2] in the current readtable.

+

Examples:

+ +

+ (read-delimited-list #\]) 1 2 3 4 5 6 ]
+=>  (1 2 3 4 5 6)
+
+ Suppose you wanted #{a b c ... z} to read as a list of all pairs of the elements a, b, c, ..., z, for example.

+

+ #{p q z a}  reads as  ((p q) (p z) (p a) (q z) (q a) (z a))
+
+ This can be done by specifying a macro-character definition for #{ that does two things: reads in all the items up to the }, and constructs the pairs. read-delimited-list performs the first task.

+

+ (defun |#{-reader| (stream char arg)
+   (declare (ignore char arg))
+   (mapcon #'(lambda (x)
+              (mapcar #'(lambda (y) (list (car x) y)) (cdr x)))
+          (read-delimited-list #\} stream t))) =>  |#{-reader|
+
+ (set-dispatch-macro-character #\# #\{ #'|#{-reader|) =>  T 
+ (set-macro-character #\} (get-macro-character #\) nil))
+
+ Note that true is supplied for the recursive-p argument.

+It is necessary here to give a definition to the character } as well to prevent it from being a constituent. If the line

+

+ (set-macro-character #\} (get-macro-character #\) nil))
+
+ shown above were not included, then the } in

+

+ #{ p q z a}
+
+ would be considered a constituent character, part of the symbol named a}. This could be corrected by putting a space before the }, but it is better to call set-macro-character.

+Giving } the same definition as the standard definition of the character ) has the twin benefit of making it terminate tokens for use with read-delimited-list and also making it invalid for use in any other context. Attempting to read a stray } will signal an error.

+

Affected By:

+

+*standard-input*, *readtable*, *terminal-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+read, peek-char, read-char, unread-char.

+

Notes:

+

+read-delimited-list is intended for use in implementing reader macros. Usually it is desirable for char to be a terminating macro character so that it can be used to delimit tokens; however, read-delimited-list makes no attempt to alter the syntax specified for char by the current readtable. The caller must make any necessary changes to the readtable syntax explicitly.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_fro.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_fro.htm new file mode 100644 index 00000000..654235f5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_fro.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function READ-FROM-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-FROM-STRING

+

Syntax:

+

+ +read-from-string string &optional eof-error-p eof-value &key start end preserve-whitespace

=> object, position

+

+

Arguments and Values:

+

+string---a string.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+ start, end---bounding index designators of string. The defaults for start and end are 0 and nil, respectively.

+preserve-whitespace---a generalized boolean. The default is false.

+object---an object (parsed by the Lisp reader) or the eof-value.

+position---an integer greater than or equal to zero, and less than or equal to one more than the length of the string.

+

Description:

+

+Parses the printed representation of an object from the subsequence of string bounded by start and end, as if read had been called on an input stream containing those same characters.

+If preserve-whitespace is true, the operation will preserve whitespace[2] as read-preserving-whitespace would do.

+If an object is successfully parsed, the primary value, object, is the object that was parsed. If eof-error-p is false and if the end of the substring is reached, eof-value is returned.

+The secondary value, position, is the index of the first character in the bounded string that was not read. The position may depend upon the value of preserve-whitespace. If the entire string was read, the position returned is either the length of the string or one greater than the length of the string.

+

Examples:

+

+

+ (read-from-string " 1 3 5" t nil :start 2) =>  3, 5
+ (read-from-string "(a b c)") =>  (A B C), 7
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If the end of the supplied substring occurs before an object can be read, an error is signaled if eof-error-p is true. An error is signaled if the end of the substring occurs in the middle of an incomplete object.

+

See Also:

+

+read, read-preserving-whitespace

+

Notes:

+

+The reason that position is allowed to be beyond the length of the string is to permit (but not require) the implementation to work by simulating the effect of a trailing delimiter at the end of the bounded string. When preserve-whitespace is true, the position might count the simulated delimiter.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_lin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_lin.htm new file mode 100644 index 00000000..55e49faa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_lin.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function READ-LINE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-LINE

+

Syntax:

+

+ +read-line &optional input-stream eof-error-p eof-value recursive-p

=> line, missing-newline-p

+

+

Arguments and Values:

+

+input-stream---an input stream designator. The default is standard input.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+recursive-p---a generalized boolean. The default is false.

+line---a string or the eof-value.

+missing-newline-p---a generalized boolean.

+

Description:

+

+Reads from input-stream a line of text that is terminated by a newline or end of file.

+ If recursive-p is true, this call is expected to be embedded in a higher-level call to read or a similar function used by the Lisp reader.

+The primary value, line, is the line that is read, represented as a string (without the trailing newline, if any). If eof-error-p is false and the end of file for input-stream is reached before any characters are read, eof-value is returned as the line.

+The secondary value, missing-newline-p, is a generalized boolean that is false if the line was terminated by a newline, or true if the line was terminated by the end of file for input-stream (or if the line is the eof-value).

+

Examples:

+

+

+ (setq a "line 1
+ line2")
+=>  "line 1
+ line2"
+ (read-line (setq input-stream (make-string-input-stream a)))
+=>  "line 1", false
+ (read-line input-stream)
+=>  "line2", true
+ (read-line input-stream nil nil)
+=>  NIL, true
+
+

+

Side Effects: None. +

+

Affected By:

+

+*standard-input*, *terminal-io*.

+

Exceptional Situations:

+

+If an end of file[2] occurs before any characters are read in the line, an error is signaled if eof-error-p is true.

+

See Also:

+

+read

+

Notes:

+

+The corresponding output function is write-line.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_rd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_rd.htm new file mode 100644 index 00000000..203a1259 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_rd.htm @@ -0,0 +1,104 @@ + + + +CLHS: Function READ, READ-PRESERVING-WHITESPACE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ, READ-PRESERVING-WHITESPACE

+

Syntax:

+

+ +read &optional input-stream eof-error-p eof-value recursive-p => object

+

+ +read-preserving-whitespace &optional input-stream eof-error-p eof-value recursive-p

=> object

+

+

Arguments and Values:

+

+input-stream---an input stream designator.

+eof-error-p---a generalized boolean. The default is true.

+ eof-value---an object. The default is nil.

+recursive-p---a generalized boolean. The default is false.

+object---an object (parsed by the Lisp reader) or the eof-value.

+

Description:

+

+read parses the printed representation of an object from input-stream and builds such an object.

+read-preserving-whitespace is like read but preserves any whitespace[2] character that delimits the printed representation of the object. read-preserving-whitespace is exactly like read when the recursive-p argument to read-preserving-whitespace is true.

+When *read-suppress* is false, read throws away the delimiting character required by certain printed representations if it is a whitespace[2] character; but read preserves the character (using unread-char) if it is syntactically meaningful, because it could be the start of the next expression.

+If a file ends in a symbol or a number immediately followed by an end of file[1], read reads the symbol or number successfully; when called again, it sees the end of file[1] and only then acts according to eof-error-p. If a file contains ignorable text at the end, such as blank lines and comments, read does not consider it to end in the middle of an object.

+If recursive-p is true, the call to read is expected to be made from within some function that itself has been called from read or from a similar input function, rather than from the top level.

+ Both functions return the object read from input-stream. Eof-value is returned if eof-error-p is false and end of file is reached before the beginning of an object.

+

Examples:

+

+

+ (read)
+>>  'a
+=>  (QUOTE A)
+ (with-input-from-string (is " ") (read is nil 'the-end)) =>  THE-END
+ (defun skip-then-read-char (s c n)
+    (if (char= c #\{) (read s t nil t) (read-preserving-whitespace s))
+    (read-char-no-hang s)) =>  SKIP-THEN-READ-CHAR
+ (let ((*readtable* (copy-readtable nil)))
+    (set-dispatch-macro-character #\# #\{ #'skip-then-read-char)
+    (set-dispatch-macro-character #\# #\} #'skip-then-read-char)
+    (with-input-from-string (is "#{123 x #}123 y")
+      (format t "~S ~S" (read is) (read is)))) =>  #\x, #\Space, NIL
+
+

+As an example, consider this reader macro definition:

+

+ (defun slash-reader (stream char)
+   (declare (ignore char))
+   `(path . ,(loop for dir = (read-preserving-whitespace stream t nil t)
+                   then (progn (read-char stream t nil t)
+                               (read-preserving-whitespace stream t nil t))
+                   collect dir
+                   while (eql (peek-char nil stream nil nil t) #\/))))
+ (set-macro-character #\/ #'slash-reader)
+
+

+Consider now calling read on this expression:

+

+ (zyedh /usr/games/zork /usr/games/boggle)
+
+ The / macro reads objects separated by more / characters; thus /usr/games/zork is intended to read as (path usr games zork). The entire example expression should therefore be read as

+

+ (zyedh (path usr games zork) (path usr games boggle))
+
+ However, if read had been used instead of read-preserving-whitespace, then after the reading of the symbol zork, the following space would be discarded; the next call to peek-char would see the following /, and the loop would continue, producing this interpretation:

+

+ (zyedh (path usr games zork usr games boggle))
+
+ There are times when whitespace[2] should be discarded. If a command interpreter takes single-character commands, but occasionally reads an object then if the whitespace[2] after a symbol is not discarded it might be interpreted as a command some time later after the symbol had been read.

+

Affected By:

+

+*standard-input*, *terminal-io*, *readtable*, *read-default-float-format*, *read-base*, *read-suppress*, *package*, *read-eval*.

+

Exceptional Situations:

+

+read signals an error of type end-of-file, regardless of eof-error-p, if the file ends in the middle of an object representation. For example, if a file does not contain enough right parentheses to balance the left parentheses in it, read signals an error. This is detected when read or read-preserving-whitespace is called with recursive-p and eof-error-p non-nil, and end-of-file is reached before the beginning of an object.

+If eof-error-p is true, an error of type end-of-file is signaled at the end of file.

+

See Also:

+

+peek-char, read-char, unread-char, read-from-string, read-delimited-list, parse-integer, Section 2 (Syntax), Section 23.1 (Reader Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_seq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_seq.htm new file mode 100644 index 00000000..d9215a71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rd_seq.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function READ-SEQUENCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READ-SEQUENCE

+

Syntax:

+

+ +read-sequence sequence stream &key start end => position

+

+sequence---a sequence.

+stream---an input stream.

+start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+position---an integer greater than or equal to zero, and less than or equal to the length of the sequence.

+

Description:

+

+Destructively modifies sequence by replacing the elements of sequence bounded by start and end with elements read from stream.

+Sequence is destructively modified by copying successive elements into it from stream. If the end of file for stream is reached before copying all elements of the subsequence, then the extra elements near the end of sequence are not updated.

+Position is the index of the first element of sequence that was not updated, which might be less than end because the end of file was reached.

+

Examples:

+

+

+ (defvar *data* (make-array 15 :initial-element nil))
+ (values (read-sequence *data* (make-string-input-stream "test string")) *data*)
+ =>  11, #(#\t #\e #\s #\t #\Space #\s #\t #\r #\i #\n #\g NIL NIL NIL NIL)
+
+

+

Side Effects:

+

+Modifies stream and sequence.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence. Should signal an error of type type-error if start is not a non-negative integer. Should signal an error of type type-error if end is not a non-negative integer or nil.

+Might signal an error of type type-error if an element read from the stream is not a member of the element type of the sequence.

+

See Also:

+

+Section 3.2.1 (Compiler Terminology), write-sequence, read-line

+

Notes:

+

+read-sequence is identical in effect to iterating over the indicated subsequence and reading one element at a time from stream and storing it into sequence, but may be more efficient than the equivalent loop. An efficient implementation is more likely to exist for the case where the sequence is a vector with the same element type as the stream.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdta_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdta_1.htm new file mode 100644 index 00000000..844d7acd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdta_1.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function READTABLEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function READTABLEP

+

Syntax:

+

+ +readtablep object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type readtable; otherwise, returns false.

+

Examples:

+

+

+ (readtablep *readtable*) =>  true
+ (readtablep (copy-readtable)) =>  true
+ (readtablep '*readtable*) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (readtablep object) ==  (typep object 'readtable) 
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdtabl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdtabl.htm new file mode 100644 index 00000000..9035815a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rdtabl.htm @@ -0,0 +1,56 @@ + + + +CLHS: Accessor READTABLE-CASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor READTABLE-CASE

+

Syntax:

+

+ +readtable-case readtable => mode

+

+ +(setf (readtable-case readtable) mode)

+

+

Arguments and Values:

+

+readtable---a readtable.

+mode---a case sensitivity mode.

+

Description:

+

+Accesses the readtable case of readtable, which affects the way in which the Lisp Reader reads symbols and the way in which the Lisp Printer writes symbols.

+

Examples:

+

+See Section 23.1.2.1 (Examples of Effect of Readtable Case on the Lisp Reader) and Section 22.1.3.3.2.1 (Examples of Effect of Readtable Case on the Lisp Printer).

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if readtable is not a readtable. Should signal an error of type type-error if mode is not a case sensitivity mode.

+

See Also:

+

+*readtable*, *print-escape*, Section 2.2 (Reader Algorithm), Section 23.1.2 (Effect of Readtable Case on the Lisp Reader), Section 22.1.3.3.2 (Effect of Readtable Case on the Lisp Printer)

+

Notes:

+

+copy-readtable copies the readtable case of the readtable.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realp.htm new file mode 100644 index 00000000..28673162 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realp.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function REALP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REALP

+

+

Syntax:

+

+ +realp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type real; otherwise, returns false.

+

Examples:

+ +

+ (realp 12) =>  true
+ (realp #c(5/3 7.2)) =>  false
+ (realp nil) =>  false
+ (realp (cons 1 2)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (realp object) ==  (typep object 'real)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realpa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realpa.htm new file mode 100644 index 00000000..18227f94 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_realpa.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function REALPART, IMAGPART + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REALPART, IMAGPART

+

Syntax:

+

+ +realpart number => real

+ +imagpart number => real

+

+

Arguments and Values:

+

+number---a number.

+real---a real.

+

Description:

+

+realpart and imagpart return the real and imaginary parts of number respectively. If number is real, then realpart returns number and imagpart returns (* 0 number), which has the effect that the imaginary part of a rational is 0 and that of a float is a floating-point zero of the same format.

+

Examples:

+

+

+ (realpart #c(23 41)) =>  23
+ (imagpart #c(23 41.0)) =>  41.0
+ (realpart #c(23 41.0)) =>  23.0
+ (imagpart 23.0) =>  0.0
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if number is not a number.

+

See Also:

+

+complex

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reduce.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reduce.htm new file mode 100644 index 00000000..a9ff042e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reduce.htm @@ -0,0 +1,81 @@ + + + +CLHS: Function REDUCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REDUCE

+

Syntax:

+

+ +reduce function sequence &key key from-end start end initial-value => result

+

+

Arguments and Values:

+

+function---a designator for a function that might be called with either zero or two arguments.

+sequence---a proper sequence.

+ key---a designator for a function of one argument, or nil.

+from-end---a generalized boolean. The default is false.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+initial-value---an object.

+result---an object.

+

Description:

+

+reduce uses a binary operation, function, to combine the elements of sequence bounded by start and end.

+The function must accept as arguments two elements of sequence or the results from combining those elements. The function must also be able to accept no arguments.

+ If key is supplied, it is used is used to extract the values to reduce. The key function is applied exactly once to each element of sequence in the order implied by the reduction order but not to the value of initial-value, if supplied. The key function typically returns part of the element of sequence. If key is not supplied or is nil, the sequence element itself is used.

+The reduction is left-associative, unless from-end is true in which case it is right-associative.

+If initial-value is supplied, it is logically placed before the subsequence (or after it if from-end is true) and included in the reduction operation.

+In the normal case, the result of reduce is the combined result of function's being applied to successive pairs of elements of sequence. If the subsequence contains exactly one element and no initial-value is given, then that element is returned and function is not called. If the subsequence is empty and an initial-value is given, then the initial-value is returned and function is not called. If the subsequence is empty and no initial-value is given, then the function is called with zero arguments, and reduce returns whatever function does. This is the only case where the function is called with other than two arguments.

+

Examples:

+ +

+ (reduce #'* '(1 2 3 4 5)) =>  120
+ (reduce #'append '((1) (2)) :initial-value '(i n i t)) =>  (I N I T 1 2)
+ (reduce #'append '((1) (2)) :from-end t                  
+                             :initial-value '(i n i t)) =>  (1 2 I N I T) 
+ (reduce #'- '(1 2 3 4)) ==  (- (- (- 1 2) 3) 4) =>  -8
+ (reduce #'- '(1 2 3 4) :from-end t)    ;Alternating sum.
+==  (- 1 (- 2 (- 3 4))) =>  -2
+ (reduce #'+ '()) =>  0
+ (reduce #'+ '(3)) =>  3
+ (reduce #'+ '(foo)) =>  FOO
+ (reduce #'list '(1 2 3 4)) =>  (((1 2) 3) 4)
+ (reduce #'list '(1 2 3 4) :from-end t) =>  (1 (2 (3 4)))
+ (reduce #'list '(1 2 3 4) :initial-value 'foo) =>  ((((foo 1) 2) 3) 4)
+ (reduce #'list '(1 2 3 4)
+        :from-end t :initial-value 'foo) =>  (1 (2 (3 (4 foo))))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reinit.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reinit.htm new file mode 100644 index 00000000..4ae90260 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_reinit.htm @@ -0,0 +1,61 @@ + + + +CLHS: Standard Generic Function REINITIALIZE-INSTANCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function REINITIALIZE-INSTANCE

+

Syntax:

+

+ +reinitialize-instance instance &rest initargs &key &allow-other-keys => instance

+

+

Method Signatures:

+

+ +reinitialize-instance (instance standard-object) &rest initargs

+

+

Arguments and Values:

+

+instance---an object.

+initargs---an initialization argument list.

+

Description:

+

+The generic function reinitialize-instance can be used to change the values of local slots of an instance according to initargs. This generic function can be called by users.

+The system-supplied primary method for reinitialize-instance checks the validity of initargs and signals an error if an initarg is supplied that is not declared as valid. The method then calls the generic function shared-initialize with the following arguments: the instance, nil (which means no slots should be initialized according to their initforms), and the initargs it received.

+

Examples: None. +

+

Side Effects:

+

+The generic function reinitialize-instance changes the values of local slots.

+

Affected By: None. +

+

Exceptional Situations:

+

+The system-supplied primary method for reinitialize-instance signals an error if an initarg is supplied that is not declared as valid.

+

See Also:

+

+initialize-instance, shared-initialize, update-instance-for-redefined-class, update-instance-for-different-class, slot-boundp, slot-makunbound, Section 7.3 (Reinitializing an Instance), Section 7.1.4 (Rules for Initialization Arguments), Section 7.1.2 (Declaring the Validity of Initialization Arguments)

+

Notes:

+

+Initargs are declared as valid by using the :initarg option to defclass, or by defining methods for reinitialize-instance or shared-initialize. The keyword name of each keyword parameter specifier in the lambda list of any method defined on reinitialize-instance or shared-initialize is declared as a valid initialization argument name for all classes for which that method is applicable.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_remhas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_remhas.htm new file mode 100644 index 00000000..5fa7a842 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_remhas.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function REMHASH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REMHASH

+

Syntax:

+

+ +remhash key hash-table => generalized-boolean

+

+

Arguments and Values:

+

+key---an object.

+hash-table---a hash table.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Removes the entry for key in hash-table, if any. Returns true if there was such an entry, or false otherwise.

+

Examples:

+ +

+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32115666>
+ (setf (gethash 100 table) "C") =>  "C"
+ (gethash 100 table) =>  "C", true
+ (remhash 100 table) =>  true
+ (gethash 100 table) =>  NIL, false
+ (remhash 100 table) =>  false
+
+

+

Side Effects:

+

+The hash-table is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rempro.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rempro.htm new file mode 100644 index 00000000..9789bb0e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rempro.htm @@ -0,0 +1,86 @@ + + + +CLHS: Function REMPROP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REMPROP

+

Syntax:

+

+ +remprop symbol indicator => generalized-boolean

+

+

Arguments and Values:

+

+symbol---a symbol.

+indicator---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+remprop removes from the property list[2] of symbol a property[1] with a property indicator identical to indicator. If there are multiple properties[1] with the identical key, remprop only removes the first such property. remprop returns false if no such property was found, or true if a property was found.

+The property indicator and the corresponding property value are removed in an undefined order by destructively splicing the property list. The permissible side-effects correspond to those permitted for remf, such that:

+

+ (remprop x y) ==  (remf (symbol-plist x) y)
+
+

+

Examples:

+

+

+ (setq test (make-symbol "PSEUDO-PI")) =>  #:PSEUDO-PI
+ (symbol-plist test) =>  ()
+ (setf (get test 'constant) t) =>  T
+ (setf (get test 'approximation) 3.14) =>  3.14
+ (setf (get test 'error-range) 'noticeable) =>  NOTICEABLE
+ (symbol-plist test) 
+=>  (ERROR-RANGE NOTICEABLE APPROXIMATION 3.14 CONSTANT T)
+ (setf (get test 'approximation) nil) =>  NIL
+ (symbol-plist test) 
+=>  (ERROR-RANGE NOTICEABLE APPROXIMATION NIL CONSTANT T)
+ (get test 'approximation) =>  NIL
+ (remprop test 'approximation) =>  true
+ (get test 'approximation) =>  NIL
+ (symbol-plist test)
+=>  (ERROR-RANGE NOTICEABLE CONSTANT T)
+ (remprop test 'approximation) =>  NIL
+ (symbol-plist test)
+=>  (ERROR-RANGE NOTICEABLE CONSTANT T)
+ (remprop test 'error-range) =>  true
+ (setf (get test 'approximation) 3) =>  3
+ (symbol-plist test)
+=>  (APPROXIMATION 3 CONSTANT T)
+
+

+

Side Effects:

+

+The property list of symbol is modified.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+remf, symbol-plist

+

Notes:

+

+Numbers and characters are not recommended for use as indicators in portable code since remprop tests with eq rather than eql, and consequently the effect of using such indicators is implementation-dependent. Of course, if you've gotten as far as needing to remove such a property, you don't have much choice---the time to have been thinking about this was when you used setf of get to establish the property.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_replac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_replac.htm new file mode 100644 index 00000000..e0df58b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_replac.htm @@ -0,0 +1,69 @@ + + + +CLHS: Function REPLACE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REPLACE

+

Syntax:

+

+ +replace sequence-1 sequence-2 &key start1 end1 start2 end2 => sequence-1

+

+

Arguments and Values:

+

+sequence-1---a sequence.

+sequence-2---a sequence.

+ start1, end1---bounding index designators of sequence-1. The defaults for start1 and end1 are 0 and nil, respectively.

+start2, end2---bounding index designators of sequence-2. The defaults for start2 and end2 are 0 and nil, respectively.

+

Description:

+

+Destructively modifies sequence-1 by replacing the elements of subsequence-1 bounded by start1 and end1 with the elements of subsequence-2 bounded by start2 and end2.

+Sequence-1 is destructively modified by copying successive elements into it from sequence-2. Elements of the subsequence of sequence-2 bounded by start2 and end2 are copied into the subsequence of sequence-1 bounded by start1 and end1. If these subsequences are not of the same length, then the shorter length determines how many elements are copied; the extra elements near the end of the longer subsequence are not involved in the operation. The number of elements copied can be expressed as:

+

+ (min (- end1 start1) (- end2 start2))
+
+

+If sequence-1 and sequence-2 are the same object and the region being modified overlaps the region being copied from, then it is as if the entire source region were copied to another place and only then copied back into the target region. However, if sequence-1 and sequence-2 are not the same, but the region being modified overlaps the region being copied from (perhaps because of shared list structure or displaced arrays), then after the replace operation the subsequence of sequence-1 being modified will have unpredictable contents. It is an error if the elements of sequence-2 are not of a type that can be stored into sequence-1.

+

Examples:

+ +

+ (replace "abcdefghij" "0123456789" :start1 4 :end1 7 :start2 4) 
+=>  "abcd456hij"
+ (setq lst "012345678") =>  "012345678"
+ (replace lst lst :start1 2 :start2 0) =>  "010123456"
+ lst =>  "010123456"
+
+

+

Side Effects:

+

+The sequence-1 is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+fill

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rest.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rest.htm new file mode 100644 index 00000000..d2fb0ea7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rest.htm @@ -0,0 +1,69 @@ + + + +CLHS: Accessor REST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor REST

+

Syntax:

+

+ +rest list => tail

+ +(setf (rest list) new-tail)

+

+

Arguments and Values:

+

+list---a list, which might be a dotted list or a circular list.

+tail---an object.

+

Description:

+

+rest performs the same operation as cdr, but mnemonically complements first. Specifically,

+

+ (rest list) ==  (cdr list)
+ (setf (rest list) new-tail) ==  (setf (cdr list) new-tail)
+
+

+

Examples:

+

+

+ (rest '(1 2)) =>  (2)
+ (rest '(1 . 2)) =>  2
+ (rest '(1)) =>  NIL
+ (setq *cons* '(1 . 2)) =>  (1 . 2)
+ (setf (rest *cons*) "two") =>  "two"
+ *cons* =>  (1 . "two")
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+cdr, nthcdr

+

Notes:

+

+rest is often preferred stylistically over cdr when the argument is to being subjectively viewed as a list rather than as a cons.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revapp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revapp.htm new file mode 100644 index 00000000..a8e6c21f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revapp.htm @@ -0,0 +1,100 @@ + + + +CLHS: Function REVAPPEND, NRECONC + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REVAPPEND, NRECONC

+

+

Syntax:

+

+ +revappend list tail => result-list

+ +nreconc list tail => result-list

+

+

Arguments and Values:

+

+list---a proper list.

+tail---an object.

+result-list---an object.

+

Description:

+

+revappend constructs a copy[2] of list, but with the elements in reverse order. It then appends (as if by nconc) the tail to that reversed list and returns the result.

+nreconc reverses the order of elements in list (as if by nreverse). It then appends (as if by nconc) the tail to that reversed list and returns the result.

+The resulting list shares list structure with tail.

+

Examples:

+

+

+ (let ((list-1 (list 1 2 3))
+       (list-2 (list 'a 'b 'c)))
+   (print (revappend list-1 list-2))
+   (print (equal list-1 '(1 2 3)))
+   (print (equal list-2 '(a b c))))
+>>  (3 2 1 A B C) 
+>>  T
+>>  T
+=>  T
+
+ (revappend '(1 2 3) '()) =>  (3 2 1)
+ (revappend '(1 2 3) '(a . b)) =>  (3 2 1 A . B)
+ (revappend '() '(a b c)) =>  (A B C)
+ (revappend '(1 2 3) 'a) =>  (3 2 1 . A)
+ (revappend '() 'a) =>  A   ;degenerate case
+
+ (let ((list-1 '(1 2 3))
+       (list-2 '(a b c)))
+   (print (nreconc list-1 list-2))
+   (print (equal list-1 '(1 2 3)))
+   (print (equal list-2 '(a b c))))
+>>  (3 2 1 A B C) 
+>>  NIL
+>>  T
+=>  T
+
+
+

+

Side Effects:

+

+revappend does not modify either of its arguments. nreconc is permitted to modify list but not tail.

+ Although it might be implemented differently, nreconc is constrained to have side-effect behavior equivalent to:

+

+ (nconc (nreverse list) tail)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+reverse, nreverse, nconc

+

Notes:

+

+The following functional equivalences are true, although good implementations will typically use a faster algorithm for achieving the same effect:

+

+ (revappend list tail) ==  (nconc (reverse list) tail)
+ (nreconc list tail) ==  (nconc (nreverse list) tail)
+
+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revers.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revers.htm new file mode 100644 index 00000000..fb4f118c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_revers.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function REVERSE, NREVERSE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REVERSE, NREVERSE

+

Syntax:

+

+ +reverse sequence => reversed-sequence

+

+ +nreverse sequence => reversed-sequence

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+reversed-sequence---a sequence.

+

Description:

+

+reverse and nreverse return a new sequence of the same kind as sequence, containing the same elements, but in reverse order.

+reverse and nreverse differ in that reverse always creates and returns a new sequence, whereas nreverse might modify and return the given sequence. reverse never modifies the given sequence.

+For reverse, if sequence is a vector, the result is a fresh simple array of rank one that has the same actual array element type as sequence. If sequence is a list, the result is a fresh list.

+For nreverse, if sequence is a vector, the result is a vector that has the same actual array element type as sequence. If sequence is a list, the result is a list.

+For nreverse, sequence might be destroyed and re-used to produce the result. The result might or might not be identical to sequence. Specifically, when sequence is a list, nreverse is permitted to setf any part, car or cdr, of any cons that is part of the list structure of sequence. When sequence is a vector, nreverse is permitted to re-order the elements of sequence in order to produce the resulting vector.

+

Examples:

+ +

+ (setq str "abc") =>  "abc"
+ (reverse str) =>  "cba"
+ str =>  "abc"
+ (setq str (copy-seq str)) =>  "abc"
+ (nreverse str) =>  "cba"
+ str =>  implementation-dependent
+ (setq l (list 1 2 3)) =>  (1 2 3)
+ (nreverse l) =>  (3 2 1)
+ l =>  implementation-dependent
+
+

+

Side Effects:

+

+nreverse might either create a new sequence, modify the argument sequence, or both. (reverse does not modify sequence.)

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_dup.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_dup.htm new file mode 100644 index 00000000..8c35f30b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_dup.htm @@ -0,0 +1,83 @@ + + + +CLHS: Function REMOVE-DUPLICATES, DELETE-DUPLICATES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REMOVE-DUPLICATES, DELETE-DUPLICATES

+

Syntax:

+

+ +remove-duplicates sequence &key from-end test test-not start end key

=> result-sequence

+

+ +delete-duplicates sequence &key from-end test test-not start end key

=> result-sequence

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+key---a designator for a function of one argument, or nil.

+result-sequence---a sequence.

+

Description:

+

+remove-duplicates returns a modified copy of sequence from which any element that matches another element occurring in sequence has been removed.

+If sequence is a vector, the result is a vector that has the same actual array element type as sequence. If sequence is a list, the result is a list.

+delete-duplicates is like remove-duplicates, but delete-duplicates may modify sequence.

+The elements of sequence are compared pairwise, and if any two match, then the one occurring earlier in sequence is discarded, unless from-end is true, in which case the one later in sequence is discarded.

+remove-duplicates and delete-duplicates return a sequence of the same type as sequence with enough elements removed so that no two of the remaining elements match. The order of the elements remaining in the result is the same as the order in which they appear in sequence.

+remove-duplicates returns a sequence that may share with sequence or may be identical to sequence if no elements need to be removed.

+ delete-duplicates, when sequence is a list, is permitted to setf any part, car or cdr, of the top-level list structure in that sequence. When sequence is a vector, delete-duplicates is permitted to change the dimensions of the vector and to slide its elements into new positions without permuting them to produce the resulting vector.

+

Examples:

+

+

+ (remove-duplicates "aBcDAbCd" :test #'char-equal :from-end t) =>  "aBcD"
+ (remove-duplicates '(a b c b d d e)) =>  (A C B D E)
+ (remove-duplicates '(a b c b d d e) :from-end t) =>  (A B C D E)
+ (remove-duplicates '((foo #\a) (bar #\%) (baz #\A))
+     :test #'char-equal :key #'cadr) =>  ((BAR #\%) (BAZ #\A))
+ (remove-duplicates '((foo #\a) (bar #\%) (baz #\A)) 
+     :test #'char-equal :key #'cadr :from-end t) =>  ((FOO #\a) (BAR #\%))
+ (setq tester (list 0 1 2 3 4 5 6))
+ (delete-duplicates tester :key #'oddp :start 1 :end 6) =>  (0 4 5 6)
+
+

+

Side Effects:

+

+delete-duplicates might destructively modify sequence.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+ Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+If sequence is a vector, the result might or might not be simple, and might or might not be identical to sequence.

+ The :test-not argument is deprecated.

+These functions are useful for converting sequence into a canonical form suitable for representing a set.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_met.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_met.htm new file mode 100644 index 00000000..e5344118 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_met.htm @@ -0,0 +1,56 @@ + + + +CLHS: Standard Generic Function REMOVE-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function REMOVE-METHOD

+

Syntax:

+

+ +remove-method generic-function method => generic-function

+

+

Method Signatures:

+

+ +remove-method (generic-function standard-generic-function) method

+

+

Arguments and Values:

+

+generic-function---a generic function.

+method---a method.

+

Description:

+

+The generic function remove-method removes a method from generic-function by modifying the generic-function (if necessary).

+remove-method must not signal an error if the method is not one of the methods on the generic-function.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+find-method

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_rm.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_rm.htm new file mode 100644 index 00000000..dd88855c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rm_rm.htm @@ -0,0 +1,137 @@ + + + +CLHS: Function REMOVE, REMOVE-IF, REMOVE-IF-NOT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT

+

Syntax:

+

+ +remove item sequence &key from-end test test-not start end count key => result-sequence

+

+ +remove-if test sequence &key from-end start end count key => result-sequence

+

+ +remove-if-not test sequence &key from-end start end count key => result-sequence

+

+ +delete item sequence &key from-end test test-not start end count key => result-sequence

+

+ +delete-if test sequence &key from-end start end count key => result-sequence

+

+ +delete-if-not test sequence &key from-end start end count key => result-sequence

+

+

Arguments and Values:

+

+item---an object.

+sequence---a proper sequence.

+test---a designator for a function of one argument that returns a generalized boolean.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+ count---an integer or nil. The default is nil.

+key---a designator for a function of one argument, or nil.

+result-sequence---a sequence.

+

Description:

+

+remove, remove-if, and remove-if-not return a sequence from which the elements that satisfy the test have been removed.

+delete, delete-if, and delete-if-not are like remove, remove-if, and remove-if-not respectively, but they may modify sequence.

+If sequence is a vector, the result is a vector that has the same actual array element type as sequence. If sequence is a list, the result is a list.

+Supplying a from-end of true matters only when the count is provided; in that case only the rightmost count elements satisfying the test are deleted.

+Count, if supplied, limits the number of elements removed or deleted; if more than count elements satisfy the test, then of these elements only the leftmost or rightmost, depending on from-end, are deleted or removed, as many as specified by count. If count is supplied and negative, the behavior is as if zero had been supplied instead. If count is nil, all matching items are affected.

+For all these functions, elements not removed or deleted occur in the same order in the result as they did in sequence.

+remove, remove-if, remove-if-not return a sequence of the same type as sequence that has the same elements except that those in the subsequence bounded by start and end and satisfying the test have been removed. This is a non-destructive operation. If any elements need to be removed, the result will be a copy. The result of remove may share with sequence; the result may be identical to the input sequence if no elements need to be removed.

+delete, delete-if, and delete-if-not return a sequence of the same type as sequence that has the same elements except that those in the subsequence bounded by start and end and satisfying the test have been deleted. Sequence may be destroyed and used to construct the result; however, the result might or might not be identical to sequence.

+ delete, when sequence is a list, is permitted to setf any part, car or cdr, of the top-level list structure in that sequence. When sequence is a vector, delete is permitted to change the dimensions of the vector and to slide its elements into new positions without permuting them to produce the resulting vector.

+delete-if is constrained to behave exactly as follows:

+

+ (delete nil sequence
+             :test #'(lambda (ignore item) (funcall test item))
+             ...)
+
+

+

+

Examples:

+ +

+ (remove 4 '(1 3 4 5 9)) =>  (1 3 5 9)
+ (remove 4 '(1 2 4 1 3 4 5)) =>  (1 2 1 3 5)
+ (remove 4 '(1 2 4 1 3 4 5) :count 1) =>  (1 2 1 3 4 5)
+ (remove 4 '(1 2 4 1 3 4 5) :count 1 :from-end t) =>  (1 2 4 1 3 5)
+ (remove 3 '(1 2 4 1 3 4 5) :test #'>) =>  (4 3 4 5)
+ (setq lst '(list of four elements)) =>  (LIST OF FOUR ELEMENTS)
+ (setq lst2 (copy-seq lst)) =>  (LIST OF FOUR ELEMENTS)
+ (setq lst3 (delete 'four lst)) =>  (LIST OF ELEMENTS)
+ (equal lst lst2) =>  false
+ (remove-if #'oddp '(1 2 4 1 3 4 5)) =>  (2 4 4)
+ (remove-if #'evenp '(1 2 4 1 3 4 5) :count 1 :from-end t) 
+=>  (1 2 4 1 3 5)
+ (remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9) :count 2 :from-end t)
+=>  (1 2 3 4 5 6 8)
+ (setq tester (list 1 2 4 1 3 4 5)) =>  (1 2 4 1 3 4 5)
+ (delete 4 tester) =>  (1 2 1 3 5)
+ (setq tester (list 1 2 4 1 3 4 5)) =>  (1 2 4 1 3 4 5)
+ (delete 4 tester :count 1) =>  (1 2 1 3 4 5)
+ (setq tester (list 1 2 4 1 3 4 5)) =>  (1 2 4 1 3 4 5)
+ (delete 4 tester :count 1 :from-end t) =>  (1 2 4 1 3 5)
+ (setq tester (list 1 2 4 1 3 4 5)) =>  (1 2 4 1 3 4 5)
+ (delete 3 tester :test #'>) =>  (4 3 4 5)
+ (setq tester (list 1 2 4 1 3 4 5)) =>  (1 2 4 1 3 4 5)
+ (delete-if #'oddp tester) =>  (2 4 4)
+ (setq tester (list 1 2 4 1 3 4 5)) =>  (1 2 4 1 3 4 5)
+ (delete-if #'evenp tester :count 1 :from-end t) =>  (1 2 4 1 3 5)    
+ (setq tester (list 1 2 3 4 5 6)) =>  (1 2 3 4 5 6) 
+ (delete-if #'evenp tester) =>  (1 3 5) 
+ tester =>  implementation-dependent
+
+

+ +

+ (setq foo (list 'a 'b 'c)) =>  (A B C)
+ (setq bar (cdr foo)) =>  (B C)
+ (setq foo (delete 'b foo)) =>  (A C)
+ bar =>  ((C)) or ...
+ (eq (cdr foo) (car bar)) =>  T or ...
+
+

+

Side Effects:

+

+For delete, delete-if, and delete-if-not, sequence may be destroyed and used to construct the result.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+ Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+If sequence is a vector, the result might or might not be simple, and might or might not be identical to sequence.

+ The :test-not argument is deprecated.

+ The functions delete-if-not and remove-if-not are deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_fil.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_fil.htm new file mode 100644 index 00000000..9b2bb0e2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_fil.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function RENAME-FILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RENAME-FILE

+

Syntax:

+

+ +rename-file filespec new-name => defaulted-new-name, old-truename, new-truename

+

+

Arguments and Values:

+

+ filespec---a pathname designator.

+new-name---a pathname designator other than a stream.

+defaulted-new-name---a pathname

+old-truename---a physical pathname.

+new-truename---a physical pathname.

+

Description:

+

+rename-file modifies the file system in such a way that the file indicated by filespec is renamed to defaulted-new-name.

+It is an error to specify a filename containing a wild component, for filespec to contain a nil component where the file system does not permit a nil component, or for the result of defaulting missing components of new-name from filespec to contain a nil component where the file system does not permit a nil component.

+ If new-name is a logical pathname, rename-file returns a logical pathname as its primary value.

+rename-file returns three values if successful. The primary value, defaulted-new-name, is the resulting name which is composed of new-name with any missing components filled in by performing a merge-pathnames operation using filespec as the defaults. The secondary value, old-truename, is the truename of the file before it was renamed. The tertiary value, new-truename, is the truename of the file after it was renamed.

+If the filespec designator is an open stream, then the stream itself and the file associated with it are affected (if the file system permits).

+

Examples:

+

+

+;; An example involving logical pathnames.
+ (with-open-file (stream "sys:chemistry;lead.text"
+                         :direction :output :if-exists :error)
+   (princ "eureka" stream)
+   (values (pathname stream) (truename stream)))
+=>  #P"SYS:CHEMISTRY;LEAD.TEXT.NEWEST", #P"Q:>sys>chem>lead.text.1"
+ (rename-file "sys:chemistry;lead.text" "gold.text")
+=>  #P"SYS:CHEMISTRY;GOLD.TEXT.NEWEST",
+   #P"Q:>sys>chem>lead.text.1",
+   #P"Q:>sys>chem>gold.text.1"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If the renaming operation is not successful, an error of type file-error is signaled.

+ An error of type file-error might be signaled if filespec is wild.

+

See Also:

+

+ truename, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_pkg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_pkg.htm new file mode 100644 index 00000000..1bf86895 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rn_pkg.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function RENAME-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RENAME-PACKAGE

+

Syntax:

+

+ +rename-package package new-name &optional new-nicknames => package-object

+

+

Arguments and Values:

+

+ package---a package designator.

+new-name---a package designator.

+new-nicknames---a list of string designators. The default is the empty list.

+ package-object---the renamed package object.

+

Description:

+

+Replaces the name and nicknames of package. The old name and all of the old nicknames of package are eliminated and are replaced by new-name and new-nicknames.

+The consequences are undefined if new-name or any new-nickname conflicts with any existing package names.

+

Examples:

+

+

+ (make-package 'temporary :nicknames '("TEMP")) =>  #<PACKAGE "TEMPORARY">
+ (rename-package 'temp 'ephemeral) =>  #<PACKAGE "EPHEMERAL">
+ (package-nicknames (find-package 'ephemeral)) =>  ()
+ (find-package 'temporary) =>  NIL
+ (rename-package 'ephemeral 'temporary '(temp fleeting))
+=>  #<PACKAGE "TEMPORARY">
+ (package-nicknames (find-package 'temp)) =>  ("TEMP" "FLEETING")
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-package

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rnd_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rnd_st.htm new file mode 100644 index 00000000..8a065439 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rnd_st.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function RANDOM-STATE-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RANDOM-STATE-P

+

Syntax:

+

+ +random-state-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type random-state; otherwise, returns false.

+

Examples:

+

+

+ (random-state-p *random-state*) =>  true
+ (random-state-p (make-random-state)) =>  true
+ (random-state-p 'test-function) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-random-state, *random-state*

+

Notes:

+

+

+ (random-state-p object) ==  (typep object 'random-state)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_room.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_room.htm new file mode 100644 index 00000000..bb8b6e8c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_room.htm @@ -0,0 +1,53 @@ + + + +CLHS: Function ROOM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ROOM

+

Syntax:

+

+ +room &optional x => implementation-dependent

+

+

Arguments and Values:

+

+x---one of t, nil, or :default.

+

Description:

+

+room prints, to standard output, information about the state of internal storage and its management. This might include descriptions of the amount of memory in use and the degree of memory compaction, possibly broken down by internal data type if that is appropriate. The nature and format of the printed information is implementation-dependent. The intent is to provide information that a programmer might use to tune a program for a particular implementation.

+(room nil) prints out a minimal amount of information. (room t) prints out a maximal amount of information. (room) or (room :default) prints out an intermediate amount of information that is likely to be useful.

+

Examples: None. +

+

Side Effects:

+

+Output to standard output.

+

Affected By:

+

+*standard-output*.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_row_ma.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_row_ma.htm new file mode 100644 index 00000000..906ad839 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_row_ma.htm @@ -0,0 +1,68 @@ + + + +CLHS: Accessor ROW-MAJOR-AREF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor ROW-MAJOR-AREF

+

Syntax:

+

+ +row-major-aref array index => element

+ +(setf (row-major-aref array index) new-element)

+

+

Arguments and Values:

+

+array---an array.

+ index---a valid array row-major index for the array.

+element, new-element---an object.

+

Description:

+

+Considers array as a vector by viewing its elements in row-major order, and returns the element of that vector which is referred to by the given index.

+row-major-aref is valid for use with setf.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+aref, array-row-major-index

+

Notes:

+

+

+ (row-major-aref array index) == 
+   (aref (make-array (array-total-size array)
+                     :displaced-to array
+                     :element-type (array-element-type array))
+         index)
+
+ (aref array i1 i2 ...) == 
+     (row-major-aref array (array-row-major-index array i1 i2))
+
+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rplaca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rplaca.htm new file mode 100644 index 00000000..d317af6f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rplaca.htm @@ -0,0 +1,69 @@ + + + +CLHS: Function RPLACA, RPLACD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RPLACA, RPLACD

+

Syntax:

+

+ +rplaca cons object => cons

+ +rplacd cons object => cons

+

+

Pronunciation:

+

+rplaca: [,ree'plakuh] or [,ruh'plakuh]

+rplacd: [,ree'plakduh] or [,ruh'plakduh] or [,ree'plakdee] or [,ruh'plakdee]

+

Arguments and Values:

+

+cons---a cons.

+object---an object.

+

Description:

+

+rplaca replaces the car of the cons with object.

+rplacd replaces the cdr of the cons with object.

+

Examples:

+ +

+ (defparameter *some-list* (list* 'one 'two 'three 'four)) =>  *some-list*
+ *some-list* =>  (ONE TWO THREE . FOUR)
+ (rplaca *some-list* 'uno) =>  (UNO TWO THREE . FOUR)
+ *some-list* =>  (UNO TWO THREE . FOUR)
+ (rplacd (last *some-list*) (list 'IV)) =>  (THREE IV)
+ *some-list* =>  (UNO TWO THREE IV)
+
+

+

Side Effects:

+

+The cons is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+Should signal an error of type type-error if cons is not a cons.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rst_na.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rst_na.htm new file mode 100644 index 00000000..01ec7f6d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_rst_na.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function RESTART-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function RESTART-NAME

+

Syntax:

+

+ +restart-name restart => name

+

+

Arguments and Values:

+

+restart---a restart.

+name---a symbol.

+

Description:

+

+Returns the name of the restart, or nil if the restart is not named.

+

Examples:

+

+

+ (restart-case 
+     (loop for restart in (compute-restarts)
+               collect (restart-name restart))
+   (case1 () :report "Return 1." 1)
+   (nil   () :report "Return 2." 2)
+   (case3 () :report "Return 3." 3)
+   (case1 () :report "Return 4." 4))
+=>  (CASE1 NIL CASE3 CASE1 ABORT)
+ ;; In the example above the restart named ABORT was not created
+ ;; explicitly, but was implicitly supplied by the system.
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+compute-restarts find-restart

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sbs_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sbs_s.htm new file mode 100644 index 00000000..188512bd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sbs_s.htm @@ -0,0 +1,123 @@ + + + +CLHS: Function SUBSTITUTE, SUBSTITUTE-IF... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT

+

Syntax:

+

+ +substitute newitem olditem sequence &key from-end test test-not start end count key

=> result-sequence

+

+ +substitute-if newitem predicate sequence &key from-end start end count key

=> result-sequence

+

+ +substitute-if-not newitem predicate sequence &key from-end start end count key

=> result-sequence

+

+ +nsubstitute newitem olditem sequence &key from-end test test-not start end count key

=> sequence

+

+ +nsubstitute-if newitem predicate sequence &key from-end start end count key

=> sequence

+

+ +nsubstitute-if-not newitem predicate sequence &key from-end start end count key

=> sequence

+

+

Arguments and Values:

+

+newitem---an object.

+olditem---an object.

+sequence---a proper sequence.

+predicate---a designator for a function of one argument that returns a generalized boolean.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+ start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+ count---an integer or nil. The default is nil.

+key---a designator for a function of one argument, or nil.

+result-sequence---a sequence.

+

Description:

+

+substitute, substitute-if, and substitute-if-not return a copy of sequence in which each element that satisfies the test has been replaced with newitem.

+nsubstitute, nsubstitute-if, and nsubstitute-if-not are like substitute, substitute-if, and substitute-if-not respectively, but they may modify sequence.

+If sequence is a vector, the result is a vector that has the same actual array element type as sequence. If sequence is a list, the result is a list.

+Count, if supplied, limits the number of elements altered; if more than count elements satisfy the test, then of these elements only the leftmost or rightmost, depending on from-end, are replaced, as many as specified by count. If count is supplied and negative, the behavior is as if zero had been supplied instead. If count is nil, all matching items are affected.

+Supplying a from-end of true matters only when the count is provided (and non-nil); in that case, only the rightmost count elements satisfying the test are removed (instead of the leftmost).

+predicate, test, and test-not might be called more than once for each sequence element, and their side effects can happen in any order.

+The result of all these functions is a sequence of the same type as sequence that has the same elements except that those in the subsequence bounded by start and end and satisfying the test have been replaced by newitem.

+substitute, substitute-if, and substitute-if-not return a sequence which can share with sequence or may be identical to the input sequence if no elements need to be changed.

+ nsubstitute and nsubstitute-if are required to setf any car (if sequence is a list) or aref (if sequence is a vector) of sequence that is required to be replaced with newitem. If sequence is a list, none of the cdrs of the top-level list can be modified.

+

Examples:

+

+

+ (substitute #\. #\SPACE "0 2 4 6") =>  "0.2.4.6"
+ (substitute 9 4 '(1 2 4 1 3 4 5)) =>  (1 2 9 1 3 9 5)
+ (substitute 9 4 '(1 2 4 1 3 4 5) :count 1) =>  (1 2 9 1 3 4 5)
+ (substitute 9 4 '(1 2 4 1 3 4 5) :count 1 :from-end t)
+=>  (1 2 4 1 3 9 5)
+ (substitute 9 3 '(1 2 4 1 3 4 5) :test #'>) =>  (9 9 4 9 3 4 5)
+
+ (substitute-if 0 #'evenp '((1) (2) (3) (4)) :start 2 :key #'car)
+=>  ((1) (2) (3) 0)
+ (substitute-if 9 #'oddp '(1 2 4 1 3 4 5)) =>  (9 2 4 9 9 4 9)
+ (substitute-if 9 #'evenp '(1 2 4 1 3 4 5) :count 1 :from-end t)
+=>  (1 2 4 1 3 9 5)
+
+ (setq some-things (list 'a 'car 'b 'cdr 'c)) =>  (A CAR B CDR C)
+ (nsubstitute-if "function was here" #'fboundp some-things
+                 :count 1 :from-end t) =>  (A CAR B "function was here" C)
+ some-things =>  (A CAR B "function was here" C)
+ (setq alpha-tester (copy-seq "ab ")) =>  "ab "
+ (nsubstitute-if-not #\z #'alpha-char-p alpha-tester) =>  "abz"
+ alpha-tester =>  "abz"
+
+

+

Side Effects:

+

+nsubstitute, nsubstitute-if, and nsubstitute-if-not modify sequence.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+subst, nsubst, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+If sequence is a vector, the result might or might not be simple, and might or might not be identical to sequence.

+ The :test-not argument is deprecated.

+ The functions substitute-if-not and nsubstitute-if-not are deprecated.

+nsubstitute and nsubstitute-if can be used in for-effect-only positions in code.

+Because the side-effecting variants (e.g., nsubstitute) potentially change the path that is being traversed, their effects in the presence of shared or circular structure may vary in surprising ways when compared to their non-side-effecting alternatives. To see this, consider the following side-effect behavior, which might be exhibited by some implementations:

+

+ (defun test-it (fn)
+   (let ((x (cons 'b nil)))
+     (rplacd x x)
+     (funcall fn 'a 'b x :count 1)))
+ (test-it #'substitute) =>  (A . #1=(B . #1#))
+ (test-it #'nsubstitute) =>  (A . #1#)
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_search.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_search.htm new file mode 100644 index 00000000..4aec1abb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_search.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function SEARCH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SEARCH

+

Syntax:

+

+ +search sequence-1 sequence-2 &key from-end test test-not key start1 start2 end1 end2

=> position

+

+

Arguments and Values:

+

+Sequence-1---a sequence.

+Sequence-2---a sequence.

+from-end---a generalized boolean. The default is false.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+ start1, end1---bounding index designators of sequence-1. The defaults for start1 and end1 are 0 and nil, respectively.

+start2, end2---bounding index designators of sequence-2. The defaults for start2 and end2 are 0 and nil, respectively.

+position---a bounding index of sequence-2, or nil.

+

Description:

+

+Searches sequence-2 for a subsequence that matches sequence-1.

+The implementation may choose to search sequence-2 in any order; there is no guarantee on the number of times the test is made. For example, when start-end is true, the sequence might actually be searched from left to right instead of from right to left (but in either case would return the rightmost matching subsequence). If the search succeeds, search returns the offset into sequence-2 of the first element of the leftmost or rightmost matching subsequence, depending on from-end; otherwise search returns nil.

+If from-end is true, the index of the leftmost element of the rightmost matching subsequence is returned.

+

Examples:

+ +

+ (search "dog" "it's a dog's life") =>  7
+ (search '(0 1) '(2 4 6 1 3 5) :key #'oddp) =>  2
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not argument is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set.htm new file mode 100644 index 00000000..13c8ed8f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set.htm @@ -0,0 +1,94 @@ + + + +CLHS: Function SET + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET

+

Syntax:

+

+ +set symbol value => value

+

+

Arguments and Values:

+

+symbol---a symbol.

+ value---an object.

+

Description:

+

+set changes the contents of the value cell of symbol to the given value.

+

+(set symbol value) ==  (setf (symbol-value symbol) value)
+
+

+

Examples:

+

+

+ (setf (symbol-value 'n) 1) =>  1
+ (set 'n 2) =>  2
+ (symbol-value 'n) =>  2
+ (let ((n 3))
+   (declare (special n))
+   (setq n (+ n 1))
+   (setf (symbol-value 'n) (* n 10))
+   (set 'n (+ (symbol-value 'n) n))
+   n) =>  80
+ n =>  2
+ (let ((n 3))
+   (setq n (+ n 1))
+   (setf (symbol-value 'n) (* n 10))
+   (set 'n (+ (symbol-value 'n) n))
+   n) =>  4
+ n =>  44
+ (defvar *n* 2)
+ (let ((*n* 3))
+   (setq *n* (+ *n* 1))
+   (setf (symbol-value '*n*) (* *n* 10))
+   (set '*n* (+ (symbol-value '*n*) *n*))
+   *n*) =>  80
+  *n* =>  2
+ (defvar *even-count* 0) =>  *EVEN-COUNT*
+ (defvar *odd-count* 0) =>  *ODD-COUNT*
+ (defun tally-list (list)
+   (dolist (element list)
+     (set (if (evenp element) '*even-count* '*odd-count*)
+          (+ element (if (evenp element) *even-count* *odd-count*)))))
+ (tally-list '(1 9 4 3 2 7)) =>  NIL
+ *even-count* =>  6
+ *odd-count* =>  20
+
+

+

Side Effects:

+

+The value of symbol is changed.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+setq, progv, symbol-value

+

Notes:

+

+The function set is deprecated.

+set cannot change the value of a lexical variable.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set__1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set__1.htm new file mode 100644 index 00000000..20530c1d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set__1.htm @@ -0,0 +1,88 @@ + + + +CLHS: Function SET-DISPATCH-MACRO-CHARACTER... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET-DISPATCH-MACRO-CHARACTER, GET-DISPATCH-MACRO-CHARACTER

+

Syntax:

+

+ +get-dispatch-macro-character disp-char sub-char &optional readtable => function

+

+ +set-dispatch-macro-character disp-char sub-char new-function &optional readtable => t

+

+

Arguments and Values:

+

+disp-char---a character.

+sub-char---a character.

+ readtable---a readtable designator. The default is the current readtable.

+function---a function designator or nil.

+new-function---a function designator.

+

Description:

+

+set-dispatch-macro-character causes new-function to be called when disp-char followed by sub-char is read. If sub-char is a lowercase letter, it is converted to its uppercase equivalent. It is an error if sub-char is one of the ten decimal digits.

+set-dispatch-macro-character installs a new-function to be called when a particular dispatching macro character pair is read. New-function is installed as the dispatch function to be called when readtable is in use and when disp-char is followed by sub-char.

+For more information about how the new-function is invoked, see Section 2.1.4.4 (Macro Characters).

+get-dispatch-macro-character retrieves the dispatch function associated with disp-char and sub-char in readtable.

+get-dispatch-macro-character returns the macro-character function for sub-char under disp-char, or nil if there is no function associated with sub-char. If sub-char is a decimal digit, get-dispatch-macro-character returns nil.

+

Examples:

+

+

+ (get-dispatch-macro-character #\# #\{) =>  NIL
+ (set-dispatch-macro-character #\# #\{        ;dispatch on #{
+    #'(lambda(s c n)
+        (let ((list (read s nil (values) t)))  ;list is object after #n{
+          (when (consp list)                   ;return nth element of list
+            (unless (and n (< 0 n (length list))) (setq n 0))
+            (setq list (nth n list)))
+         list))) =>  T
+ #{(1 2 3 4) =>  1
+ #3{(0 1 2 3) =>  3
+ #{123 =>  123
+
+ If it is desired that #$foo : as if it were (dollars foo).

+

+(defun |#$-reader| (stream subchar arg)
+   (declare (ignore subchar arg))
+   (list 'dollars (read stream t nil t))) =>  |#$-reader|
+ (set-dispatch-macro-character #\# #\$ #'|#$-reader|) =>  T
+
+

+

See Also:

+

+Section 2.1.4.4 (Macro Characters)

+

Side Effects:

+

+The readtable is modified.

+

Affected By:

+

+*readtable*.

+

Exceptional Situations:

+

+For either function, an error is signaled if disp-char is not a dispatching macro character in readtable.

+

See Also:

+

+*readtable*

+

Notes:

+ It is necessary to use make-dispatch-macro-character to set up the dispatch character before specifying its sub-characters.

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_di.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_di.htm new file mode 100644 index 00000000..e5f26139 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_di.htm @@ -0,0 +1,91 @@ + + + +CLHS: Function SET-DIFFERENCE, NSET-DIFFERENCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET-DIFFERENCE, NSET-DIFFERENCE

+

Syntax:

+

+ +set-difference list-1 list-2 &key key test test-not => result-list

+ +nset-difference list-1 list-2 &key key test test-not => result-list

+

+

Arguments and Values:

+

+list-1---a proper list.

+list-2---a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+result-list---a list.

+

Description:

+ set-difference returns a list of elements of list-1 that do not appear in list-2.

+nset-difference is the destructive version of set-difference. It may destroy list-1.

+For all possible ordered pairs consisting of one element from list-1 and one element from list-2, the :test or :test-not function is used to determine whether they satisfy the test. The first argument to the :test or :test-not function is the part of an element of list-1 that is returned by the :key function (if supplied); the second argument is the part of an element of list-2 that is returned by the :key function (if supplied).

+If :key is supplied, its argument is a list-1 or list-2 element. The :key function typically returns part of the supplied element. If :key is not supplied, the list-1 or list-2 element is used.

+An element of list-1 appears in the result if and only if it does not match any element of list-2.

+There is no guarantee that the order of elements in the result will reflect the ordering of the arguments in any particular way. The result list may share cells with, or be eq to, either of list-1 or list-2, if appropriate.

+

Examples:

+

+

+ (setq lst1 (list "A" "b" "C" "d")
+       lst2 (list "a" "B" "C" "d")) =>  ("a" "B" "C" "d")
+ (set-difference lst1 lst2) =>  ("d" "C" "b" "A")
+ (set-difference lst1 lst2 :test 'equal) =>  ("b" "A")
+ (set-difference lst1 lst2 :test #'equalp) =>  NIL 
+ (nset-difference lst1 lst2 :test #'string=) =>  ("A" "b")
+ (setq lst1 '(("a" . "b") ("c" . "d") ("e" . "f")))
+=>  (("a" . "b") ("c" . "d") ("e" . "f")) 
+ (setq lst2 '(("c" . "a") ("e" . "b") ("d" . "a")))
+=>  (("c" . "a") ("e" . "b") ("d" . "a")) 
+ (nset-difference lst1 lst2 :test #'string= :key #'cdr)
+=>  (("c" . "d") ("e" . "f")) 
+ lst1 =>  (("a" . "b") ("c" . "d") ("e" . "f")) 
+ lst2 =>  (("c" . "a") ("e" . "b") ("d" . "a")) 
+
+ +
+;; Remove all flavor names that contain "c" or "w".
+ (set-difference '("strawberry" "chocolate" "banana"
+                  "lemon" "pistachio" "rhubarb")
+          '(#\c #\w)
+          :test #'(lambda (s c) (find c s)))
+=>  ("banana" "rhubarb" "lemon")    ;One possible ordering.
+
+

+

Side Effects:

+

+nset-difference may destroy list-1.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list-1 and list-2 are not proper lists.

+

See Also:

+

+ Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ex.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ex.htm new file mode 100644 index 00000000..80a80fe6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ex.htm @@ -0,0 +1,84 @@ + + + +CLHS: Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR

+

Syntax:

+

+ +set-exclusive-or list-1 list-2 &key key test test-not => result-list

+ +nset-exclusive-or list-1 list-2 &key key test test-not => result-list

+

+

Arguments and Values:

+

+list-1---a proper list.

+list-2---a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+result-list---a list.

+

Description:

+ set-exclusive-or returns a list of elements that appear in exactly one of list-1 and list-2.

+nset-exclusive-or is the destructive version of set-exclusive-or.

+For all possible ordered pairs consisting of one element from list-1 and one element from list-2, the :test or :test-not function is used to determine whether they satisfy the test.

+If :key is supplied, it is used to extract the part to be tested from the list-1 or list-2 element. The first argument to the :test or :test-not function is the part of an element of list-1 extracted by the :key function (if supplied); the second argument is the part of an element of list-2 extracted by the :key function (if supplied). If :key is not supplied or nil, the list-1 or list-2 element is used.

+The result contains precisely those elements of list-1 and list-2 that appear in no matching pair.

+The result list of set-exclusive-or might share storage with one of list-1 or list-2.

+

Examples:

+

+

+ (setq lst1 (list 1 "a" "b")
+       lst2 (list 1 "A" "b")) =>  (1 "A" "b")
+ (set-exclusive-or lst1 lst2) =>  ("b" "A" "b" "a")
+ (set-exclusive-or lst1 lst2 :test #'equal) =>  ("A" "a")
+ (set-exclusive-or lst1 lst2 :test 'equalp) =>  NIL 
+ (nset-exclusive-or lst1 lst2) =>  ("a" "b" "A" "b") 
+ (setq lst1 (list (("a" . "b") ("c" . "d") ("e" . "f"))))
+=>  (("a" . "b") ("c" . "d") ("e" . "f"))
+ (setq lst2 (list (("c" . "a") ("e" . "b") ("d" . "a"))))
+=>  (("c" . "a") ("e" . "b") ("d" . "a")) 
+ (nset-exclusive-or lst1 lst2 :test #'string= :key #'cdr)
+=>  (("c" . "d") ("e" . "f") ("c" . "a") ("d" . "a")) 
+ lst1 =>  (("a" . "b") ("c" . "d") ("e" . "f"))
+ lst2 =>  (("c" . "a") ("d" . "a")) 
+
+

+

Side Effects:

+

+ nset-exclusive-or is permitted to modify any part, car or cdr, of the list structure of list-1 or list-2.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list-1 and list-2 are not proper lists.

+

See Also:

+

+ Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+ Since the nset-exclusive-or side effect is not required, it should not be used in for-effect-only positions in portable code.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ma.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ma.htm new file mode 100644 index 00000000..35106102 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_ma.htm @@ -0,0 +1,86 @@ + + + +CLHS: Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER

+

Syntax:

+

+ +get-macro-character char &optional readtable => function, non-terminating-p

+

+ +set-macro-character char new-function &optional non-terminating-p readtable => t

+

+

Arguments and Values:

+

+char---a character.

+non-terminating-p---a generalized boolean. The default is false.

+ readtable---a readtable designator. The default is the current readtable.

+function---nil, or a designator for a function of two arguments.

+new-function---a function designator.

+

Description:

+

+get-macro-character returns as its primary value, function, the reader macro function associated with char in readtable (if any), or else nil if char is not a macro character in readtable. The secondary value, non-terminating-p, is true if char is a non-terminating macro character; otherwise, it is false.

+set-macro-character causes char to be a macro character associated with the reader macro function new-function (or the designator for new-function) in readtable. If non-terminating-p is true, char becomes a non-terminating macro character; otherwise it becomes a terminating macro character.

+

Examples:

+

+

+ (get-macro-character #\{) =>  NIL, false
+ (not (get-macro-character #\;)) =>  false
+
+

+The following is a possible definition for the single-quote reader macro in standard syntax:

+

+ (defun single-quote-reader (stream char)
+   (declare (ignore char))
+   (list 'quote (read stream t nil t))) =>  SINGLE-QUOTE-READER
+ (set-macro-character #\' #'single-quote-reader) =>  T
+
+

+Here single-quote-reader reads an object following the single-quote and returns a list of quote and that object. The char argument is ignored.

+The following is a possible definition for the semicolon reader macro in standard syntax:

+

+ (defun semicolon-reader (stream char)
+   (declare (ignore char))
+   ;; First swallow the rest of the current input line.
+   ;; End-of-file is acceptable for terminating the comment.
+   (do () ((char= (read-char stream nil #\Newline t) #\Newline)))
+   ;; Return zero values.
+   (values)) =>  SEMICOLON-READER
+ (set-macro-character #\; #'semicolon-reader) =>  T
+
+

+

Side Effects:

+

+The readtable is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+*readtable*

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_pp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_pp.htm new file mode 100644 index 00000000..2c910e48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_pp.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function SET-PPRINT-DISPATCH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET-PPRINT-DISPATCH

+

+

Syntax:

+

+ +set-pprint-dispatch type-specifier function &optional priority table => nil

+

+

Arguments and Values:

+

+type-specifier---a type specifier.

+function---a function, a function name, or nil.

+priority---a real. The default is 0.

+table---a pprint dispatch table. The default is the value of *print-pprint-dispatch*.

+

Description:

+

+Installs an entry into the pprint dispatch table which is table.

+Type-specifier is the key of the entry. The first action of set-pprint-dispatch is to remove any pre-existing entry associated with type-specifier. This guarantees that there will never be two entries associated with the same type specifier in a given pprint dispatch table. Equality of type specifiers is tested by equal.

+Two values are associated with each type specifier in a pprint dispatch table: a function and a priority. The function must accept two arguments: the stream to which output is sent and the object to be printed. The function should pretty print the object to the stream. The function can assume that object satisfies the type given by type-specifier. The function must obey *print-readably*. Any values returned by the function are ignored.

+Priority is a priority to resolve conflicts when an object matches more than one entry.

+It is permissible for function to be nil. In this situation, there will be no type-specifier entry in table after set-pprint-dispatch returns.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+An error is signaled if priority is not a real.

+

See Also: None. +

+

Notes:

+

+Since pprint dispatch tables are often used to control the pretty printing of Lisp code, it is common for the type-specifier to be an expression of the form

+

+ (cons car-type cdr-type)
+
+

+This signifies that the corresponding object must be a cons cell whose car matches the type specifier car-type and whose cdr matches the type specifier cdr-type. The cdr-type can be omitted in which case it defaults to t.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_sy.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_sy.htm new file mode 100644 index 00000000..d404018e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_set_sy.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function SET-SYNTAX-FROM-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SET-SYNTAX-FROM-CHAR

+

Syntax:

+

+ +set-syntax-from-char to-char from-char &optional to-readtable from-readtable => t

+

+

Arguments and Values:

+

+ to-char---a character.

+from-char---a character.

+to-readtable---a readtable. The default is the current readtable.

+from-readtable---a readtable designator. The default is the standard readtable.

+

Description:

+

+set-syntax-from-char makes the syntax of to-char in to-readtable be the same as the syntax of from-char in from-readtable.

+set-syntax-from-char copies the syntax types of from-char. If from-char is a macro character, its reader macro function is copied also. If the character is a dispatching macro character, its entire dispatch table of reader macro functions is copied. The constituent traits of from-char are not copied.

+A macro definition from a character such as " can be copied to another character; the standard definition for " looks for another character that is the same as the character that invoked it. The definition of ( can not be meaningfully copied to {, on the other hand. The result is that lists are of the form {a b c), not {a b c}, because the definition always looks for a closing parenthesis, not a closing brace.

+

Examples:

+ +

+ (set-syntax-from-char #\7 #\;) =>  T
+ 123579 =>  1235
+
+

+

Side Effects:

+

+The to-readtable is modified.

+

Affected By:

+

+The existing values in the from-readtable.

+

Exceptional Situations: None. +

+

See Also:

+

+set-macro-character, make-dispatch-macro-character, Section 2.1.4 (Character Syntax Types)

+

Notes:

+

+The constituent traits of a character are ``hard wired'' into the parser for extended tokens. For example, if the definition of S is copied to *, then * will become a constituent that is alphabetic[2] but that cannot be used as a short float exponent marker. For further information, see Section 2.1.4.2 (Constituent Traits).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shadow.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shadow.htm new file mode 100644 index 00000000..8f785c19 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shadow.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function SHADOW + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SHADOW

+

Syntax:

+

+ +shadow symbol-names &optional package => t

+

+

Arguments and Values:

+

+ symbol-names---a designator for a list of string designators.

+ package---a package designator. The default is the current package.

+

Description:

+

+shadow assures that symbols with names given by symbol-names are present in the package.

+Specifically, package is searched for symbols with the names supplied by symbol-names. For each such name, if a corresponding symbol is not present in package (directly, not by inheritance), then a corresponding symbol is created with that name, and inserted into package as an internal symbol. The corresponding symbol, whether pre-existing or newly created, is then added, if not already present, to the shadowing symbols list of package.

+

Examples:

+

+

+ (package-shadowing-symbols (make-package 'temp)) =>  NIL
+ (find-symbol 'car 'temp) =>  CAR, :INHERITED
+ (shadow 'car 'temp) =>  T
+ (find-symbol 'car 'temp) =>  TEMP::CAR, :INTERNAL
+ (package-shadowing-symbols 'temp) =>  (TEMP::CAR)
+
+

+ +

+ (make-package 'test-1) =>  #<PACKAGE "TEST-1">
+ (intern "TEST" (find-package 'test-1)) =>  TEST-1::TEST, NIL
+ (shadow 'test-1::test (find-package 'test-1)) =>  T
+ (shadow 'TEST (find-package 'test-1)) =>  T
+ (assert (not (null (member 'test-1::test (package-shadowing-symbols
+                                            (find-package 'test-1))))))
+ 
+ (make-package 'test-2) =>  #<PACKAGE "TEST-2">
+ (intern "TEST" (find-package 'test-2)) =>  TEST-2::TEST, NIL
+ (export 'test-2::test (find-package 'test-2)) =>  T
+ (use-package 'test-2 (find-package 'test-1))    ;should not error
+ 
+
+

+

Side Effects:

+

+shadow changes the state of the package system in such a way that the package consistency rules do not hold across the change.

+

Affected By:

+

+Current state of the package system.

+

Exceptional Situations: None. +

+

See Also:

+

+package-shadowing-symbols, Section 11.1 (Package Concepts)

+

Notes:

+

+If a symbol with a name in symbol-names already exists in package, but by inheritance, the inherited symbol becomes shadowed[3] by a newly created internal symbol.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shared.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shared.htm new file mode 100644 index 00000000..040a2a84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shared.htm @@ -0,0 +1,67 @@ + + + +CLHS: Standard Generic Function SHARED-INITIALIZE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function SHARED-INITIALIZE

+

Syntax:

+

+ +shared-initialize instance slot-names &rest initargs &key &allow-other-keys => instance

+

+

Method Signatures:

+

+ +shared-initialize (instance standard-object) slot-names &rest initargs

+

+

Arguments and Values:

+

+instance---an object.

+slot-names---a list or t.

+initargs---a list of keyword/value pairs (of initialization argument names and values).

+

Description:

+

+The generic function shared-initialize is used to fill the slots of an instance using initargs and :initform forms. It is called when an instance is created, when an instance is re-initialized, when an instance is updated to conform to a redefined class, and when an instance is updated to conform to a different class. The generic function shared-initialize is called by the system-supplied primary method for initialize-instance, reinitialize-instance, update-instance-for-redefined-class, and update-instance-for-different-class.

+The generic function shared-initialize takes the following arguments: the instance to be initialized, a specification of a set of slot-names accessible in that instance, and any number of initargs. The arguments after the first two must form an initialization argument list. The system-supplied primary method on shared-initialize initializes the slots with values according to the initargs and supplied :initform forms. Slot-names indicates which slots should be initialized according to their :initform forms if no initargs are provided for those slots.

+The system-supplied primary method behaves as follows, regardless of whether the slots are local or shared:

+

+The slots-names argument specifies the slots that are to be initialized according to their :initform forms if no initialization arguments apply. It can be a list of slot names, which specifies the set of those slot names; or it can be the symbol t, which specifies the set of all of the slots.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+initialize-instance, reinitialize-instance, update-instance-for-redefined-class, update-instance-for-different-class, slot-boundp, slot-makunbound, Section 7.1 (Object Creation and Initialization), Section 7.1.4 (Rules for Initialization Arguments), Section 7.1.2 (Declaring the Validity of Initialization Arguments)

+

Notes:

+

+Initargs are declared as valid by using the :initarg option to defclass, or by defining methods for shared-initialize. The keyword name of each keyword parameter specifier in the lambda list of any method defined on shared-initialize is declared as a valid initarg name for all classes for which that method is applicable.

+Implementations are permitted to optimize :initform forms that neither produce nor depend on side effects, by evaluating these forms and storing them into slots before running any initialize-instance methods, rather than by handling them in the primary initialize-instance method. (This optimization might be implemented by having the allocate-instance method copy a prototype instance.)

+Implementations are permitted to optimize default initial value forms for initargs associated with slots by not actually creating the complete initialization argument list when the only method that would receive the complete list is the method on standard-object. In this case default initial value forms can be treated like :initform forms. This optimization has no visible effects other than a performance improvement.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shdw_i.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shdw_i.htm new file mode 100644 index 00000000..9621c2c4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_shdw_i.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function SHADOWING-IMPORT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SHADOWING-IMPORT

+

Syntax:

+

+ +shadowing-import symbols &optional package => t

+

+

Arguments and Values:

+

+symbols---a designator for a list of symbols.

+ package ---a package designator. The default is the current package.

+

Description:

+

+shadowing-import is like import, but it does not signal an error even if the importation of a symbol would shadow some symbol already accessible in package.

+shadowing-import inserts each of symbols into package as an internal symbol, regardless of whether another symbol of the same name is shadowed by this action. If a different symbol of the same name is already present in package, that symbol is first uninterned from package. The new symbol is added to package's shadowing-symbols list.

+shadowing-import does name-conflict checking to the extent that it checks whether a distinct existing symbol with the same name is accessible; if so, it is shadowed by the new symbol, which implies that it must be uninterned if it was present in package.

+

Examples:

+ +

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (setq sym (intern "CONFLICT")) =>  CONFLICT
+ (intern "CONFLICT" (make-package 'temp)) =>  TEMP::CONFLICT, NIL
+ (package-shadowing-symbols 'temp) =>  NIL
+ (shadowing-import sym 'temp) =>  T 
+ (package-shadowing-symbols 'temp) =>  (CONFLICT)
+
+

+

Side Effects:

+

+shadowing-import changes the state of the package system in such a way that the consistency rules do not hold across the change.

+package's shadowing-symbols list is modified.

+

Affected By:

+

+Current state of the package system.

+

Exceptional Situations: None. +

+

See Also:

+

+import, unintern, package-shadowing-symbols

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_short_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_short_.htm new file mode 100644 index 00000000..1528ff30 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_short_.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function SHORT-SITE-NAME, LONG-SITE-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SHORT-SITE-NAME, LONG-SITE-NAME

+

Syntax:

+

+ +short-site-name <no arguments> => description

+

+ +long-site-name <no arguments> => description

+

+

Arguments and Values:

+

+description---a string or nil.

+

Description:

+

+short-site-name and long-site-name return a string that identifies the physical location of the computer hardware, or nil if no appropriate description can be produced.

+

Examples:

+

+

+ (short-site-name)
+=>  "MIT AI Lab"
+OR=>  "CMU-CSD"
+ (long-site-name)
+=>  "MIT Artificial Intelligence Laboratory"
+OR=>  "CMU Computer Science Department"
+
+

+

Side Effects: None. +

+

Affected By:

+

+The implementation, the location of the computer hardware, and the installation/configuration process.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signal.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signal.htm new file mode 100644 index 00000000..892e333a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signal.htm @@ -0,0 +1,86 @@ + + + +CLHS: Function SIGNAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIGNAL

+

Syntax:

+

+ +signal datum &rest arguments => nil

+

+

Arguments and Values:

+

+datum, arguments---designators for a condition of default type simple-condition.

+

Description:

+

+Signals the condition denoted by the given datum and arguments. If the condition is not handled, signal returns nil.

+

Examples:

+

+

+ (defun handle-division-conditions (condition)
+   (format t "Considering condition for division condition handling~%")
+   (when (and (typep condition 'arithmetic-error)
+              (eq '/ (arithmetic-error-operation condition)))
+     (invoke-debugger condition)))
+HANDLE-DIVISION-CONDITIONS
+ (defun handle-other-arithmetic-errors (condition)
+   (format t "Considering condition for arithmetic condition handling~%")
+   (when (typep condition 'arithmetic-error)
+     (abort)))
+HANDLE-OTHER-ARITHMETIC-ERRORS
+ (define-condition a-condition-with-no-handler (condition) ())
+A-CONDITION-WITH-NO-HANDLER
+ (signal 'a-condition-with-no-handler)
+NIL
+ (handler-bind ((condition #'handle-division-conditions)
+                  (condition #'handle-other-arithmetic-errors))
+   (signal 'a-condition-with-no-handler))
+Considering condition for division condition handling
+Considering condition for arithmetic condition handling
+NIL
+ (handler-bind ((arithmetic-error #'handle-division-conditions)
+                  (arithmetic-error #'handle-other-arithmetic-errors))
+   (signal 'arithmetic-error :operation '* :operands '(1.2 b)))
+Considering condition for division condition handling
+Considering condition for arithmetic condition handling
+Back to Lisp Toplevel
+
+

+

Side Effects:

+

+The debugger might be entered due to *break-on-signals*.

+Handlers for the condition being signaled might transfer control.

+

Affected By:

+

+Existing handler bindings.

+*break-on-signals*

+

Exceptional Situations: None. +

+

See Also:

+

+*break-on-signals*, error, simple-condition, Section 9.1.4 (Signaling and Handling Conditions)

+

Notes:

+

+If (typep datum *break-on-signals*) yields true, the debugger is entered prior to beginning the signaling process. The continue restart can be used to continue with the signaling process. This is also true for all other functions and macros that should, might, or must signal conditions.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signum.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signum.htm new file mode 100644 index 00000000..6b980eae --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_signum.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function SIGNUM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIGNUM

+

Syntax:

+

+ +signum number => signed-prototype

+

+

Arguments and Values:

+

+number---a number.

+signed-prototype---a number.

+

Description:

+

+signum determines a numerical value that indicates whether number is negative, zero, or positive.

+For a rational, signum returns one of -1, 0, or 1 according to whether number is negative, zero, or positive. For a float, the result is a float of the same format whose value is minus one, zero, or one. For a complex number z, (signum z) is a complex number of the same phase but with unit magnitude, unless z is a complex zero, in which case the result is z.

+For rational arguments, signum is a rational function, but it may be irrational for complex arguments.

+If number is a float, the result is a float. If number is a rational, the result is a rational. If number is a complex float, the result is a complex float. If number is a complex rational, the result is a complex, but it is implementation-dependent whether that result is a complex rational or a complex float.

+

Examples:

+

+

+ (signum 0) =>  0
+ (signum 99) =>  1
+ (signum 4/5) =>  1
+ (signum -99/100) =>  -1
+ (signum 0.0) =>  0.0
+ (signum #c(0 33)) =>  #C(0.0 1.0)
+ (signum #c(7.5 10.0)) =>  #C(0.6 0.8)
+ (signum #c(0.0 -14.7)) =>  #C(0.0 -1.0)
+ (eql (signum -0.0) -0.0) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes:

+ +

+ (signum x) ==  (if (zerop x) x (/ x (abs x)))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sin_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sin_c.htm new file mode 100644 index 00000000..2e98acba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sin_c.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function SIN, COS, TAN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIN, COS, TAN

+

Syntax:

+

+ +sin radians => number

+ +cos radians => number

+ +tan radians => number

+

+

Arguments and Values:

+

+radians---a number given in radians.

+number---a number.

+

Description:

+

+sin, cos, and tan return the sine, cosine, and tangent, respectively, of radians.

+

Examples:

+

+

+ (sin 0) =>  0.0
+ (cos 0.7853982) =>  0.707107
+ (tan #c(0 1)) =>  #C(0.0 0.761594)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if radians is not a number. Might signal arithmetic-error.

+

See Also:

+

+asin, acos, atan, Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sinh_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sinh_.htm new file mode 100644 index 00000000..4826752a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sinh_.htm @@ -0,0 +1,91 @@ + + + +CLHS: Function SINH, COSH, TANH, ASINH... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SINH, COSH, TANH, ASINH, ACOSH, ATANH

+

Syntax:

+

+ +sinh number => result

+ +cosh number => result

+ +tanh number => result

+ +asinh number => result

+ +acosh number => result

+ +atanh number => result

+

+

Arguments and Values:

+

+number---a number.

+result---a number.

+

Description:

+

+These functions compute the hyperbolic sine, cosine, tangent, arc sine, arc cosine, and arc tangent functions, which are mathematically defined for an argument x as given in the next figure.

+ 

+Function                Definition                              
+Hyperbolic sine         (e^x-e^-x)/2                            
+Hyperbolic cosine       (e^x+e^-x)/2                            
+Hyperbolic tangent      (e^x-e^-x)/(e^x+e^-x)                   
+Hyperbolic arc sine     log  (x+sqrt(1+x^2))                    
+Hyperbolic arc cosine   2 log  (sqrt((x+1)/2) + sqrt((x-1)/2))  
+Hyperbolic arc tangent  (log  (1+x) - log (1-x))/2              
+
+

Figure 12-16. Mathematical definitions for hyperbolic functions

+The following definition for the inverse hyperbolic cosine determines the range and branch cuts:

+

arccosh z = 2 log (sqrt((z+1)/2) + sqrt((z-1)/2)).

+The branch cut for the inverse hyperbolic cosine function lies along the real axis to the left of 1 (inclusive), extending indefinitely along the negative real axis, continuous with quadrant II and (between 0 and 1) with quadrant I. The range is that half-strip of the complex plane containing numbers whose real part is non-negative and whose imaginary part is between -<PI> (exclusive) and <PI> (inclusive). A number with real part zero is in the range if its imaginary part is between zero (inclusive) and <PI> (inclusive).

+The following definition for the inverse hyperbolic sine determines the range and branch cuts:

+

arcsinh z = log (z+sqrt(1+z^2)).

+The branch cut for the inverse hyperbolic sine function is in two pieces: one along the positive imaginary axis above i (inclusive), continuous with quadrant I, and one along the negative imaginary axis below -i (inclusive), continuous with quadrant III. The range is that strip of the complex plane containing numbers whose imaginary part is between -<PI>/2 and <PI>/2. A number with imaginary part equal to -<PI>/2 is in the range if and only if its real part is non-positive; a number with imaginary part equal to <PI>/2 is in the range if and only if its imaginary part is non-negative.

+The following definition for the inverse hyperbolic tangent determines the range and branch cuts:

+

arctanh z = log (1+z) - log (1-z)/2.

+Note that:

+

i arctan z = arctanh iz.

+The branch cut for the inverse hyperbolic tangent function is in two pieces: one along the negative real axis to the left of -1 (inclusive), continuous with quadrant III, and one along the positive real axis to the right of 1 (inclusive), continuous with quadrant I. The points -1 and 1 are excluded from the domain. The range is that strip of the complex plane containing numbers whose imaginary part is between -<PI>/2 and <PI>/2. A number with imaginary part equal to -<PI>/2 is in the range if and only if its real part is strictly negative; a number with imaginary part equal to <PI>/2 is in the range if and only if its imaginary part is strictly positive. Thus the range of the inverse hyperbolic tangent function is identical to that of the inverse hyperbolic sine function with the points -<PI>i/2 and <PI>i/2 excluded.

+

Examples:

+

+

+ (sinh 0) =>  0.0 
+ (cosh (complex 0 -1)) =>  #C(0.540302 -0.0)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if number is not a number. Might signal arithmetic-error.

+

See Also:

+

+log, sqrt, Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes:

+

+The result of acosh may be a complex even if number is not a complex; this occurs when number is less than one. Also, the result of atanh may be a complex even if number is not a complex; this occurs when the absolute value of number is greater than one.

+The branch cut formulae are mathematically correct, assuming completely accurate computation. Implementors should consult a good text on numerical analysis. The formulae given above are not necessarily the simplest ones for real-valued computations; they are chosen to define the branch cuts in desirable ways for the complex case.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sl.htm new file mode 100644 index 00000000..ab6a1cfb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sl.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function / + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function /

+

Syntax:

+

+ +/ number => reciprocal

+ +/ numerator &rest denominators+ => quotient

+

+

Arguments and Values:

+

+number, denominator---a non-zero number.

+numerator, quotient, reciprocal---a number.

+

Description:

+

+The function / performs division or reciprocation.

+If no denominators are supplied, the function / returns the reciprocal of number.

+If at least one denominator is supplied, the function / divides the numerator by all of the denominators and returns the resulting quotient.

+If each argument is either an integer or a ratio, and the result is not an integer, then it is a ratio.

+The function / performs necessary type conversions.

+If any argument is a float then the rules of floating-point contagion apply; see Section 12.1.4 (Floating-point Computations).

+

Examples:

+

+

+ (/ 12 4) =>  3
+ (/ 13 4) =>  13/4
+ (/ -8) =>  -1/8
+ (/ 3 4 5) =>  3/20
+ (/ 0.5) =>  2.0
+ (/ 20 5) =>  4
+ (/ 5 20) =>  1/4
+ (/ 60 -2 3 5.0) =>  -2.0
+ (/ 2 #c(2 2)) =>  #C(1/2 -1/2)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences are unspecified if any argument other than the first is zero. If there is only one argument, the consequences are unspecified if it is zero.

+Might signal type-error if some argument is not a number. Might signal division-by-zero if division by zero is attempted. Might signal arithmetic-error.

+

See Also:

+

+floor, ceiling, truncate, round

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sleep.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sleep.htm new file mode 100644 index 00000000..2ecf5182 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sleep.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function SLEEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SLEEP

+

Syntax:

+

+ +sleep seconds => nil

+

+

Arguments and Values:

+

+seconds---a non-negative real.

+

Description:

+

+Causes execution to cease and become dormant for approximately the seconds of real time indicated by seconds, whereupon execution is resumed.

+

Examples:

+

+

+ (sleep 1) =>  NIL 
+
+;; Actually, since SLEEP is permitted to use approximate timing, 
+;; this might not always yield true, but it will often enough that
+;; we felt it to be a productive example of the intent.
+ (let ((then (get-universal-time))
+       (now  (progn (sleep 10) (get-universal-time))))
+   (>= (- now then) 10))
+=>  true
+
+

+

Side Effects:

+

+Causes processing to pause.

+

Affected By:

+

+The granularity of the scheduler.

+

Exceptional Situations:

+

+Should signal an error of type type-error if seconds is not a non-negative real.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_bo.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_bo.htm new file mode 100644 index 00000000..114a49bb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_bo.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function SLOT-BOUNDP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SLOT-BOUNDP

+

Syntax:

+

+ +slot-boundp instance slot-name => generalized-boolean

+

+

Arguments and Values:

+

+instance---an object.

+slot-name---a symbol naming a slot of instance.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if the slot named slot-name in instance is bound; otherwise, returns false.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If no slot of the name slot-name exists in the instance, slot-missing is called as follows:

+

+ (slot-missing (class-of instance)
+               instance
+               slot-name
+               'slot-boundp)
+
+

+ (If slot-missing is invoked and returns a value, a boolean equivalent to its primary value is returned by slot-boundp.)

+ The specific behavior depends on instance's metaclass. An error is never signaled if instance has metaclass standard-class. An error is always signaled if instance has metaclass built-in-class. The consequences are undefined if instance has any other metaclass--an error might or might not be signaled in this situation. Note in particular that the behavior for conditions and structures is not specified.

+

See Also:

+

+slot-makunbound, slot-missing

+

Notes:

+

+The function slot-boundp allows for writing after methods on initialize-instance in order to initialize only those slots that have not already been bound.

+ Although no implementation is required to do so, implementors are strongly encouraged to implement the function slot-boundp using the function slot-boundp-using-class described in the Metaobject Protocol.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ex.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ex.htm new file mode 100644 index 00000000..850a57d7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ex.htm @@ -0,0 +1,53 @@ + + + +CLHS: Function SLOT-EXISTS-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SLOT-EXISTS-P

+

Syntax:

+

+ +slot-exists-p object slot-name => generalized-boolean

+

+

Arguments and Values:

+

+ object---an object.

+slot-name---a symbol.

+generalized-boolean---a generalized boolean.

+

Description:

+

+ Returns true if the object has a slot named slot-name.

+

Examples: None. +

+

Affected By:

+

+defclass, defstruct

+

Exceptional Situations: None. +

+

See Also:

+

+defclass, slot-missing

+

Notes:

+

+ Although no implementation is required to do so, implementors are strongly encouraged to implement the function slot-exists-p using the function slot-exists-p-using-class described in the Metaobject Protocol.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ma.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ma.htm new file mode 100644 index 00000000..36e96827 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_ma.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function SLOT-MAKUNBOUND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SLOT-MAKUNBOUND

+

Syntax:

+

+ +slot-makunbound instance slot-name => instance

+

+

Arguments and Values:

+

+instance -- instance.

+Slot-name---a symbol.

+

Description:

+

+The function slot-makunbound restores a slot of the name slot-name in an instance to the unbound state.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If no slot of the name slot-name exists in the instance, slot-missing is called as follows:

+

+(slot-missing (class-of instance)
+              instance
+              slot-name
+              'slot-makunbound)
+
+

+ (Any values returned by slot-missing in this case are ignored by slot-makunbound.)

+ The specific behavior depends on instance's metaclass. An error is never signaled if instance has metaclass standard-class. An error is always signaled if instance has metaclass built-in-class. The consequences are undefined if instance has any other metaclass--an error might or might not be signaled in this situation. Note in particular that the behavior for conditions and structures is not specified.

+

See Also:

+

+slot-boundp, slot-missing

+

Notes:

+

+ Although no implementation is required to do so, implementors are strongly encouraged to implement the function slot-makunbound using the function slot-makunbound-using-class described in the Metaobject Protocol.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_mi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_mi.htm new file mode 100644 index 00000000..76c29f0b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_mi.htm @@ -0,0 +1,68 @@ + + + +CLHS: Standard Generic Function SLOT-MISSING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function SLOT-MISSING

+

Syntax:

+

+ +slot-missing class object slot-name operation &optional new-value => result*

+

+

Method Signatures:

+

+ +slot-missing (class t) object slot-name operation &optional new-value

+

+

Arguments and Values:

+

+class---the class of object.

+object---an object.

+slot-name---a symbol (the name of a would-be slot).

+operation---one of the symbols setf, slot-boundp, slot-makunbound, or slot-value.

+new-value---an object.

+result---an object.

+

Description:

+

+The generic function slot-missing is invoked when an attempt is made to access a slot in an object whose metaclass is standard-class and the slot of the name slot-name is not a name of a slot in that class. The default method signals an error.

+The generic function slot-missing is not intended to be called by programmers. Programmers may write methods for it.

+The generic function slot-missing may be called during evaluation of slot-value, (setf slot-value), slot-boundp, and slot-makunbound. For each of these operations the corresponding symbol for the operation argument is slot-value, setf, slot-boundp, and slot-makunbound respectively.

+The optional new-value argument to slot-missing is used when the operation is attempting to set the value of the slot.

+ If slot-missing returns, its values will be treated as follows:

+

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The default method on slot-missing signals an error of type error.

+

See Also:

+

+defclass, slot-exists-p, slot-value

+

Notes:

+

+The set of arguments (including the class of the instance) facilitates defining methods on the metaclass for slot-missing.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_un.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_un.htm new file mode 100644 index 00000000..dc98f0eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_un.htm @@ -0,0 +1,60 @@ + + + +CLHS: Standard Generic Function SLOT-UNBOUND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function SLOT-UNBOUND

+

Syntax:

+

+ +slot-unbound class instance slot-name => result*

+

+

Method Signatures:

+

+ +slot-unbound (class t) instance slot-name

+

+

Arguments and Values:

+

+class---the class of the instance.

+instance---the instance in which an attempt was made to read the unbound slot.

+slot-name---the name of the unbound slot.

+result---an object.

+

Description:

+

+The generic function slot-unbound is called when an unbound slot is read in an instance whose metaclass is standard-class. The default method signals an error of type unbound-slot. The name slot of the unbound-slot condition is initialized to the name of the offending variable, and the instance slot of the unbound-slot condition is initialized to the offending instance.

+ The generic function slot-unbound is not intended to be called by programmers. Programmers may write methods for it. The function slot-unbound is called only indirectly by slot-value.

+ If slot-unbound returns, only the primary value will be used by the caller, and all other values will be ignored.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+ The default method on slot-unbound signals an error of type unbound-slot.

+

See Also:

+

+slot-makunbound

+

Notes:

+

+An unbound slot may occur if no :initform form was specified for the slot and the slot value has not been set, or if slot-makunbound has been called on the slot.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_va.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_va.htm new file mode 100644 index 00000000..db311cc7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_slt_va.htm @@ -0,0 +1,93 @@ + + + +CLHS: Function SLOT-VALUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SLOT-VALUE

+

Syntax:

+

+ +slot-value object slot-name => value

+

+

Arguments and Values:

+

+object---an object.

+name---a symbol.

+value---an object.

+

Description:

+

+The function slot-value returns the value of the slot named slot-name in the object. If there is no slot named slot-name, slot-missing is called. If the slot is unbound, slot-unbound is called.

+The macro setf can be used with slot-value to change the value of a slot.

+

Examples:

+

+

+ (defclass foo () 
+   ((a :accessor foo-a :initarg :a :initform 1)
+    (b :accessor foo-b :initarg :b)
+    (c :accessor foo-c :initform 3)))
+=>  #<STANDARD-CLASS FOO 244020371>
+ (setq foo1 (make-instance 'foo :a 'one :b 'two))
+=>  #<FOO 36325624>
+ (slot-value foo1 'a) =>  ONE
+ (slot-value foo1 'b) =>  TWO
+ (slot-value foo1 'c) =>  3
+ (setf (slot-value foo1 'a) 'uno) =>  UNO
+ (slot-value foo1 'a) =>  UNO
+ (defmethod foo-method ((x foo))
+   (slot-value x 'a))
+=>  #<STANDARD-METHOD FOO-METHOD (FOO) 42720573>
+ (foo-method foo1) =>  UNO
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If an attempt is made to read a slot and no slot of the name slot-name exists in the object, slot-missing is called as follows:

+

+ (slot-missing (class-of instance)
+               instance
+               slot-name
+               'slot-value)
+
+

+ (If slot-missing is invoked, its primary value is returned by slot-value.)

+If an attempt is made to write a slot and no slot of the name slot-name exists in the object, slot-missing is called as follows:

+

+ (slot-missing (class-of instance)
+               instance
+               slot-name
+               'setf
+               new-value)
+
+

+ (If slot-missing returns in this case, any values are ignored.)

+ The specific behavior depends on object's metaclass. An error is never signaled if object has metaclass standard-class. An error is always signaled if object has metaclass built-in-class. The consequences are unspecified if object has any other metaclass--an error might or might not be signaled in this situation. Note in particular that the behavior for conditions and structures is not specified.

+

See Also:

+

+slot-missing, slot-unbound, with-slots

+

Notes:

+

+ Although no implementation is required to do so, implementors are strongly encouraged to implement the function slot-value using the function slot-value-using-class described in the Metaobject Protocol.

+Implementations may optimize slot-value by compiling it inline.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_bt.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_bt.htm new file mode 100644 index 00000000..03779f48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_bt.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function SIMPLE-BIT-VECTOR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIMPLE-BIT-VECTOR-P

+

Syntax:

+

+ +simple-bit-vector-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type simple-bit-vector; otherwise, returns false.

+

Examples:

+ +

+ (simple-bit-vector-p (make-array 6)) =>  false
+ (simple-bit-vector-p #*) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+simple-vector-p

+

Notes:

+ +

+ (simple-bit-vector-p object) ==  (typep object 'simple-bit-vector)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_cn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_cn.htm new file mode 100644 index 00000000..7689c718 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_cn.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function SIMPLE-CONDITION-FORMAT-CONTROL... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS

+

+

Syntax:

+

+ +simple-condition-format-control condition => format-control

+ +simple-condition-format-arguments condition => format-arguments

+

+

Arguments and Values:

+

+condition---a condition of type simple-condition.

+format-control---a format control.

+format-arguments---a list.

+

Description:

+

+simple-condition-format-control returns the format control needed to process the condition's format arguments.

+simple-condition-format-arguments returns a list of format arguments needed to process the condition's format control.

+

Examples:

+

+

+ (setq foo (make-condition 'simple-condition
+                          :format-control "Hi ~S"
+                          :format-arguments '(ho)))
+=>  #<SIMPLE-CONDITION 26223553>
+ (apply #'format nil (simple-condition-format-control foo)
+                     (simple-condition-format-arguments foo))
+=>  "Hi HO"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+simple-condition, Section 9.1 (Condition System Concepts)

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_st.htm new file mode 100644 index 00000000..8d32bfef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_st.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function SIMPLE-STRING-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIMPLE-STRING-P

+

Syntax:

+

+ +simple-string-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type simple-string; otherwise, returns false.

+

Examples:

+ +

+ (simple-string-p "aaaaaa") =>  true
+ (simple-string-p (make-array 6 
+                              :element-type 'character 
+                              :fill-pointer t)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+ +

+ (simple-string-p object) ==  (typep object 'simple-string)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_ve.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_ve.htm new file mode 100644 index 00000000..8703fd4e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_smp_ve.htm @@ -0,0 +1,62 @@ + + + +CLHS: Function SIMPLE-VECTOR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SIMPLE-VECTOR-P

+

Syntax:

+

+ +simple-vector-p object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type simple-vector; otherwise, returns false..

+

Examples:

+

+

+ (simple-vector-p (make-array 6)) =>  true
+ (simple-vector-p "aaaaaa") =>  false
+ (simple-vector-p (make-array 6 :fill-pointer t)) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+simple-vector

+

Notes:

+

+

+ (simple-vector-p object) ==  (typep object 'simple-vector)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sort_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sort_.htm new file mode 100644 index 00000000..31d6df92 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sort_.htm @@ -0,0 +1,107 @@ + + + +CLHS: Function SORT, STABLE-SORT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SORT, STABLE-SORT

+

Syntax:

+

+ +sort sequence predicate &key key => sorted-sequence

+ +stable-sort sequence predicate &key key => sorted-sequence

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+predicate---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+sorted-sequence---a sequence.

+

Description:

+

+sort and stable-sort destructively sort sequences according to the order determined by the predicate function.

+If sequence is a vector, the result is a vector that has the same actual array element type as sequence. If sequence is a list, the result is a list.

+sort determines the relationship between two elements by giving keys extracted from the elements to the predicate. The first argument to the predicate function is the part of one element of sequence extracted by the key function (if supplied); the second argument is the part of another element of sequence extracted by the key function (if supplied). Predicate should return true if and only if the first argument is strictly less than the second (in some appropriate sense). If the first argument is greater than or equal to the second (in the appropriate sense), then the predicate should return false.

+The argument to the key function is the sequence element. The return value of the key function becomes an argument to predicate. If key is not supplied or nil, the sequence element itself is used. There is no guarantee on the number of times the key will be called.

+If the key and predicate always return, then the sorting operation will always terminate, producing a sequence containing the same elements as sequence (that is, the result is a permutation of sequence). This is guaranteed even if the predicate does not really consistently represent a total order (in which case the elements will be scrambled in some unpredictable way, but no element will be lost). If the key consistently returns meaningful keys, and the predicate does reflect some total ordering criterion on those keys, then the elements of the sorted-sequence will be properly sorted according to that ordering.

+The sorting operation performed by sort is not guaranteed stable. Elements considered equal by the predicate might or might not stay in their original order. The predicate is assumed to consider two elements x and y to be equal if (funcall predicate x y) and (funcall predicate y x) are both false. stable-sort guarantees stability.

+The sorting operation can be destructive in all cases. In the case of a vector argument, this is accomplished by permuting the elements in place. In the case of a list, the list is destructively reordered in the same manner as for nreverse.

+

Examples:

+

+

+ (setq tester (copy-seq "lkjashd")) =>  "lkjashd"
+ (sort tester #'char-lessp) =>  "adhjkls"
+ (setq tester (list '(1 2 3) '(4 5 6) '(7 8 9))) =>  ((1 2 3) (4 5 6) (7 8 9))
+ (sort tester #'> :key #'car)  =>  ((7 8 9) (4 5 6) (1 2 3)) 
+ (setq tester (list 1 2 3 4 5 6 7 8 9 0)) =>  (1 2 3 4 5 6 7 8 9 0)
+ (stable-sort tester #'(lambda (x y) (and (oddp x) (evenp y))))
+=>  (1 3 5 7 9 2 4 6 8 0)
+ (sort (setq committee-data
+             (vector (list (list "JonL" "White") "Iteration")
+                     (list (list "Dick" "Waters") "Iteration")
+                     (list (list "Dick" "Gabriel") "Objects")
+                     (list (list "Kent" "Pitman") "Conditions")
+                     (list (list "Gregor" "Kiczales") "Objects")
+                     (list (list "David" "Moon") "Objects")
+                     (list (list "Kathy" "Chapman") "Editorial")
+                     (list (list "Larry" "Masinter") "Cleanup")
+                     (list (list "Sandra" "Loosemore") "Compiler")))
+       #'string-lessp :key #'cadar)
+=>  #((("Kathy" "Chapman") "Editorial")
+     (("Dick" "Gabriel") "Objects")
+     (("Gregor" "Kiczales") "Objects")
+     (("Sandra" "Loosemore") "Compiler")
+     (("Larry" "Masinter") "Cleanup")
+     (("David" "Moon") "Objects")
+     (("Kent" "Pitman") "Conditions")
+     (("Dick" "Waters") "Iteration")
+     (("JonL" "White") "Iteration"))
+ ;; Note that individual alphabetical order within `committees'
+ ;; is preserved.
+ (setq committee-data 
+       (stable-sort committee-data #'string-lessp :key #'cadr))
+=>  #((("Larry" "Masinter") "Cleanup")
+     (("Sandra" "Loosemore") "Compiler")
+     (("Kent" "Pitman") "Conditions")
+     (("Kathy" "Chapman") "Editorial")
+     (("Dick" "Waters") "Iteration")
+     (("JonL" "White") "Iteration")
+     (("Dick" "Gabriel") "Objects")
+     (("Gregor" "Kiczales") "Objects")
+     (("David" "Moon") "Objects"))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence.

+

See Also:

+

+merge, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects), Section 3.7 (Destructive Operations)

+

Notes:

+

+If sequence is a vector, the result might or might not be simple, and might or might not be identical to sequence.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_specia.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_specia.htm new file mode 100644 index 00000000..1618c45f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_specia.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function SPECIAL-OPERATOR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SPECIAL-OPERATOR-P

+

+

Syntax:

+

+ +special-operator-p symbol => generalized-boolean

+

+

Arguments and Values:

+

+symbol---a symbol.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if symbol is a special operator; otherwise, returns false.

+

Examples:

+

+

+ (special-operator-p 'if) =>  true
+ (special-operator-p 'car) =>  false
+ (special-operator-p 'one) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its argument is not a symbol.

+

See Also: None. +

+

Notes:

+

+Historically, this function was called special-form-p. The name was finally declared a misnomer and changed, since it returned true for special operators, not special forms.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sqrt_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sqrt_.htm new file mode 100644 index 00000000..e0dc5f12 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sqrt_.htm @@ -0,0 +1,84 @@ + + + +CLHS: Function SQRT, ISQRT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SQRT, ISQRT

+

Syntax:

+

+ +sqrt number => root

+ +isqrt natural => natural-root

+

+

Arguments and Values:

+

+number, root---a number.

+natural, natural-root---a non-negative integer.

+

Description:

+

+sqrt and isqrt compute square roots.

+sqrt returns the principal square root of number. If the number is not a complex but is negative, then the result is a complex.

+isqrt returns the greatest integer less than or equal to the exact positive square root of natural.

+If number is a positive rational, it is implementation-dependent whether root is a rational or a float. If number is a negative rational, it is implementation-dependent whether root is a complex rational or a complex float.

+ The mathematical definition of complex square root (whether or not minus zero is supported) follows:

+(sqrt x) = (exp (/ (log x) 2))

+

+The branch cut for square root lies along the negative real axis, continuous with quadrant II. The range consists of the right half-plane, including the non-negative imaginary axis and excluding the negative imaginary axis.

+

Examples:

+

+

+ (sqrt 9.0) =>  3.0
+ (sqrt -9.0) =>  #C(0.0 3.0)
+ (isqrt 9) =>  3
+ (sqrt 12) =>  3.4641016
+ (isqrt 12) =>  3
+ (isqrt 300) =>  17
+ (isqrt 325) =>  18
+ (sqrt 25)
+=>  5
+OR=>  5.0
+ (isqrt 25) =>  5
+ (sqrt -1) =>  #C(0.0 1.0)
+ (sqrt #c(0 2)) =>  #C(1.0 1.0)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The function sqrt should signal type-error if its argument is not a number.

+The function isqrt should signal type-error if its argument is not a non-negative integer.

+The functions sqrt and isqrt might signal arithmetic-error.

+

See Also:

+

+exp, log, Section 12.1.3.3 (Rule of Float Substitutability)

+

Notes:

+

+

+ (isqrt x) ==  (values (floor (sqrt x))) 
+
+ but it is potentially more efficient.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_st.htm new file mode 100644 index 00000000..e132c799 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_st.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function * + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function *

+

Syntax:

+

+ +* &rest numbers => product

+

+

Arguments and Values:

+

+number---a number.

+product---a number.

+

Description:

+

+Returns the product of numbers, performing any necessary type conversions in the process. If no numbers are supplied, 1 is returned.

+

Examples:

+

+

+ (*) =>  1
+ (* 3 5) =>  15
+ (* 1.0 #c(22 33) 55/98) =>  #C(12.346938775510203 18.520408163265305)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Might signal type-error if some argument is not a number. Might signal arithmetic-error.

+

See Also:

+

+Section 12.1.1 (Numeric Operations), Section 12.1.3 (Rational Computations), Section 12.1.4 (Floating-point Computations), Section 12.1.5 (Complex Computations)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_std_ch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_std_ch.htm new file mode 100644 index 00000000..97da1060 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_std_ch.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function STANDARD-CHAR-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STANDARD-CHAR-P

+

Syntax:

+

+ +standard-char-p character => generalized-boolean

+

+

Arguments and Values:

+

+character---a character.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if character is of type standard-char; otherwise, returns false.

+

Examples:

+

+

+ (standard-char-p #\Space) =>  true
+ (standard-char-p #\~) =>  true
+ ;; This next example presupposes an implementation
+ ;; in which #\Bell is a defined character.
+ (standard-char-p #\Bell) =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_tr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_tr.htm new file mode 100644 index 00000000..f6ef18bf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_tr.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function STRING-TRIM, STRING-LEFT-TRIM... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM

+

Syntax:

+ +string-trim character-bag string => trimmed-string

+ +string-left-trim character-bag string => trimmed-string

+ +string-right-trim character-bag string => trimmed-string

+

+

Arguments and Values:

+

+character-bag---a sequence containing characters.

+ string---a string designator.

+trimmed-string---a string.

+

Description:

+

+string-trim returns a substring of string, with all characters in character-bag stripped off the beginning and end. string-left-trim is similar but strips characters off only the beginning; string-right-trim strips off only the end.

+If no characters need to be trimmed from the string, then either string itself or a copy of it may be returned, at the discretion of the implementation.

+All of these functions observe the fill pointer.

+

Examples:

+ +

+ (string-trim "abc" "abcaakaaakabcaaa") =>  "kaaak"
+ (string-trim '(#\Space #\Tab #\Newline) " garbanzo beans
+        ") =>  "garbanzo beans"
+ (string-trim " (*)" " ( *three (silly) words* ) ")
+=>  "three (silly) words"
+
+ (string-left-trim "abc" "labcabcabc") =>  "labcabcabc"
+ (string-left-trim " (*)" " ( *three (silly) words* ) ")
+=>  "three (silly) words* ) "
+
+ (string-right-trim " (*)" " ( *three (silly) words* ) ") 
+=>  " ( *three (silly) words"
+
+

Side Effects: None. +

+

Affected By:

+

+The implementation.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_up.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_up.htm new file mode 100644 index 00000000..01bd6e82 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stg_up.htm @@ -0,0 +1,96 @@ + + + +CLHS: Function STRING-UPCASE, STRING-DOWNCASE... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE

+

Syntax:

+

+ +string-upcase string &key start end => cased-string

+ +string-downcase string &key start end => cased-string

+ +string-capitalize string &key start end => cased-string

+

+ +nstring-upcase string &key start end => string

+ +nstring-downcase string &key start end => string

+ +nstring-capitalize string &key start end => string

+

+

Arguments and Values:

+

+ string---a string designator. For nstring-upcase, nstring-downcase, and nstring-capitalize, the string designator must be a string.

+ start, end---bounding index designators of string. The defaults for start and end are 0 and nil, respectively.

+cased-string---a string.

+

Description:

+

+string-upcase, string-downcase, string-capitalize, nstring-upcase, nstring-downcase, nstring-capitalize change the case of the subsequence of string bounded by start and end as follows:

+

string-upcase

+string-upcase returns a string just like string with all lowercase characters replaced by the corresponding uppercase characters. More precisely, each character of the result string is produced by applying the function char-upcase to the corresponding character of string.

+

string-downcase

+string-downcase is like string-upcase except that all uppercase characters are replaced by the corresponding lowercase characters (using char-downcase).

+

string-capitalize

+string-capitalize produces a copy of string such that, for every word in the copy, the first character of the ``word,'' if it has case, is uppercase and any other characters with case in the word are lowercase. For the purposes of string-capitalize, a ``word'' is defined to be a consecutive subsequence consisting of alphanumeric characters, delimited at each end either by a non-alphanumeric character or by an end of the string.

+

nstring-upcase, nstring-downcase, nstring-capitalize

+nstring-upcase, nstring-downcase, and nstring-capitalize are identical to string-upcase, string-downcase, and string-capitalize respectively except that they modify string.

+For string-upcase, string-downcase, and string-capitalize, string is not modified. However, if no characters in string require conversion, the result may be either string or a copy of it, at the implementation's discretion.

+

Examples:

+ +

+ (string-upcase "abcde") =>  "ABCDE"
+ (string-upcase "Dr. Livingston, I presume?")
+=>  "DR. LIVINGSTON, I PRESUME?"
+ (string-upcase "Dr. Livingston, I presume?" :start 6 :end 10)
+=>  "Dr. LiVINGston, I presume?"
+ (string-downcase "Dr. Livingston, I presume?")
+=>  "dr. livingston, i presume?"
+
+ (string-capitalize "elm 13c arthur;fig don't") =>  "Elm 13c Arthur;Fig Don'T"
+ (string-capitalize " hello ") =>  " Hello "
+ (string-capitalize "occlUDeD cASEmenTs FOreSTAll iNADVertent DEFenestraTION")
+=>   "Occluded Casements Forestall Inadvertent Defenestration"
+ (string-capitalize 'kludgy-hash-search) =>  "Kludgy-Hash-Search"
+ (string-capitalize "DON'T!") =>  "Don'T!"    ;not "Don't!"
+ (string-capitalize "pipe 13a, foo16c") =>  "Pipe 13a, Foo16c"
+
+ (setq str (copy-seq "0123ABCD890a")) =>  "0123ABCD890a"
+ (nstring-downcase str :start 5 :end 7) =>  "0123AbcD890a"
+ str =>  "0123AbcD890a"
+
+

+

Side Effects:

+

+ nstring-upcase, nstring-downcase, and nstring-capitalize modify string as appropriate rather than constructing a new string.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+char-upcase, char-downcase

+

Notes:

+ The result is always of the same length as string.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgeq_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgeq_.htm new file mode 100644 index 00000000..4da26aed --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgeq_.htm @@ -0,0 +1,122 @@ + + + +CLHS: Function STRING=, STRING/=, STRING<... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP

+

Syntax:

+

+ +string= string1 string2 &key start1 end1 start2 end2 => generalized-boolean

+

+ +string/= string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string< string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string> string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string<= string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string>= string1 string2 &key start1 end1 start2 end2 => mismatch-index

+

+ +string-equal string1 string2 &key start1 end1 start2 end2 => generalized-boolean

+

+ +string-not-equal string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string-lessp string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string-greaterp string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string-not-greaterp string1 string2 &key start1 end1 start2 end2 => mismatch-index

+ +string-not-lessp string1 string2 &key start1 end1 start2 end2 => mismatch-index

+

+

Arguments and Values:

+

+ string1---a string designator.

+string2---a string designator.

+ start1, end1---bounding index designators of string1. The defaults for start and end are 0 and nil, respectively.

+start2, end2---bounding index designators of string2. The defaults for start and end are 0 and nil, respectively.

+generalized-boolean---a generalized boolean.

+mismatch-index---a bounding index of string1, or nil.

+

Description:

+

+These functions perform lexicographic comparisons on string1 and string2. string= and string-equal are called equality functions; the others are called inequality functions. The comparison operations these functions perform are restricted to the subsequence of string1 bounded by start1 and end1 and to the subsequence of string2 bounded by start2 and end2.

+A string a is equal to a string b if it contains the same number of characters, and the corresponding characters are the same under char= or char-equal, as appropriate.

+A string a is less than a string b if in the first position in which they differ the character of a is less than the corresponding character of b according to char< or char-lessp as appropriate, or if string a is a proper prefix of string b (of shorter length and matching in all the characters of a).

+The equality functions return a generalized boolean that is true if the strings are equal, or false otherwise.

+The inequality functions return a mismatch-index that is true if the strings are not equal, or false otherwise. When the mismatch-index is true, it is an integer representing the first character position at which the two substrings differ, as an offset from the beginning of string1.

+The comparison has one of the following results:

+

+

string=

+string= is true if the supplied substrings are of the same length and contain the same characters in corresponding positions; otherwise it is false.

+

string/=

+string/= is true if the supplied substrings are different; otherwise it is false.

+

string-equal

+string-equal is just like string= except that differences in case are ignored; two characters are considered to be the same if char-equal is true of them.

+

string<

+string< is true if substring1 is less than substring2; otherwise it is false.

+

string>

+string> is true if substring1 is greater than substring2; otherwise it is false.

+

string-lessp, string-greaterp

+string-lessp and string-greaterp are exactly like string< and string>, respectively, except that distinctions between uppercase and lowercase letters are ignored. It is as if char-lessp were used instead of char< for comparing characters.

+

string<=

+string<= is true if substring1 is less than or equal to substring2; otherwise it is false.

+

string>=

+string>= is true if substring1 is greater than or equal to substring2; otherwise it is false.

+

string-not-greaterp, string-not-lessp

+string-not-greaterp and string-not-lessp are exactly like string<= and string>=, respectively, except that distinctions between uppercase and lowercase letters are ignored. It is as if char-lessp were used instead of char< for comparing characters.

+

+

Examples:

+

+

+ (string= "foo" "foo") =>  true
+ (string= "foo" "Foo") =>  false
+ (string= "foo" "bar") =>  false
+ (string= "together" "frog" :start1 1 :end1 3 :start2 2) =>  true
+ (string-equal "foo" "Foo") =>  true
+ (string= "abcd" "01234abcd9012" :start2 5 :end2 9) =>  true
+ (string< "aaaa" "aaab") =>  3
+ (string>= "aaaaa" "aaaa") =>  4
+ (string-not-greaterp "Abcde" "abcdE") =>  5
+ (string-lessp "012AAAA789" "01aaab6" :start1 3 :end1 7
+                                      :start2 2 :end2 6) =>  6
+ (string-not-equal "AAAA" "aaaA") =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+char=

+

Notes:

+

+equal calls string= if applied to two strings.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgp.htm new file mode 100644 index 00000000..61fbe6d7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stgp.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function STRINGP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STRINGP

+

Syntax:

+

+ +stringp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type string; otherwise, returns false.

+

Examples:

+

+

+ (stringp "aaaaaa") =>  true
+ (stringp #\a) =>  false
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+typep, string (type)

+

Notes:

+

+

+ (stringp object) ==  (typep object 'string)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_el.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_el.htm new file mode 100644 index 00000000..5488e138 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_el.htm @@ -0,0 +1,71 @@ + + + +CLHS: Function STREAM-ELEMENT-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STREAM-ELEMENT-TYPE

+

Syntax:

+

+ +stream-element-type stream => typespec

+

+

Arguments and Values:

+

+stream---a stream.

+typespec---a type specifier.

+

Description:

+

+stream-element-type returns a type specifier that indicates the types of objects that may be read from or written to stream.

+Streams created by open have an element type restricted to integer or a subtype of type character.

+

Examples:

+

+

+;; Note that the stream must accomodate at least the specified type,
+;; but might accomodate other types.  Further note that even if it does
+;; accomodate exactly the specified type, the type might be specified in
+;; any of several ways.
+ (with-open-file (s "test" :element-type '(integer 0 1)
+                           :if-exists :error
+                           :direction :output)
+   (stream-element-type s))
+=>  INTEGER
+OR=>  (UNSIGNED-BYTE 16)
+OR=>  (UNSIGNED-BYTE 8)
+OR=>  BIT
+OR=>  (UNSIGNED-BYTE 1)
+OR=>  (INTEGER 0 1)
+OR=>  (INTEGER 0 (2))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_er.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_er.htm new file mode 100644 index 00000000..2f050665 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_er.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function STREAM-ERROR-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STREAM-ERROR-STREAM

+

Syntax:

+

+ +stream-error-stream condition => stream

+

+

Arguments and Values:

+

+condition---a condition of type stream-error.

+stream---a stream.

+

Description:

+

+Returns the offending stream of a condition of type stream-error.

+

Examples:

+ +

+ (with-input-from-string (s "(FOO")
+   (handler-case (read s)
+     (end-of-file (c)
+       (format nil "~&End of file on ~S." (stream-error-stream c)))))
+"End of file on #<String Stream>."
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+stream-error, Section 9 (Conditions)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_ex.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_ex.htm new file mode 100644 index 00000000..1fd2e0d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stm_ex.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function STREAM-EXTERNAL-FORMAT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STREAM-EXTERNAL-FORMAT

+

Syntax:

+

+ +stream-external-format stream => format

+

+

Arguments and Values:

+

+stream---a file stream.

+format---an external file format.

+

Description:

+

+Returns an external file format designator for the stream.

+

Examples:

+

+

+ (with-open-file (stream "test" :direction :output)
+   (stream-external-format stream))
+=>  :DEFAULT
+OR=>  :ISO8859/1-1987
+OR=>  (:ASCII :SAIL)
+OR=>  ACME::PROPRIETARY-FILE-FORMAT-17
+OR=>  #<FILE-FORMAT :ISO646-1983 2343673>
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+the :external-format argument to the function open and the with-open-file macro.

+

Notes:

+

+The format returned is not necessarily meaningful to other implementations.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stmp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stmp.htm new file mode 100644 index 00000000..eef07869 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_stmp.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function STREAMP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STREAMP

+

Syntax:

+

+ +streamp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type stream; otherwise, returns false.

+ streamp is unaffected by whether object, if it is a stream, is open or closed.

+

Examples:

+

+

+ (streamp *terminal-io*) =>  true
+ (streamp 1) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+

+ (streamp object) ==  (typep object 'stream)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_string.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_string.htm new file mode 100644 index 00000000..22760f08 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_string.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function STRING

+

Syntax:

+

+ +string x => string

+

+

Arguments and Values:

+

+ x---a string, a symbol, or a character.

+string---a string.

+

Description:

+

+Returns a string described by x; specifically:

+

+

Examples:

+

+

+ (string "already a string") =>  "already a string"
+ (string 'elm) =>  "ELM"
+ (string #\c) =>  "c"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+ In the case where a conversion is defined neither by this specification nor by the implementation, an error of type type-error is signaled.

+

See Also:

+

+coerce, string (type).

+

Notes:

+

+coerce can be used to convert a sequence of characters to a string.

+prin1-to-string, princ-to-string, write-to-string, or format (with a first argument of nil) can be used to get a string representation of a number or any other object.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sublis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sublis.htm new file mode 100644 index 00000000..9fc5e7d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sublis.htm @@ -0,0 +1,104 @@ + + + +CLHS: Function SUBLIS, NSUBLIS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SUBLIS, NSUBLIS

+

Syntax:

+

+ +sublis alist tree &key key test test-not => new-tree

+ +nsublis alist tree &key key test test-not => new-tree

+

+

Arguments and Values:

+

+alist---an association list.

+ tree---a tree.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+ new-tree---a tree.

+

Description:

+

+sublis makes substitutions for objects in tree (a structure of conses). nsublis is like sublis but destructively modifies the relevant parts of the tree.

+sublis looks at all subtrees and leaves of tree; if a subtree or leaf appears as a key in alist (that is, the key and the subtree or leaf satisfy the test), it is replaced by the object with which that key is associated. This operation is non-destructive. In effect, sublis can perform several subst operations simultaneously.

+If sublis succeeds, a new copy of tree is returned in which each occurrence of such a subtree or leaf is replaced by the object with which it is associated. If no changes are made, the original tree is returned. The original tree is left unchanged, but the result tree may share cells with it.

+nsublis is permitted to modify tree but otherwise returns the same values as sublis.

+

Examples:

+

+

+ (sublis '((x . 100) (z . zprime))
+         '(plus x (minus g z x p) 4 . x))
+=>  (PLUS 100 (MINUS G ZPRIME 100 P) 4 . 100)
+ (sublis '(((+ x y) . (- x y)) ((- x y) . (+ x y)))
+         '(* (/ (+ x y) (+ x p)) (- x y))
+         :test #'equal)
+=>  (* (/ (- X Y) (+ X P)) (+ X Y))
+ (setq tree1 '(1 (1 2) ((1 2 3)) (((1 2 3 4)))))
+=>  (1 (1 2) ((1 2 3)) (((1 2 3 4))))
+ (sublis '((3 . "three")) tree1) 
+=>  (1 (1 2) ((1 2 "three")) (((1 2 "three" 4))))
+ (sublis '((t . "string"))
+          (sublis '((1 . "") (4 . 44)) tree1)
+          :key #'stringp)
+=>  ("string" ("string" 2) (("string" 2 3)) ((("string" 2 3 44))))
+ tree1 =>  (1 (1 2) ((1 2 3)) (((1 2 3 4))))
+ (setq tree2 '("one" ("one" "two") (("one" "Two" "three"))))
+=>  ("one" ("one" "two") (("one" "Two" "three"))) 
+ (sublis '(("two" . 2)) tree2) 
+=>  ("one" ("one" "two") (("one" "Two" "three"))) 
+ tree2 =>  ("one" ("one" "two") (("one" "Two" "three"))) 
+ (sublis '(("two" . 2)) tree2 :test 'equal) 
+=>  ("one" ("one" 2) (("one" "Two" "three"))) 
+
+ (nsublis '((t . 'temp))
+           tree1
+           :key #'(lambda (x) (or (atom x) (< (list-length x) 3))))
+=>  ((QUOTE TEMP) (QUOTE TEMP) QUOTE TEMP) 
+
+

+

Side Effects:

+

+nsublis modifies tree.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+subst, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+Because the side-effecting variants (e.g., nsublis) potentially change the path that is being traversed, their effects in the presence of shared or circular structure structure may vary in surprising ways when compared to their non-side-effecting alternatives. To see this, consider the following side-effect behavior, which might be exhibited by some implementations:

+

+ (defun test-it (fn)
+   (let* ((shared-piece (list 'a 'b))
+          (data (list shared-piece shared-piece)))
+     (funcall fn '((a . b) (b . a)) data)))
+ (test-it #'sublis) =>  ((B A) (B A))
+ (test-it #'nsublis) =>  ((A B) (A B))
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subseq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subseq.htm new file mode 100644 index 00000000..7a2b0a8f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subseq.htm @@ -0,0 +1,71 @@ + + + +CLHS: Accessor SUBSEQ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor SUBSEQ

+

Syntax:

+

+ +subseq sequence start &optional end => subsequence

+ +(setf (subseq sequence start &optional end) new-subsequence)

+

+

Arguments and Values:

+

+sequence---a proper sequence.

+ start, end---bounding index designators of sequence. The default for end is nil.

+subsequence---a proper sequence.

+new-subsequence---a proper sequence.

+

Description:

+

+subseq creates a sequence that is a copy of the subsequence of sequence bounded by start and end.

+Start specifies an offset into the original sequence and marks the beginning position of the subsequence. end marks the position following the last element of the subsequence.

+subseq always allocates a new sequence for a result; it never shares storage with an old sequence. The result subsequence is always of the same type as sequence.

+If sequence is a vector, the result is a fresh simple array of rank one that has the same actual array element type as sequence. If sequence is a list, the result is a fresh list.

+setf may be used with subseq to destructively replace elements of a subsequence with elements taken from a sequence of new values. If the subsequence and the new sequence are not of equal length, the shorter length determines the number of elements that are replaced. The remaining elements at the end of the longer sequence are not modified in the operation.

+

Examples:

+

+

+ (setq str "012345") =>  "012345"
+ (subseq str 2) =>  "2345"
+ (subseq str 3 5) =>  "34"
+ (setf (subseq str 4) "abc") =>  "abc"
+ str =>  "0123ab"
+ (setf (subseq str 0 2) "A") =>  "A"
+ str =>  "A123ab"
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence. Should be prepared to signal an error of type type-error if new-subsequence is not a proper sequence.

+

See Also:

+

+replace

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subset.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subset.htm new file mode 100644 index 00000000..23802aa8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subset.htm @@ -0,0 +1,70 @@ + + + +CLHS: Function SUBSETP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SUBSETP

+

Syntax:

+

+ +subsetp list-1 list-2 &key key test test-not => generalized-boolean

+

+

Arguments and Values:

+

+list-1---a proper list.

+list-2---a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+generalized-boolean---a generalized boolean.

+

Description:

+

+subsetp returns true if every element of list-1 matches some element of list-2, and false otherwise.

+Whether a list element is the same as another list element is determined by the functions specified by the keyword arguments. The first argument to the :test or :test-not function is typically part of an element of list-1 extracted by the :key function; the second argument is typically part of an element of list-2 extracted by the :key function.

+The argument to the :key function is an element of either list-1 or list-2; the return value is part of the element of the supplied list element. If :key is not supplied or nil, the list-1 or list-2 element itself is supplied to the :test or :test-not function.

+

Examples:

+

+

+ (setq cosmos '(1 "a" (1 2))) =>  (1 "a" (1 2))
+ (subsetp '(1) cosmos) =>  true
+ (subsetp '((1 2)) cosmos) =>  false
+ (subsetp '((1 2)) cosmos :test 'equal) =>  true
+ (subsetp '(1 "A") cosmos :test #'equalp) =>  true
+ (subsetp '((1) (2)) '((1) (2))) =>  false
+ (subsetp '((1) (2)) '((1) (2)) :key #'car) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list-1 and list-2 are not proper lists.

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_substc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_substc.htm new file mode 100644 index 00000000..7ded3986 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_substc.htm @@ -0,0 +1,116 @@ + + + +CLHS: Function SUBST, SUBST-IF, SUBST-IF-NOT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT

+

Syntax:

+

+ +subst new old tree &key key test test-not => new-tree

+ +subst-if new predicate tree &key key => new-tree

+ +subst-if-not new predicate tree &key key => new-tree

+

+ +nsubst new old tree &key key test test-not => new-tree

+ +nsubst-if new predicate tree &key key => new-tree

+ +nsubst-if-not new predicate tree &key key => new-tree

+

+

Arguments and Values:

+

+new---an object.

+old---an object.

+predicate---a symbol that names a function, or a function of one argument that returns a generalized boolean value.

+ tree---a tree.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+ new-tree---a tree.

+

Description:

+

+subst, subst-if, and subst-if-not perform substitution operations on tree. Each function searches tree for occurrences of a particular old item of an element or subexpression that satisfies the test.

+nsubst, nsubst-if, and nsubst-if-not are like subst, subst-if, and subst-if-not respectively, except that the original tree is modified.

+subst makes a copy of tree, substituting new for every subtree or leaf of tree (whether the subtree or leaf is a car or a cdr of its parent) such that old and the subtree or leaf satisfy the test.

+nsubst is a destructive version of subst. The list structure of tree is altered by destructively replacing with new each leaf of the tree such that old and the leaf satisfy the test.

+For subst, subst-if, and subst-if-not, if the functions succeed, a new copy of the tree is returned in which each occurrence of such an element is replaced by the new element or subexpression. If no changes are made, the original tree may be returned. The original tree is left unchanged, but the result tree may share storage with it.

+For nsubst, nsubst-if, and nsubst-if-not the original tree is modified and returned as the function result, but the result may not be eq to tree.

+

Examples:

+

+

+ (setq tree1 '(1 (1 2) (1 2 3) (1 2 3 4))) =>  (1 (1 2) (1 2 3) (1 2 3 4))
+ (subst "two" 2 tree1) =>  (1 (1 "two") (1 "two" 3) (1 "two" 3 4))
+ (subst "five" 5 tree1) =>  (1 (1 2) (1 2 3) (1 2 3 4))
+ (eq tree1 (subst "five" 5 tree1)) =>  implementation-dependent
+ (subst 'tempest 'hurricane
+        '(shakespeare wrote (the hurricane)))
+=>  (SHAKESPEARE WROTE (THE TEMPEST))
+ (subst 'foo 'nil '(shakespeare wrote (twelfth night)))
+=>  (SHAKESPEARE WROTE (TWELFTH NIGHT . FOO) . FOO)
+ (subst '(a . cons) '(old . pair)
+        '((old . spice) ((old . shoes) old . pair) (old . pair))
+        :test #'equal)
+=>  ((OLD . SPICE) ((OLD . SHOES) A . CONS) (A . CONS))
+
+ (subst-if 5 #'listp tree1) =>  5
+ (subst-if-not '(x) #'consp tree1) 
+=>  (1 X)
+
+ tree1 =>  (1 (1 2) (1 2 3) (1 2 3 4))
+ (nsubst 'x 3 tree1 :key #'(lambda (y) (and (listp y) (third y)))) 
+=>  (1 (1 2) X X)
+ tree1 =>  (1 (1 2) X X)
+
+

+

Side Effects:

+

+nsubst, nsubst-if, and nsubst-if-not might alter the tree structure of tree.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+substitute, nsubstitute, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+ The functions subst-if-not and nsubst-if-not are deprecated.

+One possible definition of subst:

+

+ (defun subst (old new tree &rest x &key test test-not key)
+   (cond ((satisfies-the-test old tree :test test
+                              :test-not test-not :key key)
+          new)
+         ((atom tree) tree)
+         (t (let ((a (apply #'subst old new (car tree) x))
+                  (d (apply #'subst old new (cdr tree) x)))
+              (if (and (eql a (car tree))
+                       (eql d (cdr tree)))
+                  tree
+                  (cons a d))))))
+
+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subtpp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subtpp.htm new file mode 100644 index 00000000..80779779 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_subtpp.htm @@ -0,0 +1,133 @@ + + + +CLHS: Function SUBTYPEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SUBTYPEP

+

+

Syntax:

+

+ +subtypep type-1 type-2 &optional environment => subtype-p, valid-p

+

+

Arguments and Values:

+

+type-1---a type specifier.

+type-2---a type specifier.

+environment---an environment object. The default is nil, denoting the null lexical environment and the current global environment.

+subtype-p---a generalized boolean.

+valid-p---a generalized boolean.

+

Description:

+

+If type-1 is a recognizable subtype of type-2, the first value is true. Otherwise, the first value is false, indicating that either type-1 is not a subtype of type-2, or else type-1 is a subtype of type-2 but is not a recognizable subtype.

+A second value is also returned indicating the `certainty' of the first value. If this value is true, then the first value is an accurate indication of the subtype relationship. (The second value is always true when the first value is true.)

+The next figure summarizes the possible combinations of values that might result.

+

+Value 1  Value 2  Meaning                                               
+true     true     type-1 is definitely a subtype of type-2.             
+false    true     type-1 is definitely not a subtype of type-2.         
+false    false    subtypep could not determine the relationship,        
+                  so type-1 might or might not be a subtype of type-2.  
+
+

Figure 4-9. Result possibilities for subtypep

+

+subtypep is permitted to return the values false and false only when at least one argument involves one of these type specifiers: and, eql, the list form of function, member, not, or, satisfies, or values. (A type specifier `involves' such a symbol if, after being type expanded, it contains that symbol in a position that would call for its meaning as a type specifier to be used.) One consequence of this is that if neither type-1 nor type-2 involves any of these type specifiers, then subtypep is obliged to determine the relationship accurately. In particular, subtypep returns the values true and true if the arguments are equal and do not involve any of these type specifiers.

+subtypep never returns a second value of nil when both type-1 and type-2 involve only the names in Figure 4-2, or names of types defined by defstruct, define-condition, or defclass, or derived types that expand into only those names. While type specifiers listed in Figure 4-2 and names of defclass and defstruct can in some cases be implemented as derived types, subtypep regards them as primitive.

+The relationships between types reflected by subtypep are those specific to the particular implementation. For example, if an implementation supports only a single type of floating-point numbers, in that implementation (subtypep 'float 'long-float) returns the values true and true (since the two types are identical).

+ For all T1 and T2 other than *, (array T1) and (array T2) are two different type specifiers that always refer to the same sets of things if and only if they refer to arrays of exactly the same specialized representation, i.e., if (upgraded-array-element-type 'T1) and (upgraded-array-element-type 'T2) return two different type specifiers that always refer to the same sets of objects. This is another way of saying that `(array type-specifier) and `(array ,(upgraded-array-element-type 'type-specifier)) refer to the same set of specialized array representations. For all T1 and T2 other than *, the intersection of (array T1) and (array T2) is the empty set if and only if they refer to arrays of different, distinct specialized representations.

+Therefore,

+

+ (subtypep '(array T1) '(array T2)) =>  true
+
+ if and only if

+

+ (upgraded-array-element-type 'T1)  and
+ (upgraded-array-element-type 'T2)  
+
+

+return two different type specifiers that always refer to the same sets of objects.

+For all type-specifiers T1 and T2 other than *,

+

+ (subtypep '(complex T1) '(complex T2)) =>  true, true
+
+

+if:

1. T1 is a subtype of T2, or
2. (upgraded-complex-part-type 'T1) and (upgraded-complex-part-type 'T2) return two different type specifiers that always refer to the same sets of objects; in this case, (complex T1) and (complex T2) both refer to the same specialized representation.

The values are false and true otherwise.

+The form

+

+ (subtypep '(complex single-float) '(complex float))
+
+ must return true in all implementations, but

+

+ (subtypep '(array single-float) '(array float))
+
+

+returns true only in implementations that do not have a specialized array representation for single floats distinct from that for other floats.

+

+

Examples:

+

+

+ (subtypep 'compiled-function 'function) =>  true, true
+ (subtypep 'null 'list) =>  true, true
+ (subtypep 'null 'symbol) =>  true, true
+ (subtypep 'integer 'string) =>  false, true
+ (subtypep '(satisfies dummy) nil) =>  false, implementation-dependent
+ (subtypep '(integer 1 3) '(integer 1 4)) =>  true, true
+ (subtypep '(integer (0) (0)) 'nil) =>  true, true
+ (subtypep 'nil '(integer (0) (0))) =>  true, true
+ (subtypep '(integer (0) (0)) '(member)) =>  true, true ;or false, false
+ (subtypep '(member) 'nil) =>  true, true ;or false, false
+ (subtypep 'nil '(member)) =>  true, true ;or false, false
+
+

+ Let <aet-x> and <aet-y> be two distinct type specifiers that do not always refer to the same sets of objects in a given implementation, but for which make-array, will return an object of the same array type.

+Thus, in each case,

+

+  (subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
+            (array-element-type (make-array 0 :element-type '<aet-y>)))
+=>  true, true
+ 
+  (subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
+            (array-element-type (make-array 0 :element-type '<aet-x>)))
+=>  true, true
+
+

+If (array <aet-x>) and (array <aet-y>) are different names for exactly the same set of objects, these names should always refer to the same sets of objects. That implies that the following set of tests are also true:

+

+ (subtypep '(array <aet-x>) '(array <aet-y>)) =>  true, true
+ (subtypep '(array <aet-y>) '(array <aet-x>)) =>  true, true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+Section 4.2 (Types)

+

Notes:

+

+ The small differences between the subtypep specification for the array and complex types are necessary because there is no creation function for complexes which allows the specification of the resultant part type independently of the actual types of the parts. Thus in the case of the type complex, the actual type of the parts is referred to, although a number can be a member of more than one type. For example, 17 is of type (mod 18) as well as type (mod 256) and type integer; and 2.3f5 is of type single-float as well as type float.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_svref.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_svref.htm new file mode 100644 index 00000000..7f667efb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_svref.htm @@ -0,0 +1,68 @@ + + + +CLHS: Accessor SVREF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor SVREF

+

Syntax:

+

+ +svref simple-vector index => element

+ +(setf (svref simple-vector index) new-element)

+

+

Arguments and Values:

+

+simple-vector---a simple vector.

+index---a valid array index for the simple-vector.

+element, new-element---an object (whose type is a subtype of the array element type of the simple-vector).

+

Description:

+

+Accesses the element of simple-vector specified by index.

+

Examples:

+

+

+ (simple-vector-p (setq v (vector 1 2 'sirens))) =>  true
+ (svref v 0) =>  1
+ (svref v 2) =>  SIRENS
+ (setf (svref v 1) 'newcomer) =>  NEWCOMER               
+ v =>  #(1 NEWCOMER SIRENS)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+aref, sbit, schar, vector, Section 3.2.1 (Compiler Terminology)

+

Notes:

+

+svref is identical to aref except that it requires its first argument to be a simple vector.

+

+ (svref v i) ==  (aref (the simple-vector v) i)
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sw_tpc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sw_tpc.htm new file mode 100644 index 00000000..e91a62ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sw_tpc.htm @@ -0,0 +1,60 @@ + + + +CLHS: Function SOFTWARE-TYPE, SOFTWARE-VERSION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SOFTWARE-TYPE, SOFTWARE-VERSION

+

Syntax:

+

+ +software-type <no arguments> => description

+ +software-version <no arguments> => description

+

+

Arguments and Values:

+

+description---a string or nil.

+

Description:

+

+software-type returns a string that identifies the generic name of any relevant supporting software, or nil if no appropriate or relevant result can be produced.

+software-version returns a string that identifies the version of any relevant supporting software, or nil if no appropriate or relevant result can be produced.

+

Examples:

+

+

+ (software-type) =>  "Multics"
+ (software-version) =>  "1.3x"
+
+

+

Side Effects: None. +

+

Affected By:

+

+Operating system environment.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+This information should be of use to maintainers of the implementation.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sxhash.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sxhash.htm new file mode 100644 index 00000000..7b20ab53 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_sxhash.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function SXHASH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SXHASH

+

+

Syntax:

+

+ +sxhash object => hash-code

+

+

Arguments and Values:

+

+object---an object.

+hash-code---a non-negative fixnum.

+

Description:

+

+sxhash returns a hash code for object.

+The manner in which the hash code is computed is implementation-dependent, but subject to certain constraints:

+

1. (equal x y) implies (= (sxhash x) (sxhash y)).

+
2. For any two objects, x and y, both of which are bit vectors, characters, conses, numbers, pathnames, strings, or symbols, and which are similar, (sxhash x) and (sxhash y) yield the same mathematical value even if x and y exist in different Lisp images of the same implementation. See Section 3.2.4 (Literal Objects in Compiled Files).

+
3. The hash-code for an object is always the same within a single session provided that the object is not visibly modified with regard to the equivalence test equal. See Section 18.1.2 (Modifying Hash Table Keys).

+
4. The hash-code is intended for hashing. This places no verifiable constraint on a conforming implementation, but the intent is that an implementation should make a good-faith effort to produce hash-codes that are well distributed within the range of non-negative fixnums.

+
5. Computation of the hash-code must terminate, even if the object contains circularities.

+

Examples:

+

+

+ (= (sxhash (list 'list "ab")) (sxhash (list 'list "ab"))) =>  true
+ (= (sxhash "a") (sxhash (make-string 1 :initial-element #\a))) =>  true
+ (let ((r (make-random-state)))
+   (= (sxhash r) (sxhash (make-random-state r))))
+=>  implementation-dependent
+
+

+

Side Effects: None. +

+

Affected By:

+

+The implementation.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+

+Many common hashing needs are satisfied by make-hash-table and the related functions on hash tables. sxhash is intended for use where the pre-defined abstractions are insufficient. Its main intent is to allow the user a convenient means of implementing more complicated hashing paradigms than are provided through hash tables.

+The hash codes returned by sxhash are not necessarily related to any hashing strategy used by any other function in Common Lisp.

+For objects of types that equal compares with eq, item 3 requires that the hash-code be based on some immutable quality of the identity of the object. Another legitimate implementation technique would be to have sxhash assign (and cache) a random hash code for these objects, since there is no requirement that similar but non-eq objects have the same hash code.

+Although similarity is defined for symbols in terms of both the symbol's name and the packages in which the symbol is accessible, item 3 disallows using package information to compute the hash code, since changes to the package status of a symbol are not visible to equal.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_1.htm new file mode 100644 index 00000000..cfba476c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_1.htm @@ -0,0 +1,98 @@ + + + +CLHS: Accessor SYMBOL-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor SYMBOL-FUNCTION

+

Syntax:

+

+ +symbol-function symbol => contents

+ +(setf (symbol-function symbol) new-contents)

+

+

Arguments and Values:

+

+ symbol---a symbol.

+contents--- If the symbol is globally defined as a macro or a special operator, an object of implementation-dependent nature and identity is returned. If the symbol is not globally defined as either a macro or a special operator, and if the symbol is fbound, a function object is returned.

+ new-contents---a function.

+

Description:

+

+Accesses the symbol's function cell.

+

Examples:

+

+

+ (symbol-function 'car) =>  #<FUNCTION CAR>
+ (symbol-function 'twice) is an error   ;because TWICE isn't defined.
+ (defun twice (n) (* n 2)) =>  TWICE
+ (symbol-function 'twice) =>  #<FUNCTION TWICE>
+ (list (twice 3)
+       (funcall (function twice) 3)
+       (funcall (symbol-function 'twice) 3))
+=>  (6 6 6)
+ (flet ((twice (x) (list x x)))
+   (list (twice 3)
+         (funcall (function twice) 3)
+         (funcall (symbol-function 'twice) 3)))
+=>  ((3 3) (3 3) 6)   
+ (setf (symbol-function 'twice) #'(lambda (x) (list x x)))
+=>  #<FUNCTION anonymous>
+ (list (twice 3)
+       (funcall (function twice) 3)
+       (funcall (symbol-function 'twice) 3))
+=>  ((3 3) (3 3) (3 3))
+ (fboundp 'defun) =>  true
+ (symbol-function 'defun)
+=>  implementation-dependent
+ (functionp (symbol-function 'defun))
+=>  implementation-dependent
+ (defun symbol-function-or-nil (symbol)
+   (if (and (fboundp symbol) 
+            (not (macro-function symbol))
+            (not (special-operator-p symbol)))
+       (symbol-function symbol)
+       nil)) =>  SYMBOL-FUNCTION-OR-NIL
+ (symbol-function-or-nil 'car) =>  #<FUNCTION CAR>
+ (symbol-function-or-nil 'defun) =>  NIL
+
+

+

Side Effects: None. +

+

Affected By:

+

+defun

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+Should signal undefined-function if symbol is not fbound and an attempt is made to read its definition. (No such error is signaled on an attempt to write its definition.)

+

See Also:

+

+fboundp, fmakunbound, macro-function, special-operator-p

+

Notes:

+ symbol-function cannot access the value of a lexical function name produced by flet or labels; it can access only the global function value.

+setf may be used with symbol-function to replace a global function definition when the symbol's function definition does not represent a special operator.

+

+(symbol-function symbol) ==  (fdefinition symbol)
+
+ However, fdefinition accepts arguments other than just symbols.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_2.htm new file mode 100644 index 00000000..f074b980 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_2.htm @@ -0,0 +1,58 @@ + + + +CLHS: Function SYMBOL-NAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SYMBOL-NAME

+

Syntax:

+

+ +symbol-name symbol => name

+

+

Arguments and Values:

+

+symbol---a symbol.

+name---a string.

+

Description:

+

+symbol-name returns the name of symbol. The consequences are undefined if name is ever modified.

+

Examples:

+

+

+ (symbol-name 'temp) =>  "TEMP" 
+ (symbol-name :start) =>  "START"
+ (symbol-name (gensym)) =>  "G1234" ;for example
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_3.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_3.htm new file mode 100644 index 00000000..c8de7b6a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_3.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function SYMBOL-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SYMBOL-PACKAGE

+

Syntax:

+

+ +symbol-package symbol => contents

+

+

Arguments and Values:

+

+symbol---a symbol.

+contents---a package object or nil.

+

Description:

+

+Returns the home package of symbol.

+

Examples:

+

+

+ (in-package "CL-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (symbol-package 'car) =>  #<PACKAGE "COMMON-LISP">
+ (symbol-package 'bus) =>  #<PACKAGE "COMMON-LISP-USER">
+ (symbol-package :optional) =>  #<PACKAGE "KEYWORD">
+ ;; Gensyms are uninterned, so have no home package.
+ (symbol-package (gensym)) =>  NIL
+ (make-package 'pk1) =>  #<PACKAGE "PK1">
+ (intern "SAMPLE1" "PK1") =>  PK1::SAMPLE1, NIL
+ (export (find-symbol "SAMPLE1" "PK1") "PK1") =>  T
+ (make-package 'pk2 :use '(pk1)) =>  #<PACKAGE "PK2">
+ (find-symbol "SAMPLE1" "PK2") =>  PK1:SAMPLE1, :INHERITED
+ (symbol-package 'pk1::sample1) =>  #<PACKAGE "PK1">
+ (symbol-package 'pk2::sample1) =>  #<PACKAGE "PK1">
+ (symbol-package 'pk1::sample2) =>  #<PACKAGE "PK1">
+ (symbol-package 'pk2::sample2) =>  #<PACKAGE "PK2">
+ ;; The next several forms create a scenario in which a symbol
+ ;; is not really uninterned, but is "apparently uninterned",
+ ;; and so SYMBOL-PACKAGE still returns NIL.
+ (setq s3 'pk1::sample3) =>  PK1::SAMPLE3
+ (import s3 'pk2) =>  T
+ (unintern s3 'pk1) =>  T
+ (symbol-package s3) =>  NIL
+ (eq s3 'pk2::sample3) =>  T
+
+

+

Side Effects: None. +

+

Affected By:

+

+import, intern, unintern

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+intern

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_4.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_4.htm new file mode 100644 index 00000000..8b063ea6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_4.htm @@ -0,0 +1,67 @@ + + + +CLHS: Accessor SYMBOL-PLIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor SYMBOL-PLIST

+

Syntax:

+

+ +symbol-plist symbol => plist

+ +(setf (symbol-plist symbol) new-plist)

+

+

Arguments and Values:

+

+symbol---a symbol.

+plist, new-plist---a property list.

+

Description:

+

+Accesses the property list of symbol.

+

Examples:

+

+

+ (setq sym (gensym)) =>  #:G9723
+ (symbol-plist sym) =>  ()
+ (setf (get sym 'prop1) 'val1) =>  VAL1
+ (symbol-plist sym) =>  (PROP1 VAL1)
+ (setf (get sym 'prop2) 'val2) =>  VAL2
+ (symbol-plist sym) =>  (PROP2 VAL2 PROP1 VAL1)
+ (setf (symbol-plist sym) (list 'prop3 'val3)) =>  (PROP3 VAL3)
+ (symbol-plist sym) =>  (PROP3 VAL3)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+

See Also:

+

+get, remprop

+

Notes:

+

+The use of setf should be avoided, since a symbol's property list is a global resource that can contain information established and depended upon by unrelated programs in the same Lisp image.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_5.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_5.htm new file mode 100644 index 00000000..ab6d5061 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symb_5.htm @@ -0,0 +1,90 @@ + + + +CLHS: Accessor SYMBOL-VALUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor SYMBOL-VALUE

+

Syntax:

+

+ +symbol-value symbol => value

+ +(setf (symbol-value symbol) new-value)

+

+

Arguments and Values:

+

+symbol---a symbol that must have a value.

+value, new-value---an object.

+

Description:

+

+Accesses the symbol's value cell.

+

Examples:

+

+

+ (setf (symbol-value 'a) 1) =>  1
+ (symbol-value 'a) =>  1
+ ;; SYMBOL-VALUE cannot see lexical variables.
+ (let ((a 2)) (symbol-value 'a)) =>  1
+ (let ((a 2)) (setq a 3) (symbol-value 'a)) =>  1
+ ;; SYMBOL-VALUE can see dynamic variables.
+ (let ((a 2)) 
+   (declare (special a)) 
+   (symbol-value 'a)) =>  2
+ (let ((a 2)) 
+   (declare (special a)) 
+   (setq a 3)
+   (symbol-value 'a)) =>  3
+ (let ((a 2))
+   (setf (symbol-value 'a) 3)
+   a) =>  2
+ a =>  3
+ (symbol-value 'a) =>  3
+ (let ((a 4))
+   (declare (special a))
+   (let ((b (symbol-value 'a)))
+     (setf (symbol-value 'a) 5)
+     (values a b))) =>  5, 4
+ a =>  3
+ (symbol-value :any-keyword) =>  :ANY-KEYWORD
+ (symbol-value 'nil) =>  NIL
+ (symbol-value '()) =>  NIL
+ ;; The precision of this next one is implementation-dependent.
+ (symbol-value 'pi) =>  3.141592653589793d0  
+
+

+

Side Effects: None. +

+

Affected By:

+

+makunbound, set, setq

+

Exceptional Situations:

+

+Should signal an error of type type-error if symbol is not a symbol.

+Should signal unbound-variable if symbol is unbound and an attempt is made to read its value. (No such error is signaled on an attempt to write its value.)

+

See Also:

+

+boundp, makunbound, set, setq

+

Notes:

+

+symbol-value can be used to get the value of a constant variable. symbol-value cannot access the value of a lexical variable.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symbol.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symbol.htm new file mode 100644 index 00000000..b3fc5b71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_symbol.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function SYMBOLP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SYMBOLP

+

Syntax:

+

+ +symbolp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type symbol; otherwise, returns false.

+

Examples:

+

+

+ (symbolp 'elephant) =>  true
+ (symbolp 12) =>  false
+ (symbolp nil) =>  true
+ (symbolp '()) =>  true
+ (symbolp :test) =>  true
+ (symbolp "hello") =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+keywordp, symbol, typep

+

Notes:

+

+

+ (symbolp object) ==  (typep object 'symbol)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_syn_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_syn_st.htm new file mode 100644 index 00000000..603d8af5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_syn_st.htm @@ -0,0 +1,54 @@ + + + +CLHS: Function SYNONYM-STREAM-SYMBOL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function SYNONYM-STREAM-SYMBOL

+

+

Syntax:

+

+ +synonym-stream-symbol synonym-stream => symbol

+

+

Arguments and Values:

+

+synonym-stream---a synonym stream.

+symbol---a symbol.

+

Description:

+

+Returns the symbol whose symbol-value the synonym-stream is using.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-synonym-stream

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_terpri.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_terpri.htm new file mode 100644 index 00000000..7475eb54 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_terpri.htm @@ -0,0 +1,79 @@ + + + +CLHS: Function TERPRI, FRESH-LINE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TERPRI, FRESH-LINE

+

Syntax:

+

+ +terpri &optional output-stream => nil

+ +fresh-line &optional output-stream => generalized-boolean

+

+

Arguments and Values:

+

+output-stream -- an output stream designator. The default is standard output.

+generalized-boolean---a generalized boolean.

+

Description:

+

+terpri outputs a newline to output-stream.

+fresh-line is similar to terpri but outputs a newline only if the output-stream is not already at the start of a line. If for some reason this cannot be determined, then a newline is output anyway. fresh-line returns true if it outputs a newline; otherwise it returns false.

+

Examples:

+

+

+ (with-output-to-string (s)
+    (write-string "some text" s)
+    (terpri s)
+    (terpri s)
+    (write-string "more text" s))
+=>  "some text
+
+more text"
+ (with-output-to-string (s)
+    (write-string "some text" s)
+    (fresh-line s)
+    (fresh-line s)
+    (write-string "more text" s))
+=>  "some text
+more text"
+
+

+

Side Effects:

+

+The output-stream is modified.

+

Affected By:

+

+*standard-output*, *terminal-io*.

+

Exceptional Situations:

+

+None.

See Also: None. +

+

Notes:

+

+terpri is identical in effect to

+

+ (write-char #\Newline output-stream)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tn.htm new file mode 100644 index 00000000..2eb291f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tn.htm @@ -0,0 +1,80 @@ + + + +CLHS: Function TRUENAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TRUENAME

+

Syntax:

+

+ +truename filespec => truename

+

+

Arguments and Values:

+

+ filespec---a pathname designator.

+ truename---a physical pathname.

+

Description:

+

+truename tries to find the file indicated by filespec and returns its truename. If the filespec designator is an open stream, its associated file is used. If filespec is a stream, truename can be used whether the stream is open or closed. It is permissible for truename to return more specific information after the stream is closed than when the stream was open. If filespec is a pathname it represents the name used to open the file. This may be, but is not required to be, the actual name of the file.

+

Examples:

+

+

+;; An example involving version numbers.  Note that the precise nature of
+;; the truename is implementation-dependent while the file is still open.
+ (with-open-file (stream ">vistor>test.text.newest")
+   (values (pathname stream)
+           (truename stream)))
+=>  #P"S:>vistor>test.text.newest", #P"S:>vistor>test.text.1"
+OR=>  #P"S:>vistor>test.text.newest", #P"S:>vistor>test.text.newest"
+OR=>  #P"S:>vistor>test.text.newest", #P"S:>vistor>_temp_._temp_.1"
+
+;; In this case, the file is closed when the truename is tried, so the
+;; truename information is reliable.
+ (with-open-file (stream ">vistor>test.text.newest")
+   (close stream)
+   (values (pathname stream)
+           (truename stream)))
+=>  #P"S:>vistor>test.text.newest", #P"S:>vistor>test.text.1"
+
+;; An example involving TOP-20's implementation-dependent concept 
+;; of logical devices -- in this case, "DOC:" is shorthand for
+;; "PS:<DOCUMENTATION>" ...
+ (with-open-file (stream "CMUC::DOC:DUMPER.HLP")
+   (values (pathname stream)
+           (truename stream)))
+=>  #P"CMUC::DOC:DUMPER.HLP", #P"CMUC::PS:<DOCUMENTATION>DUMPER.HLP.13"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+An error of type file-error is signaled if an appropriate file cannot be located within the file system for the given filespec, or if the file system cannot perform the requested operation.

+ An error of type file-error is signaled if pathname is wild.

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+truename may be used to account for any filename translations performed by the file system.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_err.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_err.htm new file mode 100644 index 00000000..c0670db6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_err.htm @@ -0,0 +1,74 @@ + + + +CLHS: Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE

+

Syntax:

+

+ +type-error-datum condition => datum

+ +type-error-expected-type condition => expected-type

+

+

Arguments and Values:

+

+condition---a condition of type type-error.

+datum---an object.

+expected-type---a type specifier.

+

Description:

+

+type-error-datum returns the offending datum in the situation represented by the condition.

+type-error-expected-type returns the expected type of the offending datum in the situation represented by the condition.

+

Examples:

+

+

+ (defun fix-digits (condition)
+   (check-type condition type-error)
+   (let* ((digits '(zero one two three four
+                   five six seven eight nine))
+         (val (position (type-error-datum condition) digits)))
+     (if (and val (subtypep 'fixnum (type-error-expected-type condition)))
+         (store-value 7))))
+ 
+ (defun foo (x)
+   (handler-bind ((type-error #'fix-digits))
+     (check-type x number)
+     (+ x 3)))
+ 
+ (foo 'seven)
+=>  10
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+type-error, Section 9 (Conditions)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_of.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_of.htm new file mode 100644 index 00000000..342bb3d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tp_of.htm @@ -0,0 +1,98 @@ + + + +CLHS: Function TYPE-OF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TYPE-OF

+

Syntax:

+

+ +type-of object => typespec

+

+

Arguments and Values:

+

+object---an object.

+typespec---a type specifier.

+

Description:

+

+

+Returns a type specifier, typespec, for a type that has the object as an element. The typespec satisfies the following:

+

+

1. For any object that is an element of some built-in type:

+

a. the type returned is a recognizable subtype of that built-in type.

+
b. the type returned does not involve and, eql, member, not, or, satisfies, or values.

+

2. For all objects, (typep object (type-of object)) returns true. Implicit in this is that type specifiers which are not valid for use with typep, such as the list form of the function type specifier, are never returned by type-of.

+
3. The type returned by type-of is always a recognizable subtype of the class returned by class-of. That is,

+
+ (subtypep (type-of object) (class-of object)) =>  true, true
+
+

+

4. For objects of metaclass structure-class or standard-class, and for conditions, type-of returns the proper name of the class returned by class-of if it has a proper name, and otherwise returns the class itself. In particular, for objects created by the constructor function of a structure defined with defstruct without a :type option, type-of returns the structure name; and for objects created by make-condition, the typespec is the name of the condition type.

+
5. For each of the types short-float, single-float, double-float, or long-float of which the object is an element, the typespec is a recognizable subtype of that type.

+

+

+

Examples:

+

+

+
+

+ +

+ (type-of 'a) =>  SYMBOL          
+ (type-of '(1 . 2))
+=>  CONS
+OR=>  (CONS FIXNUM FIXNUM)
+ (type-of #c(0 1))
+=>  COMPLEX
+OR=>  (COMPLEX INTEGER)
+ (defstruct temp-struct x y z) =>  TEMP-STRUCT
+ (type-of (make-temp-struct)) =>  TEMP-STRUCT
+ (type-of "abc")
+=>  STRING
+OR=>  (STRING 3)
+ (subtypep (type-of "abc") 'string) =>  true, true
+ (type-of (expt 2 40))
+=>  BIGNUM
+OR=>  INTEGER
+OR=>  (INTEGER 1099511627776 1099511627776)
+OR=>  SYSTEM::TWO-WORD-BIGNUM
+OR=>  FIXNUM
+ (subtypep (type-of 112312) 'integer) =>  true, true
+ (defvar *foo* (make-array 5 :element-type t)) =>  *FOO*
+ (class-name (class-of *foo*)) =>  VECTOR
+ (type-of *foo*)
+=>  VECTOR
+OR=>  (VECTOR T 5)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+array-element-type, class-of, defstruct, typecase, typep, Section 4.2 (Types)

+

Notes:

+

+Implementors are encouraged to arrange for type-of to return a portable value.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_log.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_log.htm new file mode 100644 index 00000000..05fda116 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_log.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function TRANSLATE-LOGICAL-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TRANSLATE-LOGICAL-PATHNAME

+

+

Syntax:

+

+ +translate-logical-pathname pathname &key => physical-pathname

+

+

Arguments and Values:

+

+pathname---a pathname designator, or a logical pathname namestring.

+physical-pathname---a physical pathname.

+

Description:

+

+Translates pathname to a physical pathname, which it returns.

+ If pathname is a stream, the stream can be either open or closed. translate-logical-pathname returns the same physical pathname after a file is closed as it did when the file was open. It is an error if pathname is a stream that is created with make-two-way-stream, make-echo-stream, make-broadcast-stream, make-concatenated-stream, make-string-input-stream, make-string-output-stream.

+If pathname is a logical pathname namestring, the host portion of the logical pathname namestring and its following colon are required.

+Pathname is first coerced to a pathname. If the coerced pathname is a physical pathname, it is returned. If the coerced pathname is a logical pathname, the first matching translation (according to pathname-match-p) of the logical pathname host is applied, as if by calling translate-pathname. If the result is a logical pathname, this process is repeated. When the result is finally a physical pathname, it is returned. If no translation matches, an error is signaled.

+translate-logical-pathname might perform additional translations, typically to provide translation of file types to local naming conventions, to accomodate physical file systems with limited length names, or to deal with special character requirements such as translating hyphens to underscores or uppercase letters to lowercase. Any such additional translations are implementation-defined. Some implementations do no additional translations.

+ There are no specified keyword arguments for translate-logical-pathname, but implementations are permitted to extend it by adding keyword arguments.

+

Examples:

+

+See logical-pathname-translations.

+

Affected By: None. +

Exceptional Situations:

+

+If pathname is incorrectly supplied, an error of type type-error is signaled.

+If no translation matches, an error of type file-error is signaled.

+

See Also:

+

+logical-pathname, logical-pathname-translations, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_pn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_pn.htm new file mode 100644 index 00000000..acea1202 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tr_pn.htm @@ -0,0 +1,106 @@ + + + +CLHS: Function TRANSLATE-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TRANSLATE-PATHNAME

+

+

Syntax:

+

+ +translate-pathname source from-wildcard to-wildcard &key

=> translated-pathname

+

+

Arguments and Values:

+

+source---a pathname designator.

+from-wildcard---a pathname designator.

+to-wildcard---a pathname designator.

+translated-pathname---a pathname.

+

Description:

+

+translate-pathname translates source (that matches from-wildcard) into a corresponding pathname that matches to-wildcard, and returns the corresponding pathname.

+The resulting pathname is to-wildcard with each wildcard or missing field replaced by a portion of source. A ``wildcard field'' is a pathname component with a value of :wild, a :wild element of a list-valued directory component, or an implementation-defined portion of a component, such as the "*" in the complex wildcard string "foo*bar" that some implementations support. An implementation that adds other wildcard features, such as regular expressions, must define how translate-pathname extends to those features. A ``missing field'' is a pathname component with a value of nil.

+ The portion of source that is copied into the resulting pathname is implementation-defined. Typically it is determined by the user interface conventions of the file systems involved. Usually it is the portion of source that matches a wildcard field of from-wildcard that is in the same position as the wildcard or missing field of to-wildcard. If there is no wildcard field in from-wildcard at that position, then usually it is the entire corresponding pathname component of source, or in the case of a list-valued directory component, the entire corresponding list element.

+ During the copying of a portion of source into the resulting pathname, additional implementation-defined translations of case or file naming conventions might occur, especially when from-wildcard and to-wildcard are for different hosts.

+It is valid for source to be a wild pathname; in general this will produce a wild result. It is valid for from-wildcard and/or to-wildcard to be non-wild pathnames.

+ There are no specified keyword arguments for translate-pathname, but implementations are permitted to extend it by adding keyword arguments.

+ translate-pathname maps customary case in source into customary case in the output pathname.

+

Examples:

+

+

+ ;; The results of the following five forms are all implementation-dependent.
+ ;; The second item in particular is shown with multiple results just to 
+ ;; emphasize one of many particular variations which commonly occurs.
+ (pathname-name (translate-pathname "foobar" "foo*" "*baz")) =>  "barbaz"
+ (pathname-name (translate-pathname "foobar" "foo*" "*"))
+=>  "foobar"
+OR=>  "bar"
+ (pathname-name (translate-pathname "foobar" "*"    "foo*")) =>  "foofoobar"
+ (pathname-name (translate-pathname "bar"    "*"    "foo*")) =>  "foobar"
+ (pathname-name (translate-pathname "foobar" "foo*" "baz*")) =>  "bazbar"
+
+ (defun translate-logical-pathname-1 (pathname rules)
+   (let ((rule (assoc pathname rules :test #'pathname-match-p)))
+     (unless rule (error "No translation rule for ~A" pathname))
+     (translate-pathname pathname (first rule) (second rule))))
+ (translate-logical-pathname-1 "FOO:CODE;BASIC.LISP"
+                       '(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
+                         ("FOO:CODE;"          "MY-UNIX:/lib/foo/")
+                         ("FOO:PATCHES;*;"     "MY-UNIX:/lib/foo/patch/*/")))
+=>  #P"MY-UNIX:/lib/foo/basic.l"
+
+;;;This example assumes one particular set of wildcard conventions
+;;;Not all file systems will run this example exactly as written
+ (defun rename-files (from to)
+   (dolist (file (directory from))
+     (rename-file file (translate-pathname file from to))))
+ (rename-files "/usr/me/*.lisp" "/dev/her/*.l")
+   ;Renames /usr/me/init.lisp to /dev/her/init.l
+ (rename-files "/usr/me/pcl*/*" "/sys/pcl/*/")
+   ;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
+   ;In some file systems the result might be /sys/pcl/5-may/low.lisp
+ (rename-files "/usr/me/pcl*/*" "/sys/library/*/")
+   ;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
+   ;In some file systems the result might be /sys/library/5-may/low.lisp
+ (rename-files "/usr/me/foo.bar" "/usr/me2/")
+   ;Renames /usr/me/foo.bar to /usr/me2/foo.bar
+ (rename-files "/usr/joe/*-recipes.text" "/usr/jim/cookbook/joe's-*-rec.text")
+   ;Renames /usr/joe/lamb-recipes.text to /usr/jim/cookbook/joe's-lamb-rec.text
+   ;Renames /usr/joe/pork-recipes.text to /usr/jim/cookbook/joe's-pork-rec.text
+   ;Renames /usr/joe/veg-recipes.text to /usr/jim/cookbook/joe's-veg-rec.text
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If any of source, from-wildcard, or to-wildcard is not a pathname, a string, or a stream associated with a file an error of type type-error is signaled.

+(pathname-match-p source from-wildcard) must be true or an error of type error is signaled.

+

See Also:

+

+namestring, pathname-host, pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+The exact behavior of translate-pathname cannot be dictated by the Common Lisp language and must be allowed to vary, depending on the user interface conventions of the file systems involved.

+The following is an implementation guideline. One file system performs this operation by examining each piece of the three pathnames in turn, where a piece is a pathname component or a list element of a structured component such as a hierarchical directory. Hierarchical directory elements in from-wildcard and to-wildcard are matched by whether they are wildcards, not by depth in the directory hierarchy. If the piece in to-wildcard is present and not wild, it is copied into the result. If the piece in to-wildcard is :wild or nil, the piece in source is copied into the result. Otherwise, the piece in to-wildcard might be a complex wildcard such as "foo*bar" and the piece in from-wildcard should be wild; the portion of the piece in source that matches the wildcard portion of the piece in from-wildcard replaces the wildcard portion of the piece in to-wildcard and the value produced is used in the result.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tree_e.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tree_e.htm new file mode 100644 index 00000000..8ec01098 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_tree_e.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function TREE-EQUAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TREE-EQUAL

+

+

Syntax:

+

+ +tree-equal tree-1 tree-2 &key test test-not => generalized-boolean

+

+

Arguments and Values:

+

+tree-1---a tree.

+tree-2---a tree.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+generalized-boolean---a generalized boolean.

+

Description:

+

+tree-equal tests whether two trees are of the same shape and have the same leaves. tree-equal returns true if tree-1 and tree-2 are both atoms and satisfy the test, or if they are both conses and the car of tree-1 is tree-equal to the car of tree-2 and the cdr of tree-1 is tree-equal to the cdr of tree-2. Otherwise, tree-equal returns false.

+tree-equal recursively compares conses but not any other objects that have components.

+The first argument to the :test or :test-not function is tree-1 or a car or cdr of tree-1; the second argument is tree-2 or a car or cdr of tree-2.

+

Examples:

+

+

+ (setq tree1 '(1 (1 2))
+       tree2 '(1 (1 2))) =>  (1 (1 2))
+ (tree-equal tree1 tree2) =>  true
+ (eql tree1 tree2) =>  false
+ (setq tree1 '('a ('b 'c))
+       tree2 '('a ('b 'c))) =>  ('a ('b 'c)) 
+=>  ((QUOTE A) ((QUOTE B) (QUOTE C)))
+ (tree-equal tree1 tree2 :test 'eq) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences are undefined if both tree-1 and tree-2 are circular.

+

See Also:

+

+equal, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_two_wa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_two_wa.htm new file mode 100644 index 00000000..b8b25ab3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_two_wa.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function TWO-WAY-STREAM-INPUT-STREAM... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TWO-WAY-STREAM-INPUT-STREAM, TWO-WAY-STREAM-OUTPUT-STREAM

+

+

Syntax:

+

+ +two-way-stream-input-stream two-way-stream => input-stream

+ +two-way-stream-output-stream two-way-stream => output-stream

+

+

Arguments and Values:

+

+two-way-stream---a two-way stream.

+input-stream---an input stream.

+output-stream---an output stream.

+

Description:

+

+two-way-stream-input-stream returns the stream from which two-way-stream receives input.

+two-way-stream-output-stream returns the stream to which two-way-stream sends output.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_typep.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_typep.htm new file mode 100644 index 00000000..fc5dbe9f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_typep.htm @@ -0,0 +1,100 @@ + + + +CLHS: Function TYPEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function TYPEP

+

+

Syntax:

+

+ +typep object type-specifier &optional environment => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+type-specifier---any type specifier except values, or a type specifier list whose first element is either function or values.

+environment---an environment object. The default is nil, denoting the null lexical environment and the and current global environment.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of the type specified by type-specifier; otherwise, returns false.

+A type-specifier of the form (satisfies fn) is handled by applying the function fn to object.

+ (typep object '(array type-specifier)), where type-specifier is not *, returns true if and only if object is an array that could be the result of supplying type-specifier as the :element-type argument to make-array. (array *) refers to all arrays regardless of element type, while (array type-specifier) refers only to those arrays that can result from giving type-specifier as the :element-type argument to make-array. A similar interpretation applies to (simple-array type-specifier) and (vector type-specifier). See Section 15.1.2.1 (Array Upgrading).

+(typep object '(complex type-specifier)) returns true for all complex numbers that can result from giving numbers of type type-specifier to the function complex, plus all other complex numbers of the same specialized representation. Both the real and the imaginary parts of any such complex number must satisfy:

+

+ (typep realpart 'type-specifier)
+ (typep imagpart 'type-specifier)
+
+

+See the function upgraded-complex-part-type.

+

+

Examples:

+

+

+ (typep 12 'integer) =>  true
+ (typep (1+ most-positive-fixnum) 'fixnum) =>  false
+ (typep nil t) =>  true
+ (typep nil nil) =>  false
+ (typep 1 '(mod 2)) =>  true
+ (typep #c(1 1) '(complex (eql 1))) =>  true
+;; To understand this next example, you might need to refer to
+;; Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals).
+ (typep #c(0 0) '(complex (eql 0))) =>  false
+
+

+ Let Ax and Ay be two type specifiers that denote different types, but for which

+

+ (upgraded-array-element-type 'Ax)
+
+ and

+

+ (upgraded-array-element-type 'Ay)
+
+ denote the same type. Notice that

+

+ (typep (make-array 0 :element-type 'Ax) '(array Ax)) =>  true
+ (typep (make-array 0 :element-type 'Ay) '(array Ay)) =>  true
+ (typep (make-array 0 :element-type 'Ax) '(array Ay)) =>  true
+ (typep (make-array 0 :element-type 'Ay) '(array Ax)) =>  true
+
+

+

+

Affected By: None. +

+

Exceptional Situations:

+

+An error of type error is signaled if type-specifier is values, or a type specifier list whose first element is either function or values.

+The consequences are undefined if the type-specifier is not a type specifier.

+

See Also:

+

+type-of, upgraded-array-element-type, upgraded-complex-part-type, Section 4.2.3 (Type Specifiers)

+

Notes:

+

+Implementations are encouraged to recognize and optimize the case of (typep x (the class y)), since it does not involve any need for expansion of deftype information at runtime.

+

+
+
+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unboun.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unboun.htm new file mode 100644 index 00000000..6df44e7d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unboun.htm @@ -0,0 +1,51 @@ + + + +CLHS: Function UNBOUND-SLOT-INSTANCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UNBOUND-SLOT-INSTANCE

+

+

Syntax:

+

+ +unbound-slot-instance condition => instance

+

+

Arguments and Values:

+

+condition---a condition of type unbound-slot.

+instance---an object.

+

Description:

+

+Returns the instance which had the unbound slot in the situation represented by the condition.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+cell-error-name, unbound-slot, Section 9.1 (Condition System Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unexpo.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unexpo.htm new file mode 100644 index 00000000..e38a6a61 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unexpo.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function UNEXPORT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UNEXPORT

+

Syntax:

+

+ +unexport symbols &optional package => t

+

+

Arguments and Values:

+

+symbols---a designator for a list of symbols.

+ package---a package designator. The default is the current package.

+

Description:

+

+unexport reverts external symbols in package to internal status; it undoes the effect of export.

+unexport works only on symbols present in package, switching them back to internal status. If unexport is given a symbol that is already accessible as an internal symbol in package, it does nothing.

+

Examples:

+

+

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (export (intern "CONTRABAND" (make-package 'temp)) 'temp) =>  T
+ (find-symbol "CONTRABAND") =>  NIL, NIL 
+ (use-package 'temp) =>  T 
+ (find-symbol "CONTRABAND") =>  CONTRABAND, :INHERITED
+ (unexport 'contraband 'temp) =>  T
+ (find-symbol "CONTRABAND") =>  NIL, NIL
+
+

+

Side Effects:

+

+Package system is modified.

+

Affected By:

+

+Current state of the package system.

+

Exceptional Situations:

+

+If unexport is given a symbol not accessible in package at all, an error of type package-error is signaled.

+The consequences are undefined if package is the KEYWORD package or the COMMON-LISP package.

+

See Also:

+

+export, Section 11.1 (Package Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_uninte.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_uninte.htm new file mode 100644 index 00000000..d08264fc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_uninte.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function UNINTERN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UNINTERN

+

Syntax:

+

+ +unintern symbol &optional package => generalized-boolean

+

+

Arguments and Values:

+

+symbol---a symbol.

+ package---a package designator. The default is the current package.

+generalized-boolean---a generalized boolean.

+

Description:

+ unintern removes symbol from package. If symbol is present in package, it is removed from package and also from package's shadowing symbols list if it is present there. If package is the home package for symbol, symbol is made to have no home package. Symbol may continue to be accessible in package by inheritance.

+Use of unintern can result in a symbol that has no recorded home package, but that in fact is accessible in some package. Common Lisp does not check for this pathological case, and such symbols are always printed preceded by #:.

+unintern returns true if it removes symbol, and nil otherwise.

+

Examples:

+

+

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (setq temps-unpack (intern "UNPACK" (make-package 'temp))) =>  TEMP::UNPACK 
+ (unintern temps-unpack 'temp) =>  T
+ (find-symbol "UNPACK" 'temp) =>  NIL, NIL 
+ temps-unpack =>  #:UNPACK 
+
+

+

Side Effects:

+

+unintern changes the state of the package system in such a way that the consistency rules do not hold across the change.

+

Affected By:

+ Current state of the package system.

+

Exceptional Situations:

+ Giving a shadowing symbol to unintern can uncover a name conflict that had previously been resolved by the shadowing. If package A uses packages B and C, A contains a shadowing symbol x, and B and C each contain external symbols named x, then removing the shadowing symbol x from A will reveal a name conflict between b:x and c:x if those two symbols are distinct. In this case unintern will signal an error.

+

See Also:

+

+Section 11.1 (Package Concepts)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unionc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unionc.htm new file mode 100644 index 00000000..3003ad07 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unionc.htm @@ -0,0 +1,84 @@ + + + +CLHS: Function UNION, NUNION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UNION, NUNION

+

Syntax:

+

+ +union list-1 list-2 &key key test test-not => result-list

+ +nunion list-1 list-2 &key key test test-not => result-list

+

+

Arguments and Values:

+

+list-1---a proper list.

+list-2---a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+result-list---a list.

+

Description:

+

+union and nunion return a list that contains every element that occurs in either list-1 or list-2.

+For all possible ordered pairs consisting of one element from list-1 and one element from list-2, :test or :test-not is used to determine whether they satisfy the test. The first argument to the :test or :test-not function is the part of the element of list-1 extracted by the :key function (if supplied); the second argument is the part of the element of list-2 extracted by the :key function (if supplied).

+The argument to the :key function is an element of list-1 or list-2; the return value is part of the supplied element. If :key is not supplied or nil, the element of list-1 or list-2 itself is supplied to the :test or :test-not function.

+For every matching pair, one of the two elements of the pair will be in the result. Any element from either list-1 or list-2 that matches no element of the other will appear in the result.

+If there is a duplication between list-1 and list-2, only one of the duplicate instances will be in the result. If either list-1 or list-2 has duplicate entries within it, the redundant entries might or might not appear in the result.

+The order of elements in the result do not have to reflect the ordering of list-1 or list-2 in any way. The result list may be eq to either list-1 or list-2 if appropriate.

+

Examples:

+

+

+ (union '(a b c) '(f a d))
+=>  (A B C F D)
+OR=>  (B C F A D)
+OR=>  (D F A B C)
+ (union '((x 5) (y 6)) '((z 2) (x 4)) :key #'car)
+=>  ((X 5) (Y 6) (Z 2))
+OR=>  ((X 4) (Y 6) (Z 2))
+
+ (setq lst1 (list 1 2 '(1 2) "a" "b")
+       lst2 (list 2 3 '(2 3) "B" "C"))
+=>  (2 3 (2 3) "B" "C")
+ (nunion lst1 lst2)
+=>  (1 (1 2) "a" "b" 2 3 (2 3) "B" "C") 
+OR=>  (1 2 (1 2) "a" "b" "C" "B" (2 3) 3)
+
+

+

Side Effects:

+

+ nunion is permitted to modify any part, car or cdr, of the list structure of list-1 or list-2.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if list-1 and list-2 are not proper lists.

+

See Also:

+

+intersection, Section 3.2.1 (Compiler Terminology), Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+ The :test-not parameter is deprecated.

+Since the nunion side effect is not required, it should not be used in for-effect-only positions in portable code.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unrd_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unrd_c.htm new file mode 100644 index 00000000..1dd00dea --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unrd_c.htm @@ -0,0 +1,66 @@ + + + +CLHS: Function UNREAD-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UNREAD-CHAR

+

Syntax:

+

+ +unread-char character &optional input-stream => nil

+

+

Arguments and Values:

+

+character---a character; must be the last character that was read from input-stream.

+input-stream---an input stream designator. The default is standard input.

+

Description:

+

+unread-char places character back onto the front of input-stream so that it will again be the next character in input-stream.

+ When input-stream is an echo stream, no attempt is made to undo any echoing of the character that might already have been done on input-stream. However, characters placed on input-stream by unread-char are marked in such a way as to inhibit later re-echo by read-char.

+It is an error to invoke unread-char twice consecutively on the same stream without an intervening call to read-char (or some other input operation which implicitly reads characters) on that stream.

+ Invoking peek-char or read-char commits all previous characters. The consequences of invoking unread-char on any character preceding that which is returned by peek-char (including those passed over by peek-char that has a non-nil peek-type) are unspecified. In particular, the consequences of invoking unread-char after peek-char are unspecified.

+

Examples:

+

+

+ (with-input-from-string (is "0123")
+    (dotimes (i 6)
+      (let ((c (read-char is)))
+        (if (evenp i) (format t "~&~S ~S~%" i c) (unread-char c is)))))
+>>  0 #\0
+>>  2 #\1
+>>  4 #\2
+=>  NIL
+
+

+

Affected By:

+

+*standard-input*, *terminal-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+peek-char, read-char, Section 21.1 (Stream Concepts)

+

Notes:

+

+unread-char is intended to be an efficient mechanism for allowing the Lisp reader and other parsers to perform one-character lookahead in input-stream.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unuse_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unuse_.htm new file mode 100644 index 00000000..2adb424b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_unuse_.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function UNUSE-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UNUSE-PACKAGE

+

Syntax:

+

+ +unuse-package packages-to-unuse &optional package => t

+

+

Arguments and Values:

+

+ packages-to-unuse---a designator for a list of package designators.

+package---a package designator. The default is the current package.

+

Description:

+

+unuse-package causes package to cease inheriting all the external symbols of packages-to-unuse; unuse-package undoes the effects of use-package. The packages-to-unuse are removed from the use list of package.

+Any symbols that have been imported into package continue to be present in package.

+

Examples:

+

+

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ (export (intern "SHOES" (make-package 'temp)) 'temp) =>  T
+ (find-symbol "SHOES") =>  NIL, NIL
+ (use-package 'temp) =>  T
+ (find-symbol "SHOES") =>  SHOES, :INHERITED
+ (find (find-package 'temp) (package-use-list 'common-lisp-user)) =>  #<PACKAGE "TEMP">
+ (unuse-package 'temp) =>  T
+ (find-symbol "SHOES") =>  NIL, NIL
+
+

+

Side Effects:

+

+The use list of package is modified.

+

Affected By:

+ Current state of the package system.

Exceptional Situations: None. +

+

See Also:

+

+use-package, package-use-list

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upda_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upda_1.htm new file mode 100644 index 00000000..05195f89 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upda_1.htm @@ -0,0 +1,115 @@ + + + +CLHS: Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS

+

Syntax:

+

+ +update-instance-for-redefined-class instance added-slots discarded-slots property-list &rest initargs &key &allow-other-keys

=> result*

+

+

Method Signatures:

+

+ +update-instance-for-redefined-class (instance standard-object) added-slots discarded-slots property-list &rest initargs

+

+

Arguments and Values:

+

+instance---an object.

+added-slots---a list.

+discarded-slots---a list.

+property-list---a list.

+initargs---an initialization argument list.

+result---an object.

+

Description:

+

+The generic function update-instance-for-redefined-class is not intended to be called by programmers. Programmers may write methods for it. The generic function update-instance-for-redefined-class is called by the mechanism activated by make-instances-obsolete.

+The system-supplied primary method on update-instance-for-redefined-class checks the validity of initargs and signals an error if an initarg is supplied that is not declared as valid. This method then initializes slots with values according to the initargs, and initializes the newly added-slots with values according to their :initform forms. It does this by calling the generic function shared-initialize with the following arguments: the instance, a list of names of the newly added-slots to instance, and the initargs it received. Newly added-slots are those local slots for which no slot of the same name exists in the old version of the class.

+When make-instances-obsolete is invoked or when a class has been redefined and an instance is being updated, a property-list is created that captures the slot names and values of all the discarded-slots with values in the original instance. The structure of the instance is transformed so that it conforms to the current class definition. The arguments to update-instance-for-redefined-class are this transformed instance, a list of added-slots to the instance, a list discarded-slots from the instance, and the property-list containing the slot names and values for slots that were discarded and had values. Included in this list of discarded slots are slots that were local in the old class and are shared in the new class.

+The value returned by update-instance-for-redefined-class is ignored.

+

Examples:

+

+

+  
+ (defclass position () ())
+ 
+ (defclass x-y-position (position)
+     ((x :initform 0 :accessor position-x)
+      (y :initform 0 :accessor position-y)))
+ 
+;;; It turns out polar coordinates are used more than Cartesian 
+;;; coordinates, so the representation is altered and some new
+;;; accessor methods are added.
+ 
+ (defmethod update-instance-for-redefined-class :before
+    ((pos x-y-position) added deleted plist &key)
+   ;; Transform the x-y coordinates to polar coordinates
+   ;; and store into the new slots.
+   (let ((x (getf plist 'x))
+         (y (getf plist 'y)))
+     (setf (position-rho pos) (sqrt (+ (* x x) (* y y)))
+           (position-theta pos) (atan y x))))
+  
+ (defclass x-y-position (position)
+     ((rho :initform 0 :accessor position-rho)
+      (theta :initform 0 :accessor position-theta)))
+  
+;;; All instances of the old x-y-position class will be updated
+;;; automatically.
+ 
+;;; The new representation is given the look and feel of the old one.
+ 
+ (defmethod position-x ((pos x-y-position))  
+    (with-slots (rho theta) pos (* rho (cos theta))))
+ 
+ (defmethod (setf position-x) (new-x (pos x-y-position))
+    (with-slots (rho theta) pos
+      (let ((y (position-y pos)))
+        (setq rho (sqrt (+ (* new-x new-x) (* y y)))
+              theta (atan y new-x))
+        new-x)))
+ 
+ (defmethod position-y ((pos x-y-position))
+    (with-slots (rho theta) pos (* rho (sin theta))))
+ 
+ (defmethod (setf position-y) (new-y (pos x-y-position))
+    (with-slots (rho theta) pos
+      (let ((x (position-x pos)))
+        (setq rho (sqrt (+ (* x x) (* new-y new-y)))
+              theta (atan new-y x))
+        new-y)))
+ 
+
+

+

Affected By: None. +

+

Exceptional Situations:

+ The system-supplied primary method on update-instance-for-redefined-class signals an error if an initarg is supplied that is not declared as valid.

+

See Also:

+

+make-instances-obsolete, shared-initialize, Section 4.3.6 (Redefining Classes), Section 7.1.4 (Rules for Initialization Arguments), Section 7.1.2 (Declaring the Validity of Initialization Arguments)

+

Notes:

+

+Initargs are declared as valid by using the :initarg option to defclass, or by defining methods for update-instance-for-redefined-class or shared-initialize. The keyword name of each keyword parameter specifier in the lambda list of any method defined on update-instance-for-redefined-class or shared-initialize is declared as a valid initarg name for all classes for which that method is applicable.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_update.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_update.htm new file mode 100644 index 00000000..a5518835 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_update.htm @@ -0,0 +1,63 @@ + + + +CLHS: Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS

+

Syntax:

+

+ +update-instance-for-different-class previous current &rest initargs &key &allow-other-keys => implementation-dependent

+

+

Method Signatures:

+

+ +update-instance-for-different-class (previous standard-object) (current standard-object) &rest initargs

+

+

Arguments and Values:

+

+previous---a copy of the original instance.

+current---the original instance (altered).

+initargs---an initialization argument list.

+

Description:

+

+The generic function update-instance-for-different-class is not intended to be called by programmers. Programmers may write methods for it. The function update-instance-for-different-class is called only by the function change-class.

+The system-supplied primary method on update-instance-for-different-class checks the validity of initargs and signals an error if an initarg is supplied that is not declared as valid. This method then initializes slots with values according to the initargs, and initializes the newly added slots with values according to their :initform forms. It does this by calling the generic function shared-initialize with the following arguments: the instance (current), a list of names of the newly added slots, and the initargs it received. Newly added slots are those local slots for which no slot of the same name exists in the previous class.

+Methods for update-instance-for-different-class can be defined to specify actions to be taken when an instance is updated. If only after methods for update-instance-for-different-class are defined, they will be run after the system-supplied primary method for initialization and therefore will not interfere with the default behavior of update-instance-for-different-class.

+Methods on update-instance-for-different-class can be defined to initialize slots differently from change-class. The default behavior of change-class is described in Section 7.2 (Changing the Class of an Instance).

+The arguments to update-instance-for-different-class are computed by change-class. When change-class is invoked on an instance, a copy of that instance is made; change-class then destructively alters the original instance. The first argument to update-instance-for-different-class, previous, is that copy; it holds the old slot values temporarily. This argument has dynamic extent within change-class; if it is referenced in any way once update-instance-for-different-class returns, the results are undefined. The second argument to update-instance-for-different-class, current, is the altered original instance. The intended use of previous is to extract old slot values by using slot-value or with-slots or by invoking a reader generic function, or to run other methods that were applicable to instances of the original class.

+

Examples:

+

+See the example for the function change-class.

+

Affected By: None. +

+

Exceptional Situations:

+ The system-supplied primary method on update-instance-for-different-class signals an error if an initialization argument is supplied that is not declared as valid.

+

See Also:

+

+change-class, shared-initialize, Section 7.2 (Changing the Class of an Instance), Section 7.1.4 (Rules for Initialization Arguments), Section 7.1.2 (Declaring the Validity of Initialization Arguments)

+

Notes:

+

+Initargs are declared as valid by using the :initarg option to defclass, or by defining methods for update-instance-for-different-class or shared-initialize. The keyword name of each keyword parameter specifier in the lambda list of any method defined on update-instance-for-different-class or shared-initialize is declared as a valid initarg name for all classes for which that method is applicable.

+The value returned by update-instance-for-different-class is ignored by change-class.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgr_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgr_1.htm new file mode 100644 index 00000000..14eab34f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgr_1.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function UPGRADED-ARRAY-ELEMENT-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UPGRADED-ARRAY-ELEMENT-TYPE

+

Syntax:

+

+ +upgraded-array-element-type typespec &optional environment => upgraded-typespec

+

+

Arguments and Values:

+

+typespec---a type specifier.

+environment---an environment object. The default is nil, denoting the null lexical environment and the current global environment.

+upgraded-typespec---a type specifier.

+

Description:

+

+Returns the element type of the most specialized array representation capable of holding items of the type denoted by typespec.

+The typespec is a subtype of (and possibly type equivalent to) the upgraded-typespec.

+If typespec is bit, the result is type equivalent to bit. If typespec is base-char, the result is type equivalent to base-char. If typespec is character, the result is type equivalent to character.

+The purpose of upgraded-array-element-type is to reveal how an implementation does its upgrading.

+The environment is used to expand any derived type specifiers that are mentioned in the typespec.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+array-element-type, make-array

+

Notes:

+

+Except for storage allocation consequences and dealing correctly with the optional environment argument, upgraded-array-element-type could be defined as:

+

+ (defun upgraded-array-element-type (type &optional environment)
+   (array-element-type (make-array 0 :element-type type)))
+
+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgrad.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgrad.htm new file mode 100644 index 00000000..8a9a4112 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upgrad.htm @@ -0,0 +1,57 @@ + + + +CLHS: Function UPGRADED-COMPLEX-PART-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UPGRADED-COMPLEX-PART-TYPE

+

+

Syntax:

+

+ +upgraded-complex-part-type typespec &optional environment => upgraded-typespec

+

+

Arguments and Values:

+

+typespec---a type specifier.

+environment---an environment object. The default is nil, denoting the null lexical environment and the and current global environment.

+upgraded-typespec---a type specifier.

+

Description:

+

+upgraded-complex-part-type returns the part type of the most specialized complex number representation that can hold parts of type typespec.

+The typespec is a subtype of (and possibly type equivalent to) the upgraded-typespec.

+The purpose of upgraded-complex-part-type is to reveal how an implementation does its upgrading.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+complex (function and type)

+

Notes:

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upper_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upper_.htm new file mode 100644 index 00000000..aed22732 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_upper_.htm @@ -0,0 +1,72 @@ + + + +CLHS: Function UPPER-CASE-P, LOWER-CASE-P... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P

+

Syntax:

+

+ +upper-case-p character => generalized-boolean

+ +lower-case-p character => generalized-boolean

+ +both-case-p character => generalized-boolean

+

+

Arguments and Values:

+

+character---a character.

+generalized-boolean---a generalized boolean.

+

Description:

+

+These functions test the case of a given character.

+upper-case-p returns true if character is an uppercase character; otherwise, returns false.

+lower-case-p returns true if character is a lowercase character; otherwise, returns false.

+both-case-p returns true if character is a character with case; otherwise, returns false.

+

Examples:

+

+

+ (upper-case-p #\A) =>  true
+ (upper-case-p #\a) =>  false
+ (both-case-p #\a) =>  true
+ (both-case-p #\5) =>  false
+ (lower-case-p #\5) =>  false
+ (upper-case-p #\5) =>  false
+ ;; This next example presupposes an implementation 
+ ;; in which #\Bell is an implementation-defined character.
+ (lower-case-p #\Bell) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if character is not a character.

+

See Also:

+

+char-upcase, char-downcase, Section 13.1.4.3 (Characters With Case), Section 13.1.10 (Documentation of Implementation-Defined Scripts)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_use_pk.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_use_pk.htm new file mode 100644 index 00000000..8531a9d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_use_pk.htm @@ -0,0 +1,64 @@ + + + +CLHS: Function USE-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function USE-PACKAGE

+

Syntax:

+

+ +use-package packages-to-use &optional package => t

+

+

Arguments and Values:

+

+ packages-to-use---a designator for a list of package designators. The KEYWORD package may not be supplied.

+package---a package designator. The default is the current package. The package cannot be the KEYWORD package.

+

Description:

+

+use-package causes package to inherit all the external symbols of packages-to-use. The inherited symbols become accessible as internal symbols of package.

+Packages-to-use are added to the use list of package if they are not there already. All external symbols in packages-to-use become accessible in package as internal symbols. use-package does not cause any new symbols to be present in package but only makes them accessible by inheritance.

+use-package checks for name conflicts between the newly imported symbols and those already accessible in package. A name conflict in use-package between two external symbols inherited by package from packages-to-use may be resolved in favor of either symbol by importing one of them into package and making it a shadowing symbol.

+

Examples:

+

+

+ (export (intern "LAND-FILL" (make-package 'trash)) 'trash) =>  T
+ (find-symbol "LAND-FILL" (make-package 'temp)) =>  NIL, NIL
+ (package-use-list 'temp) =>  (#<PACKAGE "TEMP">)
+ (use-package 'trash 'temp) =>  T
+ (package-use-list 'temp) =>  (#<PACKAGE "TEMP"> #<PACKAGE "TRASH">)
+ (find-symbol "LAND-FILL" 'temp) =>  TRASH:LAND-FILL, :INHERITED
+
+

+

Side Effects:

+

+The use list of package may be modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

See Also:

+

+unuse-package, package-use-list, Section 11.1 (Package Concepts)

+

Notes:

+

+It is permissible for a package P1 to use a package P2 even if P2 already uses P1. The using of packages is not transitive, so no problem results from the apparent circularity.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_user_h.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_user_h.htm new file mode 100644 index 00000000..cc7fb64f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_user_h.htm @@ -0,0 +1,59 @@ + + + +CLHS: Function USER-HOMEDIR-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function USER-HOMEDIR-PATHNAME

+

Syntax:

+

+ +user-homedir-pathname &optional host => pathname

+

+

Arguments and Values:

+

+host---a string, a list of strings, or :unspecific.

+pathname---a pathname, or nil.

+

Description:

+

+user-homedir-pathname determines the pathname that corresponds to the user's home directory on host. If host is not supplied, its value is implementation-dependent. For a description of :unspecific, see Section 19.2.1 (Pathname Components).

+The definition of home directory is implementation-dependent, but defined in Common Lisp to mean the directory where the user keeps personal files such as initialization files and mail.

+user-homedir-pathname returns a pathname without any name, type, or version component (those components are all nil) for the user's home directory on host.

+If it is impossible to determine the user's home directory on host, then nil is returned. user-homedir-pathname never returns nil if host is not supplied.

+

Examples:

+

+

+ (pathnamep (user-homedir-pathname)) =>  true
+
+

+

Side Effects: None. +

+

Affected By:

+

+The host computer's file system, and the implementation.

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vals_l.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vals_l.htm new file mode 100644 index 00000000..1e277aeb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vals_l.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function VALUES-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function VALUES-LIST

+

Syntax:

+

+ +values-list list => element*

+

+

Arguments and Values:

+

+list---a list.

+elements---the elements of the list.

+

Description:

+

+Returns the elements of the list as multiple values[2].

+

Examples:

+

+

+ (values-list nil) =>  <no values>
+ (values-list '(1)) =>  1
+ (values-list '(1 2)) =>  1, 2
+ (values-list '(1 2 3)) =>  1, 2, 3
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal type-error if its argument is not a proper list.

+

See Also:

+

+multiple-value-bind, multiple-value-list, multiple-values-limit, values

+

Notes:

+

+

+ (values-list list) ==  (apply #'values list)
+
+

+(equal x (multiple-value-list (values-list x))) returns true for all lists x.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_values.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_values.htm new file mode 100644 index 00000000..7029ac7e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_values.htm @@ -0,0 +1,79 @@ + + + +CLHS: Accessor VALUES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Accessor VALUES

+

Syntax:

+

+ +values &rest object => object*

+ +(setf (values &rest place) new-values)

+

+

Arguments and Values:

+

+object---an object.

+ place---a place.

+new-value---an object.

+

Description:

+

+values returns the objects as multiple values[2].

+ setf of values is used to store the multiple values[2] new-values into the places. See Section 5.1.2.3 (VALUES Forms as Places).

+

Examples:

+

+

+ (values) =>  <no values>
+ (values 1) =>  1
+ (values 1 2) =>  1, 2
+ (values 1 2 3) =>  1, 2, 3
+ (values (values 1 2 3) 4 5) =>  1, 4, 5
+ (defun polar (x y)
+   (values (sqrt (+ (* x x) (* y y))) (atan y x))) =>  POLAR
+ (multiple-value-bind (r theta) (polar 3.0 4.0)
+   (vector r theta))
+=>  #(5.0 0.927295)
+
+

+Sometimes it is desirable to indicate explicitly that a function returns exactly one value. For example, the function

+

+ (defun foo (x y)
+   (floor (+ x y) y)) =>  FOO
+
+ returns two values because floor returns two values. It may be that the second value makes no sense, or that for efficiency reasons it is desired not to compute the second value. values is the standard idiom for indicating that only one value is to be returned:

+

+ (defun foo (x y)
+   (values (floor (+ x y) y))) =>  FOO
+
+ This works because values returns exactly one value for each of args; as for any function call, if any of args produces more than one value, all but the first are discarded.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+values-list, multiple-value-bind, multiple-values-limit, Section 3.1 (Evaluation)

+

Notes:

+

+Since values is a function, not a macro or special form, it receives as arguments only the primary values of its argument forms.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_po.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_po.htm new file mode 100644 index 00000000..32b4f27e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_po.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function VECTOR-POP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function VECTOR-POP

+

Syntax:

+

+ +vector-pop vector => element

+

+

Arguments and Values:

+

+vector---a vector with a fill pointer.

+element---an object.

+

Description:

+

+Decreases the fill pointer of vector by one, and retrieves the element of vector that is designated by the new fill pointer.

+

Examples:

+

+

+ (vector-push (setq fable (list 'fable))
+              (setq fa (make-array 8
+                                   :fill-pointer 2
+                                   :initial-element 'sisyphus))) =>  2 
+ (fill-pointer fa) =>  3 
+ (eq (vector-pop fa) fable) =>  true
+ (vector-pop fa) =>  SISYPHUS 
+ (fill-pointer fa) =>  1 
+
+

+

Side Effects:

+

+The fill pointer is decreased by one.

+

Affected By:

+

+The value of the fill pointer.

+

Exceptional Situations:

+

+An error of type type-error is signaled if vector does not have a fill pointer.

+If the fill pointer is zero, vector-pop signals an error of type error.

+

See Also:

+

+vector-push, vector-push-extend, fill-pointer

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_ps.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_ps.htm new file mode 100644 index 00000000..171fe155 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vec_ps.htm @@ -0,0 +1,81 @@ + + + +CLHS: Function VECTOR-PUSH, VECTOR-PUSH-EXTEND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function VECTOR-PUSH, VECTOR-PUSH-EXTEND

+

Syntax:

+

+ +vector-push new-element vector => new-index-p

+

+ +vector-push-extend new-element vector &optional extension => new-index

+

+

Arguments and Values:

+

+new-element---an object.

+vector---a vector with a fill pointer.

+extension---a positive integer. The default is implementation-dependent.

+new-index-p---a valid array index for vector, or nil.

+new-index---a valid array index for vector.

+

Description:

+

+vector-push and vector-push-extend store new-element in vector. vector-push attempts to store new-element in the element of vector designated by the fill pointer, and to increase the fill pointer by one. If the (>= (fill-pointer vector) (array-dimension vector 0)), neither vector nor its fill pointer are affected. Otherwise, the store and increment take place and vector-push returns the former value of the fill pointer which is one less than the one it leaves in vector.

+vector-push-extend is just like vector-push except that if the fill pointer gets too large, vector is extended using adjust-array so that it can contain more elements. Extension is the minimum number of elements to be added to vector if it must be extended.

+vector-push and vector-push-extend return the index of new-element in vector. If (>= (fill-pointer vector) (array-dimension vector 0)), vector-push returns nil.

+

Examples:

+

+

+ (vector-push (setq fable (list 'fable))
+              (setq fa (make-array 8 
+                                   :fill-pointer 2
+                                   :initial-element 'first-one))) =>  2 
+ (fill-pointer fa) =>  3 
+ (eq (aref fa 2) fable) =>  true
+ (vector-push-extend #\X
+                    (setq aa 
+                          (make-array 5
+                                      :element-type 'character
+                                      :adjustable t
+                                      :fill-pointer 3))) =>  3 
+ (fill-pointer aa) =>  4 
+ (vector-push-extend #\Y aa 4) =>  4 
+ (array-total-size aa) =>  at least 5 
+ (vector-push-extend #\Z aa 4) =>  5 
+ (array-total-size aa) =>  9 ;(or more)
+
+

+

Affected By:

+ The value of the fill pointer.

+How vector was created.

+

Exceptional Situations:

+

+An error of type error is signaled by vector-push-extend if it tries to extend vector and vector is not actually adjustable.

+An error of type error is signaled if vector does not have a fill pointer.

+

See Also:

+

+adjustable-array-p, fill-pointer, vector-pop

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vecp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vecp.htm new file mode 100644 index 00000000..b8cb64be --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vecp.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function VECTORP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function VECTORP

+

Syntax:

+

+ +vectorp object => generalized-boolean

+

+

Arguments and Values:

+

+object---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if object is of type vector; otherwise, returns false.

+

Examples:

+

+

+ (vectorp "aaaaaa") =>  true
+ (vectorp (make-array 6 :fill-pointer t)) =>  true
+ (vectorp (make-array '(2 3 4))) =>  false
+ (vectorp #*11) =>  true
+ (vectorp #b11) =>  false
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes:

+ +

+ (vectorp object) ==  (typep object 'vector)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vector.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vector.htm new file mode 100644 index 00000000..de4f5af8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_vector.htm @@ -0,0 +1,67 @@ + + + +CLHS: Function VECTOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function VECTOR

+

Syntax:

+

+ +vector &rest objects => vector

+

+

Arguments and Values:

+

+object---an object.

+vector---a vector of type (vector t *).

+

Description:

+

+Creates a fresh simple general vector whose size corresponds to the number of objects.

+The vector is initialized to contain the objects.

+

Examples:

+

+

+ (arrayp (setq v (vector 1 2 'sirens))) =>  true
+ (vectorp v) =>  true
+ (simple-vector-p v) =>  true         
+ (length v) =>  3
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-array

+

Notes:

+

+vector is analogous to list.

+

+ (vector a1 a2 ... an)
+  ==  (make-array (list n) :element-type t
+                          :initial-contents 
+                            (list a1 a2 ... an))
+
+
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_warn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_warn.htm new file mode 100644 index 00000000..425ce160 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_warn.htm @@ -0,0 +1,93 @@ + + + +CLHS: Function WARN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WARN

+

Syntax:

+

+ +warn datum &rest arguments => nil

+

+

Arguments and Values:

+

+datum, arguments---designators for a condition of default type simple-warning.

+

Description:

+

+Signals a condition of type warning. If the condition is not handled, reports the condition to error output.

+The precise mechanism for warning is as follows:

+

+

+

The warning condition is signaled

+While the warning condition is being signaled, the muffle-warning restart is established for use by a handler. If invoked, this restart bypasses further action by warn, which in turn causes warn to immediately return nil.

+

If no handler for the warning condition is found

+If no handlers for the warning condition are found, or if all such handlers decline, then the condition is reported to error output by warn in an implementation-dependent format.

+

nil is returned

+The value returned by warn if it returns is nil.

+

Examples:

+

+

+  (defun foo (x)
+    (let ((result (* x 2)))
+      (if (not (typep result 'fixnum))
+          (warn "You're using very big numbers."))
+      result))
+=>  FOO
+ 
+  (foo 3)
+=>  6
+ 
+  (foo most-positive-fixnum)
+>>  Warning: You're using very big numbers.
+=>  4294967294
+ 
+  (setq *break-on-signals* t)
+=>  T
+ 
+  (foo most-positive-fixnum)
+>>  Break: Caveat emptor.
+>>  To continue, type :CONTINUE followed by an option number.
+>>   1: Return from Break.
+>>   2: Abort to Lisp Toplevel.
+>>  Debug> :continue 1
+>>  Warning: You're using very big numbers.
+=>  4294967294
+
+

+

Side Effects:

+

+A warning is issued. The debugger might be entered.

+

Affected By:

+

+Existing handler bindings.

+*break-on-signals*, *error-output*.

+

Exceptional Situations:

+

+If datum is a condition and if the condition is not of type warning, or arguments is non-nil, an error of type type-error is signaled.

+If datum is a condition type, the result of (apply #'make-condition datum arguments) must be of type warning or an error of type type-error is signaled.

+

See Also:

+

+*break-on-signals*, muffle-warning, signal

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wild_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wild_p.htm new file mode 100644 index 00000000..b9c86b18 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wild_p.htm @@ -0,0 +1,69 @@ + + + +CLHS: Function WILD-PATHNAME-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WILD-PATHNAME-P

+

+

Syntax:

+

+ +wild-pathname-p pathname &optional field-key => generalized-boolean

+

+

Arguments and Values:

+

+ pathname---a pathname designator.

+Field-key---one of :host, :device :directory, :name, :type, :version, or nil.

+generalized-boolean---a generalized boolean.

+

Description:

+

+wild-pathname-p tests pathname for the presence of wildcard components.

+If pathname is a pathname (as returned by pathname) it represents the name used to open the file. This may be, but is not required to be, the actual name of the file.

+If field-key is not supplied or nil, wild-pathname-p returns true if pathname has any wildcard components, nil if pathname has none. If field-key is non-nil, wild-pathname-p returns true if the indicated component of pathname is a wildcard, nil if the component is not a wildcard.

+

Examples:

+ +

+ ;;;The following examples are not portable.  They are written to run
+ ;;;with particular file systems and particular wildcard conventions.
+ ;;;Other implementations will behave differently.  These examples are
+ ;;;intended to be illustrative, not to be prescriptive.
+ 
+ (wild-pathname-p (make-pathname :name :wild)) =>  true
+ (wild-pathname-p (make-pathname :name :wild) :name) =>  true
+ (wild-pathname-p (make-pathname :name :wild) :type) =>  false
+ (wild-pathname-p (pathname "s:>foo>**>")) =>  true ;Lispm
+ (wild-pathname-p (pathname :name "F*O")) =>  true ;Most places
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If pathname is not a pathname, a string, or a stream associated with a file an error of type type-error is signaled.

+

See Also:

+

+ pathname, logical-pathname, Section 20.1 (File System Concepts), Section 19.1.2 (Pathnames as Filenames)

+

Notes:

+

+Not all implementations support wildcards in all fields. See Section 19.2.2.2.2 (:WILD as a Component Value) and Section 19.2.2.3 (Restrictions on Wildcard Pathnames).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_by.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_by.htm new file mode 100644 index 00000000..6d3aff26 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_by.htm @@ -0,0 +1,63 @@ + + + +CLHS: Function WRITE-BYTE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WRITE-BYTE

+

Syntax:

+

+ +write-byte byte stream => byte

+

+

Arguments and Values:

+

+byte---an integer of the stream element type of stream.

+stream---a binary output stream.

+

Description:

+

+write-byte writes one byte, byte, to stream.

+

Examples:

+

+

+ (with-open-file (s "temp-bytes" 
+                    :direction :output
+                    :element-type 'unsigned-byte)
+    (write-byte 101 s)) =>  101
+
+

+

Side Effects:

+

+stream is modified.

+

Affected By:

+

+The element type of the stream.

+

Exceptional Situations:

+

+Should signal an error of type type-error if stream is not a stream. Should signal an error of type error if stream is not a binary output stream.

+Might signal an error of type type-error if byte is not an integer of the stream element type of stream.

+

See Also:

+

+read-byte, write-char, write-sequence

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_cha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_cha.htm new file mode 100644 index 00000000..3a4ec624 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_cha.htm @@ -0,0 +1,65 @@ + + + +CLHS: Function WRITE-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WRITE-CHAR

+

Syntax:

+

+ +write-char character &optional output-stream => character

+

+

Arguments and Values:

+

+character---a character.

+output-stream -- an output stream designator. The default is standard output.

+

Description:

+

+write-char outputs character to output-stream.

+

Examples:

+ +

+ (write-char #\a)
+>>  a
+=>  #\a
+ (with-output-to-string (s) 
+   (write-char #\a s)
+   (write-char #\Space s)
+   (write-char #\b s))
+=>  "a b"
+
+

+

Side Effects:

+

+The output-stream is modified.

+

Affected By:

+

+*standard-output*, *terminal-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+read-char, write-byte, write-sequence

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_pr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_pr.htm new file mode 100644 index 00000000..dc82131d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_pr.htm @@ -0,0 +1,124 @@ + + + +CLHS: Function WRITE, PRIN1, PRINT, PPRINT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WRITE, PRIN1, PRINT, PPRINT, PRINC

+

Syntax:

+

+ +write object &key array base case circle escape gensym length level lines miser-width pprint-dispatch pretty radix readably right-margin stream

=> object

+

+ +prin1 object &optional output-stream => object

+ +princ object &optional output-stream => object

+ +print object &optional output-stream => object

+ +pprint object &optional output-stream => <no values>

+

+

Arguments and Values:

+

+object---an object.

+output-stream---an output stream designator. The default is standard output.

+array---a generalized boolean.

+base---a radix.

+case---a symbol of type (member :upcase :downcase :capitalize).

+circle---a generalized boolean.

+escape---a generalized boolean.

+gensym---a generalized boolean.

+length---a non-negative integer, or nil.

+level---a non-negative integer, or nil.

+lines---a non-negative integer, or nil.

+miser-width---a non-negative integer, or nil.

+pprint-dispatch---a pprint dispatch table.

+pretty---a generalized boolean.

+radix---a generalized boolean.

+readably---a generalized boolean.

+right-margin---a non-negative integer, or nil.

+stream---an output stream designator. The default is standard output.

+

Description:

+

+write, prin1, princ, print, and pprint write the printed representation of object to output-stream.

+write is the general entry point to the Lisp printer. For each explicitly supplied keyword parameter named in the next figure, the corresponding printer control variable is dynamically bound to its value while printing goes on; for each keyword parameter in the next figure that is not explicitly supplied, the value of the corresponding printer control variable is the same as it was at the time write was invoked. Once the appropriate bindings are established, the object is output by the Lisp printer.

+

+Parameter        Corresponding Dynamic Variable  
+array            *print-array*                   
+base             *print-base*                    
+case             *print-case*                    
+circle           *print-circle*                  
+escape           *print-escape*                  
+gensym           *print-gensym*                  
+length           *print-length*                  
+level            *print-level*                   
+lines            *print-lines*                   
+miser-width      *print-miser-width*             
+pprint-dispatch  *print-pprint-dispatch*         
+pretty           *print-pretty*                  
+radix            *print-radix*                   
+readably         *print-readably*                
+right-margin     *print-right-margin*            
+
+

Figure 22-7. Argument correspondences for the WRITE function.

+ prin1, princ, print, and pprint implicitly bind certain print parameters to particular values. The remaining parameter values are taken from *print-array*, *print-base*, *print-case*, *print-circle*, *print-escape*, *print-gensym*, *print-length*, *print-level*, *print-lines*, *print-miser-width*, *print-pprint-dispatch*, *print-pretty*, *print-radix*, and *print-right-margin*.

+prin1 produces output suitable for input to read. It binds *print-escape* to true.

+princ is just like prin1 except that the output has no escape characters. It binds *print-escape* to false and *print-readably* to false. The general rule is that output from princ is intended to look good to people, while output from prin1 is intended to be acceptable to read.

+print is just like prin1 except that the printed representation of object is preceded by a newline and followed by a space.

+pprint is just like print except that the trailing space is omitted and object is printed with the *print-pretty* flag non-nil to produce pretty output.

+Output-stream specifies the stream to which output is to be sent.

+

Affected By:

+

+*standard-output*, *terminal-io*, *print-escape*, *print-radix*, *print-base*, *print-circle*, *print-pretty*, *print-level*, *print-length*, *print-case*, *print-gensym*, *print-array*, *read-default-float-format*.

+

Exceptional Situations: None. +

+

See Also:

+

+readtable-case, Section 22.3.4 (FORMAT Printer Operations)

+

Notes:

+

+The functions prin1 and print do not bind *print-readably*.

+

+ (prin1 object output-stream)
+==  (write object :stream output-stream :escape t)
+
+

+ +

+ (princ object output-stream)
+==  (write object stream output-stream :escape nil :readably nil)
+
+

+

+ (print object output-stream)
+==  (progn (terpri output-stream)
+           (write object :stream output-stream
+                         :escape t)
+           (write-char #\space output-stream))
+
+

+

+ (pprint object output-stream)
+==  (write object :stream output-stream :escape t :pretty t)
+
+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_seq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_seq.htm new file mode 100644 index 00000000..3eeb6193 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_seq.htm @@ -0,0 +1,61 @@ + + + +CLHS: Function WRITE-SEQUENCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WRITE-SEQUENCE

+

Syntax:

+

+ +write-sequence sequence stream &key start end => sequence

+

+sequence---a sequence.

+stream---an output stream.

+start, end---bounding index designators of sequence. The defaults for start and end are 0 and nil, respectively.

+

Description:

+

+write-sequence writes the elements of the subsequence of sequence bounded by start and end to stream.

+

Examples:

+

+

+ (write-sequence "bookworms" *standard-output* :end 4)
+ >>  book
+ =>  "bookworms"
+
+

+

Side Effects:

+

+Modifies stream.

+

Affected By: None. +

+

Exceptional Situations:

+

+Should be prepared to signal an error of type type-error if sequence is not a proper sequence. Should signal an error of type type-error if start is not a non-negative integer. Should signal an error of type type-error if end is not a non-negative integer or nil.

+Might signal an error of type type-error if an element of the bounded sequence is not a member of the stream element type of the stream.

+

See Also:

+

+Section 3.2.1 (Compiler Terminology), read-sequence, write-string, write-line

+

Notes:

+

+write-sequence is identical in effect to iterating over the indicated subsequence and writing one element at a time to stream, but may be more efficient than the equivalent loop. An efficient implementation is more likely to exist for the case where the sequence is a vector with the same element type as the stream.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_stg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_stg.htm new file mode 100644 index 00000000..8dc7bec8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_stg.htm @@ -0,0 +1,81 @@ + + + +CLHS: Function WRITE-STRING, WRITE-LINE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WRITE-STRING, WRITE-LINE

+

Syntax:

+

+ +write-string string &optional output-stream &key start end => string

+ +write-line string &optional output-stream &key start end => string

+

+

Arguments and Values:

+

+string---a string.

+output-stream -- an output stream designator. The default is standard output.

+ start, end---bounding index designators of string. The defaults for start and end are 0 and nil, respectively.

+

Description:

+

+write-string writes the characters of the subsequence of string bounded by start and end to output-stream. write-line does the same thing, but then outputs a newline afterwards.

+

Examples:

+

+

+ (prog1 (write-string "books" nil :end 4) (write-string "worms"))
+>>  bookworms
+=>  "books"
+ (progn (write-char #\*)
+        (write-line "test12" *standard-output* :end 5) 
+        (write-line "*test2")
+        (write-char #\*)
+        nil)
+>>  *test1
+>>  *test2
+>>  *
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By:

+

+*standard-output*, *terminal-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+read-line, write-char

+

Notes:

+

+write-line and write-string return string, not the substring bounded by start and end.

+

+ (write-string string)
+==  (dotimes (i (length string)
+      (write-char (char string i)))
+
+ (write-line string)
+==  (prog1 (write-string string) (terpri))
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_to_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_to_.htm new file mode 100644 index 00000000..d325c171 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_wr_to_.htm @@ -0,0 +1,96 @@ + + + +CLHS: Function WRITE-TO-STRING, PRIN1-TO-STRING... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING

+

Syntax:

+

+ +write-to-string object &key array base case circle escape gensym length level lines miser-width pprint-dispatch pretty radix readably right-margin

=> string

+

+ +prin1-to-string object => string

+

+ +princ-to-string object => string

+

+

Arguments and Values:

+

+object---an object.

+array---a generalized boolean.

+base---a radix.

+case---a symbol of type (member :upcase :downcase :capitalize).

+circle---a generalized boolean.

+escape---a generalized boolean.

+gensym---a generalized boolean.

+length---a non-negative integer, or nil.

+level---a non-negative integer, or nil.

+lines---a non-negative integer, or nil.

+miser-width---a non-negative integer, or nil.

+pprint-dispatch---a pprint dispatch table.

+pretty---a generalized boolean.

+radix---a generalized boolean.

+readably---a generalized boolean.

+right-margin---a non-negative integer, or nil.

+string---a string.

+

Description:

+

+write-to-string, prin1-to-string, and princ-to-string are used to create a string consisting of the printed representation of object. Object is effectively printed as if by write, prin1, or princ, respectively, and the characters that would be output are made into a string.

+write-to-string is the general output function. It has the ability to specify all the parameters applicable to the printing of object.

+prin1-to-string acts like write-to-string with :escape t, that is, escape characters are written where appropriate.

+princ-to-string acts like write-to-string with :escape nil :readably nil. Thus no escape characters are written.

+All other keywords that would be specified to write-to-string are default values when prin1-to-string or princ-to-string is invoked.

+The meanings and defaults for the keyword arguments to write-to-string are the same as those for write.

+

Examples:

+

+

+ (prin1-to-string "abc") =>  "\"abc\""
+ (princ-to-string "abc") =>  "abc"
+
+

+

Side Effects: None. +

+

Affected By:

+

+*print-escape*, *print-radix*, *print-base*, *print-circle*, *print-pretty*, *print-level*, *print-length*, *print-case*, *print-gensym*, *print-array*, *read-default-float-format*.

+

Exceptional Situations: None. +

See Also:

+

+write

+

Notes:

+

+

+ (write-to-string object {key argument}*)
+==  (with-output-to-string (#1=#:string-stream) 
+     (write object :stream #1# {key argument}*))
+
+ (princ-to-string object)
+==  (with-output-to-string (string-stream)
+     (princ object string-stream))
+
+ (prin1-to-string object)
+==  (with-output-to-string (string-stream)
+     (prin1 object string-stream))
+
+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_y_or_n.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_y_or_n.htm new file mode 100644 index 00000000..398a35e3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_y_or_n.htm @@ -0,0 +1,75 @@ + + + +CLHS: Function Y-OR-N-P, YES-OR-NO-P + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function Y-OR-N-P, YES-OR-NO-P

+

Syntax:

+

+ +y-or-n-p &optional control &rest arguments => generalized-boolean

+ +yes-or-no-p &optional control &rest arguments => generalized-boolean

+

+

Arguments and Values:

+

+ control---a format control.

+arguments---format arguments for control.

+generalized-boolean---a generalized boolean.

+

Description:

+

+These functions ask a question and parse a response from the user. They return true if the answer is affirmative, or false if the answer is negative.

+y-or-n-p is for asking the user a question whose answer is either ``yes'' or ``no.'' It is intended that the reply require the user to answer a yes-or-no question with a single character. yes-or-no-p is also for asking the user a question whose answer is either ``Yes'' or ``No.'' It is intended that the reply require the user to take more action than just a single keystroke, such as typing the full word yes or no followed by a newline.

+y-or-n-p types out a message (if supplied), reads an answer in some implementation-dependent manner (intended to be short and simple, such as reading a single character such as Y or N). yes-or-no-p types out a message (if supplied), attracts the user's attention (for example, by ringing the terminal's bell), and reads an answer in some implementation-dependent manner (intended to be multiple characters, such as YES or NO).

+If format-control is supplied and not nil, then a fresh-line operation is performed; then a message is printed as if format-control and arguments were given to format. In any case, yes-or-no-p and y-or-n-p will provide a prompt such as ``(Y or N)'' or ``(Yes or No)'' if appropriate.

+All input and output are performed using query I/O.

+

Examples:

+ +

+ (y-or-n-p "(t or nil) given by")
+>>  (t or nil) given by (Y or N) Y
+=>  true
+ (yes-or-no-p "a ~S message" 'frightening) 
+>>  a FRIGHTENING message (Yes or No) no
+=>  false
+ (y-or-n-p "Produce listing file?") 
+>>  Produce listing file?
+>>  Please respond with Y or N. n
+=>  false
+
+

+

Side Effects:

+

+Output to and input from query I/O will occur.

+

Affected By:

+

+*query-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+format

+

Notes:

+

+yes-or-no-p and yes-or-no-p do not add question marks to the end of the prompt string, so any desired question mark or other punctuation should be explicitly included in the text query.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_zerop.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_zerop.htm new file mode 100644 index 00000000..affcaee8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/f_zerop.htm @@ -0,0 +1,68 @@ + + + +CLHS: Function ZEROP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Function ZEROP

+

Syntax:

+

+ +zerop number => generalized-boolean

+

+

Pronunciation:

+

+['zee(,)roh(,)pee]

+

Arguments and Values:

+

+number---a number.

+generalized-boolean---a generalized boolean.

+

Description:

+

+Returns true if number is zero (integer, float, or complex); otherwise, returns false.

+Regardless of whether an implementation provides distinct representations for positive and negative floating-point zeros, (zerop -0.0) always returns true.

+

Examples:

+

+

+ (zerop 0) =>  true
+ (zerop 1) =>  false
+ (zerop -0.0) =>  true
+ (zerop 0/100) =>  true
+ (zerop #c(0 0.0)) =>  true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Should signal an error of type type-error if number is not a number.

+

See Also: None. +

+

Notes:

+

+

+ (zerop number) ==  (= number 0)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/h_glossa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/h_glossa.htm new file mode 100644 index 00000000..991980fc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/h_glossa.htm @@ -0,0 +1,63 @@ + + + +CLHS: About Glossary Notation + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Glossary Notation

+ Each entry in this glossary has the following parts:

+

    +

  • the term being defined, set in boldface.

    +

  • optional pronunciation, enclosed in square brackets and set in boldface, as in the following example: ['a,list]. The pronunciation key follows Webster's Third New International Dictionary the English Language, Unabridged, except that ``uh'' is used to notate the schwa (upside-down ``e'') character, ``ee'' is used to denote a hard ``e'' (an ``e'' with an overbar), ``oh'' is used to denote a hard ``o'' (an ``o'' with an overbar), and ``ay'' is used to denote a hard ``a'' (an ``a'' with an overbar)..

    +

  • the part or parts of speech, set in italics. If a term can be used as several parts of speech, there is a separate definition for each part of speech.

    +

  • one or more definitions, organized as follows:

    +

      +

    • an optional number, present if there are several definitions. Lowercase letters might also be used in cases where subdefinitions of a numbered definition are necessary.

      +

    • an optional part of speech, set in italics, present if the term is one of several parts of speech.

      +

    • an optional discipline, set in italics, present if the term has a standard definition being repeated. For example, ``Math.''

      +

    • an optional context, present if this definition is meaningful only in that context. For example, ``(of a symbol)''.

      +

    • the definition.

      +

    • an optional example sentence. For example, ``This is an example of an example.''

      +

    • optional cross references.

      +

+In addition, some terms have idiomatic usage in the Common Lisp community which is not shared by other communities, or which is not technically correct. Definitions labeled ``Idiom.'' represent such idiomatic usage; these definitions are sometimes followed by an explanatory note.

+Words in this font are words with entries in the glossary. Words in example sentences do not follow this convention.

+When an ambiguity arises, the longest matching substring has precedence. For example, ``complex float'' refers to a single glossary entry for ``complex float'' rather than the combined meaning of the glossary terms ``complex'' and ``float.''

+Subscript notation, as in ``something[n]'' means that the nth definition of ``something'' is intended. This notation is used only in situations where the context might be insufficient to disambiguate.

+The following are abbreviations used in the glossary:

+ 

+Abbreviation  Meaning                                     
+adj.          adjective                                   
+adv.          adverb                                      
+ANSI          compatible with one or more ANSI standards  
+Comp.         computers                                   
+Idiom.        idiomatic                                   
+IEEE          compatible with one or more IEEE standards  
+ISO           compatible with one or more ISO standards   
+Math.         mathematics                                 
+Trad.         traditional                                 
+n.            noun                                        
+v.            verb                                        
+v.t.          transitive verb                             
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_and.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_and.htm new file mode 100644 index 00000000..640f46a0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_and.htm @@ -0,0 +1,74 @@ + + + +CLHS: Macro AND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro AND

+

Syntax:

+

+ +and form* => result*

+

+

Arguments and Values:

+

+form---a form.

+results---the values resulting from the evaluation of the last form, or the symbols nil or t.

+

Description:

+

+The macro and evaluates each form one at a time from left to right. As soon as any form evaluates to nil, and returns nil without evaluating the remaining forms. If all forms but the last evaluate to true values, and returns the results produced by evaluating the last form.

+If no forms are supplied, (and) returns t.

+and passes back multiple values from the last subform but not from subforms other than the last.

+

Examples:

+

+

+ (if (and (>= n 0)
+          (< n (length a-simple-vector))
+          (eq (elt a-simple-vector n) 'foo))
+     (princ "Foo!"))
+
+ The above expression prints Foo! if element n of a-simple-vector is the symbol foo, provided also that n is indeed a valid index for a-simple-vector. Because and guarantees left-to-right testing of its parts, elt is not called if n is out of range.

+

+ (setq temp1 1 temp2 1 temp3 1) =>  1 
+ (and (incf temp1) (incf temp2) (incf temp3)) =>  2 
+ (and (eql 2 temp1) (eql 2 temp2) (eql 2 temp3)) =>  true
+ (decf temp3) =>  1 
+ (and (decf temp1) (decf temp2) (eq temp3 'nil) (decf temp3)) =>  NIL 
+ (and (eql temp1 temp2) (eql temp2 temp3)) =>  true
+ (and) =>  T 
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+cond, every, if, or, when

+

Notes:

+

+

+ (and form) ==  (let () form)
+ (and form1 form2 ...) ==  (when form1 (and form2 ...))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_assert.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_assert.htm new file mode 100644 index 00000000..3c396cc7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_assert.htm @@ -0,0 +1,99 @@ + + + +CLHS: Macro ASSERT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro ASSERT

+

Syntax:

+

+ +assert test-form [(place*) [datum-form argument-form*]]

=> nil

+

+

Arguments and Values:

+

+test-form---a form; always evaluated.

+place---a place; evaluated if an error is signaled.

+ datum-form---a form that evaluates to a datum. Evaluated each time an error is to be signaled, or not at all if no error is to be signaled.

+argument-form---a form that evaluates to an argument. Evaluated each time an error is to be signaled, or not at all if no error is to be signaled.

+ datum, arguments---designators for a condition of default type error. (These designators are the result of evaluating datum-form and each of the argument-forms.)

+

Description:

+

+assert assures that test-form evaluates to true. If test-form evaluates to false, assert signals a correctable error (denoted by datum and arguments). Continuing from this error using the continue restart makes it possible for the user to alter the values of the places before assert evaluates test-form again. If the value of test-form is non-nil, assert returns nil.

+The places are generalized references to data upon which test-form depends, whose values can be changed by the user in attempting to correct the error. Subforms of each place are only evaluated if an error is signaled, and might be re-evaluated if the error is re-signaled (after continuing without actually fixing the problem). The order of evaluation of the places is not specified; see Section 5.1.1.1 (Evaluation of Subforms to Places). If a place form is supplied that produces more values than there are store variables, the extra values are ignored. If the supplied form produces fewer values than there are store variables, the missing values are set to nil.

+

Examples:

+ +

+ (setq x (make-array '(3 5) :initial-element 3))
+=>  #2A((3 3 3 3 3) (3 3 3 3 3) (3 3 3 3 3))
+ (setq y (make-array '(3 5) :initial-element 7))
+=>  #2A((7 7 7 7 7) (7 7 7 7 7) (7 7 7 7 7))
+ (defun matrix-multiply (a b)
+   (let ((*print-array* nil))
+     (assert (and (= (array-rank a) (array-rank b) 2)
+                  (= (array-dimension a 1) (array-dimension b 0)))
+             (a b)
+             "Cannot multiply ~S by ~S." a b)
+            (really-matrix-multiply a b))) =>  MATRIX-MULTIPLY
+ (matrix-multiply x y)
+>>  Correctable error in MATRIX-MULTIPLY: 
+>>  Cannot multiply #<ARRAY ...> by #<ARRAY ...>.
+>>  Restart options:
+>>   1: You will be prompted for one or more new values.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Value for A: x
+>>  Value for B: (make-array '(5 3) :initial-element 6)
+=>  #2A((54 54 54 54 54)
+       (54 54 54 54 54)
+       (54 54 54 54 54)
+       (54 54 54 54 54)
+       (54 54 54 54 54))
+
+

+

+ (defun double-safely (x) (assert (numberp x) (x)) (+ x x))
+ (double-safely 4) 
+=>  8
+ 
+ (double-safely t)
+>>  Correctable error in DOUBLE-SAFELY: The value of (NUMBERP X) must be non-NIL.
+>>  Restart options:
+>>   1: You will be prompted for one or more new values.
+>>   2: Top level.
+>>  Debug> :continue 1
+>>  Value for X: 7
+=>  14
+
+

+

Affected By:

+

+*break-on-signals*

+The set of active condition handlers.

+

Exceptional Situations: None. +

+

See Also:

+

+check-type, error, Section 5.1 (Generalized Reference)

+

Notes:

+

+The debugger need not include the test-form in the error message, and the places should not be included in the message, but they should be made available for the user's perusal. If the user gives the ``continue'' command, the values of any of the references can be altered. The details of this depend on the implementation's style of user interface.

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_call_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_call_m.htm new file mode 100644 index 00000000..75084c86 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_call_m.htm @@ -0,0 +1,61 @@ + + + +CLHS: Local Macro CALL-METHOD, MAKE-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Local Macro CALL-METHOD, MAKE-METHOD

+

Syntax:

+

+ +call-method method &optional next-method-list => result*

+ +make-method form => method-object

+

+

Arguments and Values:

+

+method---a method object, or a list (see below); not evaluated.

+method-object---a method object.

+next-method-list---a list of method objects; not evaluated.

+results---the values returned by the method invocation.

+

Description:

+

+The macro call-method is used in method combination. It hides the implementation-dependent details of how methods are called. The macro call-method has lexical scope and can only be used within an effective method form.

+ Whether or not call-method is fbound in the global environment is implementation-dependent; however, the restrictions on redefinition and shadowing of call-method are the same as for symbols in the COMMON-LISP package which are fbound in the global environment. The consequences of attempting to use call-method outside of an effective method form are undefined.

+ The macro call-method invokes the specified method, supplying it with arguments and with definitions for call-next-method and for next-method-p. If the invocation of call-method is lexically inside of a make-method, the arguments are those that were supplied to that method. Otherwise the arguments are those that were supplied to the generic function. The definitions of call-next-method and next-method-p rely on the specified next-method-list.

+If method is a list, the first element of the list must be the symbol make-method and the second element must be a form. Such a list specifies a method object whose method function has a body that is the given form.

+Next-method-list can contain method objects or lists, the first element of which must be the symbol make-method and the second element of which must be a form.

+ Those are the only two places where make-method can be used. The form used with make-method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the COMMON-LISP-USER package.

+The call-next-method function available to method will call the first method in next-method-list. The call-next-method function available in that method, in turn, will call the second method in next-method-list, and so on, until the list of next methods is exhausted.

+ If next-method-list is not supplied, the call-next-method function available to method signals an error of type control-error and the next-method-p function available to method returns nil.

+

Examples:

+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+call-next-method, define-method-combination, next-method-p

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_case_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_case_.htm new file mode 100644 index 00000000..de02c7f2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_case_.htm @@ -0,0 +1,129 @@ + + + +CLHS: Macro CASE, CCASE, ECASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro CASE, CCASE, ECASE

+

Syntax:

+

+ +case keyform {normal-clause}* [otherwise-clause] => result*

+ +ccase keyplace {normal-clause}* => result*

+ +ecase keyform {normal-clause}* => result*

+

+

+normal-clause::= (keys form*) 
+
+ 
+otherwise-clause::= ({otherwise | t} form*) 
+
+ 
+clause::= normal-clause | otherwise-clause 
+
+

+

Arguments and Values:

+

+keyform---a form; evaluated to produce a test-key.

+keyplace---a form; evaluated initially to produce a test-key. Possibly also used later as a place if no keys match.

+test-key---an object produced by evaluating keyform or keyplace.

+keys---a designator for a list of objects. In the case of case, the symbols t and otherwise may not be used as the keys designator. To refer to these symbols by themselves as keys, the designators (t) and (otherwise), respectively, must be used instead.

+forms---an implicit progn.

+results---the values returned by the forms in the matching clause.

+

Description:

+

+These macros allow the conditional execution of a body of forms in a clause that is selected by matching the test-key on the basis of its identity.

+The keyform or keyplace is evaluated to produce the test-key.

+Each of the normal-clauses is then considered in turn. If the test-key is the same as any key for that clause, the forms in that clause are evaluated as an implicit progn, and the values it returns are returned as the value of the case, ccase, or ecase form.

+These macros differ only in their behavior when no normal-clause matches; specifically:

+

+

case

+If no normal-clause matches, and there is an otherwise-clause, then that otherwise-clause automatically matches; the forms in that clause are evaluated as an implicit progn, and the values it returns are returned as the value of the case.

+If there is no otherwise-clause, case returns nil.

+

ccase

+If no normal-clause matches, a correctable error of type type-error is signaled. The offending datum is the test-key and the expected type is type equivalent to (member key1 key2 ...). The store-value restart can be used to correct the error.

+If the store-value restart is invoked, its argument becomes the new test-key, and is stored in keyplace as if by (setf keyplace test-key). Then ccase starts over, considering each clause anew.

+ The subforms of keyplace might be evaluated again if none of the cases holds.

+

ecase

+If no normal-clause matches, a non-correctable error of type type-error is signaled. The offending datum is the test-key and the expected type is type equivalent to (member key1 key2 ...).

+Note that in contrast with ccase, the caller of ecase may rely on the fact that ecase does not return if a normal-clause does not match.

+

+

Examples:

+

+

+ (dolist (k '(1 2 3 :four #\v () t 'other))
+    (format t "~S "
+       (case k ((1 2) 'clause1)
+               (3 'clause2)
+               (nil 'no-keys-so-never-seen)
+               ((nil) 'nilslot)
+               ((:four #\v) 'clause4)
+               ((t) 'tslot)
+               (otherwise 'others)))) 
+>>  CLAUSE1 CLAUSE1 CLAUSE2 CLAUSE4 CLAUSE4 NILSLOT TSLOT OTHERS 
+=>  NIL
+ (defun add-em (x) (apply #'+ (mapcar #'decode x)))
+=>  ADD-EM
+ (defun decode (x)
+   (ccase x
+     ((i uno) 1)
+     ((ii dos) 2)
+     ((iii tres) 3)
+     ((iv cuatro) 4)))
+=>  DECODE
+ (add-em '(uno iii)) =>  4
+ (add-em '(uno iiii))
+>>  Error: The value of X, IIII, is not I, UNO, II, DOS, III,
+>>         TRES, IV, or CUATRO.
+>>   1: Supply a value to use instead.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> :CONTINUE 1
+>>  Value to evaluate and use for X: 'IV
+=>  5
+
+

+

Side Effects:

+

+The debugger might be entered. If the store-value restart is invoked, the value of keyplace might be changed.

+

Affected By:

+

+ccase and ecase, since they might signal an error, are potentially affected by existing handlers and *debug-io*.

+

Exceptional Situations:

+

+ccase and ecase signal an error of type type-error if no normal-clause matches.

+

See Also:

+

+cond, typecase, setf, Section 5.1 (Generalized Reference)

+

Notes:

+

+

+(case test-key
+  {((key*) form*)}*)
+== 
+(let ((#1=#:g0001 test-key))
+  (cond {((member #1# '(key*)) form*)}*))
+
+

+The specific error message used by ecase and ccase can vary between implementations. In situations where control of the specific wording of the error message is important, it is better to use case with an otherwise-clause that explicitly signals an error with an appropriate message.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_check_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_check_.htm new file mode 100644 index 00000000..e77e01a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_check_.htm @@ -0,0 +1,121 @@ + + + +CLHS: Macro CHECK-TYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro CHECK-TYPE

+

Syntax:

+

+ +check-type place typespec [string] => nil

+

+

Arguments and Values:

+

+place---a place.

+typespec---a type specifier.

+string---a string; evaluated.

Description:

+

+check-type signals a correctable error of type type-error if the contents of place are not of the type typespec.

+check-type can return only if the store-value restart is invoked, either explicitly from a handler or implicitly as one of the options offered by the debugger. If the store-value restart is invoked, check-type stores the new value that is the argument to the restart invocation (or that is prompted for interactively by the debugger) in place and starts over, checking the type of the new value and signaling another error if it is still not of the desired type.

+The first time place is evaluated, it is evaluated by normal evaluation rules. It is later evaluated as a place if the type check fails and the store-value restart is used; see Section 5.1.1.1 (Evaluation of Subforms to Places).

+string should be an English description of the type, starting with an indefinite article (``a'' or ``an''). If string is not supplied, it is computed automatically from typespec. The automatically generated message mentions place, its contents, and the desired type. An implementation may choose to generate a somewhat differently worded error message if it recognizes that place is of a particular form, such as one of the arguments to the function that called check-type. string is allowed because some applications of check-type may require a more specific description of what is wanted than can be generated automatically from typespec.

+

Examples:

+

+

+ (setq aardvarks '(sam harry fred))
+=>  (SAM HARRY FRED)
+ (check-type aardvarks (array * (3)))
+>>  Error: The value of AARDVARKS, (SAM HARRY FRED),
+>>         is not a 3-long array.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use instead.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> :CONTINUE 1
+>>  Use Value: #(SAM FRED HARRY)
+=>  NIL
+ aardvarks
+=>  #<ARRAY-T-3 13571>
+ (map 'list #'identity aardvarks)
+=>  (SAM FRED HARRY)
+ (setq aardvark-count 'foo)
+=>  FOO
+ (check-type aardvark-count (integer 0 *) "A positive integer")
+>>  Error: The value of AARDVARK-COUNT, FOO, is not a positive integer.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use instead.
+>>   2: Top level.
+>>  Debug> :CONTINUE 2
+
+

+

+ (defmacro define-adder (name amount)
+   (check-type name (and symbol (not null)) "a name for an adder function")
+   (check-type amount integer)
+   `(defun ,name (x) (+ x ,amount)))
+  
+ (macroexpand '(define-adder add3 3))
+=>  (defun add3 (x) (+ x 3))
+ 
+ (macroexpand '(define-adder 7 7))
+>>  Error: The value of NAME, 7, is not a name for an adder function.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use instead.
+>>   2: Top level.
+>>  Debug> :Continue 1
+>>  Specify a value to use instead.
+>>  Type a form to be evaluated and used instead: 'ADD7
+=>  (defun add7 (x) (+ x 7))
+ 
+ (macroexpand '(define-adder add5 something))
+>>  Error: The value of AMOUNT, SOMETHING, is not an integer.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use instead.
+>>   2: Top level.
+>>  Debug> :Continue 1
+>>  Type a form to be evaluated and used instead: 5
+=>  (defun add5 (x) (+ x 5))
+ 
+
+

+Control is transferred to a handler.

+

Side Effects:

+

+The debugger might be entered.

+

Affected By:

+

+*break-on-signals*

+The implementation.

+

Exceptional Situations: None. +

+

See Also:

+

+Section 9.1 (Condition System Concepts)

+

Notes:

+

+

+ (check-type place typespec)
+ ==  (assert (typep place 'typespec) (place)
+            'type-error :datum place :expected-type 'typespec)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_cond.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_cond.htm new file mode 100644 index 00000000..97acfe5a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_cond.htm @@ -0,0 +1,76 @@ + + + +CLHS: Macro COND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro COND

+

Syntax:

+

+ +cond {clause}* => result*

+

+

+clause::= (test-form form*) 
+
+

+

Arguments and Values:

+

+test-form---a form.

+forms---an implicit progn.

+results---the values of the forms in the first clause whose test-form yields true, or the primary value of the test-form if there are no forms in that clause, or else nil if no test-form yields true.

+

Description:

+

+cond allows the execution of forms to be dependent on test-form.

+Test-forms are evaluated one at a time in the order in which they are given in the argument list until a test-form is found that evaluates to true.

+If there are no forms in that clause, the primary value of the test-form is returned by the cond form. Otherwise, the forms associated with this test-form are evaluated in order, left to right, as an implicit progn, and the values returned by the last form are returned by the cond form.

+Once one test-form has yielded true, no additional test-forms are evaluated. If no test-form yields true, nil is returned.

+

Examples:

+

+

+ (defun select-options ()
+   (cond ((= a 1) (setq a 2))
+         ((= a 2) (setq a 3))
+         ((and (= a 3) (floor a 2)))
+         (t (floor a 3)))) =>  SELECT-OPTIONS
+ (setq a 1) =>  1
+ (select-options) =>  2
+ a =>  2
+ (select-options) =>  3
+ a =>  3
+ (select-options) =>  1
+ (setq a 5) =>  5
+ (select-options) =>  1, 2
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+if, case.

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_declai.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_declai.htm new file mode 100644 index 00000000..ee0ae714 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_declai.htm @@ -0,0 +1,54 @@ + + + +CLHS: Macro DECLAIM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DECLAIM

+

+

Syntax:

+

+ +declaim declaration-specifier* => implementation-dependent

+

+

Arguments and Values:

+

+declaration-specifier---a declaration specifier; not evaluated.

+

Description:

+

+Establishes the declarations specified by the declaration-specifiers.

+If a use of this macro appears as a top level form in a file being processed by the file compiler, the proclamations are also made at compile-time. As with other defining macros, it is unspecified whether or not the compile-time side-effects of a declaim persist after the file has been compiled.

+

Examples:

+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+declare, proclaim

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcla.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcla.htm new file mode 100644 index 00000000..b7eb1416 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcla.htm @@ -0,0 +1,116 @@ + + + +CLHS: Macro DEFCLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFCLASS

+

Syntax:

+

+ +defclass class-name ({superclass-name}*) ({slot-specifier}*) [[class-option]]

=> new-class

+

+

+slot-specifier::= slot-name | (slot-name [[slot-option]])
+slot-name::= symbol
+slot-option::= {:reader reader-function-name}* | 
+               {:writer writer-function-name}* | 
+               {:accessor reader-function-name}* | 
+               {:allocation allocation-type} | 
+               {:initarg initarg-name}* | 
+               {:initform form} | 
+               {:type type-specifier} | 
+               {:documentation string} 
+function-name::= {symbol | (setf symbol)}
+class-option::= (:default-initargs . initarg-list) | 
+                (:documentation string) | 
+                (:metaclass class-name) 
+
+

+

Arguments and Values:

+

+Class-name---a non-nil symbol.

+Superclass-name--a non-nil symbol.

+Slot-name--a symbol. The slot-name argument is a symbol that is syntactically valid for use as a variable name.

+Reader-function-name---a non-nil symbol. :reader can be supplied more than once for a given slot.

+Writer-function-name---a generic function name. :writer can be supplied more than once for a given slot.

+Reader-function-name---a non-nil symbol. :accessor can be supplied more than once for a given slot.

+Allocation-type---(member :instance :class). :allocation can be supplied once at most for a given slot.

+Initarg-name---a symbol. :initarg can be supplied more than once for a given slot.

+Form---a form. :init-form can be supplied once at most for a given slot.

+Type-specifier---a type specifier. :type can be supplied once at most for a given slot.

+Class-option--- refers to the class as a whole or to all class slots.

+Initarg-list---a list of alternating initialization argument names and default initial value forms. :default-initargs can be supplied at most once.

+Class-name---a non-nil symbol. :metaclass can be supplied once at most.

+ new-class---the new class object.

+

Description:

+

+The macro defclass defines a new named class. It returns the new class object as its result.

+The syntax of defclass provides options for specifying initialization arguments for slots, for specifying default initialization values for slots, and for requesting that methods on specified generic functions be automatically generated for reading and writing the values of slots. No reader or writer functions are defined by default; their generation must be explicitly requested. However, slots can always be accessed using slot-value.

+Defining a new class also causes a type of the same name to be defined. The predicate (typep object class-name) returns true if the class of the given object is the class named by class-name itself or a subclass of the class class-name. A class object can be used as a type specifier. Thus (typep object class) returns true if the class of the object is class itself or a subclass of class.

+The class-name argument specifies the proper name of the new class. If a class with the same proper name already exists and that class is an instance of standard-class, and if the defclass form for the definition of the new class specifies a class of class standard-class, the existing class is redefined, and instances of it (and its subclasses) are updated to the new definition at the time that they are next accessed. For details, see Section 4.3.6 (Redefining Classes).

+ Each superclass-name argument specifies a direct superclass of the new class. If the superclass list is empty, then the superclass defaults depending on the metaclass, with standard-object being the default for standard-class.

+The new class will inherit slots and methods from each of its direct superclasses, from their direct superclasses, and so on. For a discussion of how slots and methods are inherited, see Section 4.3.4 (Inheritance).

+ The following slot options are available:

+

    +

  • The :reader slot option specifies that an unqualified method is to be defined on the generic function named reader-function-name to read the value of the given slot.

    +

  • The :writer slot option specifies that an unqualified method is to be defined on the generic function named writer-function-name to write the value of the slot.

    +

  • The :accessor slot option specifies that an unqualified method is to be defined on the generic function named reader-function-name to read the value of the given slot and that an unqualified method is to be defined on the generic function named (setf reader-function-name) to be used with setf to modify the value of the slot.

    +

  • The :allocation slot option is used to specify where storage is to be allocated for the given slot. Storage for a slot can be located in each instance or in the class object itself. The value of the allocation-type argument can be either the keyword :instance or the keyword :class. If the :allocation slot option is not specified, the effect is the same as specifying :allocation :instance.

    • If allocation-type is :instance, a local slot of the name slot-name is allocated in each instance of the class.

      +

    • If allocation-type is :class, a shared slot of the given name is allocated in the class object created by this defclass form. The value of the slot is shared by all instances of the class. If a class C1 defines such a shared slot, any subclass C2 of C1 will share this single slot unless the defclass form for C2 specifies a slot of the same name or there is a superclass of C2 that precedes C1 in the class precedence list of C2 and that defines a slot of the same name.

  • The :initform slot option is used to provide a default initial value form to be used in the initialization of the slot. This form is evaluated every time it is used to initialize the slot. The lexical environment in which this form is evaluated is the lexical environment in which the defclass form was evaluated. Note that the lexical environment refers both to variables and to functions. For local slots, the dynamic environment is the dynamic environment in which make-instance is called; for shared slots, the dynamic environment is the dynamic environment in which the defclass form was evaluated. See Section 7.1 (Object Creation and Initialization).

    +No implementation is permitted to extend the syntax of defclass to allow (slot-name form) as an abbreviation for (slot-name :initform form).

    +

  • The :initarg slot option declares an initialization argument named initarg-name and specifies that this initialization argument initializes the given slot. If the initialization argument has a value in the call to initialize-instance, the value will be stored into the given slot, and the slot's :initform slot option, if any, is not evaluated. If none of the initialization arguments specified for a given slot has a value, the slot is initialized according to the :initform slot option, if specified.

    +

  • The :type slot option specifies that the contents of the slot will always be of the specified data type. It effectively declares the result type of the reader generic function when applied to an object of this class. The consequences of attempting to store in a slot a value that does not satisfy the type of the slot are undefined. The :type slot option is further discussed in Section 7.5.3 (Inheritance of Slots and Slot Options).

    +

  • The :documentation slot option provides a documentation string for the slot. :documentation can be supplied once at most for a given slot.

+Each class option is an option that refers to the class as a whole. The following class options are available:

+

  • The :default-initargs class option is followed by a list of alternating initialization argument names and default initial value forms. If any of these initialization arguments does not appear in the initialization argument list supplied to make-instance, the corresponding default initial value form is evaluated, and the initialization argument name and the form's value are added to the end of the initialization argument list before the instance is created; see Section 7.1 (Object Creation and Initialization). The default initial value form is evaluated each time it is used. The lexical environment in which this form is evaluated is the lexical environment in which the defclass form was evaluated. The dynamic environment is the dynamic environment in which make-instance was called. If an initialization argument name appears more than once in a :default-initargs class option, an error is signaled.

    +

  • The :documentation class option causes a documentation string to be attached with the class object, and attached with kind type to the class-name. :documentation can be supplied once at most.

    +

  • The :metaclass class option is used to specify that instances of the class being defined are to have a different metaclass than the default provided by the system (the class standard-class).

    +

+Note the following rules of defclass for standard classes:

+

+The object system can be extended to cover situations where these rules are not obeyed.

+Some slot options are inherited by a class from its superclasses, and some can be shadowed or altered by providing a local slot description. No class options except :default-initargs are inherited. For a detailed description of how slots and slot options are inherited, see Section 7.5.3 (Inheritance of Slots and Slot Options).

+The options to defclass can be extended. It is required that all implementations signal an error if they observe a class option or a slot option that is not implemented locally.

+It is valid to specify more than one reader, writer, accessor, or initialization argument for a slot. No other slot option can appear more than once in a single slot description, or an error is signaled.

+If no reader, writer, or accessor is specified for a slot, the slot can only be accessed by the function slot-value.

+ If a defclass form appears as a top level form, the compiler must make the class name be recognized as a valid type name in subsequent declarations (as for deftype) and be recognized as a valid class name for defmethod parameter specializers and for use as the :metaclass option of a subsequent defclass. The compiler must make the class definition available to be returned by find-class when its environment argument is a value received as the environment parameter of a macro.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+If there are any duplicate slot names, an error of type program-error is signaled.

+If an initialization argument name appears more than once in :default-initargs class option, an error of type program-error is signaled.

+If any of the following slot options appears more than once in a single slot description, an error of type program-error is signaled: :allocation, :initform, :type, :documentation.

+It is required that all implementations signal an error of type program-error if they observe a class option or a slot option that is not implemented locally.

+

See Also:

+

+documentation, initialize-instance, make-instance, slot-value, Section 4.3 (Classes), Section 4.3.4 (Inheritance), Section 4.3.6 (Redefining Classes), Section 4.3.5 (Determining the Class Precedence List), Section 7.1 (Object Creation and Initialization)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcon.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcon.htm new file mode 100644 index 00000000..feb14f22 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defcon.htm @@ -0,0 +1,71 @@ + + + +CLHS: Macro DEFCONSTANT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFCONSTANT

+

Syntax:

+

+ +defconstant name initial-value [documentation] => name

+

+

Arguments and Values:

+

+name---a symbol; not evaluated.

+initial-value---a form; evaluated.

+ documentation---a string; not evaluated.

+

Description:

+

+defconstant causes the global variable named by name to be given a value that is the result of evaluating initial-value.

+A constant defined by defconstant can be redefined with defconstant. However, the consequences are undefined if an attempt is made to assign a value to the symbol using another operator, or to assign it to a different value using a subsequent defconstant.

+If documentation is supplied, it is attached to name as a documentation string of kind variable.

+ defconstant normally appears as a top level form, but it is meaningful for it to appear as a non-top-level form. However, the compile-time side effects described below only take place when defconstant appears as a top level form.

+The consequences are undefined if there are any bindings of the variable named by name at the time defconstant is executed or if the value is not eql to the value of initial-value.

+ The consequences are undefined when constant symbols are rebound as either lexical or dynamic variables. In other words, a reference to a symbol declared with defconstant always refers to its global value.

+The side effects of the execution of defconstant must be equivalent to at least the side effects of the execution of the following code:

+

+ (setf (symbol-value 'name) initial-value)
+ (setf (documentation 'name 'variable) 'documentation)
+
+

+ If a defconstant form appears as a top level form, the compiler must recognize that name names a constant variable. An implementation may choose to evaluate the value-form at compile time, load time, or both. Therefore, users must ensure that the initial-value can be evaluated at compile time (regardless of whether or not references to name appear in the file) and that it always evaluates to the same value.

+

+

Examples:

+ +

+ (defconstant this-is-a-constant 'never-changing "for a test") =>  THIS-IS-A-CONSTANT
+this-is-a-constant =>  NEVER-CHANGING
+ (documentation 'this-is-a-constant 'variable) =>  "for a test"
+ (constantp 'this-is-a-constant) =>  true
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+declaim, defparameter, defvar, documentation, proclaim, Section 3.1.2.1.1.3 (Constant Variables), Section 3.2 (Compilation)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defgen.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defgen.htm new file mode 100644 index 00000000..83e93648 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defgen.htm @@ -0,0 +1,101 @@ + + + +CLHS: Macro DEFGENERIC + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFGENERIC

+

+

Syntax:

+

+ +defgeneric function-name gf-lambda-list [[option | {method-description}*]]

=> new-generic

+

+

+option::= (:argument-precedence-order parameter-name+) | 
+          (declare gf-declaration+) | 
+          (:documentation gf-documentation) | 
+          (:method-combination method-combination method-combination-argument*) | 
+          (:generic-function-class generic-function-class) | 
+          (:method-class method-class) 
+
+ 
+method-description::= (:method method-qualifier* specialized-lambda-list [[declaration* | documentation]] form*) 
+
+

+

Arguments and Values:

+

+function-name---a function name.

+generic-function-class---a non-nil symbol naming a class.

+gf-declaration---an optimize declaration specifier; other declaration specifiers are not permitted.

+gf-documentation---a string; not evaluated.

+gf-lambda-list---a generic function lambda list.

+method-class---a non-nil symbol naming a class.

+method-combination-argument---an object.

+method-combination-name---a symbol naming a method combination type.

+method-qualifiers, specialized-lambda-list, declarations, documentation, forms---as per defmethod.

+new-generic---the generic function object.

+parameter-name---a symbol that names a required parameter in the lambda-list. (If the :argument-precedence-order option is specified, each required parameter in the lambda-list must be used exactly once as a parameter-name.)

+

Description:

+

+The macro defgeneric is used to define a generic function or to specify options and declarations that pertain to a generic function as a whole.

+If function-name is a list it must be of the form (setf symbol). If (fboundp function-name) is false, a new generic function is created. If (fdefinition function-name) is a generic function, that generic function is modified. If function-name names an ordinary function, a macro, or a special operator, an error is signaled.

+The effect of the defgeneric macro is as if the following three steps were performed: first, methods defined by previous defgeneric forms are removed; second, ensure-generic-function is called; and finally, methods specified by the current defgeneric form are added to the generic function.

+Each method-description defines a method on the generic function. The lambda list of each method must be congruent with the lambda list specified by the gf-lambda-list option. If no method descriptions are specified and a generic function of the same name does not already exist, a generic function with no methods is created.

+The gf-lambda-list argument of defgeneric specifies the shape of lambda lists for the methods on this generic function. All methods on the resulting generic function must have lambda lists that are congruent with this shape. If a defgeneric form is evaluated and some methods for that generic function have lambda lists that are not congruent with that given in the defgeneric form, an error is signaled. For further details on method congruence, see Section 7.6.4 (Congruent Lambda-lists for all Methods of a Generic Function).

+The generic function passes to the method all the argument values passed to it, and only those; default values are not supported. Note that optional and keyword arguments in method definitions, however, can have default initial value forms and can use supplied-p parameters.

+The following options are provided. Except as otherwise noted, a given option may occur only once.

+

    +

  • The :argument-precedence-order option is used to specify the order in which the required arguments in a call to the generic function are tested for specificity when selecting a particular method. Each required argument, as specified in the gf-lambda-list argument, must be included exactly once as a parameter-name so that the full and unambiguous precedence order is supplied. If this condition is not met, an error is signaled.

    +

  • The declare option is used to specify declarations that pertain to the generic function.

    +An optimize declaration specifier is allowed. It specifies whether method selection should be optimized for speed or space, but it has no effect on methods. To control how a method is optimized, an optimize declaration must be placed directly in the defmethod form or method description. The optimization qualities speed and space are the only qualities this standard requires, but an implementation can extend the object system to recognize other qualities. A simple implementation that has only one method selection technique and ignores optimize declaration specifiers is valid.

    +The special, ftype, function, inline, notinline, and declaration declarations are not permitted. Individual implementations can extend the declare option to support additional declarations. If an implementation notices a declaration specifier that it does not support and that has not been proclaimed as a non-standard declaration identifier name in a declaration proclamation, it should issue a warning.

    + The declare option may be specified more than once. The effect is the same as if the lists of declaration specifiers had been appended together into a single list and specified as a single declare option.

    +

  • The :documentation argument is a documentation string to be attached to the generic function object, and to be attached with kind function to the function-name.

    +

  • The :generic-function-class option may be used to specify that the generic function is to have a different class than the default provided by the system (the class standard-generic-function). The class-name argument is the name of a class that can be the class of a generic function. If function-name specifies an existing generic function that has a different value for the :generic-function-class argument and the new generic function class is compatible with the old, change-class is called to change the class of the generic function; otherwise an error is signaled.

    +

  • The :method-class option is used to specify that all methods on this generic function are to have a different class from the default provided by the system (the class standard-method). The class-name argument is the name of a class that is capable of being the class of a method.

    +

  • The :method-combination option is followed by a symbol that names a type of method combination. The arguments (if any) that follow that symbol depend on the type of method combination. Note that the standard method combination type does not support any arguments. However, all types of method combination defined by the short form of define-method-combination accept an optional argument named order, defaulting to :most-specific-first, where a value of :most-specific-last reverses the order of the primary methods without affecting the order of the auxiliary methods.

    +

+The method-description arguments define methods that will be associated with the generic function. The method-qualifier and specialized-lambda-list arguments in a method description are the same as for defmethod.

+The form arguments specify the method body. The body of the method is enclosed in an implicit block. If function-name is a symbol, this block bears the same name as the generic function. If function-name is a list of the form (setf symbol), the name of the block is symbol.

+Implementations can extend defgeneric to include other options. It is required that an implementation signal an error if it observes an option that is not implemented locally.

+ defgeneric is not required to perform any compile-time side effects. In particular, the methods are not installed for invocation during compilation. An implementation may choose to store information about the generic function for the purposes of compile-time error-checking (such as checking the number of arguments on calls, or noting that a definition for the function name has been seen).

+

Examples:

+

+

Affected By: None. +

+

Exceptional Situations:

+

+If function-name names an ordinary function, a macro, or a special operator, an error of type program-error is signaled.

+Each required argument, as specified in the gf-lambda-list argument, must be included exactly once as a parameter-name, or an error of type program-error is signaled.

+The lambda list of each method specified by a method-description must be congruent with the lambda list specified by the gf-lambda-list option, or an error of type error is signaled.

+If a defgeneric form is evaluated and some methods for that generic function have lambda lists that are not congruent with that given in the defgeneric form, an error of type error is signaled.

+A given option may occur only once, or an error of type program-error is signaled.

+ If function-name specifies an existing generic function that has a different value for the :generic-function-class argument and the new generic function class is compatible with the old, change-class is called to change the class of the generic function; otherwise an error of type error is signaled.

+Implementations can extend defgeneric to include other options. It is required that an implementation signal an error of type program-error if it observes an option that is not implemented locally.

+

See Also:

+

+defmethod, documentation, ensure-generic-function, generic-function, Section 7.6.4 (Congruent Lambda-lists for all Methods of a Generic Function)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_1.htm new file mode 100644 index 00000000..312a31b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_1.htm @@ -0,0 +1,73 @@ + + + +CLHS: Macro DEFINE-SYMBOL-MACRO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFINE-SYMBOL-MACRO

+

Syntax:

+

+ +define-symbol-macro symbol expansion

=> symbol

+

+

Arguments and Values:

+

+symbol---a symbol.

+expansion---a form.

+

Description:

+

+Provides a mechanism for globally affecting the macro expansion of the indicated symbol.

+Globally establishes an expansion function for the symbol macro named by symbol. The only guaranteed property of an expansion function for a symbol macro is that when it is applied to the form and the environment it returns the correct expansion. (In particular, it is implementation-dependent whether the expansion is conceptually stored in the expansion function, the environment, or both.)

+Each global reference to symbol (i.e., not shadowed[2] by a binding for a variable or symbol macro named by the same symbol) is expanded by the normal macro expansion process; see Section 3.1.2.1.1 (Symbols as Forms). The expansion of a symbol macro is subject to further macro expansion in the same lexical environment as the symbol macro reference, exactly analogous to normal macros.

+The consequences are unspecified if a special declaration is made for symbol while in the scope of this definition (i.e., when it is not shadowed[2] by a binding for a variable or symbol macro named by the same symbol).

+Any use of setq to set the value of the symbol while in the scope of this definition is treated as if it were a setf. psetq of symbol is treated as if it were a psetf, and multiple-value-setq is treated as if it were a setf of values.

+A binding for a symbol macro can be shadowed[2] by let or symbol-macrolet.

+

Examples:

+

+

+(defvar *things* (list 'alpha 'beta 'gamma)) =>  *THINGS*
+
+(define-symbol-macro thing1 (first *things*)) =>  THING1
+(define-symbol-macro thing2 (second *things*)) =>  THING2
+(define-symbol-macro thing3 (third *things*)) =>  THING3
+
+thing1 =>  ALPHA
+(setq thing1 'ONE) =>  ONE
+*things* =>  (ONE BETA GAMMA)
+(multiple-value-setq (thing2 thing3) (values 'two 'three)) =>  TWO
+thing3 =>  THREE
+*things* =>  (ONE TWO THREE)
+
+(list thing2 (let ((thing2 2)) thing2)) =>  (TWO 2)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If symbol is already defined as a global variable, an error of type program-error is signaled.

+

See Also:

+

+symbol-macrolet, macroexpand

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_2.htm new file mode 100644 index 00000000..458aa8ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_2.htm @@ -0,0 +1,80 @@ + + + +CLHS: Macro DEFINE-MODIFY-MACRO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFINE-MODIFY-MACRO

+

Syntax:

+

+ +define-modify-macro name lambda-list function [documentation] => name

+

+

Arguments and Values:

+

+name---a symbol.

+lambda-list---a define-modify-macro lambda list

+function---a symbol.

+documentation---a string; not evaluated.

+

Description:

+

+define-modify-macro defines a macro named name to read and write a place.

+The arguments to the new macro are a place, followed by the arguments that are supplied in lambda-list. Macros defined with define-modify-macro correctly pass the environment parameter to get-setf-expansion.

+When the macro is invoked, function is applied to the old contents of the place and the lambda-list arguments to obtain the new value, and the place is updated to contain the result.

+Except for the issue of avoiding multiple evaluation (see below), the expansion of a define-modify-macro is equivalent to the following:

+

+ (defmacro name (reference . lambda-list)
+   documentation
+   `(setf ,reference
+          (function ,reference ,arg1 ,arg2 ...)))
+
+

+where arg1, arg2, ..., are the parameters appearing in lambda-list; appropriate provision is made for a rest parameter.

+ The subforms of the macro calls defined by define-modify-macro are evaluated as specified in Section 5.1.1.1 (Evaluation of Subforms to Places).

+ Documentation is attached as a documentation string to name (as kind function) and to the macro function.

+ If a define-modify-macro form appears as a top level form, the compiler must store the macro definition at compile time, so that occurrences of the macro later on in the file can be expanded correctly.

+

Examples:

+ +

+ (define-modify-macro appendf (&rest args) 
+    append "Append onto list") =>  APPENDF
+ (setq x '(a b c) y x) =>  (A B C)
+ (appendf x '(d e f) '(1 2 3)) =>  (A B C D E F 1 2 3)
+ x =>  (A B C D E F 1 2 3)
+ y =>  (A B C)
+ (define-modify-macro new-incf (&optional (delta 1)) +)
+ (define-modify-macro unionf (other-set &rest keywords) union)
+
+

+

Side Effects:

+

+A macro definition is assigned to name.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+defsetf, define-setf-expander, documentation, Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_3.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_3.htm new file mode 100644 index 00000000..57a2fe32 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_3.htm @@ -0,0 +1,108 @@ + + + +CLHS: Macro DEFINE-SETF-EXPANDER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFINE-SETF-EXPANDER

+

+

Syntax:

+

+ +define-setf-expander access-fn lambda-list [[declaration* | documentation]] form*

=> access-fn

+

+

Arguments and Values:

+

+access-fn---a symbol that names a function or macro.

+lambda-list -- macro lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+forms---an implicit progn.

+

Description:

+

+define-setf-expander specifies the means by which setf updates a place that is referenced by access-fn.

+When setf is given a place that is specified in terms of access-fn and a new value for the place, it is expanded into a form that performs the appropriate update.

+The lambda-list supports destructuring. See Section 3.4.4 (Macro Lambda Lists).

+ Documentation is attached to access-fn as a documentation string of kind setf.

+Forms constitute the body of the setf expander definition and must compute the setf expansion for a call on setf that references the place by means of the given access-fn. The setf expander function is defined in the same lexical environment in which the define-setf-expander form appears. While forms are being executed, the variables in lambda-list are bound to parts of the place form. The body forms (but not the lambda-list) in a define-setf-expander form are implicitly enclosed in a block whose name is access-fn.

+The evaluation of forms must result in the five values described in Section 5.1.1.2 (Setf Expansions).

+ If a define-setf-expander form appears as a top level form, the compiler must make the setf expander available so that it may be used to expand calls to setf later on in the file. Programmers must ensure that the forms can be evaluated at compile time if the access-fn is used in a place later in the same file. The compiler must make these setf expanders available to compile-time calls to get-setf-expansion when its environment argument is a value received as the environment parameter of a macro.

+

Examples:

+ +

+ (defun lastguy (x) (car (last x))) =>  LASTGUY
+ (define-setf-expander lastguy (x &environment env)
+   "Set the last element in a list to the given value."
+   (multiple-value-bind (dummies vals newval setter getter)
+       (get-setf-expansion x env)
+     (let ((store (gensym)))
+       (values dummies
+               vals
+               `(,store)
+               `(progn (rplaca (last ,getter) ,store) ,store)
+               `(lastguy ,getter))))) =>  LASTGUY
+ (setq a (list 'a 'b 'c 'd)
+       b (list 'x)
+       c (list 1 2 3 (list 4 5 6))) =>  (1 2 3 (4 5 6))
+ (setf (lastguy a) 3) =>  3
+ (setf (lastguy b) 7) =>  7
+ (setf (lastguy (lastguy c)) 'lastguy-symbol) =>  LASTGUY-SYMBOL
+ a =>  (A B C 3)
+ b =>  (7)
+ c =>  (1 2 3 (4 5 LASTGUY-SYMBOL))
+
+

+ +

+;;; Setf expander for the form (LDB bytespec int).
+;;; Recall that the int form must itself be suitable for SETF.
+ (define-setf-expander ldb (bytespec int &environment env)
+   (multiple-value-bind (temps vals stores
+                          store-form access-form)
+       (get-setf-expansion int env);Get setf expansion for int.
+     (let ((btemp (gensym))     ;Temp var for byte specifier.
+           (store (gensym))     ;Temp var for byte to store.
+           (stemp (first stores))) ;Temp var for int to store.
+       (if (cdr stores) (error "Can't expand this."))
+;;; Return the setf expansion for LDB as five values.
+       (values (cons btemp temps)       ;Temporary variables.
+               (cons bytespec vals)     ;Value forms.
+               (list store)             ;Store variables.
+               `(let ((,stemp (dpb ,store ,btemp ,access-form)))
+                  ,store-form
+                  ,store)               ;Storing form.
+               `(ldb ,btemp ,access-form) ;Accessing form.
+              ))))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+setf, defsetf, documentation, get-setf-expansion, Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+

+define-setf-expander differs from the long form of defsetf in that while the body is being executed the variables in lambda-list are bound to parts of the place form, not to temporary variables that will be bound to the values of such parts. In addition, define-setf-expander does not have defsetf's restriction that access-fn must be a function or a function-like macro; an arbitrary defmacro destructuring pattern is permitted in lambda-list.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_4.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_4.htm new file mode 100644 index 00000000..4a6154d6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_4.htm @@ -0,0 +1,262 @@ + + + +CLHS: Macro DEFINE-METHOD-COMBINATION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFINE-METHOD-COMBINATION

+

+

Syntax:

+

+ +define-method-combination name [[short-form-option]]

=> name

+

+ +define-method-combination name lambda-list (method-group-specifier*) [(:arguments . args-lambda-list)] [(:generic-function generic-function-symbol)] [[declaration* | documentation]] form*

=> name

+

+

+short-form-option::= :documentation documentation |  
+                     :identity-with-one-argument identity-with-one-argument | 
+                     :operator operator 
+
+ 
+method-group-specifier::= (name {qualifier-pattern+ | predicate} [[long-form-option]]) 
+
+ 
+long-form-option::= :description description | 
+                    :order order | 
+                    :required required-p 
+
+

+

Arguments and Values:

+

+args-lambda-list---a define-method-combination arguments lambda list.

+declaration---a declare expression; not evaluated.

+description---a format control.

+documentation---a string; not evaluated.

+forms---an implicit progn that must compute and return the form that specifies how the methods are combined, that is, the effective method.

+generic-function-symbol---a symbol.

+identity-with-one-argument---a generalized boolean.

+lambda-list---ordinary lambda list.

+name---a symbol. Non-keyword, non-nil symbols are usually used.

+operator---an operator. Name and operator are often the same symbol. This is the default, but it is not required.

+order---:most-specific-first or :most-specific-last; evaluated.

+predicate---a symbol that names a function of one argument that returns a generalized boolean.

+qualifier-pattern---a list, or the symbol *.

+required-p---a generalized boolean.

+

Description:

+

+The macro define-method-combination is used to define new types of method combination.

+There are two forms of define-method-combination. The short form is a simple facility for the cases that are expected to be most commonly needed. The long form is more powerful but more verbose. It resembles defmacro in that the body is an expression, usually using backquote, that computes a form. Thus arbitrary control structures can be implemented. The long form also allows arbitrary processing of method qualifiers.

+

Short Form

+The short form syntax of define-method-combination is recognized when the second subform is a non-nil symbol or is not present. When the short form is used, name is defined as a type of method combination that produces a Lisp form (operator method-call method-call ...). The operator is a symbol that can be the name of a function, macro, or special operator. The operator can be supplied by a keyword option; it defaults to name.

+Keyword options for the short form are the following:

+

    +

  • The :documentation option is used to document the method-combination type; see description of long form below.

    +

  • The :identity-with-one-argument option enables an optimization when its value is true (the default is false). If there is exactly one applicable method and it is a primary method, that method serves as the effective method and operator is not called. This optimization avoids the need to create a new effective method and avoids the overhead of a function call. This option is designed to be used with operators such as progn, and, +, and max.

    +

  • The :operator option specifies the name of the operator. The operator argument is a symbol that can be the name of a function, macro, or special form.

    +

+ These types of method combination require exactly one qualifier per method. An error is signaled if there are applicable methods with no qualifiers or with qualifiers that are not supported by the method combination type.

+A method combination procedure defined in this way recognizes two roles for methods. A method whose one qualifier is the symbol naming this type of method combination is defined to be a primary method. At least one primary method must be applicable or an error is signaled. A method with :around as its one qualifier is an auxiliary method that behaves the same as an around method in standard method combination. The function call-next-method can only be used in around methods; it cannot be used in primary methods defined by the short form of the define-method-combination macro.

+A method combination procedure defined in this way accepts an optional argument named order, which defaults to :most-specific-first. A value of :most-specific-last reverses the order of the primary methods without affecting the order of the auxiliary methods.

+The short form automatically includes error checking and support for around methods.

+For a discussion of built-in method combination types, see Section 7.6.6.4 (Built-in Method Combination Types).

+

Long Form

+The long form syntax of define-method-combination is recognized when the second subform is a list.

+The lambda-list receives any arguments provided after the name of the method combination type in the :method-combination option to defgeneric.

+A list of method group specifiers follows. Each specifier selects a subset of the applicable methods to play a particular role, either by matching their qualifiers against some patterns or by testing their qualifiers with a predicate. These method group specifiers define all method qualifiers that can be used with this type of method combination.

+ The car of each method-group-specifier is a symbol which names a variable. During the execution of the forms in the body of define-method-combination, this variable is bound to a list of the methods in the method group. The methods in this list occur in the order specified by the :order option.

+If qualifier-pattern is a symbol it must be *. A method matches a qualifier-pattern if the method's list of qualifiers is equal to the qualifier-pattern (except that the symbol * in a qualifier-pattern matches anything). Thus a qualifier-pattern can be one of the following: the empty list, which matches unqualified methods; the symbol *, which matches all methods; a true list, which matches methods with the same number of qualifiers as the length of the list when each qualifier matches the corresponding list element; or a dotted list that ends in the symbol * (the * matches any number of additional qualifiers).

+ Each applicable method is tested against the qualifier-patterns and predicates in left-to-right order. As soon as a qualifier-pattern matches or a predicate returns true, the method becomes a member of the corresponding method group and no further tests are made. Thus if a method could be a member of more than one method group, it joins only the first such group. If a method group has more than one qualifier-pattern, a method need only satisfy one of the qualifier-patterns to be a member of the group.

+The name of a predicate function can appear instead of qualifier-patterns in a method group specifier. The predicate is called for each method that has not been assigned to an earlier method group; it is called with one argument, the method's qualifier list. The predicate should return true if the method is to be a member of the method group. A predicate can be distinguished from a qualifier-pattern because it is a symbol other than nil or *.

+ If there is an applicable method that does not fall into any method group, the function invalid-method-error is called.

+Method group specifiers can have keyword options following the qualifier patterns or predicate. Keyword options can be distinguished from additional qualifier patterns because they are neither lists nor the symbol *. The keyword options are as follows:

+

    +

  • The :description option is used to provide a description of the role of methods in the method group. Programming environment tools use (apply #'format stream format-control (method-qualifiers method)) to print this description, which is expected to be concise. This keyword option allows the description of a method qualifier to be defined in the same module that defines the meaning of the method qualifier. In most cases, format-control will not contain any format directives, but they are available for generality. If :description is not supplied, a default description is generated based on the variable name and the qualifier patterns and on whether this method group includes the unqualified methods.

    +

  • The :order option specifies the order of methods. The order argument is a form that evaluates to :most-specific-first or :most-specific-last. If it evaluates to any other value, an error is signaled. If :order is not supplied, it defaults to :most-specific-first.

    +

  • The :required option specifies whether at least one method in this method group is required. If its value is true and the method group is empty (that is, no applicable methods match the qualifier patterns or satisfy the predicate), an error is signaled. If :required is not supplied, it defaults to nil.

    +

+The use of method group specifiers provides a convenient syntax to select methods, to divide them among the possible roles, and to perform the necessary error checking. It is possible to perform further filtering of methods in the body forms by using normal list-processing operations and the functions method-qualifiers and invalid-method-error. It is permissible to use setq on the variables named in the method group specifiers and to bind additional variables. It is also possible to bypass the method group specifier mechanism and do everything in the body forms. This is accomplished by writing a single method group with * as its only qualifier-pattern; the variable is then bound to a list of all of the applicable methods, in most-specific-first order.

+ The body forms compute and return the form that specifies how the methods are combined, that is, the effective method. The effective method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the COMMON-LISP-USER package. Given a method object in one of the lists produced by the method group specifiers and a list of next methods, call-method will invoke the method such that call-next-method has available the next methods.

+When an effective method has no effect other than to call a single method, some implementations employ an optimization that uses the single method directly as the effective method, thus avoiding the need to create a new effective method. This optimization is active when the effective method form consists entirely of an invocation of the call-method macro whose first subform is a method object and whose second subform is nil or unsupplied. Each define-method-combination body is responsible for stripping off redundant invocations of progn, and, multiple-value-prog1, and the like, if this optimization is desired.

+ The list (:arguments . lambda-list) can appear before any declarations or documentation string. This form is useful when the method combination type performs some specific behavior as part of the combined method and that behavior needs access to the arguments to the generic function. Each parameter variable defined by lambda-list is bound to a form that can be inserted into the effective method. When this form is evaluated during execution of the effective method, its value is the corresponding argument to the generic function; the consequences of using such a form as the place in a setf form are undefined. Argument correspondence is computed by dividing the :arguments lambda-list and the generic function lambda-list into three sections: the required parameters, the optional parameters, and the keyword and rest parameters. The arguments supplied to the generic function for a particular call are also divided into three sections; the required arguments section contains as many arguments as the generic function has required parameters, the optional arguments section contains as many arguments as the generic function has optional parameters, and the keyword/rest arguments section contains the remaining arguments. Each parameter in the required and optional sections of the :arguments lambda-list accesses the argument at the same position in the corresponding section of the arguments. If the section of the :arguments lambda-list is shorter, extra arguments are ignored. If the section of the :arguments lambda-list is longer, excess required parameters are bound to forms that evaluate to nil and excess optional parameters are bound to their initforms. The keyword parameters and rest parameters in the :arguments lambda-list access the keyword/rest section of the arguments. If the :arguments lambda-list contains &key, it behaves as if it also contained &allow-other-keys.

+In addition, &whole var can be placed first in the :arguments lambda-list. It causes var to be bound to a form that evaluates to a list of all of the arguments supplied to the generic function. This is different from &rest because it accesses all of the arguments, not just the keyword/rest arguments.

+

+Erroneous conditions detected by the body should be reported with method-combination-error or invalid-method-error; these functions add any necessary contextual information to the error message and will signal the appropriate error.

+The body forms are evaluated inside of the bindings created by the lambda list and method group specifiers. Declarations at the head of the body are positioned directly inside of bindings created by the lambda list and outside of the bindings of the method group variables. Thus method group variables cannot be declared in this way. locally may be used around the body, however.

+Within the body forms, generic-function-symbol is bound to the generic function object.

+ Documentation is attached as a documentation string to name (as kind method-combination) and to the method combination object.

+ Note that two methods with identical specializers, but with different qualifiers, are not ordered by the algorithm described in Step 2 of the method selection and combination process described in Section 7.6.6 (Method Selection and Combination). Normally the two methods play different roles in the effective method because they have different qualifiers, and no matter how they are ordered in the result of Step 2, the effective method is the same. If the two methods play the same role and their order matters, an error is signaled. This happens as part of the qualifier pattern matching in define-method-combination.

+

+ If a define-method-combination form appears as a top level form, the compiler must make the method combination name be recognized as a valid method combination name in subsequent defgeneric forms. However, the method combination is executed no earlier than when the define-method-combination form is executed, and possibly as late as the time that generic functions that use the method combination are executed.

+

Examples:

+

+Most examples of the long form of define-method-combination also illustrate the use of the related functions that are provided as part of the declarative method combination facility.

+

+;;; Examples of the short form of define-method-combination
+ 
+ (define-method-combination and :identity-with-one-argument t) 
+  
+ (defmethod func and ((x class1) y) ...)
+ 
+;;; The equivalent of this example in the long form is:
+ 
+ (define-method-combination and 
+         (&optional (order :most-specific-first))
+         ((around (:around))
+          (primary (and) :order order :required t))
+   (let ((form (if (rest primary)
+                   `(and ,@(mapcar #'(lambda (method)
+                                       `(call-method ,method))
+                                   primary))
+                   `(call-method ,(first primary)))))
+     (if around
+         `(call-method ,(first around)
+                       (,@(rest around)
+                        (make-method ,form)))
+         form)))
+  
+;;; Examples of the long form of define-method-combination
+ 
+;The default method-combination technique
+ (define-method-combination standard ()
+         ((around (:around))
+          (before (:before))
+          (primary () :required t)
+          (after (:after)))
+   (flet ((call-methods (methods)
+            (mapcar #'(lambda (method)
+                        `(call-method ,method))
+                    methods)))
+     (let ((form (if (or before after (rest primary))
+                     `(multiple-value-prog1
+                        (progn ,@(call-methods before)
+                               (call-method ,(first primary)
+                                            ,(rest primary)))
+                        ,@(call-methods (reverse after)))
+                     `(call-method ,(first primary)))))
+       (if around
+           `(call-method ,(first around)
+                         (,@(rest around)
+                          (make-method ,form)))
+           form))))
+  
+;A simple way to try several methods until one returns non-nil
+ (define-method-combination or ()
+         ((methods (or)))
+   `(or ,@(mapcar #'(lambda (method)
+                      `(call-method ,method))
+                  methods)))
+  
+;A more complete version of the preceding
+ (define-method-combination or 
+         (&optional (order ':most-specific-first))
+         ((around (:around))
+          (primary (or)))
+   ;; Process the order argument
+   (case order
+     (:most-specific-first)
+     (:most-specific-last (setq primary (reverse primary)))
+     (otherwise (method-combination-error "~S is an invalid order.~@
+     :most-specific-first and :most-specific-last are the possible values."
+                                          order)))
+   ;; Must have a primary method
+   (unless primary
+     (method-combination-error "A primary method is required."))
+   ;; Construct the form that calls the primary methods
+   (let ((form (if (rest primary)
+                   `(or ,@(mapcar #'(lambda (method)
+                                      `(call-method ,method))
+                                  primary))
+                   `(call-method ,(first primary)))))
+     ;; Wrap the around methods around that form
+     (if around
+         `(call-method ,(first around)
+                       (,@(rest around)
+                        (make-method ,form)))
+         form)))
+  
+;The same thing, using the :order and :required keyword options
+ (define-method-combination or 
+         (&optional (order ':most-specific-first))
+         ((around (:around))
+          (primary (or) :order order :required t))
+   (let ((form (if (rest primary)
+                   `(or ,@(mapcar #'(lambda (method)
+                                      `(call-method ,method))
+                                  primary))
+                   `(call-method ,(first primary)))))
+     (if around
+         `(call-method ,(first around)
+                       (,@(rest around)
+                        (make-method ,form)))
+         form)))
+  
+;This short-form call is behaviorally identical to the preceding
+ (define-method-combination or :identity-with-one-argument t)
+ 
+;Order methods by positive integer qualifiers
+;:around methods are disallowed to keep the example small
+ (define-method-combination example-method-combination ()
+         ((methods positive-integer-qualifier-p))
+   `(progn ,@(mapcar #'(lambda (method)
+                         `(call-method ,method))
+                     (stable-sort methods #'<
+                       :key #'(lambda (method)
+                                (first (method-qualifiers method)))))))
+ 
+ (defun positive-integer-qualifier-p (method-qualifiers)
+   (and (= (length method-qualifiers) 1)
+        (typep (first method-qualifiers) '(integer 0 *))))
+  
+;;; Example of the use of :arguments
+ (define-method-combination progn-with-lock ()
+         ((methods ()))
+   (:arguments object)
+   `(unwind-protect
+        (progn (lock (object-lock ,object))
+               ,@(mapcar #'(lambda (method)
+                             `(call-method ,method))
+                         methods))
+      (unlock (object-lock ,object))))
+  
+
+

+

Affected By: None. +

+

Side Effects:

+

+ The compiler is not required to perform any compile-time side-effects.

+

Exceptional Situations:

+

+Method combination types defined with the short form require exactly one qualifier per method. An error of type error is signaled if there are applicable methods with no qualifiers or with qualifiers that are not supported by the method combination type. At least one primary method must be applicable or an error of type error is signaled.

+If an applicable method does not fall into any method group, the system signals an error of type error indicating that the method is invalid for the kind of method combination in use.

+If the value of the :required option is true and the method group is empty (that is, no applicable methods match the qualifier patterns or satisfy the predicate), an error of type error is signaled.

+If the :order option evaluates to a value other than :most-specific-first or :most-specific-last, an error of type error is signaled.

+

See Also:

+

+call-method, call-next-method, documentation, method-qualifiers, method-combination-error, invalid-method-error, defgeneric, Section 7.6.6 (Method Selection and Combination), Section 7.6.6.4 (Built-in Method Combination Types), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+

+ The :method-combination option of defgeneric is used to specify that a generic function should use a particular method combination type. The first argument to the :method-combination option is the name of a method combination type and the remaining arguments are options for that type.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_5.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_5.htm new file mode 100644 index 00000000..34568ac6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defi_5.htm @@ -0,0 +1,212 @@ + + + +CLHS: Macro DEFINE-CONDITION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFINE-CONDITION

+

+

+

Syntax:

+

+ +define-condition name (parent-type*) ({slot-spec}*) option*

=> name

+

+

+slot-spec::= slot-name | (slot-name slot-option) 
+
+ 
+slot-option::= [[{:reader symbol}* |  
+               {:writer function-name}* |  
+               {:accessor symbol}* |  
+               {:allocation allocation-type} |  
+               {:initarg symbol}* |  
+               {:initform form} |  
+               {:type type-specifier} ]] 
+
+ 
+option::= [[(:default-initargs . initarg-list) |  
+          (:documentation string) |  
+          (:report report-name) ]] 
+
+ 
+function-name::= {symbol | (setf symbol)} 
+
+ 
+allocation-type::= :instance | :class 
+
+ 
+report-name::= string | symbol | lambda expression 
+
+

+

Arguments and Values:

+

+name---a symbol.

+parent-type---a symbol naming a condition type. If no parent-types are supplied, the parent-types default to (condition).

+default-initargs---a list of keyword/value pairs.

+

+Slot-spec -- the name of a slot or a list consisting of the slot-name followed by zero or more slot-options.

+Slot-name -- a slot name (a symbol), the list of a slot name, or the list of slot name/slot form pairs.

+Option -- Any of the following:

+

+

:reader

+:reader can be supplied more than once for a given slot and cannot be nil.

+

:writer

+:writer can be supplied more than once for a given slot and must name a generic function.

+

:accessor

+:accessor can be supplied more than once for a given slot and cannot be nil.

+

:allocation

+:allocation can be supplied once at most for a given slot. The default if :allocation is not supplied is :instance.

+

:initarg

+:initarg can be supplied more than once for a given slot.

+

:initform

+:initform can be supplied once at most for a given slot.

+

:type

+:type can be supplied once at most for a given slot.

+

:documentation

+:documentation can be supplied once at most for a given slot.

+

:report

+:report can be supplied once at most.

+

+

Description:

+

+define-condition defines a new condition type called name, which is a subtype of the type or types named by parent-type. Each parent-type argument specifies a direct supertype of the new condition. The new condition inherits slots and methods from each of its direct supertypes, and so on.

+ If a slot name/slot form pair is supplied, the slot form is a form that can be evaluated by make-condition to produce a default value when an explicit value is not provided. If no slot form is supplied, the contents of the slot is initialized in an implementation-dependent way.

+ If the type being defined and some other type from which it inherits have a slot by the same name, only one slot is allocated in the condition, but the supplied slot form overrides any slot form that might otherwise have been inherited from a parent-type. If no slot form is supplied, the inherited slot form (if any) is still visible.

+Accessors are created according to the same rules as used by defclass.

+A description of slot-options follows:

+

+

+

:reader

+The :reader slot option specifies that an unqualified method is to be defined on the generic function named by the argument to :reader to read the value of the given slot.

+

* The :initform slot option is used to provide a default initial value form to be used in the initialization of the slot. This form is evaluated every time it is used to initialize the slot. The lexical environment in which this form is evaluated is the lexical environment in which the define-condition form was evaluated. Note that the lexical environment refers both to variables and to functions. For local slots, the dynamic environment is the dynamic environment in which make-condition was called; for shared slots, the dynamic environment is the dynamic environment in which the define-condition form was evaluated.

+ No implementation is permitted to extend the syntax of define-condition to allow (slot-name form) as an abbreviation for (slot-name :initform form).

+

:initarg

+The :initarg slot option declares an initialization argument named by its symbol argument and specifies that this initialization argument initializes the given slot. If the initialization argument has a value in the call to initialize-instance, the value is stored into the given slot, and the slot's :initform slot option, if any, is not evaluated. If none of the initialization arguments specified for a given slot has a value, the slot is initialized according to the :initform slot option, if specified.

+

:type

+The :type slot option specifies that the contents of the slot is always of the specified type. It effectively declares the result type of the reader generic function when applied to an object of this condition type. The consequences of attempting to store in a slot a value that does not satisfy the type of the slot is undefined.

+

:default-initargs

+ This option is treated the same as it would be defclass.

+

:documentation

+ The :documentation slot option provides a documentation string for the slot.

+

:report

+ Condition reporting is mediated through the print-object method for the condition type in question, with *print-escape* always being nil. Specifying (:report report-name) in the definition of a condition type C is equivalent to:

+

+ (defmethod print-object ((x c) stream)
+   (if *print-escape* (call-next-method) (report-name x stream)))
+
+

+ If the value supplied by the argument to :report (report-name) is a symbol or a lambda expression, it must be acceptable to function. (function report-name) is evaluated in the current lexical environment. It should return a function of two arguments, a condition and a stream, that prints on the stream a description of the condition. This function is called whenever the condition is printed while *print-escape* is nil.

+If report-name is a string, it is a shorthand for

+

+ (lambda (condition stream)
+   (declare (ignore condition))
+   (write-string report-name stream))
+
+

+This option is processed after the new condition type has been defined, so use of the slot accessors within the :report function is permitted. If this option is not supplied, information about how to report this type of condition is inherited from the parent-type.

+

+The consequences are unspecifed if an attempt is made to read a slot that has not been explicitly initialized and that has not been given a default value.

+The consequences are unspecified if an attempt is made to assign the slots by using setf.

+ If a define-condition form appears as a top level form, the compiler must make name recognizable as a valid type name, and it must be possible to reference the condition type as the parent-type of another condition type in a subsequent define-condition form in the file being compiled.

+

Examples:

+

+The following form defines a condition of type peg/hole-mismatch which inherits from a condition type called blocks-world-error:

+

+(define-condition peg/hole-mismatch 
+                  (blocks-world-error)
+                  ((peg-shape  :initarg :peg-shape
+                               :reader peg/hole-mismatch-peg-shape)
+                   (hole-shape :initarg :hole-shape
+                               :reader peg/hole-mismatch-hole-shape))
+  (:report (lambda (condition stream)
+             (format stream "A ~A peg cannot go in a ~A hole."
+                     (peg/hole-mismatch-peg-shape  condition)
+                     (peg/hole-mismatch-hole-shape condition)))))
+
+

+The new type has slots peg-shape and hole-shape, so make-condition accepts :peg-shape and :hole-shape keywords. The readers peg/hole-mismatch-peg-shape and peg/hole-mismatch-hole-shape apply to objects of this type, as illustrated in the :report information.

+The following form defines a condition type named machine-error which inherits from error:

+

+(define-condition machine-error 
+                  (error)
+                  ((machine-name :initarg :machine-name
+                                 :reader machine-error-machine-name))
+  (:report (lambda (condition stream)
+             (format stream "There is a problem with ~A."
+                     (machine-error-machine-name condition)))))
+
+

+Building on this definition, a new error condition can be defined which is a subtype of machine-error for use when machines are not available:

+

+(define-condition machine-not-available-error (machine-error) ()
+  (:report (lambda (condition stream)
+             (format stream "The machine ~A is not available."
+                     (machine-error-machine-name condition)))))
+
+

+This defines a still more specific condition, built upon machine-not-available-error, which provides a slot initialization form for machine-name but which does not provide any new slots or report information. It just gives the machine-name slot a default initialization:

+

+(define-condition my-favorite-machine-not-available-error
+                  (machine-not-available-error)
+  ((machine-name :initform "mc.lcs.mit.edu")))
+
+

+Note that since no :report clause was given, the information inherited from machine-not-available-error is used to report this type of condition.

+

+ (define-condition ate-too-much (error) 
+     ((person :initarg :person :reader ate-too-much-person)
+      (weight :initarg :weight :reader ate-too-much-weight)
+      (kind-of-food :initarg :kind-of-food
+                    :reader :ate-too-much-kind-of-food)))
+=>  ATE-TOO-MUCH
+ (define-condition ate-too-much-ice-cream (ate-too-much)
+   ((kind-of-food :initform 'ice-cream)
+    (flavor       :initarg :flavor
+                  :reader ate-too-much-ice-cream-flavor
+                  :initform 'vanilla ))
+   (:report (lambda (condition stream)
+              (format stream "~A ate too much ~A ice-cream"
+                      (ate-too-much-person condition)
+                      (ate-too-much-ice-cream-flavor condition)))))
+=>  ATE-TOO-MUCH-ICE-CREAM
+ (make-condition 'ate-too-much-ice-cream
+                 :person 'fred
+                 :weight 300
+                 :flavor 'chocolate)
+=>  #<ATE-TOO-MUCH-ICE-CREAM 32236101>
+ (format t "~A" *)
+>>  FRED ate too much CHOCOLATE ice-cream
+=>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-condition, defclass, Section 9.1 (Condition System Concepts)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_define.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_define.htm new file mode 100644 index 00000000..2bad9738 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_define.htm @@ -0,0 +1,163 @@ + + + +CLHS: Macro DEFINE-COMPILER-MACRO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFINE-COMPILER-MACRO

+

+

Syntax:

+

+ +define-compiler-macro name lambda-list [[declaration* | documentation]] form*

=> name

+

+

Arguments and Values:

+

+name---a function name.

+lambda-list---a macro lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+form---a form.

+

Description:

+

+

+This is the normal mechanism for defining a compiler macro function. Its manner of definition is the same as for defmacro; the only differences are:

+

* The name can be a function name naming any function or macro.

+
* The expander function is installed as a compiler macro function for the name, rather than as a macro function.

+
* The &whole argument is bound to the form argument that is passed to the compiler macro function. The remaining lambda-list parameters are specified as if this form contained the function name in the car and the actual arguments in the cdr, but if the car of the actual form is the symbol funcall, then the destructuring of the arguments is actually performed using its cddr instead.

+
* Documentation is attached as a documentation string to name (as kind compiler-macro) and to the compiler macro function.

+
* Unlike an ordinary macro, a compiler macro can decline to provide an expansion merely by returning a form that is the same as the original (which can be obtained by using &whole).

+

Examples:

+

+

+ (defun square (x) (expt x 2)) =>  SQUARE
+ (define-compiler-macro square (&whole form arg)
+   (if (atom arg)
+       `(expt ,arg 2)
+       (case (car arg)
+         (square (if (= (length arg) 2)
+                     `(expt ,(nth 1 arg) 4)
+                     form))
+         (expt   (if (= (length arg) 3)
+                     (if (numberp (nth 2 arg))
+                         `(expt ,(nth 1 arg) ,(* 2 (nth 2 arg)))
+                         `(expt ,(nth 1 arg) (* 2 ,(nth 2 arg))))
+                     form))
+         (otherwise `(expt ,arg 2))))) =>  SQUARE
+ (square (square 3)) =>  81
+ (macroexpand '(square x)) =>  (SQUARE X), false
+ (funcall (compiler-macro-function 'square) '(square x) nil)
+=>  (EXPT X 2)
+ (funcall (compiler-macro-function 'square) '(square (square x)) nil)
+=>  (EXPT X 4)
+ (funcall (compiler-macro-function 'square) '(funcall #'square x) nil)
+=>  (EXPT X 2)
+
+ (defun distance-positional (x1 y1 x2 y2)
+   (sqrt (+ (expt (- x2 x1) 2) (expt (- y2 y1) 2))))
+=>  DISTANCE-POSITIONAL
+ (defun distance (&key (x1 0) (y1 0) (x2 x1) (y2 y1))
+   (distance-positional x1 y1 x2 y2))
+=>  DISTANCE
+ (define-compiler-macro distance (&whole form
+                                  &rest key-value-pairs
+                                  &key (x1 0  x1-p)
+                                       (y1 0  y1-p)
+                                       (x2 x1 x2-p)
+                                       (y2 y1 y2-p)
+                                  &allow-other-keys
+                                  &environment env)
+   (flet ((key (n) (nth (* n 2) key-value-pairs))
+          (arg (n) (nth (1+ (* n 2)) key-value-pairs))
+          (simplep (x)
+            (let ((expanded-x (macroexpand x env)))
+              (or (constantp expanded-x env)
+                  (symbolp expanded-x)))))
+     (let ((n (/ (length key-value-pairs) 2)))
+       (multiple-value-bind (x1s y1s x2s y2s others)
+           (loop for (key) on key-value-pairs by #'cddr
+                 count (eq key ':x1) into x1s
+                 count (eq key ':y1) into y1s
+                 count (eq key ':x2) into x2s
+                 count (eq key ':y1) into y2s
+                 count (not (member key '(:x1 :x2 :y1 :y2)))
+                   into others
+                 finally (return (values x1s y1s x2s y2s others)))
+         (cond ((and (= n 4)
+                     (eq (key 0) :x1)
+                     (eq (key 1) :y1)
+                     (eq (key 2) :x2)
+                     (eq (key 3) :y2))
+                `(distance-positional ,x1 ,y1 ,x2 ,y2))
+               ((and (if x1-p (and (= x1s 1) (simplep x1)) t)
+                     (if y1-p (and (= y1s 1) (simplep y1)) t)
+                     (if x2-p (and (= x2s 1) (simplep x2)) t)
+                     (if y2-p (and (= y2s 1) (simplep y2)) t)
+                     (zerop others))
+                `(distance-positional ,x1 ,y1 ,x2 ,y2))
+               ((and (< x1s 2) (< y1s 2) (< x2s 2) (< y2s 2)
+                     (zerop others))
+                (let ((temps (loop repeat n collect (gensym))))
+                  `(let ,(loop for i below n
+                               collect (list (nth i temps) (arg i)))
+                     (distance
+                       ,@(loop for i below n
+                               append (list (key i) (nth i temps)))))))
+               (t form))))))
+=>  DISTANCE
+ (dolist (form
+           '((distance :x1 (setq x 7) :x2 (decf x) :y1 (decf x) :y2 (decf x))
+             (distance :x1 (setq x 7) :y1 (decf x) :x2 (decf x) :y2 (decf x))
+             (distance :x1 (setq x 7) :y1 (incf x))
+             (distance :x1 (setq x 7) :y1 (incf x) :x1 (incf x))
+             (distance :x1 a1 :y1 b1 :x2 a2 :y2 b2)
+             (distance :x1 a1 :x2 a2 :y1 b1 :y2 b2)
+             (distance :x1 a1 :y1 b1 :z1 c1 :x2 a2 :y2 b2 :z2 c2)))
+   (print (funcall (compiler-macro-function 'distance) form nil)))
+>>  (LET ((#:G6558 (SETQ X 7))
+>>        (#:G6559 (DECF X))
+>>        (#:G6560 (DECF X))
+>>        (#:G6561 (DECF X)))
+>>    (DISTANCE :X1 #:G6558 :X2 #:G6559 :Y1 #:G6560 :Y2 #:G6561)) 
+>>  (DISTANCE-POSITIONAL (SETQ X 7) (DECF X) (DECF X) (DECF X)) 
+>>  (LET ((#:G6567 (SETQ X 7))
+>>        (#:G6568 (INCF X)))
+>>    (DISTANCE :X1 #:G6567 :Y1 #:G6568)) 
+>>  (DISTANCE :X1 (SETQ X 7) :Y1 (INCF X) :X1 (INCF X)) 
+>>  (DISTANCE-POSITIONAL A1 B1 A2 B2) 
+>>  (DISTANCE-POSITIONAL A1 B1 A2 B2) 
+>>  (DISTANCE :X1 A1 :Y1 B1 :Z1 C1 :X2 A2 :Y2 B2 :Z2 C2) 
+=>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+compiler-macro-function, defmacro, documentation, Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+

+The consequences of writing a compiler macro definition for a function in the COMMON-LISP package are undefined; it is quite possible that in some implementations such an attempt would override an equivalent or equally important definition. In general, it is recommended that a programmer only write compiler macro definitions for functions he or she personally maintains--writing a compiler macro definition for a function maintained elsewhere is normally considered a violation of traditional rules of modularity and data abstraction.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmac.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmac.htm new file mode 100644 index 00000000..46d68ae9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmac.htm @@ -0,0 +1,137 @@ + + + +CLHS: Macro DEFMACRO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFMACRO

+

+

Syntax:

+

+ +defmacro name lambda-list [[declaration* | documentation]] form*

=> name

+

+

Arguments and Values:

+

+name---a symbol. lambda-list---a macro lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+form---a form.

+

Description:

+

+Defines name as a macro by associating a macro function with that name in the global environment. The macro function is defined in the same lexical environment in which the defmacro form appears.

+ The parameter variables in lambda-list are bound to destructured portions of the macro call.

+The expansion function accepts two arguments, a form and an environment. The expansion function returns a form. The body of the expansion function is specified by forms. Forms are executed in order. The value of the last form executed is returned as the expansion of the macro. The body forms of the expansion function (but not the lambda-list) are implicitly enclosed in a block whose name is name.

+The lambda-list conforms to the requirements described in Section 3.4.4 (Macro Lambda Lists).

+ Documentation is attached as a documentation string to name (as kind function) and to the macro function.

+defmacro can be used to redefine a macro or to replace a function definition with a macro definition.

+ Recursive expansion of the form returned must terminate, including the expansion of other macros which are subforms of other forms returned.

+The consequences are undefined if the result of fully macroexpanding a form contains any circular list structure except in literal objects.

+ If a defmacro form appears as a top level form, the compiler must store the macro definition at compile time, so that occurrences of the macro later on in the file can be expanded correctly. Users must ensure that the body of the macro can be evaluated at compile time if it is referenced within the file being compiled.

+

Examples:

+

+

+ (defmacro mac1 (a b) "Mac1 multiplies and adds" 
+            `(+ ,a (* ,b 3))) =>  MAC1 
+ (mac1 4 5) =>  19 
+ (documentation 'mac1 'function) =>  "Mac1 multiplies and adds" 
+ (defmacro mac2 (&optional (a 2 b) (c 3 d) &rest x) `'(,a ,b ,c ,d ,x)) =>  MAC2 
+ (mac2 6) =>  (6 T 3 NIL NIL) 
+ (mac2 6 3 8) =>  (6 T 3 T (8)) 
+ (defmacro mac3 (&whole r a &optional (b 3) &rest x &key c (d a))
+    `'(,r ,a ,b ,c ,d ,x)) =>  MAC3 
+ (mac3 1 6 :d 8 :c 9 :d 10) =>  ((MAC3 1 6 :D 8 :C 9 :D 10) 1 6 9 8 (:D 8 :C 9 :D 10)) 
+
+

+ The stipulation that an embedded destructuring lambda list is permitted only where ordinary lambda list syntax would permit a parameter name but not a list is made to prevent ambiguity. For example, the following is not valid:

+

+ (defmacro loser (x &optional (a b &rest c) &rest z)
+   ...)
+
+ because ordinary lambda list syntax does permit a list following &optional; the list (a b &rest c) would be interpreted as describing an optional parameter named a whose default value is that of the form b, with a supplied-p parameter named &rest (not valid), and an extraneous symbol c in the list (also not valid). An almost correct way to express this is

+

+ (defmacro loser (x &optional ((a b &rest c)) &rest z)
+   ...)
+
+ The extra set of parentheses removes the ambiguity. However, the definition is now incorrect because a macro call such as (loser (car pool)) would not provide any argument form for the lambda list (a b &rest c), and so the default value against which to match the lambda list would be nil because no explicit default value was specified. The consequences of this are unspecified since the empty list, nil, does not have forms to satisfy the parameters a and b. The fully correct definition would be either

+

+ (defmacro loser (x &optional ((a b &rest c) '(nil nil)) &rest z)
+   ...)
+
+ or

+

+ (defmacro loser (x &optional ((&optional a b &rest c)) &rest z)
+   ...)
+
+ These differ slightly: the first requires that if the macro call specifies a explicitly then it must also specify b explicitly, whereas the second does not have this requirement. For example,

+

+ (loser (car pool) ((+ x 1)))
+
+ would be a valid call for the second definition but not for the first.

+

+

+ (defmacro dm1a (&whole x) `',x)
+ (macroexpand '(dm1a))  =>  (QUOTE (DM1A))
+ (macroexpand '(dm1a a)) is an error.
+ 
+ (defmacro dm1b (&whole x a &optional b) `'(,x ,a ,b))
+ (macroexpand '(dm1b))  is an error.
+ (macroexpand '(dm1b q))  =>  (QUOTE ((DM1B Q) Q NIL))
+ (macroexpand '(dm1b q r)) =>  (QUOTE ((DM1B Q R) Q R))
+ (macroexpand '(dm1b q r s)) is an error.
+
+

+

+ (defmacro dm2a (&whole form a b) `'(form ,form a ,a b ,b))
+ (macroexpand '(dm2a x y)) =>  (QUOTE (FORM (DM2A X Y) A X B Y))
+ (dm2a x y) =>  (FORM (DM2A X Y) A X B Y)
+
+ (defmacro dm2b (&whole form a (&whole b (c . d) &optional (e 5)) 
+                 &body f &environment env)
+   ``(,',form ,,a ,',b ,',(macroexpand c env) ,',d ,',e ,',f))
+ ;Note that because backquote is involved, implementations may differ
+ ;slightly in the nature (though not the functionality) of the expansion.
+ (macroexpand '(dm2b x1 (((incf x2) x3 x4)) x5 x6))
+ =>  (LIST* '(DM2B X1 (((INCF X2) X3 X4))
+                   X5 X6)
+            X1
+            '((((INCF X2) X3 X4)) (SETQ X2 (+ X2 1)) (X3 X4) 5 (X5 X6))),
+     T
+ (let ((x1 5))
+   (macrolet ((segundo (x) `(cadr ,x)))
+     (dm2b x1 (((segundo x2) x3 x4)) x5 x6)))
+ =>  ((DM2B X1 (((SEGUNDO X2) X3 X4)) X5 X6)
+      5 (((SEGUNDO X2) X3 X4)) (CADR X2) (X3 X4) 5 (X5 X6))
+
+

+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+ define-compiler-macro, destructuring-bind, documentation, macroexpand, *macroexpand-hook*, macrolet, macro-function, Section 3.1 (Evaluation), Section 3.2 (Compilation), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmet.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmet.htm new file mode 100644 index 00000000..81e867bf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defmet.htm @@ -0,0 +1,85 @@ + + + +CLHS: Macro DEFMETHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFMETHOD

+

+

Syntax:

+

+ +defmethod function-name {method-qualifier}* specialized-lambda-list [[declaration* | documentation]] form*

=> new-method

+

+

function-name::= {symbol | (setf symbol)}

method-qualifier::= non-list 

+specialized-lambda-list::= ({var | (var parameter-specializer-name)}* 
+                            [&optional {var | (var [initform [supplied-p-parameter] ])}*] 
+                            [&rest var] 
+                            [&key{var | ({var | (keywordvar)} [initform [supplied-p-parameter] ])}*
+                                 [&allow-other-keys] ] 
+                            [&aux {var | (var [initform] )}*] ) 
+parameter-specializer-name::= symbol | (eql eql-specializer-form)
+
+

+

Arguments and Values:

+

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+var---a variable name.

+eql-specializer-form---a form.

+Form---a form.

+Initform---a form.

+Supplied-p-parameter---variable name.

+new-method---the new method object.

+

Description:

+

+The macro defmethod defines a method on a generic function.

+If (fboundp function-name) is nil, a generic function is created with default values for the argument precedence order (each argument is more specific than the arguments to its right in the argument list), for the generic function class (the class standard-generic-function), for the method class (the class standard-method), and for the method combination type (the standard method combination type). The lambda list of the generic function is congruent with the lambda list of the method being defined; if the defmethod form mentions keyword arguments, the lambda list of the generic function will mention ..... key (but no keyword arguments). If function-name names an ordinary function, a macro, or a special operator, an error is signaled.

+If a generic function is currently named by function-name, the lambda list of the method must be congruent with the lambda list of the generic function. If this condition does not hold, an error is signaled. For a definition of congruence in this context, see Section 7.6.4 (Congruent Lambda-lists for all Methods of a Generic Function).

+Each method-qualifier argument is an object that is used by method combination to identify the given method. The method combination type might further restrict what a method qualifier can be. The standard method combination type allows for unqualified methods and methods whose sole qualifier is one of the keywords :before, :after, or :around.

+The specialized-lambda-list argument is like an ordinary lambda list except that the names of required parameters can be replaced by specialized parameters. A specialized parameter is a list of the form (var parameter-specializer-name). Only required parameters can be specialized. If parameter-specializer-name is a symbol it names a class; if it is a list, it is of the form (eql eql-specializer-form). The parameter specializer name (eql eql-specializer-form) indicates that the corresponding argument must be eql to the object that is the value of eql-specializer-form for the method to be applicable. The eql-specializer-form is evaluated at the time that the expansion of the defmethod macro is evaluated. If no parameter specializer name is specified for a given required parameter, the parameter specializer defaults to the class t. For further discussion, see Section 7.6.2 (Introduction to Methods).

+The form arguments specify the method body. The body of the method is enclosed in an implicit block. If function-name is a symbol, this block bears the same name as the generic function. If function-name is a list of the form (setf symbol), the name of the block is symbol.

+The class of the method object that is created is that given by the method class option of the generic function on which the method is defined.

+If the generic function already has a method that agrees with the method being defined on parameter specializers and qualifiers, defmethod replaces the existing method with the one now being defined. For a definition of agreement in this context. see Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers).

+The parameter specializers are derived from the parameter specializer names as described in Section 7.6.2 (Introduction to Methods).

+The expansion of the defmethod macro ``refers to'' each specialized parameter (see the description of ignore within the description of declare). This includes parameters that have an explicit parameter specializer name of t. This means that a compiler warning does not occur if the body of the method does not refer to a specialized parameter, while a warning might occur if the body of the method does not refer to an unspecialized parameter. For this reason, a parameter that specializes on t is not quite synonymous with an unspecialized parameter in this context.

+ Declarations at the head of the method body that apply to the method's lambda variables are treated as bound declarations whose scope is the same as the corresponding bindings.

+Declarations at the head of the method body that apply to the functional bindings of call-next-method or next-method-p apply to references to those functions within the method body forms. Any outer bindings of the function names call-next-method and next-method-p, and declarations associated with such bindings are shadowed[2] within the method body forms.

+The scope of free declarations at the head of the method body is the entire method body, which includes any implicit local function definitions but excludes initialization forms for the lambda variables.

+ defmethod is not required to perform any compile-time side effects. In particular, the methods are not installed for invocation during compilation. An implementation may choose to store information about the generic function for the purposes of compile-time error-checking (such as checking the number of arguments on calls, or noting that a definition for the function name has been seen).

+ Documentation is attached as a documentation string to the method object.

+

Examples: None. +

+

Affected By:

+

+The definition of the referenced generic function.

+

Exceptional Situations:

+

+If function-name names an ordinary function, a macro, or a special operator, an error of type error is signaled.

+If a generic function is currently named by function-name, the lambda list of the method must be congruent with the lambda list of the generic function, or an error of type error is signaled.

+

See Also:

+

+defgeneric, documentation, Section 7.6.2 (Introduction to Methods), Section 7.6.4 (Congruent Lambda-lists for all Methods of a Generic Function), Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpar.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpar.htm new file mode 100644 index 00000000..a3982f7d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpar.htm @@ -0,0 +1,129 @@ + + + +CLHS: Macro DEFPARAMETER, DEFVAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFPARAMETER, DEFVAR

+

Syntax:

+

+ +defparameter name initial-value [documentation] => name

+ +defvar name [initial-value [documentation]] => name

+

+

Arguments and Values:

+

+name---a symbol; not evaluated.

+

+initial-value---a form; for defparameter, it is always evaluated, but for defvar it is evaluated only if name is not already bound.

+ documentation---a string; not evaluated.

+

Description:

+

+defparameter and defvar establish name as a dynamic variable.

+defparameter unconditionally assigns the initial-value to the dynamic variable named name. defvar, by contrast, assigns initial-value (if supplied) to the dynamic variable named name only if name is not already bound.

+ If no initial-value is supplied, defvar leaves the value cell of the dynamic variable named name undisturbed; if name was previously bound, its old value persists, and if it was previously unbound, it remains unbound.

+If documentation is supplied, it is attached to name as a documentation string of kind variable.

+ defparameter and defvar normally appear as a top level form, but it is meaningful for them to appear as non-top-level forms. However, the compile-time side effects described below only take place when they appear as top level forms.

+

Examples:

+

+

+ (defparameter *p* 1) =>  *P*
+ *p* =>  1
+ (constantp '*p*) =>  false
+ (setq *p* 2) =>  2
+ (defparameter *p* 3) =>  *P*
+ *p* =>  3
+
+ (defvar *v* 1) =>  *V*
+ *v* =>  1
+ (constantp '*v*) =>  false
+ (setq *v* 2) =>  2
+ (defvar *v* 3) =>  *V*
+ *v* =>  2
+
+ (defun foo ()
+   (let ((*p* 'p) (*v* 'v))
+     (bar))) =>  FOO
+ (defun bar () (list *p* *v*)) =>  BAR
+ (foo) =>  (P V)
+
+

+The principal operational distinction between defparameter and defvar is that defparameter makes an unconditional assignment to name, while defvar makes a conditional one. In practice, this means that defparameter is useful in situations where loading or reloading the definition would want to pick up a new value of the variable, while defvar is used in situations where the old value would want to be retained if the file were loaded or reloaded. For example, one might create a file which contained:

+

+ (defvar *the-interesting-numbers* '())
+ (defmacro define-interesting-number (name n)
+   `(progn (defvar ,name ,n)
+           (pushnew ,name *the-interesting-numbers*)
+           ',name))
+ (define-interesting-number *my-height* 168) ;cm
+ (define-interesting-number *my-weight* 13)  ;stones
+
+

+Here the initial value, (), for the variable *the-interesting-numbers* is just a seed that we are never likely to want to reset to something else once something has been grown from it. As such, we have used defvar to avoid having the *interesting-numbers* information reset if the file is loaded a second time. It is true that the two calls to define-interesting-number here would be reprocessed, but if there were additional calls in another file, they would not be and that information would be lost. On the other hand, consider the following code:

+

+ (defparameter *default-beep-count* 3)
+ (defun beep (&optional (n *default-beep-count*))
+   (dotimes (i n) (si:%beep 1000. 100000.) (sleep 0.1)))
+
+

+Here we could easily imagine editing the code to change the initial value of *default-beep-count*, and then reloading the file to pick up the new value. In order to make value updating easy, we have used defparameter.

+On the other hand, there is potential value to using defvar in this situation. For example, suppose that someone had predefined an alternate value for *default-beep-count*, or had loaded the file and then manually changed the value. In both cases, if we had used defvar instead of defparameter, those user preferences would not be overridden by (re)loading the file.

+The choice of whether to use defparameter or defvar has visible consequences to programs, but is nevertheless often made for subjective reasons.

+

Side Effects:

+

+ If a defvar or defparameter form appears as a top level form, the compiler must recognize that the name has been proclaimed special. However, it must neither evaluate the initial-value form nor assign the dynamic variable named name at compile time.

+There may be additional (implementation-defined) compile-time or run-time side effects, as long as such effects do not interfere with the correct operation of conforming programs.

+

Affected By:

+

+defvar is affected by whether name is already bound.

+

Exceptional Situations: None. +

+

See Also:

+

+declaim, defconstant, documentation, Section 3.2 (Compilation)

+

Notes:

+

+It is customary to name dynamic variables with an asterisk at the beginning and end of the name. e.g., *foo* is a good name for a dynamic variable, but not for a lexical variable; foo is a good name for a lexical variable, but not for a dynamic variable. This naming convention is observed for all defined names in Common Lisp; however, neither conforming programs nor conforming implementations are obliged to adhere to this convention.

+The intent of the permission for additional side effects is to allow implementations to do normal ``bookkeeping'' that accompanies definitions. For example, the macro expansion of a defvar or defparameter form might include code that arranges to record the name of the source file in which the definition occurs.

+defparameter and defvar might be defined as follows:

+

+ (defmacro defparameter (name initial-value 
+                         &optional (documentation nil documentation-p))
+   `(progn (declaim (special ,name))
+           (setf (symbol-value ',name) ,initial-value)
+           ,(when documentation-p
+              `(setf (documentation ',name 'variable) ',documentation))
+           ',name))
+ (defmacro defvar (name &optional
+                        (initial-value nil initial-value-p)
+                        (documentation nil documentation-p))
+   `(progn (declaim (special ,name))
+           ,(when initial-value-p
+              `(unless (boundp ',name)
+                 (setf (symbol-value ',name) ,initial-value)))
+           ,(when documentation-p
+              `(setf (documentation ',name 'variable) ',documentation))
+           ',name))
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpkg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpkg.htm new file mode 100644 index 00000000..3a807820 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defpkg.htm @@ -0,0 +1,130 @@ + + + +CLHS: Macro DEFPACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFPACKAGE

+

+

Syntax:

+

+ +defpackage defined-package-name [[option]] => package

+

+ 

+option::= (:nicknames nickname*)* |  
+          (:documentation string) |  
+          (:use package-name*)* |  
+          (:shadow {symbol-name}*)* |  
+          (:shadowing-import-from package-name {symbol-name}*)* |  
+          (:import-from package-name {symbol-name}*)* |  
+          (:export {symbol-name}*)* |  
+          (:intern {symbol-name}*)* |  
+          (:size integer) 
+
+

+

Arguments and Values:

+

+defined-package-name---a string designator.

+ package-name---a package designator.

+nickname---a string designator.

+symbol-name---a string designator.

+package---the package named package-name.

+

Description:

+

+defpackage creates a package as specified and returns the package.

+If defined-package-name already refers to an existing package, the name-to-package mapping for that name is not changed. If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition. If defined-package-name is a symbol, its name is used.

+The standard options are described below.

+

:nicknames

+The arguments to :nicknames set the package's nicknames to the supplied names.

+

:documentation

+The argument to :documentation specifies a documentation string; it is attached as a documentation string to the package. At most one :documentation option can appear in a single defpackage form.

+

:use

+The arguments to :use set the packages that the package named by package-name will inherit from. If :use is not supplied, it defaults to the same implementation-dependent value as the :use argument to make-package.

+

:shadow

+The arguments to :shadow, symbol-names, name symbols that are to be created in the package being defined. These symbols are added to the list of shadowing symbols effectively as if by shadow.

+

:shadowing-import-from

+The symbols named by the argument symbol-names are found (involving a lookup as if by find-symbol) in the specified package-name. The resulting symbols are imported into the package being defined, and placed on the shadowing symbols list as if by shadowing-import. In no case are symbols created in any package other than the one being defined.

+

:import-from

+The symbols named by the argument symbol-names are found in the package named by package-name and they are imported into the package being defined. In no case are symbols created in any package other than the one being defined.

+

:export

+The symbols named by the argument symbol-names are found or created in the package being defined and exported. The :export option interacts with the :use option, since inherited symbols can be used rather than new ones created. The :export option interacts with the :import-from and :shadowing-import-from options, since imported symbols can be used rather than new ones created. If an argument to the :export option is accessible as an (inherited) internal symbol via use-package, that the symbol named by symbol-name is first imported into the package being defined, and is then exported from that package.

+

:intern

+The symbols named by the argument symbol-names are found or created in the package being defined. The :intern option interacts with the :use option, since inherited symbols can be used rather than new ones created.

+

:size

+The argument to the :size option declares the approximate number of symbols expected in the package. This is an efficiency hint only and might be ignored by an implementation.

+The order in which the options appear in a defpackage form is irrelevant. The order in which they are executed is as follows:

1. :shadow and :shadowing-import-from.
2. :use.
3. :import-from and :intern.
4. :export.

Shadows are established first, since they might be necessary to block spurious name conflicts when the :use option is processed. The :use option is executed next so that :intern and :export options can refer to normally inherited symbols. The :export option is executed last so that it can refer to symbols created by any of the other options; in particular, shadowing symbols and imported symbols can be made external.

+ If a defpackage form appears as a top level form, all of the actions normally performed by this macro at load time must also be performed at compile time.

+

Examples:

+

+

+ (defpackage "MY-PACKAGE"
+   (:nicknames "MYPKG" "MY-PKG")
+   (:use "COMMON-LISP")
+   (:shadow "CAR" "CDR")
+   (:shadowing-import-from "VENDOR-COMMON-LISP"  "CONS")
+   (:import-from "VENDOR-COMMON-LISP"  "GC")
+   (:export "EQ" "CONS" "FROBOLA")
+   )
+ 
+ 
+ (defpackage my-package
+   (:nicknames mypkg :MY-PKG)  ; remember Common Lisp conventions for case
+   (:use common-lisp)          ; conversion on symbols
+   (:shadow CAR :cdr #:cons)                              
+   (:export "CONS")            ; this is the shadowed one.
+   )
+
+

+

Affected By:

+

+Existing packages.

+

Exceptional Situations:

+

+If one of the supplied :nicknames already refers to an existing package, an error of type package-error is signaled.

+An error of type program-error should be signaled if :size or :documentation appears more than once.

+Since implementations might allow extended options an error of type program-error should be signaled if an option is present that is not actually supported in the host implementation.

+The collection of symbol-name arguments given to the options :shadow, :intern, :import-from, and :shadowing-import-from must all be disjoint; additionally, the symbol-name arguments given to :export and :intern must be disjoint. Disjoint in this context is defined as no two of the symbol-names being string= with each other. If either condition is violated, an error of type program-error should be signaled.

+For the :shadowing-import-from and :import-from options, a correctable error of type package-error is signaled if no symbol is accessible in the package named by package-name for one of the argument symbol-names.

+Name conflict errors are handled by the underlying calls to make-package, use-package, import, and export. See Section 11.1 (Package Concepts).

+

See Also:

+

+documentation, Section 11.1 (Package Concepts), Section 3.2 (Compilation)

+

Notes:

+

+The :intern option is useful if an :import-from or a :shadowing-import-from option in a subsequent call to defpackage (for some other package) expects to find these symbols accessible but not necessarily external.

+It is recommended that the entire package definition is put in a single place, and that all the package definitions of a program are in a single file. This file can be loaded before loading or compiling anything else that depends on those packages. Such a file can be read in the COMMON-LISP-USER package, avoiding any initial state issues.

+defpackage cannot be used to create two ``mutually recursive'' packages, such as:

+

+ (defpackage my-package
+   (:use common-lisp your-package)    ;requires your-package to exist first
+   (:export "MY-FUN"))                
+ (defpackage your-package
+   (:use common-lisp)
+   (:import-from my-package "MY-FUN") ;requires my-package to exist first
+   (:export "MY-FUN"))
+
+

+However, nothing prevents the user from using the package-affecting functions such as use-package, import, and export to establish such links after a more standard use of defpackage.

+The macroexpansion of defpackage could usefully canonicalize the names into strings, so that even if a source file has random symbols in the defpackage form, the compiled file would only contain strings.

+Frequently additional implementation-dependent options take the form of a keyword standing by itself as an abbreviation for a list (keyword T); this syntax should be properly reported as an unrecognized option in implementations that do not support it.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defset.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defset.htm new file mode 100644 index 00000000..99ad7f56 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defset.htm @@ -0,0 +1,133 @@ + + + +CLHS: Macro DEFSETF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFSETF

+

+

Syntax:

+

+The ``short form'':

+ +defsetf access-fn update-fn [documentation]

=> access-fn

+

+The ``long form'':

+ +defsetf access-fn lambda-list (store-variable*) [[declaration* | documentation]] form*

=> access-fn

+

+

Arguments and Values:

+

+access-fn---a symbol which names a function or a macro.

+update-fn---a symbol naming a function or macro.

+lambda-list---a defsetf lambda list.

+store-variable---a symbol (a variable name).

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+form---a form.

+

Description:

+

+defsetf defines how to setf a place of the form (access-fn ...) for relatively simple cases. (See define-setf-expander for more general access to this facility.) It must be the case that the function or macro named by access-fn evaluates all of its arguments.

+defsetf may take one of two forms, called the ``short form'' and the ``long form,'' which are distinguished by the type of the second argument.

+When the short form is used, update-fn must name a function (or macro) that takes one more argument than access-fn takes. When setf is given a place that is a call on access-fn, it expands into a call on update-fn that is given all the arguments to access-fn and also, as its last argument, the new value (which must be returned by update-fn as its value).

+The long form defsetf resembles defmacro. The lambda-list describes the arguments of access-fn. The store-variables describe the value or values to be stored into the place. The body must compute the expansion of a setf of a call on access-fn. The expansion function is defined in the same lexical environment in which the defsetf form appears.

+During the evaluation of the forms, the variables in the lambda-list and the store-variables are bound to names of temporary variables, generated as if by gensym or gentemp, that will be bound by the expansion of setf to the values of those subforms. This binding permits the forms to be written without regard for order-of-evaluation issues. defsetf arranges for the temporary variables to be optimized out of the final result in cases where that is possible.

+ The body code in defsetf is implicitly enclosed in a block whose name is access-fn

+defsetf ensures that subforms of the place are evaluated exactly once.

+Documentation is attached to access-fn as a documentation string of kind setf.

+ If a defsetf form appears as a top level form, the compiler must make the setf expander available so that it may be used to expand calls to setf later on in the file. Users must ensure that the forms, if any, can be evaluated at compile time if the access-fn is used in a place later in the same file. The compiler must make these setf expanders available to compile-time calls to get-setf-expansion when its environment argument is a value received as the environment parameter of a macro.

+

Examples:

+ The effect of

+

+ (defsetf symbol-value set)
+
+ is built into the Common Lisp system. This causes the form (setf (symbol-value foo) fu) to expand into (set foo fu).

+Note that

+

+ (defsetf car rplaca)
+
+ would be incorrect because rplaca does not return its last argument.

+

+ (defun middleguy (x) (nth (truncate (1- (list-length x)) 2) x)) =>  MIDDLEGUY
+ (defun set-middleguy (x v)
+    (unless (null x)
+      (rplaca (nthcdr (truncate (1- (list-length x)) 2) x) v))
+    v) =>  SET-MIDDLEGUY
+ (defsetf middleguy set-middleguy) =>  MIDDLEGUY
+ (setq a (list 'a 'b 'c 'd)
+       b (list 'x)
+       c (list 1 2 3 (list 4 5 6) 7 8 9)) =>  (1 2 3 (4 5 6) 7 8 9)
+ (setf (middleguy a) 3) =>  3
+ (setf (middleguy b) 7) =>  7
+ (setf (middleguy (middleguy c)) 'middleguy-symbol) =>  MIDDLEGUY-SYMBOL
+ a =>  (A 3 C D)
+ b =>  (7)
+ c =>  (1 2 3 (4 MIDDLEGUY-SYMBOL 6) 7 8 9)
+
+

+An example of the use of the long form of defsetf:

+

+ (defsetf subseq (sequence start &optional end) (new-sequence)
+   `(progn (replace ,sequence ,new-sequence
+                    :start1 ,start :end1 ,end)
+           ,new-sequence)) =>  SUBSEQ
+
+

+

+ (defvar *xy* (make-array '(10 10)))
+ (defun xy (&key ((x x) 0) ((y y) 0)) (aref *xy* x y)) =>  XY
+ (defun set-xy (new-value &key ((x x) 0) ((y y) 0))
+   (setf (aref *xy* x y) new-value)) =>  SET-XY
+ (defsetf xy (&key ((x x) 0) ((y y) 0)) (store)
+   `(set-xy ,store 'x ,x 'y ,y)) =>  XY
+ (get-setf-expansion '(xy a b))
+=>  (#:t0 #:t1),
+   (a b),
+   (#:store),
+   ((lambda (&key ((x #:x)) ((y #:y))) 
+      (set-xy #:store 'x #:x 'y #:y))
+    #:t0 #:t1),
+   (xy #:t0 #:t1)
+ (xy 'x 1) =>  NIL
+ (setf (xy 'x 1) 1) =>  1
+ (xy 'x 1) =>  1
+ (let ((a 'x) (b 'y))
+   (setf (xy a 1 b 2) 3)
+   (setf (xy b 5 a 9) 14))
+=>  14
+ (xy 'y 0 'x 1) =>  1
+ (xy 'x 1 'y 2) =>  3
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+documentation, setf, define-setf-expander, get-setf-expansion, Section 5.1 (Generalized Reference), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+

+forms must include provision for returning the correct value (the value or values of store-variable). This is handled by forms rather than by defsetf because in many cases this value can be returned at no extra cost, by calling a function that simultaneously stores into the place and returns the correct value.

+A setf of a call on access-fn also evaluates all of access-fn's arguments; it cannot treat any of them specially. This means that defsetf cannot be used to describe how to store into a generalized reference to a byte, such as (ldb field reference). define-setf-expander is used to handle situations that do not fit the restrictions imposed by defsetf and gives the user additional control.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defstr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defstr.htm new file mode 100644 index 00000000..2a118e75 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defstr.htm @@ -0,0 +1,525 @@ + + + +CLHS: Macro DEFSTRUCT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFSTRUCT

+

Syntax:

+

+ +defstruct name-and-options [documentation] {slot-description}*

=> structure-name

+

+

+name-and-options::= structure-name | (structure-name [[options]]) 
+
+ 
+options::= conc-name-option | 
+           {constructor-option}* | 
+           copier-option | 
+           include-option | 
+           initial-offset-option | 
+           named-option | 
+           predicate-option | 
+           printer-option | 
+           type-option 
+
+ 
+conc-name-option::= :conc-name | (:conc-name) | (:conc-name conc-name) 
+
+ 
+constructor-option::= :constructor | 
+                      (:constructor) | 
+                      (:constructor constructor-name) | 
+                      (:constructor constructor-name constructor-arglist) 
+
+ 
+copier-option::= :copier | (:copier) | (:copier copier-name) 
+
+ 
+predicate-option::= :predicate | (:predicate) | (:predicate predicate-name) 
+
+ 
+include-option::= (:include included-structure-name {slot-description}*) 
+
+ 
+printer-option::= print-object-option | print-function-option 
+
+ 
+print-object-option::= (:print-object printer-name) | (:print-object) 
+
+ 
+print-function-option::= (:print-function printer-name) | (:print-function) 
+
+ 
+type-option::= (:type type) 
+
+ 
+named-option::= :named 
+
+ 
+initial-offset-option::= (:initial-offset initial-offset) 
+
+ 
+slot-description::= slot-name |  
+                    (slot-name [slot-initform [[slot-option]]]) 
+
+ 
+slot-option::= :type slot-type |  
+               :read-only slot-read-only-p 
+
+

+

Arguments and Values:

+

+conc-name---a string designator.

+constructor-arglist---a boa lambda list.

+constructor-name---a symbol.

+copier-name---a symbol.

+included-structure-name---an already-defined structure name. Note that a derived type is not permissible, even if it would expand into a structure name.

+initial-offset---a non-negative integer.

+predicate-name---a symbol.

+ printer-name---a function name or a lambda expression.

+slot-name---a symbol.

+slot-initform---a form.

+slot-read-only-p---a generalized boolean.

+structure-name---a symbol.

+type---one of the type specifiers list, vector, or (vector size), or some other type specifier defined by the implementation to be appropriate.

+documentation---a string; not evaluated.

+

Description:

+

+defstruct defines a structured type, named structure-type, with named slots as specified by the slot-options.

+defstruct defines readers for the slots and arranges for setf to work properly on such reader functions. Also, unless overridden, it defines a predicate named name-p, defines a constructor function named make-constructor-name, and defines a copier function named copy-constructor-name. All names of automatically created functions might automatically be declared inline (at the discretion of the implementation).

+If documentation is supplied, it is attached to structure-name as a documentation string of kind structure, and unless :type is used, the documentation is also attached to structure-name as a documentation string of kind type and as a documentation string to the class object for the class named structure-name.

+defstruct defines a constructor function that is used to create instances of the structure created by defstruct. The default name is make-structure-name. A different name can be supplied by giving the name as the argument to the constructor option. nil indicates that no constructor function will be created.

+After a new structure type has been defined, instances of that type normally can be created by using the constructor function for the type. A call to a constructor function is of the following form:

+

+(constructor-function-name
+ slot-keyword-1 form-1
+ slot-keyword-2 form-2
+ ...)
+
+

+The arguments to the constructor function are all keyword arguments. Each slot keyword argument must be a keyword whose name corresponds to the name of a structure slot. All the keywords and forms are evaluated. If a slot is not initialized in this way, it is initialized by evaluating slot-initform in the slot description at the time the constructor function is called. If no slot-initform is supplied, the consequences are undefined if an attempt is later made to read the slot's value before a value is explicitly assigned.

+Each slot-initform supplied for a defstruct component, when used by the constructor function for an otherwise unsupplied component, is re-evaluated on every call to the constructor function. The slot-initform is not evaluated unless it is needed in the creation of a particular structure instance. If it is never needed, there can be no type-mismatch error, even if the type of the slot is specified; no warning should be issued in this case. For example, in the following sequence, only the last call is an error.

+

+ (defstruct person (name 007 :type string)) 
+ (make-person :name "James")
+ (make-person)
+
+

+It is as if the slot-initforms were used as initialization forms for the keyword parameters of the constructor function.

+ The symbols which name the slots must not be used by the implementation as the names for the lambda variables in the constructor function, since one or more of those symbols might have been proclaimed special or might be defined as the name of a constant variable. The slot default init forms are evaluated in the lexical environment in which the defstruct form itself appears and in the dynamic environment in which the call to the constructor function appears.

+For example, if the form (gensym) were used as an initialization form, either in the constructor-function call or as the default initialization form in defstruct, then every call to the constructor function would call gensym once to generate a new symbol.

+ Each slot-description in defstruct can specify zero or more slot-options. A slot-option consists of a pair of a keyword and a value (which is not a form to be evaluated, but the value itself). For example:

+

+ (defstruct ship
+   (x-position 0.0 :type short-float)
+   (y-position 0.0 :type short-float)
+   (x-velocity 0.0 :type short-float)
+   (y-velocity 0.0 :type short-float)
+   (mass *default-ship-mass* :type short-float :read-only t))
+
+ This specifies that each slot always contains a short float, and that the last slot cannot be altered once a ship is constructed.

+ The available slot-options are:

:type type

+This specifies that the contents of the slot is always of type type. This is entirely analogous to the declaration of a variable or function; it effectively declares the result type of the reader function. It is implementation-dependent whether the type is checked when initializing a slot or when assigning to it. Type is not evaluated; it must be a valid type specifier.

+

:read-only x

+When x is true, this specifies that this slot cannot be altered; it will always contain the value supplied at construction time. setf will not accept the reader function for this slot. If x is false, this slot-option has no effect. X is not evaluated.

+ When this option is false or unsupplied, it is implementation-dependent whether the ability to write the slot is implemented by a setf function or a setf expander.

+

+The following keyword options are available for use with defstruct. A defstruct option can be either a keyword or a list of a keyword and arguments for that keyword; specifying the keyword by itself is equivalent to specifying a list consisting of the keyword and no arguments. The syntax for defstruct options differs from the pair syntax used for slot-options. No part of any of these options is evaluated.

+

:conc-name

+This provides for automatic prefixing of names of reader (or access) functions. The default behavior is to begin the names of all the reader functions of a structure with the name of the structure followed by a hyphen.

+:conc-name supplies an alternate prefix to be used. If a hyphen is to be used as a separator, it must be supplied as part of the prefix. If :conc-name is nil or no argument is supplied, then no prefix is used; then the names of the reader functions are the same as the slot names. If a non-nil prefix is given, the name of the reader function for each slot is constructed by concatenating that prefix and the name of the slot, and interning the resulting symbol in the package that is current at the time the defstruct form is expanded.

+Note that no matter what is supplied for :conc-name, slot keywords that match the slot names with no prefix attached are used with a constructor function. The reader function name is used in conjunction with setf. Here is an example:

+

+ (defstruct (door (:conc-name dr-)) knob-color width material) =>  DOOR
+ (setq my-door (make-door :knob-color 'red :width 5.0)) 
+=>  #S(DOOR :KNOB-COLOR RED :WIDTH 5.0 :MATERIAL NIL)
+ (dr-width my-door) =>  5.0
+ (setf (dr-width my-door) 43.7) =>  43.7
+ (dr-width my-door) =>  43.7
+
+

+Whether or not the :conc-name option is explicitly supplied, the following rule governs name conflicts of generated reader (or accessor) names: For any structure type S1 having a reader function named R for a slot named X1 that is inherited by another structure type S2 that would have a reader function with the same name R for a slot named X2, no definition for R is generated by the definition of S2; instead, the definition of R is inherited from the definition of S1. (In such a case, if X1 and X2 are different slots, the implementation might signal a style warning.)

+

:constructor

+This option takes zero, one, or two arguments. If at least one argument is supplied and the first argument is not nil, then that argument is a symbol which specifies the name of the constructor function. If the argument is not supplied (or if the option itself is not supplied), the name of the constructor is produced by concatenating the string "MAKE-" and the name of the structure, interning the name in whatever package is current at the time defstruct is expanded. If the argument is provided and is nil, no constructor function is defined.

+If :constructor is given as (:constructor name arglist), then instead of making a keyword driven constructor function, defstruct defines a ``positional'' constructor function, taking arguments whose meaning is determined by the argument's position and possibly by keywords. Arglist is used to describe what the arguments to the constructor will be. In the simplest case something like (:constructor make-foo (a b c)) defines make-foo to be a three-argument constructor function whose arguments are used to initialize the slots named a, b, and c.

+Because a constructor of this type operates ``By Order of Arguments,'' it is sometimes known as a ``boa constructor.''

+For information on how the arglist for a ``boa constructor'' is processed, see Section 3.4.6 (Boa Lambda Lists).

+It is permissible to use the :constructor option more than once, so that you can define several different constructor functions, each taking different parameters.

+

+ defstruct creates the default-named keyword constructor function only if no explicit :constructor options are specified, or if the :constructor option is specified without a name argument.

+(:constructor nil) is meaningful only when there are no other :constructor options specified. It prevents defstruct from generating any constructors at all.

+Otherwise, defstruct creates a constructor function corresponding to each supplied :constructor option. It is permissible to specify multiple keyword constructor functions as well as multiple ``boa constructors''.

+

:copier

+This option takes one argument, a symbol, which specifies the name of the copier function. If the argument is not provided or if the option itself is not provided, the name of the copier is produced by concatenating the string "COPY-" and the name of the structure, interning the name in whatever package is current at the time defstruct is expanded. If the argument is provided and is nil, no copier function is defined.

+ The automatically defined copier function is a function of one argument, which must be of the structure type being defined. The copier function creates a fresh structure that has the same type as its argument, and that has the same component values as the original structure; that is, the component values are not copied recursively. If the defstruct :type option was not used, the following equivalence applies:

+

+ (copier-name x) = (copy-structure (the structure-name x))
+
+

+

:include

+This option is used for building a new structure definition as an extension of another structure definition. For example:

+

+ (defstruct person name age sex)
+
+ To make a new structure to represent an astronaut that has the attributes of name, age, and sex, and functions that operate on person structures, astronaut is defined with :include as follows:

+

+ (defstruct (astronaut (:include person)
+                       (:conc-name astro-))
+    helmet-size
+    (favorite-beverage 'tang))
+
+

+:include causes the structure being defined to have the same slots as the included structure. This is done in such a way that the reader functions for the included structure also work on the structure being defined. In this example, an astronaut therefore has five slots: the three defined in person and the two defined in astronaut itself. The reader functions defined by the person structure can be applied to instances of the astronaut structure, and they work correctly. Moreover, astronaut has its own reader functions for components defined by the person structure. The following examples illustrate the use of astronaut structures:

+

+ (setq x (make-astronaut :name 'buzz
+                         :age 45.
+                         :sex t
+                         :helmet-size 17.5))
+ (person-name x) =>  BUZZ
+ (astro-name x) =>  BUZZ
+ (astro-favorite-beverage x) =>  TANG
+
+ +
+ (reduce #'+ astros :key #'person-age) ; obtains the total of the ages 
+                                       ; of the possibly empty
+                                       ; sequence of astros
+
+ The difference between the reader functions person-name and astro-name is that person-name can be correctly applied to any person, including an astronaut, while astro-name can be correctly applied only to an astronaut. An implementation might check for incorrect use of reader functions.

+At most one :include can be supplied in a single defstruct. The argument to :include is required and must be the name of some previously defined structure. If the structure being defined has no :type option, then the included structure must also have had no :type option supplied for it. If the structure being defined has a :type option, then the included structure must have been declared with a :type option specifying the same representation type.

+If no :type option is involved, then the structure name of the including structure definition becomes the name of a data type, and therefore a valid type specifier recognizable by typep; it becomes a subtype of the included structure. In the above example, astronaut is a subtype of person; hence

+

+ (typep (make-astronaut) 'person) =>  true
+
+ indicating that all operations on persons also work on astronauts.

+The structure using :include can specify default values or slot-options for the included slots different from those the included structure specifies, by giving the :include option as:

+

+ (:include included-structure-name slot-description*)
+
+ Each slot-description must have a slot-name that is the same as that of some slot in the included structure. If a slot-description has no slot-initform, then in the new structure the slot has no initial value. Otherwise its initial value form is replaced by the slot-initform in the slot-description. A normally writable slot can be made read-only. If a slot is read-only in the included structure, then it must also be so in the including structure. If a type is supplied for a slot, it must be a subtype of the type specified in the included structure.

+For example, if the default age for an astronaut is 45, then

+

+ (defstruct (astronaut (:include person (age 45)))
+    helmet-size
+    (favorite-beverage 'tang))
+
+

+If :include is used with the :type option, then the effect is first to skip over as many representation elements as needed to represent the included structure, then to skip over any additional elements supplied by the :initial-offset option, and then to begin allocation of elements from that point. For example:

+

+ (defstruct (binop (:type list) :named (:initial-offset 2))
+   (operator '? :type symbol)   
+   operand-1
+   operand-2) =>  BINOP
+ (defstruct (annotated-binop (:type list)
+                             (:initial-offset 3)
+                             (:include binop))
+  commutative associative identity) =>  ANNOTATED-BINOP
+ (make-annotated-binop :operator '*
+                       :operand-1 'x
+                       :operand-2 5
+                       :commutative t
+                       :associative t
+                       :identity 1)
+   =>  (NIL NIL BINOP * X 5 NIL NIL NIL T T 1)
+
+ The first two nil elements stem from the :initial-offset of 2 in the definition of binop. The next four elements contain the structure name and three slots for binop. The next three nil elements stem from the :initial-offset of 3 in the definition of annotated-binop. The last three list elements contain the additional slots for an annotated-binop.

+

:initial-offset

+:initial-offset instructs defstruct to skip over a certain number of slots before it starts allocating the slots described in the body. This option's argument is the number of slots defstruct should skip. :initial-offset can be used only if :type is also supplied.

+ :initial-offset allows slots to be allocated beginning at a representational element other than the first. For example, the form

+

+ (defstruct (binop (:type list) (:initial-offset 2))
+   (operator '? :type symbol)
+   operand-1
+   operand-2) =>  BINOP
+
+ would result in the following behavior for make-binop:

+

+ (make-binop :operator '+ :operand-1 'x :operand-2 5)
+=>  (NIL NIL + X 5)
+ (make-binop :operand-2 4 :operator '*)
+=>  (NIL NIL * NIL 4)
+
+ The selector functions binop-operator, binop-operand-1, and binop-operand-2 would be essentially equivalent to third, fourth, and fifth, respectively. Similarly, the form

+

+ (defstruct (binop (:type list) :named (:initial-offset 2))
+   (operator '? :type symbol)
+   operand-1
+   operand-2) =>  BINOP
+
+ would result in the following behavior for make-binop:

+

+ (make-binop :operator '+ :operand-1 'x :operand-2 5) =>  (NIL NIL BINOP + X 5)
+ (make-binop :operand-2 4 :operator '*) =>  (NIL NIL BINOP * NIL 4)
+
+

+The first two nil elements stem from the :initial-offset of 2 in the definition of binop. The next four elements contain the structure name and three slots for binop.

+

:named

+:named specifies that the structure is named. If no :type is supplied, then the structure is always named.

+For example:

+

+ (defstruct (binop (:type list))
+   (operator '? :type symbol)
+   operand-1
+   operand-2) =>  BINOP
+
+ This defines a constructor function make-binop and three selector functions, namely binop-operator, binop-operand-1, and binop-operand-2. (It does not, however, define a predicate binop-p, for reasons explained below.)

+The effect of make-binop is simply to construct a list of length three:

+

+ (make-binop :operator '+ :operand-1 'x :operand-2 5) =>  (+ X 5)  
+ (make-binop :operand-2 4 :operator '*) =>  (* NIL 4)
+
+ It is just like the function list except that it takes keyword arguments and performs slot defaulting appropriate to the binop conceptual data type. Similarly, the selector functions binop-operator, binop-operand-1, and binop-operand-2 are essentially equivalent to car, cadr, and caddr, respectively. They might not be completely equivalent because, for example, an implementation would be justified in adding error-checking code to ensure that the argument to each selector function is a length-3 list.

+binop is a conceptual data type in that it is not made a part of the Common Lisp type system. typep does not recognize binop as a type specifier, and type-of returns list when given a binop structure. There is no way to distinguish a data structure constructed by make-binop from any other list that happens to have the correct structure.

+There is not any way to recover the structure name binop from a structure created by make-binop. This can only be done if the structure is named. A named structure has the property that, given an instance of the structure, the structure name (that names the type) can be reliably recovered. For structures defined with no :type option, the structure name actually becomes part of the Common Lisp data-type system. type-of, when applied to such a structure, returns the structure name as the type of the object; typep recognizes the structure name as a valid type specifier.

+For structures defined with a :type option, type-of returns a type specifier such as list or (vector t), depending on the type supplied to the :type option. The structure name does not become a valid type specifier. However, if the :named option is also supplied, then the first component of the structure (as created by a defstruct constructor function) always contains the structure name. This allows the structure name to be recovered from an instance of the structure and allows a reasonable predicate for the conceptual type to be defined: the automatically defined name-p predicate for the structure operates by first checking that its argument is of the proper type (list, (vector t), or whatever) and then checking whether the first component contains the appropriate type name.

+Consider the binop example shown above, modified only to include the :named option:

+

+ (defstruct (binop (:type list) :named)
+   (operator '? :type symbol)
+   operand-1
+   operand-2) =>  BINOP
+
+ As before, this defines a constructor function make-binop and three selector functions binop-operator, binop-operand-1, and binop-operand-2. It also defines a predicate binop-p. The effect of make-binop is now to construct a list of length four:

+

+ (make-binop :operator '+ :operand-1 'x :operand-2 5) =>  (BINOP + X 5)
+ (make-binop :operand-2 4 :operator '*) =>  (BINOP * NIL 4)
+
+ The structure has the same layout as before except that the structure name binop is included as the first list element. The selector functions binop-operator, binop-operand-1, and binop-operand-2 are essentially equivalent to cadr, caddr, and cadddr, respectively. The predicate binop-p is more or less equivalent to this definition:

+

+ (defun binop-p (x)
+   (and (consp x) (eq (car x) 'binop))) =>  BINOP-P
+
+ The name binop is still not a valid type specifier recognizable to typep, but at least there is a way of distinguishing binop structures from other similarly defined structures.

+

:predicate

+This option takes one argument, which specifies the name of the type predicate. If the argument is not supplied or if the option itself is not supplied, the name of the predicate is made by concatenating the name of the structure to the string "-P", interning the name in whatever package is current at the time defstruct is expanded. If the argument is provided and is nil, no predicate is defined. A predicate can be defined only if the structure is named; if :type is supplied and :named is not supplied, then :predicate must either be unsupplied or have the value nil.

+

:print-function, :print-object

+The :print-function and :print-object options specify that a print-object method for structures of type structure-name should be generated. These options are not synonyms, but do perform a similar service; the choice of which option (:print-function or :print-object) is used affects how the function named printer-name is called. Only one of these options may be used, and these options may be used only if :type is not supplied.

+If the :print-function option is used, then when a structure of type structure-name is to be printed, the designated printer function is called on three arguments:

+

    +

  • the structure to be printed (a generalized instance of structure-name).

    +

  • a stream to print to.

    +

  • an integer indicating the current depth. The magnitude of this integer may vary between implementations; however, it can reliably be compared against *print-level* to determine whether depth abbreviation is appropriate.

    +

+Specifying (:print-function printer-name) is approximately equivalent to specifying:

+

+ (defmethod print-object ((object structure-name) stream)
+   (funcall (function printer-name) object stream <<current-print-depth>>))
+
+

+where the <<current-print-depth>> represents the printer's belief of how deep it is currently printing. It is implementation-dependent whether <<current-print-depth>> is always 0 and *print-level*, if non-nil, is re-bound to successively smaller values as printing descends recursively, or whether current-print-depth varies in value as printing descends recursively and *print-level* remains constant during the same traversal.

+If the :print-object option is used, then when a structure of type structure-name is to be printed, the designated printer function is called on two arguments:

+

    +

  • the structure to be printed.

    +

  • the stream to print to.

    +

+Specifying (:print-object printer-name) is equivalent to specifying:

+

+ (defmethod print-object ((object structure-name) stream)
+   (funcall (function printer-name) object stream))
+
+

+ If no :type option is supplied, and if either a :print-function or a :print-object option is supplied, and if no printer-name is supplied, then a print-object method specialized for structure-name is generated that calls a function that implements the default printing behavior for structures using #S notation; see Section 22.1.3.12 (Printing Structures).

+If neither a :print-function nor a :print-object option is supplied, then defstruct does not generate a print-object method specialized for structure-name and some default behavior is inherited either from a structure named in an :include option or from the default behavior for printing structures; see the function print-object and Section 22.1.3.12 (Printing Structures).

+ When *print-circle* is true, a user-defined print function can print objects to the supplied stream using write, prin1, princ, or format and expect circularities to be detected and printed using the #n# syntax. This applies to methods on print-object in addition to :print-function options. If a user-defined print function prints to a stream other than the one that was supplied, then circularity detection starts over for that stream. See the variable *print-circle*.

+

+

:type

+:type explicitly specifies the representation to be used for the structure. Its argument must be one of these types:

+

vector

+This produces the same result as specifying (vector t). The structure is represented as a general vector, storing components as vector elements. The first component is vector element 1 if the structure is :named, and element 0 otherwise.

+

(vector element-type)

+The structure is represented as a (possibly specialized) vector, storing components as vector elements. Every component must be of a type that can be stored in a vector of the type specified. The first component is vector element 1 if the structure is :named, and element 0 otherwise. The structure can be :named only if the type symbol is a subtype of the supplied element-type.

+

list

+The structure is represented as a list. The first component is the cadr if the structure is :named, and the car if it is not :named.

+Specifying this option has the effect of forcing a specific representation and of forcing the components to be stored in the order specified in defstruct in corresponding successive elements of the specified representation. It also prevents the structure name from becoming a valid type specifier recognizable by typep.

+For example:

+

+ (defstruct (quux (:type list) :named) x y)
+
+

+should make a constructor that builds a list exactly like the one that list produces, with quux as its car.

+If this type is defined:

+

+ (deftype quux () '(satisfies quux-p))
+
+ then this form

+

+ (typep (make-quux) 'quux)
+
+ should return precisely what this one does

+

+ (typep (list 'quux nil nil) 'quux)
+
+

+If :type is not supplied, the structure is represented as an object of type structure-object.

+defstruct without a :type option defines a class with the structure name as its name. The metaclass of structure instances is structure-class.

+

+ The consequences of redefining a defstruct structure are undefined.

+In the case where no defstruct options have been supplied, the following functions are automatically defined to operate on instances of the new structure:

+

Predicate

+A predicate with the name structure-name-p is defined to test membership in the structure type. The predicate (structure-name-p object) is true if an object is of this type; otherwise it is false. typep can also be used with the name of the new type to test whether an object belongs to the type. Such a function call has the form (typep object 'structure-name).

+

Component reader functions

+Reader functions are defined to read the components of the structure. For each slot name, there is a corresponding reader function with the name structure-name-slot-name. This function reads the contents of that slot. Each reader function takes one argument, which is an instance of the structure type. setf can be used with any of these reader functions to alter the slot contents.

+

Constructor function

+A constructor function with the name make-structure-name is defined. This function creates and returns new instances of the structure type.

+

Copier function

+A copier function with the name copy-structure-name is defined. The copier function takes an object of the structure type and creates a new object of the same type that is a copy of the first. The copier function creates a new structure with the same component entries as the original. Corresponding components of the two structure instances are eql.

+ If a defstruct form appears as a top level form, the compiler must make the structure type name recognized as a valid type name in subsequent declarations (as for deftype) and make the structure slot readers known to setf. In addition, the compiler must save enough information about the structure type so that further defstruct definitions can use :include in a subsequent deftype in the same file to refer to the structure type name. The functions which defstruct generates are not defined in the compile time environment, although the compiler may save enough information about the functions to code subsequent calls inline. The #S reader macro might or might not recognize the newly defined structure type name at compile time.

+

Examples:

+ An example of a structure definition follows:

+

+ (defstruct ship
+   x-position
+   y-position
+   x-velocity
+   y-velocity
+   mass)
+
+ This declares that every ship is an object with five named components. The evaluation of this form does the following:

+

  1. It defines ship-x-position to be a function of one argument, a ship, that returns the x-position of the ship; ship-y-position and the other components are given similar function definitions. These functions are called the access functions, as they are used to access elements of the structure.

    +

  2. ship becomes the name of a type of which instances of ships are elements. ship becomes acceptable to typep, for example; (typep x 'ship) is true if x is a ship and false if x is any object other than a ship.

    +

  3. A function named ship-p of one argument is defined; it is a predicate that is true if its argument is a ship and is false otherwise.

    +

  4. A function called make-ship is defined that, when invoked, creates a data structure with five components, suitable for use with the access functions. Thus executing

    +

    + (setq ship2 (make-ship))
+
    + sets ship2 to a newly created ship object. One can supply the initial values of any desired component in the call to make-ship by using keyword arguments in this way:

    +

    + (setq ship2 (make-ship :mass *default-ship-mass*
+                        :x-position 0
+                        :y-position 0))
+
    + This constructs a new ship and initializes three of its components. This function is called the ``constructor function'' because it constructs a new structure.

    +

  5. A function called copy-ship of one argument is defined that, when given a ship object, creates a new ship object that is a copy of the given one. This function is called the ``copier function.''

+setf can be used to alter the components of a ship:

+

+ (setf (ship-x-position ship2) 100)
+
+ This alters the x-position of ship2 to be 100. This works because defstruct behaves as if it generates an appropriate defsetf for each access function.

+

+;;;
+;;; Example 1
+;;; define town structure type
+;;; area, watertowers, firetrucks, population, elevation are its components
+;;;
+ (defstruct town
+             area
+             watertowers
+             (firetrucks 1 :type fixnum)    ;an initialized slot
+             population 
+             (elevation 5128 :read-only t)) ;a slot that can't be changed
+=>  TOWN
+;create a town instance
+ (setq town1 (make-town :area 0 :watertowers 0)) =>  #S(TOWN...)
+;town's predicate recognizes the new instance
+ (town-p town1) =>  true
+;new town's area is as specified by make-town
+ (town-area town1) =>  0
+;new town's elevation has initial value
+ (town-elevation town1) =>  5128
+;setf recognizes reader function
+ (setf (town-population town1) 99) =>  99
+ (town-population town1) =>  99
+;copier function makes a copy of town1
+ (setq town2 (copy-town town1)) =>  #S(TOWN...)
+ (= (town-population town1) (town-population town2))  =>  true
+;since elevation is a read-only slot, its value can be set only
+;when the structure is created
+ (setq town3 (make-town :area 0 :watertowers 3 :elevation 1200))
+=>  #S(TOWN...)
+;;;
+;;; Example 2
+;;; define clown structure type
+;;; this structure uses a nonstandard prefix
+;;;
+ (defstruct (clown (:conc-name bozo-))
+             (nose-color 'red)         
+             frizzy-hair-p polkadots) =>  CLOWN
+ (setq funny-clown (make-clown)) =>  #S(CLOWN)
+;use non-default reader name
+ (bozo-nose-color funny-clown) =>  RED        
+ (defstruct (klown (:constructor make-up-klown) ;similar def using other
+             (:copier clone-klown)              ;customizing keywords
+             (:predicate is-a-bozo-p))
+             nose-color frizzy-hair-p polkadots) =>  klown
+;custom constructor now exists
+ (fboundp 'make-up-klown) =>  true
+;;;
+;;; Example 3
+;;; define a vehicle structure type
+;;; then define a truck structure type that includes 
+;;; the vehicle structure
+;;;
+ (defstruct vehicle name year (diesel t :read-only t)) =>  VEHICLE
+ (defstruct (truck (:include vehicle (year 79)))
+             load-limit                          
+             (axles 6)) =>  TRUCK
+ (setq x (make-truck :name 'mac :diesel t :load-limit 17))
+=>  #S(TRUCK...)
+;vehicle readers work on trucks
+ (vehicle-name x)
+=>  MAC
+;default taken from :include clause 
+ (vehicle-year x)
+=>  79 
+ (defstruct (pickup (:include truck))     ;pickup type includes truck
+             camper long-bed four-wheel-drive) =>  PICKUP
+ (setq x (make-pickup :name 'king :long-bed t)) =>  #S(PICKUP...)
+;:include default inherited
+ (pickup-year x) =>  79
+;;;
+;;; Example 4
+;;; use of BOA constructors
+;;;
+ (defstruct (dfs-boa                      ;BOA constructors
+               (:constructor make-dfs-boa (a b c)) 
+               (:constructor create-dfs-boa
+                 (a &optional b (c 'cc) &rest d &aux e (f 'ff))))
+             a b c d e f) =>  DFS-BOA
+;a, b, and c set by position, and the rest are uninitialized
+ (setq x (make-dfs-boa 1 2 3)) =>  #(DFS-BOA...)
+ (dfs-boa-a x) =>  1
+;a and b set, c and f defaulted
+ (setq x (create-dfs-boa 1 2)) =>  #(DFS-BOA...)
+ (dfs-boa-b x) =>  2
+ (eq (dfs-boa-c x) 'cc) =>  true
+;a, b, and c set, and the rest are collected into d
+ (setq x (create-dfs-boa 1 2 3 4 5 6)) =>  #(DFS-BOA...)
+ (dfs-boa-d x) =>  (4 5 6)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+ If any two slot names (whether present directly or inherited by the :include option) are the same under string=, defstruct should signal an error of type program-error.

+ The consequences are undefined if the included-structure-name does not name a structure type.

+

See Also:

+

+documentation, print-object, setf, subtypep, type-of, typep, Section 3.2 (Compilation)

+

Notes:

+

+The printer-name should observe the values of such printer-control variables as *print-escape*.

+The restriction against issuing a warning for type mismatches between a slot-initform and the corresponding slot's :type option is necessary because a slot-initform must be specified in order to specify slot options; in some cases, no suitable default may exist.

+The mechanism by which defstruct arranges for slot accessors to be usable with setf is implementation-dependent; for example, it may use setf functions, setf expanders, or some other implementation-dependent mechanism known to that implementation's code for setf.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_deftp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_deftp.htm new file mode 100644 index 00000000..2dc22520 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_deftp.htm @@ -0,0 +1,75 @@ + + + +CLHS: Macro DEFTYPE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFTYPE

+

+

Syntax:

+

+ +deftype name lambda-list [[declaration* | documentation]] form* => name

+

+

Arguments and Values:

+

+name---a symbol.

+lambda-list---a deftype lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+form---a form.

+

Description:

+

+deftype defines a derived type specifier named name.

+The meaning of the new type specifier is given in terms of a function which expands the type specifier into another type specifier, which itself will be expanded if it contains references to another derived type specifier.

+The newly defined type specifier may be referenced as a list of the form (name arg1 arg2 ...). The number of arguments must be appropriate to the lambda-list. If the new type specifier takes no arguments, or if all of its arguments are optional, the type specifier may be used as an atomic type specifier.

+The argument expressions to the type specifier, arg1 ... argn, are not evaluated. Instead, these literal objects become the objects to which corresponding parameters become bound.

+The body of the deftype form (but not the lambda-list) is implicitly enclosed in a block named name, and is evaluated as an implicit progn, returning a new type specifier.

+ The lexical environment of the body is the one which was current at the time the deftype form was evaluated, augmented by the variables in the lambda-list.

+ Recursive expansion of the type specifier returned as the expansion must terminate, including the expansion of type specifiers which are nested within the expansion.

+The consequences are undefined if the result of fully expanding a type specifier contains any circular structure, except within the objects referred to by member and eql type specifiers.

+Documentation is attached to name as a documentation string of kind type.

+ If a deftype form appears as a top level form, the compiler must ensure that the name is recognized in subsequent type declarations. The programmer must ensure that the body of a deftype form can be evaluated at compile time if the name is referenced in subsequent type declarations. If the expansion of a type specifier is not defined fully at compile time (perhaps because it expands into an unknown type specifier or a satisfies of a named function that isn't defined in the compile-time environment), an implementation may ignore any references to this type in declarations and/or signal a warning.

+

Examples:

+ +

+ (defun equidimensional (a)
+   (or (< (array-rank a) 2)
+       (apply #'= (array-dimensions a)))) =>  EQUIDIMENSIONAL
+ (deftype square-matrix (&optional type size)
+   `(and (array ,type (,size ,size))
+         (satisfies equidimensional))) =>  SQUARE-MATRIX
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+declare, defmacro, documentation, Section 4.2.3 (Type Specifiers), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defun.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defun.htm new file mode 100644 index 00000000..ff8513e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_defun.htm @@ -0,0 +1,100 @@ + + + +CLHS: Macro DEFUN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DEFUN

+

+

Syntax:

+

+ +defun function-name lambda-list [[declaration* | documentation]] form*

=> function-name

+

+

Arguments and Values:

+

+function-name---a function name.

+lambda-list---an ordinary lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+forms---an implicit progn.

+block-name---the function block name of the function-name.

+

Description:

+

+Defines a new function named function-name in the global environment. The body of the function defined by defun consists of forms; they are executed as an implicit progn when the function is called. defun can be used to define a new function, to install a corrected version of an incorrect definition, to redefine an already-defined function, or to redefine a macro as a function.

+defun implicitly puts a block named block-name around the body forms (but not the forms in the lambda-list) of the function defined.

+ Documentation is attached as a documentation string to name (as kind function) and to the function object.

+Evaluating defun causes function-name to be a global name for the function specified by the lambda expression

+

+ (lambda lambda-list
+   [[declaration* | documentation]]
+   (block block-name form*))
+
+

+processed in the lexical environment in which defun was executed.

+(None of the arguments are evaluated at macro expansion time.)

+ defun is not required to perform any compile-time side effects. In particular, defun does not make the function definition available at compile time. An implementation may choose to store information about the function for the purposes of compile-time error-checking (such as checking the number of arguments on calls), or to enable the function to be expanded inline.

+

Examples:

+

+

+ (defun recur (x)
+  (when (> x 0)
+    (recur (1- x)))) =>  RECUR 
+ (defun ex (a b &optional c (d 66) &rest keys &key test (start 0))
+    (list a b c d keys test start)) =>  EX 
+ (ex 1 2) =>  (1 2 NIL 66 NIL NIL 0)
+ (ex 1 2 3 4 :test 'equal :start 50) 
+=>  (1 2 3 4 (:TEST EQUAL :START 50) EQUAL 50)
+ (ex :test 1 :start 2) =>  (:TEST 1 :START 2 NIL NIL 0)
+
+ ;; This function assumes its callers have checked the types of the
+ ;; arguments, and authorizes the compiler to build in that assumption.
+ (defun discriminant (a b c)
+   (declare (number a b c))
+   "Compute the discriminant for a quadratic equation."
+   (- (* b b) (* 4 a c))) =>  DISCRIMINANT
+ (discriminant 1 2/3 -2) =>  76/9
+
+ ;; This function assumes its callers have not checked the types of the
+ ;; arguments, and performs explicit type checks before making any assumptions. 
+ (defun careful-discriminant (a b c)
+   "Compute the discriminant for a quadratic equation."
+   (check-type a number)
+   (check-type b number)
+   (check-type c number)
+   (locally (declare (number a b c))
+     (- (* b b) (* 4 a c)))) =>  CAREFUL-DISCRIMINANT
+ (careful-discriminant 1 2/3 -2) =>  76/9
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+flet, labels, block, return-from, declare, documentation, Section 3.1 (Evaluation), Section 3.4.1 (Ordinary Lambda Lists), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+ return-from can be used to return prematurely from a function defined by defun.

+Additional side effects might take place when additional information (typically debugging information) about the function definition is recorded.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_destru.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_destru.htm new file mode 100644 index 00000000..457f1e28 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_destru.htm @@ -0,0 +1,64 @@ + + + +CLHS: Macro DESTRUCTURING-BIND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DESTRUCTURING-BIND

+

+

Syntax:

+

+ +destructuring-bind lambda-list expression declaration* form*

=> result*

+

+

Arguments and Values:

+

+lambda-list---a destructuring lambda list.

+expression---a form.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+destructuring-bind binds the variables specified in lambda-list to the corresponding values in the tree structure resulting from the evaluation of expression; then destructuring-bind evaluates forms.

+The lambda-list supports destructuring as described in Section 3.4.5 (Destructuring Lambda Lists).

+

Examples:

+ +

+ (defun iota (n) (loop for i from 1 to n collect i))       ;helper
+ (destructuring-bind ((a &optional (b 'bee)) one two three)
+     `((alpha) ,@(iota 3))
+   (list a b three two one)) =>  (ALPHA BEE 3 2 1)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If the result of evaluating the expression does not match the destructuring pattern, an error of type error should be signaled.

+

See Also:

+

+macrolet, defmacro

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_do.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_do.htm new file mode 100644 index 00000000..9f7b1b6f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_do.htm @@ -0,0 +1,156 @@ + + + +CLHS: Macro DO, DO* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DO, DO*

+

+

Syntax:

+

+ +do ({var | (var [init-form [step-form]])}*) (end-test-form result-form*) declaration* {tag | statement}*

=> result*

+

+ +do* ({var | (var [init-form [step-form]])}*) (end-test-form result-form*) declaration* {tag | statement}*

=> result*

+

+

Arguments and Values:

+

+var---a symbol.

+init-form---a form.

+step-form---a form.

+end-test-form---a form.

+result-forms---an implicit progn.

+declaration---a declare expression; not evaluated.

+tag---a go tag; not evaluated.

+statement---a compound form; evaluated as described below.

+results---if a return or return-from form is executed, the values passed from that form; otherwise, the values returned by the result-forms.

+

Description:

+

+do iterates over a group of statements while a test condition holds. do accepts an arbitrary number of iteration vars which are bound within the iteration and stepped in parallel. An initial value may be supplied for each iteration variable by use of an init-form. Step-forms may be used to specify how the vars should be updated on succeeding iterations through the loop. Step-forms may be used both to generate successive values or to accumulate results. If the end-test-form condition is met prior to an execution of the body, the iteration terminates. Tags label statements.

+do* is exactly like do except that the bindings and steppings of the vars are performed sequentially rather than in parallel.

+Before the first iteration, all the init-forms are evaluated, and each var is bound to the value of its respective init-form, if supplied. This is a binding, not an assignment; when the loop terminates, the old values of those variables will be restored. For do, all of the init-forms are evaluated before any var is bound. The init-forms can refer to the bindings of the vars visible before beginning execution of do. For do*, the first init-form is evaluated, then the first var is bound to that value, then the second init-form is evaluated, then the second var is bound, and so on; in general, the kth init-form can refer to the new binding of the jth var if j < k, and otherwise to the old binding of the jth var.

+At the beginning of each iteration, after processing the variables, the end-test-form is evaluated. If the result is false, execution proceeds with the body of the do (or do*) form. If the result is true, the result-forms are evaluated in order as an implicit progn, and then do or do* returns.

+At the beginning of each iteration other than the first, vars are updated as follows. All the step-forms, if supplied, are evaluated, from left to right, and the resulting values are assigned to the respective vars. Any var that has no associated step-form is not assigned to. For do, all the step-forms are evaluated before any var is updated; the assignment of values to vars is done in parallel, as if by psetq. Because all of the step-forms are evaluated before any of the vars are altered, a step-form when evaluated always has access to the old values of all the vars, even if other step-forms precede it. For do*, the first step-form is evaluated, then the value is assigned to the first var, then the second step-form is evaluated, then the value is assigned to the second var, and so on; the assignment of values to variables is done sequentially, as if by setq. For either do or do*, after the vars have been updated, the end-test-form is evaluated as described above, and the iteration continues.

+The remainder of the do (or do*) form constitutes an implicit tagbody. Tags may appear within the body of a do loop for use by go statements appearing in the body (but such go statements may not appear in the variable specifiers, the end-test-form, or the result-forms). When the end of a do body is reached, the next iteration cycle (beginning with the evaluation of step-forms) occurs.

+An implicit block named nil surrounds the entire do (or do*) form. A return statement may be used at any point to exit the loop immediately.

+Init-form is an initial value for the var with which it is associated. If init-form is omitted, the initial value of var is nil. If a declaration is supplied for a var, init-form must be consistent with the declaration.

+Declarations can appear at the beginning of a do (or do*) body. They apply to code in the do (or do*) body, to the bindings of the do (or do*) vars, to the step-forms, to the end-test-form, and to the result-forms.

+

Examples:

+ +

+ (do ((temp-one 1 (1+ temp-one))
+       (temp-two 0 (1- temp-two)))
+      ((> (- temp-one temp-two) 5) temp-one)) =>  4
+
+ (do ((temp-one 1 (1+ temp-one))
+       (temp-two 0 (1+ temp-one)))     
+      ((= 3 temp-two) temp-one)) =>  3
+
+ (do* ((temp-one 1 (1+ temp-one))
+        (temp-two 0 (1+ temp-one)))
+       ((= 3 temp-two) temp-one)) =>  2                     
+
+ (do ((j 0 (+ j 1)))
+     (nil)                       ;Do forever.
+   (format t "~%Input ~D:" j)
+   (let ((item (read)))
+     (if (null item) (return)   ;Process items until NIL seen.
+         (format t "~&Output ~D: ~S" j item))))
+>>  Input 0: banana
+>>  Output 0: BANANA
+>>  Input 1: (57 boxes)
+>>  Output 1: (57 BOXES)
+>>  Input 2: NIL
+=>  NIL
+
+ (setq a-vector (vector 1 nil 3 nil))
+ (do ((i 0 (+ i 1))     ;Sets every null element of a-vector to zero.
+      (n (array-dimension a-vector 0)))
+     ((= i n))
+   (when (null (aref a-vector i))
+     (setf (aref a-vector i) 0))) =>  NIL
+a-vector =>  #(1 0 3 0)
+
+

+

+ (do ((x e (cdr x))
+      (oldx x x))
+     ((null x))
+   body)
+
+ is an example of parallel assignment to index variables. On the first iteration, the value of oldx is whatever value x had before the do was entered. On succeeding iterations, oldx contains the value that x had on the previous iteration.

+

+ (do ((x foo (cdr x))
+      (y bar (cdr y))
+      (z '() (cons (f (car x) (car y)) z)))
+     ((or (null x) (null y))
+      (nreverse z)))
+
+ does the same thing as (mapcar #'f foo bar). The step computation for z is an example of the fact that variables are stepped in parallel. Also, the body of the loop is empty.

+

+ (defun list-reverse (list)
+        (do ((x list (cdr x))
+             (y '() (cons (car x) y)))
+            ((endp x) y)))
+
+

+As an example of nested iterations, consider a data structure that is a list of conses. The car of each cons is a list of symbols, and the cdr of each cons is a list of equal length containing corresponding values. Such a data structure is similar to an association list, but is divided into ``frames''; the overall structure resembles a rib-cage. A lookup function on such a data structure might be:

+

+ (defun ribcage-lookup (sym ribcage)           
+        (do ((r ribcage (cdr r)))
+            ((null r) nil)
+          (do ((s (caar r) (cdr s))
+               (v (cdar r) (cdr v))) 
+              ((null s))
+            (when (eq (car s) sym)
+              (return-from ribcage-lookup (car v)))))) =>  RIBCAGE-LOOKUP
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+other iteration functions (dolist, dotimes, and loop) and more primitive functionality (tagbody, go, block, return, let, and setq)

+

Notes:

+ If end-test-form is nil, the test will never succeed. This provides an idiom for ``do forever'': the body of the do or do* is executed repeatedly. The infinite loop can be terminated by the use of return, return-from, go to an outer level, or throw.

+A do form may be explained in terms of the more primitive forms block, return, let, loop, tagbody, and psetq as follows:

+

+ (block nil        
+   (let ((var1 init1)
+         (var2 init2)
+         ...
+         (varn initn))
+     declarations
+     (loop (when end-test (return (progn . result)))
+           (tagbody . tagbody)
+           (psetq var1 step1
+                  var2 step2
+                  ...
+                  varn stepn))))
+
+

+do* is similar, except that let* and setq replace the let and psetq, respectively.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_sym.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_sym.htm new file mode 100644 index 00000000..033ff650 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_do_sym.htm @@ -0,0 +1,95 @@ + + + +CLHS: Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS

+

+

Syntax:

+

+ +do-symbols (var [package [result-form]]) declaration* {tag | statement}*

=> result*

+

+ +do-external-symbols (var [package [result-form]]) declaration* {tag | statement}*

=> result*

+

+ +do-all-symbols (var [result-form]) declaration* {tag | statement}*

=> result*

+

+

Arguments and Values:

+

+var---a variable name; not evaluated.

+ package---a package designator; evaluated. The default in do-symbols and do-external-symbols is the current package.

+result-form---a form; evaluated as described below. The default is nil.

+declaration---a declare expression; not evaluated.

+tag---a go tag; not evaluated.

+statement---a compound form; evaluated as described below.

+results---the values returned by the result-form if a normal return occurs, or else, if an explicit return occurs, the values that were transferred.

+

Description:

+

+do-symbols, do-external-symbols, and do-all-symbols iterate over the symbols of packages. For each symbol in the set of packages chosen, the var is bound to the symbol, and the statements in the body are executed. When all the symbols have been processed, result-form is evaluated and returned as the value of the macro.

+do-symbols iterates over the symbols accessible in package. Statements may execute more than once for symbols that are inherited from multiple packages.

+do-all-symbols iterates on every registered package. do-all-symbols will not process every symbol whatsoever, because a symbol not accessible in any registered package will not be processed. do-all-symbols may cause a symbol that is present in several packages to be processed more than once.

+do-external-symbols iterates on the external symbols of package.

+When result-form is evaluated, var is bound and has the value nil.

+ An implicit block named nil surrounds the entire do-symbols, do-external-symbols, or do-all-symbols form. return or return-from may be used to terminate the iteration prematurely.

+If execution of the body affects which symbols are contained in the set of packages over which iteration is occurring, other than to remove the symbol currently the value of var by using unintern, the consequences are undefined.

+For each of these macros, the scope of the name binding does not include any initial value form, but the optional result forms are included.

+Any tag in the body is treated as with tagbody.

+

Examples:

+

+

+ (make-package 'temp :use nil) =>  #<PACKAGE "TEMP">
+ (intern "SHY" 'temp) =>  TEMP::SHY, NIL ;SHY will be an internal symbol
+                                         ;in the package TEMP
+ (export (intern "BOLD" 'temp) 'temp)  =>  T  ;BOLD will be external  
+ (let ((lst ()))
+   (do-symbols (s (find-package 'temp)) (push s lst))
+   lst)
+=>  (TEMP::SHY TEMP:BOLD)
+OR=>  (TEMP:BOLD TEMP::SHY)
+ (let ((lst ()))
+   (do-external-symbols (s (find-package 'temp) lst) (push s lst))
+   lst) 
+=>  (TEMP:BOLD)
+ (let ((lst ()))                                                     
+   (do-all-symbols (s lst)
+     (when (eq (find-package 'temp) (symbol-package s)) (push s lst)))
+   lst)
+=>  (TEMP::SHY TEMP:BOLD)
+OR=>  (TEMP:BOLD TEMP::SHY)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+intern, export, Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dolist.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dolist.htm new file mode 100644 index 00000000..e194b385 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dolist.htm @@ -0,0 +1,78 @@ + + + +CLHS: Macro DOLIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DOLIST

+

+

Syntax:

+

+ +dolist (var list-form [result-form]) declaration* {tag | statement}*

=> result*

+

+

Arguments and Values:

+

+var---a symbol.

+list-form---a form.

+result-form---a form.

+declaration---a declare expression; not evaluated.

+tag---a go tag; not evaluated.

+statement---a compound form; evaluated as described below.

+results---if a return or return-from form is executed, the values passed from that form; otherwise, the values returned by the result-form or nil if there is no result-form.

+

Description:

+

+dolist iterates over the elements of a list. The body of dolist is like a tagbody. It consists of a series of tags and statements.

+dolist evaluates list-form, which should produce a list. It then executes the body once for each element in the list, in the order in which the tags and statements occur, with var bound to the element. Then result-form is evaluated. tags label statements.

+At the time result-form is processed, var is bound to nil.

+An implicit block named nil surrounds dolist. return may be used to terminate the loop immediately without performing any further iterations, returning zero or more values.

+The scope of the binding of var does not include the list-form, but the result-form is included.

+It is implementation-dependent whether dolist establishes a new binding of var on each iteration or whether it establishes a binding for var once at the beginning and then assigns it on any subsequent iterations.

+

Examples:

+ +

+ (setq temp-two '()) =>  NIL
+ (dolist (temp-one '(1 2 3 4) temp-two) (push temp-one temp-two)) =>  (4 3 2 1)
+
+ (setq temp-two 0) =>  0
+ (dolist (temp-one '(1 2 3 4)) (incf temp-two)) =>  NIL
+ temp-two =>  4
+
+ (dolist (x '(a b c d)) (prin1 x) (princ " ")) 
+>>  A B C D 
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+do, dotimes, tagbody, Section 3.6 (Traversal Rules and Side Effects)

+

Notes:

+

+go may be used within the body of dolist to transfer control to a statement labeled by a tag.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dotime.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dotime.htm new file mode 100644 index 00000000..977be58f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_dotime.htm @@ -0,0 +1,102 @@ + + + +CLHS: Macro DOTIMES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro DOTIMES

+

+

Syntax:

+

+ +dotimes (var count-form [result-form]) declaration* {tag | statement}*

=> result*

+

+

Arguments and Values:

+

+var---a symbol.

+count-form---a form.

+result-form---a form.

+declaration---a declare expression; not evaluated.

+tag---a go tag; not evaluated.

+statement---a compound form; evaluated as described below.

+results---if a return or return-from form is executed, the values passed from that form; otherwise, the values returned by the result-form or nil if there is no result-form.

+

Description:

+

+dotimes iterates over a series of integers.

+dotimes evaluates count-form, which should produce an integer. If count-form is zero or negative, the body is not executed. dotimes then executes the body once for each integer from 0 up to but not including the value of count-form, in the order in which the tags and statements occur, with var bound to each integer. Then result-form is evaluated. At the time result-form is processed, var is bound to the number of times the body was executed. Tags label statements.

+An implicit block named nil surrounds dotimes. return may be used to terminate the loop immediately without performing any further iterations, returning zero or more values.

+The body of the loop is an implicit tagbody; it may contain tags to serve as the targets of go statements. Declarations may appear before the body of the loop.

+The scope of the binding of var does not include the count-form, but the result-form is included.

+It is implementation-dependent whether dotimes establishes a new binding of var on each iteration or whether it establishes a binding for var once at the beginning and then assigns it on any subsequent iterations.

+

Examples:

+

+

+ (dotimes (temp-one 10 temp-one)) =>  10
+ (setq temp-two 0) =>  0
+ (dotimes (temp-one 10 t) (incf temp-two)) =>  T
+ temp-two =>  10
+
+

+Here is an example of the use of dotimes in processing strings:

+

+;;; True if the specified subsequence of the string is a
+;;; palindrome (reads the same forwards and backwards).
+ (defun palindromep (string &optional
+                           (start 0)
+                           (end (length string)))
+   (dotimes (k (floor (- end start) 2) t)
+    (unless (char-equal (char string (+ start k))
+                        (char string (- end k 1)))
+      (return nil))))
+ (palindromep "Able was I ere I saw Elba") =>  T
+ (palindromep "A man, a plan, a canal--Panama!") =>  NIL
+ (remove-if-not #'alpha-char-p          ;Remove punctuation.
+               "A man, a plan, a canal--Panama!")
+=>  "AmanaplanacanalPanama"
+ (palindromep
+  (remove-if-not #'alpha-char-p
+                "A man, a plan, a canal--Panama!")) =>  T
+ (palindromep
+  (remove-if-not
+   #'alpha-char-p
+   "Unremarkable was I ere I saw Elba Kramer, nu?")) =>  T
+ (palindromep
+  (remove-if-not
+   #'alpha-char-p
+   "A man, a plan, a cat, a ham, a yak,
+                  a yam, a hat, a canal--Panama!")) =>  T
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+do, dolist, tagbody

+

Notes:

+

+go may be used within the body of dotimes to transfer control to a statement labeled by a tag.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_format.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_format.htm new file mode 100644 index 00000000..3e9a839a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_format.htm @@ -0,0 +1,72 @@ + + + +CLHS: Macro FORMATTER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro FORMATTER

+

+

Syntax:

+

+ +formatter control-string => function

+

+

Arguments and Values:

+

+control-string---a format string; not evaluated.

+function---a function.

+

Description:

+

+Returns a function which has behavior equivalent to:

+

+  #'(lambda (*standard-output* &rest arguments)
+      (apply #'format t control-string arguments)
+      arguments-tail)
+
+

+where arguments-tail is either the tail of arguments which has as its car the argument that would be processed next if there were more format directives in the control-string, or else nil if no more arguments follow the most recently processed argument.

+

Examples:

+

+

+(funcall (formatter "~&~A~A") *standard-output* 'a 'b 'c)
+>>  AB
+=>  (C)
+
+(format t (formatter "~&~A~A") 'a 'b 'c)
+>>  AB
+=>  NIL
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+Might signal an error (at macro expansion time or at run time) if the argument is not a valid format string.

+

See Also:

+

+format

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_hand_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_hand_1.htm new file mode 100644 index 00000000..ae110f06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_hand_1.htm @@ -0,0 +1,143 @@ + + + +CLHS: Macro HANDLER-CASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro HANDLER-CASE

+

+

Syntax:

+

+ +handler-case expression [[{error-clause}* | no-error-clause]] => result*

+

+

+clause::= error-clause | no-error-clause 
+
+ 
+error-clause::= (typespec ([var]) declaration* form*) 
+
+ 
+no-error-clause::= (:no-error lambda-list declaration* form*) 
+
+

+

Arguments and Values:

+

+expression---a form.

+typespec---a type specifier.

+var---a variable name.

+lambda-list---an ordinary lambda list.

+declaration---a declare expression; not evaluated.

+form---a form.

+results---In the normal situation, the values returned are those that result from the evaluation of expression; in the exceptional situation when control is transferred to a clause, the value of the last form in that clause is returned.

+

Description:

+

+handler-case executes expression in a dynamic environment where various handlers are active. Each error-clause specifies how to handle a condition matching the indicated typespec. A no-error-clause allows the specification of a particular action if control returns normally.

+If a condition is signaled for which there is an appropriate error-clause during the execution of expression (i.e., one for which (typep condition 'typespec) returns true) and if there is no intervening handler for a condition of that type, then control is transferred to the body of the relevant error-clause. In this case, the dynamic state is unwound appropriately (so that the handlers established around the expression are no longer active), and var is bound to the condition that had been signaled. If more than one case is provided, those cases are made accessible in parallel. That is, in

+

+  (handler-case form
+    (typespec1 (var1) form1)
+    (typespec2 (var2) form2))
+
+

+if the first clause (containing form1) has been selected, the handler for the second is no longer visible (or vice versa).

+ The clauses are searched sequentially from top to bottom. If there is type overlap between typespecs, the earlier of the clauses is selected.

+ If var is not needed, it can be omitted. That is, a clause such as:

+

+  (typespec (var) (declare (ignore var)) form)
+
+

+can be written (typespec () form).

+ If there are no forms in a selected clause, the case, and therefore handler-case, returns nil. If execution of expression returns normally and no no-error-clause exists, the values returned by expression are returned by handler-case. If execution of expression returns normally and a no-error-clause does exist, the values returned are used as arguments to the function described by constructing (lambda lambda-list form*) from the no-error-clause, and the values of that function call are returned by handler-case. The handlers which were established around the expression are no longer active at the time of this call.

+

Examples:

+

+

+ (defun assess-condition (condition)
+   (handler-case (signal condition)
+     (warning () "Lots of smoke, but no fire.")
+     ((or arithmetic-error control-error cell-error stream-error)
+        (condition)
+       (format nil "~S looks especially bad." condition))
+     (serious-condition (condition)
+       (format nil "~S looks serious." condition))
+     (condition () "Hardly worth mentioning.")))
+=>  ASSESS-CONDITION
+ (assess-condition (make-condition 'stream-error :stream *terminal-io*))
+=>  "#<STREAM-ERROR 12352256> looks especially bad."
+ (define-condition random-condition (condition) () 
+   (:report (lambda (condition stream)
+              (declare (ignore condition))
+              (princ "Yow" stream))))
+=>  RANDOM-CONDITION
+ (assess-condition (make-condition 'random-condition))
+=>  "Hardly worth mentioning."
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+handler-bind, ignore-errors, Section 9.1 (Condition System Concepts)

+

Notes:

+

+

+ (handler-case form
+   (type1 (var1) . body1)
+   (type2 (var2) . body2) ...)
+
+ is approximately equivalent to:

+

+ (block #1=#:g0001
+   (let ((#2=#:g0002 nil))
+     (tagbody
+       (handler-bind ((type1 #'(lambda (temp)
+                                       (setq #1# temp)
+                                       (go #3=#:g0003)))
+                      (type2 #'(lambda (temp)
+                                       (setq #2# temp)
+                                       (go #4=#:g0004))) ...)
+       (return-from #1# form))
+         #3# (return-from #1# (let ((var1 #2#)) . body1))
+         #4# (return-from #1# (let ((var2 #2#)) . body2)) ...)))
+
+

+

+ (handler-case form
+   (type1 (var1) . body1)
+   ...
+   (:no-error (varN-1 varN-2 ...) . bodyN))
+
+ is approximately equivalent to:

+

+
+ (block #1=#:error-return
+  (multiple-value-call #'(lambda (varN-1 varN-2 ...) . bodyN)
+     (block #2=#:normal-return
+       (return-from #1#
+         (handler-case (return-from #2# form)
+           (type1 (var1) . body1) ...)))))
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_handle.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_handle.htm new file mode 100644 index 00000000..0bdafe04 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_handle.htm @@ -0,0 +1,88 @@ + + + +CLHS: Macro HANDLER-BIND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro HANDLER-BIND

+

Syntax:

+

+ +handler-bind ({binding}*) form* => result*

+

+

+binding::= (type handler) 
+
+

+

Arguments and Values:

+

+type---a type specifier.

+handler---a form; evaluated to produce a handler-function.

+handler-function---a designator for a function of one argument.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+Executes forms in a dynamic environment where the indicated handler bindings are in effect.

+Each handler should evaluate to a handler-function, which is used to handle conditions of the given type during execution of the forms. This function should take a single argument, the condition being signaled.

+If more than one handler binding is supplied, the handler bindings are searched sequentially from top to bottom in search of a match (by visual analogy with typecase). If an appropriate type is found, the associated handler is run in a dynamic environment where none of these handler bindings are visible (to avoid recursive errors). If the handler declines, the search continues for another handler.

+If no appropriate handler is found, other handlers are sought from dynamically enclosing contours. If no handler is found outside, then signal returns or error enters the debugger.

+

Examples:

+

+In the following code, if an unbound variable error is signaled in the body (and not handled by an intervening handler), the first function is called.

+

+ (handler-bind ((unbound-variable #'(lambda ...))
+                (error #'(lambda ...)))
+   ...)
+
+

+If any other kind of error is signaled, the second function is called. In either case, neither handler is active while executing the code in the associated function.

+

+ (defun trap-error-handler (condition)
+   (format *error-output* "~&~A~&" condition)
+   (throw 'trap-errors nil))
+
+ (defmacro trap-errors (&rest forms)
+   `(catch 'trap-errors
+      (handler-bind ((error #'trap-error-handler))
+        ,@forms)))
+ 
+ (list (trap-errors (signal "Foo.") 1)
+       (trap-errors (error  "Bar.") 2)
+       (+ 1 2))
+>>  Bar.
+=>  (1 NIL 3)
+
+

+Note that ``Foo.'' is not printed because the condition made by signal is a simple condition, which is not of type error, so it doesn't trigger the handler for error set up by trap-errors.

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+handler-case

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ignore.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ignore.htm new file mode 100644 index 00000000..32bbfd57 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ignore.htm @@ -0,0 +1,78 @@ + + + +CLHS: Macro IGNORE-ERRORS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro IGNORE-ERRORS

+

Syntax:

+

+ +ignore-errors form* => result*

+

+

Arguments and Values:

+

+forms---an implicit progn.

+results---In the normal situation, the values of the forms are returned; in the exceptional situation, two values are returned: nil and the condition.

+

Description:

+

+ignore-errors is used to prevent conditions of type error from causing entry into the debugger.

+Specifically, ignore-errors executes forms in a dynamic environment where a handler for conditions of type error has been established; if invoked, it handles such conditions by returning two values, nil and the condition that was signaled, from the ignore-errors form.

+If a normal return from the forms occurs, any values returned are returned by ignore-errors.

+

Examples:

+

+

+ (defun load-init-file (program)
+   (let ((win nil))
+     (ignore-errors ;if this fails, don't enter debugger
+       (load (merge-pathnames (make-pathname :name program :type :lisp)
+                              (user-homedir-pathname)))
+       (setq win t))
+     (unless win (format t "~&Init file failed to load.~%"))
+     win))
+ 
+ (load-init-file "no-such-program")
+>>  Init file failed to load.
+NIL
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+handler-case, Section 9.1 (Condition System Concepts)

+

Notes:

+

+

+ (ignore-errors . forms)
+
+

+ is equivalent to:

+

+ (handler-case (progn . forms)
+   (error (condition) (values nil condition)))
+
+

+Because the second return value is a condition in the exceptional case, it is common (but not required) to arrange for the second return value in the normal case to be missing or nil so that the two situations can be distinguished.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_in_pkg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_in_pkg.htm new file mode 100644 index 00000000..c47d2b12 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_in_pkg.htm @@ -0,0 +1,57 @@ + + + +CLHS: Macro IN-PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro IN-PACKAGE

+

+

Syntax:

+

+ +in-package name => package

+

+

Arguments and Values:

+

+name---a string designator; not evaluated.

+package---the package named by name.

+

Description:

+

+Causes the the package named by name to become the current package---that is, the value of *package*. If no such package already exists, an error of type package-error is signaled.

+Everything in-package does is also performed at compile time if the call appears as a top level form.

+

Examples: None. +

+

Side Effects:

+

+The variable *package* is assigned. If the in-package form is a top level form, this assignment also occurs at compile time.

+

Affected By: None. +

+

Exceptional Situations:

+

+An error of type package-error is signaled if the specified package does not exist.

+

See Also:

+

+*package*

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_incf_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_incf_.htm new file mode 100644 index 00000000..519e61c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_incf_.htm @@ -0,0 +1,73 @@ + + + +CLHS: Macro INCF, DECF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro INCF, DECF

+

Syntax:

+

+ +incf place [delta-form] => new-value

+ +decf place [delta-form] => new-value

+

+

Arguments and Values:

+

+place---a place.

+delta-form---a form; evaluated to produce a delta. The default is 1.

+delta---a number.

+new-value---a number.

+

Description:

+

+incf and decf are used for incrementing and decrementing the value of place, respectively.

+The delta is added to (in the case of incf) or subtracted from (in the case of decf) the number in place and the result is stored in place.

+Any necessary type conversions are performed automatically.

+ For information about the evaluation of subforms of places, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+

Examples:

+ +

+ (setq n 0)
+ (incf n) =>  1      
+ n =>  1
+ (decf n 3) =>  -2   
+ n =>  -2
+ (decf n -5) =>  3      
+ (decf n) =>  2      
+ (incf n 0.5) =>  2.5
+ (decf n) =>  1.5
+ n =>  1.5
+
+

+

Side Effects:

+

+Place is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

++, -, 1+, 1-, setf

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_lambda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_lambda.htm new file mode 100644 index 00000000..d2ecf239 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_lambda.htm @@ -0,0 +1,72 @@ + + + +CLHS: Macro LAMBDA + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro LAMBDA

+

Syntax:

+

+ +lambda lambda-list [[declaration* | documentation]] form* => function

+

+

Arguments and Values:

+

+lambda-list---an ordinary lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+form---a form.

+function---a function.

+

Description:

+

+Provides a shorthand notation for a function special form involving a lambda expression such that:

+

+    (lambda lambda-list [[declaration* | documentation]] form*)
+ ==  (function (lambda lambda-list [[declaration* | documentation]] form*))
+ ==  #'(lambda lambda-list [[declaration* | documentation]] form*)
+
+

+

Examples:

+

+

+ (funcall (lambda (x) (+ x 3)) 4) =>  7
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+lambda (symbol)

+

Notes:

+

+This macro could be implemented by:

+

+(defmacro lambda (&whole form &rest bvl-decls-and-body)
+  (declare (ignore bvl-decls-and-body))
+  `#',form)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop.htm new file mode 100644 index 00000000..69e478ce --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop.htm @@ -0,0 +1,225 @@ + + + +CLHS: Macro LOOP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro LOOP

+

+

Syntax:

+

+The ``simple'' loop form:

+ +loop compound-form* => result*

+

+The ``extended'' loop form:

+ +loop [name-clause] {variable-clause}* {main-clause}* => result*

+

+

+name-clause::= named name 
+
+ 
+variable-clause::= with-clause | initial-final | for-as-clause 
+
+ 
+with-clause::= with var1 [type-spec] [= form1] {and var2 [type-spec] [= form2]}* 
+
+ 
+main-clause::= unconditional | accumulation | conditional | termination-test | initial-final 
+
+ 
+initial-final::= initially compound-form+ | finally compound-form+ 
+
+ 
+unconditional::= {do | doing} compound-form+ | return {form | it} 
+
+ 
+accumulation::= list-accumulation | numeric-accumulation 
+
+ 
+list-accumulation::= {collect | collecting | append | appending | nconc | nconcing} {form | it}  
+                     [into simple-var] 
+
+ 
+numeric-accumulation::= {count | counting | sum | summing | } 
+                         maximize | maximizing | minimize | minimizing {form | it} 
+                        [into simple-var] [type-spec] 
+
+ 
+conditional::= {if | when | unless} form selectable-clause {and selectable-clause}*  
+               [else selectable-clause {and selectable-clause}*]  
+               [end] 
+
+ 
+selectable-clause::= unconditional | accumulation | conditional 
+
+ 
+termination-test::= while form | until form | repeat form | always form | never form | thereis form 
+
+ 
+for-as-clause::= {for | as} for-as-subclause {and for-as-subclause}* 
+
+ 
+for-as-subclause::= for-as-arithmetic | for-as-in-list | for-as-on-list | for-as-equals-then | 
+                    for-as-across | for-as-hash | for-as-package 
+
+ 
+for-as-arithmetic::= var [type-spec] for-as-arithmetic-subclause 
+
+ 
+for-as-arithmetic-subclause::= arithmetic-up | arithmetic-downto | arithmetic-downfrom 
+
+ 
+arithmetic-up::= [[{from | upfrom} form1 |   {to | upto | below} form2 |   by form3]]+ 
+
+ 
+arithmetic-downto::= [[{{from form1}}1  |   {{{downto | above} form2}}1  |   by form3]] 
+
+ 
+arithmetic-downfrom::= [[{{downfrom form1}}1  |   {to | downto | above} form2 |   by form3]] 
+
+ 
+for-as-in-list::= var [type-spec] in form1 [by step-fun] 
+
+ 
+for-as-on-list::= var [type-spec] on form1 [by step-fun] 
+
+ 
+for-as-equals-then::= var [type-spec] = form1 [then form2] 
+
+ 
+for-as-across::= var [type-spec] across vector 
+
+ 
+for-as-hash::= var [type-spec] being {each | the}  
+               {{hash-key | hash-keys} {in | of} hash-table  
+                [using (hash-value other-var)] |  
+                {hash-value | hash-values} {in | of} hash-table  
+                [using (hash-key other-var)]} 
+
+ 
+for-as-package::= var [type-spec] being {each | the}  
+                  {symbol | symbols | 
+                   present-symbol | present-symbols | 
+                   external-symbol | external-symbols} 
+                  [{in | of} package] 
+
+ 
+type-spec::= simple-type-spec | destructured-type-spec 
+
+ 
+simple-type-spec::= fixnum | float | t | nil 
+
+ 
+destructured-type-spec::= of-type d-type-spec 
+
+ 
+d-type-spec::= type-specifier | (d-type-spec . d-type-spec) 
+
+ 
+var::= d-var-spec 
+
+ 
+var1::= d-var-spec 
+
+ 
+var2::= d-var-spec 
+
+ 
+other-var::= d-var-spec 
+
+ 
+d-var-spec::= simple-var | nil | (d-var-spec . d-var-spec) 
+
+

+

Arguments and Values:

+

+compound-form---a compound form.

+name---a symbol.

+simple-var---a symbol (a variable name).

+form, form1, form2, form3---a form.

+ step-fun---a form that evaluates to a function of one argument.

+vector---a form that evaluates to a vector.

+hash-table---a form that evaluates to a hash table.

+package---a form that evaluates to a package designator.

+type-specifier---a type specifier. This might be either an atomic type specifier or a compound type specifier, which introduces some additional complications to proper parsing in the face of destructuring; for further information, see Section 6.1.1.7 (Destructuring).

+result---an object.

+

+

Description:

+

+For details, see Section 6.1 (The LOOP Facility).

+

Examples:

+

+

+;; An example of the simple form of LOOP.
+ (defun sqrt-advisor ()
+   (loop (format t "~&Number: ")
+         (let ((n (parse-integer (read-line) :junk-allowed t)))
+           (when (not n) (return))
+           (format t "~&The square root of ~D is ~D.~%" n (sqrt n)))))
+=>  SQRT-ADVISOR
+ (sqrt-advisor)
+>>  Number: 5<NEWLINE>
+>>  The square root of 5 is 2.236068.
+>>  Number: 4<NEWLINE>
+>>  The square root of 4 is 2.
+>>  Number: done<NEWLINE>
+=>  NIL
+
+;; An example of the extended form of LOOP.
+ (defun square-advisor ()
+   (loop as n = (progn (format t "~&Number: ")
+                       (parse-integer (read-line) :junk-allowed t))
+         while n
+         do (format t "~&The square of ~D is ~D.~%" n (* n n))))
+=>  SQUARE-ADVISOR
+ (square-advisor)
+>>  Number: 4<NEWLINE>
+>>  The square of 4 is 16.
+>>  Number: 23<NEWLINE>
+>>  The square of 23 is 529.
+>>  Number: done<NEWLINE>
+=>  NIL
+
+;; Another example of the extended form of LOOP.
+ (loop for n from 1 to 10
+       when (oddp n)
+         collect n)
+=>  (1 3 5 7 9)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+do, dolist, dotimes, return, go, throw, Section 6.1.1.7 (Destructuring)

+

Notes:

+

+Except that loop-finish cannot be used within a simple loop form, a simple loop form is related to an extended loop form in the following way:

+

+ (loop compound-form*) ==  (loop do compound-form*)
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop_f.htm new file mode 100644 index 00000000..ac3be030 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_loop_f.htm @@ -0,0 +1,93 @@ + + + +CLHS: Local Macro LOOP-FINISH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Local Macro LOOP-FINISH

+

Syntax:

+

+ +loop-finish <no arguments> =>|

+

+

Description:

+

+The loop-finish macro can be used lexically within an extended loop form to terminate that form ``normally.'' That is, it transfers control to the loop epilogue of the lexically innermost extended loop form. This permits execution of any finally clause (for effect) and the return of any accumulated result.

+

Examples:

+

+

+;; Terminate the loop, but return the accumulated count.
+ (loop for i in '(1 2 3 stop-here 4 5 6)
+       when (symbolp i) do (loop-finish)
+       count i)
+=>  3
+ 
+;; The preceding loop is equivalent to:
+ (loop for i in '(1 2 3 stop-here 4 5 6)
+       until (symbolp i)
+       count i)
+=>  3
+
+;; While LOOP-FINISH can be used can be used in a variety of 
+;; situations it is really most needed in a situation where a need
+;; to exit is detected at other than the loop's `top level'
+;; (where UNTIL or WHEN often work just as well), or where some 
+;; computation must occur between the point where a need to exit is
+;; detected and the point where the exit actually occurs.  For example:
+ (defun tokenize-sentence (string)
+   (macrolet ((add-word (wvar svar)
+                `(when ,wvar
+                   (push (coerce (nreverse ,wvar) 'string) ,svar)
+                   (setq ,wvar nil))))
+     (loop with word = '() and sentence = '() and endpos = nil
+           for i below (length string)
+           do (let ((char (aref string i)))
+                (case char
+                  (#\Space (add-word word sentence))
+                  (#\. (setq endpos (1+ i)) (loop-finish))
+                  (otherwise (push char word))))
+           finally (add-word word sentence)
+                   (return (values (nreverse sentence) endpos)))))
+=>  TOKENIZE-SENTENCE
+ 
+ (tokenize-sentence "this is a sentence. this is another sentence.")
+=>  ("this" "is" "a" "sentence"), 19
+ 
+ (tokenize-sentence "this is a sentence")
+=>  ("this" "is" "a" "sentence"), NIL
+
+
+

+

Side Effects:

+

+Transfers control.

+

Affected By: None. +

+

Exceptional Situations:

+

+ Whether or not loop-finish is fbound in the global environment is implementation-dependent; however, the restrictions on redefinition and shadowing of loop-finish are the same as for symbols in the COMMON-LISP package which are fbound in the global environment. The consequences of attempting to use loop-finish outside of loop are undefined.

+

See Also:

+

+loop, Section 6.1 (The LOOP Facility)

+

Notes:

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_1.htm new file mode 100644 index 00000000..44cff276 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_1.htm @@ -0,0 +1,61 @@ + + + +CLHS: Macro MULTIPLE-VALUE-LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro MULTIPLE-VALUE-LIST

+

Syntax:

+

+ +multiple-value-list form => list

+

+

Arguments and Values:

+

+form---a form; evaluated as described below.

+list---a list of the values returned by form.

+

Description:

+

+multiple-value-list evaluates form and creates a list of the multiple values[2] it returns.

+

Examples:

+

+

+ (multiple-value-list (floor -3 4)) =>  (-1 1)
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+values-list, multiple-value-call

+

Notes:

+

+multiple-value-list and values-list are inverses of each other.

+

+ (multiple-value-list form) ==  (multiple-value-call #'list form)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_2.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_2.htm new file mode 100644 index 00000000..3564841b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_mult_2.htm @@ -0,0 +1,77 @@ + + + +CLHS: Macro MULTIPLE-VALUE-SETQ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro MULTIPLE-VALUE-SETQ

+

Syntax:

+

+ +multiple-value-setq vars form => result

+

+

Arguments and Values:

+

+vars---a list of symbols that are either variable names or names of symbol macros.

+form---a form.

+result---The primary value returned by the form.

+

Description:

+

+multiple-value-setq assigns values to vars.

+The form is evaluated, and each var is assigned to the corresponding value returned by that form. If there are more vars than values returned, nil is assigned to the extra vars. If there are more values than vars, the extra values are discarded.

+ If any var is the name of a symbol macro, then it is assigned as if by setf. Specifically,

+ +

+ (multiple-value-setq (symbol1 ... symboln) value-producing-form)
+
+ is defined to always behave in the same way as

+

+ (values (setf (values symbol1 ... symboln) value-producing-form))
+
+ in order that the rules for order of evaluation and side-effects be consistent with those used by setf. See Section 5.1.2.3 (VALUES Forms as Places).

+

Examples:

+

+

+ (multiple-value-setq (quotient remainder) (truncate 3.2 2)) =>  1
+ quotient =>  1
+ remainder =>  1.2
+ (multiple-value-setq (a b c) (values 1 2)) =>  1
+ a =>  1
+ b =>  2
+ c =>  NIL
+ (multiple-value-setq (a b) (values 4 5 6)) =>  4
+ a =>  4
+ b =>  5
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+setq, symbol-macrolet

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_multip.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_multip.htm new file mode 100644 index 00000000..7166a773 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_multip.htm @@ -0,0 +1,72 @@ + + + +CLHS: Macro MULTIPLE-VALUE-BIND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro MULTIPLE-VALUE-BIND

+

+

Syntax:

+

+ +multiple-value-bind (var*) values-form declaration* form*

=> result*

+

+

Arguments and Values:

+

+var---a symbol naming a variable; not evaluated.

+values-form---a form; evaluated.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+Creates new variable bindings for the vars and executes a series of forms that use these bindings.

+The variable bindings created are lexical unless special declarations are specified.

+Values-form is evaluated, and each of the vars is bound to the respective value returned by that form. If there are more vars than values returned, extra values of nil are given to the remaining vars. If there are more values than vars, the excess values are discarded. The vars are bound to the values over the execution of the forms, which make up an implicit progn. The consequences are unspecified if a type declaration is specified for a var, but the value to which that var is bound is not consistent with the type declaration.

+The scopes of the name binding and declarations do not include the values-form.

+

Examples:

+

+

+ (multiple-value-bind (f r) 
+     (floor 130 11)
+   (list f r)) =>  (11 9)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+let, multiple-value-call

+

Notes:

+

+

+ (multiple-value-bind (var*) values-form form*)
+ ==  (multiple-value-call #'(lambda (&optional var* &rest #1=#:ignore)
+                             (declare (ignore #1#))
+                             form*)
+                         values-form)
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_nth_va.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_nth_va.htm new file mode 100644 index 00000000..5bf7248e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_nth_va.htm @@ -0,0 +1,71 @@ + + + +CLHS: Macro NTH-VALUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro NTH-VALUE

+

+

Syntax:

+

+ +nth-value n form => object

+

+

Arguments and Values:

+

+n---a non-negative integer; evaluated.

+form---a form; evaluated as described below.

+object---an object.

+

Description:

+

+Evaluates n and then form, returning as its only value the nth value yielded by form, or nil if n is greater than or equal to the number of values returned by form. (The first returned value is numbered 0.)

+

Examples:

+

+

+ (nth-value 0 (values 'a 'b)) =>  A
+ (nth-value 1 (values 'a 'b)) =>  B
+ (nth-value 2 (values 'a 'b)) =>  NIL
+ (let* ((x 83927472397238947423879243432432432)
+        (y 32423489732)
+        (a (nth-value 1 (floor x y)))
+        (b (mod x y)))
+   (values a b (= a b)))
+=>  3332987528, 3332987528, true
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+multiple-value-list, nth

+

Notes:

+

+Operationally, the following relationship is true, although nth-value might be more efficient in some implementations because, for example, some consing might be avoided.

+

+ (nth-value n form) ==  (nth n (multiple-value-list form))
+
+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_or.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_or.htm new file mode 100644 index 00000000..2f42d235 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_or.htm @@ -0,0 +1,68 @@ + + + +CLHS: Macro OR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro OR

+

Syntax:

+

+ +or form* => results*

+

+

Arguments and Values:

+

+form---a form.

+results---the values or primary value (see below) resulting from the evaluation of the last form executed or nil.

+

Description:

+

+or evaluates each form, one at a time, from left to right. The evaluation of all forms terminates when a form evaluates to true (i.e., something other than nil).

+If the evaluation of any form other than the last returns a primary value that is true, or immediately returns that value (but no additional values) without evaluating the remaining forms. If every form but the last returns false as its primary value, or returns all values returned by the last form. If no forms are supplied, or returns nil.

+

Examples:

+

+

+ (or) =>  NIL 
+ (setq temp0 nil temp1 10 temp2 20 temp3 30) =>  30
+ (or temp0 temp1 (setq temp2 37)) =>  10
+ temp2 =>  20
+ (or (incf temp1) (incf temp2) (incf temp3)) =>  11
+ temp1 =>  11
+ temp2 =>  20
+ temp3 =>  30
+ (or (values) temp1) =>  11
+ (or (values temp1 temp2) temp3) =>  11
+ (or temp0 (values temp1 temp2)) =>  11, 20
+ (or (values temp0 temp1) (values temp2 temp3)) =>  20, 30
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+and, some, unless

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pop.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pop.htm new file mode 100644 index 00000000..92942544 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pop.htm @@ -0,0 +1,68 @@ + + + +CLHS: Macro POP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro POP

+

Syntax:

+

+ +pop place => element

+

+

Arguments and Values:

+

+ place---a place, the value of which is a list (possibly, but necessarily, a dotted list or circular list).

+element---an object (the car of the contents of place).

+

Description:

+

+pop reads the value of place, remembers the car of the list which was retrieved, writes the cdr of the list back into the place, and finally yields the car of the originally retrieved list.

+ For information about the evaluation of subforms of place, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+

Examples:

+

+

+ (setq stack '(a b c)) =>  (A B C)
+ (pop stack) =>  A  
+ stack =>  (B C)
+ (setq llst '((1 2 3 4))) =>  ((1 2 3 4))
+ (pop (car llst)) =>  1
+ llst =>  ((2 3 4))
+
+

+

Side Effects:

+

+The contents of place are modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+push, pushnew, Section 5.1 (Generalized Reference)

+

Notes:

+

+The effect of (pop place) is roughly equivalent to

+

+ (prog1 (car place) (setf place (cdr place)))
+
+ except that the latter would evaluate any subforms of place three times, while pop evaluates them only once.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_ex.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_ex.htm new file mode 100644 index 00000000..96034bc5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_ex.htm @@ -0,0 +1,54 @@ + + + +CLHS: Local Macro PPRINT-EXIT-IF-LIST-EXHAUSTED + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Local Macro PPRINT-EXIT-IF-LIST-EXHAUSTED

+

+

Syntax:

+

+ +pprint-exit-if-list-exhausted <no arguments> => nil

+

+

Arguments and Values: None. +

+

Description:

+

+Tests whether or not the list passed to the lexically current logical block has been exhausted; see Section 22.2.1.1 (Dynamic Control of the Arrangement of Output). If this list has been reduced to nil, pprint-exit-if-list-exhausted terminates the execution of the lexically current logical block except for the printing of the suffix. Otherwise pprint-exit-if-list-exhausted returns nil.

+ Whether or not pprint-exit-if-list-exhausted is fbound in the global environment is implementation-dependent; however, the restrictions on redefinition and shadowing of pprint-exit-if-list-exhausted are the same as for symbols in the COMMON-LISP package which are fbound in the global environment. The consequences of attempting to use pprint-exit-if-list-exhausted outside of pprint-logical-block are undefined.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+An error is signaled (at macro expansion time or at run time) if pprint-exit-if-list-exhausted is used anywhere other than lexically within a call on pprint-logical-block. Also, the consequences of executing pprint-if-list-exhausted outside of the dynamic extent of the pprint-logical-block which lexically contains it are undefined.

+

See Also:

+

+pprint-logical-block, pprint-pop.

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_lo.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_lo.htm new file mode 100644 index 00000000..aa4cf94a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_lo.htm @@ -0,0 +1,76 @@ + + + +CLHS: Macro PPRINT-LOGICAL-BLOCK + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PPRINT-LOGICAL-BLOCK

+

+

+

Syntax:

+

+ +pprint-logical-block (stream-symbol object &key prefix per-line-prefix suffix) declaration* form*

=> nil

+

+

Arguments and Values:

+

+stream-symbol---a stream variable designator.

+object---an object; evaluated.

+:prefix---a string; evaluated. Complicated defaulting behavior; see below.

+:per-line-prefix---a string; evaluated. Complicated defaulting behavior; see below.

+:suffix---a string; evaluated. The default is the null string.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+

Description:

+

+Causes printing to be grouped into a logical block.

+The logical block is printed to the stream that is the value of the variable denoted by stream-symbol. During the execution of the forms, that variable is bound to a pretty printing stream that supports decisions about the arrangement of output and then forwards the output to the destination stream. All the standard printing functions (e.g., write, princ, and terpri) can be used to print output to the pretty printing stream. All and only the output sent to this pretty printing stream is treated as being in the logical block.

+The prefix specifies a prefix to be printed before the beginning of the logical block. The per-line-prefix specifies a prefix that is printed before the block and at the beginning of each new line in the block. The :prefix and :pre-line-prefix arguments are mutually exclusive. If neither :prefix nor :per-line-prefix is specified, a prefix of the null string is assumed.

+The suffix specifies a suffix that is printed just after the logical block.

+The object is normally a list that the body forms are responsible for printing. If object is not a list, it is printed using write. (This makes it easier to write printing functions that are robust in the face of malformed arguments.) If *print-circle* is non-nil and object is a circular (or shared) reference to a cons, then an appropriate ``#n#'' marker is printed. (This makes it easy to write printing functions that provide full support for circularity and sharing abbreviation.) If *print-level* is not nil and the logical block is at a dynamic nesting depth of greater than *print-level* in logical blocks, ``#'' is printed. (This makes easy to write printing functions that provide full support for depth abbreviation.)

+If either of the three conditions above occurs, the indicated output is printed on stream-symbol and the body forms are skipped along with the printing of the :prefix and :suffix. (If the body forms are not to be responsible for printing a list, then the first two tests above can be turned off by supplying nil for the object argument.)

+In addition to the object argument of pprint-logical-block, the arguments of the standard printing functions (such as write, print, prin1, and pprint, as well as the arguments of the standard format directives such as ~A, ~S, (and ~W) are all checked (when necessary) for circularity and sharing. However, such checking is not applied to the arguments of the functions write-line, write-string, and write-char or to the literal text output by format. A consequence of this is that you must use one of the latter functions if you want to print some literal text in the output that is not supposed to be checked for circularity or sharing.

+The body forms of a pprint-logical-block form must not perform any side-effects on the surrounding environment; for example, no variables must be assigned which have not been bound within its scope.

+ The pprint-logical-block macro may be used regardless of the value of *print-pretty*.

+

Examples: None. +

+

Side Effects: None. +

+

Affected By:

+

+*print-circle*, *print-level*.

+

Exceptional Situations:

+

+An error of type type-error is signaled if any of the :suffix, :prefix, or :per-line-prefix is supplied but does not evaluate to a string.

+An error is signaled if :prefix and :pre-line-prefix are both used.

+pprint-logical-block and the pretty printing stream it creates have dynamic extent. The consequences are undefined if, outside of this extent, output is attempted to the pretty printing stream it creates.

+It is also unspecified what happens if, within this extent, any output is sent directly to the underlying destination stream.

+

See Also:

+

+pprint-pop, pprint-exit-if-list-exhausted, Section 22.3.5.2 (Tilde Less-Than-Sign: Logical Block)

+

Notes:

+

+ One reason for using the pprint-logical-block macro when the value of *print-pretty* is nil would be to allow it to perform checking for dotted lists, as well as (in conjunction with pprint-pop) checking for *print-level* or *print-length* being exceeded.

+Detection of circularity and sharing is supported by the pretty printer by in essence performing requested output twice. On the first pass, circularities and sharing are detected and the actual outputting of characters is suppressed. On the second pass, the appropriate ``#n='' and ``#n#'' markers are inserted and characters are output. This is why the restriction on side-effects is necessary. Obeying this restriction is facilitated by using pprint-pop, instead of an ordinary pop when traversing a list being printed by the body forms of the pprint-logical-block form.)

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_po.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_po.htm new file mode 100644 index 00000000..b1574771 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_ppr_po.htm @@ -0,0 +1,65 @@ + + + +CLHS: Local Macro PPRINT-POP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Local Macro PPRINT-POP

+

+

Syntax:

+

+ +pprint-pop <no arguments> => object

+

+

Arguments and Values:

+

+object---an element of the list being printed in the lexically current logical block, or nil.

+

Description:

+

+Pops one element from the list being printed in the lexically current logical block, obeying *print-length* and *print-circle* as described below.

+Each time pprint-pop is called, it pops the next value off the list passed to the lexically current logical block and returns it. However, before doing this, it performs three tests:

+

  • If the remaining `list' is not a list, ``. '' is printed followed by the remaining `list.' (This makes it easier to write printing functions that are robust in the face of malformed arguments.)

    +

  • If *print-length* is non-nil, and pprint-pop has already been called *print-length* times within the immediately containing logical block, ``...'' is printed. (This makes it easy to write printing functions that properly handle *print-length*.)

    +

  • If *print-circle* is non-nil, and the remaining list is a circular (or shared) reference, then ``. '' is printed followed by an appropriate ``#n#'' marker. (This catches instances of cdr circularity and sharing in lists.)

+If either of the three conditions above occurs, the indicated output is printed on the pretty printing stream created by the immediately containing pprint-logical-block and the execution of the immediately containing pprint-logical-block is terminated except for the printing of the suffix.

+If pprint-logical-block is given a `list' argument of nil---because it is not processing a list---pprint-pop can still be used to obtain support for *print-length*. In this situation, the first and third tests above are disabled and pprint-pop always returns nil. See Section 22.2.2 (Examples of using the Pretty Printer)---specifically, the pprint-vector example.

+ Whether or not pprint-pop is fbound in the global environment is implementation-dependent; however, the restrictions on redefinition and shadowing of pprint-pop are the same as for symbols in the COMMON-LISP package which are fbound in the global environment. The consequences of attempting to use pprint-pop outside of pprint-logical-block are undefined.

+

Examples: None. +

+

Side Effects:

+

+Might cause output to the pretty printing stream associated with the lexically current logical block.

+

Affected By:

+

+*print-length*, *print-circle*.

+

Exceptional Situations:

+

+An error is signaled (either at macro expansion time or at run time) if a usage of pprint-pop occurs where there is no lexically containing pprint-logical-block form.

+The consequences are undefined if pprint-pop is executed outside of the dynamic extent of this pprint-logical-block.

+

See Also:

+

+pprint-exit-if-list-exhausted, pprint-logical-block.

+

Notes:

+

+It is frequently a good idea to call pprint-exit-if-list-exhausted before calling pprint-pop.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pr_unr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pr_unr.htm new file mode 100644 index 00000000..165cd87f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pr_unr.htm @@ -0,0 +1,66 @@ + + + +CLHS: Macro PRINT-UNREADABLE-OBJECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PRINT-UNREADABLE-OBJECT

+

Syntax:

+

+ +print-unreadable-object (object stream &key type identity) form* => nil

+

+

Arguments and Values:

+

+object---an object; evaluated.

+stream---a stream designator; evaluated.

+type---a generalized boolean; evaluated.

+identity---a generalized boolean; evaluated.

+forms---an implicit progn.

+

Description:

+

+Outputs a printed representation of object on stream, beginning with ``#<'' and ending with ``>''. Everything output to stream by the body forms is enclosed in the the angle brackets. If type is true, the output from forms is preceded by a brief description of the object's type and a space character. If identity is true, the output from forms is followed by a space character and a representation of the object's identity, typically a storage address.

+If either type or identity is not supplied, its value is false. It is valid to omit the body forms. If type and identity are both true and there are no body forms, only one space character separates the type and the identity.

+

Examples:

+

+;; Note that in this example, the precise form of the output ;; is implementation-dependent.

+

+ (defmethod print-object ((obj airplane) stream)
+   (print-unreadable-object (obj stream :type t :identity t)
+     (princ (tail-number obj) stream)))
+
+ (prin1-to-string my-airplane)
+=>  "#<Airplane NW0773 36000123135>"
+OR=>  "#<FAA:AIRPLANE NW0773 17>"
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+If *print-readably* is true, print-unreadable-object signals an error of type print-not-readable without printing anything.

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog1c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog1c.htm new file mode 100644 index 00000000..871fee0a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog1c.htm @@ -0,0 +1,91 @@ + + + +CLHS: Macro PROG1, PROG2 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PROG1, PROG2

+

Syntax:

+

+ +prog1 first-form form* => result-1

+ +prog2 first-form second-form form* => result-2

+

+

Arguments and Values:

+

+first-form---a form; evaluated as described below.

+second-form---a form; evaluated as described below.

+forms---an implicit progn; evaluated as described below.

+result-1---the primary value resulting from the evaluation of first-form.

+result-2---the primary value resulting from the evaluation of second-form.

+

Description:

+

+prog1 evaluates first-form and then forms, yielding as its only value the primary value yielded by first-form.

+prog2 evaluates first-form, then second-form, and then forms, yielding as its only value the primary value yielded by first-form.

+

Examples:

+

+

+ (setq temp 1) =>  1
+ (prog1 temp (print temp) (incf temp) (print temp))
+>>  1
+>>  2
+=>  1
+ (prog1 temp (setq temp nil)) =>  2
+ temp =>  NIL
+ (prog1 (values 1 2 3) 4) =>  1 
+ (setq temp (list 'a 'b 'c))
+ (prog1 (car temp) (setf (car temp) 'alpha)) =>  A
+ temp =>  (ALPHA B C)
+ (flet ((swap-symbol-values (x y)
+          (setf (symbol-value x) 
+                (prog1 (symbol-value y)
+                       (setf (symbol-value y) (symbol-value x))))))
+   (let ((*foo* 1) (*bar* 2))
+     (declare (special *foo* *bar*))
+     (swap-symbol-values '*foo* '*bar*)
+     (values *foo* *bar*)))
+=>  2, 1
+ (setq temp 1) =>  1
+ (prog2 (incf temp) (incf temp) (incf temp)) =>  3
+ temp =>  4
+ (prog2 1 (values 2 3 4) 5) =>  2
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+multiple-value-prog1, progn

+

Notes:

+

+prog1 and prog2 are typically used to evaluate one or more forms with side effects and return a value that must be computed before some or all of the side effects happen.

+

+ (prog1 form*) ==  (values (multiple-value-prog1 form*))
+ (prog2 form1 form*) ==  (let () form1 (prog1 form*))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog_.htm new file mode 100644 index 00000000..72951916 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_prog_.htm @@ -0,0 +1,128 @@ + + + +CLHS: Macro PROG, PROG* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PROG, PROG*

+

+

Syntax:

+

+ +prog ({var | (var [init-form])}*) declaration* {tag | statement}*

=> result*

+

+ +prog* ({var | (var [init-form])}*) declaration* {tag | statement}*

=> result*

+

+

Arguments and Values:

+

+var---variable name.

+init-form---a form.

+declaration---a declare expression; not evaluated.

+tag---a go tag; not evaluated.

+statement---a compound form; evaluated as described below.

+results---nil if a normal return occurs, or else, if an explicit return occurs, the values that were transferred.

+

Description:

+

+Three distinct operations are performed by prog and prog*: they bind local variables, they permit use of the return statement, and they permit use of the go statement. A typical prog looks like this:

+

+ (prog (var1 var2 (var3 init-form-3) var4 (var5 init-form-5))
+       declaration*
+       statement1
+  tag1
+       statement2
+       statement3
+       statement4
+  tag2
+       statement5
+       ...
+       )
+
+

+For prog, init-forms are evaluated first, in the order in which they are supplied. The vars are then bound to the corresponding values in parallel. If no init-form is supplied for a given var, that var is bound to nil.

+The body of prog is executed as if it were a tagbody form; the go statement can be used to transfer control to a tag. Tags label statements.

+prog implicitly establishes a block named nil around the entire prog form, so that return can be used at any time to exit from the prog form.

+The difference between prog* and prog is that in prog* the binding and initialization of the vars is done sequentially, so that the init-form for each one can use the values of previous ones.

+

Examples:

+ +

+(prog* ((y z) (x (car y)))
+       (return x))
+
+ returns the car of the value of z.

+

+ (setq a 1) =>  1
+ (prog ((a 2) (b a)) (return (if (= a b) '= '/=))) =>  /=
+ (prog* ((a 2) (b a)) (return (if (= a b) '= '/=))) =>  =
+ (prog () 'no-return-value) =>  NIL
+
+ +
+ (defun king-of-confusion (w)
+   "Take a cons of two lists and make a list of conses.
+    Think of this function as being like a zipper."
+   (prog (x y z)          ;Initialize x, y, z to NIL
+        (setq y (car w) z (cdr w))
+    loop
+        (cond ((null y) (return x))
+              ((null z) (go err)))
+    rejoin
+        (setq x (cons (cons (car y) (car z)) x))
+        (setq y (cdr y) z (cdr z))
+        (go loop)
+    err
+        (cerror "Will self-pair extraneous items"
+                "Mismatch - gleep!  ~S" y)
+        (setq z y)
+        (go rejoin))) =>  KING-OF-CONFUSION 
+
+ This can be accomplished more perspicuously as follows:

+

+ (defun prince-of-clarity (w)
+   "Take a cons of two lists and make a list of conses.
+    Think of this function as being like a zipper."
+   (do ((y (car w) (cdr y))
+        (z (cdr w) (cdr z))
+        (x '() (cons (cons (car y) (car z)) x)))
+       ((null y) x)
+     (when (null z)
+       (cerror "Will self-pair extraneous items"
+              "Mismatch - gleep!  ~S" y)
+       (setq z y)))) =>  PRINCE-OF-CLARITY 
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+block, let, tagbody, go, return, Section 3.1 (Evaluation)

+

Notes:

+ prog can be explained in terms of block, let, and tagbody as follows:

+

+ (prog variable-list declaration . body)
+    ==  (block nil (let variable-list declaration (tagbody . body)))
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_psetq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_psetq.htm new file mode 100644 index 00000000..acf5eba9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_psetq.htm @@ -0,0 +1,93 @@ + + + +CLHS: Macro PSETQ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PSETQ

+

Syntax:

+

+ +psetq {pair}* => nil

+

+

+pair::= var form 
+
+

+

Pronunciation:

+

+psetq: [;pee'set,kyoo]

+

Arguments and Values:

+

+var---a symbol naming a variable other than a constant variable.

+form---a form.

+

Description:

+

+Assigns values to variables.

+This is just like setq, except that the assignments happen ``in parallel.'' That is, first all of the forms are evaluated, and only then are the variables set to the resulting values. In this way, the assignment to one variable does not affect the value computation of another in the way that would occur with setq's sequential assignment.

+ If any var refers to a binding made by symbol-macrolet, then that var is treated as if psetf (not psetq) had been used.

+

Examples:

+

+

+ ;; A simple use of PSETQ to establish values for variables.
+ ;; As a matter of style, many programmers would prefer SETQ 
+ ;; in a simple situation like this where parallel assignment
+ ;; is not needed, but the two have equivalent effect.
+ (psetq a 1 b 2 c 3) =>  NIL
+ a =>  1
+ b =>  2
+ c =>  3
+
+ ;; Use of PSETQ to update values by parallel assignment.
+ ;; The effect here is very different than if SETQ had been used.
+ (psetq a (1+ b) b (1+ a) c (+ a b)) =>  NIL
+ a =>  3
+ b =>  2
+ c =>  3
+
+ ;; Use of PSETQ on a symbol macro.
+ (let ((x (list 10 20 30)))
+   (symbol-macrolet ((y (car x)) (z (cadr x)))
+     (psetq y (1+ z) z (1+ y))
+     (list x y z)))
+=>  ((21 11 30) 21 11)
+
+ ;; Use of parallel assignment to swap values of A and B.
+ (let ((a 1) (b 2))
+   (psetq a b  b a)
+   (values a b))
+=>  2, 1
+
+

+

Side Effects:

+

+The values of forms are assigned to vars.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+psetf, setq

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pshnew.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pshnew.htm new file mode 100644 index 00000000..e861d737 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_pshnew.htm @@ -0,0 +1,85 @@ + + + +CLHS: Macro PUSHNEW + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PUSHNEW

+

Syntax:

+

+ +pushnew item place &key key test test-not

=> new-place-value

+

+

Arguments and Values:

+

+item---an object.

+place---a place, the value of which is a proper list.

+test---a designator for a function of two arguments that returns a generalized boolean.

+test-not---a designator for a function of two arguments that returns a generalized boolean.

+key---a designator for a function of one argument, or nil.

+new-place-value---a list (the new value of place).

+

Description:

+

+pushnew tests whether item is the same as any existing element of the list stored in place. If item is not, it is prepended to the list, and the new list is stored in place.

+pushnew returns the new list that is stored in place.

+Whether or not item is already a member of the list that is in place is determined by comparisons using :test or :test-not. The first argument to the :test or :test-not function is item; the second argument is an element of the list in place as returned by the :key function (if supplied).

+If :key is supplied, it is used to extract the part to be tested from both item and the list element, as for adjoin.

+The argument to the :key function is an element of the list stored in place. The :key function typically returns part part of the element of the list. If :key is not supplied or nil, the list element is used.

+ For information about the evaluation of subforms of place, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+ It is implementation-dependent whether or not pushnew actually executes the storing form for its place in the situation where the item is already a member of the list held by place.

+

Examples:

+ +

+ (setq x '(a (b c) d)) =>  (A (B C) D)
+ (pushnew 5 (cadr x)) =>  (5 B C)   
+ x =>  (A (5 B C) D)
+ (pushnew 'b (cadr x)) =>  (5 B C)  
+ x =>  (A (5 B C) D)
+ (setq lst '((1) (1 2) (1 2 3))) =>  ((1) (1 2) (1 2 3))
+ (pushnew '(2) lst) =>  ((2) (1) (1 2) (1 2 3))
+ (pushnew '(1) lst) =>  ((1) (2) (1) (1 2) (1 2 3))
+ (pushnew '(1) lst :test 'equal) =>  ((1) (2) (1) (1 2) (1 2 3))
+ (pushnew '(1) lst :key #'car) =>  ((1) (2) (1) (1 2) (1 2 3)) 
+
+

+

Side Effects:

+

+The contents of place may be modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+push, adjoin, Section 5.1 (Generalized Reference)

+

Notes:

+

+The effect of +

+ (pushnew item place :test p)
+
+ is roughly equivalent to +
+ (setf place (adjoin item place :test p))
+
+ except that the subforms of place are evaluated only once, and item is evaluated before place.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_push.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_push.htm new file mode 100644 index 00000000..fc5de575 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_push.htm @@ -0,0 +1,70 @@ + + + +CLHS: Macro PUSH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro PUSH

+

Syntax:

+

+ +push item place => new-place-value

+

+

Arguments and Values:

+

+item---an object.

+ place---a place, the value of which may be any object.

+new-place-value---a list (the new value of place).

+

Description:

+

+push prepends item to the list that is stored in place, stores the resulting list in place, and returns the list.

+ For information about the evaluation of subforms of place, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+

Examples:

+ +

+ (setq llst '(nil)) =>  (NIL)
+ (push 1 (car llst)) =>  (1)
+ llst =>  ((1))
+ (push 1 (car llst)) =>  (1 1)
+ llst =>  ((1 1))
+ (setq x '(a (b c) d)) =>  (A (B C) D)
+ (push 5 (cadr x)) =>  (5 B C)  
+ x =>  (A (5 B C) D)
+
+

+

Side Effects:

+

+The contents of place are modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+pop, pushnew, Section 5.1 (Generalized Reference)

+

Notes:

+ The effect of (push item place) is equivalent to

+

+ (setf place (cons item place))
+
+ except that the subforms of place are evaluated only once, and item is evaluated before place.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_remf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_remf.htm new file mode 100644 index 00000000..98dc7242 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_remf.htm @@ -0,0 +1,63 @@ + + + +CLHS: Macro REMF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro REMF

+

Syntax:

+

+ +remf place indicator => generalized-boolean

+

+

Arguments and Values:

+

+place---a place.

+indicator---an object.

+generalized-boolean---a generalized boolean.

+

Description:

+

+remf removes from the property list stored in place a property[1] with a property indicator identical to indicator. If there are multiple properties[1] with the identical key, remf only removes the first such property. remf returns false if no such property was found, or true if a property was found.

+The property indicator and the corresponding property value are removed in an undefined order by destructively splicing the property list. remf is permitted to either setf place or to setf any part, car or cdr, of the list structure held by that place.

+ For information about the evaluation of subforms of place, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+

Examples:

+

+

+ (setq x (cons () ())) =>  (NIL)
+ (setf (getf (car x) 'prop1) 'val1) =>  VAL1
+ (remf (car x) 'prop1) =>  true
+ (remf (car x) 'prop1) =>  false
+
+

+

Side Effects:

+

+The property list stored in place is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+remprop, getf

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_return.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_return.htm new file mode 100644 index 00000000..ade71d31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_return.htm @@ -0,0 +1,64 @@ + + + +CLHS: Macro RETURN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro RETURN

+

Syntax:

+

+ +return [result] =>|

+

+

Arguments and Values:

+

+result---a form; evaluated. The default is nil.

+

Description:

+

+Returns, as if by return-from, from the block named nil.

+

Examples:

+

+

+ (block nil (return) 1) =>  NIL
+ (block nil (return 1) 2) =>  1
+ (block nil (return (values 1 2)) 3) =>  1, 2
+ (block nil (block alpha (return 1) 2)) =>  1
+ (block alpha (block nil (return 1)) 2) =>  2
+ (block nil (block nil (return 1) 2)) =>  1
+
+

+

Affected By: None. +

+

Conditions: None. +

+

See Also:

+

+block, return-from, Section 3.1 (Evaluation)

+

Notes:

+

+

+ (return) ==  (return-from nil)
+ (return form) ==  (return-from nil form)
+
+

+The implicit blocks established by macros such as do are often named nil, so that return can be used to exit from such forms.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rotate.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rotate.htm new file mode 100644 index 00000000..3ed08fa4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rotate.htm @@ -0,0 +1,69 @@ + + + +CLHS: Macro ROTATEF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro ROTATEF

+

Syntax:

+

+ +rotatef place* => nil

+

+

Arguments and Values:

+

+place---a place.

+

Description:

+

+rotatef modifies the values of each place by rotating values from one place into another.

+ If a place produces more values than there are store variables, the extra values are ignored. If a place produces fewer values than there are store variables, the missing values are set to nil.

+In the form (rotatef place1 place2 ... placen), the values in place1 through placen are read and written. Values 2 through n and value 1 are then stored into place1 through placen. It is as if all the places form an end-around shift register that is rotated one place to the left, with the value of place1 being shifted around the end to placen.

+ For information about the evaluation of subforms of places, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+

Examples:

+ +

+ (let ((n 0)
+        (x (list 'a 'b 'c 'd 'e 'f 'g)))
+    (rotatef (nth (incf n) x)
+             (nth (incf n) x)
+             (nth (incf n) x))
+    x) =>  (A C D B E F G)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+define-setf-expander, defsetf, setf, shiftf, *macroexpand-hook*, Section 5.1 (Generalized Reference)

+

Notes:

+

+The effect of (rotatef place1 place2 ... placen) is roughly equivalent to

+

+ (psetf place1 place2
+        place2 place3
+        ...
+        placen place1)
+
+ except that the latter would evaluate any subforms of each place twice, whereas rotatef evaluates them once.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_bi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_bi.htm new file mode 100644 index 00000000..81912a78 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_bi.htm @@ -0,0 +1,77 @@ + + + +CLHS: Macro RESTART-BIND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro RESTART-BIND

+

Syntax:

+

+ +restart-bind ({(name function {key-val-pair}*)}) form*

=> result*

+

+

+key-val-pair::= :interactive-function interactive-function |  
+                :report-function report-function |  
+                :test-function test-function 
+
+

+

Arguments and Values:

+

+name---a symbol; not evaluated.

+function---a form; evaluated.

+forms---an implicit progn.

+interactive-function---a form; evaluated.

+report-function---a form; evaluated.

+test-function---a form; evaluated.

+results---the values returned by the forms.

+

Description:

+

+restart-bind executes the body of forms in a dynamic environment where restarts with the given names are in effect.

+If a name is nil, it indicates an anonymous restart; if a name is a non-nil symbol, it indicates a named restart.

+The function, interactive-function, and report-function are unconditionally evaluated in the current lexical and dynamic environment prior to evaluation of the body. Each of these forms must evaluate to a function.

+If invoke-restart is done on that restart, the function which resulted from evaluating function is called, in the dynamic environment of the invoke-restart, with the arguments given to invoke-restart. The function may either perform a non-local transfer of control or may return normally.

+If the restart is invoked interactively from the debugger (using invoke-restart-interactively), the arguments are defaulted by calling the function which resulted from evaluating interactive-function. That function may optionally prompt interactively on query I/O, and should return a list of arguments to be used by invoke-restart-interactively when invoking the restart.

+If a restart is invoked interactively but no interactive-function is used, then an argument list of nil is used. In that case, the function must be compatible with an empty argument list.

+If the restart is presented interactively (e.g., by the debugger), the presentation is done by calling the function which resulted from evaluating report-function. This function must be a function of one argument, a stream. It is expected to print a description of the action that the restart takes to that stream. This function is called any time the restart is printed while *print-escape* is nil.

+In the case of interactive invocation, the result is dependent on the value of :interactive-function as follows.

+

:interactive-function

+ Value is evaluated in the current lexical environment and should return a function of no arguments which constructs a list of arguments to be used by invoke-restart-interactively when invoking this restart. The function may prompt interactively using query I/O if necessary.

+

:report-function

+ Value is evaluated in the current lexical environment and should return a function of one argument, a stream, which prints on the stream a summary of the action that this restart takes. This function is called whenever the restart is reported (printed while *print-escape* is nil). If no :report-function option is provided, the manner in which the restart is reported is implementation-dependent.

+

:test-function

+ Value is evaluated in the current lexical environment and should return a function of one argument, a condition, which returns true if the restart is to be considered visible.

+

+

Side Effects: None. +

+

Affected By:

+

+*query-io*.

+

Exceptional Situations: None. +

+

See Also:

+

+restart-case, with-simple-restart

+

Notes:

+

+restart-bind is primarily intended to be used to implement restart-case and might be useful in implementing other macros. Programmers who are uncertain about whether to use restart-case or restart-bind should prefer restart-case for the cases where it is powerful enough, using restart-bind only in cases where its full generality is really needed.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_ca.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_ca.htm new file mode 100644 index 00000000..b68a3dee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_rst_ca.htm @@ -0,0 +1,203 @@ + + + +CLHS: Macro RESTART-CASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro RESTART-CASE

+

+

Syntax:

+

+ +restart-case restartable-form {clause} => result*

+

+ 

+clause::= (case-name lambda-list  
+           [[:interactive interactive-expression | :report report-expression | :test test-expression]]  
+           declaration* form*) 
+
+

+

Arguments and Values:

+

+restartable-form---a form.

+case-name---a symbol or nil.

+lambda-list---an ordinary lambda list.

+interactive-expression---a symbol or a lambda expression.

+report-expression---a string, a symbol, or a lambda expression.

+test-expression---a symbol or a lambda expression.

+declaration---a declare expression; not evaluated.

+form---a form.

+results---the values resulting from the evaluation of restartable-form, or the values returned by the last form executed in a chosen clause, or nil.

+

Description:

+

+restart-case evaluates restartable-form in a dynamic environment where the clauses have special meanings as points to which control may be transferred. If restartable-form finishes executing and returns any values, all values returned are returned by restart-case and processing has completed. While restartable-form is executing, any code may transfer control to one of the clauses (see invoke-restart). If a transfer occurs, the forms in the body of that clause is evaluated and any values returned by the last such form are returned by restart-case. In this case, the dynamic state is unwound appropriately (so that the restarts established around the restartable-form are no longer active) prior to execution of the clause.

+ If there are no forms in a selected clause, restart-case returns nil.

+If case-name is a symbol, it names this restart.

+It is possible to have more than one clause use the same case-name. In this case, the first clause with that name is found by find-restart. The other clauses are accessible using compute-restarts.

+Each arglist is an ordinary lambda list to be bound during the execution of its corresponding forms. These parameters are used by the restart-case clause to receive any necessary data from a call to invoke-restart.

+By default, invoke-restart-interactively passes no arguments and all arguments must be optional in order to accomodate interactive restarting. However, the arguments need not be optional if the :interactive keyword has been used to inform invoke-restart-interactively about how to compute a proper argument list.

+Keyword options have the following meaning.

:interactive

+The value supplied by :interactive value must be a suitable argument to function. (function value) is evaluated in the current lexical environment. It should return a function of no arguments which returns arguments to be used by invoke-restart-interactively when it is invoked. invoke-restart-interactively is called in the dynamic environment available prior to any restart attempt, and uses query I/O for user interaction.

+ If a restart is invoked interactively but no :interactive option was supplied, the argument list used in the invocation is the empty list.

+

:report

+If the value supplied by :report value is a lambda expression or a symbol, it must be acceptable to function. (function value) is evaluated in the current lexical environment. It should return a function of one argument, a stream, which prints on the stream a description of the restart. This function is called whenever the restart is printed while *print-escape* is nil.

+If value is a string, it is a shorthand for

+

+ (lambda (stream) (write-string value stream))
+
+

+ If a named restart is asked to report but no report information has been supplied, the name of the restart is used in generating default report text.

+ When *print-escape* is nil, the printer uses the report information for a restart. For example, a debugger might announce the action of typing a ``continue'' command by:

+

+ (format t "~&~S -- ~A~%" ':continue some-restart)
+
+ which might then display as something like:

+

+ :CONTINUE -- Return to command level
+
+

+The consequences are unspecified if an unnamed restart is specified but no :report option is provided.

+

:test

+The value supplied by :test value must be a suitable argument to function. (function value) is evaluated in the current lexical environment. It should return a function of one argument, the condition, that returns true if the restart is to be considered visible.

+The default for this option is equivalent to (lambda (c) (declare (ignore c)) t).

+ If the restartable-form is a list whose car is any of the symbols signal, error, cerror, or warn (or is a macro form which macroexpands into such a list), then with-condition-restarts is used implicitly to associate the indicated restarts with the condition to be signaled.

+

Examples:

+

+

+ (restart-case
+     (handler-bind ((error #'(lambda (c)
+                             (declare (ignore condition))
+                             (invoke-restart 'my-restart 7))))
+       (error "Foo."))
+   (my-restart (&optional v) v))
+=>  7
+
+ (define-condition food-error (error) ())
+=>  FOOD-ERROR
+ (define-condition bad-tasting-sundae (food-error) 
+   ((ice-cream :initarg :ice-cream :reader bad-tasting-sundae-ice-cream)
+    (sauce :initarg :sauce :reader bad-tasting-sundae-sauce)
+    (topping :initarg :topping :reader bad-tasting-sundae-topping))
+   (:report (lambda (condition stream)
+              (format stream "Bad tasting sundae with ~S, ~S, and ~S"
+                      (bad-tasting-sundae-ice-cream condition)
+                      (bad-tasting-sundae-sauce condition)
+                      (bad-tasting-sundae-topping condition)))))
+=>  BAD-TASTING-SUNDAE
+ (defun all-start-with-same-letter (symbol1 symbol2 symbol3)
+   (let ((first-letter (char (symbol-name symbol1) 0)))
+     (and (eql first-letter (char (symbol-name symbol2) 0))
+          (eql first-letter (char (symbol-name symbol3) 0)))))
+=>  ALL-START-WITH-SAME-LETTER
+ (defun read-new-value ()
+   (format t "Enter a new value: ")
+   (multiple-value-list (eval (read))))
+=>  READ-NEW-VALUE
+ (defun verify-or-fix-perfect-sundae (ice-cream sauce topping)
+   (do ()
+      ((all-start-with-same-letter ice-cream sauce topping))
+     (restart-case
+       (error 'bad-tasting-sundae
+              :ice-cream ice-cream
+              :sauce sauce
+              :topping topping)
+       (use-new-ice-cream (new-ice-cream)
+         :report "Use a new ice cream."
+         :interactive read-new-value  
+         (setq ice-cream new-ice-cream))
+       (use-new-sauce (new-sauce)
+         :report "Use a new sauce."
+         :interactive read-new-value
+         (setq sauce new-sauce))
+       (use-new-topping (new-topping)
+         :report "Use a new topping."
+         :interactive read-new-value
+         (setq topping new-topping))))
+   (values ice-cream sauce topping))
+=>  VERIFY-OR-FIX-PERFECT-SUNDAE
+ (verify-or-fix-perfect-sundae 'vanilla 'caramel 'cherry)
+>>  Error: Bad tasting sundae with VANILLA, CARAMEL, and CHERRY.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Use a new ice cream.
+>>   2: Use a new sauce.
+>>   3: Use a new topping.
+>>   4: Return to Lisp Toplevel.
+>>  Debug> :continue 1
+>>  Use a new ice cream.
+>>  Enter a new ice cream: 'chocolate
+=>  CHOCOLATE, CARAMEL, CHERRY
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+restart-bind, with-simple-restart.

+

Notes:

+

+

+ (restart-case expression
+    (name1 arglist1 ...options1... . body1)
+    (name2 arglist2 ...options2... . body2))
+
+ is essentially equivalent to

+

+ (block #1=#:g0001
+   (let ((#2=#:g0002 nil))
+        (tagbody
+        (restart-bind ((name1 #'(lambda (&rest temp)
+                                (setq #2# temp)
+                                (go #3=#:g0003))
+                          ...slightly-transformed-options1...)
+                       (name2 #'(lambda (&rest temp)
+                                (setq #2# temp)
+                                (go #4=#:g0004))
+                          ...slightly-transformed-options2...))
+        (return-from #1# expression))
+          #3# (return-from #1#
+                  (apply #'(lambda arglist1 . body1) #2#))
+          #4# (return-from #1#
+                  (apply #'(lambda arglist2 . body2) #2#)))))
+
+

+Unnamed restarts are generally only useful interactively and an interactive option which has no description is of little value. Implementations are encouraged to warn if an unnamed restart is used and no report information is provided at compilation time. At runtime, this error might be noticed when entering the debugger. Since signaling an error would probably cause recursive entry into the debugger (causing yet another recursive error, etc.) it is suggested that the debugger print some indication of such problems when they occur but not actually signal errors.

+ +

+ (restart-case (signal fred)
+   (a ...)
+   (b ...))
+ == 
+ (restart-case
+     (with-condition-restarts fred 
+                              (list (find-restart 'a) 
+                                    (find-restart 'b))
+       (signal fred))
+   (a ...)
+   (b ...))
+
+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_setf_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_setf_.htm new file mode 100644 index 00000000..0f57a95a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_setf_.htm @@ -0,0 +1,86 @@ + + + +CLHS: Macro SETF, PSETF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro SETF, PSETF

+

Syntax:

+

+ +setf {pair}* => result*

+ +psetf {pair}* => nil

+

+

+pair::= place newvalue 
+
+

+

Arguments and Values:

+

+place---a place.

+newvalue---a form.

+ results---the multiple values[2] returned by the storing form for the last place, or nil if there are no pairs.

+

Description:

+

+setf changes the value of place to be newvalue.

+(setf place newvalue) expands into an update form that stores the result of evaluating newvalue into the location referred to by place. Some place forms involve uses of accessors that take optional arguments. Whether those optional arguments are permitted by setf, or what their use is, is up to the setf expander function and is not under the control of setf. The documentation for any function that accepts &optional, &rest, or ..... key arguments and that claims to be usable with setf must specify how those arguments are treated.

+If more than one pair is supplied, the pairs are processed sequentially; that is,

+

+ (setf place-1 newvalue-1
+       place-2 newvalue-2
+       ...
+       place-N newvalue-N)
+
+ is precisely equivalent to

+

+ (progn (setf place-1 newvalue-1)
+        (setf place-2 newvalue-2)
+        ...
+        (setf place-N newvalue-N))
+
+ For psetf, if more than one pair is supplied then the assignments of new values to places are done in parallel. More precisely, all subforms (in both the place and newvalue forms) that are to be evaluated are evaluated from left to right; after all evaluations have been performed, all of the assignments are performed in an unpredictable order.

+For detailed treatment of the expansion of setf and psetf, see Section 5.1.2 (Kinds of Places).

+

Examples:

+

+

+ (setq x (cons 'a 'b) y (list 1 2 3)) =>  (1 2 3) 
+ (setf (car x) 'x (cadr y) (car x) (cdr x) y) =>  (1 X 3) 
+ x =>  (X 1 X 3) 
+ y =>  (1 X 3) 
+ (setq x (cons 'a 'b) y (list 1 2 3)) =>  (1 2 3) 
+ (psetf (car x) 'x (cadr y) (car x) (cdr x) y) =>  NIL 
+ x =>  (X 1 A 3) 
+ y =>  (1 A 3) 
+
+

+

Affected By:

+

+define-setf-expander, defsetf, *macroexpand-hook*

+

Exceptional Situations: None. +

+

See Also:

+

+define-setf-expander, defsetf, macroexpand-1, rotatef, shiftf, Section 5.1 (Generalized Reference)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_shiftf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_shiftf.htm new file mode 100644 index 00000000..14844541 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_shiftf.htm @@ -0,0 +1,94 @@ + + + +CLHS: Macro SHIFTF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro SHIFTF

+

Syntax:

+

+ +shiftf place+ newvalue => old-value-1

+

+

Arguments and Values:

+

+place---a place.

+newvalue---a form; evaluated.

+old-value-1---an object (the old value of the first place).

+

Description:

+

+shiftf modifies the values of each place by storing newvalue into the last place, and shifting the values of the second through the last place into the remaining places.

+ If newvalue produces more values than there are store variables, the extra values are ignored. If newvalue produces fewer values than there are store variables, the missing values are set to nil.

+In the form (shiftf place1 place2 ... placen newvalue), the values in place1 through placen are read and saved, and newvalue is evaluated, for a total of n+1 values in all. Values 2 through n+1 are then stored into place1 through placen, respectively. It is as if all the places form a shift register; the newvalue is shifted in from the right, all values shift over to the left one place, and the value shifted out of place1 is returned.

+ For information about the evaluation of subforms of places, see Section 5.1.1.1 (Evaluation of Subforms to Places).

+

Examples:

+

+

+ (setq x (list 1 2 3) y 'trash) =>  TRASH
+ (shiftf y x (cdr x) '(hi there)) =>  TRASH
+ x =>  (2 3)
+ y =>  (1 HI THERE)
+
+ (setq x (list 'a 'b 'c)) =>  (A B C)
+ (shiftf (cadr x) 'z) =>  B
+ x =>  (A Z C)
+ (shiftf (cadr x) (cddr x) 'q) =>  Z
+ x =>  (A (C) . Q)
+ (setq n 0) =>  0
+ (setq x (list 'a 'b 'c 'd)) =>  (A B C D)
+ (shiftf (nth (setq n (+ n 1)) x) 'z) =>  B
+ x =>  (A Z C D)
+
+

+

Affected By:

+

+define-setf-expander, defsetf, *macroexpand-hook*

+

Exceptional Situations: None. +

+

See Also:

+

+setf, rotatef, Section 5.1 (Generalized Reference)

+

Notes:

+

+The effect of (shiftf place1 place2 ... placen newvalue) is roughly equivalent to

+

+ (let ((var1 place1)
+       (var2 place2)
+       ...
+       (varn placen)
+       (var0 newvalue))
+   (setf place1 var2)
+   (setf place2 var3)
+   ...
+   (setf placen var0)
+   var1)
+
+ except that the latter would evaluate any subforms of each place twice, whereas shiftf evaluates them once. For example,

+

+ (setq n 0) =>  0
+ (setq x (list 'a 'b 'c 'd)) =>  (A B C D)
+ (prog1 (nth (setq n (+ n 1)) x)
+        (setf (nth (setq n (+ n 1)) x) 'z)) =>  B
+ x =>  (A B Z D)
+
+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_step.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_step.htm new file mode 100644 index 00000000..b9b17f1f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_step.htm @@ -0,0 +1,55 @@ + + + +CLHS: Macro STEP + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro STEP

+

Syntax:

+

+ +step form => result*

+

+

Arguments and Values:

+

+form---a form; evaluated as described below.

+results---the values returned by the form.

+

Description:

+

+step implements a debugging paradigm wherein the programmer is allowed to step through the evaluation of a form. The specific nature of the interaction, including which I/O streams are used and whether the stepping has lexical or dynamic scope, is implementation-defined.

+ step evaluates form in the current environment. A call to step can be compiled, but it is acceptable for an implementation to interactively step through only those parts of the computation that are interpreted.

+ It is technically permissible for a conforming implementation to take no action at all other than normal execution of the form. In such a situation, (step form) is equivalent to, for example, (let () form). In implementations where this is the case, the associated documentation should mention that fact.

+

Examples: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+trace

+

+

Notes:

+

+Implementations are encouraged to respond to the typing of ? or the pressing of a ``help key'' by providing help including a list of commands.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_time.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_time.htm new file mode 100644 index 00000000..9386fa06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_time.htm @@ -0,0 +1,55 @@ + + + +CLHS: Macro TIME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro TIME

+

Syntax:

+

+ +time form => result*

+

+

Arguments and Values:

+

+form---a form; evaluated as described below.

+results---the values returned by the form.

+

Description:

+

+ time evaluates form in the current environment (lexical and dynamic). A call to time can be compiled.

+time prints various timing data and other information to trace output. The nature and format of the printed information is implementation-defined. Implementations are encouraged to provide such information as elapsed real time, machine run time, and storage management statistics.

+

Examples: None. +

+

Affected By:

+

+The accuracy of the results depends, among other things, on the accuracy of the corresponding functions provided by the underlying operating system.

+The magnitude of the results may depend on the hardware, the operating system, the lisp implementation, and the state of the global environment. Some specific issues which frequently affect the outcome are hardware speed, nature of the scheduler (if any), number of competing processes (if any), system paging, whether the call is interpreted or compiled, whether functions called are compiled, the kind of garbage collector involved and whether it runs, whether internal data structures (e.g., hash tables) are implicitly reorganized, etc.

+

Exceptional Situations: None. +

+

See Also:

+

+get-internal-real-time, get-internal-run-time

+

Notes:

+

+In general, these timings are not guaranteed to be reliable enough for marketing comparisons. Their value is primarily heuristic, for tuning purposes.

+For useful background information on the complicated issues involved in interpreting timing results, see Performance and Evaluation of Lisp Programs.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tpcase.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tpcase.htm new file mode 100644 index 00000000..23ea8f1d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tpcase.htm @@ -0,0 +1,136 @@ + + + +CLHS: Macro TYPECASE, CTYPECASE, ETYPECASE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro TYPECASE, CTYPECASE, ETYPECASE

+

Syntax:

+

+ +typecase keyform {normal-clause}* [otherwise-clause] => result*

+ +ctypecase keyplace {normal-clause}* => result*

+ +etypecase keyform {normal-clause}* => result*

+

+

+normal-clause::= (type form*) 
+
+ 
+otherwise-clause::= ({otherwise | t} form*) 
+
+ 
+clause::= normal-clause | otherwise-clause 
+
+

+

Arguments and Values:

+

+keyform---a form; evaluated to produce a test-key.

+keyplace---a form; evaluated initially to produce a test-key. Possibly also used later as a place if no types match.

+test-key---an object produced by evaluating keyform or keyplace.

+type---a type specifier.

+forms---an implicit progn.

+results---the values returned by the forms in the matching clause.

+

Description:

+

+These macros allow the conditional execution of a body of forms in a clause that is selected by matching the test-key on the basis of its type.

+The keyform or keyplace is evaluated to produce the test-key.

+Each of the normal-clauses is then considered in turn. If the test-key is of the type given by the clauses's type, the forms in that clause are evaluated as an implicit progn, and the values it returns are returned as the value of the typecase, ctypecase, or etypecase form.

+These macros differ only in their behavior when no normal-clause matches; specifically:

+

+

typecase

+If no normal-clause matches, and there is an otherwise-clause, then that otherwise-clause automatically matches; the forms in that clause are evaluated as an implicit progn, and the values it returns are returned as the value of the typecase.

+If there is no otherwise-clause, typecase returns nil.

+

ctypecase

+If no normal-clause matches, a correctable error of type type-error is signaled. The offending datum is the test-key and the expected type is type equivalent to (or type1 type2 ...). The store-value restart can be used to correct the error.

+If the store-value restart is invoked, its argument becomes the new test-key, and is stored in keyplace as if by (setf keyplace test-key). Then ctypecase starts over, considering each clause anew.

+If the store-value restart is invoked interactively, the user is prompted for a new test-key to use.

+The subforms of keyplace might be evaluated again if none of the cases holds.

+

etypecase

+If no normal-clause matches, a non-correctable error of type type-error is signaled. The offending datum is the test-key and the expected type is type equivalent to (or type1 type2 ...).

+Note that in contrast with ctypecase, the caller of etypecase may rely on the fact that etypecase does not return if a normal-clause does not match.

+

+In all three cases, is permissible for more than one clause to specify a matching type, particularly if one is a subtype of another; the earliest applicable clause is chosen.

+

Examples:

+

+

+;;; (Note that the parts of this example which use TYPE-OF 
+;;;  are implementation-dependent.)
+ (defun what-is-it (x)
+   (format t "~&~S is ~A.~%"
+           x (typecase x
+               (float "a float")
+               (null "a symbol, boolean false, or the empty list")
+               (list "a list")
+               (t (format nil "a(n) ~(~A~)" (type-of x))))))
+=>  WHAT-IS-IT
+ (map 'nil #'what-is-it '(nil (a b) 7.0 7 box))
+>>  NIL is a symbol, boolean false, or the empty list.
+>>  (A B) is a list.
+>>  7.0 is a float.
+>>  7 is a(n) integer.
+>>  BOX is a(n) symbol.
+=>  NIL
+ (setq x 1/3)
+=>  1/3
+ (ctypecase x
+     (integer (* x 4))
+     (symbol  (symbol-value x)))
+>>  Error: The value of X, 1/3, is neither an integer nor a symbol.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use instead.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> :CONTINUE 1
+>>  Use value: 3.7
+>>  Error: The value of X, 3.7, is neither an integer nor a symbol.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use instead.
+>>   2: Return to Lisp Toplevel.
+>>  Debug> :CONTINUE 1
+>>  Use value: 12
+=>  48
+ x =>  12
+
+

+

Affected By:

+

+ctypecase and etypecase, since they might signal an error, are potentially affected by existing handlers and *debug-io*.

+

Exceptional Situations:

+

+ctypecase and etypecase signal an error of type type-error if no normal-clause matches.

+The compiler may choose to issue a warning of type style-warning if a clause will never be selected because it is completely shadowed by earlier clauses.

+

See Also:

+

+case, cond, setf, Section 5.1 (Generalized Reference)

+

Notes:

+

+

+(typecase test-key
+  {(type form*)}*)
+== 
+(let ((#1=#:g0001 test-key))
+  (cond {((typep #1# 'type) form*)}*))
+
+

+The specific error message used by etypecase and ctypecase can vary between implementations. In situations where control of the specific wording of the error message is important, it is better to use typecase with an otherwise-clause that explicitly signals an error with an appropriate message.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tracec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tracec.htm new file mode 100644 index 00000000..37fc0d9d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_tracec.htm @@ -0,0 +1,81 @@ + + + +CLHS: Macro TRACE, UNTRACE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro TRACE, UNTRACE

+

Syntax:

+

+ +trace function-name* => trace-result

+ +untrace function-name* => untrace-result

+

+

Arguments and Values:

+

+ function-name---a function name.

+trace-result---implementation-dependent, unless no function-names are supplied, in which case trace-result is a list of function names.

+untrace-result---implementation-dependent.

+

Description:

+

+trace and untrace control the invocation of the trace facility.

+Invoking trace with one or more function-names causes the denoted functions to be ``traced.'' Whenever a traced function is invoked, information about the call, about the arguments passed, and about any eventually returned values is printed to trace output. If trace is used with no function-names, no tracing action is performed; instead, a list of the functions currently being traced is returned.

+Invoking untrace with one or more function names causes those functions to be ``untraced'' (i.e., no longer traced). If untrace is used with no function-names, all functions currently being traced are untraced.

+If a function to be traced has been open-coded (e.g., because it was declared inline), a call to that function might not produce trace output.

+

Examples:

+

+

+ (defun fact (n) (if (zerop n) 1 (* n (fact (- n 1)))))
+=>  FACT
+ (trace fact)
+=>  (FACT)
+;; Of course, the format of traced output is implementation-dependent.
+ (fact 3)
+>>  1 Enter FACT 3
+>>  | 2 Enter FACT 2
+>>  |   3 Enter FACT 1
+>>  |   | 4 Enter FACT 0
+>>  |   | 4 Exit FACT 1
+>>  |   3 Exit FACT 1
+>>  | 2 Exit FACT 2
+>>  1 Exit FACT 6
+=>  6
+
+

+

Side Effects:

+

+Might change the definitions of the functions named by function-names.

+

Affected By:

+

+Whether the functions named are defined or already being traced.

+

Exceptional Situations:

+

+ Tracing an already traced function, or untracing a function not currently being traced, should produce no harmful effects, but might signal a warning.

+

See Also:

+

+*trace-output*, step

+

Notes:

+

+trace and untrace may also accept additional implementation-dependent argument formats. The format of the trace output is implementation-dependent.

+Although trace can be extended to permit non-standard options, implementations are nevertheless encouraged (but not required) to warn about the use of syntax or options that are neither specified by this standard nor added as an extension by the implementation, since they could be symptomatic of typographical errors or of reliance on features supported in implementations other than the current implementation.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_acce.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_acce.htm new file mode 100644 index 00000000..0bfae8e1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_acce.htm @@ -0,0 +1,110 @@ + + + +CLHS: Macro WITH-ACCESSORS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-ACCESSORS

+

+

Syntax:

+

+ +with-accessors (slot-entry*) instance-form declaration* form*

=> result*

+

+

+slot-entry::= (variable-name accessor-name) 
+
+

+

Arguments and Values:

+

+variable-name---a variable name; not evaluated.

+accessor-name---a function name; not evaluated.

+instance-form---a form; evaluated.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+Creates a lexical environment in which the slots specified by slot-entry are lexically available through their accessors as if they were variables. The macro with-accessors invokes the appropriate accessors to access the slots specified by slot-entry. Both setf and setq can be used to set the value of the slot.

+

Examples:

+

+

+ (defclass thing ()
+           ((x :initarg :x :accessor thing-x)
+            (y :initarg :y :accessor thing-y)))
+=>  #<STANDARD-CLASS THING 250020173>
+ (defmethod (setf thing-x) :before (new-x (thing thing))
+   (format t "~&Changing X from ~D to ~D in ~S.~%"
+           (thing-x thing) new-x thing))
+ (setq thing1 (make-instance 'thing :x 1 :y 2)) =>  #<THING 43135676>
+ (setq thing2 (make-instance 'thing :x 7 :y 8)) =>  #<THING 43147374>
+ (with-accessors ((x1 thing-x) (y1 thing-y))
+                 thing1
+   (with-accessors ((x2 thing-x) (y2 thing-y))
+                   thing2
+     (list (list x1 (thing-x thing1) y1 (thing-y thing1)
+                 x2 (thing-x thing2) y2 (thing-y thing2))
+           (setq x1 (+ y1 x2))
+           (list x1 (thing-x thing1) y1 (thing-y thing1)
+                 x2 (thing-x thing2) y2 (thing-y thing2))
+           (setf (thing-x thing2) (list x1))
+           (list x1 (thing-x thing1) y1 (thing-y thing1)
+                 x2 (thing-x thing2) y2 (thing-y thing2)))))
+>>  Changing X from 1 to 9 in #<THING 43135676>.
+>>  Changing X from 7 to (9) in #<THING 43147374>.
+=>  ((1 1 2 2 7 7 8 8)
+     9
+     (9 9 2 2 7 7 8 8) 
+     (9)
+     (9 9 2 2 (9) (9) 8 8))
+
+

+

Affected By:

+

+defclass

+

Exceptional Situations:

+

+The consequences are undefined if any accessor-name is not the name of an accessor for the instance.

+

See Also:

+

+with-slots, symbol-macrolet

+

Notes:

+

+A with-accessors expression of the form:

+

+(with-accessors (slot-entry1 ... slot-entryn) instance-form form1 ... formk)
+
+

+expands into the equivalent of

+ +

+(let ((in instance-form))
+  (symbol-macrolet (Q1 ... Qn) form1 ... formk))
+
+

+where Qi is

+

+ (variable-namei () (accessor-namei in))
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_cnd_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_cnd_.htm new file mode 100644 index 00000000..54d9770b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_cnd_.htm @@ -0,0 +1,60 @@ + + + +CLHS: Macro WITH-CONDITION-RESTARTS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-CONDITION-RESTARTS

+

+

Syntax:

+

+ +with-condition-restarts condition-form restarts-form form*

=> result*

+

+

Arguments and Values:

+

+condition-form---a form; evaluated to produce a condition.

+condition---a condition object resulting from the evaluation of condition-form.

+restart-form---a form; evaluated to produce a restart-list.

+restart-list---a list of restart objects resulting from the evaluation of restart-form.

+forms---an implicit progn; evaluated.

+results---the values returned by forms.

+

Description:

+

+First, the condition-form and restarts-form are evaluated in normal left-to-right order; the primary values yielded by these evaluations are respectively called the condition and the restart-list.

+Next, the forms are evaluated in a dynamic environment in which each restart in restart-list is associated with the condition. See Section 9.1.4.2.4 (Associating a Restart with a Condition).

+

Examples: None. +

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+restart-case

+

Notes:

+

+Usually this macro is not used explicitly in code, since restart-case handles most of the common cases in a way that is syntactically more concise.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_comp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_comp.htm new file mode 100644 index 00000000..14a99d18 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_comp.htm @@ -0,0 +1,75 @@ + + + +CLHS: Macro WITH-COMPILATION-UNIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-COMPILATION-UNIT

+

+

Syntax:

+

+ +with-compilation-unit ([[option]]) form* => result*

+

+

+option::= :override override 
+
+

+

Arguments and Values:

+

+override---a generalized boolean; evaluated. The default is nil.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+Executes forms from left to right. Within the dynamic environment of with-compilation-unit, actions deferred by the compiler until the end of compilation will be deferred until the end of the outermost call to with-compilation-unit.

+The set of options permitted may be extended by the implementation, but the only standardized keyword is :override.

+If nested dynamically only the outer call to with-compilation-unit has any effect unless the value associated with :override is true, in which case warnings are deferred only to the end of the innermost call for which override is true.

+The function compile-file provides the effect of

+

+ (with-compilation-unit (:override nil) ...)
+
+ around its code.

+Any implementation-dependent extensions can only be provided as the result of an explicit programmer request by use of an implementation-dependent keyword. Implementations are forbidden from attaching additional meaning to a use of this macro which involves either no keywords or just the keyword :override.

+

Examples:

+

+If an implementation would normally defer certain kinds of warnings, such as warnings about undefined functions, to the end of a compilation unit (such as a file), the following example shows how to cause those warnings to be deferred to the end of the compilation of several files.

+

+ (defun compile-files (&rest files)
+   (with-compilation-unit ()
+     (mapcar #'(lambda (file) (compile-file file)) files)))
+
+ (compile-files "A" "B" "C")
+
+

+Note however that if the implementation does not normally defer any warnings, use of with-compilation-unit might not have any effect.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+compile, compile-file

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_hash.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_hash.htm new file mode 100644 index 00000000..044efb0f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_hash.htm @@ -0,0 +1,95 @@ + + + +CLHS: Macro WITH-HASH-TABLE-ITERATOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-HASH-TABLE-ITERATOR

+

+

+

Syntax:

+

+ +with-hash-table-iterator (name hash-table) declaration* form* => result*

+

+

Arguments and Values:

+

+name---a name suitable for the first argument to macrolet.

+hash-table---a form, evaluated once, that should produce a hash table.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by forms.

+

Description:

+

+Within the lexical scope of the body, name is defined via macrolet such that successive invocations of (name) return the items, one by one, from the hash table that is obtained by evaluating hash-table only once.

+An invocation (name) returns three values as follows:

+

1. A generalized boolean that is true if an entry is returned.
2. The key from the hash-table entry.
3. The value from the hash-table entry.

After all entries have been returned by successive invocations of (name), then only one value is returned, namely nil.

+It is unspecified what happens if any of the implicit interior state of an iteration is returned outside the dynamic extent of the with-hash-table-iterator form such as by returning some closure over the invocation form.

+Any number of invocations of with-hash-table-iterator can be nested, and the body of the innermost one can invoke all of the locally established macros, provided all of those macros have distinct names.

+

Examples:

+

+The following function should return t on any hash table, and signal an error if the usage of with-hash-table-iterator does not agree with the corresponding usage of maphash.

+

+ (defun test-hash-table-iterator (hash-table)
+   (let ((all-entries '())
+         (generated-entries '())
+         (unique (list nil)))
+     (maphash #'(lambda (key value) (push (list key value) all-entries))
+              hash-table)
+     (with-hash-table-iterator (generator-fn hash-table)
+       (loop     
+         (multiple-value-bind (more? key value) (generator-fn)
+           (unless more? (return))
+           (unless (eql value (gethash key hash-table unique))
+             (error "Key ~S not found for value ~S" key value))
+           (push (list key value) generated-entries))))
+     (unless (= (length all-entries)
+                (length generated-entries)
+                (length (union all-entries generated-entries
+                               :key #'car :test (hash-table-test hash-table))))
+       (error "Generated entries and Maphash entries don't correspond"))
+     t))
+
+

+The following could be an acceptable definition of maphash, implemented by with-hash-table-iterator.

+

+ (defun maphash (function hash-table)
+   (with-hash-table-iterator (next-entry hash-table)
+     (loop (multiple-value-bind (more key value) (next-entry)
+             (unless more (return nil))
+             (funcall function key value)))))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences are undefined if the local function named name established by with-hash-table-iterator is called after it has returned false as its primary value.

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_in_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_in_f.htm new file mode 100644 index 00000000..86a6ec4e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_in_f.htm @@ -0,0 +1,74 @@ + + + +CLHS: Macro WITH-INPUT-FROM-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-INPUT-FROM-STRING

+

+

Syntax:

+

+ +with-input-from-string (var string &key index start end) declaration* form*

=> result*

+

+

Arguments and Values:

+

+var---a variable name.

+string---a form; evaluated to produce a string.

+index---a place.

+ start, end---bounding index designators of string. The defaults for start and end are 0 and nil, respectively. declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+result---the values returned by the forms.

+

Description:

+

+Creates an input string stream, provides an opportunity to perform operations on the stream (returning zero or more values), and then closes the string stream.

+String is evaluated first, and var is bound to a character input string stream that supplies characters from the subsequence of the resulting string bounded by start and end. The body is executed as an implicit progn.

+The input string stream is automatically closed on exit from with-input-from-string, no matter whether the exit is normal or abnormal. The input string stream to which the variable var is bound has dynamic extent; its extent ends when the form is exited.

+The index is a pointer within the string to be advanced. If with-input-from-string is exited normally, then index will have as its value the index into the string indicating the first character not read which is (length string) if all characters were used. The place specified by index is not updated as reading progresses, but only at the end of the operation.

+start and index may both specify the same variable, which is a pointer within the string to be advanced, perhaps repeatedly by some containing loop.

+ The consequences are undefined if an attempt is made to assign the variable var.

+

Examples:

+ +

+ (with-input-from-string (s "XXX1 2 3 4xxx"
+                             :index ind
+                             :start 3 :end 10)
+    (+ (read s) (read s) (read s))) =>  6
+ ind =>  9
+ (with-input-from-string (s "Animal Crackers" :index j :start 6)
+   (read s)) =>  CRACKERS
+
+ The variable j is set to 15.

+

Side Effects:

+

+The value of the place named by index, if any, is modified.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+make-string-input-stream, Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_op_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_op_1.htm new file mode 100644 index 00000000..31dcb47a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_op_1.htm @@ -0,0 +1,65 @@ + + + +CLHS: Macro WITH-OPEN-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-OPEN-STREAM

+

+

Syntax:

+

+ +with-open-stream (var stream) declaration* form*

=> result*

+

+

Arguments and Values:

+

+var---a variable name.

+stream---a form; evaluated to produce a stream.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+with-open-stream performs a series of operations on stream, returns a value, and then closes the stream.

+Var is bound to the value of stream, and then forms are executed as an implicit progn. stream is automatically closed on exit from with-open-stream, no matter whether the exit is normal or abnormal. The stream has dynamic extent; its extent ends when the form is exited.

+ The consequences are undefined if an attempt is made to assign the the variable var with the forms.

+

Examples:

+

+

+ (with-open-stream (s (make-string-input-stream "1 2 3 4"))
+    (+ (read s) (read s) (read s))) =>  6
+
+

+

Side Effects:

+

+The stream is closed (upon exit).

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+close

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_open.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_open.htm new file mode 100644 index 00000000..eaa78b08 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_open.htm @@ -0,0 +1,98 @@ + + + +CLHS: macro WITH-OPEN-FILE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +macro WITH-OPEN-FILE

+

+

Syntax:

+

+ +with-open-file (stream filespec options*) declaration* form*

=> results

+

+

Arguments and Values:

+

+stream -- a variable.

+ filespec---a pathname designator.

+options -- forms; evaluated.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+ with-open-file uses open to create a file stream to file named by filespec. Filespec is the name of the file to be opened. Options are used as keyword arguments to open.

+ The stream object to which the stream variable is bound has dynamic extent; its extent ends when the form is exited.

+with-open-file evaluates the forms as an implicit progn with stream bound to the value returned by open.

+When control leaves the body, either normally or abnormally (such as by use of throw), the file is automatically closed. If a new output file is being written, and control leaves abnormally, the file is aborted and the file system is left, so far as possible, as if the file had never been opened.

+It is possible by the use of :if-exists nil or :if-does-not-exist nil for stream to be bound to nil. Users of :if-does-not-exist nil should check for a valid stream.

+ The consequences are undefined if an attempt is made to assign the stream variable. The compiler may choose to issue a warning if such an attempt is detected.

+

Examples:

+

+

+ (setq p (merge-pathnames "test"))
+=>  #<PATHNAME :HOST NIL :DEVICE device-name :DIRECTORY directory-name
+    :NAME "test" :TYPE NIL :VERSION :NEWEST>
+ (with-open-file (s p :direction :output :if-exists :supersede)
+    (format s "Here are a couple~%of test data lines~%")) =>  NIL
+ (with-open-file (s p)
+    (do ((l (read-line s) (read-line s nil 'eof)))
+        ((eq l 'eof) "Reached end of file.")
+     (format t "~&*** ~A~%" l)))
+>>  *** Here are a couple
+>>  *** of test data lines
+=>  "Reached end of file."
+
+

+ +

+;; Normally one would not do this intentionally because it is
+;; not perspicuous, but beware when using :IF-DOES-NOT-EXIST NIL
+;; that this doesn't happen to you accidentally...
+ (with-open-file (foo "no-such-file" :if-does-not-exist nil)
+   (read foo))
+>>  hello?
+=>  HELLO? ;This value was read from the terminal, not a file!
+
+;; Here's another bug to avoid...
+ (with-open-file (foo "no-such-file" :direction :output :if-does-not-exist nil)
+   (format foo "Hello"))
+=>  "Hello" ;FORMAT got an argument of NIL!
+
+

+

Side Effects:

+

+Creates a stream to the file named by filename (upon entry), and closes the stream (upon exit). In some implementations, the file might be locked in some way while it is open. If the stream is an output stream, a file might be created.

+

Affected By:

+

+The host computer's file system.

+

Exceptional Situations:

+

+ See the function open.

+

See Also:

+

+ open, close, pathname, logical-pathname, Section 19.1.2 (Pathnames as Filenames)

+

Notes: None. +

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_out_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_out_.htm new file mode 100644 index 00000000..591b4441 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_out_.htm @@ -0,0 +1,76 @@ + + + +CLHS: Macro WITH-OUTPUT-TO-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-OUTPUT-TO-STRING

+

+

Syntax:

+

+ +with-output-to-string (var &optional string-form &key element-type) declaration* form*

=> result*

+

+

Arguments and Values:

+

+var---a variable name.

+string-form---a form or nil; if non-nil, evaluated to produce string.

+string---a string that has a fill pointer.

+ element-type---a type specifier; evaluated. The default is character.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---If a string-form is not supplied or nil, a string; otherwise, the values returned by the forms.

+

Description:

+

+with-output-to-string creates a character output stream, performs a series of operations that may send results to this stream, and then closes the stream.

+ The element-type names the type of the elements of the stream; a stream is constructed of the most specialized type that can accommodate elements of the given type.

+The body is executed as an implicit progn with var bound to an output string stream. All output to that string stream is saved in a string.

+ If string is supplied, element-type is ignored, and the output is incrementally appended to string as if by use of vector-push-extend.

+The output stream is automatically closed on exit from with-output-from-string, no matter whether the exit is normal or abnormal. The output string stream to which the variable var is bound has dynamic extent; its extent ends when the form is exited.

+If no string is provided, then with-output-from-string produces a stream that accepts characters and returns a string of the indicated element-type. If string is provided, with-output-to-string returns the results of evaluating the last form.

+ The consequences are undefined if an attempt is made to assign the variable var.

+

Examples:

+ +

+ (setq fstr (make-array '(0) :element-type 'base-char
+                             :fill-pointer 0 :adjustable t)) =>  ""
+ (with-output-to-string (s fstr)
+    (format s "here's some output")
+    (input-stream-p s)) =>  false
+ fstr =>  "here's some output"
+
+

+

Side Effects:

+

+The string is modified.

+

Affected By: None. +

+

Exceptional Situations:

+

+ The consequences are undefined if destructive modifications are performed directly on the string during the dynamic extent of the call.

+

See Also:

+

+make-string-output-stream, vector-push-extend, Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_pkg_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_pkg_.htm new file mode 100644 index 00000000..fa103fce --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_pkg_.htm @@ -0,0 +1,124 @@ + + + +CLHS: Macro WITH-PACKAGE-ITERATOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-PACKAGE-ITERATOR

+

+

+

Syntax:

+

+ +with-package-iterator (name package-list-form &rest symbol-types) declaration* form*

=> result*

+

+

Arguments and Values:

+

+name---a symbol.

+package-list-form---a form; evaluated once to produce a package-list.

+package-list---a designator for a list of package designators.

+symbol-type---one of the symbols :internal, :external, or :inherited.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values of the forms.

+

Description:

+

+Within the lexical scope of the body forms, the name is defined via macrolet such that successive invocations of (name) will return the symbols, one by one, from the packages in package-list.

+It is unspecified whether symbols inherited from multiple packages are returned more than once. The order of symbols returned does not necessarily reflect the order of packages in package-list. When package-list has more than one element, it is unspecified whether duplicate symbols are returned once or more than once.

+Symbol-types controls which symbols that are accessible in a package are returned as follows:

+

:internal

+ The symbols that are present in the package, but that are not exported.

+

:external

+ The symbols that are present in the package and are exported.

+

:inherited

+ The symbols that are exported by used packages and that are not shadowed.

+When more than one argument is supplied for symbol-types, a symbol is returned if its accessibility matches any one of the symbol-types supplied. Implementations may extend this syntax by recognizing additional symbol accessibility types.

+An invocation of (name) returns four values as follows:

+

1. A flag that indicates whether a symbol is returned (true means that a symbol is returned).
2. A symbol that is accessible in one the indicated packages.
3. The accessibility type for that symbol; i.e., one of the symbols :internal, :external, or :inherited.
4. The package from which the symbol was obtained. The package is one of the packages present or named in package-list.

+After all symbols have been returned by successive invocations of (name), then only one value is returned, namely nil.

+The meaning of the second, third, and fourth values is that the returned symbol is accessible in the returned package in the way indicated by the second return value as follows:

+

:internal

+Means present and not exported.

+

:external

+Means present and exported.

+

:inherited

+Means not present (thus not shadowed) but inherited from some used package.

+It is unspecified what happens if any of the implicit interior state of an iteration is returned outside the dynamic extent of the with-package-iterator form such as by returning some closure over the invocation form.

+Any number of invocations of with-package-iterator can be nested, and the body of the innermost one can invoke all of the locally established macros, provided all those macros have distinct names.

+

Examples:

+

+The following function should return t on any package, and signal an error if the usage of with-package-iterator does not agree with the corresponding usage of do-symbols.

+

+ (defun test-package-iterator (package)
+   (unless (packagep package)
+     (setq package (find-package package)))
+   (let ((all-entries '())
+         (generated-entries '()))
+     (do-symbols (x package) 
+       (multiple-value-bind (symbol accessibility) 
+           (find-symbol (symbol-name x) package)
+         (push (list symbol accessibility) all-entries)))
+     (with-package-iterator (generator-fn package 
+                             :internal :external :inherited)
+       (loop     
+         (multiple-value-bind (more? symbol accessibility pkg)
+             (generator-fn)
+           (unless more? (return))
+           (let ((l (multiple-value-list (find-symbol (symbol-name symbol) 
+                                                      package))))
+             (unless (equal l (list symbol accessibility))
+               (error "Symbol ~S not found as ~S in package ~A [~S]"
+                      symbol accessibility (package-name package) l))
+             (push l generated-entries)))))
+     (unless (and (subsetp all-entries generated-entries :test #'equal)
+                  (subsetp generated-entries all-entries :test #'equal))
+      (error "Generated entries and Do-Symbols entries don't correspond"))
+     t))
+
+

+The following function prints out every present symbol (possibly more than once):

+

+ (defun print-all-symbols () 
+   (with-package-iterator (next-symbol (list-all-packages)
+                           :internal :external)
+     (loop
+       (multiple-value-bind (more? symbol) (next-symbol)
+         (if more? 
+            (print symbol)
+            (return))))))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations:

+

+with-package-iterator signals an error of type program-error if no symbol-types are supplied or if a symbol-type is not recognized by the implementation is supplied.

+The consequences are undefined if the local function named name established by with-package-iterator is called after it has returned false as its primary value.

+

See Also:

+

+ Section 3.6 (Traversal Rules and Side Effects)

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_slts.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_slts.htm new file mode 100644 index 00000000..28cce8a7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_slts.htm @@ -0,0 +1,123 @@ + + + +CLHS: Macro WITH-SLOTS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-SLOTS

+

+

Syntax:

+

+ +with-slots (slot-entry*) instance-form declaration* form*

=> result*

+

+

+slot-entry::= slot-name | (variable-name slot-name) 
+
+

+

Arguments and Values:

+

+slot-name---a slot name; not evaluated.

+variable-name---a variable name; not evaluated.

+instance-form---a form; evaluted to produce instance.

+instance---an object.

+declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+The macro with-slots establishes a lexical environment for referring to the slots in the instance named by the given slot-names as though they were variables. Within such a context the value of the slot can be specified by using its slot name, as if it were a lexically bound variable. Both setf and setq can be used to set the value of the slot.

+The macro with-slots translates an appearance of the slot name as a variable into a call to slot-value.

+

Examples:

+

+

+ (defclass thing ()
+           ((x :initarg :x :accessor thing-x)
+            (y :initarg :y :accessor thing-y)))
+=>  #<STANDARD-CLASS THING 250020173>
+ (defmethod (setf thing-x) :before (new-x (thing thing))
+   (format t "~&Changing X from ~D to ~D in ~S.~%"
+           (thing-x thing) new-x thing))
+ (setq thing (make-instance 'thing :x 0 :y 1)) =>  #<THING 62310540>
+ (with-slots (x y) thing (incf x) (incf y)) =>  2
+ (values (thing-x thing) (thing-y thing)) =>  1, 2
+ (setq thing1 (make-instance 'thing :x 1 :y 2)) =>  #<THING 43135676>
+ (setq thing2 (make-instance 'thing :x 7 :y 8)) =>  #<THING 43147374>
+ (with-slots ((x1 x) (y1 y))
+             thing1
+   (with-slots ((x2 x) (y2 y))
+               thing2
+     (list (list x1 (thing-x thing1) y1 (thing-y thing1)
+                 x2 (thing-x thing2) y2 (thing-y thing2))
+           (setq x1 (+ y1 x2))
+           (list x1 (thing-x thing1) y1 (thing-y thing1)
+                 x2 (thing-x thing2) y2 (thing-y thing2))
+           (setf (thing-x thing2) (list x1))
+           (list x1 (thing-x thing1) y1 (thing-y thing1)
+                 x2 (thing-x thing2) y2 (thing-y thing2)))))
+>>  Changing X from 7 to (9) in #<THING 43147374>.
+=>  ((1 1 2 2 7 7 8 8)
+     9
+     (9 9 2 2 7 7 8 8) 
+     (9)
+     (9 9 2 2 (9) (9) 8 8))
+
+

+

Affected By:

+

+defclass

+

Exceptional Situations:

+

+The consequences are undefined if any slot-name is not the name of a slot in the instance.

+

See Also:

+

+with-accessors, slot-value, symbol-macrolet

+

Notes:

+

+A with-slots expression of the form:

+ (with-slots (slot-entry1 ... slot-entryn) instance-form form1 ... formk)

+expands into the equivalent of

+ +

+(let ((in instance-form))
+  (symbol-macrolet (Q1 ... Qn) form1 ... formk))
+
+

+where Qi is

+ +

+(slot-entryi () (slot-value in 'slot-entryi))
+
+

+if slot-entryi is a symbol and is

+ +

+(variable-namei () (slot-value in 'slot-namei))
+
+

+if slot-entryi is of the form

+

+(variable-namei 'slot-namei))
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_smp_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_smp_.htm new file mode 100644 index 00000000..e7d84006 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_smp_.htm @@ -0,0 +1,115 @@ + + + +CLHS: Macro WITH-SIMPLE-RESTART + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-SIMPLE-RESTART

+

Syntax:

+

+ +with-simple-restart (name format-control format-argument*) form*

=> result*

+

+

Arguments and Values:

+

+name---a symbol.

+ format-control---a format control.

+format-argument---an object (i.e., a format argument).

+forms---an implicit progn.

+results---in the normal situation, the values returned by the forms; in the exceptional situation where the restart named name is invoked, two values---nil and t.

+

Description:

+

+with-simple-restart establishes a restart.

+If the restart designated by name is not invoked while executing forms, all values returned by the last of forms are returned. If the restart designated by name is invoked, control is transferred to with-simple-restart, which returns two values, nil and t.

+If name is nil, an anonymous restart is established.

+The format-control and format-arguments are used report the restart.

+

Examples:

+

+

+ (defun read-eval-print-loop (level)
+   (with-simple-restart (abort "Exit command level ~D." level)
+     (loop
+       (with-simple-restart (abort "Return to command level ~D." level)
+         (let ((form (prog2 (fresh-line) (read) (fresh-line))))
+           (prin1 (eval form)))))))
+=>  READ-EVAL-PRINT-LOOP
+ (read-eval-print-loop 1)
+ (+ 'a 3)
+>>  Error: The argument, A, to the function + was of the wrong type.
+>>         The function expected a number.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Specify a value to use this time.
+>>   2: Return to command level 1.
+>>   3: Exit command level 1.
+>>   4: Return to Lisp Toplevel.
+
+

+

+ (defun compute-fixnum-power-of-2 (x)
+   (with-simple-restart (nil "Give up on computing 2^~D." x)
+     (let ((result 1))
+       (dotimes (i x result)
+         (setq result (* 2 result))
+         (unless (fixnump result)
+           (error "Power of 2 is too large."))))))
+COMPUTE-FIXNUM-POWER-OF-2
+ (defun compute-power-of-2 (x)
+   (or (compute-fixnum-power-of-2 x) 'something big))
+COMPUTE-POWER-OF-2
+ (compute-power-of-2 10)
+1024
+ (compute-power-of-2 10000)
+>>  Error: Power of 2 is too large.
+>>  To continue, type :CONTINUE followed by an option number.
+>>   1: Give up on computing 2^10000.
+>>   2: Return to Lisp Toplevel
+>>  Debug> :continue 1
+=>  SOMETHING-BIG
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+restart-case

+

Notes:

+

+with-simple-restart is shorthand for one of the most common uses of restart-case.

+with-simple-restart could be defined by:

+ +

+ (defmacro with-simple-restart ((restart-name format-control
+                                              &rest format-arguments)
+                                &body forms)
+   `(restart-case (progn ,@forms)
+      (,restart-name ()
+          :report (lambda (stream)
+                    (format stream ,format-control ,@format-arguments))
+         (values nil t))))
+
+

+Because the second return value is t in the exceptional case, it is common (but not required) to arrange for the second return value in the normal case to be missing or nil so that the two situations can be distinguished.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_std_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_std_.htm new file mode 100644 index 00000000..3b12fb5a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_w_std_.htm @@ -0,0 +1,86 @@ + + + +CLHS: Macro WITH-STANDARD-IO-SYNTAX + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WITH-STANDARD-IO-SYNTAX

+

Syntax:

+

+ +with-standard-io-syntax form* => result*

+

+

Arguments and Values:

+

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+Within the dynamic extent of the body of forms, all reader/printer control variables, including any implementation-defined ones not specified by this standard, are bound to values that produce standard read/print behavior. The values for the variables specified by this standard are listed in the next figure.

+ 

+Variable                     Value                               
+*package*                    The CL-USER package                 
+*print-array*                t                                   
+*print-base*                 10                                  
+*print-case*                 :upcase                             
+*print-circle*               nil                                 
+*print-escape*               t                                   
+*print-gensym*               t                                   
+*print-length*               nil                                 
+*print-level*                nil                                 
+*print-lines*                nil                                 
+*print-miser-width*          nil                                 
+*print-pprint-dispatch*      The standard pprint dispatch table  
+*print-pretty*               nil                                 
+*print-radix*                nil                                 
+*print-readably*             t                                   
+*print-right-margin*         nil                                 
+*read-base*                  10                                  
+*read-default-float-format*  single-float                        
+*read-eval*                  t                                   
+*read-suppress*              nil                                 
+*readtable*                  The standard readtable              
+
+

Figure 23-1. Values of standard control variables

+

Examples:

+

+

+ (with-open-file (file pathname :direction :output)
+   (with-standard-io-syntax
+     (print data file)))
+
+;;; ... Later, in another Lisp:
+
+ (with-open-file (file pathname :direction :input)
+   (with-standard-io-syntax
+     (setq data (read file))))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_when_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_when_.htm new file mode 100644 index 00000000..7fbb27ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/m_when_.htm @@ -0,0 +1,95 @@ + + + +CLHS: Macro WHEN, UNLESS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Macro WHEN, UNLESS

+

Syntax:

+

+ +when test-form form* => result*

+

+ +unless test-form form* => result*

+

+

Arguments and Values:

+

+test-form---a form.

+forms---an implicit progn.

+results---the values of the forms in a when form if the test-form yields true or in an unless form if the test-form yields false; otherwise nil.

+

Description:

+

+when and unless allow the execution of forms to be dependent on a single test-form.

+In a when form, if the test-form yields true, the forms are evaluated in order from left to right and the values returned by the forms are returned from the when form. Otherwise, if the test-form yields false, the forms are not evaluated, and the when form returns nil.

+In an unless form, if the test-form yields false, the forms are evaluated in order from left to right and the values returned by the forms are returned from the unless form. Otherwise, if the test-form yields false, the forms are not evaluated, and the unless form returns nil.

+

Examples:

+

+

+ (when t 'hello) =>  HELLO
+ (unless t 'hello) =>  NIL
+ (when nil 'hello) =>  NIL
+ (unless nil 'hello) =>  HELLO
+ (when t) =>  NIL
+ (unless nil) =>  NIL
+ (when t (prin1 1) (prin1 2) (prin1 3))
+>>  123
+=>  3
+ (unless t (prin1 1) (prin1 2) (prin1 3)) =>  NIL
+ (when nil (prin1 1) (prin1 2) (prin1 3)) =>  NIL
+ (unless nil (prin1 1) (prin1 2) (prin1 3))
+>>  123
+=>  3
+ (let ((x 3))
+   (list (when (oddp x) (incf x) (list x))
+         (when (oddp x) (incf x) (list x))
+         (unless (oddp x) (incf x) (list x))
+         (unless (oddp x) (incf x) (list x))
+         (if (oddp x) (incf x) (list x)) 
+         (if (oddp x) (incf x) (list x)) 
+         (if (not (oddp x)) (incf x) (list x)) 
+         (if (not (oddp x)) (incf x) (list x))))
+=>  ((4) NIL (5) NIL 6 (6) 7 (7))
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+and, cond, if, or

+

Notes:

+

+

+ (when test {form}+) ==  (and test (progn {form}+))
+ (when test {form}+) ==  (cond (test {form}+))
+ (when test {form}+) ==  (if test (progn {form}+) nil)
+ (when test {form}+) ==  (unless (not test) {form}+)
+ (unless test {form}+) ==  (cond ((not test) {form}+))
+ (unless test {form}+) ==  (if test nil (progn {form}+))
+ (unless test {form}+) ==  (when (not test) {form}+)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_abort.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_abort.htm new file mode 100644 index 00000000..90de49da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_abort.htm @@ -0,0 +1,36 @@ + + + +CLHS: Restart ABORT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Restart ABORT

+

Data Arguments Required:

+

+None.

+

Description:

+

+The intent of the abort restart is to allow return to the innermost ``command level.'' Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time and expect something reasonable to happen; exactly what the reasonable thing is may vary somewhat. Typically, in an interactive listener, the invocation of abort returns to the Lisp reader phase of the Lisp read-eval-print loop, though in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate.

+

See Also:

+

+Section 9.1.4.2 (Restarts), Section 9.1.4.2.2 (Interfaces to Restarts), invoke-restart, abort (function)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_contin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_contin.htm new file mode 100644 index 00000000..a95eae42 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_contin.htm @@ -0,0 +1,49 @@ + + + +CLHS: Restart CONTINUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Restart CONTINUE

+

Data Arguments Required:

+

+None.

+

Description:

+

+The continue restart is generally part of protocols where there is a single ``obvious'' way to continue, such as in break and cerror. Some user-defined protocols may also wish to incorporate it for similar reasons. In general, however, it is more reliable to design a special purpose restart with a name that more directly suits the particular application.

+

Examples:

+

+

+ (let ((x 3))
+   (handler-bind ((error #'(lambda (c)
+                             (let ((r (find-restart 'continue c)))
+                               (when r (invoke-restart r))))))
+     (cond ((not (floatp x))
+            (cerror "Try floating it." "~D is not a float." x)
+            (float x))
+           (t x)))) =>  3.0
+
+

+

See Also:

+

+Section 9.1.4.2 (Restarts), Section 9.1.4.2.2 (Interfaces to Restarts), invoke-restart, continue (function), assert, cerror

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_muffle.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_muffle.htm new file mode 100644 index 00000000..28c45f3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_muffle.htm @@ -0,0 +1,69 @@ + + + +CLHS: Restart MUFFLE-WARNING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Restart MUFFLE-WARNING

+

Data Arguments Required:

+

+None.

+

Description:

+

+This restart is established by warn so that handlers of warning conditions have a way to tell warn that a warning has already been dealt with and that no further action is warranted.

+

Examples:

+

+

+ (defvar *all-quiet* nil) =>  *ALL-QUIET*
+ (defvar *saved-warnings* '()) =>  *SAVED-WARNINGS*
+ (defun quiet-warning-handler (c)
+   (when *all-quiet*
+     (let ((r (find-restart 'muffle-warning c)))
+       (when r 
+         (push c *saved-warnings*)
+         (invoke-restart r)))))
+=>  CUSTOM-WARNING-HANDLER
+ (defmacro with-quiet-warnings (&body forms)
+   `(let ((*all-quiet* t)
+          (*saved-warnings* '()))
+      (handler-bind ((warning #'quiet-warning-handler))
+        ,@forms
+        *saved-warnings*)))
+=>  WITH-QUIET-WARNINGS
+ (setq saved
+   (with-quiet-warnings
+     (warn "Situation #1.")
+     (let ((*all-quiet* nil))
+       (warn "Situation #2."))
+     (warn "Situation #3.")))
+>>  Warning: Situation #2.
+=>  (#<SIMPLE-WARNING 42744421> #<SIMPLE-WARNING 42744365>)
+ (dolist (s saved) (format t "~&~A~%" s))
+>>  Situation #3.
+>>  Situation #1.
+=>  NIL
+
+

+

See Also:

+

+Section 9.1.4.2 (Restarts), Section 9.1.4.2.2 (Interfaces to Restarts), invoke-restart, muffle-warning (function), warn

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_store_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_store_.htm new file mode 100644 index 00000000..21a27913 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_store_.htm @@ -0,0 +1,52 @@ + + + +CLHS: Restart STORE-VALUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Restart STORE-VALUE

+

Data Arguments Required:

+

+a value to use instead (on an ongoing basis).

+

Description:

+

+The store-value restart is generally used by handlers trying to recover from errors of types such as cell-error or type-error, which may wish to supply a replacement datum to be stored permanently.

+

Examples:

+

+

+ (defun type-error-auto-coerce (c)
+   (when (typep c 'type-error)
+     (let ((r (find-restart 'store-value c)))
+       (handler-case (let ((v (coerce (type-error-datum c)
+                                      (type-error-expected-type c))))
+                       (invoke-restart r v))
+         (error ()))))) =>  TYPE-ERROR-AUTO-COERCE
+ (let ((x 3))
+   (handler-bind ((type-error #'type-error-auto-coerce))
+     (check-type x float)
+     x)) =>  3.0
+
+

+

See Also:

+

+Section 9.1.4.2 (Restarts), Section 9.1.4.2.2 (Interfaces to Restarts), invoke-restart, store-value (function), ccase, check-type, ctypecase, use-value (function and restart)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_use_va.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_use_va.htm new file mode 100644 index 00000000..1ee1fd8e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/r_use_va.htm @@ -0,0 +1,36 @@ + + + +CLHS: Restart USE-VALUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Restart USE-VALUE

+

Data Arguments Required:

+

+a value to use instead (once).

+

Description:

+

+The use-value restart is generally used by handlers trying to recover from errors of types such as cell-error, where the handler may wish to supply a replacement datum for one-time use.

+

See Also:

+

+Section 9.1.4.2 (Restarts), Section 9.1.4.2.2 (Interfaces to Restarts), invoke-restart, use-value (function), store-value (function and restart)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_block.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_block.htm new file mode 100644 index 00000000..1059c640 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_block.htm @@ -0,0 +1,70 @@ + + + +CLHS: Special Operator BLOCK + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator BLOCK

+

Syntax:

+

+ +block name form* => result*

+

+

Arguments and Values:

+

+name---a symbol.

+form---a form.

+results---the values of the forms if a normal return occurs, or else, if an explicit return occurs, the values that were transferred.

+

Description:

+

+block establishes a block named name and then evaluates forms as an implicit progn.

+The special operators block and return-from work together to provide a structured, lexical, non-local exit facility. At any point lexically contained within forms, return-from can be used with the given name to return control and values from the block form, except when an intervening block with the same name has been established, in which case the outer block is shadowed by the inner one.

+The block named name has lexical scope and dynamic extent.

+Once established, a block may only be exited once, whether by normal return or explicit return.

+

Examples:

+

+

+ (block empty) =>  NIL
+ (block whocares (values 1 2) (values 3 4)) =>  3, 4
+ (let ((x 1)) 
+   (block stop (setq x 2) (return-from stop) (setq x 3))
+   x) =>  2
+ (block early (return-from early (values 1 2)) (values 3 4)) =>  1, 2
+ (block outer (block inner (return-from outer 1)) 2) =>  1
+ (block twin (block twin (return-from twin 1)) 2) =>  2
+ ;; Contrast behavior of this example with corresponding example of CATCH.
+ (block b
+   (flet ((b1 () (return-from b 1)))
+     (block b (b1) (print 'unreachable))
+     2)) =>  1
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+return, return-from, Section 3.1 (Evaluation)

+

Notes:

+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_catch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_catch.htm new file mode 100644 index 00000000..6f38ddd0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_catch.htm @@ -0,0 +1,72 @@ + + + +CLHS: Special Operator CATCH + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator CATCH

+

Syntax:

+

+ +catch tag form* => result*

+

+

Arguments and Values:

+

+tag---a catch tag; evaluated.

+forms---an implicit progn.

+results---if the forms exit normally, the values returned by the forms; if a throw occurs to the tag, the values that are thrown.

+

Description:

+

+catch is used as the destination of a non-local control transfer by throw. Tags are used to find the catch to which a throw is transferring control. (catch 'foo form) catches a (throw 'foo form) but not a (throw 'bar form).

+The order of execution of catch follows:

+

1. Tag is evaluated. It serves as the name of the catch.

+
2. Forms are then evaluated as an implicit progn, and the results of the last form are returned unless a throw occurs.

+
3. If a throw occurs during the execution of one of the forms, control is transferred to the catch form whose tag is eq to the tag argument of the throw and which is the most recently established catch with that tag. No further evaluation of forms occurs.

+
4. The tag established by catch is disestablished just before the results are returned.

+

+If during the execution of one of the forms, a throw is executed whose tag is eq to the catch tag, then the values specified by the throw are returned as the result of the dynamically most recently established catch form with that tag.

+The mechanism for catch and throw works even if throw is not within the lexical scope of catch. throw must occur within the dynamic extent of the evaluation of the body of a catch with a corresponding tag.

+

Examples:

+ +

+ (catch 'dummy-tag 1 2 (throw 'dummy-tag 3) 4) =>  3
+ (catch 'dummy-tag 1 2 3 4) =>  4
+ (defun throw-back (tag) (throw tag t)) =>  THROW-BACK
+ (catch 'dummy-tag (throw-back 'dummy-tag) 2) =>  T
+
+ ;; Contrast behavior of this example with corresponding example of BLOCK.
+ (catch 'c
+   (flet ((c1 () (throw 'c 1)))
+     (catch 'c (c1) (print 'unreachable))
+     2)) =>  2
+
+

+

Affected By: None. +

Exceptional Situations:

+ An error of type control-error is signaled if throw is done when there is no suitable catch tag.

See Also:

+

+throw, Section 3.1 (Evaluation)

+

Notes:

+

+It is customary for symbols to be used as tags, but any object is permitted. However, numbers should not be used because the comparison is done using eq.

+catch differs from block in that catch tags have dynamic scope while block names have lexical scope.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_declar.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_declar.htm new file mode 100644 index 00000000..00086fe8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_declar.htm @@ -0,0 +1,88 @@ + + + +CLHS: Symbol DECLARE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Symbol DECLARE

+

Syntax:

+

+ +declare declaration-specifier*

+

+

Arguments:

+

+declaration-specifier---a declaration specifier; not evaluated.

+

Description:

+

+A declare expression, sometimes called a declaration, can occur only at the beginning of the bodies of certain forms; that is, it may be preceded only by other declare expressions, or by a documentation string if the context permits.

+A declare expression can occur in a lambda expression or in any of the forms listed in the next figure.

+ 

+defgeneric                 do-external-symbols   prog                      
+define-compiler-macro      do-symbols            prog*                     
+define-method-combination  dolist                restart-case              
+define-setf-expander       dotimes               symbol-macrolet           
+defmacro                   flet                  with-accessors            
+defmethod                  handler-case          with-hash-table-iterator  
+defsetf                    labels                with-input-from-string    
+deftype                    let                   with-open-file            
+defun                      let*                  with-open-stream          
+destructuring-bind         locally               with-output-to-string     
+do                         macrolet              with-package-iterator     
+do*                        multiple-value-bind   with-slots                
+do-all-symbols             pprint-logical-block                            
+
+

Figure 3-23. Standardized Forms In Which Declarations Can Occur

+A declare expression can only occur where specified by the syntax of these forms. The consequences of attempting to evaluate a declare expression are undefined. In situations where such expressions can appear, explicit checks are made for their presence and they are never actually evaluated; it is for this reason that they are called ``declare expressions'' rather than ``declare forms.''

+ Macro forms cannot expand into declarations; declare expressions must appear as actual subexpressions of the form to which they refer.

+The next figure shows a list of declaration identifiers that can be used with declare.

+ 

+dynamic-extent  ignore     optimize  
+ftype           inline     special   
+ignorable       notinline  type      
+
+

Figure 3-24. Local Declaration Specifiers

+An implementation is free to support other (implementation-defined) declaration identifiers as well.

+

Examples:

+

+

+ (defun nonsense (k x z)
+   (foo z x)                     ;First call to foo
+   (let ((j (foo k x))           ;Second call to foo
+         (x (* k k)))
+     (declare (inline foo) (special x z))
+     (foo x j z)))               ;Third call to foo
+
+

+In this example, the inline declaration applies only to the third call to foo, but not to the first or second ones. The special declaration of x causes let to make a dynamic binding for x, and causes the reference to x in the body of let to be a dynamic reference. The reference to x in the second call to foo is a local reference to the second parameter of nonsense. The reference to x in the first call to foo is a local reference, not a special one. The special declaration of z causes the reference to z in the third call to foo to be a dynamic reference; it does not refer to the parameter to nonsense named z, because that parameter binding has not been declared to be special. (The special declaration of z does not appear in the body of defun, but in an inner form, and therefore does not affect the binding of the parameter.)

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences of trying to use a declare expression as a form to be evaluated are undefined.

+

+

See Also:

+

+proclaim, Section 4.2.3 (Type Specifiers), declaration, dynamic-extent, ftype, ignorable, ignore, inline, notinline, optimize, type

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_eval_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_eval_w.htm new file mode 100644 index 00000000..092fe9cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_eval_w.htm @@ -0,0 +1,157 @@ + + + +CLHS: Special Operator EVAL-WHEN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator EVAL-WHEN

+

Syntax:

+

+ +eval-when (situation*) form* => result*

+

+

Arguments and Values:

+

+ situation---One of the symbols :compile-toplevel, :load-toplevel, :execute, compile, load, or eval.

+The use of eval, compile, and load is deprecated.

+forms---an implicit progn.

+results---the values of the forms if they are executed, or nil if they are not.

+

Description:

+

+ The body of an eval-when form is processed as an implicit progn, but only in the situations listed.

+ The use of the situations :compile-toplevel (or compile) and :load-toplevel (or load) controls whether and when evaluation occurs when eval-when appears as a top level form in code processed by compile-file. See Section 3.2.3 (File Compilation).

+The use of the situation :execute (or eval) controls whether evaluation occurs for other eval-when forms; that is, those that are not top level forms, or those in code processed by eval or compile. If the :execute situation is specified in such a form, then the body forms are processed as an implicit progn; otherwise, the eval-when form returns nil.

+

+ eval-when normally appears as a top level form, but it is meaningful for it to appear as a non-top-level form. However, the compile-time side effects described in Section 3.2 (Compilation) only take place when eval-when appears as a top level form.

+

Examples:

+

+One example of the use of eval-when is that for the compiler to be able to read a file properly when it uses user-defined reader macros, it is necessary to write

+

+ (eval-when (:compile-toplevel :load-toplevel :execute)
+   (set-macro-character #\$ #'(lambda (stream char)
+                                (declare (ignore char))
+                                (list 'dollar (read stream))))) =>  T
+
+ This causes the call to set-macro-character to be executed in the compiler's execution environment, thereby modifying its reader syntax table.

+

+;;;     The EVAL-WHEN in this case is not at toplevel, so only the :EXECUTE
+;;;     keyword is considered. At compile time, this has no effect.
+;;;     At load time (if the LET is at toplevel), or at execution time
+;;;     (if the LET is embedded in some other form which does not execute
+;;;     until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
+;;;     returns 1.
+ (let ((x 1))
+   (eval-when (:execute :load-toplevel :compile-toplevel)
+     (setf (symbol-function 'foo1) #'(lambda () x))))
+
+;;;     If this expression occurs at the toplevel of a file to be compiled,
+;;;     it has BOTH a compile time AND a load-time effect of setting
+;;;     (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
+ (eval-when (:execute :load-toplevel :compile-toplevel)
+   (let ((x 2))
+     (eval-when (:execute :load-toplevel :compile-toplevel)
+       (setf (symbol-function 'foo2) #'(lambda () x)))))
+
+;;;     If this expression occurs at the toplevel of a file to be compiled,
+;;;     it has BOTH a compile time AND a load-time effect of setting the
+;;;     function cell of FOO3 to a function which returns 3.
+ (eval-when (:execute :load-toplevel :compile-toplevel)
+   (setf (symbol-function 'foo3) #'(lambda () 3)))
+ 
+;;; #4: This always does nothing. It simply returns NIL.
+ (eval-when (:compile-toplevel)
+   (eval-when (:compile-toplevel) 
+     (print 'foo4)))
+
+;;;     If this form occurs at toplevel of a file to be compiled, FOO5 is
+;;;     printed at compile time. If this form occurs in a non-top-level
+;;;     position, nothing is printed at compile time. Regardless of context,
+;;;     nothing is ever printed at load time or execution time.
+ (eval-when (:compile-toplevel) 
+   (eval-when (:execute)
+     (print 'foo5)))
+ 
+;;;     If this form occurs at toplevel of a file to be compiled, FOO6 is
+;;;     printed at compile time.  If this form occurs in a non-top-level
+;;;     position, nothing is printed at compile time. Regardless of context,
+;;;     nothing is ever printed at load time or execution time.
+ (eval-when (:execute :load-toplevel)
+   (eval-when (:compile-toplevel)
+     (print 'foo6)))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+compile-file, Section 3.2 (Compilation)

+

Notes:

+

+ The following effects are logical consequences of the definition of eval-when:

+

* Execution of a single eval-when expression executes the body code at most once.

+
* Macros intended for use in top level forms should be written so that side-effects are done by the forms in the macro expansion. The macro-expander itself should not do the side-effects.

+For example:

+ Wrong:

+

+ (defmacro foo ()
+   (really-foo)
+   `(really-foo))
+
+

+ Right:

+

+ (defmacro foo ()
+   `(eval-when (:compile-toplevel :execute :load-toplevel) (really-foo)))
+
+

+Adherence to this convention means that such macros behave intuitively when appearing as non-top-level forms.

+

* Placing a variable binding around an eval-when reliably captures the binding because the compile-time-too mode cannot occur (i.e., introducing a variable binding means that the eval-when is not a top level form). For example,

+
+ (let ((x 3))
+   (eval-when (:execute :load-toplevel :compile-toplevel) (print x)))
+
+

+prints 3 at execution (i.e., load) time, and does not print anything at compile time. This is important so that expansions of defun and defmacro can be done in terms of eval-when and can correctly capture the lexical environment.

+

+ (defun bar (x) (defun foo () (+ x 3)))
+
+

+might expand into

+

+ (defun bar (x) 
+   (progn (eval-when (:compile-toplevel) 
+            (compiler::notice-function-definition 'foo '(x)))
+          (eval-when (:execute :load-toplevel)
+            (setf (symbol-function 'foo) #'(lambda () (+ x 3))))))
+
+

+which would be treated by the above rules the same as

+

+ (defun bar (x) 
+   (setf (symbol-function 'foo) #'(lambda () (+ x 3))))
+
+

+when the definition of bar is not a top level form.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_flet_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_flet_.htm new file mode 100644 index 00000000..668d1d3e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_flet_.htm @@ -0,0 +1,167 @@ + + + +CLHS: Special Operator FLET, LABELS, MACROLET + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator FLET, LABELS, MACROLET

+

+

Syntax:

+

+ +flet ((function-name lambda-list [[local-declaration* | local-documentation]] local-form*)*) declaration* form*

=> result*

+

+ +labels ((function-name lambda-list [[local-declaration* | local-documentation]] local-form*)*) declaration* form*

=> result*

+

+ +macrolet ((name lambda-list [[local-declaration* | local-documentation]] local-form*)*) declaration* form*

=> result*

+

+

Arguments and Values:

+

+ function-name---a function name.

+name---a symbol.

+lambda-list---a lambda list; for flet and labels, it is an ordinary lambda list; for macrolet, it is a macro lambda list.

+local-declaration---a declare expression; not evaluated.

+declaration---a declare expression; not evaluated.

+local-documentation---a string; not evaluated.

+local-forms, forms---an implicit progn.

+results---the values of the forms.

+

Description:

+

+flet, labels, and macrolet define local functions and macros, and execute forms using the local definitions. Forms are executed in order of occurrence.

+ The body forms (but not the lambda list) of each function created by flet and labels and each macro created by macrolet are enclosed in an implicit block whose name is the function block name of the function-name or name, as appropriate.

+ The scope of the declarations between the list of local function/macro definitions and the body forms in flet and labels does not include the bodies of the locally defined functions, except that for labels, any inline, notinline, or ftype declarations that refer to the locally defined functions do apply to the local function bodies. That is, their scope is the same as the function name that they affect. The scope of these declarations does not include the bodies of the macro expander functions defined by macrolet.

+

flet

+flet defines locally named functions and executes a series of forms with these definition bindings. Any number of such local functions can be defined.

+The scope of the name binding encompasses only the body. Within the body of flet, function-names matching those defined by flet refer to the locally defined functions rather than to the global function definitions of the same name. Also, within the scope of flet, global setf expander definitions of the function-name defined by flet do not apply. Note that this applies to (defsetf f ...), not (defmethod (setf f) ...).

+The names of functions defined by flet are in the lexical environment; they retain their local definitions only within the body of flet. The function definition bindings are visible only in the body of flet, not the definitions themselves. Within the function definitions, local function names that match those being defined refer to functions or macros defined outside the flet. flet can locally shadow a global function name, and the new definition can refer to the global definition.

+Any local-documentation is attached to the corresponding local function (if one is actually created) as a documentation string.

+

labels

+labels is equivalent to flet except that the scope of the defined function names for labels encompasses the function definitions themselves as well as the body.

+

macrolet

+macrolet establishes local macro definitions, using the same format used by defmacro.

+ Within the body of macrolet, global setf expander definitions of the names defined by the macrolet do not apply; rather, setf expands the macro form and recursively process the resulting form.

+The macro-expansion functions defined by macrolet are defined in the lexical environment in which the macrolet form appears. Declarations and macrolet and symbol-macrolet definitions affect the local macro definitions in a macrolet, but the consequences are undefined if the local macro definitions reference any local variable or function bindings that are visible in that lexical environment.

+Any local-documentation is attached to the corresponding local macro function as a documentation string.

+

+

Examples:

+

+

+ (defun foo (x flag)
+   (macrolet ((fudge (z)
+                 ;The parameters x and flag are not accessible
+                 ; at this point; a reference to flag would be to
+                 ; the global variable of that name.
+                 ` (if flag (* ,z ,z) ,z)))
+    ;The parameters x and flag are accessible here.
+     (+ x
+        (fudge x)
+        (fudge (+ x 1)))))
+ == 
+ (defun foo (x flag)
+   (+ x
+      (if flag (* x x) x)
+      (if flag (* (+ x 1) (+ x 1)) (+ x 1))))
+
+ after macro expansion. The occurrences of x and flag legitimately refer to the parameters of the function foo because those parameters are visible at the site of the macro call which produced the expansion.

+

+

+ (flet ((flet1 (n) (+ n n)))
+    (flet ((flet1 (n) (+ 2 (flet1 n))))
+      (flet1 2))) =>  6
+
+ (defun dummy-function () 'top-level) =>  DUMMY-FUNCTION 
+ (funcall #'dummy-function) =>  TOP-LEVEL 
+ (flet ((dummy-function () 'shadow)) 
+      (funcall #'dummy-function)) =>  SHADOW 
+ (eq (funcall #'dummy-function) (funcall 'dummy-function))
+=>  true 
+ (flet ((dummy-function () 'shadow))
+   (eq (funcall #'dummy-function)
+       (funcall 'dummy-function)))
+=>  false 
+
+ (defun recursive-times (k n)
+   (labels ((temp (n) 
+              (if (zerop n) 0 (+ k (temp (1- n))))))
+     (temp n))) =>  RECURSIVE-TIMES
+ (recursive-times 2 3) =>  6
+
+ (defmacro mlets (x &environment env) 
+    (let ((form `(babbit ,x)))
+      (macroexpand form env))) =>  MLETS
+ (macrolet ((babbit (z) `(+ ,z ,z))) (mlets 5)) =>  10
+
+

+

+ (flet ((safesqrt (x) (sqrt (abs x))))
+  ;; The safesqrt function is used in two places.
+   (safesqrt (apply #'+ (map 'list #'safesqrt '(1 2 3 4 5 6)))))
+=>  3.291173
+
+

+

+ (defun integer-power (n k)     
+   (declare (integer n))         
+   (declare (type (integer 0 *) k))
+   (labels ((expt0 (x k a)
+              (declare (integer x a) (type (integer 0 *) k))
+              (cond ((zerop k) a)
+                    ((evenp k) (expt1 (* x x) (floor k 2) a))
+                    (t (expt0 (* x x) (floor k 2) (* x a)))))
+            (expt1 (x k a)
+              (declare (integer x a) (type (integer 0 *) k))
+              (cond ((evenp k) (expt1 (* x x) (floor k 2) a))
+                    (t (expt0 (* x x) (floor k 2) (* x a))))))
+    (expt0 n k 1))) =>  INTEGER-POWER
+
+

+ +

+ (defun example (y l)
+   (flet ((attach (x)
+            (setq l (append l (list x)))))
+     (declare (inline attach))
+     (dolist (x y)
+       (unless (null (cdr x))
+         (attach x)))
+     l))
+
+ (example '((a apple apricot) (b banana) (c cherry) (d) (e))
+          '((1) (2) (3) (4 2) (5) (6 3 2)))
+=>  ((1) (2) (3) (4 2) (5) (6 3 2) (A APPLE APRICOT) (B BANANA) (C CHERRY))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+declare, defmacro, defun, documentation, let, Section 3.1 (Evaluation), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+

+It is not possible to define recursive functions with flet. labels can be used to define mutually recursive functions.

+If a macrolet form is a top level form, the body forms are also processed as top level forms. See Section 3.2.3 (File Compilation).

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_fn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_fn.htm new file mode 100644 index 00000000..3f34552e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_fn.htm @@ -0,0 +1,66 @@ + + + +CLHS: Special Operator FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator FUNCTION

+

+

Syntax:

+

+ +function name => function

+

+

Arguments and Values:

+

+name---a function name or lambda expression.

+function---a function object.

+

Description:

+

+The value of function is the functional value of name in the current lexical environment.

+If name is a function name, the functional definition of that name is that established by the innermost lexically enclosing flet, labels, or macrolet form, if there is one. Otherwise the global functional definition of the function name is returned.

+If name is a lambda expression, then a lexical closure is returned. In situations where a closure over the same set of bindings might be produced more than once, the various resulting closures might or might not be eq.

+ It is an error to use function on a function name that does not denote a function in the lexical environment in which the function form appears. Specifically, it is an error to use function on a symbol that denotes a macro or special form. An implementation may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a useful behavior.

+

Examples:

+

+

+ (defun adder (x) (function (lambda (y) (+ x y))))
+
+ The result of (adder 3) is a function that adds 3 to its argument:

+

+ (setq add3 (adder 3))
+ (funcall add3 5) =>  8
+
+ This works because function creates a closure of the lambda expression that is able to refer to the value 3 of the variable x even after control has returned from the function adder.

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+defun, fdefinition, flet, labels, symbol-function, Section 3.1.2.1.1 (Symbols as Forms), Section 2.4.8.2 (Sharpsign Single-Quote), Section 22.1.3.13 (Printing Other Objects)

+

Notes:

+

+The notation #'name may be used as an abbreviation for (function name).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_go.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_go.htm new file mode 100644 index 00000000..ae5258d8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_go.htm @@ -0,0 +1,73 @@ + + + +CLHS: Special Operator GO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator GO

+

Syntax:

+

+ +go tag =>|

+

+

Arguments and Values:

+

+tag---a go tag.

+

Description:

+

+go transfers control to the point in the body of an enclosing tagbody form labeled by a tag eql to tag. If there is no such tag in the body, the bodies of lexically containing tagbody forms (if any) are examined as well. If several tags are eql to tag, control is transferred to whichever matching tag is contained in the innermost tagbody form that contains the go. The consequences are undefined if there is no matching tag lexically visible to the point of the go.

+The transfer of control initiated by go is performed as described in Section 5.2 (Transfer of Control to an Exit Point).

+

Examples:

+ +

+ (tagbody
+   (setq val 2)
+   (go lp)
+   (incf val 3)
+   lp (incf val 4)) =>  NIL
+ val =>  6 
+
+

+

+The following is in error because there is a normal exit of the tagbody before the go is executed.

+

+ (let ((a nil)) 
+   (tagbody t (setq a #'(lambda () (go t))))
+   (funcall a))
+
+

+The following is in error because the tagbody is passed over before the go form is executed.

+

+ (funcall (block nil
+            (tagbody a (return #'(lambda () (go a))))))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+tagbody

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_if.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_if.htm new file mode 100644 index 00000000..4c634ab5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_if.htm @@ -0,0 +1,73 @@ + + + +CLHS: Special Operator IF + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator IF

+

Syntax:

+

+ +if test-form then-form [else-form] => result*

+

+

Arguments and Values:

+

+Test-form---a form.

+Then-form---a form.

+Else-form---a form. The default is nil.

+results---if the test-form yielded true, the values returned by the then-form; otherwise, the values returned by the else-form.

+

Description:

+

+if allows the execution of a form to be dependent on a single test-form.

+First test-form is evaluated. If the result is true, then then-form is selected; otherwise else-form is selected. Whichever form is selected is then evaluated.

+

Examples:

+

+

+ (if t 1) =>  1
+ (if nil 1 2) =>  2 
+ (defun test ()
+   (dolist (truth-value '(t nil 1 (a b c)))
+     (if truth-value (print 'true) (print 'false))
+     (prin1 truth-value))) =>  TEST
+ (test)
+>>  TRUE T
+>>  FALSE NIL
+>>  TRUE 1
+>>  TRUE (A B C)
+=>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+cond, unless, when

+

Notes:

+

+

+ (if test-form then-form else-form)
+ ==  (cond (test-form then-form) (t else-form))
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_lambda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_lambda.htm new file mode 100644 index 00000000..b641648b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_lambda.htm @@ -0,0 +1,59 @@ + + + +CLHS: Symbol LAMBDA + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Symbol LAMBDA

+

+

Syntax:

+

+ +lambda lambda-list [[declaration* | documentation]] form*

+

+

Arguments:

+

+lambda-list---an ordinary lambda list.

+declaration---a declare expression; not evaluated.

+documentation---a string; not evaluated.

+form---a form.

+

Description:

+

+A lambda expression is a list that can be used in place of a function name in certain contexts to denote a function by directly describing its behavior rather than indirectly by referring to the name of an established function.

+Documentation is attached to the denoted function (if any is actually created) as a documentation string.

+

See Also:

+

+function, documentation, Section 3.1.3 (Lambda Expressions), Section 3.1.2.1.2.4 (Lambda Forms), Section 3.4.11 (Syntactic Interaction of Documentation Strings and Declarations)

+

Notes:

+

+The lambda form

+

+ ((lambda lambda-list . body) . arguments)
+
+

+is semantically equivalent to the function form

+

+ (funcall #'(lambda lambda-list . body) . arguments)
+
+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ld_tim.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ld_tim.htm new file mode 100644 index 00000000..b42cde1e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ld_tim.htm @@ -0,0 +1,99 @@ + + + +CLHS: Special Operator LOAD-TIME-VALUE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator LOAD-TIME-VALUE

+

Syntax:

+

+ +load-time-value form &optional read-only-p => object

+

+

Arguments and Values:

+

+form---a form; evaluated as described below.

+read-only-p---a boolean; not evaluated.

+object---the primary value resulting from evaluating form.

+

Description:

+

+load-time-value provides a mechanism for delaying evaluation of form until the expression is in the run-time environment; see Section 3.2 (Compilation).

+Read-only-p designates whether the result can be considered a constant object. If t, the result is a read-only quantity that can, if appropriate to the implementation, be copied into read-only space and/or coalesced with similar constant objects from other programs. If nil (the default), the result must be neither copied nor coalesced; it must be considered to be potentially modifiable data.

+If a load-time-value expression is processed by compile-file, the compiler performs its normal semantic processing (such as macro expansion and translation into machine code) on form, but arranges for the execution of form to occur at load time in a null lexical environment, with the result of this evaluation then being treated as a literal object at run time. It is guaranteed that the evaluation of form will take place only once when the file is loaded, but the order of evaluation with respect to the evaluation of top level forms in the file is implementation-dependent.

+If a load-time-value expression appears within a function compiled with compile, the form is evaluated at compile time in a null lexical environment. The result of this compile-time evaluation is treated as a literal object in the compiled code.

+If a load-time-value expression is processed by eval, form is evaluated in a null lexical environment, and one value is returned. Implementations that implicitly compile (or partially compile) expressions processed by eval might evaluate form only once, at the time this compilation is performed.

+If the same list (load-time-value form) is evaluated or compiled more than once, it is implementation-dependent whether form is evaluated only once or is evaluated more than once. This can happen both when an expression being evaluated or compiled shares substructure, and when the same form is processed by eval or compile multiple times. Since a load-time-value expression can be referenced in more than one place and can be evaluated multiple times by eval, it is implementation-dependent whether each execution returns a fresh object or returns the same object as some other execution. Users must use caution when destructively modifying the resulting object.

+If two lists (load-time-value form) that are the same under equal but are not identical are evaluated or compiled, their values always come from distinct evaluations of form. Their values may not be coalesced unless read-only-p is t.

+

Examples:

+

+

+;;; The function INCR1 always returns the same value, even in different images.
+;;; The function INCR2 always returns the same value in a given image, 
+;;; but the value it returns might vary from image to image.
+(defun incr1 (x) (+ x #.(random 17)))
+(defun incr2 (x) (+ x (load-time-value (random 17))))
+
+;;; The function FOO1-REF references the nth element of the first of 
+;;; the *FOO-ARRAYS* that is available at load time.  It is permissible for
+;;; that array to be modified (e.g., by SET-FOO1-REF); FOO1-REF will see the
+;;; updated values.
+(defvar *foo-arrays* (list (make-array 7) (make-array 8)))
+(defun foo1-ref (n) (aref (load-time-value (first *my-arrays*) nil) n))
+(defun set-foo1-ref (n val) 
+  (setf (aref (load-time-value (first *my-arrays*) nil) n) val))
+
+;;; The function BAR1-REF references the nth element of the first of 
+;;; the *BAR-ARRAYS* that is available at load time.  The programmer has
+;;; promised that the array will be treated as read-only, so the system 
+;;; can copy or coalesce the array.
+(defvar *bar-arrays* (list (make-array 7) (make-array 8)))
+(defun bar1-ref (n) (aref (load-time-value (first *my-arrays*) t) n))
+
+;;; This use of LOAD-TIME-VALUE permits the indicated vector to be coalesced
+;;; even though NIL was specified, because the object was already read-only
+;;; when it was written as a literal vector rather than created by a constructor.
+;;; User programs must treat the vector v as read-only.
+(defun baz-ref (n)
+  (let ((v (load-time-value #(A B C) nil)))
+    (values (svref v n) v)))
+
+;;; This use of LOAD-TIME-VALUE permits the indicated vector to be coalesced
+;;; even though NIL was specified in the outer situation because T was specified
+;;; in the inner situation.  User programs must treat the vector v as read-only.
+(defun baz-ref (n)
+  (let ((v (load-time-value (load-time-value (vector 1 2 3) t) nil)))
+    (values (svref v n) v)))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+compile-file, compile, eval, Section 3.2.2.2 (Minimal Compilation), Section 3.2 (Compilation)

+

Notes:

+

+load-time-value must appear outside of quoted structure in a ``for evaluation'' position. In situations which would appear to call for use of load-time-value within a quoted structure, the backquote reader macro is probably called for; see Section 2.4.6 (Backquote).

+Specifying nil for read-only-p is not a way to force an object to become modifiable if it has already been made read-only. It is only a way to say that, for an object that is modifiable, this operation is not intended to make that object read-only.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_let_l.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_let_l.htm new file mode 100644 index 00000000..165e9cb0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_let_l.htm @@ -0,0 +1,115 @@ + + + +CLHS: Special Operator LET, LET* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator LET, LET*

+

+

Syntax:

+

+ +let ({var | (var [init-form])}*) declaration* form* => result*

+

+ +let* ({var | (var [init-form])}*) declaration* form* => result*

+

+

Arguments and Values:

+

+var---a symbol.

+init-form---a form.

+declaration---a declare expression; not evaluated.

+form---a form.

+results---the values returned by the forms.

+

Description:

+

+let and let* create new variable bindings and execute a series of forms that use these bindings. let performs the bindings in parallel and let* does them sequentially.

+The form

+ +

+ (let ((var1 init-form-1)
+       (var2 init-form-2)
+       ...
+       (varm init-form-m))
+   declaration1
+   declaration2
+   ...
+   declarationp
+   form1
+   form2
+   ...
+   formn)
+
+ first evaluates the expressions init-form-1, init-form-2, and so on, in that order, saving the resulting values. Then all of the variables varj are bound to the corresponding values; each binding is lexical unless there is a special declaration to the contrary. The expressions formk are then evaluated in order; the values of all but the last are discarded (that is, the body of a let is an implicit progn).

+let* is similar to let, but the bindings of variables are performed sequentially rather than in parallel. The expression for the init-form of a var can refer to vars previously bound in the let*.

+The form

+ +

+ (let* ((var1 init-form-1)
+        (var2 init-form-2)
+        ...
+        (varm init-form-m))
+   declaration1
+   declaration2
+   ...
+   declarationp
+   form1
+   form2
+   ...
+   formn)
+
+ first evaluates the expression init-form-1, then binds the variable var1 to that value; then it evaluates init-form-2 and binds var2, and so on. The expressions formj are then evaluated in order; the values of all but the last are discarded (that is, the body of let* is an implicit progn).

+For both let and let*, if there is not an init-form associated with a var, var is initialized to nil.

+The special form let has the property that the scope of the name binding does not include any initial value form. For let*, a variable's scope also includes the remaining initial value forms for subsequent variable bindings.

+

Examples:

+

+

+ (setq a 'top) =>  TOP
+ (defun dummy-function () a) =>  DUMMY-FUNCTION
+ (let ((a 'inside) (b a))
+    (format nil "~S ~S ~S" a b (dummy-function))) =>  "INSIDE TOP TOP" 
+ (let* ((a 'inside) (b a))
+    (format nil "~S ~S ~S" a b (dummy-function))) =>  "INSIDE INSIDE TOP" 
+ (let ((a 'inside) (b a))
+    (declare (special a))
+    (format nil "~S ~S ~S" a b (dummy-function))) =>  "INSIDE TOP INSIDE"
+
+

+The code

+

+ (let (x)
+   (declare (integer x))
+   (setq x (gcd y z))
+   ...)
+
+ is incorrect; although x is indeed set before it is used, and is set to a value of the declared type integer, nevertheless x initially takes on the value nil in violation of the type declaration.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+progv

+

Notes: None. +

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_locall.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_locall.htm new file mode 100644 index 00000000..1e84e2d4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_locall.htm @@ -0,0 +1,93 @@ + + + +CLHS: Special Operator LOCALLY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator LOCALLY

+

+

Syntax:

+

+ +locally declaration* form* => result*

+

+

Arguments and Values:

+

+Declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+ results---the values of the forms.

+

Description:

+

+Sequentially evaluates a body of forms in a lexical environment where the given declarations have effect.

+

Examples:

+

+

+ (defun sample-function (y)  ;this y is regarded as special
+   (declare (special y))                                
+   (let ((y t))              ;this y is regarded as lexical
+     (list y
+           (locally (declare (special y))
+             ;; this next y is regarded as special
+             y))))
+=>  SAMPLE-FUNCTION
+ (sample-function nil) =>  (T NIL) 
+ (setq x '(1 2 3) y '(4 . 5)) =>  (4 . 5)
+
+;;; The following declarations are not notably useful in specific.
+;;; They just offer a sample of valid declaration syntax using LOCALLY.
+ (locally (declare (inline floor) (notinline car cdr))
+          (declare (optimize space))
+    (floor (car x) (cdr y))) =>  0, 1
+
+

+ +

+;;; This example shows a definition of a function that has a particular set
+;;; of OPTIMIZE settings made locally to that definition.
+ (locally (declare (optimize (safety 3) (space 3) (speed 0)))
+   (defun frob (w x y &optional (z (foo x y)))
+     (mumble x y z w)))
+=>  FROB
+
+;;; This is like the previous example, except that the optimize settings
+;;; remain in effect for subsequent definitions in the same compilation unit.
+ (declaim (optimize (safety 3) (space 3) (speed 0)))
+ (defun frob (w x y &optional (z (foo x y)))
+   (mumble x y z w))
+=>  FROB
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+declare

+

Notes:

+

+The special declaration may be used with locally to affect references to, rather than bindings of, variables.

+ If a locally form is a top level form, the body forms are also processed as top level forms. See Section 3.2.3 (File Compilation).

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_mult_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_mult_1.htm new file mode 100644 index 00000000..6c88e720 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_mult_1.htm @@ -0,0 +1,61 @@ + + + +CLHS: Special Operator MULTIPLE-VALUE-PROG1 + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator MULTIPLE-VALUE-PROG1

+

Syntax:

+

+ +multiple-value-prog1 first-form form* => first-form-results

+

+

Arguments and Values:

+

+first-form---a form; evaluated as described below.

+form---a form; evaluated as described below.

+first-form-results---the values resulting from the evaluation of first-form.

+

Description:

+

+multiple-value-prog1 evaluates first-form and saves all the values produced by that form. It then evaluates each form from left to right, discarding their values.

+

Examples:

+

+

+ (setq temp '(1 2 3)) =>  (1 2 3)
+ (multiple-value-prog1
+    (values-list temp)
+    (setq temp nil)
+    (values-list temp)) =>  1, 2, 3
+
+

+

Side Effects: None. +

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+prog1

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_multip.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_multip.htm new file mode 100644 index 00000000..1a0aa086 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_multip.htm @@ -0,0 +1,62 @@ + + + +CLHS: Special Operator MULTIPLE-VALUE-CALL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator MULTIPLE-VALUE-CALL

+

Syntax:

+

+ +multiple-value-call function-form form* => result*

+

+

Arguments and Values:

+

+function-form---a form; evaluated to produce function.

+function---a function designator resulting from the evaluation of function-form.

+form---a form.

+results---the values returned by the function.

+

Description:

+

+Applies function to a list of the objects collected from groups of multiple values[2].

+multiple-value-call first evaluates the function-form to obtain function, and then evaluates each form. All the values of each form are gathered together (not just one value from each) and given as arguments to the function.

+

Examples:

+ +

+ (multiple-value-call #'list 1 '/ (values 2 3) '/ (values) '/ (floor 2.5))
+=>  (1 / 2 3 / / 2 0.5)
+ (+ (floor 5 3) (floor 19 4)) ==  (+ 1 4)
+=>  5
+ (multiple-value-call #'+ (floor 5 3) (floor 19 4)) ==  (+ 1 2 4 3)
+=>  10
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+multiple-value-list, multiple-value-bind

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progn.htm new file mode 100644 index 00000000..115af58c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progn.htm @@ -0,0 +1,64 @@ + + + +CLHS: Special Operator PROGN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator PROGN

+

Syntax:

+

+ +progn form* => result*

+

+

Arguments and Values:

+

+forms---an implicit progn.

+results---the values of the forms.

+

Description:

+

+progn evaluates forms, in the order in which they are given.

+The values of each form but the last are discarded.

+If progn appears as a top level form, then all forms within that progn are considered by the compiler to be top level forms.

+

Examples:

+ +

+ (progn) =>  NIL
+ (progn 1 2 3) =>  3
+ (progn (values 1 2 3)) =>  1, 2, 3
+ (setq a 1) =>  1
+ (if a
+      (progn (setq a nil) 'here)
+      (progn (setq a t) 'there)) =>  HERE
+ a =>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+prog1, prog2, Section 3.1 (Evaluation)

+

Notes:

+

+Many places in Common Lisp involve syntax that uses implicit progns. That is, part of their syntax allows many forms to be written that are to be evaluated sequentially, discarding the results of all forms but the last and returning the results of the last form. Such places include, but are not limited to, the following: the body of a lambda expression; the bodies of various control and conditional forms (e.g., case, catch, progn, and when).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progv.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progv.htm new file mode 100644 index 00000000..6d79aae3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_progv.htm @@ -0,0 +1,66 @@ + + + +CLHS: Special Operator PROGV + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator PROGV

+

Syntax:

+

+ +progv symbols values form* => result*

+

+

Arguments and Values:

+

+symbols---a list of symbols; evaluated.

+values---a list of objects; evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+progv creates new dynamic variable bindings and executes each form using those bindings. Each form is evaluated in order.

+progv allows binding one or more dynamic variables whose names may be determined at run time. Each form is evaluated in order with the dynamic variables whose names are in symbols bound to corresponding values. If too few values are supplied, the remaining symbols are bound and then made to have no value. If too many values are supplied, the excess values are ignored. The bindings of the dynamic variables are undone on exit from progv.

+

Examples:

+ +

+ (setq *x* 1) =>  1
+ (progv '(*x*) '(2) *x*) =>  2
+ *x* =>  1
+
+Assuming *x* is not globally special,
+
+ (let ((*x* 3)) 
+    (progv '(*x*) '(4) 
+      (list *x* (symbol-value '*x*)))) =>  (3 4)
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+let, Section 3.1 (Evaluation)

+

Notes:

+

+Among other things, progv is useful when writing interpreters for languages embedded in Lisp; it provides a handle on the mechanism for binding dynamic variables.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_quote.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_quote.htm new file mode 100644 index 00000000..989f781d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_quote.htm @@ -0,0 +1,72 @@ + + + +CLHS: Special Operator QUOTE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator QUOTE

+

Syntax:

+

+ +quote object => object

+

+

Arguments and Values:

+

+object---an object; not evaluated.

+

Description:

+

+The quote special operator just returns object.

+The consequences are undefined if literal objects (including quoted objects) are destructively modified.

+

Examples:

+

+

+ (setq a 1) =>  1
+ (quote (setq a 3)) =>  (SETQ A 3)
+ a =>  1
+ 'a =>  A
+ ''a =>  (QUOTE A) 
+ '''a =>  (QUOTE (QUOTE A))
+ (setq a 43) =>  43
+ (list a (cons a 3)) =>  (43 (43 . 3))
+ (list (quote a) (quote (cons a 3))) =>  (A (CONS A 3)) 
+ 1 =>  1
+ '1 =>  1
+ "foo" =>  "foo"
+ '"foo" =>  "foo"
+ (car '(a b)) =>  A
+ '(car '(a b)) =>  (CAR (QUOTE (A B)))
+ #(car '(a b)) =>  #(CAR (QUOTE (A B)))
+ '#(car '(a b)) =>  #(CAR (QUOTE (A B)))
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+Section 3.1 (Evaluation), Section 2.4.3 (Single-Quote), Section 3.2.1 (Compiler Terminology)

+

Notes:

+

+The textual notation 'object is equivalent to (quote object); see Section 3.2.1 (Compiler Terminology).

+Some objects, called self-evaluating objects, do not require quotation by quote. However, symbols and lists are used to represent parts of programs, and so would not be useable as constant data in a program without quote. Since quote suppresses the evaluation of these objects, they become data rather than program.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ret_fr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ret_fr.htm new file mode 100644 index 00000000..4bec54af --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_ret_fr.htm @@ -0,0 +1,106 @@ + + + +CLHS: Special Operator RETURN-FROM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator RETURN-FROM

+

Syntax:

+

+ +return-from name [result] =>|

+

+

Arguments and Values:

+

+name---a block tag; not evaluated.

+result---a form; evaluated. The default is nil.

+

Description:

+

+Returns control and multiple values[2] from a lexically enclosing block.

+A block form named name must lexically enclose the occurrence of return-from; any values yielded by the evaluation of result are immediately returned from the innermost such lexically enclosing block.

+The transfer of control initiated by return-from is performed as described in Section 5.2 (Transfer of Control to an Exit Point).

+

Examples:

+

+ +

+ (block alpha (return-from alpha) 1) =>  NIL
+ (block alpha (return-from alpha 1) 2) =>  1
+ (block alpha (return-from alpha (values 1 2)) 3) =>  1, 2
+ (let ((a 0))
+    (dotimes (i 10) (incf a) (when (oddp i) (return)))
+    a) =>  2
+ (defun temp (x)
+    (if x (return-from temp 'dummy))
+    44) =>  TEMP
+ (temp nil) =>  44
+ (temp t) =>  DUMMY
+ (block out
+   (flet ((exit (n) (return-from out n)))
+     (block out (exit 1)))
+   2) =>  1
+ (block nil   
+   (unwind-protect (return-from nil 1)
+     (return-from nil 2)))
+=>  2
+ (dolist (flag '(nil t))
+   (block nil
+     (let ((x 5))
+       (declare (special x))
+       (unwind-protect (return-from nil)
+         (print x))))
+   (print 'here))
+>>  5
+>>  HERE
+>>  5
+>>  HERE
+=>  NIL
+ (dolist (flag '(nil t))
+   (block nil
+     (let ((x 5))
+       (declare (special x))
+       (unwind-protect
+           (if flag (return-from nil))
+         (print x))))
+   (print 'here))
+>>  5
+>>  HERE
+>>  5
+>>  HERE
+=>  NIL
+
+

+The following has undefined consequences because the block form exits normally before the return-from form is attempted.

+

+ (funcall (block nil #'(lambda () (return-from nil)))) is an error.
+
+

+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+block, return, Section 3.1 (Evaluation)

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_setq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_setq.htm new file mode 100644 index 00000000..86838173 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_setq.htm @@ -0,0 +1,84 @@ + + + +CLHS: Special Form SETQ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Form SETQ

+

Syntax:

+

+ +setq {pair}* => result

+

+

+pair::= var form 
+
+

+

Pronunciation:

+

+['set,kyoo]

+

Arguments and Values:

+

+var---a symbol naming a variable other than a constant variable.

+form---a form.

+result---the primary value of the last form, or nil if no pairs were supplied.

+

Description:

+

+Assigns values to variables.

+(setq var1 form1 var2 form2 ...) is the simple variable assignment statement of Lisp. First form1 is evaluated and the result is stored in the variable var1, then form2 is evaluated and the result stored in var2, and so forth. setq may be used for assignment of both lexical and dynamic variables.

+ If any var refers to a binding made by symbol-macrolet, then that var is treated as if setf (not setq) had been used.

+

Examples:

+

+

+ ;; A simple use of SETQ to establish values for variables.
+ (setq a 1 b 2 c 3) =>  3
+ a =>  1
+ b =>  2
+ c =>  3
+
+ ;; Use of SETQ to update values by sequential assignment.
+ (setq a (1+ b) b (1+ a) c (+ a b)) =>  7
+ a =>  3
+ b =>  4
+ c =>  7
+
+ ;; This illustrates the use of SETQ on a symbol macro.
+ (let ((x (list 10 20 30)))
+   (symbol-macrolet ((y (car x)) (z (cadr x)))
+     (setq y (1+ z) z (1+ y))
+     (list x y z)))
+=>  ((21 22 30) 21 22)
+
+

+

Side Effects:

+

+The primary value of each form is assigned to the corresponding var.

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+psetq, set, setf

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_symbol.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_symbol.htm new file mode 100644 index 00000000..7f7c501f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_symbol.htm @@ -0,0 +1,78 @@ + + + +CLHS: Special Operator SYMBOL-MACROLET + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator SYMBOL-MACROLET

+

+

Syntax:

+

+ +symbol-macrolet ((symbol expansion)*) declaration* form*

=> result*

+

+

Arguments and Values:

+

+symbol---a symbol.

+expansion---a form.

+ declaration---a declare expression; not evaluated.

+forms---an implicit progn.

+results---the values returned by the forms.

+

Description:

+

+symbol-macrolet provides a mechanism for affecting the macro expansion environment for symbols.

+symbol-macrolet lexically establishes expansion functions for each of the symbol macros named by symbols. The only guaranteed property of an expansion function for a symbol macro is that when it is applied to the form and the environment it returns the correct expansion. (In particular, it is implementation-dependent whether the expansion is conceptually stored in the expansion function, the environment, or both.)

+Each reference to symbol as a variable within the lexical scope of symbol-macrolet is expanded by the normal macro expansion process; see Section 3.1.2.1.1 (Symbols as Forms). The expansion of a symbol macro is subject to further macro expansion in the same lexical environment as the symbol macro invocation, exactly analogous to normal macros.

+ Exactly the same declarations are allowed as for let with one exception: symbol-macrolet signals an error if a special declaration names one of the symbols being defined by symbol-macrolet.

+When the forms of the symbol-macrolet form are expanded, any use of setq to set the value of one of the specified variables is treated as if it were a setf. psetq of a symbol defined as a symbol macro is treated as if it were a psetf, and multiple-value-setq is treated as if it were a setf of values.

+The use of symbol-macrolet can be shadowed by let. In other words, symbol-macrolet only substitutes for occurrences of symbol that would be in the scope of a lexical binding of symbol surrounding the forms.

+

Examples:

+

+

+;;; The following is equivalent to
+;;;   (list 'foo (let ((x 'bar)) x)),
+;;; not
+;;;   (list 'foo (let (('foo 'bar)) 'foo))
+ (symbol-macrolet ((x 'foo))
+   (list x (let ((x 'bar)) x))) 
+=>  (foo bar)
+NOT=>  (foo foo) 
+ 
+ (symbol-macrolet ((x '(foo x)))
+   (list x))
+=>  ((FOO X))
+
+

+

Affected By: None. +

+

Exceptional Situations:

+ If an attempt is made to bind a symbol that is defined as a global variable, an error of type program-error is signaled.

+If declaration contains a special declaration that names one of the symbols being bound by symbol-macrolet, an error of type program-error is signaled.

+

See Also:

+

+with-slots, macroexpand

+

Notes:

+

+The special form symbol-macrolet is the basic mechanism that is used to implement with-slots.

+If a symbol-macrolet form is a top level form, the forms are also processed as top level forms. See Section 3.2.3 (File Compilation).

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_tagbod.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_tagbod.htm new file mode 100644 index 00000000..6a45587f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_tagbod.htm @@ -0,0 +1,96 @@ + + + +CLHS: Special Operator TAGBODY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator TAGBODY

+

Syntax:

+

+ +tagbody {tag | statement}* => nil

+

+

Arguments and Values:

+

+tag---a go tag; not evaluated.

+statement---a compound form; evaluated as described below.

+

Description:

+

+Executes zero or more statements in a lexical environment that provides for control transfers to labels indicated by the tags.

+The statements in a tagbody are evaluated in order from left to right, and their values are discarded. If at any time there are no remaining statements, tagbody returns nil. However, if (go tag) is evaluated, control jumps to the part of the body labeled with the tag. (Tags are compared with eql.)

+A tag established by tagbody has lexical scope and has dynamic extent. Once tagbody has been exited, it is no longer valid to go to a tag in its body. It is permissible for go to jump to a tagbody that is not the innermost tagbody containing that go; the tags established by a tagbody only shadow other tags of like name.

+ The determination of which elements of the body are tags and which are statements is made prior to any macro expansion of that element. If a statement is a macro form and its macro expansion is an atom, that atom is treated as a statement, not a tag.

+

Examples:

+

+

+ (let (val)
+    (tagbody
+      (setq val 1)
+      (go point-a)
+      (incf val 16)
+     point-c
+      (incf val 04)
+      (go point-b)
+      (incf val 32)
+     point-a
+      (incf val 02)
+      (go point-c)
+      (incf val 64)
+     point-b
+      (incf val 08))
+    val)
+=>  15
+ (defun f1 (flag)
+   (let ((n 1))
+     (tagbody 
+       (setq n (f2 flag #'(lambda () (go out))))
+      out
+       (prin1 n))))
+=>  F1
+ (defun f2 (flag escape)
+   (if flag (funcall escape) 2))
+=>  F2
+ (f1 nil)
+>>  2
+=>  NIL
+ (f1 t)
+>>  1
+=>  NIL
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+go

+

Notes:

+

+The macros in the next figure have implicit tagbodies.

+

+do              do-external-symbols  dotimes  
+do*             do-symbols           prog     
+do-all-symbols  dolist               prog*    
+
+

Figure 5-10. Macros that have implicit tagbodies.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_the.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_the.htm new file mode 100644 index 00000000..f5a89b9e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_the.htm @@ -0,0 +1,83 @@ + + + +CLHS: Special Operator THE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator THE

+

Syntax:

+

+ +the value-type form => result*

+

+

Arguments and Values:

+

+value-type---a type specifier; not evaluated.

+form---a form; evaluated.

+ results---the values resulting from the evaluation of form. These values must conform to the type supplied by value-type; see below.

+

Description:

+

+the specifies that the values[1a] returned by form are of the types specified by value-type. The consequences are undefined if any result is not of the declared type.

+

+ It is permissible for form to yield a different number of values than are specified by value-type, provided that the values for which types are declared are indeed of those types. Missing values are treated as nil for the purposes of checking their types.

+Regardless of number of values declared by value-type, the number of values returned by the the special form is the same as the number of values returned by form.

+

Examples:

+

+ +

+ (the symbol (car (list (gensym)))) =>  #:G9876
+ (the fixnum (+ 5 7)) =>  12
+ (the (values) (truncate 3.2 2)) =>  1, 1.2
+ (the integer (truncate 3.2 2)) =>  1, 1.2
+ (the (values integer) (truncate 3.2 2)) =>  1, 1.2
+ (the (values integer float) (truncate 3.2 2))   =>  1, 1.2
+ (the (values integer float symbol) (truncate 3.2 2)) =>  1, 1.2
+ (the (values integer float symbol t null list) 
+      (truncate 3.2 2)) =>  1, 1.2
+ (let ((i 100))
+    (declare (fixnum i))
+    (the fixnum (1+ i))) =>  101
+ (let* ((x (list 'a 'b 'c))
+        (y 5))
+    (setf (the fixnum (car x)) y)
+    x) =>  (5 B C)
+
+

+

Affected By: None. +

+

Exceptional Situations:

+

+The consequences are undefined if the values yielded by the form are not of the type specified by value-type.

+

See Also:

+

+values

+

Notes:

+

+The values type specifier can be used to indicate the types of multiple values:

+

+ (the (values integer integer) (floor x y))
+ (the (values string t)
+      (gethash the-key the-string-table))
+
+

+setf can be used with the type declarations. In this case the declaration is transferred to the form that specifies the new value. The resulting setf form is then analyzed.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_throw.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_throw.htm new file mode 100644 index 00000000..53d22a05 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_throw.htm @@ -0,0 +1,90 @@ + + + +CLHS: Special Operator THROW + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator THROW

+

Syntax:

+

+ +throw tag result-form =>|

+

+

Arguments and Values:

+

+tag---a catch tag; evaluated.

+result-form---a form; evaluated as described below.

+

Description:

+

+throw causes a non-local control transfer to a catch whose tag is eq to tag.

+Tag is evaluated first to produce an object called the throw tag; then result-form is evaluated, and its results are saved. If the result-form produces multiple values, then all the values are saved. The most recent outstanding catch whose tag is eq to the throw tag is exited; the saved results are returned as the value or values of catch.

+The transfer of control initiated by throw is performed as described in Section 5.2 (Transfer of Control to an Exit Point).

+

Examples:

+

+

+ (catch 'result
+    (setq i 0 j 0)
+    (loop (incf j 3) (incf i)
+          (if (= i 3) (throw 'result (values i j))))) =>  3, 9
+
+
+

+ +

+ (catch nil 
+   (unwind-protect (throw nil 1)
+     (throw nil 2))) =>  2
+
+

+The consequences of the following are undefined because the catch of b is passed over by the first throw, hence portable programs must assume that its dynamic extent is terminated. The binding of the catch tag is not yet disestablished and therefore it is the target of the second throw.

+

+ (catch 'a
+   (catch 'b
+     (unwind-protect (throw 'a 1)
+       (throw 'b 2))))
+
+

+The following prints ``The inner catch returns :SECOND-THROW'' and then returns :outer-catch.

+

+ (catch 'foo
+         (format t "The inner catch returns ~s.~%"
+                 (catch 'foo
+                     (unwind-protect (throw 'foo :first-throw)
+                         (throw 'foo :second-throw))))
+         :outer-catch)
+>>  The inner catch returns :SECOND-THROW
+=>  :OUTER-CATCH
+
+

+

+

Affected By: None. +

+

Exceptional Situations:

+

+If there is no outstanding catch tag that matches the throw tag, no unwinding of the stack is performed, and an error of type control-error is signaled. When the error is signaled, the dynamic environment is that which was in force at the point of the throw.

+

See Also:

+

+block, catch, return-from, unwind-protect, Section 3.1 (Evaluation)

+

Notes:

+

+catch and throw are normally used when the exit point must have dynamic scope (e.g., the throw is not lexically enclosed by the catch), while block and return are used when lexical scope is sufficient.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_unwind.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_unwind.htm new file mode 100644 index 00000000..20f5e04f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/s_unwind.htm @@ -0,0 +1,167 @@ + + + +CLHS: Special Operator UNWIND-PROTECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Special Operator UNWIND-PROTECT

+

Syntax:

+

+ +unwind-protect protected-form cleanup-form* => result*

+

+

Arguments and Values:

+

+protected-form---a form.

+cleanup-form---a form.

+results---the values of the protected-form.

+

Description:

+ unwind-protect evaluates protected-form and guarantees that cleanup-forms are executed before unwind-protect exits, whether it terminates normally or is aborted by a control transfer of some kind. unwind-protect is intended to be used to make sure that certain side effects take place after the evaluation of protected-form.

+If a non-local exit occurs during execution of cleanup-forms, no special action is taken. The cleanup-forms of unwind-protect are not protected by that unwind-protect.

+unwind-protect protects against all attempts to exit from protected-form, including go, handler-case, ignore-errors, restart-case, return-from, throw, and with-simple-restart.

+ Undoing of handler and restart bindings during an exit happens in parallel with the undoing of the bindings of dynamic variables and catch tags, in the reverse order in which they were established. The effect of this is that cleanup-form sees the same handler and restart bindings, as well as dynamic variable bindings and catch tags, as were visible when the unwind-protect was entered.

+

Examples:

+ +

+ (tagbody
+   (let ((x 3))
+     (unwind-protect
+       (if (numberp x) (go out))
+       (print x)))
+  out
+   ...)
+
+ When go is executed, the call to print is executed first, and then the transfer of control to the tag out is completed.

+

+ (defun dummy-function (x)
+    (setq state 'running)
+    (unless (numberp x) (throw 'abort 'not-a-number))
+    (setq state (1+ x))) =>  DUMMY-FUNCTION
+ (catch 'abort (dummy-function 1)) =>  2
+ state =>  2
+ (catch 'abort (dummy-function 'trash)) =>  NOT-A-NUMBER
+ state =>  RUNNING
+ (catch 'abort (unwind-protect (dummy-function 'trash) 
+                  (setq state 'aborted))) =>  NOT-A-NUMBER
+ state =>  ABORTED
+
+

+The following code is not correct:

+

+ (unwind-protect
+   (progn (incf *access-count*)
+          (perform-access))
+   (decf *access-count*))
+
+ If an exit occurs before completion of incf, the decf form is executed anyway, resulting in an incorrect value for *access-count*. The correct way to code this is as follows:

+

+ (let ((old-count *access-count*))
+   (unwind-protect
+     (progn (incf *access-count*)
+            (perform-access))
+     (setq *access-count* old-count)))
+
+

+

+

+;;; The following returns 2.
+ (block nil   
+   (unwind-protect (return 1)
+     (return 2)))
+ 
+;;; The following has undefined consequences.
+ (block a    
+   (block b
+     (unwind-protect (return-from a 1)
+       (return-from b 2))))
+ 
+;;; The following returns 2.
+ (catch nil 
+   (unwind-protect (throw nil 1)
+     (throw nil 2)))
+ 
+;;; The following has undefined consequences because the catch of B is 
+;;; passed over by the first THROW, hence portable programs must assume 
+;;; its dynamic extent is terminated.  The binding of the catch tag is not
+;;; yet disestablished and therefore it is the target of the second throw.
+ (catch 'a
+   (catch 'b
+     (unwind-protect (throw 'a 1)
+       (throw 'b 2))))
+ 
+;;; The following prints "The inner catch returns :SECOND-THROW"
+;;; and then returns :OUTER-CATCH.
+ (catch 'foo
+         (format t "The inner catch returns ~s.~%"
+                 (catch 'foo
+                     (unwind-protect (throw 'foo :first-throw)
+                         (throw 'foo :second-throw))))
+         :outer-catch)
+ 
+ 
+;;; The following returns 10. The inner CATCH of A is passed over, but 
+;;; because that CATCH is disestablished before the THROW to A is executed,
+;;; it isn't seen.
+ (catch 'a
+   (catch 'b
+     (unwind-protect (1+ (catch 'a (throw 'b 1)))
+       (throw 'a 10))))
+ 
+ 
+;;; The following has undefined consequences because the extent of
+;;; the (CATCH 'BAR ...) exit ends when the (THROW 'FOO ...)
+;;; commences.
+ (catch 'foo
+   (catch 'bar
+       (unwind-protect (throw 'foo 3)
+         (throw 'bar 4)
+         (print 'xxx))))
+ 
+ 
+;;; The following returns 4; XXX is not printed.
+;;; The (THROW 'FOO ...) has no effect on the scope of the BAR
+;;; catch tag or the extent of the (CATCH 'BAR ...) exit.
+ (catch 'bar
+   (catch 'foo
+       (unwind-protect (throw 'foo 3)
+         (throw 'bar 4)
+         (print 'xxx))))
+ 
+ 
+;;; The following prints 5.
+ (block nil
+   (let ((x 5))
+     (declare (special x))
+     (unwind-protect (return)
+       (print x))))          
+
+

+

Affected By: None. +

+

Exceptional Situations: None. +

+

See Also:

+

+catch, go, handler-case, restart-case, return, return-from, throw, Section 3.1 (Evaluation)

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_and.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_and.htm new file mode 100644 index 00000000..e6d25f19 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_and.htm @@ -0,0 +1,43 @@ + + + +CLHS: Type Specifier AND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier AND

+

Compound Type Specifier Kind:

+

+Combining.

+

Compound Type Specifier Syntax:

+

+ +and typespec*

+

+

Compound Type Specifier Arguments:

+

+typespec---a type specifier.

+

Compound Type Specifier Description:

+

+This denotes the set of all objects of the type determined by the intersection of the typespecs.

+ * is not permitted as an argument.

+The type specifiers (and) and t are equivalent. The symbol and is not valid as a type specifier, and, specifically, it is not an abbreviation for (and).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_array.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_array.htm new file mode 100644 index 00000000..c8ef6b78 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_array.htm @@ -0,0 +1,62 @@ + + + +CLHS: System Class ARRAY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class ARRAY

+

Class Precedence List:

+ array, t

+

Description:

+

+An array contains objects arranged according to a Cartesian coordinate system. An array provides mappings from a set of fixnums {i0,i1,...,ir-1} to corresponding elements of the array, where 0 <=ij < dj, r is the rank of the array, and dj is the size of dimension j of the array.

+When an array is created, the program requesting its creation may declare that all elements are of a particular type, called the expressed array element type. The implementation is permitted to upgrade this type in order to produce the actual array element type, which is the element type for the array is actually specialized. See the function upgraded-array-element-type.

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +array [{element-type | *} [dimension-spec]]

+

+

+dimension-spec::= rank | * | ({dimension | *}*) 
+
+

+

Compound Type Specifier Arguments:

+

+dimension---a valid array dimension.

+element-type---a type specifier.

+ rank---a non-negative fixnum.

+

Compound Type Specifier Description:

+

+This denotes the set of arrays whose element type, rank, and dimensions match any given element-type, rank, and dimensions. Specifically:

+If element-type is the symbol *, arrays are not excluded on the basis of their element type. Otherwise, only those arrays are included whose actual array element type is the result of upgrading element-type; see Section 15.1.2.1 (Array Upgrading).

+If the dimension-spec is a rank, the set includes only those arrays having that rank. If the dimension-spec is a list of dimensions, the set includes only those arrays having a rank given by the length of the dimensions, and having the indicated dimensions; in this case, * matches any value for the corresponding dimension. If the dimension-spec is the symbol *, the set is not restricted on the basis of rank or dimension.

+

+

See Also:

+

+*print-array*, aref, make-array, vector, Section 2.4.8.12 (Sharpsign A), Section 22.1.3.8 (Printing Other Arrays)

+

Notes:

+

+Note that the type (array t) is a proper subtype of the type (array *). The reason is that the type (array t) is the set of arrays that can hold any object (the elements are of type t, which includes all objects). On the other hand, the type (array *) is the set of all arrays whatsoever, including for example arrays that can hold only characters. The type (array character) is not a subtype of the type (array t); the two sets are disjoint because the type (array character) is not the set of all arrays that can hold characters, but rather the set of arrays that are specialized to hold precisely characters and no other objects.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_atom.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_atom.htm new file mode 100644 index 00000000..8ed41156 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_atom.htm @@ -0,0 +1,33 @@ + + + +CLHS: Type ATOM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type ATOM

+

Supertypes:

+

+atom, t

+

Description:

+

+It is equivalent to (not cons).

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ban.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ban.htm new file mode 100644 index 00000000..e6d43a22 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ban.htm @@ -0,0 +1,39 @@ + + + +CLHS: Type BOOLEAN + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type BOOLEAN

+

Supertypes:

+

+boolean, symbol, t

+

Description:

+

+The type boolean contains the symbols t and nil, which represent true and false, respectively.

+

See Also:

+

+t (constant variable), nil (constant variable), if, not, complement

+

Notes:

+

+Conditional operations, such as if, permit the use of generalized booleans, not just booleans; any non-nil value, not just t, counts as true for a generalized boolean. However, as a matter of convention, the symbol t is considered the canonical value to use even for a generalized boolean when no better choice presents itself.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_c.htm new file mode 100644 index 00000000..7bd472c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_c.htm @@ -0,0 +1,38 @@ + + + +CLHS: Type BASE-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type BASE-CHAR

+

+

Supertypes:

+

+base-char, character, t

+

Description:

+

+The type base-char is defined as the upgraded array element type of standard-char. An implementation can support additional subtypes of type character (besides the ones listed in this standard) that might or might not be supertypes of type base-char. In addition, an implementation can define base-char to be the same type as character.

+Base characters are distinguished in the following respects:

1. The type standard-char is a subrepertoire of the type base-char.
2. The selection of base characters that are not standard characters is implementation defined.
3. Only objects of the type base-char can be elements of a base string.
4. No upper bound is specified for the number of characters in the base-char repertoire; the size of that repertoire is implementation-defined. The lower bound is 96, the number of standard characters.

+ Whether a character is a base character depends on the way that an implementation represents strings, and not any other properties of the implementation or the host operating system. For example, one implementation might encode all strings as characters having 16-bit encodings, and another might have two kinds of strings: those with characters having 8-bit encodings and those with characters having 16-bit encodings. In the first implementation, the type base-char is equivalent to the type character: there is only one kind of string. In the second implementation, the base characters might be those characters that could be stored in a string of characters having 8-bit encodings. In such an implementation, the type base-char is a proper subtype of the type character.

+The type standard-char is a subtype of type base-char.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_s.htm new file mode 100644 index 00000000..a5c7ba8c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_base_s.htm @@ -0,0 +1,49 @@ + + + +CLHS: Type BASE-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type BASE-STRING

+

+

Supertypes:

+

+base-string, string, vector, array, sequence, t

+

Description:

+

+The type base-string is equivalent to (vector base-char). The base string representation is the most efficient string representation that can hold an arbitrary sequence of standard characters.

+

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +base-string [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *.

+

Compound Type Specifier Description:

+

+This is equivalent to the type (vector base-char size); that is, the set of base strings of size size.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bignum.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bignum.htm new file mode 100644 index 00000000..570c4ac9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bignum.htm @@ -0,0 +1,33 @@ + + + +CLHS: Type BIGNUM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type BIGNUM

+

Supertypes:

+

+bignum, integer, rational, real, number, t

+

Description:

+

+ The type bignum is defined to be exactly (and integer (not fixnum)).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bit.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bit.htm new file mode 100644 index 00000000..dadf08e6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bit.htm @@ -0,0 +1,33 @@ + + + +CLHS: Type BIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type BIT

+

Supertypes:

+

+bit, unsigned-byte, signed-byte, integer, rational, real, number, t

+

Description:

+

+The type bit is equivalent to the type (integer 0 1) and (unsigned-byte 1).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_broadc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_broadc.htm new file mode 100644 index 00000000..e108bb37 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_broadc.htm @@ -0,0 +1,49 @@ + + + +CLHS: System Class BROADCAST-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class BROADCAST-STREAM

+

+

Class Precedence List:

+

+broadcast-stream, stream, t

+

Description:

+

+A broadcast stream is an output stream which has associated with it a set of zero or more output streams such that any output sent to the broadcast stream gets passed on as output to each of the associated output streams. (If a broadcast stream has no component streams, then all output to the broadcast stream is discarded.)

+The set of operations that may be performed on a broadcast stream is the intersection of those for its associated output streams.

+Some output operations (e.g., fresh-line) return values based on the state of the stream at the time of the operation. Since these values might differ for each of the component streams, it is necessary to describe their return value specifically:

+

+

* stream-element-type returns the value from the last component stream, or t if there are no component streams.

+
* fresh-line returns the value from the last component stream, or nil if there are no component streams.

+
* The functions file-length, file-position, file-string-length, and stream-external-format return the value from the last component stream; if there are no component streams, file-length and file-position return 0, file-string-length returns 1, and stream-external-format returns :default.

+
* The functions streamp and output-stream-p always return true for broadcast streams.

+
* The functions open-stream-p tests whether the broadcast stream is open[2], not whether its component streams are open.

+
* The functions input-stream-p and interactive-stream-p return an implementation-defined, generalized boolean value.

+
* For the input operations clear-input listen, peek-char, read-byte, read-char-no-hang, read-char, read-line, and unread-char, the consequences are undefined if the indicated operation is performed. However, an implementation is permitted to define such a behavior as an implementation-dependent extension.

+For any output operations not having their return values explicitly specified above or elsewhere in this document, it is defined that the values returned by such an operation are the values resulting from performing the operation on the last of its component streams; the values resulting from performing the operation on all preceding streams are discarded. If there are no component streams, the value is implementation-dependent.

+

See Also:

+

+broadcast-stream-streams, make-broadcast-stream

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bt_vec.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bt_vec.htm new file mode 100644 index 00000000..8fd92392 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_bt_vec.htm @@ -0,0 +1,50 @@ + + + +CLHS: System Class BIT-VECTOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class BIT-VECTOR

+

Class Precedence List:

+ bit-vector, vector, array, sequence, t

+

Description:

+

+A bit vector is a vector the element type of which is bit.

+The type bit-vector is a subtype of type vector, for bit-vector means (vector bit).

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +bit-vector [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the same type as the type (array bit (size)); that is, the set of bit vectors of size size.

+

See Also:

+

+Section 2.4.8.4 (Sharpsign Asterisk), Section 22.1.3.6 (Printing Bit Vectors), Section 15.1.2.2 (Required Kinds of Specialized Arrays)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_built_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_built_.htm new file mode 100644 index 00000000..3f021f87 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_built_.htm @@ -0,0 +1,32 @@ + + + +CLHS: System Class BUILT-IN-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class BUILT-IN-CLASS

+

Class Precedence List:

+ built-in-class, class, standard-object, t

+

Description:

+

+A built-in class is a class whose instances have restricted capabilities or special representations. Attempting to use defclass to define subclasses of a built-in class signals an error of type error. Calling make-instance to create an instance of a built-in class signals an error of type error. Calling slot-value on an instance of a built-in class signals an error of type error. Redefining a built-in class or using change-class to change the class of an instance to or from a built-in class signals an error of type error. However, built-in classes can be used as parameter specializers in methods.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ch.htm new file mode 100644 index 00000000..2a879f2a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ch.htm @@ -0,0 +1,36 @@ + + + +CLHS: System Class CHARACTER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class CHARACTER

+

Class Precedence List:

+ character, t

+

Description:

+

+A character is an object that represents a unitary token in an aggregate quantity of text; see Section 13.1 (Character Concepts).

+ The types base-char and extended-char form an exhaustive partition of the type character.

+

See Also:

+

+Section 13.1 (Character Concepts), Section 2.4.8.1 (Sharpsign Backslash), Section 22.1.3.2 (Printing Characters)

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_class.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_class.htm new file mode 100644 index 00000000..5007a87e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_class.htm @@ -0,0 +1,32 @@ + + + +CLHS: System Class CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class CLASS

+

Class Precedence List:

+ class, standard-object, t

+

Description:

+

+The type class represents objects that determine the structure and behavior of their instances. Associated with an object of type class is information describing its place in the directed acyclic graph of classes, its slots, and its options.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cmpd_f.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cmpd_f.htm new file mode 100644 index 00000000..62eb4f2f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cmpd_f.htm @@ -0,0 +1,36 @@ + + + +CLHS: Type COMPILED-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type COMPILED-FUNCTION

+

+

Supertypes:

+

+compiled-function, function, t

+

Description:

+

+ Any function may be considered by an implementation to be a a compiled function if it contains no references to macros that must be expanded at run time, and it contains no unresolved references to load time values. See Section 3.2.2 (Compilation Semantics).

+Functions whose definitions appear lexically within a file that has been compiled with compile-file and then loaded with load are of type compiled-function. Functions produced by the compile function are of type compiled-function. Other functions might also be of type compiled-function.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_comple.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_comple.htm new file mode 100644 index 00000000..4a810b25 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_comple.htm @@ -0,0 +1,56 @@ + + + +CLHS: System Class COMPLEX + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class COMPLEX

+

Class Precedence List:

+ complex, number, t

+

Description:

+

+The type complex includes all mathematical complex numbers other than those included in the type rational. Complexes are expressed in Cartesian form with a real part and an imaginary part, each of which is a real. The real part and imaginary part are either both rational or both of the same float type. The imaginary part can be a float zero, but can never be a rational zero, for such a number is always represented by Common Lisp as a rational rather than a complex.

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +complex [typespec | *]

+

+

Compound Type Specifier Arguments:

+

+typespec---a type specifier that denotes a subtype of type real.

+

Compound Type Specifier Description:

+

+

+Every element of this type is a complex whose real part and imaginary part are each of type (upgraded-complex-part-type typespec). This type encompasses those complexes that can result by giving numbers of type typespec to complex.

+(complex type-specifier) refers to all complexes that can result from giving numbers of type type-specifier to the function complex, plus all other complexes of the same specialized representation.

+

+

See Also:

+

+Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals), Section 2.3.2 (Constructing Numbers from Tokens), Section 22.1.3.1.4 (Printing Complexes)

+

Notes:

+

+The input syntax for a complex with real part r and imaginary part i is #C(r i). For further details, see Section 2.4 (Standard Macro Characters).

+For every float, n, there is a complex which represents the same mathematical number and which can be obtained by (COERCE n 'COMPLEX).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_concat.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_concat.htm new file mode 100644 index 00000000..7dafd272 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_concat.htm @@ -0,0 +1,39 @@ + + + +CLHS: System Class CONCATENATED-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class CONCATENATED-STREAM

+

+

Class Precedence List:

+

+concatenated-stream, stream, t

+

Description:

+

+A concatenated stream is an input stream which is a composite stream of zero or more other input streams, such that the sequence of data which can be read from the concatenated stream is the same as the concatenation of the sequences of data which could be read from each of the constituent streams.

+Input from a concatenated stream is taken from the first of the associated input streams until it reaches end of file[1]; then that stream is discarded, and subsequent input is taken from the next input stream, and so on. An end of file on the associated input streams is always managed invisibly by the concatenated stream---the only time a client of a concatenated stream sees an end of file is when an attempt is made to obtain data from the concatenated stream but it has no remaining input streams from which to obtain such data.

+

+

See Also:

+

+concatenated-stream-streams, make-concatenated-stream

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cons.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cons.htm new file mode 100644 index 00000000..c00d96c7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_cons.htm @@ -0,0 +1,52 @@ + + + +CLHS: System Class CONS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class CONS

+

Class Precedence List:

+ cons, list, sequence, t

+

Description:

+

+A cons is a compound object having two components, called the car and cdr. These form a dotted pair. Each component can be any object.

+

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +cons [car-typespec [cdr-typespec]]

+

+

Compound Type Specifier Arguments:

+

+car-typespec---a type specifier, or the symbol *. The default is the symbol *.

+cdr-typespec---a type specifier, or the symbol *. The default is the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the set of conses whose car is constrained to be of type car-typespec and whose cdr is constrained to be of type cdr-typespec. (If either car-typespec or cdr-typespec is *, it is as if the type t had been denoted.)

+

+

See Also:

+

+Section 2.4.1 (Left-Parenthesis), Section 22.1.3.5 (Printing Lists and Conses)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_echo_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_echo_s.htm new file mode 100644 index 00000000..89577b2a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_echo_s.htm @@ -0,0 +1,39 @@ + + + +CLHS: System Class ECHO-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class ECHO-STREAM

+

+

Class Precedence List:

+

+echo-stream, stream, t

+

Description:

+

+An echo stream is a bidirectional stream that gets its input from an associated input stream and sends its output to an associated output stream.

+All input taken from the input stream is echoed to the output stream. Whether the input is echoed immediately after it is encountered, or after it has been read from the input stream is implementation-dependent.

+

+

See Also:

+

+echo-stream-input-stream, echo-stream-output-stream, make-echo-stream

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_eql.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_eql.htm new file mode 100644 index 00000000..21f8dc06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_eql.htm @@ -0,0 +1,42 @@ + + + +CLHS: Type Specifier EQL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier EQL

+

Compound Type Specifier Kind:

+

+Combining.

+

Compound Type Specifier Syntax:

+

+ +eql object

+

+

Compound Type Specifier Arguments:

+

+object---an object.

+

Compound Type Specifier Description:

+

+Represents the type of all x for which (eql object x) is true.

+ The argument object is required. The object can be *, but if so it denotes itself (the symbol *) and does not represent an unspecified value. The symbol eql is not valid as an atomic type specifier.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_extend.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_extend.htm new file mode 100644 index 00000000..0695d322 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_extend.htm @@ -0,0 +1,38 @@ + + + +CLHS: Type EXTENDED-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type EXTENDED-CHAR

+

+

Supertypes:

+

+extended-char, character, t

+

Description:

+

+The type extended-char is equivalent to the type (and character (not base-char)).

+

Notes:

+

+The type extended-char might have no elements[4] in implementations in which all characters are of type base-char.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_file_s.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_file_s.htm new file mode 100644 index 00000000..3ab20bd9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_file_s.htm @@ -0,0 +1,38 @@ + + + +CLHS: System Class FILE-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class FILE-STREAM

+

+

Class Precedence List:

+

+file-stream, stream, t

+

Description:

+

+An object of type file-stream is a stream the direct source or sink of which is a file. Such a stream is created explicitly by open and with-open-file, and implicitly by functions such as load that process files.

+

+

See Also:

+

+load, open, with-open-file

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fixnum.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fixnum.htm new file mode 100644 index 00000000..13def879 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fixnum.htm @@ -0,0 +1,33 @@ + + + +CLHS: Type FIXNUM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type FIXNUM

+

Supertypes:

+

+fixnum, integer, rational, real, number, t

+

Description:

+

+A fixnum is an integer whose value is between most-negative-fixnum and most-positive-fixnum inclusive. Exactly which integers are fixnums is implementation-defined. The type fixnum is required to be a supertype of (signed-byte 16).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_float.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_float.htm new file mode 100644 index 00000000..e18ad37a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_float.htm @@ -0,0 +1,55 @@ + + + +CLHS: System Class FLOAT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class FLOAT

+

Class Precedence List:

+ float, real, number, t

+

Description:

+

+A float is a mathematical rational (but not a Common Lisp rational) of the form s*f*b^e-p, where s is +1 or -1, the sign; b is an integer greater than 1, the base or radix of the representation; p is a positive integer, the precision (in base-b digits) of the float; f is a positive integer between b^p-1 and b^p-1 (inclusive), the significand; and e is an integer, the exponent. The value of p and the range of e depends on the implementation and on the type of float within that implementation. In addition, there is a floating-point zero; depending on the implementation, there can also be a ``minus zero''. If there is no minus zero, then 0.0 and -0.0 are both interpreted as simply a floating-point zero. (= 0.0 -0.0) is always true. If there is a minus zero, (eql -0.0 0.0) is false, otherwise it is true.

+

+

+The types short-float, single-float, double-float, and long-float are subtypes of type float. Any two of them must be either disjoint types or the same type; if the same type, then any other types between them in the above ordering must also be the same type. For example, if the type single-float and the type long-float are the same type, then the type double-float must be the same type also.

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +float [lower-limit [upper-limit]]

+

+

Compound Type Specifier Arguments:

+

+lower-limit, upper-limit---interval designators for type float. The defaults for each of lower-limit and upper-limit is the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the floats on the interval described by lower-limit and upper-limit.

+

See Also:

+

+Figure 2-9, Section 2.3.2 (Constructing Numbers from Tokens), Section 22.1.3.1.3 (Printing Floats)

+

Notes:

+

+Note that all mathematical integers are representable not only as Common Lisp reals, but also as complex floats. For example, possible representations of the mathematical number 1 include the integer 1, the float 1.0, or the complex #C(1.0 0.0).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fn.htm new file mode 100644 index 00000000..57a59b84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_fn.htm @@ -0,0 +1,102 @@ + + + +CLHS: System Class FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class FUNCTION

+

+

Class Precedence List:

+ function, t

+

Description:

+

+A function is an object that represents code to be executed when an appropriate number of arguments is supplied. A function is produced by the function special form, the function coerce, or the function compile. A function can be directly invoked by using it as the first argument to funcall, apply, or multiple-value-call.

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +function [arg-typespec [value-typespec]]

+

+

+arg-typespec::= (typespec*  
+                 [&optional typespec*]  
+                 [&rest typespec]  
+                 [&key (keyword typespec)*]) 
+
+

+

Compound Type Specifier Arguments:

+

+typespec---a type specifier.

+value-typespec---a type specifier.

+

Compound Type Specifier Description:

+

+

+

+The list form of the function type-specifier can be used only for declaration and not for discrimination. Every element of this type is a function that accepts arguments of the types specified by the argj-types and returns values that are members of the types specified by value-type. The &optional, &rest, &key, and &allow-other-keys markers can appear in the list of argument types. The type specifier provided with &rest is the type of each actual argument, not the type of the corresponding variable.

+ The &key parameters should be supplied as lists of the form (keyword type). The keyword must be a valid keyword-name symbol as must be supplied in the actual arguments of a call. This is usually a symbol in the KEYWORD package but can be any symbol. When &key is given in a function type specifier lambda list, the keyword parameters given are exhaustive unless &allow-other-keys is also present. &allow-other-keys is an indication that other keyword arguments might actually be supplied and, if supplied, can be used. For example, the type of the function make-list could be declared as follows:

+

+ (function ((integer 0) &key (:initial-element t)) list)
+
+

+The value-type can be a values type specifier in order to indicate the types of multiple values.

+

+Consider a declaration of the following form:

+

+ (ftype (function (arg0-type arg1-type ...) val-type) f))
+
+

+Any form (f arg0 arg1 ...) within the scope of that declaration is equivalent to the following:

+

+ (the val-type (f (the arg0-type arg0) (the arg1-type arg1) ...))
+
+

+That is, the consequences are undefined if any of the arguments are not of the specified types or the result is not of the specified type. In particular, if any argument is not of the correct type, the result is not guaranteed to be of the specified type.

+Thus, an ftype declaration for a function describes calls to the function, not the actual definition of the function.

+Consider a declaration of the following form:

+

+ (type (function (arg0-type arg1-type ...) val-type) fn-valued-variable)
+
+

+This declaration has the interpretation that, within the scope of the declaration, the consequences are unspecified if the value of fn-valued-variable is called with arguments not of the specified types; the value resulting from a valid call will be of type val-type.

+As with variable type declarations, nested declarations imply intersections of types, as follows:

* Consider the following two declarations of ftype:

+
+ (ftype (function (arg0-type1 arg1-type1 ...) val-type1) f))
+
+ and

+

+ (ftype (function (arg0-type2 arg1-type2 ...) val-type2) f))
+
+

+If both these declarations are in effect, then within the shared scope of the declarations, calls to f can be treated as if f were declared as follows:

+

+ (ftype (function ((and arg0-type1 arg0-type2) (and arg1-type1 arg1-type2 ...) ...)
+                  (and val-type1 val-type2)) 
+        f))
+
+

+It is permitted to ignore one or all of the ftype declarations in force.

+

* If two (or more) type declarations are in effect for a variable, and they are both function declarations, the declarations combine similarly.

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_generi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_generi.htm new file mode 100644 index 00000000..5fc92427 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_generi.htm @@ -0,0 +1,34 @@ + + + +CLHS: System Class GENERIC-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class GENERIC-FUNCTION

+

Class Precedence List:

+

+generic-function, function, t

+

Description:

+

+A generic function is a function whose behavior depends on the classes or identities of the arguments supplied to it. A generic function object contains a set of methods, a lambda list, a method combination type, and other information. The methods define the class-specific behavior and operations of the generic function; a method is said to specialize a generic function. When invoked, a generic function executes a subset of its methods based on the classes or identities of its arguments.

+A generic function can be used in the same ways that an ordinary function can be used; specifically, a generic function can be used as an argument to funcall and apply, and can be given a global or a local name.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_hash_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_hash_t.htm new file mode 100644 index 00000000..c931162c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_hash_t.htm @@ -0,0 +1,38 @@ + + + +CLHS: System Class HASH-TABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class HASH-TABLE

+

Class Precedence List:

+ hash-table, t

+

Description:

+

+Hash tables provide a way of mapping any object (a key) to an associated object (a value).

+

See Also:

+

+Section 18.1 (Hash Table Concepts), Section 22.1.3.13 (Printing Other Objects)

+

Notes:

+

+The intent is that this mapping be implemented by a hashing mechanism, such as that described in Section 6.4 ``Hashing'' of The Art of Computer Programming, Volume 3 (pp506-549). In spite of this intent, no conforming implementation is required to use any particular technique to implement the mapping.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_intege.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_intege.htm new file mode 100644 index 00000000..6b9cb885 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_intege.htm @@ -0,0 +1,54 @@ + + + +CLHS: System Class INTEGER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class INTEGER

+

Class Precedence List:

+ integer, rational, real, number, t

+

Description:

+

+An integer is a mathematical integer. There is no limit on the magnitude of an integer.

+ The types fixnum and bignum form an exhaustive partition of type integer.

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +integer [lower-limit [upper-limit]]

+

+

Compound Type Specifier Arguments:

+

+lower-limit, upper-limit---interval designators for type integer. The defaults for each of lower-limit and upper-limit is the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the integers on the interval described by lower-limit and upper-limit.

+

See Also:

+

+Figure 2-9, Section 2.3.2 (Constructing Numbers from Tokens), Section 22.1.3.1.1 (Printing Integers)

+

Notes:

+

+The type (integer lower upper), where lower and upper are most-negative-fixnum and most-positive-fixnum, respectively, is also called fixnum.

+The type (integer 0 1) is also called bit. The type (integer 0 *) is also called unsigned-byte.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_kwd.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_kwd.htm new file mode 100644 index 00000000..15cba1a7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_kwd.htm @@ -0,0 +1,38 @@ + + + +CLHS: Type KEYWORD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type KEYWORD

+

Supertypes:

+

+keyword, symbol, t

+

Description:

+

+The type keyword includes all symbols interned the KEYWORD package.

+Interning a symbol in the KEYWORD package has three automatic effects:

+

1. It causes the symbol to become bound to itself.
2. It causes the symbol to become an external symbol of the KEYWORD package.
3. It causes the symbol to become a constant variable.

+

See Also:

+

+keywordp

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_list.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_list.htm new file mode 100644 index 00000000..e9716f00 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_list.htm @@ -0,0 +1,40 @@ + + + +CLHS: System Class LIST + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class LIST

+

Class Precedence List:

+

+list, sequence, t

+

Description:

+

+A list is a chain of conses in which the car of each cons is an element of the list, and the cdr of each cons is either the next link in the chain or a terminating atom.

+A proper list is a chain of conses terminated by the empty list, (), which is itself a proper list. A dotted list is a list which has a terminating atom that is not the empty list. A circular list is a chain of conses that has no termination because some cons in the chain is the cdr of a later cons.

+Dotted lists and circular lists are also lists, but usually the unqualified term ``list'' within this specification means proper list. Nevertheless, the type list unambiguously includes dotted lists and circular lists.

+For each element of a list there is a cons. The empty list has no elements and is not a cons.

+The types cons and null form an exhaustive partition of the type list.

+

See Also:

+

+Section 2.4.1 (Left-Parenthesis), Section 22.1.3.5 (Printing Lists and Conses)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_logica.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_logica.htm new file mode 100644 index 00000000..38c9aa4b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_logica.htm @@ -0,0 +1,38 @@ + + + +CLHS: System Class LOGICAL-PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class LOGICAL-PATHNAME

+

+

Class Precedence List:

+

+logical-pathname, pathname, t

+

Description:

+

+A pathname that uses a namestring syntax that is implementation-independent, and that has component values that are implementation-independent. Logical pathnames do not refer directly to filenames

+

See Also:

+

+Section 20.1 (File System Concepts), Section 2.4.8.14 (Sharpsign P), Section 22.1.3.11 (Printing Pathnames)

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_member.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_member.htm new file mode 100644 index 00000000..d6776a6a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_member.htm @@ -0,0 +1,45 @@ + + + +CLHS: Type Specifier MEMBER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier MEMBER

+

Compound Type Specifier Kind:

+

+Combining.

+

Compound Type Specifier Syntax:

+

+ +member object*

+

+

Compound Type Specifier Arguments:

+

+object---an object.

+

Compound Type Specifier Description:

+

+This denotes the set containing the named objects. An object is of this type if and only if it is eql to one of the specified objects.

+ The type specifiers (member) and nil are equivalent. * can be among the objects, but if so it denotes itself (the symbol *) and does not represent an unspecified value. The symbol member is not valid as a type specifier; and, specifically, it is not an abbreviation for either (member) or (member *).

+

See Also:

+

+the type eql

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_meth_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_meth_1.htm new file mode 100644 index 00000000..63bc29c4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_meth_1.htm @@ -0,0 +1,32 @@ + + + +CLHS: System Class METHOD-COMBINATION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class METHOD-COMBINATION

+

Class Precedence List:

+ method-combination, t

+

Description:

+

+Every method combination object is an indirect instance of the class method-combination. A method combination object represents the information about the method combination being used by a generic function. A method combination object contains information about both the type of method combination and the arguments being used with that type.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_method.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_method.htm new file mode 100644 index 00000000..9818f36f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_method.htm @@ -0,0 +1,37 @@ + + + +CLHS: System Class METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class METHOD

+

Class Precedence List:

+ method, t

+

Description:

+

+A method is an object that represents a modular part of the behavior of a generic function.

+A method contains code to implement the method's behavior, a sequence of parameter specializers that specify when the given method is applicable, and a sequence of qualifiers that is used by the method combination facility to distinguish among methods. Each required parameter of each method has an associated parameter specializer, and the method will be invoked only on arguments that satisfy its parameter specializers.

+The method combination facility controls the selection of methods, the order in which they are run, and the values that are returned by the generic function. The object system offers a default method combination type and provides a facility for declaring new types of method combination.

+

See Also:

+

+Section 7.6 (Generic Functions and Methods)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_mod.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_mod.htm new file mode 100644 index 00000000..d9f24b40 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_mod.htm @@ -0,0 +1,43 @@ + + + +CLHS: Type Specifier MOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier MOD

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +mod n

+

+

Compound Type Specifier Arguments:

+

+n---a positive integer.

+

Compound Type Specifier Description:

+

+This denotes the set of non-negative integers less than n. This is equivalent to (integer 0 (n)) or to (integer 0 m), where m=n-1.

+ The argument is required, and cannot be *.

+The symbol mod is not valid as a type specifier.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_nil.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_nil.htm new file mode 100644 index 00000000..ffd0aab8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_nil.htm @@ -0,0 +1,35 @@ + + + +CLHS: Type NIL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type NIL

+

Supertypes:

+ all types

+

Description:

+

+The type nil contains no objects and so is also called the empty type. The type nil is a subtype of every type. No object is of type nil.

+

Notes:

+

+The type containing the object nil is the type null, not the type nil.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_not.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_not.htm new file mode 100644 index 00000000..0cafbda4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_not.htm @@ -0,0 +1,43 @@ + + + +CLHS: Type Specifier NOT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier NOT

+

Compound Type Specifier Kind:

+

+Combining.

+

Compound Type Specifier Syntax:

+

+ +not typespec

+

+

Compound Type Specifier Arguments:

+

+typespec---a type specifier.

+

Compound Type Specifier Description:

+

+This denotes the set of all objects that are not of the type typespec.

+ The argument is required, and cannot be *.

+The symbol not is not valid as a type specifier.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_null.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_null.htm new file mode 100644 index 00000000..c779558b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_null.htm @@ -0,0 +1,35 @@ + + + +CLHS: System Class NULL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class NULL

+

Class Precedence List:

+ null, symbol, list, sequence, t

+

Description:

+

+The only object of type null is nil, which represents the empty list and can also be notated ().

+

See Also:

+

+Section 2.3.4 (Symbols as Tokens), Section 2.4.1 (Left-Parenthesis), Section 22.1.3.3 (Printing Symbols)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_number.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_number.htm new file mode 100644 index 00000000..8950ef89 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_number.htm @@ -0,0 +1,36 @@ + + + +CLHS: System Class NUMBER + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class NUMBER

+

Class Precedence List:

+ number, t

+

Description:

+

+The type number contains objects which represent mathematical numbers. The types real and complex are disjoint subtypes of number.

+The function = tests for numerical equality. The function eql, when its arguments are both numbers, tests that they have both the same type and numerical value. Two numbers that are the same under eql or = are not necessarily the same under eq.

+

Notes:

+

+Common Lisp differs from mathematics on some naming issues. In mathematics, the set of real numbers is traditionally described as a subset of the complex numbers, but in Common Lisp, the type real and the type complex are disjoint. The Common Lisp type which includes all mathematical complex numbers is called number. The reasons for these differences include historical precedent, compatibility with most other popular computer languages, and various issues of time and space efficiency.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_or.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_or.htm new file mode 100644 index 00000000..f47f1cb2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_or.htm @@ -0,0 +1,43 @@ + + + +CLHS: Type Specifier OR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier OR

+

Compound Type Specifier Kind:

+

+Combining.

+

Compound Type Specifier Syntax:

+

+ +or typespec*

+

+

Compound Type Specifier Arguments:

+

+typespec---a type specifier.

+

Compound Type Specifier Description:

+

+This denotes the set of all objects of the type determined by the union of the typespecs. For example, the type list by definition is the same as (or null cons). Also, the value returned by position is an object of type (or null (integer 0 *)); i.e., either nil or a non-negative integer.

+ * is not permitted as an argument.

+The type specifiers (or) and nil are equivalent. The symbol or is not valid as a type specifier; and, specifically, it is not an abbreviation for (or).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pkg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pkg.htm new file mode 100644 index 00000000..a1d04f99 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pkg.htm @@ -0,0 +1,35 @@ + + + +CLHS: System Class PACKAGE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class PACKAGE

+

Class Precedence List:

+ package, t

+

Description:

+

+A package is a namespace that maps symbol names to symbols; see Section 11.1 (Package Concepts).

+

See Also:

+

+Section 11.1 (Package Concepts), Section 22.1.3.13 (Printing Other Objects), Section 2.3.4 (Symbols as Tokens)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pn.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pn.htm new file mode 100644 index 00000000..98ef5fda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_pn.htm @@ -0,0 +1,33 @@ + + + +CLHS: System Class PATHNAME + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class PATHNAME

+

Class Precedence List:

+ pathname, t

+

Description:

+

+A pathname is a structured object which represents a filename.

+There are two kinds of pathnames---physical pathnames and logical pathnames.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ratio.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ratio.htm new file mode 100644 index 00000000..4ef72eab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ratio.htm @@ -0,0 +1,35 @@ + + + +CLHS: System Class RATIO + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class RATIO

+

Class Precedence List:

+ ratio, rational, real, number, t

+

Description:

+

+A ratio is a number representing the mathematical ratio of two non-zero integers, the numerator and denominator, whose greatest common divisor is one, and of which the denominator is positive and greater than one.

+

See Also:

+

+Figure 2-9, Section 2.3.2 (Constructing Numbers from Tokens), Section 22.1.3.1.2 (Printing Ratios)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ration.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ration.htm new file mode 100644 index 00000000..b747f108 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_ration.htm @@ -0,0 +1,47 @@ + + + +CLHS: System Class RATIONAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class RATIONAL

+

Class Precedence List:

+ rational, real, number, t

+

Description:

+

+The canonical representation of a rational is as an integer if its value is integral, and otherwise as a ratio.

+The types integer and ratio are disjoint subtypes of type rational.

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +rational [lower-limit [upper-limit]]

+

+

Compound Type Specifier Arguments:

+

+lower-limit, upper-limit---interval designators for type rational. The defaults for each of lower-limit and upper-limit is the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the rationals on the interval described by lower-limit and upper-limit.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rdtabl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rdtabl.htm new file mode 100644 index 00000000..f736feb1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rdtabl.htm @@ -0,0 +1,36 @@ + + + +CLHS: System Class READTABLE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class READTABLE

+

Class Precedence List:

+ readtable, t

+

Description:

+

+A readtable maps characters into syntax types for the Lisp reader; see Section 2 (Syntax). A readtable also contains associations between macro characters and their reader macro functions, and records information about the case conversion rules to be used by the Lisp reader when parsing symbols.

+ Each simple character must be representable in the readtable. It is implementation-defined whether non-simple characters can have syntax descriptions in the readtable.

+

See Also:

+

+Section 2.1.1 (Readtables), Section 22.1.3.13 (Printing Other Objects)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_real.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_real.htm new file mode 100644 index 00000000..d08d3887 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_real.htm @@ -0,0 +1,49 @@ + + + +CLHS: System Class REAL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class REAL

+

+

Class Precedence List:

+ real, number, t

+

Description:

+

+The type real includes all numbers that represent mathematical real numbers, though there are mathematical real numbers (e.g., irrational numbers) that do not have an exact representation in Common Lisp. Only reals can be ordered using the <, >, <=, and >= functions.

+ The types rational and float are disjoint subtypes of type real.

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +real [lower-limit [upper-limit]]

+

+

Compound Type Specifier Arguments:

+

+lower-limit, upper-limit---interval designators for type real. The defaults for each of lower-limit and upper-limit is the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the reals on the interval described by lower-limit and upper-limit.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rnd_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rnd_st.htm new file mode 100644 index 00000000..28c8fbb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rnd_st.htm @@ -0,0 +1,36 @@ + + + +CLHS: System Class RANDOM-STATE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class RANDOM-STATE

+

Class Precedence List:

+ random-state, t

+

Description:

+

+A random state object contains state information used by the pseudo-random number generator. The nature of a random state object is implementation-dependent. It can be printed out and successfully read back in by the same implementation, but might not function correctly as a random state in another implementation.

+Implementations are required to provide a read syntax for objects of type random-state, but the specific nature of that syntax is implementation-dependent.

+

See Also:

+

+*random-state*, random, Section 22.1.3.10 (Printing Random States)

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rst.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rst.htm new file mode 100644 index 00000000..d493ff6c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_rst.htm @@ -0,0 +1,33 @@ + + + +CLHS: System Class RESTART + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class RESTART

+

Class Precedence List:

+ restart, t

+

Description:

+

+An object of type restart represents a function that can be called to perform some form of recovery action, usually a transfer of control to an outer point in the running program.

+An implementation is free to implement a restart in whatever manner is most convenient; a restart has only dynamic extent relative to the scope of the binding form which establishes it.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_satisf.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_satisf.htm new file mode 100644 index 00000000..8c172627 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_satisf.htm @@ -0,0 +1,43 @@ + + + +CLHS: Type Specifier SATISFIES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier SATISFIES

+

Compound Type Specifier Kind:

+

+Predicating.

+

Compound Type Specifier Syntax:

+

+ +satisfies predicate-name

+

+

Compound Type Specifier Arguments:

+

+predicate-name---a symbol.

+

Compound Type Specifier Description:

+

+This denotes the set of all objects that satisfy the predicate predicate-name, which must be a symbol whose global function definition is a one-argument predicate. A name is required for predicate-name; lambda expressions are not allowed. For example, the type specifier (and integer (satisfies evenp)) denotes the set of all even integers. The form (typep x '(satisfies p)) is equivalent to (if (p x) t nil).

+ The argument is required. The symbol * can be the argument, but it denotes itself (the symbol *), and does not represent an unspecified value.

+The symbol satisfies is not valid as a type specifier.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_seq.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_seq.htm new file mode 100644 index 00000000..67aa4db9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_seq.htm @@ -0,0 +1,34 @@ + + + +CLHS: System Class SEQUENCE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class SEQUENCE

+

Class Precedence List:

+ sequence, t

+

Description:

+

+Sequences are ordered collections of objects, called the elements of the sequence.

+The types vector and the type list are disjoint subtypes of type sequence, but are not necessarily an exhaustive partition of sequence.

+When viewing a vector as a sequence, only the active elements of that vector are considered elements of the sequence; that is, sequence operations respect the fill pointer when given sequences represented as vectors.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_sgn_by.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_sgn_by.htm new file mode 100644 index 00000000..c9fd5ddc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_sgn_by.htm @@ -0,0 +1,47 @@ + + + +CLHS: Type SIGNED-BYTE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SIGNED-BYTE

+

Supertypes:

+

+signed-byte, integer, rational, real, number, t

+

Description:

+

+The atomic type specifier signed-byte denotes the same type as is denoted by the type specifier integer; however, the list forms of these two type specifiers have different semantics.

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +signed-byte [s | *]

+

+

Compound Type Specifier Arguments:

+

+s---a positive integer.

+

Compound Type Specifier Description:

+

+This denotes the set of integers that can be represented in two's-complement form in a byte of s bits. This is equivalent to (integer -2^s-1 2^s-1-1). The type signed-byte or the type (signed-byte *) is the same as the type integer.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_short_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_short_.htm new file mode 100644 index 00000000..4c40e632 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_short_.htm @@ -0,0 +1,70 @@ + + + +CLHS: Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT

+

Supertypes:

+

+short-float: short-float, float, real, number, t

+single-float: single-float, float, real, number, t

+double-float: double-float, float, real, number, t

+long-float: long-float, float, real, number, t

+

Description:

+

+For the four defined subtypes of type float, it is true that intermediate between the type short-float and the type long-float are the type single-float and the type double-float. The precise definition of these categories is implementation-defined. The precision (measured in ``bits'', computed as p log 2b) and the exponent size (also measured in ``bits,'' computed as log 2(n+1), where n is the maximum exponent value) is recommended to be at least as great as the values in the next figure. Each of the defined subtypes of type float might or might not have a minus zero.

+

+Format  Minimum Precision  Minimum Exponent Size  
+----------

+                                          
+Short   13 bits            5 bits                 
+Single  24 bits            8 bits                 
+Double  50 bits            8 bits                 
+Long    50 bits            8 bits                 
+
+

Figure 12-12. Recommended Minimum Floating-Point Precision and Exponent Size

+There can be fewer than four internal representations for floats. If there are fewer distinct representations, the following rules apply:

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +short-float [short-lower-limit [short-upper-limit]]

+ +single-float [single-lower-limit [single-upper-limit]]

+ +double-float [double-lower-limit [double-upper-limit]]

+ +long-float [long-lower-limit [long-upper-limit]]

+

+

Compound Type Specifier Arguments:

+

+short-lower-limit, short-upper-limit---interval designators for type short-float. The defaults for each of lower-limit and upper-limit is the symbol *.

+single-lower-limit, single-upper-limit---interval designators for type single-float. The defaults for each of lower-limit and upper-limit is the symbol *.

+double-lower-limit, double-upper-limit---interval designators for type double-float. The defaults for each of lower-limit and upper-limit is the symbol *.

+long-lower-limit, long-upper-limit---interval designators for type long-float. The defaults for each of lower-limit and upper-limit is the symbol *.

+

Compound Type Specifier Description:

+

+Each of these denotes the set of floats of the indicated type that are on the interval specified by the interval designators.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ar.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ar.htm new file mode 100644 index 00000000..78e500ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ar.htm @@ -0,0 +1,58 @@ + + + +CLHS: Type SIMPLE-ARRAY + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SIMPLE-ARRAY

+

Supertypes:

+

+simple-array, array, t

+

Description:

+

+The type of an array that is not displaced to another array, has no fill pointer, and is not expressly adjustable is a subtype of type simple-array. The concept of a simple array exists to allow the implementation to use a specialized representation and to allow the user to declare that certain values will always be simple arrays.

+The types simple-vector, simple-string, and simple-bit-vector are disjoint subtypes of type simple-array, for they respectively mean (simple-array t (*)), the union of all (simple-array c (*)) for any c being a subtype of type character, and (simple-array bit (*)).

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +simple-array [{element-type | *} [dimension-spec]]

+

+

+dimension-spec::= rank | * | ({dimension | *}*) 
+
+

+

Compound Type Specifier Arguments:

+

+dimension---a valid array dimension.

+element-type---a type specifier.

+ rank---a non-negative fixnum.

+

Compound Type Specifier Description:

+

+This compound type specifier is treated exactly as the corresponding compound type specifier for type array would be treated, except that the set is further constrained to include only simple arrays.

+

Notes:

+

+It is implementation-dependent whether displaced arrays, vectors with fill pointers, or arrays that are actually adjustable are simple arrays.

+ (simple-array *) refers to all simple arrays regardless of element type, (simple-array type-specifier) refers only to those simple arrays that can result from giving type-specifier as the :element-type argument to make-array.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ba.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ba.htm new file mode 100644 index 00000000..cc133773 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ba.htm @@ -0,0 +1,47 @@ + + + +CLHS: Type SIMPLE-BASE-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SIMPLE-BASE-STRING

+

Supertypes:

+

+simple-base-string, base-string, simple-string, string, vector, simple-array, array, sequence, t

+

Description:

+

+The type simple-base-string is equivalent to (simple-array base-char (*)).

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +simple-base-string [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *.

+

Compound Type Specifier Description:

+

+This is equivalent to the type (simple-array base-char (size)); that is, the set of simple base strings of size size.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_bt.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_bt.htm new file mode 100644 index 00000000..5c862ec5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_bt.htm @@ -0,0 +1,47 @@ + + + +CLHS: Type SIMPLE-BIT-VECTOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SIMPLE-BIT-VECTOR

+

Supertypes:

+

+simple-bit-vector, bit-vector, vector, simple-array, array, sequence, t

+

Description:

+

+The type of a bit vector that is not displaced to another array, has no fill pointer, and is not expressly adjustable is a subtype of type simple-bit-vector.

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +simple-bit-vector [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *. The default is the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the same type as the type (simple-array bit (size)); that is, the set of simple bit vectors of size size.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_st.htm new file mode 100644 index 00000000..46dde31b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_st.htm @@ -0,0 +1,47 @@ + + + +CLHS: Type SIMPLE-STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SIMPLE-STRING

+

Supertypes:

+

+simple-string, string, vector, simple-array, array, sequence, t

+

Description:

+

+ A simple string is a specialized one-dimensional simple array whose elements are of type character or a subtype of type character. When used as a type specifier for object creation, simple-string means (simple-array character (size)).

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +simple-string [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the union of all types (simple-array c (size)) for all subtypes c of character; that is, the set of simple strings of size size.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ve.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ve.htm new file mode 100644 index 00000000..4059d5da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_smp_ve.htm @@ -0,0 +1,48 @@ + + + +CLHS: Type SIMPLE-VECTOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type SIMPLE-VECTOR

+

Supertypes:

+

+simple-vector, vector, simple-array, array, sequence, t

+

Description:

+

+The type of a vector that is not displaced to another array, has no fill pointer, is not expressly adjustable and is able to hold elements of any type is a subtype of type simple-vector.

+The type simple-vector is a subtype of type vector, and is a subtype of type (vector t).

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +simple-vector [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *. The default is the symbol *.

+

Compound Type Specifier Description:

+

+This is the same as (simple-array t (size)).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ch.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ch.htm new file mode 100644 index 00000000..b79b3109 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ch.htm @@ -0,0 +1,39 @@ + + + +CLHS: Type STANDARD-CHAR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type STANDARD-CHAR

+

+

Supertypes:

+

+standard-char, base-char, character, t

+

Description:

+

+A fixed set of 96 characters required to be present in all conforming implementations. Standard characters are defined in Section 2.1.3 (Standard Characters).

+ Any character that is not simple is not a standard character.

+

+

See Also:

+

+Section 2.1.3 (Standard Characters)

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_cl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_cl.htm new file mode 100644 index 00000000..a31d8bda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_cl.htm @@ -0,0 +1,32 @@ + + + +CLHS: System Class STANDARD-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STANDARD-CLASS

+

Class Precedence List:

+ standard-class, class, standard-object, t

+

Description:

+

+The class standard-class is the default class of classes defined by defclass.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ge.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ge.htm new file mode 100644 index 00000000..389f9030 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ge.htm @@ -0,0 +1,32 @@ + + + +CLHS: System Class STANDARD-GENERIC-FUNCTION + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STANDARD-GENERIC-FUNCTION

+

Class Precedence List:

+ standard-generic-function, generic-function, function, t

+

Description:

+

+The class standard-generic-function is the default class of generic functions established by defmethod, ensure-generic-function, defgeneric, and defclass forms.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_me.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_me.htm new file mode 100644 index 00000000..1be9358a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_me.htm @@ -0,0 +1,31 @@ + + + +CLHS: System Class STANDARD-METHOD + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STANDARD-METHOD

+

Class Precedence List:

+ standard-method, method, standard-object, t

+

Description:

+

+The class standard-method is the default class of methods defined by the defmethod and defgeneric forms.

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ob.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ob.htm new file mode 100644 index 00000000..8eedc39a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_std_ob.htm @@ -0,0 +1,32 @@ + + + +CLHS: Class STANDARD-OBJECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Class STANDARD-OBJECT

+

Class Precedence List:

+ standard-object, t

+

Description:

+

+The class standard-object is an instance of standard-class and is a superclass of every class that is an instance of standard-class except itself.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stg_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stg_st.htm new file mode 100644 index 00000000..df7faa28 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stg_st.htm @@ -0,0 +1,39 @@ + + + +CLHS: System Class STRING-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STRING-STREAM

+

+

Class Precedence List:

+

+string-stream, stream, t

+

Description:

+

+A string stream is a stream which reads input from or writes output to an associated string.

+The stream element type of a string stream is always a subtype of type character.

+

See Also:

+

+make-string-input-stream, make-string-output-stream, with-input-from-string, with-output-to-string

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stream.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stream.htm new file mode 100644 index 00000000..c29e590d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stream.htm @@ -0,0 +1,37 @@ + + + +CLHS: System Class STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STREAM

+

Class Precedence List:

+ stream, t

+

Description:

+

+A stream is an object that can be used with an input or output function to identify an appropriate source or sink of characters or bytes for that operation.

+For more complete information, see Section 21.1 (Stream Concepts).

+

+

See Also:

+

+Section 21.1 (Stream Concepts), Section 22.1.3.13 (Printing Other Objects), Section 22 (Printer), Section 23 (Reader)

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_string.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_string.htm new file mode 100644 index 00000000..c938ab38 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_string.htm @@ -0,0 +1,50 @@ + + + +CLHS: System Class STRING + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STRING

+

Class Precedence List:

+ string, vector, array, sequence, t

+

Description:

+

+ A string is a specialized vector whose elements are of type character or a subtype of type character. When used as a type specifier for object creation, string means (vector character).

+

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +string [size]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum, or the symbol *.

+

Compound Type Specifier Description:

+

+This denotes the union of all types (array c (size)) for all subtypes c of character; that is, the set of strings of size size.

+

See Also:

+

+Section 16.1 (String Concepts), Section 2.4.5 (Double-Quote), Section 22.1.3.4 (Printing Strings)

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_cl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_cl.htm new file mode 100644 index 00000000..cdbc6889 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_cl.htm @@ -0,0 +1,33 @@ + + + +CLHS: System Class STRUCTURE-CLASS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class STRUCTURE-CLASS

+

Class Precedence List:

+

+structure-class, class, standard-object, t

+

Description:

+

+All classes defined by means of defstruct are instances of the class structure-class.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_ob.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_ob.htm new file mode 100644 index 00000000..a4adec2c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_stu_ob.htm @@ -0,0 +1,37 @@ + + + +CLHS: Class STRUCTURE-OBJECT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Class STRUCTURE-OBJECT

+

Class Precedence List:

+

+structure-object, t

+

Description:

+

+The class structure-object is an instance of structure-class and is a superclass of every class that is an instance of structure-class except itself, and is a superclass of every class that is defined by defstruct.

+

+

See Also:

+

+defstruct, Section 2.4.8.13 (Sharpsign S), Section 22.1.3.12 (Printing Structures)

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_symbol.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_symbol.htm new file mode 100644 index 00000000..061c16dc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_symbol.htm @@ -0,0 +1,57 @@ + + + +CLHS: System Class SYMBOL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class SYMBOL

+

Class Precedence List:

+ symbol, t

+

Description:

+

+Symbols are used for their object identity to name various entities in Common Lisp, including (but not limited to) linguistic entities such as variables and functions.

+Symbols can be collected together into packages. A symbol is said to be interned in a package if it is accessible in that package; the same symbol can be interned in more than one package. If a symbol is not interned in any package, it is called uninterned.

+An interned symbol is uniquely identifiable by its name from any package in which it is accessible.

+Symbols have the following attributes. For historical reasons, these are sometimes referred to as cells, although the actual internal representation of symbols and their attributes is implementation-dependent.

+

+

Name

+The name of a symbol is a string used to identify the symbol. Every symbol has a name, and the consequences are undefined if that name is altered. The name is used as part of the external, printed representation of the symbol; see Section 2.1 (Character Syntax). The function symbol-name returns the name of a given symbol. A symbol may have any character in its name.

+

Package

+The object in this cell is called the home package of the symbol. If the home package is nil, the symbol is sometimes said to have no home package.

+When a symbol is first created, it has no home package. When it is first interned, the package in which it is initially interned becomes its home package. The home package of a symbol can be accessed by using the function symbol-package.

+If a symbol is uninterned from the package which is its home package, its home package is set to nil. Depending on whether there is another package in which the symbol is interned, the symbol might or might not really be an uninterned symbol. A symbol with no home package is therefore called apparently uninterned.

+ The consequences are undefined if an attempt is made to alter the home package of a symbol external in the COMMON-LISP package or the KEYWORD package.

+

Property list

+The property list of a symbol provides a mechanism for associating named attributes with that symbol. The operations for adding and removing entries are destructive to the property list. Common Lisp provides operators both for direct manipulation of property list objects (e.g., see getf, remf, and symbol-plist) and for implicit manipulation of a symbol's property list by reference to the symbol (e.g., see get and remprop). The property list associated with a fresh symbol is initially null.

+

Value

+If a symbol has a value attribute, it is said to be bound, and that fact can be detected by the function boundp. The object contained in the value cell of a bound symbol is the value of the global variable named by that symbol, and can be accessed by the function symbol-value. A symbol can be made to be unbound by the function makunbound.

+The consequences are undefined if an attempt is made to change the value of a symbol that names a constant variable, or to make such a symbol be unbound.

+

Function

+If a symbol has a function attribute, it is said to be fbound, and that fact can be detected by the function fboundp. If the symbol is the name of a function in the global environment, the function cell contains the function, and can be accessed by the function symbol-function. If the symbol is the name of either a macro in the global environment (see macro-function) or a special operator (see special-operator-p), the symbol is fbound, and can be accessed by the function symbol-function, but the object which the function cell contains is of implementation-dependent type and purpose. A symbol can be made to be funbound by the function fmakunbound.

+The consequences are undefined if an attempt is made to change the functional value of a symbol that names a special form.

+

+Operations on a symbol's value cell and function cell are sometimes described in terms of their effect on the symbol itself, but the user should keep in mind that there is an intimate relationship between the contents of those cells and the global variable or global function definition, respectively.

+Symbols are used as identifiers for lexical variables and lexical function definitions, but in that role, only their object identity is significant. Common Lisp provides no operation on a symbol that can have any effect on a lexical variable or on a lexical function definition.

+

See Also:

+

+Section 2.3.4 (Symbols as Tokens), Section 2.3.1.1 (Potential Numbers as Tokens), Section 22.1.3.3 (Printing Symbols)

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_syn_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_syn_st.htm new file mode 100644 index 00000000..e054f5cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_syn_st.htm @@ -0,0 +1,39 @@ + + + +CLHS: System Class SYNONYM-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class SYNONYM-STREAM

+

+

Class Precedence List:

+

+synonym-stream, stream, t

+

Description:

+

+A stream that is an alias for another stream, which is the value of a dynamic variable whose name is the synonym stream symbol of the synonym stream.

+Any operations on a synonym stream will be performed on the stream that is then the value of the dynamic variable named by the synonym stream symbol. If the value of the variable should change, or if the variable should be bound, then the stream will operate on the new value of the variable.

+

See Also:

+

+make-synonym-stream, synonym-stream-symbol

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_t.htm new file mode 100644 index 00000000..4a51fbd2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_t.htm @@ -0,0 +1,32 @@ + + + +CLHS: System Class T + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class T

+

Class Precedence List:

+ t

+

Description:

+ The set of all objects. The type t is a supertype of every type, including itself. Every object is of type t.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_two_wa.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_two_wa.htm new file mode 100644 index 00000000..f3e5b25a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_two_wa.htm @@ -0,0 +1,39 @@ + + + +CLHS: System Class TWO-WAY-STREAM + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class TWO-WAY-STREAM

+

+

Class Precedence List:

+

+two-way-stream, stream, t

+

Description:

+

+A bidirectional composite stream that receives its input from an associated input stream and sends its output to an associated output stream.

+

See Also:

+

+make-two-way-stream, two-way-stream-input-stream, two-way-stream-output-stream

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_unsgn_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_unsgn_.htm new file mode 100644 index 00000000..e99b39d2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_unsgn_.htm @@ -0,0 +1,50 @@ + + + +CLHS: Type UNSIGNED-BYTE + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type UNSIGNED-BYTE

+

Supertypes:

+

+unsigned-byte, signed-byte, integer, rational, real, number, t

+

Description:

+

+The atomic type specifier unsigned-byte denotes the same type as is denoted by the type specifier (integer 0 *).

+

Compound Type Specifier Kind:

+

+Abbreviating.

+

Compound Type Specifier Syntax:

+

+ +unsigned-byte [s | *]

+

+

Compound Type Specifier Arguments:

+

+s---a positive integer.

+

Compound Type Specifier Description:

+

+This denotes the set of non-negative integers that can be represented in a byte of size s (bits). This is equivalent to (mod m) for m=2^s, or to (integer 0 n) for n=2^s-1. The type unsigned-byte or the type (unsigned-byte *) is the same as the type (integer 0 *), the set of non-negative integers.

+

Notes:

+

+The type (unsigned-byte 1) is also called bit.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_values.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_values.htm new file mode 100644 index 00000000..b7c662cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_values.htm @@ -0,0 +1,47 @@ + + + +CLHS: Type Specifier VALUES + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Type Specifier VALUES

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +values value-typespec

+

+ 

+value-typespec::= typespec* [&optional typespec*] [&rest typespec] [&allow-other-keys] 
+
+

+

Compound Type Specifier Arguments:

+

+typespec---a type specifier.

+

Compound Type Specifier Description:

+

+This type specifier can be used only as the value-type in a function type specifier or a the special form. It is used to specify individual types when multiple values are involved. The &optional and &rest markers can appear in the value-type list; they indicate the parameter list of a function that, when given to multiple-value-call along with the values, would correctly receive those values.

+ The symbol * may not be among the value-types.

+The symbol values is not valid as a type specifier; and, specifically, it is not an abbreviation for (values).

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_vector.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_vector.htm new file mode 100644 index 00000000..6e727d29 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/t_vector.htm @@ -0,0 +1,60 @@ + + + +CLHS: System Class VECTOR + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +System Class VECTOR

+

Class Precedence List:

+ vector, array, sequence, t

+

Description:

+

+Any one-dimensional array is a vector.

+The type vector is a subtype of type array; for all types x, (vector x) is the same as (array x (*)).

+The type (vector t), the type string, and the type bit-vector are disjoint subtypes of type vector.

+

Compound Type Specifier Kind:

+

+Specializing.

+

Compound Type Specifier Syntax:

+

+ +vector [{element-type | *} [{size | *}]]

+

+

Compound Type Specifier Arguments:

+

+ size---a non-negative fixnum.

+element-type---a type specifier.

+

Compound Type Specifier Description:

+

+This denotes the set of specialized vectors whose element type and dimension match the specified values. Specifically:

+If element-type is the symbol *, vectors are not excluded on the basis of their element type. Otherwise, only those vectors are included whose actual array element type is the result of upgrading element-type; see Section 15.1.2.1 (Array Upgrading).

+If a size is specified, the set includes only those vectors whose only dimension is size. If the symbol * is specified instead of a size, the set is not restricted on the basis of dimension.

+

See Also:

+

+Section 15.1.2.2 (Required Kinds of Specialized Arrays), Section 2.4.8.3 (Sharpsign Left-Parenthesis), Section 22.1.3.7 (Printing Other Vectors), Section 2.4.8.12 (Sharpsign A)

+

Notes:

+

+The type (vector e s) is equivalent to the type (array e (s)).

+The type (vector bit) has the name bit-vector.

+The union of all types (vector C), where C is any subtype of character, has the name string.

+ (vector *) refers to all vectors regardless of element type, (vector type-specifier) refers only to those vectors that can result from giving type-specifier as the :element-type argument to make-array.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__.htm new file mode 100644 index 00000000..2963bdcb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__.htm @@ -0,0 +1,52 @@ + + + +CLHS: Variable - + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable -

+

Value Type:

+

+a form.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The value of - is the form that is currently being evaluated by the Lisp read-eval-print loop.

+

Examples:

+

+

+(format t "~&Evaluating ~S~%" -)
+>>  Evaluating (FORMAT T "~&Evaluating ~S~%" -)
+=>  NIL
+
+

+

Affected By:

+

+Lisp read-eval-print loop.

+

See Also:

+

++ (variable), * (variable), / (variable), Section 25.1.1 (Top level loop)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__stst_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__stst_.htm new file mode 100644 index 00000000..c428d548 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v__stst_.htm @@ -0,0 +1,67 @@ + + + +CLHS: Variable *, **, *** + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *, **, ***

+

Value Type:

+

+an object.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The variables *, **, and *** are maintained by the Lisp read-eval-print loop to save the values of results that are printed each time through the loop.

+The value of * is the most recent primary value that was printed, the value of ** is the previous value of *, and the value of *** is the previous value of **.

+If several values are produced, * contains the first value only; * contains nil if zero values are produced.

+The values of *, **, and *** are updated immediately prior to printing the return value of a top-level form by the Lisp read-eval-print loop. If the evaluation of such a form is aborted prior to its normal return, the values of *, **, and *** are not updated.

+

Examples:

+ +

+(values 'a1 'a2) =>  A1, A2
+'b =>  B
+(values 'c1 'c2 'c3) =>  C1, C2, C3
+(list * ** ***) =>  (C1 B A1)
+
+(defun cube-root (x) (expt x 1/3)) =>  CUBE-ROOT
+(compile *) =>  CUBE-ROOT
+(setq a (cube-root 27.0)) =>  3.0
+(* * 9.0) =>  27.0
+
+

+

Affected By:

+

+Lisp read-eval-print loop.

+

See Also:

+

+- (variable), + (variable), / (variable), Section 25.1.1 (Top level loop)

+

Notes:

+

+

+ *   ==  (car /)
+ **  ==  (car //)
+ *** ==  (car ///)
+
+

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_dim.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_dim.htm new file mode 100644 index 00000000..2bcebeda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_dim.htm @@ -0,0 +1,40 @@ + + + +CLHS: Constant Variable ARRAY-DIMENSION-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable ARRAY-DIMENSION-LIMIT

+

Constant Value:

+

+A positive fixnum, the exact magnitude of which is implementation-dependent, but which is not less than 1024.

+

Description:

+

+The upper exclusive bound on each individual dimension of an array.

+

Examples: None. +

+

See Also:

+

+make-array

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_ran.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_ran.htm new file mode 100644 index 00000000..8225d15a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_ran.htm @@ -0,0 +1,40 @@ + + + +CLHS: Constant Variable ARRAY-RANK-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable ARRAY-RANK-LIMIT

+

Constant Value:

+

+A positive fixnum, the exact magnitude of which is implementation-dependent, but which is not less than 8.

+

Description:

+

+The upper exclusive bound on the rank of an array.

+

Examples: None. +

+

See Also:

+

+make-array

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_tot.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_tot.htm new file mode 100644 index 00000000..bb2ec155 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ar_tot.htm @@ -0,0 +1,41 @@ + + + +CLHS: Constant Variable ARRAY-TOTAL-SIZE-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable ARRAY-TOTAL-SIZE-LIMIT

+

Constant Value:

+

+A positive fixnum, the exact magnitude of which is implementation-dependent, but which is not less than 1024.

+

Description:

+

+The upper exclusive bound on the array total size of an array.

+The actual limit on the array total size imposed by the implementation might vary according the element type of the array; in this case, the value of array-total-size-limit will be the smallest of these possible limits.

+

Examples: None. +

+

See Also:

+

+make-array, array-element-type

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_b_1_b.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_b_1_b.htm new file mode 100644 index 00000000..7fa65a8b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_b_1_b.htm @@ -0,0 +1,46 @@ + + + +CLHS: Constant Variable BOOLE-1, BOOLE-2... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR

+

Constant Value:

+

+The identity and nature of the values of each of these variables is implementation-dependent, except that it must be distinct from each of the values of the others, and it must be a valid first argument to the function boole.

+

Description:

+

+Each of these constants has a value which is one of the sixteen possible bit-wise logical operation specifiers.

+

Examples:

+ +

+ (boole boole-ior 1 16) =>  17
+ (boole boole-and -2 5) =>  4
+ (boole boole-eqv 17 15) =>  -31
+
+

+

See Also:

+

+boole

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_break_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_break_.htm new file mode 100644 index 00000000..4e55bc48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_break_.htm @@ -0,0 +1,82 @@ + + + +CLHS: Variable *BREAK-ON-SIGNALS* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *BREAK-ON-SIGNALS*

+

Value Type:

+

+a type specifier.

+

Initial Value:

+

+nil.

+

Description:

+

+When (typep condition *break-on-signals*) returns true, calls to signal, and to other operators such as error that implicitly call signal, enter the debugger prior to signaling the condition.

+The continue restart can be used to continue with the normal signaling process when a break occurs process due to *break-on-signals*.

+

Examples:

+

+ +

+ *break-on-signals* =>  NIL
+ (ignore-errors (error 'simple-error :format-control "Fooey!"))
+=>  NIL, #<SIMPLE-ERROR 32207172>
+
+ (let ((*break-on-signals* 'error))
+   (ignore-errors (error 'simple-error :format-control "Fooey!")))
+>>  Break: Fooey!
+>>  BREAK entered because of *BREAK-ON-SIGNALS*.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Continue to signal.
+>>   2: Top level.
+>>  Debug> :CONTINUE 1
+>>  Continue to signal.
+=>  NIL, #<SIMPLE-ERROR 32212257>
+
+ (let ((*break-on-signals* 'error))
+   (error 'simple-error :format-control "Fooey!"))
+>>  Break: Fooey!
+>>  BREAK entered because of *BREAK-ON-SIGNALS*.
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Continue to signal.
+>>   2: Top level.
+>>  Debug> :CONTINUE 1
+>>  Continue to signal.
+>>  Error: Fooey!
+>>  To continue, type :CONTINUE followed by an option number:
+>>   1: Top level.
+>>  Debug> :CONTINUE 1
+>>  Top level.
+
+

+

Affected By: None. +

+

See Also:

+

+break, signal, warn, error, typep, Section 9.1 (Condition System Concepts)

+

Notes:

+

+*break-on-signals* is intended primarily for use in debugging code that does signaling. When setting *break-on-signals*, the user is encouraged to choose the most restrictive specification that suffices. Setting *break-on-signals* effectively violates the modular handling of condition signaling. In practice, the complete effect of setting *break-on-signals* might be unpredictable in some cases since the user might not be aware of the variety or number of calls to signal that are used in code called only incidentally.

+

+*break-on-signals* enables an early entry to the debugger but such an entry does not preclude an additional entry to the debugger in the case of operations such as error and cerror.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_call_a.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_call_a.htm new file mode 100644 index 00000000..1146fffe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_call_a.htm @@ -0,0 +1,40 @@ + + + +CLHS: Constant Variable CALL-ARGUMENTS-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable CALL-ARGUMENTS-LIMIT

+

Constant Value:

+

+An integer not smaller than 50 and at least as great as the value of lambda-parameters-limit, the exact magnitude of which is implementation-dependent.

+

Description:

+

+The upper exclusive bound on the number of arguments that may be passed to a function.

+

Examples: None. +

+

See Also:

+

+lambda-parameters-limit, multiple-values-limit

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_char_c.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_char_c.htm new file mode 100644 index 00000000..c2afdc03 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_char_c.htm @@ -0,0 +1,39 @@ + + + +CLHS: Constant Variable CHAR-CODE-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable CHAR-CODE-LIMIT

+

Constant Value:

+

+A non-negative integer, the exact magnitude of which is implementation-dependent, but which is not less than 96 (the number of standard characters).

+

Description:

+

+The upper exclusive bound on the value returned by the function char-code.

+

See Also:

+

+char-code

+

Notes:

+

+The value of char-code-limit might be larger than the actual number of characters supported by the implementation.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_fi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_fi.htm new file mode 100644 index 00000000..ef18fe92 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_fi.htm @@ -0,0 +1,51 @@ + + + +CLHS: Variable *COMPILE-FILE-PATHNAME*... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*

+

+

Value Type:

+

+The value of *compile-file-pathname* must always be a pathname or nil. The value of *compile-file-truename* must always be a physical pathname or nil.

+

Initial Value:

+

+nil.

+

Description:

+

+During a call to compile-file, *compile-file-pathname* is bound to the pathname denoted by the first argument to compile-file, merged against the defaults; that is, it is bound to (pathname (merge-pathnames input-file)). During the same time interval, *compile-file-truename* is bound to the truename of the file being compiled.

+At other times, the value of these variables is nil.

+If a break loop is entered while compile-file is ongoing, it is implementation-dependent whether these variables retain the values they had just prior to entering the break loop or whether they are bound to nil.

+The consequences are unspecified if an attempt is made to assign or bind either of these variables.

+

Examples: None. +

+

Affected By:

+

+The file system.

+

See Also:

+

+compile-file

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_pr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_pr.htm new file mode 100644 index 00000000..b083aa5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_cmp_pr.htm @@ -0,0 +1,47 @@ + + + +CLHS: Variable *COMPILE-PRINT*, *COMPILE-VERBOSE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*

+

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The value of *compile-print* is the default value of the :print argument to compile-file. The value of *compile-verbose* is the default value of the :verbose argument to compile-file.

+

Examples: None. +

+

Affected By: None. +

+

See Also:

+

+compile-file

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debug_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debug_.htm new file mode 100644 index 00000000..28d13be9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debug_.htm @@ -0,0 +1,91 @@ + + + +CLHS: Variable *DEBUG-IO*, *ERROR-OUTPUT*... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*

+

Value Type:

+

+For *standard-input*: an input stream

+For *error-output*, *standard-output*, and *trace-output*: an output stream.

+For *debug-io*, *query-io*: a bidirectional stream.

+

Initial Value:

+

+implementation-dependent, but it must be an open stream that is not a generalized synonym stream to an I/O customization variables but that might be a generalized synonym stream to the value of some I/O customization variable. The initial value might also be a generalized synonym stream to either the symbol *terminal-io* or to the stream that is its value.

+

Description:

+

+These variables are collectively called the standardized I/O customization variables. They can be bound or assigned in order to change the default destinations for input and/or output used by various standardized operators and facilities.

+The value of *debug-io*, called debug I/O, is a stream to be used for interactive debugging purposes.

+The value of *error-output*, called error output, is a stream to which warnings and non-interactive error messages should be sent.

+The value of *query-io*, called query I/O, is a bidirectional stream to be used when asking questions of the user. The question should be output to this stream, and the answer read from it.

+ The value of *standard-input*, called standard input, is a stream that is used by many operators as a default source of input when no specific input stream is explicitly supplied.

+The value of *standard-output*, called standard output, is a stream that is used by many operators as a default destination for output when no specific output stream is explicitly supplied.

+The value of *trace-output*, called trace output, is the stream on which traced functions (see trace) and the time macro print their output.

+

Examples:

+

+

+ (with-output-to-string (*error-output*)
+   (warn "this string is sent to *error-output*"))
+ =>  "Warning: this string is sent to *error-output*
+" ;The exact format of this string is implementation-dependent.
+
+ (with-input-from-string (*standard-input* "1001")
+    (+ 990 (read))) =>  1991                       
+
+ (progn (setq out (with-output-to-string (*standard-output*)
+                     (print "print and format t send things to")
+                     (format t "*standard-output* now going to a string")))
+        :done)
+=>  :DONE
+ out
+=>  "
+\"print and format t send things to\" *standard-output* now going to a string"
+
+ (defun fact (n) (if (< n 2) 1 (* n (fact (- n 1)))))
+=>  FACT
+ (trace fact)
+=>  (FACT)
+;; Of course, the format of traced output is implementation-dependent.
+ (with-output-to-string (*trace-output*)
+   (fact 3)) 
+=>  "
+1 Enter FACT 3
+| 2 Enter FACT 2
+|   3 Enter FACT 1
+|   3 Exit FACT 1
+| 2 Exit FACT 2
+1 Exit FACT 6"
+
+

+

See Also:

+

+*terminal-io*, synonym-stream, time, trace, Section 9 (Conditions), Section 23 (Reader), Section 22 (Printer)

+

Notes:

+

+ The intent of the constraints on the initial value of the I/O customization variables is to ensure that it is always safe to bind or assign such a variable to the value of another I/O customization variable, without unduly restricting implementation flexibility.

+It is common for an implementation to make the initial values of *debug-io* and *query-io* be the same stream, and to make the initial values of *error-output* and *standard-output* be the same stream.

+The functions y-or-n-p and yes-or-no-p use query I/O for their input and output.

+In the normal Lisp read-eval-print loop, input is read from standard input. Many input functions, including read and read-char, take a stream argument that defaults to standard input.

+In the normal Lisp read-eval-print loop, output is sent to standard output. Many output functions, including print and write-char, take a stream argument that defaults to standard output.

+A program that wants, for example, to divert output to a file should do so by binding *standard-output*; that way error messages sent to *error-output* can still get to the user by going through *terminal-io* (if *error-output* is bound to *terminal-io*), which is usually what is desired.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debugg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debugg.htm new file mode 100644 index 00000000..132eebe5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_debugg.htm @@ -0,0 +1,81 @@ + + + +CLHS: Variable *DEBUGGER-HOOK* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *DEBUGGER-HOOK*

+

Value Type:

+

+a designator for a function of two arguments (a condition and the value of *debugger-hook* at the time the debugger was entered), or nil.

+

Initial Value:

+

+nil.

+

Description:

+

+When the value of *debugger-hook* is non-nil, it is called prior to normal entry into the debugger, either due to a call to invoke-debugger or due to automatic entry into the debugger from a call to error or cerror with a condition that is not handled. The function may either handle the condition (transfer control) or return normally (allowing the standard debugger to run). To minimize recursive errors while debugging, *debugger-hook* is bound to nil by invoke-debugger prior to calling the function.

+

Examples:

+

+

+ (defun one-of (choices &optional (prompt "Choice"))
+   (let ((n (length choices)) (i))
+     (do ((c choices (cdr c)) (i 1 (+ i 1)))
+         ((null c))
+       (format t "~&[~D] ~A~%" i (car c)))
+     (do () ((typep i `(integer 1 ,n)))
+       (format t "~&~A: " prompt)
+       (setq i (read))
+       (fresh-line))
+     (nth (- i 1) choices)))
+
+ (defun my-debugger (condition me-or-my-encapsulation)
+   (format t "~&Fooey: ~A" condition)
+   (let ((restart (one-of (compute-restarts))))
+     (if (not restart) (error "My debugger got an error."))
+     (let ((*debugger-hook* me-or-my-encapsulation))
+       (invoke-restart-interactively restart))))
+ 
+ (let ((*debugger-hook* #'my-debugger))
+   (+ 3 'a))
+>>  Fooey: The argument to +, A, is not a number.
+>>   [1] Supply a replacement for A.
+>>   [2] Return to Cloe Toplevel.
+>>  Choice: 1
+>>   Form to evaluate and use: (+ 5 'b)
+>>   Fooey: The argument to +, B, is not a number.
+>>   [1] Supply a replacement for B.
+>>   [2] Supply a replacement for A.
+>>   [3] Return to Cloe Toplevel.
+>>  Choice: 1
+>>   Form to evaluate and use: 1
+=>  9
+
+

+

Affected By:

+

+invoke-debugger

+

See Also: None. +

+

Notes:

+

+When evaluating code typed in by the user interactively, it is sometimes useful to have the hook function bind *debugger-hook* to the function that was its second argument so that recursive errors can be handled using the same interactive facility.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_defaul.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_defaul.htm new file mode 100644 index 00000000..9bac043e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_defaul.htm @@ -0,0 +1,58 @@ + + + +CLHS: Variable *DEFAULT-PATHNAME-DEFAULTS* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *DEFAULT-PATHNAME-DEFAULTS*

+

Value Type:

+

+a pathname object.

+

Initial Value:

+

+An implementation-dependent pathname, typically in the working directory that was current when Common Lisp was started up.

+

Description:

+

+a pathname, used as the default whenever a function needs a default pathname and one is not supplied.

+

Examples:

+ +

+ ;; This example illustrates a possible usage for a hypothetical Lisp running on a
+ ;; DEC TOPS-20 file system.  Since pathname conventions vary between Lisp 
+ ;; implementations and host file system types, it is not possible to provide a
+ ;; general-purpose, conforming example.
+ *default-pathname-defaults* =>  #P"PS:<FRED>"
+ (merge-pathnames (make-pathname :name "CALENDAR"))
+=>  #P"PS:<FRED>CALENDAR"
+ (let ((*default-pathname-defaults* (pathname "<MARY>")))
+   (merge-pathnames (make-pathname :name "CALENDAR")))
+=>  #P"<MARY>CALENDAR"
+
+

+

Affected By:

+

+The implementation.

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_featur.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_featur.htm new file mode 100644 index 00000000..aad7161a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_featur.htm @@ -0,0 +1,67 @@ + + + +CLHS: Variable *FEATURES* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *FEATURES*

+

Value Type:

+

+a proper list.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The value of *features* is called the features list. It is a list of symbols, called features, that correspond to some aspect of the implementation or environment.

+Most features have implementation-dependent meanings; The following meanings have been assigned to feature names:

+

+

:cltl1

+If present, indicates that the LISP package purports to conform to the 1984 specification Common Lisp: The Language. It is possible, but not required, for a conforming implementation to have this feature because this specification specifies that its symbols are to be in the COMMON-LISP package, not the LISP package.

+

:cltl2

+If present, indicates that the implementation purports to conform to Common Lisp: The Language, Second Edition. This feature must not be present in any conforming implementation, since conformance to that document is not compatible with conformance to this specification. The name, however, is reserved by this specification in order to help programs distinguish implementations which conform to that document from implementations which conform to this specification.

+

:ieee-floating-point

+If present, indicates that the implementation purports to conform to the requirements of IEEE Standard for Binary Floating-Point Arithmetic.

+

:x3j13

+If present, indicates that the implementation conforms to some particular working draft of this specification, or to some subset of features that approximates a belief about what this specification might turn out to contain. A conforming implementation might or might not contain such a feature. (This feature is intended primarily as a stopgap in order to provide implementors something to use prior to the availability of a draft standard, in order to discourage them from introducing the :draft-ansi-cl and :ansi-cl features prematurely.)

+

:draft-ansi-cl

+If present, indicates that the implementation purports to conform to the first full draft of this specification, which went to public review in 1992. A conforming implementation which has the :draft-ansi-cl-2 or :ansi-cl feature is not permitted to retain the :draft-ansi-cl feature since incompatible changes were made subsequent to the first draft.

+

:draft-ansi-cl-2

+If present, indicates that a second full draft of this specification has gone to public review, and that the implementation purports to conform to that specification. (If additional public review drafts are produced, this keyword will continue to refer to the second draft, and additional keywords will be added to identify conformance with such later drafts. As such, the meaning of this keyword can be relied upon not to change over time.) A conforming implementation which has the :ansi-cl feature is only permitted to retain the :draft-ansi-cl feature if the finally approved standard is not incompatible with the draft standard.

+

:ansi-cl

+If present, indicates that this specification has been adopted by ANSI as an official standard, and that the implementation purports to conform.

+

:common-lisp

+This feature must appear in *features* for any implementation that has one or more of the features :x3j13, :draft-ansi-cl, or :ansi-cl. It is intended that it should also appear in implementations which have the features :cltl1 or :cltl2, but this specification cannot force such behavior. The intent is that this feature should identify the language family named ``Common Lisp,'' rather than some specific dialect within that family.

+

+

Examples: None. +

+

Affected By: None. +

+

See Also:

+

+Section 1.5.2.1.1 (Use of Read-Time Conditionals), Section 2.4 (Standard Macro Characters)

+

Notes:

+

+The value of *features* is used by the #+ and #- reader syntax.

+ Symbols in the features list may be in any package, but in practice they are generally in the KEYWORD package. This is because KEYWORD is the package used by default when reading[2] feature expressions in the #+ and #- reader macros. Code that needs to name a feature[2] in a package P (other than KEYWORD) can do so by making explicit use of a package prefix for P, but note that such code must also assure that the package P exists in order for the feature expression to be read[2]---even in cases where the feature expression is expected to fail.

+It is generally considered wise for an implementation to include one or more features identifying the specific implementation, so that conditional expressions can be written which distinguish idiosyncrasies of one implementation from those of another. Since features are normally symbols in the KEYWORD package where name collisions might easily result, and since no uniquely defined mechanism is designated for deciding who has the right to use which symbol for what reason, a conservative strategy is to prefer names derived from one's own company or product name, since those names are often trademarked and are hence less likely to be used unwittingly by another implementation.

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_gensym.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_gensym.htm new file mode 100644 index 00000000..4defcc3a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_gensym.htm @@ -0,0 +1,47 @@ + + + +CLHS: Variable *GENSYM-COUNTER* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *GENSYM-COUNTER*

+

Value Type:

+

+a non-negative integer.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+A number which will be used in constructing the name of the next symbol generated by the function gensym.

+*gensym-counter* can be either assigned or bound at any time, but its value must always be a non-negative integer.

+

Examples: None. +

+

Affected By:

+

+gensym.

+

See Also:

+

+gensym

+

Notes:

+

+The ability to pass a numeric argument to gensym has been deprecated; explicitly binding *gensym-counter* is now stylistically preferred.

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_intern.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_intern.htm new file mode 100644 index 00000000..f9aa6b7e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_intern.htm @@ -0,0 +1,41 @@ + + + +CLHS: Constant Variable INTERNAL-TIME-UNITS-PER-SECOND + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable INTERNAL-TIME-UNITS-PER-SECOND

+

Constant Value:

+

+A positive integer, the magnitude of which is implementation-dependent.

+

Description:

+

+The number of internal time units in one second.

+

Examples: None. +

+

See Also:

+

+get-internal-run-time, get-internal-real-time

+

Notes:

+

+These units form the basis of the Internal Time format representation.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lamb_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lamb_1.htm new file mode 100644 index 00000000..51055480 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lamb_1.htm @@ -0,0 +1,41 @@ + + + +CLHS: Constant Variable LAMBDA-PARAMETERS-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable LAMBDA-PARAMETERS-LIMIT

+

Constant Value:

+

+implementation-dependent, but not smaller than 50.

+

Description:

+

+A positive integer that is the upper exclusive bound on the number of parameter names that can appear in a single lambda list.

+

Examples: None. +

+

See Also:

+

+call-arguments-limit

+

Notes:

+

+Implementors are encouraged to make the value of lambda-parameters-limit as large as possible.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lambda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lambda.htm new file mode 100644 index 00000000..9132ba01 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_lambda.htm @@ -0,0 +1,40 @@ + + + +CLHS: Constant Variable LAMBDA-LIST-KEYWORDS + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable LAMBDA-LIST-KEYWORDS

+

Constant Value:

+

+a list, the elements of which are implementation-dependent, but which must contain at least the symbols &allow-other-keys, &aux, &body, &environment, &key, &optional, &rest, and &whole.

+

Description:

+

+A list of all the lambda list keywords used in the implementation, including the additional ones used only by macro definition forms.

+

Examples: None. +

+

See Also:

+

+defun, flet, defmacro, macrolet, Section 3.1.2 (The Evaluation Model)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_pns.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_pns.htm new file mode 100644 index 00000000..b12db994 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_pns.htm @@ -0,0 +1,50 @@ + + + +CLHS: Variable *LOAD-PATHNAME*, *LOAD-TRUENAME* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*

+

Value Type:

+

+The value of *load-pathname* must always be a pathname or nil. The value of *load-truename* must always be a physical pathname or nil.

+

Initial Value:

+

+nil.

+

Description:

+

+During a call to load, *load-pathname* is bound to the pathname denoted by the the first argument to load, merged against the defaults; that is, it is bound to (pathname (merge-pathnames filespec)). During the same time interval, *load-truename* is bound to the truename of the file being loaded.

+At other times, the value of these variables is nil.

+If a break loop is entered while load is ongoing, it is implementation-dependent whether these variables retain the values they had just prior to entering the break loop or whether they are bound to nil.

+The consequences are unspecified if an attempt is made to assign or bind either of these variables.

+

Examples: None. +

+

Affected By:

+

+The file system.

+

See Also:

+

+load

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_prs.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_prs.htm new file mode 100644 index 00000000..6e442501 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_ld_prs.htm @@ -0,0 +1,46 @@ + + + +CLHS: Variable *LOAD-PRINT*, *LOAD-VERBOSE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *LOAD-PRINT*, *LOAD-VERBOSE*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+The initial value of *load-print* is false. The initial value of *load-verbose* is implementation-dependent.

+

Description:

+

+The value of *load-print* is the default value of the :print argument to load. The value of *load-verbose* is the default value of the :verbose argument to load.

+

Examples: None. +

+

Affected By: None. +

+

See Also:

+

+load

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_mexp_h.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_mexp_h.htm new file mode 100644 index 00000000..a497924a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_mexp_h.htm @@ -0,0 +1,61 @@ + + + +CLHS: Variable *MACROEXPAND-HOOK* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *MACROEXPAND-HOOK*

+

+

Value Type:

+

+a designator for a function of three arguments: a macro function, a macro form, and an environment object.

+

Initial Value:

+

+ a designator for a function that is equivalent to the function funcall, but that might have additional implementation-dependent side-effects.

+

Description:

+

+Used as the expansion interface hook by macroexpand-1 to control the macro expansion process. When a macro form is to be expanded, this function is called with three arguments: the macro function, the macro form, and the environment in which the macro form is to be expanded. The environment object has dynamic extent; the consequences are undefined if the environment object is referred to outside the dynamic extent of the macro expansion function.

+

Examples:

+

+

+ (defun hook (expander form env)
+    (format t "Now expanding: ~S~%" form)
+    (funcall expander form env)) =>  HOOK 
+ (defmacro machook (x y) `(/ (+ ,x ,y) 2)) =>  MACHOOK 
+ (macroexpand '(machook 1 2)) =>  (/ (+ 1 2) 2), true 
+ (let ((*macroexpand-hook* #'hook)) (macroexpand '(machook 1 2)))
+>>  Now expanding (MACHOOK 1 2) 
+=>  (/ (+ 1 2) 2), true
+
+

+

Affected By: None. +

+

See Also:

+

+macroexpand, macroexpand-1, funcall, Section 3.1 (Evaluation)

+

Notes:

+

+The net effect of the chosen initial value is to just invoke the macro function, giving it the macro form and environment as its two arguments.

+Users or user programs can assign this variable to customize or trace the macro expansion mechanism. Note, however, that this variable is a global resource, potentially shared by multiple programs; as such, if any two programs depend for their correctness on the setting of this variable, those programs may not be able to run in the same Lisp image. For this reason, it is frequently best to confine its uses to debugging situations.

+ Users who put their own function into *macroexpand-hook* should consider saving the previous value of the hook, and calling that value from their own.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_module.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_module.htm new file mode 100644 index 00000000..e692345d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_module.htm @@ -0,0 +1,49 @@ + + + +CLHS: Variable *MODULES* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *MODULES*

+

+

Value Type:

+

+a list of strings.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The value of *modules* is a list of names of the modules that have been loaded into the current Lisp image.

+

Examples: None. +

+

Affected By:

+

+provide

+

See Also:

+

+provide, require

+

Notes:

+

+The variable *modules* is deprecated.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_1.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_1.htm new file mode 100644 index 00000000..0d76e853 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_1.htm @@ -0,0 +1,53 @@ + + + +CLHS: Constant Variable MOST-POSITIVE-SHORT-FLOAT... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT

+

+

Constant Value:

+

+implementation-dependent.

+

Description:

+

+These constant variables provide a way for programs to examine the implementation-defined limits for the various float formats.

+Of these variables, each which has ``-normalized'' in its name must have a value which is a normalized float, and each which does not have ``-normalized'' in its name may have a value which is either a normalized float or a denormalized float, as appropriate.

+Of these variables, each which has ``short-float'' in its name must have a value which is a short float, each which has ``single-float'' in its name must have a value which is a single float, each which has ``double-float'' in its name must have a value which is a double float, and each which has ``long-float'' in its name must have a value which is a long float.

+

+

Examples: None. +

+

See Also: None. +

+

Notes:

+

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_p.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_p.htm new file mode 100644 index 00000000..c1777295 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_most_p.htm @@ -0,0 +1,40 @@ + + + +CLHS: Constant Variable MOST-POSITIVE-FIXNUM... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM

+

Constant Value:

+

+implementation-dependent.

+

Description:

+

+most-positive-fixnum is that fixnum closest in value to positive infinity provided by the implementation, and greater than or equal to both 2^15 - 1 and array-dimension-limit.

+most-negative-fixnum is that fixnum closest in value to negative infinity provided by the implementation, and less than or equal to -2^15.

+

Examples: None. +

+

See Also: None. +

+

Notes: None. +

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_multip.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_multip.htm new file mode 100644 index 00000000..73c1b853 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_multip.htm @@ -0,0 +1,41 @@ + + + +CLHS: Constant Variable MULTIPLE-VALUES-LIMIT + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable MULTIPLE-VALUES-LIMIT

+

Constant Value:

+

+An integer not smaller than 20, the exact magnitude of which is implementation-dependent.

+

Description:

+

+The upper exclusive bound on the number of values that may be returned from a function, bound or assigned by multiple-value-bind or multiple-value-setq, or passed as a first argument to nth-value. (If these individual limits might differ, the minimum value is used.)

+

Examples: None. +

+

See Also:

+

+lambda-parameters-limit, call-arguments-limit

+

Notes:

+

+Implementors are encouraged to make this limit as large as possible.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_nil.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_nil.htm new file mode 100644 index 00000000..e74c2108 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_nil.htm @@ -0,0 +1,44 @@ + + + +CLHS: Constant Variable NIL + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable NIL

+

Constant Value:

+

+nil.

+

Description:

+

+nil represents both boolean (and generalized boolean) false and the empty list.

+

Examples:

+ +

+ nil =>  NIL 
+
+

+

See Also:

+

+t

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pi.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pi.htm new file mode 100644 index 00000000..c2388f3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pi.htm @@ -0,0 +1,54 @@ + + + +CLHS: Constant Variable PI + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable PI

+

Value:

+

+an implementation-dependent long float.

+

Description:

+

+The best long float approximation to the mathematical constant <PI>.

+

Examples:

+

+

+ ;; In each of the following computations, the precision depends 
+ ;; on the implementation.  Also, if `long float' is treated by 
+ ;; the implementation as equivalent to some other float format 
+ ;; (e.g., `double float') the exponent marker might be the marker
+ ;; for that equivalent (e.g., `D' instead of `L').
+ pi =>  3.141592653589793L0
+ (cos pi) =>  -1.0L0
+
+ (defun sin-of-degrees (degrees)
+   (let ((x (if (floatp degrees) degrees (float degrees pi))))
+     (sin (* x (/ (float pi x) 180)))))
+
+

+

See Also: None. +

+

Notes:

+

+An approximation to <PI> in some other precision can be obtained by writing (float pi x), where x is a float of the desired precision, or by writing (coerce pi type), where type is the desired type, such as short-float.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pkg.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pkg.htm new file mode 100644 index 00000000..7246e028 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pkg.htm @@ -0,0 +1,66 @@ + + + +CLHS: Variable *PACKAGE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PACKAGE*

+

Value Type:

+

+a package object.

+

Initial Value:

+

+the COMMON-LISP-USER package.

+

Description:

+

+Whatever package object is currently the value of *package* is referred to as the current package.

+

Examples:

+

+

+ (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
+ *package* =>  #<PACKAGE "COMMON-LISP-USER">
+ (make-package "SAMPLE-PACKAGE" :use '("COMMON-LISP"))
+=>  #<PACKAGE "SAMPLE-PACKAGE">
+ (list 
+   (symbol-package
+     (let ((*package* (find-package 'sample-package)))
+       (setq *some-symbol* (read-from-string "just-testing"))))
+   *package*)
+=>  (#<PACKAGE "SAMPLE-PACKAGE"> #<PACKAGE "COMMON-LISP-USER">)
+ (list (symbol-package (read-from-string "just-testing"))
+       *package*)
+=>  (#<PACKAGE "COMMON-LISP-USER"> #<PACKAGE "COMMON-LISP-USER">)
+ (eq 'foo (intern "FOO")) =>  true
+ (eq 'foo (let ((*package* (find-package 'sample-package)))
+            (intern "FOO")))
+=>  false
+
+

+

Affected By:

+

+load, compile-file, in-package

+

See Also:

+

+compile-file, in-package, load, package

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pl_plp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pl_plp.htm new file mode 100644 index 00000000..7e196f72 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pl_plp.htm @@ -0,0 +1,59 @@ + + + +CLHS: Variable +, ++, +++ + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable +, ++, +++

+

Value Type:

+

+an object.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The variables +, ++, and +++ are maintained by the Lisp read-eval-print loop to save forms that were recently evaluated.

+The value of + is the last form that was evaluated, the value of ++ is the previous value of +, and the value of +++ is the previous value of ++.

+

Examples:

+ +

+(+ 0 1) =>  1
+(- 4 2) =>  2
+(/ 9 3) =>  3
+(list + ++ +++) =>  ((/ 9 3) (- 4 2) (+ 0 1))
+(setq a 1 b 2 c 3 d (list a b c)) =>  (1 2 3)
+(setq a 4 b 5 c 6 d (list a b c)) =>  (4 5 6)
+(list a b c) =>  (4 5 6)
+(eval +++) =>  (1 2 3)
+#.`(,@++ d) =>  (1 2 3 (1 2 3))
+
+

+

Affected By:

+

+Lisp read-eval-print loop.

+

See Also:

+

+- (variable), * (variable), / (variable), Section 25.1.1 (Top level loop)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ar.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ar.htm new file mode 100644 index 00000000..e15cf008 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ar.htm @@ -0,0 +1,46 @@ + + + +CLHS: Variable *PRINT-ARRAY* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-ARRAY*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+Controls the format in which arrays are printed. If it is false, the contents of arrays other than strings are never printed. Instead, arrays are printed in a concise form using #< that gives enough information for the user to be able to identify the array, but does not include the entire array contents. If it is true, non-string arrays are printed using #(...), #*, or #nA syntax.

+

Examples: None. +

+

Affected By:

+

+The implementation.

+

See Also:

+

+Section 2.4.8.3 (Sharpsign Left-Parenthesis), Section 2.4.8.20 (Sharpsign Less-Than-Sign)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_bas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_bas.htm new file mode 100644 index 00000000..680a100d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_bas.htm @@ -0,0 +1,77 @@ + + + +CLHS: Variable *PRINT-BASE*, *PRINT-RADIX* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-BASE*, *PRINT-RADIX*

+

Value Type:

+

+*print-base*---a radix. *print-radix*---a generalized boolean.

+

Initial Value:

+

+The initial value of *print-base* is 10. The initial value of *print-radix* is false.

+

Description:

+

+*print-base* and *print-radix* control the printing of rationals. The value of *print-base* is called the current output base.

+The value of *print-base* is the radix in which the printer will print rationals. For radices above 10, letters of the alphabet are used to represent digits above 9.

+If the value of *print-radix* is true, the printer will print a radix specifier to indicate the radix in which it is printing a rational number. The radix specifier is always printed using lowercase letters. If *print-base* is 2, 8, or 16, then the radix specifier used is #b, #o, or #x, respectively. For integers, base ten is indicated by a trailing decimal point instead of a leading radix specifier; for ratios, #10r is used.

+

Examples:

+

+

+ (let ((*print-base* 24.) (*print-radix* t)) 
+   (print 23.))
+>>  #24rN
+=>  23
+ (setq *print-base* 10) =>  10
+ (setq *print-radix* nil) =>  NIL                                          
+ (dotimes (i 35)
+    (let ((*print-base* (+ i 2)))           ;print the decimal number 40 
+      (write 40)                            ;in each base from 2 to 36
+      (if (zerop (mod i 10)) (terpri) (format t " "))))
+>>  101000
+>>  1111 220 130 104 55 50 44 40 37 34
+>>  31 2C 2A 28 26 24 22 20 1J 1I
+>>  1H 1G 1F 1E 1D 1C 1B 1A 19 18
+>>  17 16 15 14 
+=>  NIL
+ (dolist (pb '(2 3 8 10 16))               
+    (let ((*print-radix* t)                 ;print the integer 10 and 
+          (*print-base* pb))                ;the ratio 1/10 in bases 2, 
+     (format t "~&~S  ~S~%" 10 1/10)))        ;3, 8, 10, 16
+>>  #b1010  #b1/1010
+>>  #3r101  #3r1/101
+>>  #o12  #o1/12
+>>  10.  #10r1/10
+>>  #xA  #x1/A
+=>  NIL
+
+

+

Affected By:

+

+Might be bound by format, and write, write-to-string.

+

See Also:

+

+format, write, write-to-string

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cas.htm new file mode 100644 index 00000000..aa28b367 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cas.htm @@ -0,0 +1,69 @@ + + + +CLHS: Variable *PRINT-CASE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-CASE*

+

Value Type:

+

+One of the symbols :upcase, :downcase, or :capitalize.

+

Initial Value:

+

+The symbol :upcase.

+

Description:

+

+The value of *print-case* controls the case (upper, lower, or mixed) in which to print any uppercase characters in the names of symbols when vertical-bar syntax is not used.

+ *print-case* has an effect at all times when the value of *print-escape* is false. *print-case* also has an effect when the value of *print-escape* is true unless inside an escape context (i.e., unless between vertical-bars or after a slash).

+

Examples:

+

+

+ (defun test-print-case ()
+   (dolist (*print-case* '(:upcase :downcase :capitalize))
+     (format t "~&~S ~S~%" 'this-and-that '|And-something-elSE|)))
+=>  TEST-PC
+;; Although the choice of which characters to escape is specified by
+;; *PRINT-CASE*, the choice of how to escape those characters 
+;; (i.e., whether single escapes or multiple escapes are used)
+;; is implementation-dependent.  The examples here show two of the
+;; many valid ways in which escaping might appear.
+ (test-print-case) ;Implementation A
+>>  THIS-AND-THAT |And-something-elSE|
+>>  this-and-that a\n\d-\s\o\m\e\t\h\i\n\g-\e\lse
+>>  This-And-That A\n\d-\s\o\m\e\t\h\i\n\g-\e\lse
+=>  NIL
+ (test-print-case) ;Implementation B
+>>  THIS-AND-THAT |And-something-elSE|
+>>  this-and-that a|nd-something-el|se
+>>  This-And-That A|nd-something-el|se
+=>  NIL
+
+

+

Affected By: None. +

+

See Also:

+

+write

+

Notes:

+

+read normally converts lowercase characters appearing in symbols to corresponding uppercase characters, so that internally print names normally contain only uppercase characters.

+If *print-escape* is true, lowercase characters in the name of a symbol are always printed in lowercase, and are preceded by a single escape character or enclosed by multiple escape characters; uppercase characters in the name of a symbol are printed in upper case, in lower case, or in mixed case so as to capitalize words, according to the value of *print-case*. The convention for what constitutes a ``word'' is the same as for string-capitalize.

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cir.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cir.htm new file mode 100644 index 00000000..46976b50 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_cir.htm @@ -0,0 +1,62 @@ + + + +CLHS: Variable *PRINT-CIRCLE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-CIRCLE*

+

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+false.

+

Description:

+

+Controls the attempt to detect circularity and sharing in an object being printed.

+If false, the printing process merely proceeds by recursive descent without attempting to detect circularity and sharing.

+If true, the printer will endeavor to detect cycles and sharing in the structure to be printed, and to use #n= and #n# syntax to indicate the circularities or shared components.

+ If true, a user-defined print-object method can print objects to the supplied stream using write, prin1, princ, or format and expect circularities and sharing to be detected and printed using the #n# syntax. If a user-defined print-object method prints to a stream other than the one that was supplied, then circularity detection starts over for that stream.

+Note that implementations should not use #n# notation when the Lisp reader would automatically assure sharing without it (e.g., as happens with interned symbols).

+

Examples:

+

+

+ (let ((a (list 1 2 3)))
+   (setf (cdddr a) a)
+   (let ((*print-circle* t))
+     (write a)
+     :done))
+>>  #1=(1 2 3 . #1#)
+=>  :DONE
+
+

+

Affected By: None. +

+

See Also:

+

+write

+

Notes:

+

+An attempt to print a circular structure with *print-circle* set to nil may lead to looping behavior and failure to terminate.

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_esc.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_esc.htm new file mode 100644 index 00000000..f842211a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_esc.htm @@ -0,0 +1,58 @@ + + + +CLHS: Variable *PRINT-ESCAPE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-ESCAPE*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+true.

+

Description:

+

+If false, escape characters and package prefixes are not output when an expression is printed.

+If true, an attempt is made to print an expression in such a way that it can be read again to produce an equal expression. (This is only a guideline; not a requirement. See *print-readably*.)

+For more specific details of how the value of *print-escape* affects the printing of certain types, see Section 22.1.3 (Default Print-Object Methods).

+

Examples:

+ +

+ (let ((*print-escape* t)) (write #\a))
+>>  #\a
+=>  #\a
+ (let ((*print-escape* nil)) (write #\a))
+>>  a
+=>  #\a
+
+

+

Affected By:

+

+princ, prin1, format

+

See Also:

+

+write, readtable-case

+

Notes:

+

+princ effectively binds *print-escape* to false. prin1 effectively binds *print-escape* to true.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_gen.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_gen.htm new file mode 100644 index 00000000..6fb56ebe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_gen.htm @@ -0,0 +1,52 @@ + + + +CLHS: Variable *PRINT-GENSYM* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-GENSYM*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+true.

+

Description:

+

+Controls whether the prefix ``#:'' is printed before apparently uninterned symbols. The prefix is printed before such symbols if and only if the value of *print-gensym* is true.

+

Examples:

+

+

+ (let ((*print-gensym* nil))
+   (print (gensym)))
+>>  G6040 
+=>  #:G6040
+
+

+

Affected By: None. +

+

See Also:

+

+write, *print-escape*

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lev.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lev.htm new file mode 100644 index 00000000..dabe541c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lev.htm @@ -0,0 +1,96 @@ + + + +CLHS: Variable *PRINT-LEVEL*, *PRINT-LENGTH* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-LEVEL*, *PRINT-LENGTH*

+

Value Type:

+

+a non-negative integer, or nil.

+

Initial Value:

+

+nil.

+

Description:

+

+*print-level* controls how many levels deep a nested object will print. If it is false, then no control is exercised. Otherwise, it is an integer indicating the maximum level to be printed. An object to be printed is at level 0; its components (as of a list or vector) are at level 1; and so on. If an object to be recursively printed has components and is at a level equal to or greater than the value of *print-level*, then the object is printed as ``#''.

+*print-length* controls how many elements at a given level are printed. If it is false, there is no limit to the number of components printed. Otherwise, it is an integer indicating the maximum number of elements of an object to be printed. If exceeded, the printer will print ``...'' in place of the other elements. In the case of a dotted list, if the list contains exactly as many elements as the value of *print-length*, the terminating atom is printed rather than printing ``...''

+*print-level* and *print-length* affect the printing of an any object printed with a list-like syntax. They do not affect the printing of symbols, strings, and bit vectors.

+

Examples:

+

+

+ (setq a '(1 (2 (3 (4 (5 (6))))))) =>  (1 (2 (3 (4 (5 (6))))))
+ (dotimes (i 8) 
+   (let ((*print-level* i)) 
+     (format t "~&~D -- ~S~%" i a)))
+>>  0 -- #
+>>  1 -- (1 #)
+>>  2 -- (1 (2 #))
+>>  3 -- (1 (2 (3 #)))
+>>  4 -- (1 (2 (3 (4 #))))
+>>  5 -- (1 (2 (3 (4 (5 #)))))
+>>  6 -- (1 (2 (3 (4 (5 (6))))))
+>>  7 -- (1 (2 (3 (4 (5 (6))))))
+=>  NIL
+
+ (setq a '(1 2 3 4 5 6)) =>  (1 2 3 4 5 6)
+ (dotimes (i 7) 
+   (let ((*print-length* i)) 
+     (format t "~&~D -- ~S~%" i a))) 
+>>  0 -- (...)
+>>  1 -- (1 ...)
+>>  2 -- (1 2 ...)
+>>  3 -- (1 2 3 ...)
+>>  4 -- (1 2 3 4 ...)
+>>  5 -- (1 2 3 4 5 6)
+>>  6 -- (1 2 3 4 5 6)
+=>  NIL
+
+(dolist (level-length '((0 1) (1 1) (1 2) (1 3) (1 4) 
+                        (2 1) (2 2) (2 3) (3 2) (3 3) (3 4)))
+ (let ((*print-level*  (first  level-length))
+       (*print-length* (second level-length)))
+   (format t "~&~D ~D -- ~S~%"
+           *print-level* *print-length* 
+           '(if (member x y) (+ (car x) 3) '(foo . #(a b c d "Baz"))))))
+>>  0 1 -- #
+>>  1 1 -- (IF ...)
+>>  1 2 -- (IF # ...)
+>>  1 3 -- (IF # # ...)
+>>  1 4 -- (IF # # #)
+>>  2 1 -- (IF ...)
+>>  2 2 -- (IF (MEMBER X ...) ...)
+>>  2 3 -- (IF (MEMBER X Y) (+ # 3) ...)
+>>  3 2 -- (IF (MEMBER X ...) ...)
+>>  3 3 -- (IF (MEMBER X Y) (+ (CAR X) 3) ...)
+>>  3 4 -- (IF (MEMBER X Y) (+ (CAR X) 3) '(FOO . #(A B C D ...)))
+=>  NIL
+
+

+

Affected By: None. +

+

See Also:

+

+write

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lin.htm new file mode 100644 index 00000000..becf3277 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_lin.htm @@ -0,0 +1,53 @@ + + + +CLHS: Variable *PRINT-LINES* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-LINES*

+

Value Type:

+

+a non-negative integer, or nil.

+

Initial Value:

+

+nil.

+

Description:

+

+When the value of *print-lines* is other than nil, it is a limit on the number of output lines produced when something is pretty printed. If an attempt is made to go beyond that many lines, ``..'' is printed at the end of the last line followed by all of the suffixes (closing delimiters) that are pending to be printed.

+

Examples:

+

+

+ (let ((*print-right-margin* 25) (*print-lines* 3))
+   (pprint '(progn (setq a 1 b 2 c 3 d 4))))
+>>  (PROGN (SETQ A 1
+>>               B 2
+>>               C 3 ..))
+=>  <no values>
+
+

+

See Also: None. +

+

Notes:

+

+The ``..'' notation is intentionally different than the ``...'' notation used for level abbreviation, so that the two different situations can be visually distinguished.

+This notation is used to increase the likelihood that the Lisp reader will signal an error if an attempt is later made to read the abbreviated output. Note however that if the truncation occurs in a string, as in "This string has been trunc..", the problem situation cannot be detected later and no such error will be signaled.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_mis.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_mis.htm new file mode 100644 index 00000000..075b5bd6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_mis.htm @@ -0,0 +1,44 @@ + + + +CLHS: Variable *PRINT-MISER-WIDTH* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-MISER-WIDTH*

+

+

Value Type:

+

+a non-negative integer, or nil.

+

Initial Value:

+

+implementation-dependent

+

Description:

+

+If it is not nil, the pretty printer switches to a compact style of output (called miser style) whenever the width available for printing a substructure is less than or equal to this many ems.

+

Examples: None. +

+

See Also: None. +

+

Notes: None. +

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ppr.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ppr.htm new file mode 100644 index 00000000..bc676d50 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_ppr.htm @@ -0,0 +1,45 @@ + + + +CLHS: Variable *PRINT-PPRINT-DISPATCH* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-PPRINT-DISPATCH*

+

+

Value Type:

+

+a pprint dispatch table.

+

Initial Value:

+

+implementation-dependent, but the initial entries all use a special class of priorities that have the property that they are less than every priority that can be specified using set-pprint-dispatch, so that the initial contents of any entry can be overridden.

+

Description:

+

+The pprint dispatch table which currently controls the pretty printer.

+

Examples: None. +

+

See Also:

+

+*print-pretty*, Section 22.2.1.4 (Pretty Print Dispatch Tables)

+

Notes:

+

+The intent is that the initial value of this variable should cause `traditional' pretty printing of code. In general, however, you can put a value in *print-pprint-dispatch* that makes pretty-printed output look exactly like non-pretty-printed output. Setting *print-pretty* to true just causes the functions contained in the current pprint dispatch table to have priority over normal print-object methods; it has no magic way of enforcing that those functions actually produce pretty output. For details, see Section 22.2.1.4 (Pretty Print Dispatch Tables).

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_pre.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_pre.htm new file mode 100644 index 00000000..949ac5ef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_pre.htm @@ -0,0 +1,82 @@ + + + +CLHS: Variable *PRINT-PRETTY* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-PRETTY*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+Controls whether the Lisp printer calls the pretty printer.

+If it is false, the pretty printer is not used and a minimum of whitespace[1] is output when printing an expression.

+If it is true, the pretty printer is used, and the Lisp printer will endeavor to insert extra whitespace[1] where appropriate to make expressions more readable.

+*print-pretty* has an effect even when the value of *print-escape* is false.

+

Examples:

+

+ +

+ (setq *print-pretty* 'nil) =>  NIL
+ (progn (write '(let ((a 1) (b 2) (c 3)) (+ a b c))) nil)
+>>  (LET ((A 1) (B 2) (C 3)) (+ A B C))
+=>  NIL
+ (let ((*print-pretty* t))
+   (progn (write '(let ((a 1) (b 2) (c 3)) (+ a b c))) nil))
+>>  (LET ((A 1)
+>>        (B 2)
+>>        (C 3))
+>>    (+ A B C))
+=>  NIL
+;; Note that the first two expressions printed by this next form
+;; differ from the second two only in whether escape characters are printed.
+;; In all four cases, extra whitespace is inserted by the pretty printer.
+ (flet ((test (x)
+          (let ((*print-pretty* t))
+            (print x)
+            (format t "~%~S " x)
+            (terpri) (princ x) (princ " ")
+            (format t "~%~A " x))))
+  (test '#'(lambda () (list "a" #'c #'d))))
+>>  #'(LAMBDA ()
+>>      (LIST "a" #'C #'D))
+>>  #'(LAMBDA ()
+>>      (LIST "a" #'C #'D))
+>>  #'(LAMBDA ()
+>>      (LIST a b 'C #'D)) 
+>>  #'(LAMBDA ()
+>>      (LIST a b 'C #'D))
+=>  NIL
+
+

+

Affected By: None. +

+

See Also:

+

+write

+

Notes: None. +

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rda.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rda.htm new file mode 100644 index 00000000..949a7910 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rda.htm @@ -0,0 +1,97 @@ + + + +CLHS: Variable *PRINT-READABLY* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-READABLY*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+false.

+

Description:

+

+If *print-readably* is true, some special rules for printing objects go into effect. Specifically, printing any object O1 produces a printed representation that, when seen by the Lisp reader while the standard readtable is in effect, will produce an object O2 that is similar to O1. The printed representation produced might or might not be the same as the printed representation produced when *print-readably* is false. If printing an object readably is not possible, an error of type print-not-readable is signaled rather than using a syntax (e.g., the ``#<'' syntax) that would not be readable by the same implementation. If the value of some other printer control variable is such that these requirements would be violated, the value of that other variable is ignored.

+ Specifically, if *print-readably* is true, printing proceeds as if *print-escape*, *print-array*, and *print-gensym* were also true, and as if *print-length*, *print-level*, and *print-lines* were false.

+If *print-readably* is false, the normal rules for printing and the normal interpretations of other printer control variables are in effect.

+Individual methods for print-object, including user-defined methods, are responsible for implementing these requirements.

+If *read-eval* is false and *print-readably* is true, any such method that would output a reference to the ``#.'' reader macro will either output something else or will signal an error (as described above).

+

Examples:

+

+

+ (let ((x (list "a" '\a (gensym) '((a (b (c))) d e f g)))
+       (*print-escape* nil)
+       (*print-gensym* nil)
+       (*print-level* 3)
+       (*print-length* 3))
+   (write x)
+   (let ((*print-readably* t))
+     (terpri)
+     (write x)
+     :done))
+>>  (a a G4581 ((A #) D E ...))
+>>  ("a" |a| #:G4581 ((A (B (C))) D E F G))
+=>  :DONE
+
+;; This is setup code is shared between the examples
+;; of three hypothetical implementations which follow.
+ (setq table (make-hash-table)) =>  #<HASH-TABLE EQL 0/120 32005763> 
+ (setf (gethash table 1) 'one) =>  ONE
+ (setf (gethash table 2) 'two) =>  TWO
+
+;; Implementation A
+ (let ((*print-readably* t)) (print table))
+ Error: Can't print #<HASH-TABLE EQL 0/120 32005763> readably.
+
+;; Implementation B
+;; No standardized #S notation for hash tables is defined, 
+;; but there might be an implementation-defined notation.
+ (let ((*print-readably* t)) (print table))
+>>  #S(HASH-TABLE :TEST EQL :SIZE 120 :CONTENTS (1 ONE 2 TWO))
+=>  #<HASH-TABLE EQL 0/120 32005763>
+
+;; Implementation C
+;; Note that #. notation can only be used if *READ-EVAL* is true.
+;; If *READ-EVAL* were false, this same implementation might have to
+;; signal an error unless it had yet another printing strategy to fall
+;; back on.
+ (let ((*print-readably* t)) (print table))
+>>  #.(LET ((HASH-TABLE (MAKE-HASH-TABLE)))
+>>      (SETF (GETHASH 1 HASH-TABLE) ONE)
+>>      (SETF (GETHASH 2 HASH-TABLE) TWO)
+>>      HASH-TABLE)
+=>  #<HASH-TABLE EQL 0/120 32005763>
+
+

+

Affected By: None. +

+

See Also:

+

+write, print-unreadable-object

+

Notes:

+

+The rules for ``similarity'' imply that #A or #( syntax cannot be used for arrays of element type other than t. An implementation will have to use another syntax or signal an error of type print-not-readable.

+

+

+

The following X3J13 cleanup issues, not part of the specification, apply to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rig.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rig.htm new file mode 100644 index 00000000..17487fcb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_pr_rig.htm @@ -0,0 +1,46 @@ + + + +CLHS: Variable *PRINT-RIGHT-MARGIN* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *PRINT-RIGHT-MARGIN*

+

+

Value Type:

+

+a non-negative integer, or nil.

+

Initial Value:

+

+nil.

+

Description:

+

+If it is non-nil, it specifies the right margin (as integer number of ems) to use when the pretty printer is making layout decisions.

+If it is nil, the right margin is taken to be the maximum line length such that output can be displayed without wraparound or truncation. If this cannot be determined, an implementation-dependent value is used.

+

Examples: None. +

+

See Also: None. +

+

Notes:

+

+This measure is in units of ems in order to be compatible with implementation-defined variable-width fonts while still not requiring the language to provide support for fonts.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_bas.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_bas.htm new file mode 100644 index 00000000..bda4c3d2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_bas.htm @@ -0,0 +1,61 @@ + + + +CLHS: Variable *READ-BASE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *READ-BASE*

+

Value Type:

+

+a radix.

+

Initial Value:

+

+10.

+

Description:

+

+Controls the interpretation of tokens by read as being integers or ratios.

+The value of *read-base*, called the current input base, is the radix in which integers and ratios are to be read by the Lisp reader. The parsing of other numeric types (e.g., floats) is not affected by this option.

+The effect of *read-base* on the reading of any particular rational number can be locally overridden by explicit use of the #O, #X, #B, or #nR syntax or by a trailing decimal point.

+

Examples:

+

+

+ (dotimes (i 6)
+   (let ((*read-base* (+ 10. i)))
+     (let ((object (read-from-string "(\\DAD DAD |BEE| BEE 123. 123)")))
+       (print (list *read-base* object)))))
+>>  (10 (DAD DAD BEE BEE 123 123))
+>>  (11 (DAD DAD BEE BEE 123 146))
+>>  (12 (DAD DAD BEE BEE 123 171))
+>>  (13 (DAD DAD BEE BEE 123 198))
+>>  (14 (DAD 2701 BEE BEE 123 227))
+>>  (15 (DAD 3088 BEE 2699 123 258))
+=>  NIL
+
+

+

Affected By: None. +

+

See Also: None. +

+

Notes:

+

+Altering the input radix can be useful when reading data files in special formats.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_def.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_def.htm new file mode 100644 index 00000000..eca78a14 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_def.htm @@ -0,0 +1,56 @@ + + + +CLHS: Variable *READ-DEFAULT-FLOAT-FORMAT* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *READ-DEFAULT-FLOAT-FORMAT*

+

Value Type:

+

+one of the atomic type specifiers short-float, single-float, double-float, or long-float, or else some other type specifier defined by the implementation to be acceptable.

+

Initial Value:

+

+The symbol single-float.

+

Description:

+

+Controls the floating-point format that is to be used when reading a floating-point number that has no exponent marker or that has e or E for an exponent marker. Other exponent markers explicitly prescribe the floating-point format to be used.

+The printer uses *read-default-float-format* to guide the choice of exponent markers when printing floating-point numbers.

+

Examples:

+

+

+ (let ((*read-default-float-format* 'double-float))
+   (read-from-string "(1.0 1.0e0 1.0s0 1.0f0 1.0d0 1.0L0)"))
+=>  (1.0   1.0   1.0   1.0 1.0   1.0)   ;Implementation has float format F.
+=>  (1.0   1.0   1.0s0 1.0 1.0   1.0)   ;Implementation has float formats S and F.
+=>  (1.0d0 1.0d0 1.0   1.0 1.0d0 1.0d0) ;Implementation has float formats F and D.
+=>  (1.0d0 1.0d0 1.0s0 1.0 1.0d0 1.0d0) ;Implementation has float formats S, F, D.
+=>  (1.0d0 1.0d0 1.0   1.0 1.0d0 1.0L0) ;Implementation has float formats F, D, L.
+=>  (1.0d0 1.0d0 1.0s0 1.0 1.0d0 1.0L0) ;Implementation has formats S, F, D, L.
+
+

+

Affected By: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_eva.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_eva.htm new file mode 100644 index 00000000..cacce7e4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_eva.htm @@ -0,0 +1,48 @@ + + + +CLHS: Variable *READ-EVAL* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *READ-EVAL*

+

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+true.

+

Description:

+

+If it is true, the #. reader macro has its normal effect. Otherwise, that reader macro signals an error of type reader-error.

+

Examples: None. +

+

Affected By: None. +

+

See Also:

+

+*print-readably*

+

Notes:

+

+If *read-eval* is false and *print-readably* is true, any method for print-object that would output a reference to the #. reader macro either outputs something different or signals an error of type print-not-readable.

+

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_sup.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_sup.htm new file mode 100644 index 00000000..06e66e46 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rd_sup.htm @@ -0,0 +1,70 @@ + + + +CLHS: Variable *READ-SUPPRESS* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *READ-SUPPRESS*

+

Value Type:

+

+a generalized boolean.

+

Initial Value:

+

+false.

+

Description:

+

+This variable is intended primarily to support the operation of the read-time conditional notations #+ and #-. It is important for the reader macros which implement these notations to be able to skip over the printed representation of an expression despite the possibility that the syntax of the skipped expression may not be entirely valid for the current implementation, since #+ and #- exist in order to allow the same program to be shared among several Lisp implementations (including dialects other than Common Lisp) despite small incompatibilities of syntax.

+If it is false, the Lisp reader operates normally.

+

+If the value of *read-suppress* is true, read, read-preserving-whitespace, read-delimited-list, and read-from-string all return a primary value of nil when they complete successfully; however, they continue to parse the representation of an object in the normal way, in order to skip over the object, and continue to indicate end of file in the normal way. Except as noted below, any standardized reader macro[2] that is defined to read[2] a following object or token will do so, but not signal an error if the object read is not of an appropriate type or syntax. The standard syntax and its associated reader macros will not construct any new objects (e.g., when reading the representation of a symbol, no symbol will be constructed or interned).

+

+

Extended tokens

+All extended tokens are completely uninterpreted. Errors such as those that might otherwise be signaled due to detection of invalid potential numbers, invalid patterns of package markers, and invalid uses of the dot character are suppressed.

+

Dispatching macro characters (including sharpsign)

+Dispatching macro characters continue to parse an infix numerical argument, and invoke the dispatch function. The standardized sharpsign reader macros do not enforce any constraints on either the presence of or the value of the numerical argument.

+

+

#=

+The #= notation is totally ignored. It does not read a following object. It produces no object, but is treated as whitespace[2].

+

##

+The ## notation always produces nil.

+No matter what the value of *read-suppress*, parentheses still continue to delimit and construct lists; the #( notation continues to delimit vectors; and comments, strings, and the single-quote and backquote notations continue to be interpreted properly. Such situations as '), #<, #), and #<Space> continue to signal errors.

+

Examples:

+

+ +

+ (let ((*read-suppress* t))
+   (mapcar #'read-from-string
+           '("#(foo bar baz)" "#P(:type :lisp)" "#c1.2"
+             "#.(PRINT 'FOO)" "#3AHELLO" "#S(INTEGER)"
+             "#*ABC" "#\GARBAGE" "#RALPHA" "#3R444")))
+=>  (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)
+
+

+

Affected By: None. +

+

See Also:

+

+read, Section 2 (Syntax)

+

Notes:

+

+ Programmers and implementations that define additional macro characters are strongly encouraged to make them respect *read-suppress* just as standardized macro characters do. That is, when the value of *read-suppress* is true, they should ignore type errors when reading a following object and the functions that implement dispatching macro characters should tolerate nil as their infix parameter value even if a numeric value would ordinarily be required.

+

The following X3J13 cleanup issue, not part of the specification, applies to this section:

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rdtabl.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rdtabl.htm new file mode 100644 index 00000000..3da14711 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rdtabl.htm @@ -0,0 +1,57 @@ + + + +CLHS: Variable *READTABLE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *READTABLE*

+

Value Type:

+

+a readtable.

+

Initial Value:

+

+A readtable that conforms to the description of Common Lisp syntax in Section 2 (Syntax).

+

Description:

+

+The value of *readtable* is called the current readtable. It controls the parsing behavior of the Lisp reader, and can also influence the Lisp printer (e.g., see the function readtable-case).

+

Examples:

+

+

+ (readtablep *readtable*) =>  true
+ (setq zvar 123) =>  123
+ (set-syntax-from-char #\z #\' (setq table2 (copy-readtable))) =>  T
+ zvar =>  123
+ (setq *readtable* table2) =>  #<READTABLE>
+ zvar =>  VAR
+ (setq *readtable* (copy-readtable nil)) =>  #<READTABLE>
+ zvar =>  123
+
+

+

Affected By:

+

+compile-file, load

+

See Also:

+

+compile-file, load, readtable, Section 2.1.1.1 (The Current Readtable)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rnd_st.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rnd_st.htm new file mode 100644 index 00000000..31543391 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_rnd_st.htm @@ -0,0 +1,65 @@ + + + +CLHS: Variable *RANDOM-STATE* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *RANDOM-STATE*

+

Value Type:

+

+a random state.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The current random state, which is used, for example, by the function random when a random state is not explicitly supplied.

+

Examples:

+

+

+ (random-state-p *random-state*) =>  true
+ (setq snap-shot (make-random-state))
+ ;; The series from any given point is random,
+ ;; but if you backtrack to that point, you get the same series.
+ (list (loop for i from 1 to 10 collect (random))
+       (let ((*random-state* snap-shot))
+         (loop for i from 1 to 10 collect (random)))
+       (loop for i from 1 to 10 collect (random))
+       (let ((*random-state* snap-shot))
+         (loop for i from 1 to 10 collect (random))))
+=>  ((19 16 44 19 96 15 76 96 13 61)
+    (19 16 44 19 96 15 76 96 13 61)
+    (16 67 0 43 70 79 58 5 63 50)
+    (16 67 0 43 70 79 58 5 63 50))
+
+

+

Affected By:

+

+The implementation.

+random.

+

See Also:

+

+make-random-state, random, random-state

+

Notes:

+

+Binding *random-state* to a different random state object correctly saves and restores the old random state object.

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_short_.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_short_.htm new file mode 100644 index 00000000..358add62 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_short_.htm @@ -0,0 +1,42 @@ + + + +CLHS: Constant Variable SHORT-FLOAT-EPSILON... + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON

+

Constant Value:

+

+implementation-dependent.

+

Description:

+

+The value of each of the constants short-float-epsilon, single-float-epsilon, double-float-epsilon, and long-float-epsilon is the smallest positive float <EPSILON> of the given format, such that the following expression is true when evaluated:

+(not (= (float 1 <EPSILON>) (+ (float 1 <EPSILON>) <EPSILON>)))

+The value of each of the constants short-float-negative-epsilon, single-float-negative-epsilon, double-float-negative-epsilon, and long-float-negative-epsilon is the smallest positive float <EPSILON> of the given format, such that the following expression is true when evaluated:

+(not (= (float 1 <EPSILON>) (- (float 1 <EPSILON>) <EPSILON>)))

+

Examples: None. +

+

See Also: None. +

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_sl_sls.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_sl_sls.htm new file mode 100644 index 00000000..adb3f3e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_sl_sls.htm @@ -0,0 +1,53 @@ + + + +CLHS: Variable /, //, /// + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable /, //, ///

+

Value Type:

+

+a proper list.

+

Initial Value:

+

+implementation-dependent.

+

Description:

+

+The variables /, //, and /// are maintained by the Lisp read-eval-print loop to save the values of results that were printed at the end of the loop.

+The value of / is a list of the most recent values that were printed, the value of // is the previous value of /, and the value of /// is the previous value of //.

+The values of /, //, and /// are updated immediately prior to printing the return value of a top-level form by the Lisp read-eval-print loop. If the evaluation of such a form is aborted prior to its normal return, the values of /, //, and /// are not updated.

+

Examples:

+ +

+ (floor 22 7) =>  3, 1
+ (+ (* (car /) 7) (cadr /)) =>  22
+
+

+

Affected By:

+

+Lisp read-eval-print loop.

+

See Also:

+

+- (variable), + (variable), * (variable), Section 25.1.1 (Top level loop)

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_t.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_t.htm new file mode 100644 index 00000000..fb31d413 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_t.htm @@ -0,0 +1,52 @@ + + + +CLHS: Constant Variable T + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Constant Variable T

+

Constant Value:

+

+t.

+

Description:

+

+The boolean representing true, and the canonical generalized boolean representing true. Although any object other than nil is considered true, t is generally used when there is no special reason to prefer one such object over another.

+The symbol t is also sometimes used for other purposes as well. For example, as the name of a class, as a designator (e.g., a stream designator) or as a special symbol for some syntactic reason (e.g., in case and typecase to label the otherwise-clause).

+

Examples:

+

+

+ t =>  T 
+ (eq t 't) =>  true
+ (find-class 't) =>  #<CLASS T 610703333>
+ (case 'a (a 1) (t 2)) =>  1
+ (case 'b (a 1) (t 2)) =>  2
+ (prin1 'hello t)
+>>  HELLO
+=>  HELLO
+
+

+

See Also:

+

+nil

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_termin.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_termin.htm new file mode 100644 index 00000000..288885c2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Body/v_termin.htm @@ -0,0 +1,57 @@ + + + +CLHS: Variable *TERMINAL-IO* + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +Variable *TERMINAL-IO*

+

Value Type:

+

+a bidirectional stream.

+

Initial Value:

+

+implementation-dependent, but it must be an open stream that is not a generalized synonym stream to an I/O customization variables but that might be a generalized synonym stream to the value of some I/O customization variable.

+

Description:

+

+The value of *terminal-io*, called terminal I/O, is ordinarily a bidirectional stream that connects to the user's console. Typically, writing to this stream would cause the output to appear on a display screen, for example, and reading from the stream would accept input from a keyboard. It is intended that standard input functions such as read and read-char, when used with this stream, cause echoing of the input into the output side of the stream. The means by which this is accomplished are implementation-dependent.

+The effect of changing the value of *terminal-io*, either by binding or assignment, is implementation-defined.

+

Examples:

+

+

+ (progn (prin1 'foo) (prin1 'bar *terminal-io*))
+>>  FOOBAR
+=>  BAR
+ (with-output-to-string (*standard-output*)
+   (prin1 'foo) 
+   (prin1 'bar *terminal-io*))
+>>  BAR
+=>  "FOO"
+
+

+

Affected By: None. +

+

See Also:

+

+*debug-io*, *error-output*, *query-io*, *standard-input*, *standard-output*, *trace-output*

+

Notes: None. +

+

+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

+ + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssW.txt b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssW.txt new file mode 100644 index 00000000..930d02a0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssW.txt @@ -0,0 +1,652 @@ +&ENVIRONMENT-BINDING-ORDER +../Issues/iss001_w.htm +ACCESS-ERROR-NAME +../Issues/iss002_w.htm +ADJUST-ARRAY-DISPLACEMENT +../Issues/iss003_w.htm +ADJUST-ARRAY-FILL-POINTER +../Issues/iss004_w.htm +ADJUST-ARRAY-NOT-ADJUSTABLE +../Issues/iss005_w.htm +ALLOCATE-INSTANCE +../Issues/iss006_w.htm +ALLOW-LOCAL-INLINE +../Issues/iss007_w.htm +ALLOW-OTHER-KEYS-NIL +../Issues/iss008_w.htm +AREF-1D +../Issues/iss009_w.htm +ARGUMENT-MISMATCH-ERROR-AGAIN +../Issues/iss010_w.htm +ARGUMENT-MISMATCH-ERROR-MOON +../Issues/iss011_w.htm +ARGUMENT-MISMATCH-ERROR +../Issues/iss012_w.htm +ARGUMENTS-UNDERSPECIFIED +../Issues/iss013_w.htm +ARRAY-DIMENSION-LIMIT-IMPLICATIONS +../Issues/iss014_w.htm +ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS +../Issues/iss015_w.htm +ASSERT-ERROR-TYPE +../Issues/iss016_w.htm +ASSOC-RASSOC-IF-KEY +../Issues/iss017_w.htm +BOA-AUX-INITIALIZATION +../Issues/iss019_w.htm +BREAK-ON-WARNINGS-OBSOLETE +../Issues/iss020_w.htm +BROADCAST-STREAM-RETURN-VALUES +../Issues/iss021_w.htm +BUTLAST-NEGATIVE +../Issues/iss022_w.htm +CHANGE-CLASS-INITARGS +../Issues/iss023_w.htm +CHAR-NAME-CASE +../Issues/iss024_w.htm +CHARACTER-LOOSE-ENDS +../Issues/iss025_w.htm +CHARACTER-PROPOSAL +../Issues/iss026_w.htm +CHARACTER-VS-CHAR +../Issues/iss046_w.htm +CLASS-OBJECT-SPECIALIZER +../Issues/iss047_w.htm +CLOS-CONDITIONS-AGAIN +../Issues/iss048_w.htm +CLOS-CONDITIONS +../Issues/iss049_w.htm +CLOS-ERROR-CHECKING-ORDER +../Issues/iss050_w.htm +CLOS-MACRO-COMPILATION +../Issues/iss051_w.htm +CLOSE-CONSTRUCTED-STREAM +../Issues/iss052_w.htm +CLOSED-STREAM-OPERATIONS +../Issues/iss053_w.htm +COERCING-SETF-NAME-TO-FUNCTION +../Issues/iss054_w.htm +COLON-NUMBER +../Issues/iss055_w.htm +COMMON-FEATURES +../Issues/iss056_w.htm +COMMON-TYPE +../Issues/iss057_w.htm +COMPILE-ARGUMENT-PROBLEMS-AGAIN +../Issues/iss058_w.htm +COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS +../Issues/iss059_w.htm +COMPILE-FILE-OUTPUT-FILE-DEFAULTS +../Issues/iss060_w.htm +COMPILE-FILE-PACKAGE +../Issues/iss061_w.htm +COMPILE-FILE-PATHNAME-ARGUMENTS +../Issues/iss062_w.htm +COMPILE-FILE-SYMBOL-HANDLING +../Issues/iss063_w.htm +COMPILED-FUNCTION-REQUIREMENTS +../Issues/iss064_w.htm +COMPILER-DIAGNOSTICS +../Issues/iss065_w.htm +COMPILER-LET-CONFUSION +../Issues/iss066_w.htm +COMPILER-VERBOSITY +../Issues/iss067_w.htm +COMPILER-WARNING-STREAM +../Issues/iss068_w.htm +COMPLEX-ATAN-BRANCH-CUT +../Issues/iss069_w.htm +COMPLEX-ATANH-BOGUS-FORMULA +../Issues/iss070_w.htm +COMPLEX-RATIONAL-RESULT +../Issues/iss071_w.htm +COMPUTE-APPLICABLE-METHODS +../Issues/iss072_w.htm +CONCATENATE-SEQUENCE +../Issues/iss073_w.htm +CONDITION-ACCESSORS-SETFABLE +../Issues/iss074_w.htm +CONDITION-RESTARTS +../Issues/iss075_w.htm +CONDITION-SLOTS +../Issues/iss077_w.htm +CONS-TYPE-SPECIFIER +../Issues/iss078_w.htm +CONSTANT-CIRCULAR-COMPILATION +../Issues/iss079_w.htm +CONSTANT-COLLAPSING +../Issues/iss080_w.htm +CONSTANT-COMPILABLE-TYPES +../Issues/iss081_w.htm +CONSTANT-FUNCTION-COMPILATION +../Issues/iss082_w.htm +CONSTANT-MODIFICATION +../Issues/iss083_w.htm +CONSTANTP-DEFINITION +../Issues/iss084_w.htm +CONSTANTP-ENVIRONMENT +../Issues/iss085_w.htm +CONTAGION-ON-NUMERICAL-COMPARISONS +../Issues/iss086_w.htm +COPY-SYMBOL-COPY-PLIST +../Issues/iss087_w.htm +COPY-SYMBOL-PRINT-NAME +../Issues/iss088_w.htm +DATA-IO +../Issues/iss089_w.htm +DATA-TYPES-HIERARCHY-UNDERSPECIFIED +../Issues/iss090_w.htm +DEBUGGER-HOOK-VS-BREAK +../Issues/iss091_w.htm +DECLARATION-SCOPE +../Issues/iss092_w.htm +DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES +../Issues/iss093_w.htm +DECLARE-FUNCTION-AMBIGUITY +../Issues/iss094_w.htm +DECLARE-MACROS +../Issues/iss095_w.htm +DECLARE-TYPE-FREE +../Issues/iss096_w.htm +DECLS-AND-DOC +../Issues/iss097_w.htm +DECODE-UNIVERSAL-TIME-DAYLIGHT +../Issues/iss098_w.htm +DEFCONSTANT-SPECIAL +../Issues/iss099_w.htm +DEFGENERIC-DECLARE +../Issues/iss100_w.htm +DEFINE-COMPILER-MACRO +../Issues/iss101_w.htm +DEFINE-CONDITION-SYNTAX +../Issues/iss102_w.htm +DEFINE-METHOD-COMBINATION-BEHAVIOR +../Issues/iss103_w.htm +DEFINING-MACROS-NON-TOP-LEVEL +../Issues/iss104_w.htm +DEFMACRO-BLOCK-SCOPE +../Issues/iss105_w.htm +DEFMACRO-LAMBDA-LIST +../Issues/iss106_w.htm +DEFMETHOD-DECLARATION-SCOPE +../Issues/iss107_w.htm +DEFPACKAGE +../Issues/iss108_w.htm +DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE +../Issues/iss109_w.htm +DEFSTRUCT-CONSTRUCTOR-OPTIONS +../Issues/iss110_w.htm +DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES +../Issues/iss111_w.htm +DEFSTRUCT-COPIER-ARGUMENT-TYPE +../Issues/iss112_w.htm +DEFSTRUCT-COPIER +../Issues/iss113_w.htm +DEFSTRUCT-DEFAULT-VALUE-EVALUATION +../Issues/iss114_w.htm +DEFSTRUCT-INCLUDE-DEFTYPE +../Issues/iss115_w.htm +DEFSTRUCT-PRINT-FUNCTION-AGAIN +../Issues/iss116_w.htm +DEFSTRUCT-PRINT-FUNCTION-INHERITANCE +../Issues/iss117_w.htm +DEFSTRUCT-REDEFINITION +../Issues/iss118_w.htm +DEFSTRUCT-SLOTS-CONSTRAINTS-NAME +../Issues/iss119_w.htm +DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER +../Issues/iss120_w.htm +DEFTYPE-DESTRUCTURING +../Issues/iss121_w.htm +DEFTYPE-KEY +../Issues/iss122_w.htm +DEFVAR-DOCUMENTATION +../Issues/iss123_w.htm +DEFVAR-INIT-TIME +../Issues/iss124_w.htm +DEFVAR-INITIALIZATION +../Issues/iss125_w.htm +DEPRECATION-POSITION +../Issues/iss126_w.htm +DESCRIBE-INTERACTIVE +../Issues/iss127_w.htm +DESCRIBE-UNDERSPECIFIED +../Issues/iss128_w.htm +DESTRUCTIVE-OPERATIONS +../Issues/iss129_w.htm +DESTRUCTURING-BIND +../Issues/iss130_w.htm +DISASSEMBLE-SIDE-EFFECT +../Issues/iss131_w.htm +DISPLACED-ARRAY-PREDICATE +../Issues/iss132_w.htm +DO-SYMBOLS-BLOCK-SCOPE +../Issues/iss133_w.htm +DO-SYMBOLS-DUPLICATES +../Issues/iss134_w.htm +DOCUMENTATION-FUNCTION-BUGS +../Issues/iss135_w.htm +DOCUMENTATION-FUNCTION-TANGLED +../Issues/iss136_w.htm +DOTIMES-IGNORE +../Issues/iss137_w.htm +DOTTED-LIST-ARGUMENTS +../Issues/iss138_w.htm +DOTTED-MACRO-FORMS +../Issues/iss139_w.htm +DRIBBLE-TECHNIQUE +../Issues/iss140_w.htm +DYNAMIC-EXTENT-FUNCTION +../Issues/iss141_w.htm +DYNAMIC-EXTENT +../Issues/iss142_w.htm +EQUAL-STRUCTURE +../Issues/iss143_w.htm +ERROR-TERMINOLOGY-WARNING +../Issues/iss144_w.htm +EVAL-OTHER +../Issues/iss145_w.htm +EVAL-TOP-LEVEL +../Issues/iss146_w.htm +EVAL-WHEN-NON-TOP-LEVEL +../Issues/iss147_w.htm +EVAL-WHEN-OBSOLETE-KEYWORDS +../Issues/iss148_w.htm +EVALHOOK-STEP-CONFUSION +../Issues/iss149_w.htm +EXIT-EXTENT-AND-CONDITION-SYSTEM +../Issues/iss151_w.htm +EXIT-EXTENT +../Issues/iss152_w.htm +EXPT-RATIO +../Issues/iss153_w.htm +EXTENSIONS-POSITION +../Issues/iss154_w.htm +EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION +../Issues/iss155_w.htm +EXTRA-RETURN-VALUES +../Issues/iss156_w.htm +FILE-OPEN-ERROR +../Issues/iss157_w.htm +FIXNUM-NON-PORTABLE +../Issues/iss158_w.htm +FLET-DECLARATIONS +../Issues/iss159_w.htm +FLET-IMPLICIT-BLOCK +../Issues/iss161_w.htm +FLOAT-UNDERFLOW +../Issues/iss162_w.htm +FLOATING-POINT-CONDITION-NAMES +../Issues/iss163_w.htm +FORMAT-ATSIGN-COLON +../Issues/iss164_w.htm +FORMAT-COLON-UPARROW-SCOPE +../Issues/iss165_w.htm +FORMAT-COMMA-INTERVAL +../Issues/iss166_w.htm +FORMAT-E-EXPONENT-SIGN +../Issues/iss167_w.htm +FORMAT-OP-C +../Issues/iss168_w.htm +FORMAT-PRETTY-PRINT +../Issues/iss169_w.htm +FORMAT-STRING-ARGUMENTS +../Issues/iss170_w.htm +FUNCTION-CALL-EVALUATION-ORDER +../Issues/iss171_w.htm +FUNCTION-COMPOSITION +../Issues/iss172_w.htm +FUNCTION-DEFINITION +../Issues/iss173_w.htm +FUNCTION-NAME +../Issues/iss174_w.htm +FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS +../Issues/iss176_w.htm +FUNCTION-TYPE-KEY-NAME +../Issues/iss177_w.htm +FUNCTION-TYPE-REST-LIST-ELEMENT +../Issues/iss178_w.htm +FUNCTION-TYPE +../Issues/iss175_w.htm +GENERALIZE-PRETTY-PRINTER +../Issues/iss180_w.htm +GENERIC-FLET-POORLY-DESIGNED +../Issues/iss181_w.htm +GENSYM-NAME-STICKINESS +../Issues/iss182_w.htm +GENTEMP-BAD-IDEA +../Issues/iss183_w.htm +GET-MACRO-CHARACTER-READTABLE +../Issues/iss184_w.htm +GET-SETF-METHOD-ENVIRONMENT +../Issues/iss185_w.htm +HASH-TABLE-ACCESS +../Issues/iss186_w.htm +HASH-TABLE-KEY-MODIFICATION +../Issues/iss187_w.htm +HASH-TABLE-PACKAGE-GENERATORS +../Issues/iss188_w.htm +HASH-TABLE-REHASH-SIZE-INTEGER +../Issues/iss189_w.htm +HASH-TABLE-SIZE +../Issues/iss190_w.htm +HASH-TABLE-TESTS +../Issues/iss191_w.htm +IEEE-ATAN-BRANCH-CUT +../Issues/iss192_w.htm +IGNORE-USE-TERMINOLOGY +../Issues/iss193_w.htm +IMPORT-SETF-SYMBOL-PACKAGE +../Issues/iss194_w.htm +IN-PACKAGE-FUNCTIONALITY +../Issues/iss195_w.htm +IN-SYNTAX +../Issues/iss196_w.htm +INITIALIZATION-FUNCTION-KEYWORD-CHECKING +../Issues/iss197_w.htm +ISO-COMPATIBILITY +../Issues/iss198_w.htm +JUN90-TRIVIAL-ISSUES +../Issues/iss199_w.htm +KEYWORD-ARGUMENT-NAME-PACKAGE +../Issues/iss208_w.htm +LAST-N +../Issues/iss209_w.htm +LCM-NO-ARGUMENTS +../Issues/iss210_w.htm +LEXICAL-CONSTRUCT-GLOBAL-DEFINITION +../Issues/iss211_w.htm +LISP-PACKAGE-NAME +../Issues/iss212_w.htm +LISP-SYMBOL-REDEFINITION-AGAIN +../Issues/iss213_w.htm +LISP-SYMBOL-REDEFINITION +../Issues/iss214_w.htm +LOAD-OBJECTS +../Issues/iss215_w.htm +LOAD-TIME-EVAL +../Issues/iss216_w.htm +LOAD-TRUENAME +../Issues/iss218_w.htm +LOCALLY-TOP-LEVEL +../Issues/iss219_w.htm +LOOP-AND-DISCREPANCY +../Issues/iss220_w.htm +LOOP-FOR-AS-ON-TYPO +../Issues/iss221_w.htm +LOOP-INITFORM-ENVIRONMENT +../Issues/iss222_w.htm +LOOP-MISCELLANEOUS-REPAIRS +../Issues/iss223_w.htm +LOOP-NAMED-BLOCK-NIL +../Issues/iss224_w.htm +LOOP-PRESENT-SYMBOLS-TYPO +../Issues/iss225_w.htm +LOOP-SYNTAX-OVERHAUL +../Issues/iss226_w.htm +MACRO-AS-FUNCTION +../Issues/iss227_w.htm +MACRO-DECLARATIONS +../Issues/iss228_w.htm +MACRO-ENVIRONMENT-EXTENT +../Issues/iss229_w.htm +MACRO-FUNCTION-ENVIRONMENT +../Issues/iss230_w.htm +MACRO-SUBFORMS-TOP-LEVEL-P +../Issues/iss232_w.htm +MACROEXPAND-HOOK-DEFAULT +../Issues/iss233_w.htm +MACROEXPAND-HOOK-INITIAL-VALUE +../Issues/iss234_w.htm +MACROEXPAND-RETURN-VALUE +../Issues/iss235_w.htm +MAKE-LOAD-FORM-CONFUSION +../Issues/iss236_w.htm +MAKE-LOAD-FORM-SAVING-SLOTS +../Issues/iss237_w.htm +MAKE-PACKAGE-USE-DEFAULT +../Issues/iss238_w.htm +MAP-INTO +../Issues/iss239_w.htm +MAPPING-DESTRUCTIVE-INTERACTION +../Issues/iss240_w.htm +METACLASS-OF-SYSTEM-CLASS +../Issues/iss241_w.htm +METHOD-COMBINATION-ARGUMENTS +../Issues/iss242_w.htm +METHOD-INITFORM +../Issues/iss243_w.htm +MUFFLE-WARNING-CONDITION-ARGUMENT +../Issues/iss244_w.htm +MULTIPLE-VALUE-SETQ-ORDER +../Issues/iss245_w.htm +MULTIPLE-VALUES-LIMIT-ON-VARIABLES +../Issues/iss246_w.htm +NINTERSECTION-DESTRUCTION +../Issues/iss247_w.htm +NOT-AND-NULL-RETURN-VALUE +../Issues/iss249_w.htm +NTH-VALUE +../Issues/iss250_w.htm +OPTIMIZE-DEBUG-INFO +../Issues/iss251_w.htm +PACKAGE-CLUTTER +../Issues/iss252_w.htm +PACKAGE-DELETION +../Issues/iss253_w.htm +PACKAGE-FUNCTION-CONSISTENCY +../Issues/iss254_w.htm +PARSE-ERROR-STREAM +../Issues/iss255_w.htm +PATHNAME-COMPONENT-CASE +../Issues/iss256_w.htm +PATHNAME-COMPONENT-VALUE +../Issues/iss257_w.htm +PATHNAME-HOST-PARSING +../Issues/iss258_w.htm +PATHNAME-LOGICAL +../Issues/iss259_w.htm +PATHNAME-PRINT-READ +../Issues/iss260_w.htm +PATHNAME-STREAM +../Issues/iss261_w.htm +PATHNAME-SUBDIRECTORY-LIST +../Issues/iss263_w.htm +PATHNAME-SYMBOL +../Issues/iss264_w.htm +PATHNAME-SYNTAX-ERROR-TIME +../Issues/iss265_w.htm +PATHNAME-UNSPECIFIC-COMPONENT +../Issues/iss266_w.htm +PATHNAME-WILD +../Issues/iss267_w.htm +PEEK-CHAR-READ-CHAR-ECHO +../Issues/iss268_w.htm +PLIST-DUPLICATES +../Issues/iss269_w.htm +PRETTY-PRINT-INTERFACE +../Issues/iss270_w.htm +PRINC-READABLY +../Issues/iss271_w.htm +PRINT-CASE-BEHAVIOR +../Issues/iss272_w.htm +PRINT-CASE-PRINT-ESCAPE-INTERACTION +../Issues/iss273_w.htm +PRINT-CIRCLE-SHARED +../Issues/iss274_w.htm +PRINT-CIRCLE-STRUCTURE +../Issues/iss275_w.htm +PRINT-READABLY-BEHAVIOR +../Issues/iss276_w.htm +PRINTER-WHITESPACE +../Issues/iss277_w.htm +PROCLAIM-ETC-IN-COMPILE-FILE +../Issues/iss278_w.htm +PUSH-EVALUATION-ORDER +../Issues/iss279_w.htm +PUSHNEW-STORE-REQUIRED +../Issues/iss281_w.htm +QUOTE-SEMANTICS +../Issues/iss282_w.htm +RANGE-OF-COUNT-KEYWORD +../Issues/iss283_w.htm +RANGE-OF-START-AND-END-PARAMETERS +../Issues/iss284_w.htm +READ-AND-WRITE-BYTES +../Issues/iss285_w.htm +READ-CASE-SENSITIVITY +../Issues/iss286_w.htm +READ-MODIFY-WRITE-EVALUATION-ORDER +../Issues/iss287_w.htm +READ-SUPPRESS-CONFUSING +../Issues/iss288_w.htm +READER-ERROR +../Issues/iss289_w.htm +REAL-NUMBER-TYPE +../Issues/iss290_w.htm +RECURSIVE-DEFTYPE +../Issues/iss291_w.htm +REDUCE-ARGUMENT-EXTRACTION +../Issues/iss292_w.htm +REMF-DESTRUCTION-UNSPECIFIED +../Issues/iss293_w.htm +REQUIRE-PATHNAME-DEFAULTS-AGAIN +../Issues/iss294_w.htm +REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN +../Issues/iss295_w.htm +REQUIRE-PATHNAME-DEFAULTS +../Issues/iss296_w.htm +REST-LIST-ALLOCATION +../Issues/iss297_w.htm +RESULT-LISTS-SHARED +../Issues/iss298_w.htm +RETURN-VALUES-UNSPECIFIED +../Issues/iss299_w.htm +ROOM-DEFAULT-ARGUMENT +../Issues/iss300_w.htm +SELF-MODIFYING-CODE +../Issues/iss301_w.htm +SEQUENCE-TYPE-LENGTH +../Issues/iss302_w.htm +SETF-APPLY-EXPANSION +../Issues/iss303_w.htm +SETF-FIND-CLASS +../Issues/iss304_w.htm +SETF-FUNCTIONS-AGAIN +../Issues/iss305_w.htm +SETF-GET-DEFAULT +../Issues/iss306_w.htm +SETF-MACRO-EXPANSION +../Issues/iss307_w.htm +SETF-METHOD-VS-SETF-METHOD +../Issues/iss308_w.htm +SETF-MULTIPLE-STORE-VARIABLES +../Issues/iss309_w.htm +SETF-OF-APPLY +../Issues/iss310_w.htm +SETF-OF-VALUES +../Issues/iss311_w.htm +SETF-SUB-METHODS +../Issues/iss312_w.htm +SHADOW-ALREADY-PRESENT +../Issues/iss313_w.htm +SHARP-COMMA-CONFUSION +../Issues/iss315_w.htm +SHARP-O-FOOBAR +../Issues/iss316_w.htm +SHARP-STAR-DELIMITER +../Issues/iss317_w.htm +SHARPSIGN-PLUS-MINUS-PACKAGE +../Issues/iss318_w.htm +SLOT-MISSING-VALUES +../Issues/iss319_w.htm +SLOT-VALUE-METACLASSES +../Issues/iss320_w.htm +SPECIAL-FORM-P-MISNOMER +../Issues/iss321_w.htm +SPECIAL-TYPE-SHADOWING +../Issues/iss322_w.htm +STANDARD-INPUT-INITIAL-BINDING +../Issues/iss323_w.htm +STANDARD-REPERTOIRE-GRATUITOUS +../Issues/iss324_w.htm +STEP-ENVIRONMENT +../Issues/iss325_w.htm +STEP-MINIMAL +../Issues/iss326_w.htm +STREAM-ACCESS +../Issues/iss327_w.htm +STREAM-CAPABILITIES +../Issues/iss328_w.htm +STRING-COERCION +../Issues/iss329_w.htm +STRING-OUTPUT-STREAM-BASHING +../Issues/iss330_w.htm +STRUCTURE-READ-PRINT-SYNTAX +../Issues/iss331_w.htm +SUBSEQ-OUT-OF-BOUNDS +../Issues/iss332_w.htm +SUBSETTING-POSITION +../Issues/iss333_w.htm +SUBTYPEP-ENVIRONMENT +../Issues/iss334_w.htm +SUBTYPEP-TOO-VAGUE +../Issues/iss335_w.htm +SXHASH-DEFINITION +../Issues/iss336_w.htm +SYMBOL-MACROLET-DECLARE +../Issues/iss337_w.htm +SYMBOL-MACROLET-SEMANTICS +../Issues/iss338_w.htm +SYMBOL-MACROLET-TYPE-DECLARATION +../Issues/iss339_w.htm +SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS +../Issues/iss340_w.htm +SYMBOL-PRINT-ESCAPE-BEHAVIOR +../Issues/iss341_w.htm +SYNTACTIC-ENVIRONMENT-ACCESS +../Issues/iss342_w.htm +TAGBODY-TAG-EXPANSION +../Issues/iss343_w.htm +TAILP-NIL +../Issues/iss344_w.htm +TEST-NOT-IF-NOT +../Issues/iss345_w.htm +THE-AMBIGUITY +../Issues/iss346_w.htm +THE-VALUES +../Issues/iss347_w.htm +TIME-ZONE-NON-INTEGER +../Issues/iss348_w.htm +TYPE-DECLARATION-ABBREVIATION +../Issues/iss349_w.htm +TYPE-OF-AND-PREDEFINED-CLASSES +../Issues/iss350_w.htm +TYPE-OF-UNDERCONSTRAINED +../Issues/iss352_w.htm +TYPE-SPECIFIER-ABBREVIATION +../Issues/iss353_w.htm +UNDEFINED-VARIABLES-AND-FUNCTIONS +../Issues/iss354_w.htm +UNINITIALIZED-ELEMENTS +../Issues/iss355_w.htm +UNREAD-CHAR-AFTER-PEEK-CHAR +../Issues/iss356_w.htm +UNSOLICITED-MESSAGES +../Issues/iss357_w.htm +VARIABLE-LIST-ASYMMETRY +../Issues/iss358_w.htm +WITH-ADDED-METHODS +../Issues/iss359_w.htm +WITH-COMPILATION-UNIT +../Issues/iss360_w.htm +WITH-OPEN-FILE-DOES-NOT-EXIST +../Issues/iss361_w.htm +WITH-OPEN-FILE-SETQ +../Issues/iss362_w.htm +WITH-OPEN-FILE-STREAM-EXTENT +../Issues/iss363_w.htm +WITH-OUTPUT-TO-STRING-APPEND-STYLE +../Issues/iss364_w.htm +WITH-STANDARD-IO-SYNTAX-READTABLE +../Issues/iss365_w.htm diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssX.txt b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssX.txt new file mode 100644 index 00000000..3c533d5a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_IssX.txt @@ -0,0 +1,730 @@ +&ENVIRONMENT-BINDING-ORDER:FIRST +../Issues/iss001.htm +ACCESS-ERROR-NAME +../Issues/iss002.htm +ADJUST-ARRAY-DISPLACEMENT +../Issues/iss003.htm +ADJUST-ARRAY-FILL-POINTER +../Issues/iss004.htm +ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY +../Issues/iss005.htm +ALLOCATE-INSTANCE:ADD +../Issues/iss006.htm +ALLOW-LOCAL-INLINE:INLINE-NOTINLINE +../Issues/iss007.htm +ALLOW-OTHER-KEYS-NIL:PERMIT +../Issues/iss008.htm +AREF-1D +../Issues/iss009.htm +ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT +../Issues/iss010.htm +ARGUMENT-MISMATCH-ERROR-MOON:FIX +../Issues/iss011.htm +ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS +../Issues/iss012.htm +ARGUMENTS-UNDERSPECIFIED:SPECIFY +../Issues/iss013.htm +ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM +../Issues/iss014.htm +ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING +../Issues/iss015.htm +ASSERT-ERROR-TYPE:ERROR +../Issues/iss016.htm +ASSOC-RASSOC-IF-KEY +../Issues/iss017.htm +ASSOC-RASSOC-IF-KEY:YES +../Issues/iss018.htm +BOA-AUX-INITIALIZATION:ERROR-ON-READ +../Issues/iss019.htm +BREAK-ON-WARNINGS-OBSOLETE:REMOVE +../Issues/iss020.htm +BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY +../Issues/iss021.htm +BUTLAST-NEGATIVE:SHOULD-SIGNAL +../Issues/iss022.htm +CHANGE-CLASS-INITARGS:PERMIT +../Issues/iss023.htm +CHAR-NAME-CASE:X3J13-MAR-91 +../Issues/iss024.htm +CHARACTER-LOOSE-ENDS:FIX +../Issues/iss025.htm +CHARACTER-PROPOSAL:2 +../Issues/iss026.htm +CHARACTER-PROPOSAL:2-1-1 +../Issues/iss027.htm +CHARACTER-PROPOSAL:2-1-2 +../Issues/iss028.htm +CHARACTER-PROPOSAL:2-2-1 +../Issues/iss029.htm +CHARACTER-PROPOSAL:2-3-1 +../Issues/iss030.htm +CHARACTER-PROPOSAL:2-3-2 +../Issues/iss031.htm +CHARACTER-PROPOSAL:2-3-3 +../Issues/iss032.htm +CHARACTER-PROPOSAL:2-3-4 +../Issues/iss033.htm +CHARACTER-PROPOSAL:2-3-5 +../Issues/iss034.htm +CHARACTER-PROPOSAL:2-3-6 +../Issues/iss035.htm +CHARACTER-PROPOSAL:2-4-1 +../Issues/iss036.htm +CHARACTER-PROPOSAL:2-4-2 +../Issues/iss037.htm +CHARACTER-PROPOSAL:2-4-3 +../Issues/iss038.htm +CHARACTER-PROPOSAL:2-5-2 +../Issues/iss039.htm +CHARACTER-PROPOSAL:2-5-6 +../Issues/iss040.htm +CHARACTER-PROPOSAL:2-5-7 +../Issues/iss041.htm +CHARACTER-PROPOSAL:2-6-1 +../Issues/iss042.htm +CHARACTER-PROPOSAL:2-6-2 +../Issues/iss043.htm +CHARACTER-PROPOSAL:2-6-3 +../Issues/iss044.htm +CHARACTER-PROPOSAL:2-6-5 +../Issues/iss045.htm +CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT +../Issues/iss046.htm +CLASS-OBJECT-SPECIALIZER:AFFIRM +../Issues/iss047.htm +CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET +../Issues/iss048.htm +CLOS-CONDITIONS:INTEGRATE +../Issues/iss049.htm +CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST +../Issues/iss050.htm +CLOS-MACRO-COMPILATION:MINIMAL +../Issues/iss051.htm +CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY +../Issues/iss052.htm +CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY +../Issues/iss053.htm +COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES +../Issues/iss054.htm +COLON-NUMBER +../Issues/iss055.htm +COMMON-FEATURES:SPECIFY +../Issues/iss056.htm +COMMON-TYPE:REMOVE +../Issues/iss057.htm +COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX +../Issues/iss058.htm +COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY +../Issues/iss059.htm +COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE +../Issues/iss060.htm +COMPILE-FILE-PACKAGE +../Issues/iss061.htm +COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT +../Issues/iss062.htm +COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY +../Issues/iss063.htm +COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN +../Issues/iss064.htm +COMPILER-DIAGNOSTICS:USE-HANDLER +../Issues/iss065.htm +COMPILER-LET-CONFUSION:ELIMINATE +../Issues/iss066.htm +COMPILER-VERBOSITY:LIKE-LOAD +../Issues/iss067.htm +COMPILER-WARNING-STREAM +../Issues/iss068.htm +COMPLEX-ATAN-BRANCH-CUT:TWEAK +../Issues/iss069.htm +COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE +../Issues/iss070.htm +COMPLEX-RATIONAL-RESULT:EXTEND +../Issues/iss071.htm +COMPUTE-APPLICABLE-METHODS:GENERIC +../Issues/iss072.htm +CONCATENATE-SEQUENCE:SIGNAL-ERROR +../Issues/iss073.htm +CONDITION-ACCESSORS-SETFABLE:NO +../Issues/iss074.htm +CONDITION-RESTARTS:BUGGY +../Issues/iss075.htm +CONDITION-RESTARTS:PERMIT-ASSOCIATION +../Issues/iss076.htm +CONDITION-SLOTS:HIDDEN +../Issues/iss077.htm +CONS-TYPE-SPECIFIER:ADD +../Issues/iss078.htm +CONSTANT-CIRCULAR-COMPILATION:YES +../Issues/iss079.htm +CONSTANT-COLLAPSING:GENERALIZE +../Issues/iss080.htm +CONSTANT-COMPILABLE-TYPES:SPECIFY +../Issues/iss081.htm +CONSTANT-FUNCTION-COMPILATION:NO +../Issues/iss082.htm +CONSTANT-MODIFICATION:DISALLOW +../Issues/iss083.htm +CONSTANTP-DEFINITION:INTENTIONAL +../Issues/iss084.htm +CONSTANTP-ENVIRONMENT:ADD-ARG +../Issues/iss085.htm +CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE +../Issues/iss086.htm +COPY-SYMBOL-COPY-PLIST:COPY-LIST +../Issues/iss087.htm +COPY-SYMBOL-PRINT-NAME:EQUAL +../Issues/iss088.htm +DATA-IO:ADD-SUPPORT +../Issues/iss089.htm +DATA-TYPES-HIERARCHY-UNDERSPECIFIED +../Issues/iss090.htm +DEBUGGER-HOOK-VS-BREAK:CLARIFY +../Issues/iss091.htm +DECLARATION-SCOPE:NO-HOISTING +../Issues/iss092.htm +DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE +../Issues/iss093.htm +DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION +../Issues/iss094.htm +DECLARE-MACROS:FLUSH +../Issues/iss095.htm +DECLARE-TYPE-FREE:LEXICAL +../Issues/iss096.htm +DECLS-AND-DOC +../Issues/iss097.htm +DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE +../Issues/iss098.htm +DEFCONSTANT-SPECIAL:NO +../Issues/iss099.htm +DEFGENERIC-DECLARE:ALLOW-MULTIPLE +../Issues/iss100.htm +DEFINE-COMPILER-MACRO:X3J13-NOV89 +../Issues/iss101.htm +DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY +../Issues/iss102.htm +DEFINE-METHOD-COMBINATION-BEHAVIOR:CLARIFY +../Issues/iss103.htm +DEFINING-MACROS-NON-TOP-LEVEL:ALLOW +../Issues/iss104.htm +DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS +../Issues/iss105.htm +DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION +../Issues/iss106.htm +DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS +../Issues/iss107.htm +DEFPACKAGE:ADDITION +../Issues/iss108.htm +DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY +../Issues/iss109.htm +DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT +../Issues/iss110.htm +DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND +../Issues/iss111.htm +DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT +../Issues/iss112.htm +DEFSTRUCT-COPIER:ARGUMENT-TYPE +../Issues/iss113.htm +DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED +../Issues/iss114.htm +DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED +../Issues/iss115.htm +DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93 +../Issues/iss116.htm +DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES +../Issues/iss117.htm +DEFSTRUCT-REDEFINITION:ERROR +../Issues/iss118.htm +DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR +../Issues/iss119.htm +DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER +../Issues/iss120.htm +DEFTYPE-DESTRUCTURING:YES +../Issues/iss121.htm +DEFTYPE-KEY:ALLOW +../Issues/iss122.htm +DEFVAR-DOCUMENTATION:UNEVALUATED +../Issues/iss123.htm +DEFVAR-INIT-TIME:NOT-DELAYED +../Issues/iss124.htm +DEFVAR-INITIALIZATION:CONSERVATIVE +../Issues/iss125.htm +DEPRECATION-POSITION:LIMITED +../Issues/iss126.htm +DESCRIBE-INTERACTIVE:NO +../Issues/iss127.htm +DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT +../Issues/iss128.htm +DESTRUCTIVE-OPERATIONS:SPECIFY +../Issues/iss129.htm +DESTRUCTURING-BIND:NEW-MACRO +../Issues/iss130.htm +DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL +../Issues/iss131.htm +DISPLACED-ARRAY-PREDICATE:ADD +../Issues/iss132.htm +DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM +../Issues/iss133.htm +DO-SYMBOLS-DUPLICATES +../Issues/iss134.htm +DOCUMENTATION-FUNCTION-BUGS:FIX +../Issues/iss135.htm +DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT +../Issues/iss136.htm +DOTIMES-IGNORE:X3J13-MAR91 +../Issues/iss137.htm +DOTTED-LIST-ARGUMENTS:CLARIFY +../Issues/iss138.htm +DOTTED-MACRO-FORMS:ALLOW +../Issues/iss139.htm +DRIBBLE-TECHNIQUE +../Issues/iss140.htm +DYNAMIC-EXTENT-FUNCTION:EXTEND +../Issues/iss141.htm +DYNAMIC-EXTENT:NEW-DECLARATION +../Issues/iss142.htm +EQUAL-STRUCTURE:MAYBE-STATUS-QUO +../Issues/iss143.htm +ERROR-TERMINOLOGY-WARNING:MIGHT +../Issues/iss144.htm +EVAL-OTHER:SELF-EVALUATE +../Issues/iss145.htm +EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE +../Issues/iss146.htm +EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS +../Issues/iss147.htm +EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993 +../Issues/iss148.htm +EVALHOOK-STEP-CONFUSION:FIX +../Issues/iss149.htm +EVALHOOK-STEP-CONFUSION:X3J13-NOV-89 +../Issues/iss150.htm +EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS +../Issues/iss151.htm +EXIT-EXTENT:MINIMAL +../Issues/iss152.htm +EXPT-RATIO:P.211 +../Issues/iss153.htm +EXTENSIONS-POSITION:DOCUMENTATION +../Issues/iss154.htm +EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM +../Issues/iss155.htm +EXTRA-RETURN-VALUES:NO +../Issues/iss156.htm +FILE-OPEN-ERROR:SIGNAL-FILE-ERROR +../Issues/iss157.htm +FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION +../Issues/iss158.htm +FLET-DECLARATIONS +../Issues/iss159.htm +FLET-DECLARATIONS:ALLOW +../Issues/iss160.htm +FLET-IMPLICIT-BLOCK:YES +../Issues/iss161.htm +FLOAT-UNDERFLOW:ADD-VARIABLES +../Issues/iss162.htm +FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89 +../Issues/iss163.htm +FORMAT-ATSIGN-COLON +../Issues/iss164.htm +FORMAT-COLON-UPARROW-SCOPE +../Issues/iss165.htm +FORMAT-COMMA-INTERVAL +../Issues/iss166.htm +FORMAT-E-EXPONENT-SIGN:FORCE-SIGN +../Issues/iss167.htm +FORMAT-OP-C +../Issues/iss168.htm +FORMAT-PRETTY-PRINT:YES +../Issues/iss169.htm +FORMAT-STRING-ARGUMENTS:SPECIFY +../Issues/iss170.htm +FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED +../Issues/iss171.htm +FUNCTION-COMPOSITION:JAN89-X3J13 +../Issues/iss172.htm +FUNCTION-DEFINITION:JAN89-X3J13 +../Issues/iss173.htm +FUNCTION-NAME:LARGE +../Issues/iss174.htm +FUNCTION-TYPE +../Issues/iss175.htm +FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE +../Issues/iss176.htm +FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD +../Issues/iss177.htm +FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE +../Issues/iss178.htm +FUNCTION-TYPE:X3J13-MARCH-88 +../Issues/iss179.htm +GENERALIZE-PRETTY-PRINTER:UNIFY +../Issues/iss180.htm +GENERIC-FLET-POORLY-DESIGNED:DELETE +../Issues/iss181.htm +GENSYM-NAME-STICKINESS:LIKE-TEFLON +../Issues/iss182.htm +GENTEMP-BAD-IDEA:DEPRECATE +../Issues/iss183.htm +GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD +../Issues/iss184.htm +GET-SETF-METHOD-ENVIRONMENT:ADD-ARG +../Issues/iss185.htm +HASH-TABLE-ACCESS:X3J13-MAR-89 +../Issues/iss186.htm +HASH-TABLE-KEY-MODIFICATION:SPECIFY +../Issues/iss187.htm +HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER +../Issues/iss188.htm +HASH-TABLE-REHASH-SIZE-INTEGER +../Issues/iss189.htm +HASH-TABLE-SIZE:INTENDED-ENTRIES +../Issues/iss190.htm +HASH-TABLE-TESTS:ADD-EQUALP +../Issues/iss191.htm +IEEE-ATAN-BRANCH-CUT:SPLIT +../Issues/iss192.htm +IGNORE-USE-TERMINOLOGY:VALUE-ONLY +../Issues/iss193.htm +IMPORT-SETF-SYMBOL-PACKAGE +../Issues/iss194.htm +IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13 +../Issues/iss195.htm +IN-SYNTAX:MINIMAL +../Issues/iss196.htm +INITIALIZATION-FUNCTION-KEYWORD-CHECKING +../Issues/iss197.htm +ISO-COMPATIBILITY:ADD-SUBSTRATE +../Issues/iss198.htm +JUN90-TRIVIAL-ISSUES:11 +../Issues/iss199.htm +JUN90-TRIVIAL-ISSUES:14 +../Issues/iss200.htm +JUN90-TRIVIAL-ISSUES:24 +../Issues/iss201.htm +JUN90-TRIVIAL-ISSUES:25 +../Issues/iss202.htm +JUN90-TRIVIAL-ISSUES:27 +../Issues/iss203.htm +JUN90-TRIVIAL-ISSUES:3 +../Issues/iss204.htm +JUN90-TRIVIAL-ISSUES:4 +../Issues/iss205.htm +JUN90-TRIVIAL-ISSUES:5 +../Issues/iss206.htm +JUN90-TRIVIAL-ISSUES:9 +../Issues/iss207.htm +KEYWORD-ARGUMENT-NAME-PACKAGE:ANY +../Issues/iss208.htm +LAST-N +../Issues/iss209.htm +LCM-NO-ARGUMENTS:1 +../Issues/iss210.htm +LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED +../Issues/iss211.htm +LISP-PACKAGE-NAME:COMMON-LISP +../Issues/iss212.htm +LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES +../Issues/iss213.htm +LISP-SYMBOL-REDEFINITION:MAR89-X3J13 +../Issues/iss214.htm +LOAD-OBJECTS:MAKE-LOAD-FORM +../Issues/iss215.htm +LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM +../Issues/iss216.htm +LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM +../Issues/iss217.htm +LOAD-TRUENAME:NEW-PATHNAME-VARIABLES +../Issues/iss218.htm +LOCALLY-TOP-LEVEL:SPECIAL-FORM +../Issues/iss219.htm +LOOP-AND-DISCREPANCY:NO-REITERATION +../Issues/iss220.htm +LOOP-FOR-AS-ON-TYPO:FIX-TYPO +../Issues/iss221.htm +LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE +../Issues/iss222.htm +LOOP-MISCELLANEOUS-REPAIRS:FIX +../Issues/iss223.htm +LOOP-NAMED-BLOCK-NIL:OVERRIDE +../Issues/iss224.htm +LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS +../Issues/iss225.htm +LOOP-SYNTAX-OVERHAUL:REPAIR +../Issues/iss226.htm +MACRO-AS-FUNCTION:DISALLOW +../Issues/iss227.htm +MACRO-DECLARATIONS:MAKE-EXPLICIT +../Issues/iss228.htm +MACRO-ENVIRONMENT-EXTENT:DYNAMIC +../Issues/iss229.htm +MACRO-FUNCTION-ENVIRONMENT +../Issues/iss230.htm +MACRO-FUNCTION-ENVIRONMENT:YES +../Issues/iss231.htm +MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS +../Issues/iss232.htm +MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE +../Issues/iss233.htm +MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT +../Issues/iss234.htm +MACROEXPAND-RETURN-VALUE:TRUE +../Issues/iss235.htm +MAKE-LOAD-FORM-CONFUSION:REWRITE +../Issues/iss236.htm +MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS +../Issues/iss237.htm +MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT +../Issues/iss238.htm +MAP-INTO:ADD-FUNCTION +../Issues/iss239.htm +MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE +../Issues/iss240.htm +METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED +../Issues/iss241.htm +METHOD-COMBINATION-ARGUMENTS:CLARIFY +../Issues/iss242.htm +METHOD-INITFORM:FORBID-CALL-NEXT-METHOD +../Issues/iss243.htm +MUFFLE-WARNING-CONDITION-ARGUMENT +../Issues/iss244.htm +MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES +../Issues/iss245.htm +MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED +../Issues/iss246.htm +NINTERSECTION-DESTRUCTION +../Issues/iss247.htm +NINTERSECTION-DESTRUCTION:REVERT +../Issues/iss248.htm +NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93 +../Issues/iss249.htm +NTH-VALUE:ADD +../Issues/iss250.htm +OPTIMIZE-DEBUG-INFO:NEW-QUALITY +../Issues/iss251.htm +PACKAGE-CLUTTER:REDUCE +../Issues/iss252.htm +PACKAGE-DELETION:NEW-FUNCTION +../Issues/iss253.htm +PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE +../Issues/iss254.htm +PARSE-ERROR-STREAM:SPLIT-TYPES +../Issues/iss255.htm +PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT +../Issues/iss256.htm +PATHNAME-COMPONENT-VALUE:SPECIFY +../Issues/iss257.htm +PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES +../Issues/iss258.htm +PATHNAME-LOGICAL:ADD +../Issues/iss259.htm +PATHNAME-PRINT-READ:SHARPSIGN-P +../Issues/iss260.htm +PATHNAME-STREAM +../Issues/iss261.htm +PATHNAME-STREAM:FILES-OR-SYNONYM +../Issues/iss262.htm +PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION +../Issues/iss263.htm +PATHNAME-SYMBOL +../Issues/iss264.htm +PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE +../Issues/iss265.htm +PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN +../Issues/iss266.htm +PATHNAME-WILD:NEW-FUNCTIONS +../Issues/iss267.htm +PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR +../Issues/iss268.htm +PLIST-DUPLICATES:ALLOW +../Issues/iss269.htm +PRETTY-PRINT-INTERFACE +../Issues/iss270.htm +PRINC-READABLY:X3J13-DEC-91 +../Issues/iss271.htm +PRINT-CASE-BEHAVIOR:CLARIFY +../Issues/iss272.htm +PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE +../Issues/iss273.htm +PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE +../Issues/iss274.htm +PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK +../Issues/iss275.htm +PRINT-READABLY-BEHAVIOR:CLARIFY +../Issues/iss276.htm +PRINTER-WHITESPACE:JUST-ONE-SPACE +../Issues/iss277.htm +PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO +../Issues/iss278.htm +PUSH-EVALUATION-ORDER:FIRST-ITEM +../Issues/iss279.htm +PUSH-EVALUATION-ORDER:ITEM-FIRST +../Issues/iss280.htm +PUSHNEW-STORE-REQUIRED:UNSPECIFIED +../Issues/iss281.htm +QUOTE-SEMANTICS:NO-COPYING +../Issues/iss282.htm +RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER +../Issues/iss283.htm +RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL +../Issues/iss284.htm +READ-AND-WRITE-BYTES:NEW-FUNCTIONS +../Issues/iss285.htm +READ-CASE-SENSITIVITY:READTABLE-KEYWORDS +../Issues/iss286.htm +READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES +../Issues/iss287.htm +READ-SUPPRESS-CONFUSING:GENERALIZE +../Issues/iss288.htm +READER-ERROR:NEW-TYPE +../Issues/iss289.htm +REAL-NUMBER-TYPE:X3J13-MAR-89 +../Issues/iss290.htm +RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE +../Issues/iss291.htm +REDUCE-ARGUMENT-EXTRACTION +../Issues/iss292.htm +REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89 +../Issues/iss293.htm +REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91 +../Issues/iss294.htm +REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT +../Issues/iss295.htm +REQUIRE-PATHNAME-DEFAULTS:ELIMINATE +../Issues/iss296.htm +REST-LIST-ALLOCATION:MAY-SHARE +../Issues/iss297.htm +RESULT-LISTS-SHARED:SPECIFY +../Issues/iss298.htm +RETURN-VALUES-UNSPECIFIED:SPECIFY +../Issues/iss299.htm +ROOM-DEFAULT-ARGUMENT:NEW-VALUE +../Issues/iss300.htm +SELF-MODIFYING-CODE:FORBID +../Issues/iss301.htm +SEQUENCE-TYPE-LENGTH:MUST-MATCH +../Issues/iss302.htm +SETF-APPLY-EXPANSION:IGNORE-EXPANDER +../Issues/iss303.htm +SETF-FIND-CLASS:ALLOW-NIL +../Issues/iss304.htm +SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES +../Issues/iss305.htm +SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED +../Issues/iss306.htm +SETF-MACRO-EXPANSION:LAST +../Issues/iss307.htm +SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS +../Issues/iss308.htm +SETF-MULTIPLE-STORE-VARIABLES:ALLOW +../Issues/iss309.htm +SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS +../Issues/iss310.htm +SETF-OF-VALUES:ADD +../Issues/iss311.htm +SETF-SUB-METHODS:DELAYED-ACCESS-STORES +../Issues/iss312.htm +SHADOW-ALREADY-PRESENT +../Issues/iss313.htm +SHADOW-ALREADY-PRESENT:WORKS +../Issues/iss314.htm +SHARP-COMMA-CONFUSION:REMOVE +../Issues/iss315.htm +SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED +../Issues/iss316.htm +SHARP-STAR-DELIMITER:NORMAL-DELIMITER +../Issues/iss317.htm +SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD +../Issues/iss318.htm +SLOT-MISSING-VALUES:SPECIFY +../Issues/iss319.htm +SLOT-VALUE-METACLASSES:LESS-MINIMAL +../Issues/iss320.htm +SPECIAL-FORM-P-MISNOMER:RENAME +../Issues/iss321.htm +SPECIAL-TYPE-SHADOWING:CLARIFY +../Issues/iss322.htm +STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS +../Issues/iss323.htm +STANDARD-REPERTOIRE-GRATUITOUS:RENAME +../Issues/iss324.htm +STEP-ENVIRONMENT:CURRENT +../Issues/iss325.htm +STEP-MINIMAL:PERMIT-PROGN +../Issues/iss326.htm +STREAM-ACCESS:ADD-TYPES-ACCESSORS +../Issues/iss327.htm +STREAM-CAPABILITIES:INTERACTIVE-STREAM-P +../Issues/iss328.htm +STRING-COERCION:MAKE-CONSISTENT +../Issues/iss329.htm +STRING-OUTPUT-STREAM-BASHING:UNDEFINED +../Issues/iss330.htm +STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS +../Issues/iss331.htm +SUBSEQ-OUT-OF-BOUNDS +../Issues/iss332.htm +SUBSETTING-POSITION:NONE +../Issues/iss333.htm +SUBTYPEP-ENVIRONMENT:ADD-ARG +../Issues/iss334.htm +SUBTYPEP-TOO-VAGUE:CLARIFY-MORE +../Issues/iss335.htm +SXHASH-DEFINITION:SIMILAR-FOR-SXHASH +../Issues/iss336.htm +SYMBOL-MACROLET-DECLARE:ALLOW +../Issues/iss337.htm +SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM +../Issues/iss338.htm +SYMBOL-MACROLET-TYPE-DECLARATION:NO +../Issues/iss339.htm +SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR +../Issues/iss340.htm +SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY +../Issues/iss341.htm +SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91 +../Issues/iss342.htm +TAGBODY-TAG-EXPANSION:NO +../Issues/iss343.htm +TAILP-NIL:T +../Issues/iss344.htm +TEST-NOT-IF-NOT:FLUSH-ALL +../Issues/iss345.htm +THE-AMBIGUITY:FOR-DECLARATION +../Issues/iss346.htm +THE-VALUES:RETURN-NUMBER-RECEIVED +../Issues/iss347.htm +TIME-ZONE-NON-INTEGER:ALLOW +../Issues/iss348.htm +TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL +../Issues/iss349.htm +TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS +../Issues/iss350.htm +TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND +../Issues/iss351.htm +TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS +../Issues/iss352.htm +TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS +../Issues/iss353.htm +UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE +../Issues/iss354.htm +UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED +../Issues/iss355.htm +UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW +../Issues/iss356.htm +UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS +../Issues/iss357.htm +VARIABLE-LIST-ASYMMETRY:SYMMETRIZE +../Issues/iss358.htm +WITH-ADDED-METHODS:DELETE +../Issues/iss359.htm +WITH-COMPILATION-UNIT:NEW-MACRO +../Issues/iss360.htm +WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL +../Issues/iss361.htm +WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE +../Issues/iss362.htm +WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT +../Issues/iss363.htm +WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND +../Issues/iss364.htm +WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91 +../Issues/iss365.htm diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_Sym.txt b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_Sym.txt new file mode 100644 index 00000000..eb1a000b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/Map_Sym.txt @@ -0,0 +1,1956 @@ +&ALLOW-OTHER-KEYS +../Body/03_da.htm +&AUX +../Body/03_da.htm +&BODY +../Body/03_dd.htm +&ENVIRONMENT +../Body/03_dd.htm +&KEY +../Body/03_da.htm +&OPTIONAL +../Body/03_da.htm +&REST +../Body/03_da.htm +&WHOLE +../Body/03_dd.htm +* +../Body/a_st.htm +** +../Body/v__stst_.htm +*** +../Body/v__stst_.htm +*BREAK-ON-SIGNALS* +../Body/v_break_.htm +*COMPILE-FILE-PATHNAME* +../Body/v_cmp_fi.htm +*COMPILE-FILE-TRUENAME* +../Body/v_cmp_fi.htm +*COMPILE-PRINT* +../Body/v_cmp_pr.htm +*COMPILE-VERBOSE* +../Body/v_cmp_pr.htm +*DEBUG-IO* +../Body/v_debug_.htm +*DEBUGGER-HOOK* +../Body/v_debugg.htm +*DEFAULT-PATHNAME-DEFAULTS* +../Body/v_defaul.htm +*ERROR-OUTPUT* +../Body/v_debug_.htm +*FEATURES* +../Body/v_featur.htm +*GENSYM-COUNTER* +../Body/v_gensym.htm +*LOAD-PATHNAME* +../Body/v_ld_pns.htm +*LOAD-PRINT* +../Body/v_ld_prs.htm +*LOAD-TRUENAME* +../Body/v_ld_pns.htm +*LOAD-VERBOSE* +../Body/v_ld_prs.htm +*MACROEXPAND-HOOK* +../Body/v_mexp_h.htm +*MODULES* +../Body/v_module.htm +*PACKAGE* +../Body/v_pkg.htm +*PRINT-ARRAY* +../Body/v_pr_ar.htm +*PRINT-BASE* +../Body/v_pr_bas.htm +*PRINT-CASE* +../Body/v_pr_cas.htm +*PRINT-CIRCLE* +../Body/v_pr_cir.htm +*PRINT-ESCAPE* +../Body/v_pr_esc.htm +*PRINT-GENSYM* +../Body/v_pr_gen.htm +*PRINT-LENGTH* +../Body/v_pr_lev.htm +*PRINT-LEVEL* +../Body/v_pr_lev.htm +*PRINT-LINES* +../Body/v_pr_lin.htm +*PRINT-MISER-WIDTH* +../Body/v_pr_mis.htm +*PRINT-PPRINT-DISPATCH* +../Body/v_pr_ppr.htm +*PRINT-PRETTY* +../Body/v_pr_pre.htm +*PRINT-RADIX* +../Body/v_pr_bas.htm +*PRINT-READABLY* +../Body/v_pr_rda.htm +*PRINT-RIGHT-MARGIN* +../Body/v_pr_rig.htm +*QUERY-IO* +../Body/v_debug_.htm +*RANDOM-STATE* +../Body/v_rnd_st.htm +*READ-BASE* +../Body/v_rd_bas.htm +*READ-DEFAULT-FLOAT-FORMAT* +../Body/v_rd_def.htm +*READ-EVAL* +../Body/v_rd_eva.htm +*READ-SUPPRESS* +../Body/v_rd_sup.htm +*READTABLE* +../Body/v_rdtabl.htm +*STANDARD-INPUT* +../Body/v_debug_.htm +*STANDARD-OUTPUT* +../Body/v_debug_.htm +*TERMINAL-IO* +../Body/v_termin.htm +*TRACE-OUTPUT* +../Body/v_debug_.htm ++ +../Body/a_pl.htm +++ +../Body/v_pl_plp.htm ++++ +../Body/v_pl_plp.htm +- +../Body/a__.htm +/ +../Body/a_sl.htm +// +../Body/v_sl_sls.htm +/// +../Body/v_sl_sls.htm +/= +../Body/f_eq_sle.htm +1+ +../Body/f_1pl_1_.htm +1- +../Body/f_1pl_1_.htm +< +../Body/f_eq_sle.htm +<= +../Body/f_eq_sle.htm += +../Body/f_eq_sle.htm +> +../Body/f_eq_sle.htm +>= +../Body/f_eq_sle.htm +ABORT +../Body/a_abort.htm +ABS +../Body/f_abs.htm +ACONS +../Body/f_acons.htm +ACOS +../Body/f_asin_.htm +ACOSH +../Body/f_sinh_.htm +ADD-METHOD +../Body/f_add_me.htm +ADJOIN +../Body/f_adjoin.htm +ADJUST-ARRAY +../Body/f_adjust.htm +ADJUSTABLE-ARRAY-P +../Body/f_adju_1.htm +ALLOCATE-INSTANCE +../Body/f_alloca.htm +ALPHA-CHAR-P +../Body/f_alpha_.htm +ALPHANUMERICP +../Body/f_alphan.htm +AND +../Body/a_and.htm +APPEND +../Body/f_append.htm +APPLY +../Body/f_apply.htm +APROPOS +../Body/f_apropo.htm +APROPOS-LIST +../Body/f_apropo.htm +AREF +../Body/f_aref.htm +ARITHMETIC-ERROR +../Body/e_arithm.htm +ARITHMETIC-ERROR-OPERANDS +../Body/f_arithm.htm +ARITHMETIC-ERROR-OPERATION +../Body/f_arithm.htm +ARRAY +../Body/t_array.htm +ARRAY-DIMENSION +../Body/f_ar_dim.htm +ARRAY-DIMENSION-LIMIT +../Body/v_ar_dim.htm +ARRAY-DIMENSIONS +../Body/f_ar_d_1.htm +ARRAY-DISPLACEMENT +../Body/f_ar_dis.htm +ARRAY-ELEMENT-TYPE +../Body/f_ar_ele.htm +ARRAY-HAS-FILL-POINTER-P +../Body/f_ar_has.htm +ARRAY-IN-BOUNDS-P +../Body/f_ar_in_.htm +ARRAY-RANK +../Body/f_ar_ran.htm +ARRAY-RANK-LIMIT +../Body/v_ar_ran.htm +ARRAY-ROW-MAJOR-INDEX +../Body/f_ar_row.htm +ARRAY-TOTAL-SIZE +../Body/f_ar_tot.htm +ARRAY-TOTAL-SIZE-LIMIT +../Body/v_ar_tot.htm +ARRAYP +../Body/f_arrayp.htm +ASH +../Body/f_ash.htm +ASIN +../Body/f_asin_.htm +ASINH +../Body/f_sinh_.htm +ASSERT +../Body/m_assert.htm +ASSOC +../Body/f_assocc.htm +ASSOC-IF +../Body/f_assocc.htm +ASSOC-IF-NOT +../Body/f_assocc.htm +ATAN +../Body/f_asin_.htm +ATANH +../Body/f_sinh_.htm +ATOM +../Body/a_atom.htm +BASE-CHAR +../Body/t_base_c.htm +BASE-STRING +../Body/t_base_s.htm +BIGNUM +../Body/t_bignum.htm +BIT +../Body/a_bit.htm +BIT-AND +../Body/f_bt_and.htm +BIT-ANDC1 +../Body/f_bt_and.htm +BIT-ANDC2 +../Body/f_bt_and.htm +BIT-EQV +../Body/f_bt_and.htm +BIT-IOR +../Body/f_bt_and.htm +BIT-NAND +../Body/f_bt_and.htm +BIT-NOR +../Body/f_bt_and.htm +BIT-NOT +../Body/f_bt_and.htm +BIT-ORC1 +../Body/f_bt_and.htm +BIT-ORC2 +../Body/f_bt_and.htm +BIT-VECTOR +../Body/t_bt_vec.htm +BIT-VECTOR-P +../Body/f_bt_vec.htm +BIT-XOR +../Body/f_bt_and.htm +BLOCK +../Body/s_block.htm +BOOLE +../Body/f_boole.htm +BOOLE-1 +../Body/v_b_1_b.htm +BOOLE-2 +../Body/v_b_1_b.htm +BOOLE-AND +../Body/v_b_1_b.htm +BOOLE-ANDC1 +../Body/v_b_1_b.htm +BOOLE-ANDC2 +../Body/v_b_1_b.htm +BOOLE-C1 +../Body/v_b_1_b.htm +BOOLE-C2 +../Body/v_b_1_b.htm +BOOLE-CLR +../Body/v_b_1_b.htm +BOOLE-EQV +../Body/v_b_1_b.htm +BOOLE-IOR +../Body/v_b_1_b.htm +BOOLE-NAND +../Body/v_b_1_b.htm +BOOLE-NOR +../Body/v_b_1_b.htm +BOOLE-ORC1 +../Body/v_b_1_b.htm +BOOLE-ORC2 +../Body/v_b_1_b.htm +BOOLE-SET +../Body/v_b_1_b.htm +BOOLE-XOR +../Body/v_b_1_b.htm +BOOLEAN +../Body/t_ban.htm +BOTH-CASE-P +../Body/f_upper_.htm +BOUNDP +../Body/f_boundp.htm +BREAK +../Body/f_break.htm +BROADCAST-STREAM +../Body/t_broadc.htm +BROADCAST-STREAM-STREAMS +../Body/f_broadc.htm +BUILT-IN-CLASS +../Body/t_built_.htm +BUTLAST +../Body/f_butlas.htm +BYTE +../Body/f_by_by.htm +BYTE-POSITION +../Body/f_by_by.htm +BYTE-SIZE +../Body/f_by_by.htm +CAAAAR +../Body/f_car_c.htm +CAAADR +../Body/f_car_c.htm +CAAAR +../Body/f_car_c.htm +CAADAR +../Body/f_car_c.htm +CAADDR +../Body/f_car_c.htm +CAADR +../Body/f_car_c.htm +CAAR +../Body/f_car_c.htm +CADAAR +../Body/f_car_c.htm +CADADR +../Body/f_car_c.htm +CADAR +../Body/f_car_c.htm +CADDAR +../Body/f_car_c.htm +CADDDR +../Body/f_car_c.htm +CADDR +../Body/f_car_c.htm +CADR +../Body/f_car_c.htm +CALL-ARGUMENTS-LIMIT +../Body/v_call_a.htm +CALL-METHOD +../Body/m_call_m.htm +CALL-NEXT-METHOD +../Body/f_call_n.htm +CAR +../Body/f_car_c.htm +CASE +../Body/m_case_.htm +CATCH +../Body/s_catch.htm +CCASE +../Body/m_case_.htm +CDAAAR +../Body/f_car_c.htm +CDAADR +../Body/f_car_c.htm +CDAAR +../Body/f_car_c.htm +CDADAR +../Body/f_car_c.htm +CDADDR +../Body/f_car_c.htm +CDADR +../Body/f_car_c.htm +CDAR +../Body/f_car_c.htm +CDDAAR +../Body/f_car_c.htm +CDDADR +../Body/f_car_c.htm +CDDAR +../Body/f_car_c.htm +CDDDAR +../Body/f_car_c.htm +CDDDDR +../Body/f_car_c.htm +CDDDR +../Body/f_car_c.htm +CDDR +../Body/f_car_c.htm +CDR +../Body/f_car_c.htm +CEILING +../Body/f_floorc.htm +CELL-ERROR +../Body/e_cell_e.htm +CELL-ERROR-NAME +../Body/f_cell_e.htm +CERROR +../Body/f_cerror.htm +CHANGE-CLASS +../Body/f_chg_cl.htm +CHAR +../Body/f_char_.htm +CHAR-CODE +../Body/f_char_c.htm +CHAR-CODE-LIMIT +../Body/v_char_c.htm +CHAR-DOWNCASE +../Body/f_char_u.htm +CHAR-EQUAL +../Body/f_chareq.htm +CHAR-GREATERP +../Body/f_chareq.htm +CHAR-INT +../Body/f_char_i.htm +CHAR-LESSP +../Body/f_chareq.htm +CHAR-NAME +../Body/f_char_n.htm +CHAR-NOT-EQUAL +../Body/f_chareq.htm +CHAR-NOT-GREATERP +../Body/f_chareq.htm +CHAR-NOT-LESSP +../Body/f_chareq.htm +CHAR-UPCASE +../Body/f_char_u.htm +CHAR/= +../Body/f_chareq.htm +CHAR< +../Body/f_chareq.htm +CHAR<= +../Body/f_chareq.htm +CHAR= +../Body/f_chareq.htm +CHAR> +../Body/f_chareq.htm +CHAR>= +../Body/f_chareq.htm +CHARACTER +../Body/a_ch.htm +CHARACTERP +../Body/f_chp.htm +CHECK-TYPE +../Body/m_check_.htm +CIS +../Body/f_cis.htm +CLASS +../Body/t_class.htm +CLASS-NAME +../Body/f_class_.htm +CLASS-OF +../Body/f_clas_1.htm +CLEAR-INPUT +../Body/f_clear_.htm +CLEAR-OUTPUT +../Body/f_finish.htm +CLOSE +../Body/f_close.htm +CLRHASH +../Body/f_clrhas.htm +CODE-CHAR +../Body/f_code_c.htm +COERCE +../Body/f_coerce.htm +COMPILATION-SPEED +../Body/d_optimi.htm +COMPILE +../Body/f_cmp.htm +COMPILE-FILE +../Body/f_cmp_fi.htm +COMPILE-FILE-PATHNAME +../Body/f_cmp__1.htm +COMPILED-FUNCTION +../Body/t_cmpd_f.htm +COMPILED-FUNCTION-P +../Body/f_cmpd_f.htm +COMPILER-MACRO +../Body/f_docume.htm +COMPILER-MACRO-FUNCTION +../Body/f_cmp_ma.htm +COMPLEMENT +../Body/f_comple.htm +COMPLEX +../Body/a_comple.htm +COMPLEXP +../Body/f_comp_3.htm +COMPUTE-APPLICABLE-METHODS +../Body/f_comput.htm +COMPUTE-RESTARTS +../Body/f_comp_1.htm +CONCATENATE +../Body/f_concat.htm +CONCATENATED-STREAM +../Body/t_concat.htm +CONCATENATED-STREAM-STREAMS +../Body/f_conc_1.htm +COND +../Body/m_cond.htm +CONDITION +../Body/e_cnd.htm +CONJUGATE +../Body/f_conjug.htm +CONS +../Body/a_cons.htm +CONSP +../Body/f_consp.htm +CONSTANTLY +../Body/f_cons_1.htm +CONSTANTP +../Body/f_consta.htm +CONTINUE +../Body/a_contin.htm +CONTROL-ERROR +../Body/e_contro.htm +COPY-ALIST +../Body/f_cp_ali.htm +COPY-LIST +../Body/f_cp_lis.htm +COPY-PPRINT-DISPATCH +../Body/f_cp_ppr.htm +COPY-READTABLE +../Body/f_cp_rdt.htm +COPY-SEQ +../Body/f_cp_seq.htm +COPY-STRUCTURE +../Body/f_cp_stu.htm +COPY-SYMBOL +../Body/f_cp_sym.htm +COPY-TREE +../Body/f_cp_tre.htm +COS +../Body/f_sin_c.htm +COSH +../Body/f_sinh_.htm +COUNT +../Body/f_countc.htm +COUNT-IF +../Body/f_countc.htm +COUNT-IF-NOT +../Body/f_countc.htm +CTYPECASE +../Body/m_tpcase.htm +DEBUG +../Body/d_optimi.htm +DECF +../Body/m_incf_.htm +DECLAIM +../Body/m_declai.htm +DECLARATION +../Body/d_declar.htm +DECLARE +../Body/s_declar.htm +DECODE-FLOAT +../Body/f_dec_fl.htm +DECODE-UNIVERSAL-TIME +../Body/f_dec_un.htm +DEFCLASS +../Body/m_defcla.htm +DEFCONSTANT +../Body/m_defcon.htm +DEFGENERIC +../Body/m_defgen.htm +DEFINE-COMPILER-MACRO +../Body/m_define.htm +DEFINE-CONDITION +../Body/m_defi_5.htm +DEFINE-METHOD-COMBINATION +../Body/m_defi_4.htm +DEFINE-MODIFY-MACRO +../Body/m_defi_2.htm +DEFINE-SETF-EXPANDER +../Body/m_defi_3.htm +DEFINE-SYMBOL-MACRO +../Body/m_defi_1.htm +DEFMACRO +../Body/m_defmac.htm +DEFMETHOD +../Body/m_defmet.htm +DEFPACKAGE +../Body/m_defpkg.htm +DEFPARAMETER +../Body/m_defpar.htm +DEFSETF +../Body/m_defset.htm +DEFSTRUCT +../Body/m_defstr.htm +DEFTYPE +../Body/m_deftp.htm +DEFUN +../Body/m_defun.htm +DEFVAR +../Body/m_defpar.htm +DELETE +../Body/f_rm_rm.htm +DELETE-DUPLICATES +../Body/f_rm_dup.htm +DELETE-FILE +../Body/f_del_fi.htm +DELETE-IF +../Body/f_rm_rm.htm +DELETE-IF-NOT +../Body/f_rm_rm.htm +DELETE-PACKAGE +../Body/f_del_pk.htm +DENOMINATOR +../Body/f_numera.htm +DEPOSIT-FIELD +../Body/f_deposi.htm +DESCRIBE +../Body/f_descri.htm +DESCRIBE-OBJECT +../Body/f_desc_1.htm +DESTRUCTURING-BIND +../Body/m_destru.htm +DIGIT-CHAR +../Body/f_digit_.htm +DIGIT-CHAR-P +../Body/f_digi_1.htm +DIRECTORY +../Body/f_dir.htm +DIRECTORY-NAMESTRING +../Body/f_namest.htm +DISASSEMBLE +../Body/f_disass.htm +DIVISION-BY-ZERO +../Body/e_divisi.htm +DO +../Body/m_do_do.htm +DO* +../Body/m_do_do.htm +DO-ALL-SYMBOLS +../Body/m_do_sym.htm +DO-EXTERNAL-SYMBOLS +../Body/m_do_sym.htm +DO-SYMBOLS +../Body/m_do_sym.htm +DOCUMENTATION +../Body/f_docume.htm +DOLIST +../Body/m_dolist.htm +DOTIMES +../Body/m_dotime.htm +DOUBLE-FLOAT +../Body/t_short_.htm +DOUBLE-FLOAT-EPSILON +../Body/v_short_.htm +DOUBLE-FLOAT-NEGATIVE-EPSILON +../Body/v_short_.htm +DPB +../Body/f_dpb.htm +DRIBBLE +../Body/f_dribbl.htm +DYNAMIC-EXTENT +../Body/d_dynami.htm +ECASE +../Body/m_case_.htm +ECHO-STREAM +../Body/t_echo_s.htm +ECHO-STREAM-INPUT-STREAM +../Body/f_echo_s.htm +ECHO-STREAM-OUTPUT-STREAM +../Body/f_echo_s.htm +ED +../Body/f_ed.htm +EIGHTH +../Body/f_firstc.htm +ELT +../Body/f_elt.htm +ENCODE-UNIVERSAL-TIME +../Body/f_encode.htm +END-OF-FILE +../Body/e_end_of.htm +ENDP +../Body/f_endp.htm +ENOUGH-NAMESTRING +../Body/f_namest.htm +ENSURE-DIRECTORIES-EXIST +../Body/f_ensu_1.htm +ENSURE-GENERIC-FUNCTION +../Body/f_ensure.htm +EQ +../Body/f_eq.htm +EQL +../Body/a_eql.htm +EQUAL +../Body/f_equal.htm +EQUALP +../Body/f_equalp.htm +ERROR +../Body/a_error.htm +ETYPECASE +../Body/m_tpcase.htm +EVAL +../Body/f_eval.htm +EVAL-WHEN +../Body/s_eval_w.htm +EVENP +../Body/f_evenpc.htm +EVERY +../Body/f_everyc.htm +EXP +../Body/f_exp_e.htm +EXPORT +../Body/f_export.htm +EXPT +../Body/f_exp_e.htm +EXTENDED-CHAR +../Body/t_extend.htm +FBOUNDP +../Body/f_fbound.htm +FCEILING +../Body/f_floorc.htm +FDEFINITION +../Body/f_fdefin.htm +FFLOOR +../Body/f_floorc.htm +FIFTH +../Body/f_firstc.htm +FILE-AUTHOR +../Body/f_file_a.htm +FILE-ERROR +../Body/e_file_e.htm +FILE-ERROR-PATHNAME +../Body/f_file_e.htm +FILE-LENGTH +../Body/f_file_l.htm +FILE-NAMESTRING +../Body/f_namest.htm +FILE-POSITION +../Body/f_file_p.htm +FILE-STREAM +../Body/t_file_s.htm +FILE-STRING-LENGTH +../Body/f_file_s.htm +FILE-WRITE-DATE +../Body/f_file_w.htm +FILL +../Body/f_fill.htm +FILL-POINTER +../Body/f_fill_p.htm +FIND +../Body/f_find_.htm +FIND-ALL-SYMBOLS +../Body/f_find_a.htm +FIND-CLASS +../Body/f_find_c.htm +FIND-IF +../Body/f_find_.htm +FIND-IF-NOT +../Body/f_find_.htm +FIND-METHOD +../Body/f_find_m.htm +FIND-PACKAGE +../Body/f_find_p.htm +FIND-RESTART +../Body/f_find_r.htm +FIND-SYMBOL +../Body/f_find_s.htm +FINISH-OUTPUT +../Body/f_finish.htm +FIRST +../Body/f_firstc.htm +FIXNUM +../Body/t_fixnum.htm +FLET +../Body/s_flet_.htm +FLOAT +../Body/a_float.htm +FLOAT-DIGITS +../Body/f_dec_fl.htm +FLOAT-PRECISION +../Body/f_dec_fl.htm +FLOAT-RADIX +../Body/f_dec_fl.htm +FLOAT-SIGN +../Body/f_dec_fl.htm +FLOATING-POINT-INEXACT +../Body/e_floa_1.htm +FLOATING-POINT-INVALID-OPERATION +../Body/e_floati.htm +FLOATING-POINT-OVERFLOW +../Body/e_floa_2.htm +FLOATING-POINT-UNDERFLOW +../Body/e_floa_3.htm +FLOATP +../Body/f_floatp.htm +FLOOR +../Body/f_floorc.htm +FMAKUNBOUND +../Body/f_fmakun.htm +FORCE-OUTPUT +../Body/f_finish.htm +FORMAT +../Body/f_format.htm +FORMATTER +../Body/m_format.htm +FOURTH +../Body/f_firstc.htm +FRESH-LINE +../Body/f_terpri.htm +FROUND +../Body/f_floorc.htm +FTRUNCATE +../Body/f_floorc.htm +FTYPE +../Body/d_ftype.htm +FUNCALL +../Body/f_funcal.htm +FUNCTION +../Body/a_fn.htm +FUNCTION-KEYWORDS +../Body/f_fn_kwd.htm +FUNCTION-LAMBDA-EXPRESSION +../Body/f_fn_lam.htm +FUNCTIONP +../Body/f_fnp.htm +GCD +../Body/f_gcd.htm +GENERIC-FUNCTION +../Body/t_generi.htm +GENSYM +../Body/f_gensym.htm +GENTEMP +../Body/f_gentem.htm +GET +../Body/f_get.htm +GET-DECODED-TIME +../Body/f_get_un.htm +GET-DISPATCH-MACRO-CHARACTER +../Body/f_set__1.htm +GET-INTERNAL-REAL-TIME +../Body/f_get_in.htm +GET-INTERNAL-RUN-TIME +../Body/f_get__1.htm +GET-MACRO-CHARACTER +../Body/f_set_ma.htm +GET-OUTPUT-STREAM-STRING +../Body/f_get_ou.htm +GET-PROPERTIES +../Body/f_get_pr.htm +GET-SETF-EXPANSION +../Body/f_get_se.htm +GET-UNIVERSAL-TIME +../Body/f_get_un.htm +GETF +../Body/f_getf.htm +GETHASH +../Body/f_gethas.htm +GO +../Body/s_go.htm +GRAPHIC-CHAR-P +../Body/f_graphi.htm +HANDLER-BIND +../Body/m_handle.htm +HANDLER-CASE +../Body/m_hand_1.htm +HASH-TABLE +../Body/t_hash_t.htm +HASH-TABLE-COUNT +../Body/f_hash_1.htm +HASH-TABLE-P +../Body/f_hash_t.htm +HASH-TABLE-REHASH-SIZE +../Body/f_hash_2.htm +HASH-TABLE-REHASH-THRESHOLD +../Body/f_hash_3.htm +HASH-TABLE-SIZE +../Body/f_hash_4.htm +HASH-TABLE-TEST +../Body/f_hash_5.htm +HOST-NAMESTRING +../Body/f_namest.htm +IDENTITY +../Body/f_identi.htm +IF +../Body/s_if.htm +IGNORABLE +../Body/d_ignore.htm +IGNORE +../Body/d_ignore.htm +IGNORE-ERRORS +../Body/m_ignore.htm +IMAGPART +../Body/f_realpa.htm +IMPORT +../Body/f_import.htm +IN-PACKAGE +../Body/m_in_pkg.htm +INCF +../Body/m_incf_.htm +INITIALIZE-INSTANCE +../Body/f_init_i.htm +INLINE +../Body/d_inline.htm +INPUT-STREAM-P +../Body/f_in_stm.htm +INSPECT +../Body/f_inspec.htm +INTEGER +../Body/t_intege.htm +INTEGER-DECODE-FLOAT +../Body/f_dec_fl.htm +INTEGER-LENGTH +../Body/f_intege.htm +INTEGERP +../Body/f_inte_1.htm +INTERACTIVE-STREAM-P +../Body/f_intera.htm +INTERN +../Body/f_intern.htm +INTERNAL-TIME-UNITS-PER-SECOND +../Body/v_intern.htm +INTERSECTION +../Body/f_isec_.htm +INVALID-METHOD-ERROR +../Body/f_invali.htm +INVOKE-DEBUGGER +../Body/f_invoke.htm +INVOKE-RESTART +../Body/f_invo_1.htm +INVOKE-RESTART-INTERACTIVELY +../Body/f_invo_2.htm +ISQRT +../Body/f_sqrt_.htm +KEYWORD +../Body/t_kwd.htm +KEYWORDP +../Body/f_kwdp.htm +LABELS +../Body/s_flet_.htm +LAMBDA +../Body/a_lambda.htm +LAMBDA-LIST-KEYWORDS +../Body/v_lambda.htm +LAMBDA-PARAMETERS-LIMIT +../Body/v_lamb_1.htm +LAST +../Body/f_last.htm +LCM +../Body/f_lcm.htm +LDB +../Body/f_ldb.htm +LDB-TEST +../Body/f_ldb_te.htm +LDIFF +../Body/f_ldiffc.htm +LEAST-NEGATIVE-DOUBLE-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-LONG-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-SHORT-FLOAT +../Body/v_most_1.htm +LEAST-NEGATIVE-SINGLE-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-DOUBLE-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-LONG-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-NORMALIZED-LONG-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-SHORT-FLOAT +../Body/v_most_1.htm +LEAST-POSITIVE-SINGLE-FLOAT +../Body/v_most_1.htm +LENGTH +../Body/f_length.htm +LET +../Body/s_let_l.htm +LET* +../Body/s_let_l.htm +LISP-IMPLEMENTATION-TYPE +../Body/f_lisp_i.htm +LISP-IMPLEMENTATION-VERSION +../Body/f_lisp_i.htm +LIST +../Body/a_list.htm +LIST* +../Body/f_list_.htm +LIST-ALL-PACKAGES +../Body/f_list_a.htm +LIST-LENGTH +../Body/f_list_l.htm +LISTEN +../Body/f_listen.htm +LISTP +../Body/f_listp.htm +LOAD +../Body/f_load.htm +LOAD-LOGICAL-PATHNAME-TRANSLATIONS +../Body/f_ld_log.htm +LOAD-TIME-VALUE +../Body/s_ld_tim.htm +LOCALLY +../Body/s_locall.htm +LOG +../Body/f_log.htm +LOGAND +../Body/f_logand.htm +LOGANDC1 +../Body/f_logand.htm +LOGANDC2 +../Body/f_logand.htm +LOGBITP +../Body/f_logbtp.htm +LOGCOUNT +../Body/f_logcou.htm +LOGEQV +../Body/f_logand.htm +LOGICAL-PATHNAME +../Body/a_logica.htm +LOGICAL-PATHNAME-TRANSLATIONS +../Body/f_logica.htm +LOGIOR +../Body/f_logand.htm +LOGNAND +../Body/f_logand.htm +LOGNOR +../Body/f_logand.htm +LOGNOT +../Body/f_logand.htm +LOGORC1 +../Body/f_logand.htm +LOGORC2 +../Body/f_logand.htm +LOGTEST +../Body/f_logtes.htm +LOGXOR +../Body/f_logand.htm +LONG-FLOAT +../Body/t_short_.htm +LONG-FLOAT-EPSILON +../Body/v_short_.htm +LONG-FLOAT-NEGATIVE-EPSILON +../Body/v_short_.htm +LONG-SITE-NAME +../Body/f_short_.htm +LOOP +../Body/m_loop.htm +LOOP-FINISH +../Body/m_loop_f.htm +LOWER-CASE-P +../Body/f_upper_.htm +MACHINE-INSTANCE +../Body/f_mach_i.htm +MACHINE-TYPE +../Body/f_mach_t.htm +MACHINE-VERSION +../Body/f_mach_v.htm +MACRO-FUNCTION +../Body/f_macro_.htm +MACROEXPAND +../Body/f_mexp_.htm +MACROEXPAND-1 +../Body/f_mexp_.htm +MACROLET +../Body/s_flet_.htm +MAKE-ARRAY +../Body/f_mk_ar.htm +MAKE-BROADCAST-STREAM +../Body/f_mk_bro.htm +MAKE-CONCATENATED-STREAM +../Body/f_mk_con.htm +MAKE-CONDITION +../Body/f_mk_cnd.htm +MAKE-DISPATCH-MACRO-CHARACTER +../Body/f_mk_dis.htm +MAKE-ECHO-STREAM +../Body/f_mk_ech.htm +MAKE-HASH-TABLE +../Body/f_mk_has.htm +MAKE-INSTANCE +../Body/f_mk_ins.htm +MAKE-INSTANCES-OBSOLETE +../Body/f_mk_i_1.htm +MAKE-LIST +../Body/f_mk_lis.htm +MAKE-LOAD-FORM +../Body/f_mk_ld_.htm +MAKE-LOAD-FORM-SAVING-SLOTS +../Body/f_mk_l_1.htm +MAKE-METHOD +../Body/m_call_m.htm +MAKE-PACKAGE +../Body/f_mk_pkg.htm +MAKE-PATHNAME +../Body/f_mk_pn.htm +MAKE-RANDOM-STATE +../Body/f_mk_rnd.htm +MAKE-SEQUENCE +../Body/f_mk_seq.htm +MAKE-STRING +../Body/f_mk_stg.htm +MAKE-STRING-INPUT-STREAM +../Body/f_mk_s_1.htm +MAKE-STRING-OUTPUT-STREAM +../Body/f_mk_s_2.htm +MAKE-SYMBOL +../Body/f_mk_sym.htm +MAKE-SYNONYM-STREAM +../Body/f_mk_syn.htm +MAKE-TWO-WAY-STREAM +../Body/f_mk_two.htm +MAKUNBOUND +../Body/f_makunb.htm +MAP +../Body/f_map.htm +MAP-INTO +../Body/f_map_in.htm +MAPC +../Body/f_mapc_.htm +MAPCAN +../Body/f_mapc_.htm +MAPCAR +../Body/f_mapc_.htm +MAPCON +../Body/f_mapc_.htm +MAPHASH +../Body/f_maphas.htm +MAPL +../Body/f_mapc_.htm +MAPLIST +../Body/f_mapc_.htm +MASK-FIELD +../Body/f_mask_f.htm +MAX +../Body/f_max_m.htm +MEMBER +../Body/a_member.htm +MEMBER-IF +../Body/f_mem_m.htm +MEMBER-IF-NOT +../Body/f_mem_m.htm +MERGE +../Body/f_merge.htm +MERGE-PATHNAMES +../Body/f_merge_.htm +METHOD +../Body/t_method.htm +METHOD-COMBINATION +../Body/a_method.htm +METHOD-COMBINATION-ERROR +../Body/f_meth_1.htm +METHOD-QUALIFIERS +../Body/f_method.htm +MIN +../Body/f_max_m.htm +MINUSP +../Body/f_minusp.htm +MISMATCH +../Body/f_mismat.htm +MOD +../Body/a_mod.htm +MOST-NEGATIVE-DOUBLE-FLOAT +../Body/v_most_1.htm +MOST-NEGATIVE-FIXNUM +../Body/v_most_p.htm +MOST-NEGATIVE-LONG-FLOAT +../Body/v_most_1.htm +MOST-NEGATIVE-SHORT-FLOAT +../Body/v_most_1.htm +MOST-NEGATIVE-SINGLE-FLOAT +../Body/v_most_1.htm +MOST-POSITIVE-DOUBLE-FLOAT +../Body/v_most_1.htm +MOST-POSITIVE-FIXNUM +../Body/v_most_p.htm +MOST-POSITIVE-LONG-FLOAT +../Body/v_most_1.htm +MOST-POSITIVE-SHORT-FLOAT +../Body/v_most_1.htm +MOST-POSITIVE-SINGLE-FLOAT +../Body/v_most_1.htm +MUFFLE-WARNING +../Body/a_muffle.htm +MULTIPLE-VALUE-BIND +../Body/m_multip.htm +MULTIPLE-VALUE-CALL +../Body/s_multip.htm +MULTIPLE-VALUE-LIST +../Body/m_mult_1.htm +MULTIPLE-VALUE-PROG1 +../Body/s_mult_1.htm +MULTIPLE-VALUE-SETQ +../Body/m_mult_2.htm +MULTIPLE-VALUES-LIMIT +../Body/v_multip.htm +NAME-CHAR +../Body/f_name_c.htm +NAMESTRING +../Body/f_namest.htm +NBUTLAST +../Body/f_butlas.htm +NCONC +../Body/f_nconc.htm +NEXT-METHOD-P +../Body/f_next_m.htm +NIL +../Body/a_nil.htm +NINTERSECTION +../Body/f_isec_.htm +NINTH +../Body/f_firstc.htm +NO-APPLICABLE-METHOD +../Body/f_no_app.htm +NO-NEXT-METHOD +../Body/f_no_nex.htm +NOT +../Body/a_not.htm +NOTANY +../Body/f_everyc.htm +NOTEVERY +../Body/f_everyc.htm +NOTINLINE +../Body/d_inline.htm +NRECONC +../Body/f_revapp.htm +NREVERSE +../Body/f_revers.htm +NSET-DIFFERENCE +../Body/f_set_di.htm +NSET-EXCLUSIVE-OR +../Body/f_set_ex.htm +NSTRING-CAPITALIZE +../Body/f_stg_up.htm +NSTRING-DOWNCASE +../Body/f_stg_up.htm +NSTRING-UPCASE +../Body/f_stg_up.htm +NSUBLIS +../Body/f_sublis.htm +NSUBST +../Body/f_substc.htm +NSUBST-IF +../Body/f_substc.htm +NSUBST-IF-NOT +../Body/f_substc.htm +NSUBSTITUTE +../Body/f_sbs_s.htm +NSUBSTITUTE-IF +../Body/f_sbs_s.htm +NSUBSTITUTE-IF-NOT +../Body/f_sbs_s.htm +NTH +../Body/f_nth.htm +NTH-VALUE +../Body/m_nth_va.htm +NTHCDR +../Body/f_nthcdr.htm +NULL +../Body/a_null.htm +NUMBER +../Body/t_number.htm +NUMBERP +../Body/f_nump.htm +NUMERATOR +../Body/f_numera.htm +NUNION +../Body/f_unionc.htm +ODDP +../Body/f_evenpc.htm +OPEN +../Body/f_open.htm +OPEN-STREAM-P +../Body/f_open_s.htm +OPTIMIZE +../Body/d_optimi.htm +OR +../Body/a_or.htm +OTHERWISE +../Body/m_case_.htm +OUTPUT-STREAM-P +../Body/f_in_stm.htm +PACKAGE +../Body/t_pkg.htm +PACKAGE-ERROR +../Body/e_pkg_er.htm +PACKAGE-ERROR-PACKAGE +../Body/f_pkg_er.htm +PACKAGE-NAME +../Body/f_pkg_na.htm +PACKAGE-NICKNAMES +../Body/f_pkg_ni.htm +PACKAGE-SHADOWING-SYMBOLS +../Body/f_pkg_sh.htm +PACKAGE-USE-LIST +../Body/f_pkg_us.htm +PACKAGE-USED-BY-LIST +../Body/f_pkg__1.htm +PACKAGEP +../Body/f_pkgp.htm +PAIRLIS +../Body/f_pairli.htm +PARSE-ERROR +../Body/e_parse_.htm +PARSE-INTEGER +../Body/f_parse_.htm +PARSE-NAMESTRING +../Body/f_pars_1.htm +PATHNAME +../Body/a_pn.htm +PATHNAME-DEVICE +../Body/f_pn_hos.htm +PATHNAME-DIRECTORY +../Body/f_pn_hos.htm +PATHNAME-HOST +../Body/f_pn_hos.htm +PATHNAME-MATCH-P +../Body/f_pn_mat.htm +PATHNAME-NAME +../Body/f_pn_hos.htm +PATHNAME-TYPE +../Body/f_pn_hos.htm +PATHNAME-VERSION +../Body/f_pn_hos.htm +PATHNAMEP +../Body/f_pnp.htm +PEEK-CHAR +../Body/f_peek_c.htm +PHASE +../Body/f_phase.htm +PI +../Body/v_pi.htm +PLUSP +../Body/f_minusp.htm +POP +../Body/m_pop.htm +POSITION +../Body/f_pos_p.htm +POSITION-IF +../Body/f_pos_p.htm +POSITION-IF-NOT +../Body/f_pos_p.htm +PPRINT +../Body/f_wr_pr.htm +PPRINT-DISPATCH +../Body/f_ppr_di.htm +PPRINT-EXIT-IF-LIST-EXHAUSTED +../Body/m_ppr_ex.htm +PPRINT-FILL +../Body/f_ppr_fi.htm +PPRINT-INDENT +../Body/f_ppr_in.htm +PPRINT-LINEAR +../Body/f_ppr_fi.htm +PPRINT-LOGICAL-BLOCK +../Body/m_ppr_lo.htm +PPRINT-NEWLINE +../Body/f_ppr_nl.htm +PPRINT-POP +../Body/m_ppr_po.htm +PPRINT-TAB +../Body/f_ppr_ta.htm +PPRINT-TABULAR +../Body/f_ppr_fi.htm +PRIN1 +../Body/f_wr_pr.htm +PRIN1-TO-STRING +../Body/f_wr_to_.htm +PRINC +../Body/f_wr_pr.htm +PRINC-TO-STRING +../Body/f_wr_to_.htm +PRINT +../Body/f_wr_pr.htm +PRINT-NOT-READABLE +../Body/e_pr_not.htm +PRINT-NOT-READABLE-OBJECT +../Body/f_pr_not.htm +PRINT-OBJECT +../Body/f_pr_obj.htm +PRINT-UNREADABLE-OBJECT +../Body/m_pr_unr.htm +PROBE-FILE +../Body/f_probe_.htm +PROCLAIM +../Body/f_procla.htm +PROG +../Body/m_prog_.htm +PROG* +../Body/m_prog_.htm +PROG1 +../Body/m_prog1c.htm +PROG2 +../Body/m_prog1c.htm +PROGN +../Body/s_progn.htm +PROGRAM-ERROR +../Body/e_progra.htm +PROGV +../Body/s_progv.htm +PROVIDE +../Body/f_provid.htm +PSETF +../Body/m_setf_.htm +PSETQ +../Body/m_psetq.htm +PUSH +../Body/m_push.htm +PUSHNEW +../Body/m_pshnew.htm +QUOTE +../Body/s_quote.htm +RANDOM +../Body/f_random.htm +RANDOM-STATE +../Body/t_rnd_st.htm +RANDOM-STATE-P +../Body/f_rnd_st.htm +RASSOC +../Body/f_rassoc.htm +RASSOC-IF +../Body/f_rassoc.htm +RASSOC-IF-NOT +../Body/f_rassoc.htm +RATIO +../Body/t_ratio.htm +RATIONAL +../Body/a_ration.htm +RATIONALIZE +../Body/f_ration.htm +RATIONALP +../Body/f_rati_1.htm +READ +../Body/f_rd_rd.htm +READ-BYTE +../Body/f_rd_by.htm +READ-CHAR +../Body/f_rd_cha.htm +READ-CHAR-NO-HANG +../Body/f_rd_c_1.htm +READ-DELIMITED-LIST +../Body/f_rd_del.htm +READ-FROM-STRING +../Body/f_rd_fro.htm +READ-LINE +../Body/f_rd_lin.htm +READ-PRESERVING-WHITESPACE +../Body/f_rd_rd.htm +READ-SEQUENCE +../Body/f_rd_seq.htm +READER-ERROR +../Body/e_rder_e.htm +READTABLE +../Body/t_rdtabl.htm +READTABLE-CASE +../Body/f_rdtabl.htm +READTABLEP +../Body/f_rdta_1.htm +REAL +../Body/t_real.htm +REALP +../Body/f_realp.htm +REALPART +../Body/f_realpa.htm +REDUCE +../Body/f_reduce.htm +REINITIALIZE-INSTANCE +../Body/f_reinit.htm +REM +../Body/f_mod_r.htm +REMF +../Body/m_remf.htm +REMHASH +../Body/f_remhas.htm +REMOVE +../Body/f_rm_rm.htm +REMOVE-DUPLICATES +../Body/f_rm_dup.htm +REMOVE-IF +../Body/f_rm_rm.htm +REMOVE-IF-NOT +../Body/f_rm_rm.htm +REMOVE-METHOD +../Body/f_rm_met.htm +REMPROP +../Body/f_rempro.htm +RENAME-FILE +../Body/f_rn_fil.htm +RENAME-PACKAGE +../Body/f_rn_pkg.htm +REPLACE +../Body/f_replac.htm +REQUIRE +../Body/f_provid.htm +REST +../Body/f_rest.htm +RESTART +../Body/t_rst.htm +RESTART-BIND +../Body/m_rst_bi.htm +RESTART-CASE +../Body/m_rst_ca.htm +RESTART-NAME +../Body/f_rst_na.htm +RETURN +../Body/m_return.htm +RETURN-FROM +../Body/s_ret_fr.htm +REVAPPEND +../Body/f_revapp.htm +REVERSE +../Body/f_revers.htm +ROOM +../Body/f_room.htm +ROTATEF +../Body/m_rotate.htm +ROUND +../Body/f_floorc.htm +ROW-MAJOR-AREF +../Body/f_row_ma.htm +RPLACA +../Body/f_rplaca.htm +RPLACD +../Body/f_rplaca.htm +SAFETY +../Body/d_optimi.htm +SATISFIES +../Body/t_satisf.htm +SBIT +../Body/f_bt_sb.htm +SCALE-FLOAT +../Body/f_dec_fl.htm +SCHAR +../Body/f_char_.htm +SEARCH +../Body/f_search.htm +SECOND +../Body/f_firstc.htm +SEQUENCE +../Body/t_seq.htm +SERIOUS-CONDITION +../Body/e_seriou.htm +SET +../Body/f_set.htm +SET-DIFFERENCE +../Body/f_set_di.htm +SET-DISPATCH-MACRO-CHARACTER +../Body/f_set__1.htm +SET-EXCLUSIVE-OR +../Body/f_set_ex.htm +SET-MACRO-CHARACTER +../Body/f_set_ma.htm +SET-PPRINT-DISPATCH +../Body/f_set_pp.htm +SET-SYNTAX-FROM-CHAR +../Body/f_set_sy.htm +SETF +../Body/a_setf.htm +SETQ +../Body/s_setq.htm +SEVENTH +../Body/f_firstc.htm +SHADOW +../Body/f_shadow.htm +SHADOWING-IMPORT +../Body/f_shdw_i.htm +SHARED-INITIALIZE +../Body/f_shared.htm +SHIFTF +../Body/m_shiftf.htm +SHORT-FLOAT +../Body/t_short_.htm +SHORT-FLOAT-EPSILON +../Body/v_short_.htm +SHORT-FLOAT-NEGATIVE-EPSILON +../Body/v_short_.htm +SHORT-SITE-NAME +../Body/f_short_.htm +SIGNAL +../Body/f_signal.htm +SIGNED-BYTE +../Body/t_sgn_by.htm +SIGNUM +../Body/f_signum.htm +SIMPLE-ARRAY +../Body/t_smp_ar.htm +SIMPLE-BASE-STRING +../Body/t_smp_ba.htm +SIMPLE-BIT-VECTOR +../Body/t_smp_bt.htm +SIMPLE-BIT-VECTOR-P +../Body/f_smp_bt.htm +SIMPLE-CONDITION +../Body/e_smp_cn.htm +SIMPLE-CONDITION-FORMAT-ARGUMENTS +../Body/f_smp_cn.htm +SIMPLE-CONDITION-FORMAT-CONTROL +../Body/f_smp_cn.htm +SIMPLE-ERROR +../Body/e_smp_er.htm +SIMPLE-STRING +../Body/t_smp_st.htm +SIMPLE-STRING-P +../Body/f_smp_st.htm +SIMPLE-TYPE-ERROR +../Body/e_smp_tp.htm +SIMPLE-VECTOR +../Body/t_smp_ve.htm +SIMPLE-VECTOR-P +../Body/f_smp_ve.htm +SIMPLE-WARNING +../Body/e_smp_wa.htm +SIN +../Body/f_sin_c.htm +SINGLE-FLOAT +../Body/t_short_.htm +SINGLE-FLOAT-EPSILON +../Body/v_short_.htm +SINGLE-FLOAT-NEGATIVE-EPSILON +../Body/v_short_.htm +SINH +../Body/f_sinh_.htm +SIXTH +../Body/f_firstc.htm +SLEEP +../Body/f_sleep.htm +SLOT-BOUNDP +../Body/f_slt_bo.htm +SLOT-EXISTS-P +../Body/f_slt_ex.htm +SLOT-MAKUNBOUND +../Body/f_slt_ma.htm +SLOT-MISSING +../Body/f_slt_mi.htm +SLOT-UNBOUND +../Body/f_slt_un.htm +SLOT-VALUE +../Body/f_slt_va.htm +SOFTWARE-TYPE +../Body/f_sw_tpc.htm +SOFTWARE-VERSION +../Body/f_sw_tpc.htm +SOME +../Body/f_everyc.htm +SORT +../Body/f_sort_.htm +SPACE +../Body/d_optimi.htm +SPECIAL +../Body/d_specia.htm +SPECIAL-OPERATOR-P +../Body/f_specia.htm +SPEED +../Body/d_optimi.htm +SQRT +../Body/f_sqrt_.htm +STABLE-SORT +../Body/f_sort_.htm +STANDARD +../Body/07_ffb.htm +STANDARD-CHAR +../Body/t_std_ch.htm +STANDARD-CHAR-P +../Body/f_std_ch.htm +STANDARD-CLASS +../Body/t_std_cl.htm +STANDARD-GENERIC-FUNCTION +../Body/t_std_ge.htm +STANDARD-METHOD +../Body/t_std_me.htm +STANDARD-OBJECT +../Body/t_std_ob.htm +STEP +../Body/m_step.htm +STORAGE-CONDITION +../Body/e_storag.htm +STORE-VALUE +../Body/a_store_.htm +STREAM +../Body/t_stream.htm +STREAM-ELEMENT-TYPE +../Body/f_stm_el.htm +STREAM-ERROR +../Body/e_stm_er.htm +STREAM-ERROR-STREAM +../Body/f_stm_er.htm +STREAM-EXTERNAL-FORMAT +../Body/f_stm_ex.htm +STREAMP +../Body/f_stmp.htm +STRING +../Body/a_string.htm +STRING-CAPITALIZE +../Body/f_stg_up.htm +STRING-DOWNCASE +../Body/f_stg_up.htm +STRING-EQUAL +../Body/f_stgeq_.htm +STRING-GREATERP +../Body/f_stgeq_.htm +STRING-LEFT-TRIM +../Body/f_stg_tr.htm +STRING-LESSP +../Body/f_stgeq_.htm +STRING-NOT-EQUAL +../Body/f_stgeq_.htm +STRING-NOT-GREATERP +../Body/f_stgeq_.htm +STRING-NOT-LESSP +../Body/f_stgeq_.htm +STRING-RIGHT-TRIM +../Body/f_stg_tr.htm +STRING-STREAM +../Body/t_stg_st.htm +STRING-TRIM +../Body/f_stg_tr.htm +STRING-UPCASE +../Body/f_stg_up.htm +STRING/= +../Body/f_stgeq_.htm +STRING< +../Body/f_stgeq_.htm +STRING<= +../Body/f_stgeq_.htm +STRING= +../Body/f_stgeq_.htm +STRING> +../Body/f_stgeq_.htm +STRING>= +../Body/f_stgeq_.htm +STRINGP +../Body/f_stgp.htm +STRUCTURE +../Body/f_docume.htm +STRUCTURE-CLASS +../Body/t_stu_cl.htm +STRUCTURE-OBJECT +../Body/t_stu_ob.htm +STYLE-WARNING +../Body/e_style_.htm +SUBLIS +../Body/f_sublis.htm +SUBSEQ +../Body/f_subseq.htm +SUBSETP +../Body/f_subset.htm +SUBST +../Body/f_substc.htm +SUBST-IF +../Body/f_substc.htm +SUBST-IF-NOT +../Body/f_substc.htm +SUBSTITUTE +../Body/f_sbs_s.htm +SUBSTITUTE-IF +../Body/f_sbs_s.htm +SUBSTITUTE-IF-NOT +../Body/f_sbs_s.htm +SUBTYPEP +../Body/f_subtpp.htm +SVREF +../Body/f_svref.htm +SXHASH +../Body/f_sxhash.htm +SYMBOL +../Body/t_symbol.htm +SYMBOL-FUNCTION +../Body/f_symb_1.htm +SYMBOL-MACROLET +../Body/s_symbol.htm +SYMBOL-NAME +../Body/f_symb_2.htm +SYMBOL-PACKAGE +../Body/f_symb_3.htm +SYMBOL-PLIST +../Body/f_symb_4.htm +SYMBOL-VALUE +../Body/f_symb_5.htm +SYMBOLP +../Body/f_symbol.htm +SYNONYM-STREAM +../Body/t_syn_st.htm +SYNONYM-STREAM-SYMBOL +../Body/f_syn_st.htm +T +../Body/a_t.htm +TAGBODY +../Body/s_tagbod.htm +TAILP +../Body/f_ldiffc.htm +TAN +../Body/f_sin_c.htm +TANH +../Body/f_sinh_.htm +TENTH +../Body/f_firstc.htm +TERPRI +../Body/f_terpri.htm +THE +../Body/s_the.htm +THIRD +../Body/f_firstc.htm +THROW +../Body/s_throw.htm +TIME +../Body/m_time.htm +TRACE +../Body/m_tracec.htm +TRANSLATE-LOGICAL-PATHNAME +../Body/f_tr_log.htm +TRANSLATE-PATHNAME +../Body/f_tr_pn.htm +TREE-EQUAL +../Body/f_tree_e.htm +TRUENAME +../Body/f_tn.htm +TRUNCATE +../Body/f_floorc.htm +TWO-WAY-STREAM +../Body/t_two_wa.htm +TWO-WAY-STREAM-INPUT-STREAM +../Body/f_two_wa.htm +TWO-WAY-STREAM-OUTPUT-STREAM +../Body/f_two_wa.htm +TYPE +../Body/a_type.htm +TYPE-ERROR +../Body/e_tp_err.htm +TYPE-ERROR-DATUM +../Body/f_tp_err.htm +TYPE-ERROR-EXPECTED-TYPE +../Body/f_tp_err.htm +TYPE-OF +../Body/f_tp_of.htm +TYPECASE +../Body/m_tpcase.htm +TYPEP +../Body/f_typep.htm +UNBOUND-SLOT +../Body/e_unboun.htm +UNBOUND-SLOT-INSTANCE +../Body/f_unboun.htm +UNBOUND-VARIABLE +../Body/e_unbo_1.htm +UNDEFINED-FUNCTION +../Body/e_undefi.htm +UNEXPORT +../Body/f_unexpo.htm +UNINTERN +../Body/f_uninte.htm +UNION +../Body/f_unionc.htm +UNLESS +../Body/m_when_.htm +UNREAD-CHAR +../Body/f_unrd_c.htm +UNSIGNED-BYTE +../Body/t_unsgn_.htm +UNTRACE +../Body/m_tracec.htm +UNUSE-PACKAGE +../Body/f_unuse_.htm +UNWIND-PROTECT +../Body/s_unwind.htm +UPDATE-INSTANCE-FOR-DIFFERENT-CLASS +../Body/f_update.htm +UPDATE-INSTANCE-FOR-REDEFINED-CLASS +../Body/f_upda_1.htm +UPGRADED-ARRAY-ELEMENT-TYPE +../Body/f_upgr_1.htm +UPGRADED-COMPLEX-PART-TYPE +../Body/f_upgrad.htm +UPPER-CASE-P +../Body/f_upper_.htm +USE-PACKAGE +../Body/f_use_pk.htm +USE-VALUE +../Body/a_use_va.htm +USER-HOMEDIR-PATHNAME +../Body/f_user_h.htm +VALUES +../Body/a_values.htm +VALUES-LIST +../Body/f_vals_l.htm +VARIABLE +../Body/f_docume.htm +VECTOR +../Body/a_vector.htm +VECTOR-POP +../Body/f_vec_po.htm +VECTOR-PUSH +../Body/f_vec_ps.htm +VECTOR-PUSH-EXTEND +../Body/f_vec_ps.htm +VECTORP +../Body/f_vecp.htm +WARN +../Body/f_warn.htm +WARNING +../Body/e_warnin.htm +WHEN +../Body/m_when_.htm +WILD-PATHNAME-P +../Body/f_wild_p.htm +WITH-ACCESSORS +../Body/m_w_acce.htm +WITH-COMPILATION-UNIT +../Body/m_w_comp.htm +WITH-CONDITION-RESTARTS +../Body/m_w_cnd_.htm +WITH-HASH-TABLE-ITERATOR +../Body/m_w_hash.htm +WITH-INPUT-FROM-STRING +../Body/m_w_in_f.htm +WITH-OPEN-FILE +../Body/m_w_open.htm +WITH-OPEN-STREAM +../Body/m_w_op_1.htm +WITH-OUTPUT-TO-STRING +../Body/m_w_out_.htm +WITH-PACKAGE-ITERATOR +../Body/m_w_pkg_.htm +WITH-SIMPLE-RESTART +../Body/m_w_smp_.htm +WITH-SLOTS +../Body/m_w_slts.htm +WITH-STANDARD-IO-SYNTAX +../Body/m_w_std_.htm +WRITE +../Body/f_wr_pr.htm +WRITE-BYTE +../Body/f_wr_by.htm +WRITE-CHAR +../Body/f_wr_cha.htm +WRITE-LINE +../Body/f_wr_stg.htm +WRITE-SEQUENCE +../Body/f_wr_seq.htm +WRITE-STRING +../Body/f_wr_stg.htm +WRITE-TO-STRING +../Body/f_wr_to_.htm +Y-OR-N-P +../Body/f_y_or_n.htm +YES-OR-NO-P +../Body/f_y_or_n.htm +ZEROP +../Body/f_zerop.htm diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Data/clhs.css b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/clhs.css similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Data/clhs.css rename to clones/lisp/HyperSpec-7-0/HyperSpec/Data/clhs.css diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Data/md5.txt b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/md5.txt new file mode 100644 index 00000000..c139286d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Data/md5.txt @@ -0,0 +1,2343 @@ +a770d5614a7bded99d0d869eee1b721a ../Body/00_.htm +a29e5542885fd3218e09692982bc1598 ../Body/01_aa.htm +9d0f327926ecd424ab85abfd19809edf ../Body/01_ab.htm +4ef1c183328804390412a1fd180dd595 ../Body/01_a.htm +b50d808991230fc69b7dfc89d3dce40c ../Body/01_b.htm +22f4e9c1c5b31f7043ea975fa7ac29a6 ../Body/01_c.htm +8e49ce262c541e48c28733562cfe93d0 ../Body/01_daa.htm +4451556a36dc6654ff4fc0283df38add ../Body/01_daba.htm +a6599497bff06a0993bb8fdac39991c9 ../Body/01_dabb.htm +013d298ffa29c7943da5b43d923aa8eb ../Body/01_dabc.htm +d1c4e9f563e0572dfb866d0ebcda0e46 ../Body/01_dab.htm +e891ab7c881127a9cf25496ee8726acc ../Body/01_dac.htm +06cf507eeaf4f9e56e813cbc1d476929 ../Body/01_dada.htm +fdd21ce6ced280423272e1b2e668cfc1 ../Body/01_dadb.htm +9d8f651eb6792a9ae9e0eacb7cf27539 ../Body/01_dadc.htm +b2efd6082d387b1affe459380817da5d ../Body/01_dadd.htm +7ddd0c6fd48b3e76cb5681946f113020 ../Body/01_dad.htm +998a07f28cb59d2a04e3692a9d1fec7f ../Body/01_dae.htm +e92d0732e2b4c7021964110ee4285327 ../Body/01_daf.htm +3cc176c1f9394885e1a952b2e71a8c86 ../Body/01_da.htm +72652096a786e53ea7c2ce7389a7b021 ../Body/01_db.htm +156302086cf7d171ca827535ac20c2c3 ../Body/01_dc.htm +83444713981a369585e658d6da717996 ../Body/01_dda.htm +51c77c1525a9b9643838a5da9e153175 ../Body/01_ddb.htm +5269ed384f9bfed5fde58ed62a50f8df ../Body/01_ddc.htm +3561322568693b0c7034b38821eacb9e ../Body/01_ddd.htm +bf4f0846d95bba14576d1a64cf3d73f6 ../Body/01_dde.htm +7b99e004c88e833ca4b1962dc00d690f ../Body/01_ddfa.htm +8e2adddde0491e77c62526e3f0851207 ../Body/01_ddfb.htm +50d033a01457ca544ba45bb3dab66741 ../Body/01_ddfc.htm +4fc09b8f43e8b40b3b713829c90e938c ../Body/01_ddfd.htm +949cb265d3ba29a44b234574f3252de8 ../Body/01_ddf.htm +6500cf4604a1deee0b94b336cc628cc8 ../Body/01_ddg.htm +4d7c0afa73f11e8cc3d6b5287761cb64 ../Body/01_ddh.htm +45fb9bdbcff9dbd702e23989c1787099 ../Body/01_dd.htm +a83f1ecc63cc19a73c7a276833b8294f ../Body/01_ddi.htm +c29c5f68c34720344f6574b5f240e7ac ../Body/01_ddj.htm +e4bcaa89ffbdbc760b7982b59cce7077 ../Body/01_ddk.htm +2a5a21f7fbc25846d29c02b80b8738ff ../Body/01_ddl.htm +d22d119929567f4dcff47b2e0349ab80 ../Body/01_ddm.htm +fac1ca8a89df0283da9c441f3de552fa ../Body/01_ddn.htm +0caad001c01f0c4c8b207777514d5627 ../Body/01_ddo.htm +934fc0aa95438c74fe71d74fefb5b142 ../Body/01_ddp.htm +dac812bbb07a251e22b90ece76c9cda9 ../Body/01_ddq.htm +2bc5dfce3b76974aa9e05907d3780cf6 ../Body/01_ddr.htm +95af3c5add59cc60b2be891b23ead65c ../Body/01_dds.htm +47977b06db642565b51fef9c5e8a9fbd ../Body/01_ddta.htm +16e54f41e84cdd3a731fdf53eeeebf56 ../Body/01_ddtb.htm +ecd7430be367b3086f0e42c9266f7c53 ../Body/01_ddtc.htm +e1ec4578fac06789d7150a68cd495725 ../Body/01_ddtda.htm +f1b17b3d3ad83fe02dcefb035f9e3d27 ../Body/01_ddtdb.htm +a722ae933ea1b0d00e54090e8f43178a ../Body/01_ddtd.htm +86631f5e8ad683f2e8813c4b70d5acd6 ../Body/01_ddt.htm +5f9749f480e2b3b3978abf2d66cc167c ../Body/01_ddu.htm +2929844e724426af7f93289a5ec5a52c ../Body/01_ddv.htm +f796ef12dc7b9a32e8acf68e536446f9 ../Body/01_d.htm +3b60cafc6bbb16dd6aa27aaa56c1add7 ../Body/01_eaa.htm +a3a9250ab3a9e0ed392b847ff5ac87e5 ../Body/01_eab.htm +a6bafcc8bbfc576a57fd863d4730d788 ../Body/01_eac.htm +cc431f118216a4dba879ca0eb153dd34 ../Body/01_eadaa.htm +4f5d0a87f2e528f4182d4d4f58a7d150 ../Body/01_eada.htm +da55889b3abb64dc3d3ac47fbee75aae ../Body/01_ead.htm +fdf883d607dd01e75d8b006031bb987f ../Body/01_eae.htm +2fc4468a08c2537149c7f462ffdaa346 ../Body/01_ea.htm +59435e72fba72fcd4196cbffb3d45762 ../Body/01_ebaa.htm +e1ee66b12cc005165608714c973d55ce ../Body/01_eba.htm +cf46b8ba809ea76b45b177ee816d139c ../Body/01_ebb.htm +4501c6f0df7ef9bd43080ff6eb66778c ../Body/01_eb.htm +d7bcded267dd79da79f6066b6d96b98d ../Body/01_e.htm +c1398f268eba1e6feceeefc640e1fe5e ../Body/01_f.htm +6589f946ca0099d4682f973ae580cfa4 ../Body/01_g.htm +e25c7220d287503f444cc09cbe83ef93 ../Body/01_ha.htm +bb6815c21f8d83ae6162f22a8002aa99 ../Body/01_hb.htm +b4e6584e35717e0b2741462e9d0855a7 ../Body/01_hc.htm +c72ad268b05298c2257f14e143b105eb ../Body/01_hd.htm +6e81810b2d3fc7483b08d140f74e7068 ../Body/01_h.htm +f7f9b233ae0700058f7f924efa94a4bd ../Body/01_.htm +e4e5baa8dfe0fc21465e35fb49bd15d1 ../Body/01_i.htm +7cce5ecaea6f6cd5b1470e43cc92ef86 ../Body/02_aaa.htm +be0fb4c05a1627da7e54a8104b50e763 ../Body/02_aab.htm +559387b83f9f00f7b97b7203fb1d3875 ../Body/02_aac.htm +e8603e7ef46195f27498623b6152c922 ../Body/02_aa.htm +cdf9fdfa1b9e80cd888d45f30004a1df ../Body/02_ab.htm +d490f69bc87415ed452871b8a14bad3b ../Body/02_ac.htm +a853f44a0b32d4f08de7191f32f3d58b ../Body/02_ada.htm +1b7ba6fcaaae186e7a6b3952f160f5c2 ../Body/02_adb.htm +61729f0c03833468e5944e1b304ce7fa ../Body/02_adc.htm +4f7f061e42282800821637a079118880 ../Body/02_add.htm +b954b7896e61b8905814acbcd9f7e915 ../Body/02_adea.htm +61896eb7468f9203015447b412898781 ../Body/02_ade.htm +59b86189f38c4fb388bbea7c62532af1 ../Body/02_adfa.htm +092ab3df82c1ce30273446dd10c169e4 ../Body/02_adf.htm +626e446d0868aecb629df696009e581a ../Body/02_adga.htm +f9265e8cde0abbe0f96fcb3108187c47 ../Body/02_adg.htm +0a4d4469577afd2fd98f9be7344762d1 ../Body/02_ad.htm +819599c24ae61ae01e4ef00f61c0ad18 ../Body/02_a.htm +4b699f9a99081db4d3ce138ad05e550b ../Body/02_b.htm +37715bba9ff0726c559ffe8796cbb226 ../Body/02_caaa.htm +fedb701c7e1c12c4a9aaa73717ccc2e5 ../Body/02_caab.htm +e2ef0d4d802ca0a88608cccd61fcde59 ../Body/02_caa.htm +72a68d3a69ce67c6cd3732e2ffd65b70 ../Body/02_ca.htm +a393e3ac4ef08384e2f1989586ef4005 ../Body/02_cbaa.htm +7a6108c0a786388b2fbe2e5927f678a6 ../Body/02_cbab.htm +1dcfa44e902c3e63ae5a3c4fca2f1060 ../Body/02_cba.htm +05fa4550b48eaac98ae61ade874878b7 ../Body/02_cbb.htm +08ef149647a429299499c9bc89da54ab ../Body/02_cbc.htm +ea82cc2593ed4c284dabd308d659e42f ../Body/02_cb.htm +3aa73d90cbcd452c174f52a2b4939143 ../Body/02_cc.htm +f151fde80c1271285eab55870eefb90e ../Body/02_cd.htm +9a8159062879b4ca690d07fdc3bec0b3 ../Body/02_ce.htm +14c42fed4be48c79b8c30a8fe6fb26cd ../Body/02_cf.htm +12ef942b7f138e0f0899565eac1e3cb3 ../Body/02_c.htm +8e35a6b914aee2695fdefeb00c8abc42 ../Body/02_da.htm +ecf7513b0f6af74e1ad1f9571594e46c ../Body/02_db.htm +cb6ba4690287a5a194dac819772fe5a1 ../Body/02_dca.htm +cdff821ce7dc261008d62c84becdfe22 ../Body/02_dc.htm +a752d69b49f9654b1401cd67e5586a4b ../Body/02_dda.htm +fea5cab6580e47f965b80d05bba9887f ../Body/02_ddba.htm +2da3f705df67930c42a816f60581925b ../Body/02_ddbb.htm +1dce478751a2924979e581d21a6f4892 ../Body/02_ddbc.htm +ae55b5d7bc986036ba74b3a1c4704232 ../Body/02_ddbd.htm +33e40abbb732b3f13d73c75b1c868ebb ../Body/02_ddbe.htm +eac48c3711c098c2267fbd4ddb5cb2a3 ../Body/02_ddb.htm +7391438d1c94938f305ba820f9ef003b ../Body/02_dd.htm +b25a71dba049fb54827ab3c60c2ec143 ../Body/02_de.htm +25c488b91e0d5b0bcd0425043bcce518 ../Body/02_dfa.htm +99585c5f384a7a80f61c23135f4d08f4 ../Body/02_df.htm +6bc4e2db238808d43091d2e70d4e8ed5 ../Body/02_dg.htm +578c3298cc712aeac3200bcccb257955 ../Body/02_dha.htm +00fb4b3d636bbe6416388c66f726590f ../Body/02_dhb.htm +2f853ff879da7e8695546ae34f40ae55 ../Body/02_dhc.htm +0d8cf50c40f3bc2d6f504bb8bd715b42 ../Body/02_dhda.htm +82698ecdef6e8f7ae7408daa3815ece9 ../Body/02_dhd.htm +dba5096eb2bee15b9e8150d60b7691aa ../Body/02_dhe.htm +017e4be1d8239b9676b886648fc30274 ../Body/02_dhf.htm +d1001717446d6b7b6c5073f73d738670 ../Body/02_dhg.htm +8372bcd8e3a5320510453959f2ab30f3 ../Body/02_dhh.htm +159a557662fd0bc13f845d317679da09 ../Body/02_dh.htm +80ff5e3152cd8d74978c784d2866a9df ../Body/02_dhi.htm +57d73b0f4d1db22080bcaa8b9526a26d ../Body/02_dhj.htm +8e4417a6192054ce9cd0b6a355ecc22a ../Body/02_dhk.htm +620b152ad03ef8c2f47a457e0979eb09 ../Body/02_dhl.htm +28beb2ae3dd5738c72574c9a884cb48e ../Body/02_dhm.htm +1b914c3a654ccc47bde4102836c942c0 ../Body/02_dhn.htm +ebae799cc0b22bec3e96a39c5e90c48d ../Body/02_dho.htm +41bc9697207a172fa58166f2d3668251 ../Body/02_dhp.htm +31f5e955d16b82e19bcaecc6827368df ../Body/02_dhq.htm +2179328701305289e185ba807d213bc5 ../Body/02_dhr.htm +33d5c9b0f98056769985e5b07ad7e4ca ../Body/02_dhsa.htm +0ea3b4f1d6e181ecf51175637cacb629 ../Body/02_dhsb.htm +ace665db1b4887c96736994a6c0964b7 ../Body/02_dhs.htm +824de5ba82b04886ac9c7921e527241d ../Body/02_dht.htm +847732915c0288a8b3a2c161912985f8 ../Body/02_d.htm +f02ad67bd9e48adf00c186f007937be3 ../Body/02_dhu.htm +a32046227d59d74fe06603bed67d367f ../Body/02_dhv.htm +1e0ab422bf41b2cc97f41be7b8425e82 ../Body/02_di.htm +a322788ff4f693f2e851cf2a90025d20 ../Body/02_.htm +c837d270ddacc85bf8f446df409b2be5 ../Body/03_aaa.htm +204526d9a29cc92bbf6485954c8ced00 ../Body/03_aab.htm +d4553ca3acdf2c15e6ea841bc06ea3b1 ../Body/03_aaca.htm +8cb63bda182529277b004b826d9db9eb ../Body/03_aac.htm +2967f9253a398f84736f7bc0834eeda4 ../Body/03_aad.htm +add00db5ca41d816599748bb0e252b26 ../Body/03_aa.htm +4701d16406cfc1d289c3f2bb00e16aa0 ../Body/03_abaaa.htm +fd29b85a0a9b5b1e40cf9a8bda793fd5 ../Body/03_abaab.htm +a739649bffb96459a0786c43bc00560b ../Body/03_abaac.htm +4ef26dd9ac387e6f506e6d8d4a094db4 ../Body/03_abaad.htm +3e0e64874c0796115bc7ee5f56ba1612 ../Body/03_abaa.htm +2e76dd5eb5f18abce8ccdb474ec4cab6 ../Body/03_ababa.htm +5bb05e5cda9ea6759b443bedf918d1bb ../Body/03_ababb.htm +7a19d3d9f0559538989bfd685762f837 ../Body/03_ababc.htm +d846d0f32ffc0f2465068f46abe0ab7d ../Body/03_ababd.htm +4e5e66a711cc9d435d1399ce905512bd ../Body/03_abab.htm +d019482da0730d263bf5b9c5093d43fd ../Body/03_abaca.htm +93ceb12718e4679ef8aa56a62a20ee81 ../Body/03_abac.htm +942949d81226e8cac4d437b5c7c661c1 ../Body/03_aba.htm +20e0b6c5e81b480f205a1f0ab1f3115f ../Body/03_ab.htm +9ae8cc237ff63b928ab9bb3ca904f5df ../Body/03_ac.htm +83b42cece232ee56c4c3703244b2311d ../Body/03_ad.htm +28dd02593cf5d8867d9f5077d57e7d6f ../Body/03_ae.htm +5c0586dc98c0197a1a90f0e9bda8ef7d ../Body/03_af.htm +7273faac64396ac34fec1797bd637583 ../Body/03_ag.htm +bfd9657c390e467135a7fc8b09f45989 ../Body/03_a.htm +42ffa2c727879f9c7d97c7030bed26aa ../Body/03_ba.htm +8fa5a5caf6f1206d278804bc30501fa6 ../Body/03_bbaa.htm +efa842a1b8c1cfa7b96d76b3cec3abbf ../Body/03_bbab.htm +8c485fa2544635ea7b68982ac6c90891 ../Body/03_bbaca.htm +d21b21408ad52306fa20d36735384fa3 ../Body/03_bbac.htm +d15f93cf372581c30832f6ba7ff4c3ca ../Body/03_bba.htm +a4b31219f46045a0faba895cba4dd93f ../Body/03_bbb.htm +2c14c92c9f5737aa27228074e3d5c758 ../Body/03_bbc.htm +27c1135c593083b949bb2dd047398c28 ../Body/03_bb.htm +5655867bb7105a3fef8cfb03ddf531cb ../Body/03_bcaa.htm +1b3b48b49f885d42195fdd9bf0fd4b87 ../Body/03_bcab.htm +ba5f103e84e60f4a0df0d6c22f3044f5 ../Body/03_bca.htm +e1539577e3b6356d170f1df39cc71b7c ../Body/03_bc.htm +e9fb9758ab1083f9e6492ec082f64e98 ../Body/03_bda.htm +ee22629989c61cf9cfff19cf140382f0 ../Body/03_bdba.htm +31f6485ca8101ab81a0de40e5c985e21 ../Body/03_bdbb.htm +c037ea9884a6da3036c923ced16a4caf ../Body/03_bdb.htm +706424fe651a0014f9894d28aafbb226 ../Body/03_bdc.htm +f4c20785c416829568af6a7ac5d23090 ../Body/03_bdd.htm +5a0d0d5f9446eac81f05bd1a8361a8c3 ../Body/03_bd.htm +5825b6c8309d810bd222f119c0dd0bcb ../Body/03_be.htm +873a0c9593393504a2ef4de06b0b59dc ../Body/03_b.htm +a8db5e7ce7a7e2333f60e2369a50bed2 ../Body/03_ca.htm +e86560506d4857c33748c88206234620 ../Body/03_cb.htm +fcbacd687d73b86aaa5d7fffc432730d ../Body/03_cca.htm +7acd992635f88894e028a5b18998bdbe ../Body/03_cc.htm +566ba5544cb9f04a3a05e4898ea52f80 ../Body/03_cda.htm +6a34169882ebef989fd8deb15554c558 ../Body/03_cd.htm +63bd77533d81173b5d37c9b03077be54 ../Body/03_c.htm +eb73d14069dfc0c0498fb029d5e98f01 ../Body/03_daa.htm +935816019a19e37a5bbe2df1761c7c18 ../Body/03_dab.htm +e9c3e24ad3f0dde0f6ced320cdeff26b ../Body/03_dac.htm +a002e234e5d96d70f1a4e307ff1f42bf ../Body/03_dadaa.htm +66422f99ebb6b32f43f46c34b173f8cc ../Body/03_dada.htm +cde088a3b2d24930f30b2bb3fb8fa1f0 ../Body/03_dad.htm +68ea2298c849614bf68034f24905784b ../Body/03_dae.htm +8744e0b29edd8fb2d5b99db11ec1fc4e ../Body/03_daf.htm +44849939af553a36f91991a42f9e9ced ../Body/03_da.htm +53aa5317d6385c50862a270600cbd67b ../Body/03_db.htm +a184e48cdf0c7e09a5f1a104b79aa540 ../Body/03_dc.htm +5585f73eaeabb6b0f42722887291cbe6 ../Body/03_ddaaa.htm +d075b159611a6cd16f57536353324993 ../Body/03_ddaa.htm +856701477d882ce0cafd7c6b58a26a9d ../Body/03_ddab.htm +5add954492c2442a2effb1f368826b8c ../Body/03_dda.htm +b2a3d47e3941deb6a943d5c57d370867 ../Body/03_dd.htm +3b7393dbf492dac6945f2b981ee6c32c ../Body/03_de.htm +57d7a0206d2f44fe296132f4c5e7c687 ../Body/03_df.htm +dddefcdf025257ddbef2f07f07e79187 ../Body/03_dg.htm +d496223202aa2db1d1e2a9788be7bb55 ../Body/03_dh.htm +23821d8f129e419890eb7016e46798a4 ../Body/03_d.htm +f9986953b14a5cc1f2062958a0c33a0f ../Body/03_di.htm +b844bb2b03106f7d39fab8536c8190ec ../Body/03_dj.htm +462144d4cac3fd50fbababb11e4dd282 ../Body/03_dk.htm +1dc6f0638fae2e0ac2de24e2a165770f ../Body/03_eaaa.htm +5a5d2ef8bbbd78a987259e9c6da1b3fc ../Body/03_eaa.htm +d33082f3a411d1ff8573b39635d34525 ../Body/03_eab.htm +bd0a1df2dd704306a8c43d8f60c32378 ../Body/03_eac.htm +fa0676e5531cce78394a2e21ca093047 ../Body/03_ead.htm +9ca19323accebea4f5918e9cfdd74163 ../Body/03_eae.htm +2a50971af38ed29cb8f24419b2b5d4ce ../Body/03_eaf.htm +468815e4fa236a8c33d3ee3ce8d23d49 ../Body/03_eag.htm +bd1dcfb645c9f5bd7596c82a30f8a5ff ../Body/03_eah.htm +874998409dc8750a3c484267b01775de ../Body/03_ea.htm +12bc55f7cda62a03abd2c17df0c0f08f ../Body/03_e.htm +874547d236e3f1a432c8337a822ef523 ../Body/03_f.htm +83e88b9fa7371b7af127808ae026cab2 ../Body/03_ga.htm +b3cc543dd6c8217c0f3aae35410a56c8 ../Body/03_gba.htm +d591a323c3b0b02b6820cda46a520b25 ../Body/03_gb.htm +124af9916183cbb3eafd6e4f197bb10e ../Body/03_g.htm +f119d34443c8c6972a0a00bb4fccb752 ../Body/03_.htm +b287d7a36c8249c2c3bb1fabda579fab ../Body/04_a.htm +098aba03e2d1cb9ebef3a87c7cb72131 ../Body/04_ba.htm +cc2ecad7ef3539e18527a976dccb0301 ../Body/04_bb.htm +81b833c7bccbafd34cd728dab8d60cd6 ../Body/04_bc.htm +1f3e0123217f73c14419b0869dc639c0 ../Body/04_b.htm +36e846a548e77db2174b057eb12db932 ../Body/04_caa.htm +8f7b4d3f655e609ff50f18c9d7cf7560 ../Body/04_ca.htm +b2f7d00c2febbe35646386b53ca03e3b ../Body/04_cb.htm +e184cdff775a19645f0176635aa915d3 ../Body/04_cc.htm +73fd95c07920d62471a697802e5ca093 ../Body/04_cda.htm +765ccba1beb406888a4c19f9f3017174 ../Body/04_cdb.htm +1ae8a67e2af30201b503cf7477950fa4 ../Body/04_cd.htm +904c484f3817b52205975386793580d5 ../Body/04_cea.htm +4e6da0f09fd97f2976230658f246ea9b ../Body/04_ceb.htm +aa3c5ae0e7092cb42af6aba6e13a3f78 ../Body/04_ce.htm +5fda0d807043301618e12976fdaca869 ../Body/04_cfa.htm +a0d66fb396f00009434403e7cf8d9960 ../Body/04_cfb.htm +ea087ec9e4ca17fa0512c90591f74bb5 ../Body/04_cfc.htm +2aced34d6987f43e1baf83d73686c457 ../Body/04_cf.htm +3035f079ea3f2589dc54c25bae1744c6 ../Body/04_cg.htm +038d29a194f6471a19c15771be5ff90a ../Body/04_c.htm +6e8a2145d28bb4ab03bbef032f3f53bc ../Body/04_.htm +a3883feb20c3a19e4ea9e29412654541 ../Body/05_aaaa.htm +1f8224231cb0c95c5b66ae82569d2664 ../Body/05_aaa.htm +6125c73df5a87a311fd668d5dcdf50f6 ../Body/05_aaba.htm +8cedb3d4ba716d1a7c5353c8b08af949 ../Body/05_aab.htm +aa2322f31a6b2b679dd8e4b885d8d666 ../Body/05_aa.htm +09a6feb93b76d93afaa6e194cfe84d57 ../Body/05_aba.htm +b7499a37056be79da7d7a7bbda9b46ee ../Body/05_abb.htm +f20d6593ff84645db68c65a8a2293f8c ../Body/05_abc.htm +21d36476acaabf0754288b28a7524f45 ../Body/05_abd.htm +64493542ff62fc50d3551c73c89dbe3d ../Body/05_abe.htm +42b94d39e36d1ea912d18af215166af5 ../Body/05_abf.htm +1e48b10a20a1bde75901d0212bf10617 ../Body/05_abg.htm +018398db7697cd987e19ac60b1336fde ../Body/05_abh.htm +bdc11abd88e8ae8d2870e1d30b3091c4 ../Body/05_ab.htm +2d5bad8a08fd343851ecbbce642d21f1 ../Body/05_abi.htm +ba5f6da8f6c911ef71dbfa27e824c3af ../Body/05_ac.htm +2740f9f1244f2b5b495260079c9942ba ../Body/05_a.htm +b04da46551a1a2eb3e714a049d665597 ../Body/05_b.htm +e557fed79cf10210d505522550c26518 ../Body/05_.htm +f17ff3e5b5943b25fb3367587573403b ../Body/06_aaaa.htm +c831d7ff905174539df2aff624626dce ../Body/06_aaab.htm +ebf3d2169dc96b083a42f8230e64c370 ../Body/06_aaa.htm +85419df6662495796b339c788b1961ab ../Body/06_aab.htm +00f9eb09fa3b8c842755d1bee057ae02 ../Body/06_aac.htm +34f89cc4a1f1baf79a9a81af2944f954 ../Body/06_aad.htm +6a0896a7d679e71785e991b5f2ada6bc ../Body/06_aaea.htm +7b76682881f765da99eaaa4fd48dbf7d ../Body/06_aaeb.htm +47c76cb44eefd565f2495b577d2e0df5 ../Body/06_aaec.htm +42528c703e9e921ecb793425e90804c8 ../Body/06_aaed.htm +09cf4d832727195e5f340c55763779fb ../Body/06_aaee.htm +1e72184487a8510fa48aede83f324b21 ../Body/06_aaef.htm +ae2199ba2e7295c50481b21e4c05b591 ../Body/06_aae.htm +9145b8f95b149b6c1efbb248aee4b5ec ../Body/06_aaf.htm +cc3091c4b0156800702148c3841f65db ../Body/06_aag.htm +fa08197b0ecf1332cd4ed25358d62a1b ../Body/06_aah.htm +6d343ea1c0d81ee27c7872a406660505 ../Body/06_aa.htm +c4388adf362e0b48f94c41c40a20128d ../Body/06_abaaa.htm +5920da7a4f69de8aa9be3c6b6be203d4 ../Body/06_abaa.htm +48d4a5f3e1c965d3030b46446e4a7c0a ../Body/06_ababa.htm +f701db5cdb1b27c1b31efeecf61af735 ../Body/06_abab.htm +bee7d72935442b8eb603dd3945fd2df3 ../Body/06_abaca.htm +ba27f90c1586455696e306682c249fc5 ../Body/06_abac.htm +16a9a5bb52ee4a76d1f7bee3507d76b6 ../Body/06_abada.htm +c81c350d9d87dd791d263b6618b48431 ../Body/06_abad.htm +8c6466bbc0e13d3d9474407b82c298df ../Body/06_abaea.htm +eb2753c4e0b81701253796cfc7f11505 ../Body/06_abae.htm +2212abd553d4de9a3b22a4f05dd59d49 ../Body/06_abaf.htm +a98be93f6a6c46a4dc123f8a65efcf3b ../Body/06_abaga.htm +6d27c127b3f47adb3a1d83bc70673bfa ../Body/06_abag.htm +3037264ef8fbfcb2f49a4633727a3a99 ../Body/06_aba.htm +a19d9c3cef315493d521347c33ee4a17 ../Body/06_abba.htm +97b117ea0d2ad666cd745ce4457e786e ../Body/06_abb.htm +de93a2e032dd0d4860f6b22ff1dccadf ../Body/06_ab.htm +7eafda80185b9a74be979c584c8f232d ../Body/06_aca.htm +93b2c488433c92e253c4a8c8ee847807 ../Body/06_acb.htm +0b44545d16a2e71d2234e93fd1bf9c40 ../Body/06_acc.htm +0db90254866caae92e603e73c44da102 ../Body/06_acd.htm +27e7d7f706ba2d1d6bba2fd84ec8538c ../Body/06_ace.htm +5b5cbb9df9b778fad7d631a7eeafecec ../Body/06_ac.htm +0b8241fde9894f4bb86e412062359efd ../Body/06_ada.htm +6fdd75fc2d76ec9d8e827c5c40766f3e ../Body/06_adb.htm +34d83019a2903ebd25e199a87705edfd ../Body/06_adc.htm +1bd76f09ff844ed9028dbf760b585462 ../Body/06_ad.htm +9e38b3ec922795fee63040ff85e04f1a ../Body/06_aea.htm +aba1f90ccd823b60e0ecb36e3ffc0c72 ../Body/06_ae.htm +bd9fd77f1010a637bd81c471ed13b6ff ../Body/06_afa.htm +80f4a4b48432e0bb17f57916055f9686 ../Body/06_af.htm +7e08148f37100a2854e0f2e61ef38e3d ../Body/06_agaa.htm +29b1ead08cfcec24ed28d8fcba1195c6 ../Body/06_aga.htm +556f27bb88fc35d7a0d08c8d659ade77 ../Body/06_agb.htm +2f57017e8d9ef022d3c425f4ecbf871e ../Body/06_ag.htm +117bb79090402ee0e798dcb7373fd69b ../Body/06_aha.htm +6f9ce02b8721ad56ec59c507dad21c8a ../Body/06_ah.htm +c15f05bc5c320104683edea52435a516 ../Body/06_a.htm +59905a08889511c86813933d3b484e10 ../Body/06_ai.htm +9a14e42836a98bd33e5e38200ac8f99e ../Body/06_.htm +7c76f82c21c6b3ba5e57c3eb6f87b0d3 ../Body/07_aa.htm +03194c438a54d21ca55489178d059793 ../Body/07_ab.htm +b26113a940fa2e6607c3d68811aac92e ../Body/07_ac.htm +4a324e1c580c75d7251fc87455a05dcd ../Body/07_ad.htm +7b5d4393939ebca42764b6046f7003ba ../Body/07_ae.htm +f9896bca3c22c6cba5f47086308f5227 ../Body/07_af.htm +9d404c9f2201042609582e5e4b31d3e8 ../Body/07_ag.htm +4253be47e101d781939bad79f9eb49f2 ../Body/07_a.htm +6ad32b16055a8223022a0411934584a4 ../Body/07_ba.htm +f82c4460ad608433c0efffa5d7f78fdb ../Body/07_bb.htm +a7905d642740267229f8a7a89be26b27 ../Body/07_bc.htm +71ecf189c08b16d0f789284a1a473824 ../Body/07_b.htm +4b17f6e39fb912a4a90e54527fb0de8e ../Body/07_ca.htm +9188edbff3de373fe44552464f90eb31 ../Body/07_c.htm +59e1f8ad50a963af4c68b418c558bebb ../Body/07_da.htm +e31c6f5040f97bbcdf4e0cf96b55fb91 ../Body/07_d.htm +53e324a31abf05dcc55e6fdcd1a850c9 ../Body/07_ea.htm +795dce3515e7d0ac6c39cc1bc488d619 ../Body/07_eb.htm +abd1840c75332ced4382b09214526e4d ../Body/07_ec.htm +61a79aea6346d02620c3ed5cba3bc549 ../Body/07_e.htm +7cb3446d7e4af51198df586130df7686 ../Body/07_fa.htm +109c7ec0345023299156a552e9f76280 ../Body/07_fb.htm +0552eabf5208305e5fcb4b545a16f75f ../Body/07_fc.htm +b5896ea3216186471eefb5dac4466294 ../Body/07_fd.htm +d5f8fbd1679bf6576593f157d720b1cc ../Body/07_fea.htm +011e750faeb6318ecfb0940d7006edc3 ../Body/07_fe.htm +2c51abc061cfb215a7ed636032a89690 ../Body/07_ffaa.htm +34838546271467509871389a559e3edb ../Body/07_ffab.htm +3bf6737b560524ed362e00772520452a ../Body/07_ffac.htm +39a78fdce02e8347960d87ea0171822b ../Body/07_ffa.htm +63ba1727c950ec3e65e7c47a6107d418 ../Body/07_ffb.htm +29877af9b60d86641bfcf5d03fe04e46 ../Body/07_ffc.htm +4896235ff463e72fd25010fbb0de969f ../Body/07_ffd.htm +ce056696df245b152cc450a904dd77cf ../Body/07_ff.htm +0b0e751497e34fc7b3d18da25f060c7c ../Body/07_fg.htm +d095e40e6cb17a956d62ae5caf9d4e27 ../Body/07_f.htm +fa3194fdd7a2953f5bf22d9867506b41 ../Body/07_.htm +52bf4ac7609494f690416b58730511ca ../Body/08_.htm +4b1a8af927b9a5b9715016f0c5abc013 ../Body/09_aaa.htm +a3827e9a9c8b9e89e8625e218a752ab2 ../Body/09_aa.htm +64224569c3492699083e36b8d1957d60 ../Body/09_aba.htm +f2c1a9085893d36ef880b2090a4f3744 ../Body/09_ab.htm +32e15587d4458e9304ae4cd2d53b180d ../Body/09_acaa.htm +01aaf956f44da581921766d782a04368 ../Body/09_acab.htm +8670940823fa10e22523ca59ba4ec865 ../Body/09_acac.htm +4fcf5c57e44b299d6c6bff583fdaff1c ../Body/09_acad.htm +3f998f86a57b965954b5ca2663c82bbb ../Body/09_acae.htm +d1aa7702768094274202a44724115ee7 ../Body/09_aca.htm +e18556ec66ad2887b8505e756bb265d9 ../Body/09_ac.htm +59278439ff6b5a20ddf4d57ba852ea6b ../Body/09_adaa.htm +84113d7c9f5e505a77f6f15b3da42c1e ../Body/09_ada.htm +c1215a30b52dc289526d502bd5f5c107 ../Body/09_adba.htm +9291127966505d27104088c58a529ec9 ../Body/09_adbb.htm +06ee85cdc6630bdfd3a4468a050cdbab ../Body/09_adbc.htm +bbb18bacc71a05c57ce9924b47518827 ../Body/09_adbd.htm +bd2a5f9f7d8c89da2d4cff0da338dea0 ../Body/09_adb.htm +3739db1c6a70bf070848b155ddb5ca0c ../Body/09_ad.htm +53b5f69cde5553459ec07237304154c8 ../Body/09_ae.htm +7b02ec6e97a30da2067186fd687b7047 ../Body/09_af.htm +e76dfc2e3419f454c0f557659cb32cdd ../Body/09_a.htm +4edaaf4659807d33a3f4a92a8c72004f ../Body/09_.htm +22a3f5f5d506317830f2ce0d51c022c2 ../Body/10_a.htm +a584d570e3f082bb95c956d8eec16017 ../Body/10_.htm +e8d135c9fc883097ac1292622e9634e4 ../Body/11_aaa.htm +9bb17a37650887005dce620d0d95d59e ../Body/11_aaba.htm +466c85ae095df46f55fc3e58fffb7255 ../Body/11_aabb.htm +6d6c656a9da68b65e2591b87ac6a0922 ../Body/11_aabc.htm +7e4a2210c47e4d3ed197bf5d5dfa7ae1 ../Body/11_aabd.htm +a78db88b4488a96c14e1f93b790fecb1 ../Body/11_aabe.htm +ecf9de0606c5dc6a073c86b1d29c9a42 ../Body/11_aab.htm +560a47010253728f67935a663a2bc246 ../Body/11_aa.htm +51fab6d7bfcb248c85886a6ec273b4d0 ../Body/11_abaa.htm +929918a95789674c313c3337d1542407 ../Body/11_ababa.htm +783dabd9a0e6826dcafaeeb4e6107b53 ../Body/11_abab.htm +20835a6b420ea5691c6bbf047a753f9f ../Body/11_aba.htm +75b1f8b067f9d23c213c143e82af1f58 ../Body/11_abb.htm +d801fb9ae3869e99d8578feedbd501df ../Body/11_abca.htm +12fbee326681d965537909f0e5877f83 ../Body/11_abcb.htm +29cae9e00c854ca07754af987ed63936 ../Body/11_abc.htm +b5c5a57b69528bf923dc075d27592650 ../Body/11_abd.htm +6a704a5f799312ba9d6da8708630b501 ../Body/11_ab.htm +26d2c328ddb2813616f17514e6351132 ../Body/11_a.htm +1db55a1ae5208e2755872ef9fcfbc0a8 ../Body/11_.htm +bd34d8d20bbdba4fd5ce28adee8abea6 ../Body/12_aaaa.htm +1fdad73ea446b8424776ca7ab4e05f10 ../Body/12_aaa.htm +282ba68bf816f7c789ab68facf265bde ../Body/12_aab.htm +71800cc2cfcc413a5f6f44ce9f31747f ../Body/12_aaca.htm +1836ab28ff0c00b3743792ef296074f3 ../Body/12_aacb.htm +a4ffd700bcc826c38376b53398b1e1ac ../Body/12_aac.htm +13646db02c8a8c044f78ef4f87bda6ea ../Body/12_aa.htm +bf99cad6be7fbb551a1031962bd3151a ../Body/12_ab.htm +f0372709d50de0be4fb59e90c8315c3b ../Body/12_aca.htm +82deb84685dd15bebd1bcd76e1150c8c ../Body/12_acb.htm +296ad9462f224cc0677abb0bbac88722 ../Body/12_acc.htm +02462ba9cbda05bd33289407b1e8e6b6 ../Body/12_ac.htm +3c2bb7378e3ae0c554fe9a34edb5d950 ../Body/12_adaa.htm +401d53f340376bda137778ac2d0caffc ../Body/12_ada.htm +528eebf4250d1c7f2aaf168b30ba98a5 ../Body/12_adb.htm +a40c49f4defd419dce0e71ae8352ec40 ../Body/12_adc.htm +74fe461d94706bbf17cd3aaf63e5df10 ../Body/12_add.htm +fbec713ad995fc1a07e896f789654263 ../Body/12_ad.htm +8e53acec179e9308c981edc87cfed1fd ../Body/12_aea.htm +369e9ee716090107fe7df5731b54e377 ../Body/12_aeb.htm +42a5d8db567ff129b84f2b3c22f98aef ../Body/12_aeca.htm +cea9f5dd79ef14c72eefbae802640591 ../Body/12_aec.htm +43f25cbe8c838ab9bb2a1f4c5946b888 ../Body/12_aed.htm +6a7e3e340d7d8b5e825c73266a4b8bc9 ../Body/12_ae.htm +6c3f9b6189359ba7c67e0c927c66fb07 ../Body/12_af.htm +216c14e1a5eead5138b1b87484056d1e ../Body/12_ag.htm +1df193f84226e012ccc59646a682de15 ../Body/12_a.htm +912ac3b32fc43096b0c22aeb42104b3a ../Body/12_.htm +85dfd9865e5e985ac58bf7ab2bdc081a ../Body/13_aa.htm +21f1f0a4623595675661e690e4b20662 ../Body/13_aba.htm +66d3e82db08613fba9526b3b2748cee9 ../Body/13_abb.htm +9e8311744e614732dc9aa6fdbc325896 ../Body/13_ab.htm +a27712564602302b59f73a19670a3bec ../Body/13_ac.htm +1969c7807eec792b294be1bc1135653c ../Body/13_ada.htm +49fb6f2863c54b7f8eebd2d2152a06e5 ../Body/13_adb.htm +8203b35304686c976245f9a2d8e0b0e6 ../Body/13_adca.htm +ad1d137da726afb7abb560d28ccd012b ../Body/13_adcb.htm +ecf0b6e093841a1339a2f9935741b79e ../Body/13_adcc.htm +4dc7a997535289fc82ca45d0d0d017bd ../Body/13_adcd.htm +909f2ee6ddfb86b1e69a53fac4b28b17 ../Body/13_adc.htm +2b635eb0178264a39176df8167891059 ../Body/13_add.htm +585dc812ecd4eb96cbbc751c8f923dbd ../Body/13_ade.htm +68bcdfa7d0f94aaac4ba37231a3e9f01 ../Body/13_adf.htm +e02cef2b73b26b501d7f28ecb170a480 ../Body/13_ad.htm +44591de10fcdd0f7f5093bc9d31c1e73 ../Body/13_ae.htm +7a5689edcc21eba23f2eee7868dd1370 ../Body/13_af.htm +12a9bc1151dc75425603458fe21d53dd ../Body/13_ag.htm +8279b8537e5d7225f0542387d788d0b9 ../Body/13_ah.htm +671c4759cd68e2638aecb7fd9d42fd18 ../Body/13_a.htm +b6cab3c0deea9c70c9f5909218e744ad ../Body/13_ai.htm +94edd1cbba227ca8e2197ab7ec922bd3 ../Body/13_aj.htm +6b53fe39ac27fe67966ffe4c0d3c4648 ../Body/13_.htm +8d139f7c51c0988e65fdd5a51422c8a8 ../Body/14_aaa.htm +b2184326cbeb1a9a5e14656bc2b6e8c0 ../Body/14_aa.htm +753ef2d0cabce864741e8917708ef9ea ../Body/14_aba.htm +a31f26d2a31e53443cc4c40c269208b2 ../Body/14_abb.htm +1a1895e2c540d7915a13fa0556f3ebd6 ../Body/14_abc.htm +bc6b7fac5d4e15ebc09bb511e93382e8 ../Body/14_ab.htm +7fc45c403294baadcb23d0fc97a20e93 ../Body/14_a.htm +2d9262cefb54d13a2c518e94a9f2c8d3 ../Body/14_.htm +6bd32b7ca45b0b5ad4d10dba7d0eac2a ../Body/15_aaa.htm +5ff5590fc81146eb65b3697d960cb76f ../Body/15_aaba.htm +8315c462d8b7a92323e768045e8b0ae4 ../Body/15_aab.htm +37cccbae25dd853298f6b7dd70e7b3f8 ../Body/15_aacaa.htm +ced14febbf2de978cc1f587f47844b1b ../Body/15_aaca.htm +f39da4d9edb4225e8a2d7e99f9bae805 ../Body/15_aacba.htm +8f9e0562a74df12841d9a39cb8540d81 ../Body/15_aacbb.htm +09c7e55b765d2663c8fe6a6185582d92 ../Body/15_aacb.htm +de87cb64b5b4066674cdda2ce514c0d1 ../Body/15_aac.htm +0a332adfce69e03b1263cc560e518a01 ../Body/15_aa.htm +cf8eb22d5bd5a02af26f07a7ceb97ab4 ../Body/15_aba.htm +972f012430f5a2e3dc042d7523d2a48a ../Body/15_abb.htm +3ae94eb3206304dedadd78546e0063f8 ../Body/15_ab.htm +6dfeaa85535a6e1b916a92743bb2ddf5 ../Body/15_a.htm +ae97e73d1ab8e99be679ff74a1638f15 ../Body/15_.htm +c337af5f0352407a7707094b8b6ce914 ../Body/16_aa.htm +4c745a872724aadd1e944c43645cdc5c ../Body/16_ab.htm +0c801d9d16193a023f897faf58de6d9d ../Body/16_a.htm +eab43e71071871fd241cdda7fb08568b ../Body/16_.htm +60b84e8f1aa4e28bd5a5eb61cc02bee7 ../Body/17_aa.htm +00265c02c56216c3d211a385e312b0dd ../Body/17_a.htm +3317d32b82e466a59a467960cf6f446e ../Body/17_baa.htm +7014d1917317ca99d6fddd54da8eaf58 ../Body/17_ba.htm +941f0c76d79f4be92b86c98ab5e6447d ../Body/17_bba.htm +090cb8486f514df28e994f750688d8ae ../Body/17_bb.htm +19549dc9c2bf0219d763eebf06e9bb97 ../Body/17_b.htm +ff2d369da28683b0dcb9d954ce10cacf ../Body/17_.htm +3a4a88f8dbf9ac34b6e40d7b5d56f667 ../Body/18_aa.htm +30a6b7a5d676cf4f899a579560754cbc ../Body/18_aba.htm +35b4339a6752e9195495653898769413 ../Body/18_abba.htm +762ff1e962bb42d1895a15c7a3785e5b ../Body/18_abbb.htm +283749362a0ad2d179921dc7253e76f3 ../Body/18_abb.htm +3e61d7c27e67fe760df5b72cc478ee21 ../Body/18_abca.htm +365074f91da9a05c982e018943f79f3d ../Body/18_abcb.htm +dd726cfa8b05c3b7e1e4794305a3d4be ../Body/18_abcc.htm +cd627f76aca773c1953ef51d04f30c85 ../Body/18_abc.htm +4d62ebbc6350c4a5d7e7728fe0a7e93e ../Body/18_abd.htm +be6d3b0ab96a007a650bd6bdd4c69007 ../Body/18_ab.htm +2181291fdab1c25e9bd8e65117cb1bd1 ../Body/18_a.htm +31265ec89a653366b325124ff3654112 ../Body/18_.htm +826ee4291813b95b5b58519bc3475125 ../Body/19_aa.htm +b881f0e2b355b361a3dec8d82521f482 ../Body/19_ab.htm +9ba2c95002cbf48457f949d6eaaf0721 ../Body/19_ac.htm +86df79b217c40000ff4f2b8d7046c716 ../Body/19_a.htm +13d60b3d940f89b713063f30576766c1 ../Body/19_baa.htm +81502a03a30db64089a2af08f7a8c8a8 ../Body/19_bab.htm +1987a509a3db3dc88bb45cf434271664 ../Body/19_bac.htm +6e82089aa9d93054bfd9c448a29b4a3b ../Body/19_bad.htm +1ac92bbace83ca1166d4604720d9a70e ../Body/19_bae.htm +cab1058066ac8f205bdf4c82b39a39f1 ../Body/19_baf.htm +f726d5308738397535079d2ec470bba3 ../Body/19_ba.htm +774262af0fb5acb5a953482de9805c51 ../Body/19_bbaa.htm +75d5fdb3a10b29adf3fb81a60bdcb67c ../Body/19_bbaba.htm +ad6050be4d3c9fe87dcb62d6f936fddc ../Body/19_bbabb.htm +f26bdd4f590000e5e95bc4327877684e ../Body/19_bbab.htm +275c61d994357fe2d7151b1b542b3a90 ../Body/19_bba.htm +3fc9fd52554ce22111c2b71283369516 ../Body/19_bbba.htm +e0d0a49025bba880c387761d9064a4bb ../Body/19_bbbb.htm +abcb394f2d9eb8a9331068c82d4d256f ../Body/19_bbbca.htm +7ceeda44462694528bf0a170c49767a3 ../Body/19_bbbc.htm +a1e09222e2bfc58742223571aaba85f4 ../Body/19_bbb.htm +72864a8908b1a027e5dec8b527923dfe ../Body/19_bbc.htm +32157c115c885f1f806be2d381320513 ../Body/19_bbda.htm +f21e16500e14a144792c0ce13d3cb3d0 ../Body/19_bbdb.htm +82f61674afdc9f076420b749b151b46b ../Body/19_bbdca.htm +1483171f2185b075d7eb7bc38dfaa66d ../Body/19_bbdc.htm +14dafe633d2e2d2f538466790b278b6e ../Body/19_bbdd.htm +9edf79877d7266d0cb3f479b9e343da2 ../Body/19_bbde.htm +9af4fd768b6bcf6a0f08d1e65c6bafd6 ../Body/19_bbdf.htm +ee64335e8f2772ceb91a28f217040fbd ../Body/19_bbdg.htm +6eb0f116e3dadc0bb6b45b473f33d5d8 ../Body/19_bbd.htm +b6049fee5e63fb4c3890f977f069ffa8 ../Body/19_bbe.htm +b320da994a59168f1a24023f4275afed ../Body/19_bb.htm +75dc8c30b65830c4b97dca4d3070517e ../Body/19_bca.htm +5285edc49a1bbcca8b48280692af6e77 ../Body/19_bc.htm +4f9e59954dc8fa79488a7ad97c9127d6 ../Body/19_b.htm +5b973d59705289b58f5c18f4e948ca0b ../Body/19_caaa.htm +9777f2809183ddac2dbce4a6148ccf50 ../Body/19_caab.htm +3aa705930284e09844be2668d9202dc4 ../Body/19_caac.htm +55f11d765ed9f46f0c2493cabdc1f771 ../Body/19_caad.htm +aa6ca3b4f05808697792b8b11eb9891b ../Body/19_caae.htm +b539b4d57dbcffee4a3288458326f3b7 ../Body/19_caaf.htm +e86c2e414a31a4ecb3f8ae5ad0896f82 ../Body/19_caag.htm +4f52ed4203c3cbcc312584921435e16b ../Body/19_caah.htm +b130181ae6dd4d334a519aca7b3ebae5 ../Body/19_caa.htm +1167a95a5e986feec049dd39858b298c ../Body/19_ca.htm +7e307cdeda4f6bcd730f1b6a1f7ce922 ../Body/19_cba.htm +9223dd1efbfdcf6bb758f16f5a6cce24 ../Body/19_cbb.htm +8c094a57f92a338d246a242e32272f21 ../Body/19_cb.htm +f1af15689ffd87699df871f0e8f7fcf5 ../Body/19_c.htm +aae96f10bbac3e2bc59c187b1d272241 ../Body/19_.htm +900ac16a9e1110b2a3b6bd13e6ac71af ../Body/20_aa.htm +15cebc1d4cea437e697672e9376fd809 ../Body/20_ab.htm +b765a20ebef369c3ea0110f982dbfd41 ../Body/20_aca.htm +6876a3cc1f33596b6d6348fb19f676c4 ../Body/20_ac.htm +b3bb2276161bbdd27cc52e391a985eb4 ../Body/20_a.htm +05e20a8c6ee8defd2c4be29f6060016a ../Body/20_.htm +8f4ea0be4b49886a5ebca431f729d8d7 ../Body/21_aaaa.htm +d4502614a7ef01aa16bc138e5601b456 ../Body/21_aaab.htm +4d1fea393f8a165e54716c56769eb266 ../Body/21_aaac.htm +2206d760822f0abde436e18cc581d1d5 ../Body/21_aaa.htm +5d53eca66c7d066d33a2b233d8d0b671 ../Body/21_aaba.htm +316a1f821c356b299deb96e49ec00ba8 ../Body/21_aab.htm +dc31054bf019269dae5e80db6d5078df ../Body/21_aac.htm +1c11c2f396f5728974936ba8ee09fc65 ../Body/21_aa.htm +f80e31d0d6ec80cddfb991488ba0a75a ../Body/21_ab.htm +6318ee8723050f892e333f7515c0199d ../Body/21_ac.htm +00bc80eeb2db12d524cd1a92462abf26 ../Body/21_ad.htm +7b905d73ff4c6dab03e5e23f7154d51e ../Body/21_a.htm +434416f26c98a09112503765d1d00d86 ../Body/21_.htm +f16580d64ced8e1ea2ae3129433667c4 ../Body/22_aaaa.htm +90e9ada59567a06f20a515d65de7cac9 ../Body/22_aaa.htm +296e00a6de179f0bfaaa07f23815b871 ../Body/22_aa.htm +22d79196b311c50ca3f4f43f5fb63490 ../Body/22_ab.htm +f3aacdb57aa0a15a8ef283bdb3056b15 ../Body/22_acaa.htm +abe4d101613a5adc3afd4ad4597ef80c ../Body/22_acab.htm +6f0689ec9f44f50affbb865c3903f8f6 ../Body/22_acac.htm +bbb379a269b28ac53449d9318c20348e ../Body/22_acad.htm +38c1ed8bef7160b3211ceb5b8a350905 ../Body/22_acae.htm +c1aac6721158e38aae43c4ad07585efb ../Body/22_aca.htm +45e96f976a3eb9a99a7fba7a0cb58383 ../Body/22_acb.htm +264e428c267efd28a67cc3effd63e40c ../Body/22_acca.htm +5a3d040f273bafe42617fee4341c14b7 ../Body/22_accba.htm +bfb6cd162679bc74dcd59dffd7405878 ../Body/22_accb.htm +8cb6f7007263f9dd9961628fbef3225a ../Body/22_acc.htm +2d8a0f401171f51ad36e8d315a0f9c3a ../Body/22_acd.htm +072556869be785a6eb748fe6772e6835 ../Body/22_ace.htm +13e32620000e58a6d1f39bd21250f3c0 ../Body/22_acf.htm +f909d4a678508986ed916d552396b92f ../Body/22_acg.htm +6f26dc17622885a036af211611c39d3b ../Body/22_ach.htm +c8da35a22d95268b1d511c9ea660ca6b ../Body/22_ac.htm +54a7de982105b1913a172a017885a5c7 ../Body/22_aci.htm +90910cacdba4f47642545018d5790ac8 ../Body/22_acj.htm +fdec5906b038be575ccf6be9cc9558a8 ../Body/22_ack.htm +7594746bf61320de86d85d387b1a85fb ../Body/22_acl.htm +07eb3334524e974ac936bf4ad9ca0417 ../Body/22_acm.htm +dbd13763ade1c1fd55f7eb064387a937 ../Body/22_ad.htm +f81009e7d82d7a4f17f5a811a267a0c1 ../Body/22_a.htm +ea6b40dbe232375e00b8efb3f5cb4425 ../Body/22_baa.htm +42e2d70c677b80d6d11abe9785d43091 ../Body/22_bab.htm +ddda1fee92ce165960d19964cf76384d ../Body/22_bac.htm +b9c9d414b2abd14871c07873fde8c583 ../Body/22_bad.htm +c6776800092ab8cafd016a9ded99340e ../Body/22_bae.htm +53119c1c607a5a17be05d8147ad7d0b9 ../Body/22_ba.htm +cce9947a268afef4b56d37118da79970 ../Body/22_bb.htm +1273bc715c118e0fa5cda89e5edde478 ../Body/22_bc.htm +469da2e78c6e9e014f6f10310af7cd5b ../Body/22_b.htm +9df4be358d199dcd86adb23e8b270baa ../Body/22_caa.htm +f17ebaeb4b5d768cda73dfdca8382373 ../Body/22_cab.htm +daad26fd7de3997fb5df0aadf9fefa16 ../Body/22_cac.htm +86fe51c095c3b57daaebb70321a1c4e6 ../Body/22_cad.htm +f66a1573ad3597cb28fade6e0f842053 ../Body/22_cae.htm +fa7f06fc58108d04f47797d2e6a68612 ../Body/22_ca.htm +15b6df49dda3cbb055478baaf430fb42 ../Body/22_cba.htm +bb267348bd85079e95facd9c08159897 ../Body/22_cbb.htm +8021d845043e43010febd23da9ef975b ../Body/22_cbc.htm +b189595e7cc805b13c1a8096e8827aee ../Body/22_cbd.htm +d1905078b0137e1e254222de3e344d2d ../Body/22_cbe.htm +55cc561de1f58b45c51562155668a0c9 ../Body/22_cb.htm +e1eb5dc6a50faf23c379d588f5b76de1 ../Body/22_cca.htm +4a48f564ecdcc21d06d7b7cd2639cfae ../Body/22_ccb.htm +3f1981912dec5e63af4feef613e9853d ../Body/22_ccc.htm +81c1d21b90f0e2d1b2f2838a86905a47 ../Body/22_ccd.htm +4b82f4333a1cdadf71642955af95c660 ../Body/22_cc.htm +2ec3cdb126270804efff18fc70a82c0c ../Body/22_cda.htm +d0875b2689acdd8a1b3e20589208455e ../Body/22_cdb.htm +cfe5bceba25e69889be4baddc2c50fa5 ../Body/22_cdc.htm +16cdbd9828db5e3221be0de165e8e88f ../Body/22_cd.htm +fc12314518f5ee27adcc7094b9d0ee8a ../Body/22_cea.htm +a7cafb29a31a61630d3ee007893c891e ../Body/22_ceb.htm +dc957e96946a12fd1efe7bd62d9aa620 ../Body/22_cec.htm +0f71e1b12acce99c993135d7a96ebc50 ../Body/22_ced.htm +ac6dacbd3faff8fdfc673e68bce5bb0d ../Body/22_ce.htm +9be4071747af54e64de4f83a9ae1a89d ../Body/22_cfa.htm +cff7af3a792a4e1cb909225a8c3feac5 ../Body/22_cfb.htm +afea8bd4af4426e0b8dac1bf7a136bee ../Body/22_cfc.htm +d9db36558408794e170432a9b2a95336 ../Body/22_cf.htm +f7d0cb3179c68d9dd3c4665dc3a9a6bb ../Body/22_cga.htm +fca9b0631b93b672aaddc68fa0e4c82b ../Body/22_cgb.htm +c55cb96e57b1cdf027bd077a5c30ffd7 ../Body/22_cgc.htm +52bea580bae46dd71c940098a7d6be7e ../Body/22_cgd.htm +a795cb43a1b0044bf949978df15456df ../Body/22_cge.htm +04f8d60a456c48714fe3ac9f9a34a695 ../Body/22_cgf.htm +67a8c841ae12bf7d7c135e101c3fd730 ../Body/22_cg.htm +870c0976d113731fdf83a1b6ebb62d98 ../Body/22_cha.htm +5d8d5275a3a6dd788dd5a6544c510f0a ../Body/22_chb.htm +ffd7fcbdad2133e15d2c5efa59cf4634 ../Body/22_chc.htm +ab1ef530740d38c2fa81a3573bb926cb ../Body/22_ch.htm +8bb2c5480f4baa35b907708bde847eea ../Body/22_c.htm +7323a16a344262166fde76c126b01b82 ../Body/22_cia.htm +e79b76e176a143718dbfa2bf795bb810 ../Body/22_cib.htm +b9e96e4bb72d91858e0d4608ebf8701b ../Body/22_cic.htm +246ab8985ade43bb53ee60311fd68a86 ../Body/22_ci.htm +f46e54ca6aaea319c79caa088a44d251 ../Body/22_cja.htm +c747f3292cb585a881d70eaf0e28bef1 ../Body/22_cjb.htm +1550d59092671b66cbb993891be25b56 ../Body/22_cjc.htm +6a77472db4fea4ed510f84d81427d80b ../Body/22_cjd.htm +a46793c923e9dcd16ac126c8e388159a ../Body/22_cj.htm +3e257d7079233d5ac384201bfea04a80 ../Body/22_ck.htm +a87c0e728cff6d4b63e4b6d59a8bb3bf ../Body/22_cl.htm +d165fb4f2dda05635a7bb35bb2665800 ../Body/22_.htm +c9a41d6ecd50b83f31ac22260f3d202b ../Body/23_aa.htm +7835d06387cb02832e7e3367fde70860 ../Body/23_aba.htm +61c237f49395aaad3aa1efb3cfeb0c0e ../Body/23_ab.htm +9f38ad7dd971caf843c58b54a5775ff5 ../Body/23_aca.htm +180a67e6238676e48810c0fef8661cfc ../Body/23_acb.htm +3b568b83c69852e87292df8a4d7c4178 ../Body/23_ac.htm +62a2831b84fc6daf5971a4709ad88d8c ../Body/23_a.htm +244a1f9691002031fcdef1cfe8ebfb54 ../Body/23_.htm +9432a5f69e03f683d91b65ff47ddbf9b ../Body/24_aa.htm +13e3e2714c611e5755cdb394bf45c437 ../Body/24_abaa.htm +5527c13aa9df25dad2e46c435214aead ../Body/24_aba.htm +8c16597133dabab7df4f6347c0c6afd3 ../Body/24_ab.htm +4721ae0a18da13013bb4ed84bb3e6299 ../Body/24_a.htm +9d7ce53da21e98672bd1e6119439a6bd ../Body/24_.htm +6faff17abc2cfda22f7f4b2e2f6aa186 ../Body/25_aa.htm +9f13a26bb997d3b74918ecaac3c49920 ../Body/25_ab.htm +14d332db43a222ff89ce87ab1fe65166 ../Body/25_ac.htm +fa2402ed43386e2b5eca29d289a1745b ../Body/25_ada.htm +bd973a749edf69eeb3d88cd8d2f48c1f ../Body/25_adb.htm +ce06e71b7102f516b38085a4791788a7 ../Body/25_adc.htm +4b26fef00d79bf5ca32ec557b8625879 ../Body/25_add.htm +bf8f1542f86081854958b7d836bbc44a ../Body/25_ad.htm +e07d8f0bcc114733847a81bdf15a0458 ../Body/25_a.htm +457ec81d88090536062f73d6f811b3b6 ../Body/25_.htm +dccdc32ce578381493e5e5526ba2459b ../Body/26_a.htm +99cde4f09c810b9bb6585fd1f258773f ../Body/26_glo_9.htm +687c78495c6c01df4eed75ce0750d8ae ../Body/26_glo_a.htm +84d8fd68750adaa575b98809a8c19359 ../Body/26_glo_b.htm +42e4efd72ec8157ca007978bbefdf351 ../Body/26_glo_c.htm +3c0180ad275010ad014f2e3faa7e5871 ../Body/26_glo_d.htm +26e277a939ac5237603c1e5cb97b4bde ../Body/26_glo_e.htm +70b3b4f09f405aeccffb123ef086ff5d ../Body/26_glo_f.htm +b887caa6785e3d310e25fdd06e9c809b ../Body/26_glo_g.htm +053f51f98f461a4eda6cff86e796ae8b ../Body/26_glo_h.htm +28e277c3a662264e474c01ebbe4cc9ae ../Body/26_glo_i.htm +d7ff01506339637df7cec0999c87e7d6 ../Body/26_glo_k.htm +86971256dc86be11e1026c983c35c021 ../Body/26_glo_l.htm +b524a8955b8512d037d0b3f34250f7c4 ../Body/26_glo_m.htm +c81e8c99d5f29c3602d3d4f2eca97548 ../Body/26_glo_n.htm +2a4ac3225dec5e287bb600aa228f18d4 ../Body/26_glo_o.htm +4393fcfd06f46fdf62cca3583206e6ba ../Body/26_glo_p.htm +fd6f04cd71e138dc3ef5d63e1af2f48d ../Body/26_glo_q.htm +2341ffd968cc4b95185d8d8ce1fcbc91 ../Body/26_glo_r.htm +9dad134ff0ab0289db0528a12a73154d ../Body/26_glo_s.htm +dfbba3bfd8cd6e261c8a89a036f41ac6 ../Body/26_glo_t.htm +e76f77f6446c435ab865792d62aed682 ../Body/26_glo_u.htm +899106f84035fc73d52a837a80c7ad9d ../Body/26_glo_v.htm +62f8d01782ca696afb1284180231e44c ../Body/26_glo_w.htm +0b57c1449a16d075f6efba989b01709b ../Body/26_glo_y.htm +db1b1b1fb04bf16c7c898317ae379aac ../Body/26_.htm +1f22c7182af7ecb933f82cb6731262e3 ../Body/27_aa.htm +59839e1dd6b4c6c0c39937c783e82ad5 ../Body/27_ab.htm +7aa9dabde66fd40fd2fa985011434235 ../Body/27_ac.htm +ec14539cba8e011ed3c3796527e6093f ../Body/27_ad.htm +ff5ca8b6b688f5a4ea09790bf9383707 ../Body/27_ae.htm +6ed6a85c37e43336b7a40385b8186a28 ../Body/27_af.htm +4a754ebf576d6c967c78c4a2a41a72ce ../Body/27_ag.htm +b1eba621c24d2bbd302a5df0bff1243a ../Body/27_a.htm +7a97cfedf3557f135e95de375cafd5ec ../Body/27_.htm +7bd03574518f52a0135880427a459497 ../Body/a_abort.htm +c180a39b44aadc0c9377492797876833 ../Body/a_and.htm +c6bf88e76b60cec6529d8b444e56c42f ../Body/a_atom.htm +f743522db536af266d4ee7518008d4ba ../Body/a_bit.htm +364b2b1f0336226c1c6bb05e18e0a8cf ../Body/a_ch.htm +1c859f8c9c64a83eba1f67905a265235 ../Body/a_comple.htm +dbb1948d53e18b39b479ffec1aff77d7 ../Body/a_cons.htm +b1b996a1badfe76514af3529cf6eb5d8 ../Body/a_contin.htm +ccd96ab76e095d5d48a3421e62689539 ../Body/a_eql.htm +60462a4a2c33914aa2f8b95bb693bb5e ../Body/a_error.htm +98f4e9dcd1e65e4d6c3e65719d36e219 ../Body/a_float.htm +f0e9f85cebdc03c95d8ec7dcda54f6cf ../Body/a_fn.htm +ec4b80a15f190f720a6893d659309f3d ../Body/a__.htm +42744a6f14030a775d86061eeba0da08 ../Body/a_lambda.htm +525a8930084a3e3206d34c49716faec4 ../Body/a_list.htm +ba7472548bc7783838264120417d5cd2 ../Body/a_logica.htm +05d7dd1787478b48240beaac75671f04 ../Body/a_member.htm +2923a312a050a1420306f438fd60c918 ../Body/a_method.htm +b6f7bdd20809df5f1ac5c99de3086b28 ../Body/a_mod.htm +4ed4af12c86ad2c4196f039940c85445 ../Body/a_muffle.htm +41d2c89006db3c6ba14707bd95016b78 ../Body/a_nil.htm +368f6b0c7057aab0f73d9f56a95ab49f ../Body/a_not.htm +1fb180336baab53da4da3ffa5da47094 ../Body/a_null.htm +e808c88e5b724a89b594171ef0aa06a9 ../Body/a_or.htm +811b485f440409e8173e7b35adb1937e ../Body/a_pl.htm +425056284f042d54890b48d9c4aab81a ../Body/a_pn.htm +d73b24276a25481f93d6ceece0a5d52e ../Body/a_ration.htm +267683bedb4306a19a1176bb1d97001a ../Body/a_setf.htm +c5d1ccf78c98d6d8e05ef06c264f80d8 ../Body/a_sl.htm +98a4e22c0f9811ab0878ad842cfbbfd9 ../Body/a_st.htm +62cbfef4fae735b88b0ac5f3e555adff ../Body/a_store_.htm +0b189f13176d4690e12d64bff9ab71a4 ../Body/a_string.htm +daf65ebec997d843f0cdb8320697cdc9 ../Body/a_t.htm +48f8e39f26ff69c0bfcda525ff9b2514 ../Body/a_type.htm +5a4b16cfe49cd8bafbcb6791779af877 ../Body/a_use_va.htm +e7eed8e6ef32048ffb5c30b0a3601bb0 ../Body/a_values.htm +5e200152f0e9d52128e1f660662a5bd6 ../Body/a_vector.htm +1d720e747531b68443a27b848890f6fa ../Body/c_arrays.htm +e60116a2ca60e9ac66d152b28c0774b0 ../Body/c_charac.htm +c2f562d69fbc5b7fff796701129b5893 ../Body/c_condit.htm +10687a13faa8ed108c3af1009bc998ed ../Body/c_conses.htm +73ea5935be6ee77454d3915141068c9f ../Body/c_data_a.htm +b3fe64fcc8dd7b3f5b8fbef21e36c81f ../Body/c_enviro.htm +978112cf39771fca0f4fdbc1083b375e ../Body/c_evalua.htm +b31985fd96ad4ade712e366c43c33c49 ../Body/c_filena.htm +b5b2ef29a3f0c7712f429ebeaf9386ad ../Body/c_files.htm +1716c990344d5a0ed982fc21efc819b4 ../Body/c_hash_t.htm +f674fb4663d4801d458331b7f0ae2c67 ../Body/c_iterat.htm +7e2e3eb9eb76e2657103854ba9c8e582 ../Body/c_number.htm +ee4d1b57ab60fb01a7e2b8f35a81d67c ../Body/c_object.htm +39ac810da2fa8ef2774017a2d5e1d09a ../Body/c_packag.htm +b2a93ab45dc25c625a481e02f8a5bcda ../Body/c_printe.htm +0553ac20a5923e033bafd5c2226205a1 ../Body/c_reader.htm +70e8469eed59cfedd246796a67212481 ../Body/c_sequen.htm +83be0ab63dc1cce03a2f36f3a2115264 ../Body/c_stream.htm +2d7974e430feb4add9c114c1fdbc8754 ../Body/c_string.htm +1f40fd76d88c0307e65bb7b35f090dcd ../Body/c_struct.htm +3796f388c6203a61715b0779fa048630 ../Body/c_symbol.htm +1d8437811c50459676d365dda54b1c50 ../Body/c_system.htm +be335124333330c3005b8ab1a1d34d8c ../Body/c_types_.htm +d2fff38786a83567c4bb657f3a17d4e5 ../Body/d_declar.htm +7d0f1d206cc9d2bed2f793822099476d ../Body/d_dynami.htm +772b0bf5784da6c53aa009c7d301b1dc ../Body/d_ftype.htm +3c9cc9909a6b1352ef5d5d6a57f10ab1 ../Body/d_ignore.htm +6cadf6f8cd5c52e9ddb8d86b3b4a5cbd ../Body/d_inline.htm +8ad4df5b28ed75a5adfacfd04573e293 ../Body/d_optimi.htm +afcf999db409e087e6b2d23fef8e6389 ../Body/d_specia.htm +e50bb515090742015f9f6349eeef5244 ../Body/d_type.htm +9463acd6414f3ef2cd87aad7843bd689 ../Body/e_arithm.htm +e720950ead8ae379761795c5a24cb5e4 ../Body/e_cell_e.htm +b4e6cd448c3148e694ea1d4e1a5a3bec ../Body/e_cnd.htm +e83a3660634d12c9db2f211bbc305402 ../Body/e_contro.htm +f63c93d6c0c7e348c75f235dda7f6684 ../Body/e_divisi.htm +e1fa920494b701d193961ad5774e842b ../Body/e_end_of.htm +d80fe8cedb47bae08f3c13a2949692ab ../Body/e_error.htm +8b36dd6644f9860792beb7ef11292c67 ../Body/e_file_e.htm +317de555846e6a5804e61e8369afcf12 ../Body/e_floa_1.htm +08d322c5cf0e186fa5f393f33734e093 ../Body/e_floa_2.htm +af5b30994876a177e75005ee62530985 ../Body/e_floa_3.htm +d5e736eef7f64bd3cdea91d63237a49c ../Body/e_floati.htm +42cedcb0d919faf58f581b402bf71915 ../Body/e_parse_.htm +f535556e66541d29f5eaaa01612ee853 ../Body/e_pkg_er.htm +b6a1634fc187167b7f50bc6688aceee8 ../Body/e_pr_not.htm +e8bdd2309b5f15d9896e769d5cb0138c ../Body/e_progra.htm +5a0b9e7b03bdac777ab8173d4223c7b2 ../Body/e_rder_e.htm +471b973305bcca2afd4b29cc1d7f7fdc ../Body/e_seriou.htm +0a6d4562f7778f7e0bb41d88bb6a9d44 ../Body/e_smp_cn.htm +0a9f1a42175c73532a30724f7cf6b77e ../Body/e_smp_er.htm +f5624c717144acbf7702cf5caae76b74 ../Body/e_smp_tp.htm +b79f8d82f2cbf45236d96fe8d42f4390 ../Body/e_smp_wa.htm +44bd8e1c19403fe1521c71d95349fa50 ../Body/e_stm_er.htm +51e4c8958f95c703889a422aa251fa19 ../Body/e_storag.htm +23c03482c2eacede208f7bd3de39ad3f ../Body/e_style_.htm +2d13f4d274081d659c89b4683c65c713 ../Body/e_tp_err.htm +442a723aa96b18da2f871311f656a00e ../Body/e_unbo_1.htm +28ede643f91685555fcdd737ef16abf8 ../Body/e_unboun.htm +01ca8c52b8e6f77fa4aecb3f8406deee ../Body/e_undefi.htm +62cb774f955181a41dae4744f7a6c846 ../Body/e_warnin.htm +e2461fc7cf09fbc37ca0700f785a638b ../Body/f_1pl_1_.htm +d2b418fcd8821b469b3b1b2f32155dcc ../Body/f_abortc.htm +4b0e77b47221f78889d46e7788afc49b ../Body/f_abs.htm +539c73e9b9f64464ec4b31d70a906d71 ../Body/f_acons.htm +69180cafad77c48ac842c00b3ebbc729 ../Body/f_add_me.htm +68684b629a3f75dd2f6f58bc00b4403a ../Body/f_adjoin.htm +8671791d1ce1c0183670f30ceb50e72f ../Body/f_adju_1.htm +32ef51bd3296ad70cf8c4bc0a2f0083a ../Body/f_adjust.htm +0e3b1be8787789a09a81b8afbde81c21 ../Body/f_alloca.htm +5021d35866e96aa27988c29808f8f92e ../Body/f_alpha_.htm +4f90cb52ddd71c2a0d87bff6d2d335e1 ../Body/f_alphan.htm +75111613b0c5416ebb4a487d6639a116 ../Body/f_append.htm +c42e389141f09585a69eb842f4de4e27 ../Body/f_apply.htm +0a195e2c4489755722b57916e3b11008 ../Body/f_apropo.htm +f51747e5d831d1cb33afeb7f8b7e9a58 ../Body/f_ar_d_1.htm +5ede31dd6c0d8610f1da1e01368ff5dc ../Body/f_ar_dim.htm +64f8657345f7b4ee71dd4fe803214c71 ../Body/f_ar_dis.htm +11a3613c16aa3d160d46812cbfcf1c6f ../Body/f_aref.htm +294382f104296e2f443c7f2a8f92e381 ../Body/f_ar_ele.htm +a72b763c3a93c1f38b31eb0cff0aa546 ../Body/f_ar_has.htm +29a85455fd251cecc95db367b36d2765 ../Body/f_ar_in_.htm +aec6c760ea96323be42508cd590d010b ../Body/f_arithm.htm +5ed71437d1103c659df510f2c9032e1d ../Body/f_ar_ran.htm +71a3833bf2d3b45e3058f4c7b0b05400 ../Body/f_arrayp.htm +ac96bb099d0be253c235ceda287d3595 ../Body/f_ar_row.htm +459ed16bd2afe764c22bae7ae3748d71 ../Body/f_ar_tot.htm +e60737fd617463ce2f0033ba1626defa ../Body/f_ash.htm +96354377d2a1016301435a7638a48f01 ../Body/f_asin_.htm +3ee3e5cfbe13d68504556b6aa26dbf63 ../Body/f_assocc.htm +f0a49d6cba82bcd55cd72e392a45dfbc ../Body/f_atom.htm +c1ea70cb5fa510910fda5e2aa35f6a00 ../Body/f_boole.htm +2a0ae385f32470739d00afa9400d8a14 ../Body/f_boundp.htm +e48ad2dfb75b53d60c3ca02fd448d926 ../Body/f_break.htm +cff0a05fb4b4ef084af9b35ab5facd69 ../Body/f_broadc.htm +098123df4c5f1dcd6a0371e99bed75df ../Body/f_bt_and.htm +1b722bbcb7f138fb10c6f190cdb94786 ../Body/f_bt_sb.htm +26044dab3f3dec367a0fbd3b685f3f2a ../Body/f_bt_vec.htm +d7830152a33d4e436ac93ad9b4621a77 ../Body/f_butlas.htm +1499f80b2d992ee67c8f3a4a9f3f550f ../Body/f_by_by.htm +392fe63490477ea6b08c6c19a0d41e44 ../Body/f_call_n.htm +94e5c24fc694523dcd686bc59ef94465 ../Body/f_car_c.htm +9e43b47d79b18ad15c6ae79f86314d20 ../Body/f_cell_e.htm +0abe2459d1fdb4858db42f8ae684e066 ../Body/f_cerror.htm +8d8510eec14a894c88eeeff633e64a82 ../Body/f_char_c.htm +1aa2a62281e8ff40f9ff5b2961d73d0d ../Body/f_chareq.htm +6789b6b4433d5658e6a17ffdba516720 ../Body/f_char_.htm +1a4b09e4faa1340f656840c45e3fddb0 ../Body/f_char_i.htm +70ec1ca22e68901c466035291d0b49a7 ../Body/f_char_n.htm +d1c669ae69b06386f2d1a83f9a506469 ../Body/f_char_u.htm +d6c065d6cf54ce4d94afc4aea9f5f15f ../Body/f_chg_cl.htm +033990a176c425a99eb7d82aaf4dc37e ../Body/f_ch.htm +e93a8303aa1cbced068e530484d797db ../Body/f_chp.htm +6f3ca0bcac116634ebb1905398f42869 ../Body/f_cis.htm +433a9d7a0edc7505e79fc4ed2bb54282 ../Body/f_clas_1.htm +5521467759f0a3b4cbac21c45e6e5c01 ../Body/f_class_.htm +6c868febbdc949fb1094af71d493251a ../Body/f_clear_.htm +3601d59355636204a8e7c1a1288136d2 ../Body/f_close.htm +9b8201a5951b367664d91f7db011d848 ../Body/f_clrhas.htm +54658c930c9494e51b5faeb6113057d5 ../Body/f_cmp__1.htm +b0a41c070ba33a1525746cdf8ab2f5e4 ../Body/f_cmpd_f.htm +2e3868aff347d73eebf5dc5c6723bd12 ../Body/f_cmp_fi.htm +501daa4a3b5cf4726c01b9b5bb4cbfec ../Body/f_cmp.htm +005d08e17b206671ac9f76dbb6f4bd15 ../Body/f_cmp_ma.htm +e56ad10edbf8853a6ab8858cecd06a61 ../Body/f_code_c.htm +3288da3400c0344daddc228b9846bca0 ../Body/f_coerce.htm +b0f7cac2a5dd205116751c880f9fb3e4 ../Body/f_comp_1.htm +71bce47ac74a3b42e5850701fb2a7bcf ../Body/f_comp_2.htm +4df4c00b542ac83212a2590e8f9d39b0 ../Body/f_comp_3.htm +319a803a525a4d1ea206624dd7013be8 ../Body/f_comple.htm +a2dbc5f818330051580a60b0bc714ae6 ../Body/f_comput.htm +f41f15c2bbd33fd4c46ae4f911fbc691 ../Body/f_conc_1.htm +f46398e2376b31bb7ca706ec7edcfc22 ../Body/f_concat.htm +6a7f0cc7c07faec39c68b2a1f7f7b9bf ../Body/f_conjug.htm +e145192df83cfb9b3b4702f374a9506f ../Body/f_cons_1.htm +bff993e7ff344f9a577ace4e781fd740 ../Body/f_cons.htm +68c2563db4295c14ba9a9e9a5b857f80 ../Body/f_consp.htm +849a8d8231fc058f81b6e53c894a64f1 ../Body/f_consta.htm +4e539eebd4e4c2e97e6a6c0d1bf78d70 ../Body/f_countc.htm +913da0a017e8eee73e0dbb2ebbbe71b2 ../Body/f_cp_ali.htm +9d2176afaf354c3531b9094371631a99 ../Body/f_cp_lis.htm +1206558dfa48ceba65d7a4051909b06b ../Body/f_cp_ppr.htm +b386b74f04f365af13a4727804866dbe ../Body/f_cp_rdt.htm +84ce1e156b77f3842a5cb4c796529e48 ../Body/f_cp_seq.htm +f23ef4031dfc71093a14fc8a700c78de ../Body/f_cp_stu.htm +d2d992b7ff35764f7d7406b65438b2af ../Body/f_cp_sym.htm +96361d6fc72953ddb22b2b803a0ec84b ../Body/f_cp_tre.htm +dc0d5ca28802761b8b57dabbb1c9a4a1 ../Body/f_dec_fl.htm +18894d4eaa2cb9a62bf0cbda920e30ff ../Body/f_dec_un.htm +a42f99ebf79ef4c4ec092f7c7f3a4186 ../Body/f_del_fi.htm +dfb19c0bc39125a70e4d130d5a5b067c ../Body/f_del_pk.htm +ff0da45e444beac50874d825af2ddee2 ../Body/f_deposi.htm +fce9987ecabbe90a95ce7cdaed0f7dba ../Body/f_desc_1.htm +fd80e4af84b3b1f6a04e2176b6db0108 ../Body/f_descri.htm +3525a58d0abcd5228af259c06715811c ../Body/f_digi_1.htm +21ba135fef212024b7965bff3bca47cb ../Body/f_digit_.htm +636485bdcfd24fd04aa0a497aeeda88c ../Body/f_dir.htm +0e80300d1b40a97139982e59d9a91023 ../Body/f_disass.htm +9d7c728fb78be9469c5362a5c0551d17 ../Body/f_docume.htm +4a06a6d9b24cf6f8259f13b74eba2f22 ../Body/f_dpb.htm +30446a967c819d9f5a52339f9ed8f2fb ../Body/f_dribbl.htm +3e89a78c4c8a9f6d8a2f8b888c3c5a9a ../Body/f_echo_s.htm +81192910e6ec4c26aadd46f1d588dfc7 ../Body/f_ed.htm +ea24f34ef44b40d2de3df63789185355 ../Body/f_elt.htm +9af2278afc32020ceacf0935b9a2212e ../Body/f_encode.htm +135be377235a366b8c718a6c691b24f2 ../Body/f_endp.htm +2f6aa52ca424b898857ad0546de2e051 ../Body/f_ensu_1.htm +837957a2798f2109bb077eb5560d44f7 ../Body/f_ensure.htm +8c5e5a3ab994c0408587c577ebca802b ../Body/f_eq.htm +dc5234fa951ad54967c46203333878ad ../Body/f_eql.htm +24b64eef04bb1ed9372ac6c9920bd415 ../Body/f_eq_sle.htm +bdf702f779bb613063923e4bca8b7183 ../Body/f_equal.htm +4f541e05e3fc4e3b5c767a0d39c4c643 ../Body/f_equalp.htm +b1a4312a326542ea64d224c02c2abe1a ../Body/f_error.htm +c4ad6a2b1badf23a731c854532ba2bc2 ../Body/f_eval.htm +566fe088d7c5cd9ea5ce2be5e2c86f68 ../Body/f_evenpc.htm +b2513c3ba879a076877eb1614833d65c ../Body/f_everyc.htm +92ec4b4d7584be46a3152efee029e178 ../Body/f_exp_e.htm +7dd98056117bcc99bd211fa4b9ab3ab2 ../Body/f_export.htm +4ea9d9faaf648f7c9ff007e212af35d8 ../Body/f_fbound.htm +eebabca0f7b698df24e846fe7abf6b74 ../Body/f_fdefin.htm +7a735dbf6006171e2ee72ae1e9183c1a ../Body/f_file_a.htm +80ad8e2882233f6cf80cc52731bd70dd ../Body/f_file_e.htm +b8f57ebe01c01cbd0ee80fa3962f9adc ../Body/f_file_l.htm +7a4575c29d3e2aa2a131c2465d9f0b8e ../Body/f_file_p.htm +788ada4135e2a9907681127f58bc8814 ../Body/f_file_s.htm +d0b00cc3456c6502fa61867a40878b92 ../Body/f_file_w.htm +9a8a27e29ad1015bae3e7c26140c103e ../Body/f_fill.htm +e88c2c3834ff7843f4eff6fe3861e153 ../Body/f_fill_p.htm +b4d0804d52735a37233ced2be3a7424c ../Body/f_find_a.htm +bd6fa86372beb4ceaca42a4a8fa8f208 ../Body/f_find_c.htm +d65028cb52e1886dea837faecdba6ee8 ../Body/f_find_.htm +dc75fba9ea87396095d7414bb0b7c7e9 ../Body/f_find_m.htm +7ef5c0216664106a0f8cc0715ea71e6e ../Body/f_find_p.htm +f41d8a94f121eef21001dac0f44c151d ../Body/f_find_r.htm +23c914b3c8c3f8fe90e59d0639b92ed3 ../Body/f_find_s.htm +4ae616b8665e83fc0652364a73c3e879 ../Body/f_finish.htm +99a7c6d3ff89f054b1c97c2049c6ac34 ../Body/f_firstc.htm +dff55f23eeb76413bdc315806b52225d ../Body/f_float.htm +964cda26981841a4e3f8cccca62fd509 ../Body/f_floatp.htm +707e1922b00e06ebb6be4343fa0dc3aa ../Body/f_floorc.htm +6bcd730fb301cc6f77a2efd5d2ac9561 ../Body/f_fmakun.htm +f2482d023f9abceb63dd228b7d62fce5 ../Body/f_fn_kwd.htm +864022037a924691e30848488db7c5b3 ../Body/f_fn_lam.htm +b173aa1ad8d7e950b7642114a4ea522e ../Body/f_fnp.htm +7e346990b0c4bb2862ae56465088f3bb ../Body/f_format.htm +c4362ba5db59e7464b7a994d9e38fc95 ../Body/f_funcal.htm +f4fff498081f0f7273a053bafc01202f ../Body/f_gcd.htm +db1494c4f9762ad464a22feaa73e38c1 ../Body/f_gensym.htm +d5c0a6bcdae1844387c3d0ceb8a979b6 ../Body/f_gentem.htm +1fc6df4dfb618a511d90650fc39db1eb ../Body/f_get__1.htm +613a677054afef07e7454acb20e540f7 ../Body/f_getf.htm +ed76cf4a51745e975d160b354523d1d3 ../Body/f_gethas.htm +2a62f9bbf923d4b67b7b3eb2a5ba02de ../Body/f_get.htm +1326b79ed235726655e54be976b931c0 ../Body/f_get_in.htm +60f4875413b209f4b326e97030f2cf76 ../Body/f_get_ou.htm +7ab60e6161ffe4d1a7062aa9528f5cfb ../Body/f_get_pr.htm +b03666222366732498f660ab8081d2e8 ../Body/f_get_se.htm +434f22671b6512499c4ae08e121578df ../Body/f_get_un.htm +72764106a89cb6ab13d4d1140a4c5104 ../Body/f_graphi.htm +93d91229f52f6bf60ab0a05bf7fb6b4c ../Body/f_hash_1.htm +0813213657a399997e18ea030766e71e ../Body/f_hash_2.htm +c1dbd3e581f72891a418e652e6994234 ../Body/f_hash_3.htm +5d5ec03a9b71eb85b233fc251cb47bcc ../Body/f_hash_4.htm +b55d23530efc7a7ee3b5defacf48a6cc ../Body/f_hash_5.htm +0e6e14f90de30ec89761127390c5d51e ../Body/f_hash_t.htm +671fff6cf1e55354e7e994d907d1aaf3 ../Body/f__.htm +1b23ccca0877303e289b23ccd373bc8a ../Body/f_identi.htm +620c7492ed2f852bb4b8a0a6a3664621 ../Body/f_import.htm +62306aebe831a504ee8d3e76bad85527 ../Body/f_init_i.htm +f9157a91632b9dc53acc0ce93d9e2de2 ../Body/f_inspec.htm +e45917e0e1b0c2391035aed18a8473b7 ../Body/f_in_stm.htm +67b833e4578666b2f796d7f11f8d174b ../Body/f_inte_1.htm +156d429388bb47138816eaea357b7ee0 ../Body/f_intege.htm +bf0b961e528cbbf42381d454ac701343 ../Body/f_intera.htm +228295e28b135ab5fba1086eef7a0966 ../Body/f_intern.htm +49ca0cffeeba1161b2d7e29ed514f0e2 ../Body/f_invali.htm +77e780a1498699be039206e47cbacf88 ../Body/f_invo_1.htm +7813d9f682401b4f37c1bc0362a26819 ../Body/f_invo_2.htm +c9b126b89f2e544c2539694595960dd5 ../Body/f_invoke.htm +eedc37835fc0f3463f922d3cde278ad9 ../Body/f_isec_.htm +ae785dee44427fd7fbec3bff1d0a1785 ../Body/f_kwdp.htm +091a819e2d3b0ac661f4585c88d8a3f8 ../Body/f_last.htm +68589cb6dca8899b982391988f13b3b8 ../Body/f_lcm.htm +96124f21329aa44cef7bbc38a3bdf5a9 ../Body/f_ldb.htm +70d98537a5842274e1e738555a06141e ../Body/f_ldb_te.htm +bdb7dcb59abad5c14d76e6b8a847d926 ../Body/f_ldiffc.htm +394c4d6d4cc8b96cd48f2bd85437ac0e ../Body/f_ld_log.htm +04d461e51e87998c68598c64772b13e4 ../Body/f_length.htm +7f190a70abe7977dbf0644eb628311bc ../Body/f_lisp_i.htm +e8dd1adc9cd6d67b84cca69aa7098621 ../Body/f_list_a.htm +503970d5b1690faad7af873d82c0277e ../Body/f_listen.htm +90abfa2748dd4ba6db0be21703f61b84 ../Body/f_list_.htm +dab82b4f35ebd471b7369e39acbe529a ../Body/f_list_l.htm +8bf60d08eac8f7e0e1d016b4caacc8be ../Body/f_listp.htm +4510d66f080f2c55a0531b6a316ebaae ../Body/f_load.htm +e222e51470166e1c5188aeec6bac6c63 ../Body/f_logand.htm +d5d91ed4e6f3886024463988053c7fa8 ../Body/f_logbtp.htm +0c6fdf869b90794e2278282084966d22 ../Body/f_logcou.htm +3b6ae4a73d1462c6d06cc7e54d8e0c80 ../Body/f_log.htm +84031a235c5babf71c7b888ec32677d0 ../Body/f_logi_1.htm +44201d3ad03a385b13c36e8118246a28 ../Body/f_logica.htm +6cac020f0bb4ecdf9f8fb4e9c003cb98 ../Body/f_logtes.htm +ef8e383257b6b21e02b9463bb634a56f ../Body/f_mach_i.htm +e4897b149c57fb1d43b7197dd0f9f6d4 ../Body/f_mach_t.htm +263a3d34c1b4d815bf009d1b767fb91f ../Body/f_mach_v.htm +c73ffd62d97863cd78ce72987e631e84 ../Body/f_macro_.htm +2f6c93fa174a556c0a7fc36e59afa26f ../Body/f_makunb.htm +f35948d5ed2eeb7e9b76904467cd78a8 ../Body/f_mapc_.htm +bfcd1e5d2462f3bec4d126a833a96cb5 ../Body/f_maphas.htm +830d18dc3d10ca2ae649819d18402961 ../Body/f_map.htm +80bca8cf99db9e8a5d10710ce5aa1f0e ../Body/f_map_in.htm +799d1dc3ae2be34b223b0a3b30a3cd4d ../Body/f_mask_f.htm +4ff014448a7cbdf8eadb64d5c56b4f3e ../Body/f_max_m.htm +94d9ee2d1dd7b8f55bbcaa47017cf885 ../Body/f_mem_m.htm +10c37129894c6008cf5269962dea6a60 ../Body/f_merge_.htm +05d2f42139257b2efa5180daaea9f398 ../Body/f_merge.htm +d81796e386654760401c0d891eda9c34 ../Body/f_meth_1.htm +e328b2dede63658c166d41a26e250f3d ../Body/f_method.htm +27503499a139398dfe2734c874dc9541 ../Body/f_mexp_.htm +e0497d8adf14a764f06f16fdfd15d351 ../Body/f_minusp.htm +ddacabc1a93c884f4435ed3d965909a9 ../Body/f_mismat.htm +b6e7fc2418128a8a0115b2f332f4d69a ../Body/f_mk_ar.htm +c5f1ef4c28fa42325b188b34b1e710c0 ../Body/f_mk_bro.htm +d8089599d0f0d2445ebbb6bc3ea057fa ../Body/f_mk_cnd.htm +d3a93b68732d0aeb07cc84325436fd13 ../Body/f_mk_con.htm +2f4f57fbf42ac0e89925c4367453235a ../Body/f_mk_dis.htm +b0e6b4711795202388f2f50942897339 ../Body/f_mk_ech.htm +4b203baf5dd544315372a80359be2887 ../Body/f_mk_has.htm +1d3753b1b7260da6dd4be32efa2b4b0f ../Body/f_mk_i_1.htm +addf31deff51c71fc0ab242d2b1b2c10 ../Body/f_mk_ins.htm +b9bfb94248cda3a382c2aaab5d96888e ../Body/f_mk_l_1.htm +61f4a779f7d37425537c9247196c446c ../Body/f_mk_ld_.htm +cdebdd3e82de3035129bf2f9a6c57639 ../Body/f_mk_lis.htm +42a0527e5de30cfd637d8f5302bf1b5f ../Body/f_mk_pkg.htm +66229016c3cb1ece1b253c5faba50252 ../Body/f_mk_pn.htm +c26a37381e52ccf8ad6e7461ad1ffbef ../Body/f_mk_rnd.htm +9a77f2c057955b5f21b1f101af9b1664 ../Body/f_mk_s_1.htm +aacd0176e3ee82972acc1853c544aa4e ../Body/f_mk_s_2.htm +3fd1f32ea614be3f8dd680762af1ceff ../Body/f_mk_seq.htm +183ced45290e7f8d9f2f3687b22757ba ../Body/f_mk_stg.htm +664504a27deb1959849eb2055e5cbf06 ../Body/f_mk_sym.htm +8fce94545a1c1d2e7f168b6421e5a6a1 ../Body/f_mk_syn.htm +5d7615d3db963a5a09014c4a4a2dd5c6 ../Body/f_mk_two.htm +fb3c4faa2afbba78b6a52a9e2c3f0a4c ../Body/f_mod_r.htm +eaada5389ff7aaaa14c76b83ef44932c ../Body/f_name_c.htm +a86a2f77d38f771b1cf335eeff1947c2 ../Body/f_namest.htm +28736cb57c8980b0bcb92a871a85deac ../Body/f_nconc.htm +a05750dc77ef677d87ee0da20d838b84 ../Body/f_next_m.htm +1118d508bf538c5cb68ace083c169dc3 ../Body/f_no_app.htm +8ff56167396e2b850bb6adf3727cbbc6 ../Body/f_no_nex.htm +84918017b48f587eb03b489fdd6f1365 ../Body/f_not.htm +e7eab4d33bed94c7ea4191b2270b7b2f ../Body/f_nthcdr.htm +e4ea7932d5d0b561049090b6e18677e7 ../Body/f_nth.htm +4d1c29d59bae4b2c9096530c11d9a4b8 ../Body/f_null.htm +9a1507e9e665d1dc9beafb13cfcdae5b ../Body/f_numera.htm +85cea37613f627788514efbfe2128198 ../Body/f_nump.htm +f1606af93eed1e70373d8bcb24ce7180 ../Body/f_open.htm +bd7555b4a53d758c48262ae17aed1c30 ../Body/f_open_s.htm +69cc2f2f637f10e185c20ef59502bdf0 ../Body/f_opsetf.htm +0b86a0d320466ef5798e5107528dff26 ../Body/f_pairli.htm +7ff3423ec6bdcc09f02b74a40e02d441 ../Body/f_pars_1.htm +9ae2ef3300045fc8eeaa5092b698289d ../Body/f_parse_.htm +32d6d82761fa0d423b2211b810500254 ../Body/f_peek_c.htm +cdbc390d106ee7ba8c67c890cbaf857b ../Body/f_phase.htm +4b831c06e962366b878db7d79efdc8b6 ../Body/f_pkg__1.htm +eef54ac1cdebe52d37c0578332251fcb ../Body/f_pkg_er.htm +217bd33fdfa39f6b7074cb8a59ffa611 ../Body/f_pkg_na.htm +73e6126b4e0469290ce8399e68c2caf0 ../Body/f_pkg_ni.htm +dade0b0bc1cb130130fdf3e9292812f5 ../Body/f_pkgp.htm +c4394b96cd9cc7dc67e928a112de4aba ../Body/f_pkg_sh.htm +f50cf8b202bfc1dcac8654dee7990c72 ../Body/f_pkg_us.htm +7d0e0f4fe40756e76e20efb356117e39 ../Body/f_pl.htm +9469d58efd45c7b3746286f132148b92 ../Body/f_pn_hos.htm +6adb00648ef1472d5213afcd7decb24a ../Body/f_pn.htm +bd9a77ae1e945bc32c2ecb37eed08931 ../Body/f_pn_mat.htm +3f452033bd3019e03ee6a647d7c0fb68 ../Body/f_pnp.htm +8ec6bc433de595f9770fda80cd225cce ../Body/f_pos_p.htm +683684a9ec6faf74feba894b5823df7b ../Body/f_ppr_di.htm +0c8544ce930c0da9efce6d37170864ed ../Body/f_ppr_fi.htm +ad7fea9d0f1de9471391aa6dfde8808f ../Body/f_ppr_in.htm +93285ec8e38c25963a51da0942d2810e ../Body/f_ppr_nl.htm +039c1200ec284610734482907defb976 ../Body/f_ppr_ta.htm +b902720eab8ea877d0d93db0ae0e3153 ../Body/f_pr_not.htm +6835d32d41c72e19b5fb5b83efb0db00 ../Body/f_probe_.htm +dab7afa0e1652ba8ad732a0c6d27332f ../Body/f_pr_obj.htm +9cd6ad420f6877bec3d93bdfc90f18fb ../Body/f_procla.htm +77c3b7d9de3c85d5c55f4f97092d4490 ../Body/f_provid.htm +e787c12f749e1c9aaef8b4f8e421a549 ../Body/f_random.htm +d1f314b99db4394bb4ac9a0a9825fcf7 ../Body/f_rassoc.htm +3f933cb801a66be03ff5b5d6960c84ea ../Body/f_rati_1.htm +4de65bb95afeae9b312b1c89fa457d91 ../Body/f_ration.htm +4c08441c1492141a67b1a5021bc15b24 ../Body/f_rd_by.htm +53c270eda49c76330309b4cc932b7cac ../Body/f_rd_c_1.htm +db3660ff4bc292151e4b1f438192de7e ../Body/f_rd_cha.htm +fdb7dc57a820a9ef85955fe10bec9eef ../Body/f_rd_del.htm +b3399b9d833d85fc6d261c95327e51a9 ../Body/f_rd_fro.htm +059de73c56d65b63889828eae76430c5 ../Body/f_rd_lin.htm +71cbf81e90d24d112dd0c494ff57edcd ../Body/f_rd_rd.htm +7b7b8ebf650d350086b93218cc4af427 ../Body/f_rd_seq.htm +1f5bdf5d546562f3d8abdc3c7875106f ../Body/f_rdta_1.htm +7ce490516d19ffba99c346bca2f86cb8 ../Body/f_rdtabl.htm +9df03f486788c41682687e12a1941fb9 ../Body/f_realpa.htm +849d691b37d134c41ce782005da4d64e ../Body/f_realp.htm +a1161f085752ffb1a58a66571bebebdd ../Body/f_reduce.htm +f97b64c291b382c0757bf98e277b00e3 ../Body/f_reinit.htm +3a33eec427ce988be150a7c6ed066fe1 ../Body/f_remhas.htm +9c0036e43501fa757eb56489c0676649 ../Body/f_rempro.htm +e5dc07e88245860e0ff169d68aaa3968 ../Body/f_replac.htm +7e32a937bfd9c04902fe56b46e969594 ../Body/f_rest.htm +68c8746eb6a062c655de048eb233e31a ../Body/f_revapp.htm +6be9e83d6805c34a3f5a48fc1cd72070 ../Body/f_revers.htm +545889d60711d0acf9493509ec6a7a57 ../Body/f_rm_dup.htm +370b2470e1bce191536cbb534efb79c8 ../Body/f_rm_met.htm +56bc8ba8a50d54b3206c4a6f816158b7 ../Body/f_rm_rm.htm +1a52d15fe04e1fea07529a8552bbf5c6 ../Body/f_rnd_st.htm +77a0f29a4f88b5c0720be7b337ced79b ../Body/f_rn_fil.htm +0042adf587736b4193c659a5e8369b38 ../Body/f_rn_pkg.htm +3616b7dd499424c3bd003e3a1190800a ../Body/f_room.htm +a173fd75947d8380dc618942861ca0f4 ../Body/f_row_ma.htm +958fb97733753eade7ff2712c2827fda ../Body/f_rplaca.htm +335e4e71fe4c76adbb487bcc08eaacd4 ../Body/f_rst_na.htm +d3cf2c971c28e9bb23ae978ea580624e ../Body/f_sbs_s.htm +edf161aa567854ae8681b328e018efc9 ../Body/f_search.htm +9d988efe400daed9348ecfb89ff160aa ../Body/f_set__1.htm +5327dd64c92ad89b484fcf11447f7567 ../Body/f_set_di.htm +2ec50dd2a5fe94672d3e99970979319b ../Body/f_set_ex.htm +87daa6d791f5a8e353b6deb99873213d ../Body/f_set.htm +37d169cd952d9e01a7784102b80805c3 ../Body/f_set_ma.htm +9ccf5bb7aebaedd1ec7b5baa73ce54e2 ../Body/f_set_pp.htm +0494f4ac2f8c471666fbc4a3b1a537c6 ../Body/f_set_sy.htm +3289764328da7e600d4f74d35ef43085 ../Body/f_shadow.htm +250b49dd55ab6a34940085e114609dcd ../Body/f_shared.htm +a4259a982a095e14d81b1ef5488d61a7 ../Body/f_shdw_i.htm +4ae4bfb6fc473a34393f416b32e698ea ../Body/f_short_.htm +39f9cfc063dee76d7d8cb3e96140c1fe ../Body/f_signal.htm +5264204b692d138175ee029adf8822dd ../Body/f_signum.htm +4486f5bb92edbdf2a05820787d64ed59 ../Body/f_sin_c.htm +10b87395eb9f8ff194a18c92a61b3670 ../Body/f_sinh_.htm +ab9bfef4fa22e1e625698c36f25b1605 ../Body/f_sleep.htm +976e97b73801783bb97301a2ce27a149 ../Body/f_sl.htm +0a0f22ae3d7f9d9d81e7d826b0736a85 ../Body/f_slt_bo.htm +2ce1c1368b4cacb63b174f8b25733428 ../Body/f_slt_ex.htm +e2ba0a2877f10ab2bb1cef2b97098635 ../Body/f_slt_ma.htm +cf8d3898bd1afb832c45023257c64fc1 ../Body/f_slt_mi.htm +c113f050861691e631a91cc84515cbd6 ../Body/f_slt_un.htm +1bfbd607f6aed64469a18a3cf1ccf74a ../Body/f_slt_va.htm +6e4999a3f97d265b03cc4ba12c8f59e3 ../Body/f_smp_bt.htm +5383f17ad9f09d5252edd08c7ba398c2 ../Body/f_smp_cn.htm +482794dedff17ce03b1197c81c7e65c7 ../Body/f_smp_st.htm +37798d51036ab48ff4f232b3310fa169 ../Body/f_smp_ve.htm +3186845a832b4c08a046cff2b2a98e9b ../Body/f_sort_.htm +55da5f0f436bb5a49b268c603252e068 ../Body/f_specia.htm +eb2654f03acd05ac9a0a195a1a55cd2b ../Body/f_sqrt_.htm +4659f370edb705728fc59e24c9613224 ../Body/f_std_ch.htm +45dd28a13560e938541227261575923a ../Body/f_stgeq_.htm +db8a616c54a4f1aa09a1347cfa38b442 ../Body/f_stgp.htm +0b7d4d8f6c049b050ec6da4b0169142c ../Body/f_stg_tr.htm +30cde6c9ea9d9f27c7a58802b7d8347b ../Body/f_stg_up.htm +637d34b78d1ead15504f906634b69448 ../Body/f_st.htm +1438c987eba26aab2dd521dcb130ccec ../Body/f_stm_el.htm +b9e60756d16c70bc0f4883bf34e75e57 ../Body/f_stm_er.htm +d23a7719a5aa78b62312d59645bd7ea6 ../Body/f_stm_ex.htm +8ef20d6526cd69471c44aba9461d1716 ../Body/f_stmp.htm +e904470f031ee37f9bd0389995fa0cc1 ../Body/f_string.htm +dc84f2a70b364cbdfcbefa21d467b026 ../Body/f_sublis.htm +e7aea6e2944be621771f0556385420ef ../Body/f_subseq.htm +9c2921b009bcc45fb94d2bba26a87b4a ../Body/f_subset.htm +afb1d6dee52a8d7c74fe69fc536e756c ../Body/f_substc.htm +8fd8bef5cffc4142e8f0b041c06191ca ../Body/f_subtpp.htm +2ddeb42ae0691676750b098dc81f5b0f ../Body/f_svref.htm +1f10d1d15607d652183e10b339936ab7 ../Body/f_sw_tpc.htm +f7a3876492efcb66d6f1596d3573c902 ../Body/f_sxhash.htm +27e7f1c2714a72ebb09629e4702e89aa ../Body/f_symb_1.htm +acef5c957fe8aef7c561c9a2995e59bd ../Body/f_symb_2.htm +75a72bc4b242fe28873cd2b6e2e3ba09 ../Body/f_symb_3.htm +f1b35935c54515338440e5db32f3d5a6 ../Body/f_symb_4.htm +5019aebd967e7ddbea48696d9559ffa2 ../Body/f_symb_5.htm +25bd92fb49642be35e3819db570a0651 ../Body/f_symbol.htm +a95cdf56699e4162abb89af0a328647e ../Body/f_syn_st.htm +437e315757ecf856f40e322e78221b64 ../Body/f_terpri.htm +7907199c840a77e5cf7a79f1ae0447ae ../Body/f_tn.htm +6d54d1f15da016432d83d03bb25f00ac ../Body/f_tp_err.htm +0de91fbaae007c4ab86d0349e791f898 ../Body/f_tp_of.htm +df2a695b5becf257bdf1c966e5dc2551 ../Body/f_tree_e.htm +706b55142da6305f9e965a8142af44da ../Body/f_tr_log.htm +d97db1396210ab90e26109b590af16fd ../Body/f_tr_pn.htm +9cee52a0ada8de3db6e2c0e607f95532 ../Body/f_two_wa.htm +c037b026b4f8f09f5d1be9fafd5f4951 ../Body/f_typep.htm +b2eee80adc28ed2cd60f650259b93334 ../Body/f_unboun.htm +93a26b17dda7b9bf1293c518ac83b062 ../Body/f_unexpo.htm +5041a909102be72312d67a28a883a660 ../Body/f_uninte.htm +c05cc5339c69248d30e8c1fa0e9da779 ../Body/f_unionc.htm +abb8f41190cfa01289720bdeaddf9cb7 ../Body/f_unrd_c.htm +72802488da1ab7f20cb92e67b6b13b1d ../Body/f_unuse_.htm +957220cb258e5803e1990e7a6a99feb6 ../Body/f_upda_1.htm +1e8dade545ed831c610059b8df289fea ../Body/f_update.htm +91c79f01dbae70ed9c365d3d205eb3a4 ../Body/f_upgr_1.htm +699e8bab699c03934ff761134d6f9a7c ../Body/f_upgrad.htm +c2fe27e779590eb1bf58a70b206c259f ../Body/f_upper_.htm +ad141bfb10de09459376922f3089070a ../Body/f_use_pk.htm +89be94ac72a882325a3d0a4c86a3c77f ../Body/f_user_h.htm +c0f11d0fef721196d1f2cbdb45c1b78c ../Body/f_vals_l.htm +7e42eb159aac9ab183819203172ba775 ../Body/f_values.htm +6d996d4a9e1b640d10434be2f85a7109 ../Body/f_vecp.htm +2f6c374d772ed949ea570787deb54838 ../Body/f_vec_po.htm +b7154c71246507056ed59ce6c0ced7e2 ../Body/f_vec_ps.htm +28ffee07d6612f735795ef723c722823 ../Body/f_vector.htm +9412a4355dab18602b5425b1dab39abc ../Body/f_warn.htm +02bebeefc4a94d6a4b61e63991ef6f41 ../Body/f_wild_p.htm +485eccf3f9df47e922e608e2ca56e207 ../Body/f_wr_by.htm +90927fdc564458cbb31f6b21a9d791f9 ../Body/f_wr_cha.htm +f0cc503e5cef3973a691eff2b582a707 ../Body/f_wr_pr.htm +485f114ecde5504e172b305b6716a31f ../Body/f_wr_seq.htm +707e507f3dca06d1993497686ce6513c ../Body/f_wr_stg.htm +f711df664011a1781f43e390be26d205 ../Body/f_wr_to_.htm +4fa9ff1c22088fffb87a134f42cffa6a ../Body/f_y_or_n.htm +b25f49d66f39d9f96277470ea620dfb7 ../Body/f_zerop.htm +cde3da7219f9291acfab6ad66a341f9c ../Body/h_glossa.htm +828b1a0b17eb2384709a131c77a060c5 ../Body/m_and.htm +995c1ff54d40412049ff8fdd588092bd ../Body/m_assert.htm +0968bee2f18e28988578d4e5240951f0 ../Body/m_call_m.htm +34959971a5b3d8723aae1f41a774d397 ../Body/m_case_.htm +00a37b71b0cb3d496d2dd8675d137b4e ../Body/m_check_.htm +fd01599bb24173917e094e6502161804 ../Body/m_cond.htm +a54b06698aeac319e8dbd278c6159cf2 ../Body/m_declai.htm +2da08d116af88e7c57116897510f6a14 ../Body/m_defcla.htm +87745b324edb352fe428797dd7c5ac59 ../Body/m_defcon.htm +1e8296d45e27e8d3b82f59ac095f7b73 ../Body/m_defgen.htm +12c5d52dd3fdff8a228d21ae26b1c4f3 ../Body/m_defi_1.htm +a8a047f618fe7c408474f6098a21ba6c ../Body/m_defi_2.htm +7b9c9c72c6a7b4180e1836057bf269fb ../Body/m_defi_3.htm +6bda378fc4c12de697b5422b16f57d35 ../Body/m_defi_4.htm +d46977ffc223fc9b500144d2119d32af ../Body/m_defi_5.htm +c4937d43dfba6ab4ae0791d1eb7b7e42 ../Body/m_define.htm +113551af5e70f20781cf51333ee25adb ../Body/m_defmac.htm +973702963787b28677e01236dceb03cc ../Body/m_defmet.htm +62cef1498e4e3e2ef26181e6e201eba6 ../Body/m_defpar.htm +4f9540e0ea1bccbf60b135d4c0922243 ../Body/m_defpkg.htm +f369dcb70599a224a4e6b192d8be3470 ../Body/m_defset.htm +2d74b5cbfbf8435dd2fbf24946c022a0 ../Body/m_defstr.htm +a8066d61d09d3f5ca666fdd403d749dc ../Body/m_deftp.htm +71fc079597e7167745acbee561f882c6 ../Body/m_defun.htm +0620a986374f9d1bab57c94954dab019 ../Body/m_destru.htm +a8919eb4ba7bafc6bc42d35813a6aa8e ../Body/m_do_do.htm +cdee209c120249e7d84d206ad0d1fbf1 ../Body/m_dolist.htm +76abaea5ae7fcfe633d64589aade6c93 ../Body/m_do_sym.htm +e5cd8b4db307209a2100d7970bfadd4a ../Body/m_dotime.htm +150da3ebdff82e46d70a6f9843b4f2c7 ../Body/m_format.htm +6e11a611d6bebb773bdc7fe4b0ec6a74 ../Body/m_hand_1.htm +bab6996611c4c7afed032897aba49520 ../Body/m_handle.htm +56046148f3f6f6392ce712fc65a04beb ../Body/m_ignore.htm +5455c313423bbcd6d4b59980936a5483 ../Body/m_incf_.htm +a2b32833d645937bb6db6709206dd0ab ../Body/m_in_pkg.htm +12aeaeb18094d4a03da3c452dd22c84c ../Body/m_lambda.htm +c8318dcba499527d95218f54d2aff915 ../Body/m_loop_f.htm +8ca3b961648d3b845358d89cc6cd6bcd ../Body/m_loop.htm +a16f316c8663e323416cae4b1a967928 ../Body/m_mult_1.htm +ad4d199dbbfe498c30f780851af79390 ../Body/m_mult_2.htm +3a8ba9838d53a617e443828b2ce71878 ../Body/m_multip.htm +ae8cf07bd9238e1a38f07d12bd30ef12 ../Body/m_nth_va.htm +1882866e3e5e4dc5131ebed1601d7beb ../Body/m_or.htm +10399c12045d4f69d6b3e39211911e55 ../Body/m_pop.htm +ec8341988204c6208dedc27728e69514 ../Body/m_ppr_ex.htm +418f7727efffa5b56cfe14e2e6710511 ../Body/m_ppr_lo.htm +c1593cfb274abbb0362b531feccec820 ../Body/m_ppr_po.htm +a698822c11c0b89cc130f3d15f739681 ../Body/m_prog1c.htm +011634e7e30f77deee107dbf6409464b ../Body/m_prog_.htm +99075d912c236812ae810d58ba756b44 ../Body/m_pr_unr.htm +7c1ecc6058bb896609442d97a03a28b6 ../Body/m_psetq.htm +7c95ed12fbee3476835c7fef15e65e06 ../Body/m_pshnew.htm +6aef0a6f9feaad34b4d393afea98b1ac ../Body/m_push.htm +4f0d9948ecd554256631d0063be1a905 ../Body/m_remf.htm +9e6799e55f9ee10dae6568f9bdee8113 ../Body/m_return.htm +f73616b3d8c48e6f09ab08df65308e31 ../Body/m_rotate.htm +88b4b1b5eebe4c774f4773d5d4fa1df3 ../Body/m_rst_bi.htm +17a53bc04a823157a3d43390ce3e8963 ../Body/m_rst_ca.htm +75a6b2a0c5908993e37c9835cc0d26da ../Body/m_setf_.htm +5b7f45f109529c1ad8a5b7776ec8a918 ../Body/m_shiftf.htm +90558b70cf183fb83a77125ca83d3d04 ../Body/m_step.htm +3e1e62c1a81107af0275f28c9695ba33 ../Body/m_time.htm +a5aa8aa0115e9ac5feec6648c7ca3985 ../Body/m_tpcase.htm +d5bc351e060644d97c0f657a29939a3b ../Body/m_tracec.htm +4b3d99ff01f3927e6b02c008089ceb1c ../Body/m_w_acce.htm +bf58381c4c27b291750178d3cf654384 ../Body/m_w_cnd_.htm +8e982e4b0380731168a886188f77d812 ../Body/m_w_comp.htm +623a4a17e48b0b548b9ec193717edeac ../Body/m_w_hash.htm +8eb9ff64912b1a7acf31d6b445c8c09c ../Body/m_when_.htm +744a3a14e9c6cdc58add7bb5adc10829 ../Body/m_w_in_f.htm +587e7b1bf15108de690f3a8e387ce89c ../Body/m_w_op_1.htm +502d4901fae5d3e8b1393d03c3dd9f84 ../Body/m_w_open.htm +8bdcd132b13546094e548da3e84faaed ../Body/m_w_out_.htm +7b0f33901b0b182b149ad8e465dbead7 ../Body/m_w_pkg_.htm +dbf6d4c55eaf550346a57710a0837a73 ../Body/m_w_slts.htm +63879225ef80798afc0590e1f08f31a7 ../Body/m_w_smp_.htm +2be3fab0c48525d800a0a27d7a294380 ../Body/m_w_std_.htm +9f89d6ac14481a8434714e9b245c4c77 ../Body/r_abort.htm +7d63100b728b44a23fa0fff22f8a85a3 ../Body/r_contin.htm +b7f0de896e43f75d30b7fcddfe916e94 ../Body/r_muffle.htm +014e282bb3531b1f23197d158f57ab83 ../Body/r_store_.htm +227ecdbb5f810e3a7196db4c14283091 ../Body/r_use_va.htm +3d83db273063bbc4a8717da6ae9d27f4 ../Body/s_block.htm +28ac33aadc20162b05cb838845351b69 ../Body/s_catch.htm +7029281ebb623b912d2fbc59b79fc4ca ../Body/s_declar.htm +115770ee698f959541dc0ae4a465ac15 ../Body/s_eval_w.htm +d1366f17a4f2186d5458b9f72023a15e ../Body/s_flet_.htm +3a77668114c22282a113c9d5bda5e5d0 ../Body/s_fn.htm +a8a4c1c9e9936f83620146be61337311 ../Body/s_go.htm +6bb0010de8b9feab8bf2d49b50e2dcde ../Body/s_if.htm +58a3de813749d5876e6b1fc4581607cb ../Body/s_lambda.htm +c543db7c990e1e8376a50abe3df3fcc3 ../Body/s_ld_tim.htm +cd8ee1de83c0e45db36246dd266f86fc ../Body/s_let_l.htm +e79d168bd1cb028ce435877152b0b63d ../Body/s_locall.htm +823bce24d5debcfa8f6699c9a09497fc ../Body/s_mult_1.htm +56b29ed9682d43891e693a92370482f5 ../Body/s_multip.htm +4b7bfc79d17f06ee5c8c6e9d001f2f59 ../Body/s_progn.htm +4032fae5b51da4fa3db7f3415ad9e3ea ../Body/s_progv.htm +fcd2687fcadb1e30b705420052604f2d ../Body/s_quote.htm +d8ff8f2cae1710d0ff4e5bcd1d160a86 ../Body/s_ret_fr.htm +dfd925a44a14a92bb51e83d27e8142ad ../Body/s_setq.htm +151411f404b7f1584f48fd1c5a144cc5 ../Body/s_symbol.htm +4a7cc3dd62fe95ba7d123b6cceea06b7 ../Body/s_tagbod.htm +8c20c66c665bb363d07485c845e72712 ../Body/s_the.htm +bbbc4b22e46bacddac952539bc431f87 ../Body/s_throw.htm +ff2ff61255fa86dd4f7cd773d137ef38 ../Body/s_unwind.htm +ff9e781f512fdd70474696368b6faeb2 ../Body/t_and.htm +4ed8326f68c857dcfa105ecacd8dd3c8 ../Body/t_array.htm +17a2a9b4bff3eb78344f0d508dc53e3d ../Body/t_atom.htm +5b9cf6659fafa728ee3e6caa5052f427 ../Body/t_ban.htm +f45c3b30587fcbe90301e3a5dd1c78a6 ../Body/t_base_c.htm +a7b48d1eb47b53a02e579cd228de9c47 ../Body/t_base_s.htm +f99dc0fefda230ae2f69b375341371f8 ../Body/t_bignum.htm +6f82f53c51ddd9ff9e7065b7b6a61c02 ../Body/t_bit.htm +22decb11fd7558da93da63aa150299ab ../Body/t_broadc.htm +f262635115730c674f76526a98f91df6 ../Body/t_bt_vec.htm +8ca143a5bcec7b501e39d6d5aacc4028 ../Body/t_built_.htm +843f92081835ab2ed0d544c1cd9167ca ../Body/t_ch.htm +b2cc2a0b415b33b48e9a67564065742e ../Body/t_class.htm +c58dd8252fcbad3e69b38336109537c9 ../Body/t_cmpd_f.htm +ed2703dc0b9f3a58a64d2faeb15e9ba4 ../Body/t_comple.htm +4b6bb7ada56480b625399cadbfd48f77 ../Body/t_concat.htm +2e52c021f7644c9218ee94d0f3826dbf ../Body/t_cons.htm +aa0416dc64d4e68c4bf243f15912c67d ../Body/t_echo_s.htm +e482b8e3877d76d67ea7e16c9b4f4565 ../Body/t_eql.htm +71858a0a1e31caccc059d71cc4bfee8f ../Body/t_extend.htm +24750b3b9bc0ef2df7b4a4b1ee76b7ce ../Body/t_file_s.htm +352632b1c90633bda026d2055d840e43 ../Body/t_fixnum.htm +14e55287053af011f1769719c643b199 ../Body/t_float.htm +97959e3d30f0d068159407e0e62c793e ../Body/t_fn.htm +aaabb7c5444893588813cb06801f84be ../Body/t_generi.htm +9b25d6f5c6472af3b02096980903f32b ../Body/t_hash_t.htm +30726f8f4b4dfb9fe0102b7abab3366d ../Body/t_intege.htm +c7b7760466fe388fec7e11c870522b32 ../Body/t_kwd.htm +e8165f9247d8be68736b8e3fd5c8a62b ../Body/t_list.htm +22c85b627c0e9be861bec2cbeb5d3925 ../Body/t_logica.htm +226a965ec2b67a67aacaadef9d952962 ../Body/t_member.htm +956ee25fc07045401a91bdee01dc41e4 ../Body/t_meth_1.htm +83b1a97d465577c531fce50a77b08941 ../Body/t_method.htm +73c25f8125f93c683da66136d9c31ed0 ../Body/t_mod.htm +7ad0a2e0a071b1d546cbb9a2f513e13a ../Body/t_nil.htm +fc7806bf586896eaaa33fba103640888 ../Body/t_not.htm +ba736bc467f2e867557078ccd2cd5826 ../Body/t_null.htm +c246b240cfc109aa9f4dfb50699b4425 ../Body/t_number.htm +6d3673007c99709dc7ed73e872f7c3b0 ../Body/t_or.htm +88321c654f4ae9270a3ee98cdd2ba1f1 ../Body/t_pkg.htm +fc441f835c8cc476cb94a870fcc8510f ../Body/t_pn.htm +33b4222991eb438e547ea37472f21feb ../Body/t_ratio.htm +9fb9bc99823f74dfa1b32cfd5f50ed19 ../Body/t_ration.htm +a42207ab964f9dd23e3225c5a2a36f93 ../Body/t_rdtabl.htm +ce81f6593317e8ca2a5e45ee55e42555 ../Body/t_real.htm +9a5336895ea0567e33e81ed59084515c ../Body/t_rnd_st.htm +239294d33ad82a1fdd39356c98b9d346 ../Body/t_rst.htm +81c26a1c0332857406d62c8ac0bec083 ../Body/t_satisf.htm +bc6ddb74b06d970555295fe08dbc2084 ../Body/t_seq.htm +597a9ade5f4b4f3900a78281ed06682f ../Body/t_sgn_by.htm +203bb6d12012d3266889de392ebe9769 ../Body/t_short_.htm +99659f6c8c293ff273d55b73916bbbcd ../Body/t_smp_ar.htm +6f41a72466d071746a7dfc1a1c53bc6d ../Body/t_smp_ba.htm +bd984ac680f817d653fc26771c5717c3 ../Body/t_smp_bt.htm +82a31f15eb7c0868bff0a65becd277f0 ../Body/t_smp_st.htm +2a8d0dff8180c108320a181f235072a6 ../Body/t_smp_ve.htm +a4df144512cfcb656327dc8257bb0540 ../Body/t_std_ch.htm +57d1a8f419d752a1268c4cd033fc3ebe ../Body/t_std_cl.htm +adb6eb3e27a0b6f458b764e79b43b7b2 ../Body/t_std_ge.htm +4554e2610bcbbb00475f522199b3caef ../Body/t_std_me.htm +33eb6ec6791a494f611983ea4600db8c ../Body/t_std_ob.htm +f1fd0389084bfc760c107d18fa15d5cd ../Body/t_stg_st.htm +b9f5ec6f41d68be4604b1d1c02ee7d83 ../Body/t_stream.htm +9e5a050e520666a93fa6f4afa6bd0649 ../Body/t_string.htm +3d99e237b6dd47afa1259f58c666cb7b ../Body/t_stu_cl.htm +111196836c9ee2f95f61f66a8f25c8c4 ../Body/t_stu_ob.htm +fc8d054c90df1cbf5be7400c8ca16190 ../Body/t_symbol.htm +65d248d760883532aca899b03c6d8097 ../Body/t_syn_st.htm +8779699c8f2dcb483782ef30978ff48c ../Body/t_t.htm +0b7fd285639ebb26db4de39ca85b2747 ../Body/t_two_wa.htm +917612dc9a086ecfd555bc890adad8c5 ../Body/t_unsgn_.htm +be0b17664130f0ded141467db5ca0b0b ../Body/t_values.htm +c06a3998567d20221015de5b7f3c9250 ../Body/t_vector.htm +bc2527454a3ab983f345878934dfeb02 ../Body/v_ar_dim.htm +1520832dc985788112e5527eb65d07d1 ../Body/v_ar_ran.htm +b5e3f8e248ed42c296710514cbf6d1a7 ../Body/v_ar_tot.htm +199b4e07780417c8ed4359fc20839b28 ../Body/v_b_1_b.htm +d9eaf3ce8c3cbf0476c4114495b2911f ../Body/v_break_.htm +dd0bb76b23038d49a5e4cb6696e572a1 ../Body/v_call_a.htm +396cf57ee2b4169f08dc230f00686989 ../Body/v_char_c.htm +463ba4e527835c2bed970c9b3c0ccbc0 ../Body/v_cmp_fi.htm +571c63e2c9e48166a5274aa98153c324 ../Body/v_cmp_pr.htm +c80072ef325981628e4be95e345cf180 ../Body/v_debugg.htm +1b92a0cb3cf1c4d394059145bc0599b0 ../Body/v_debug_.htm +b783ba261367b1036ebf9892e5ed1a75 ../Body/v_defaul.htm +190aa990057c4c58e818e5d8fa3797c6 ../Body/v_featur.htm +bde8eb7b230d0df626b59468796f49db ../Body/v_gensym.htm +e1a565a57ac6f882a0c89027930a89c0 ../Body/v__.htm +a6ced29bf934e19bb622cc9ec7ade19c ../Body/v_intern.htm +6cca80fd3113d505701dd2a8056c9550 ../Body/v_lamb_1.htm +7027051ef76c48c1bb0323f7577a177a ../Body/v_lambda.htm +181e40663551d73f51d863241638ff58 ../Body/v_ld_pns.htm +267e6a3e0ecfc27c1039f8aa80629876 ../Body/v_ld_prs.htm +56d633ac1e70802081cefecdcc61d91b ../Body/v_mexp_h.htm +74d091ab1e659e34c1fc252083c4e9aa ../Body/v_module.htm +f1ce5ff23e710a9465bd0c0469210c4d ../Body/v_most_1.htm +a089d9d55d04a7c1ec15e606cc72fd74 ../Body/v_most_p.htm +9b2ae3e4a4cb38e7062c15ae40c84c6c ../Body/v_multip.htm +30723636c5bc4de518ed1d044c46846a ../Body/v_nil.htm +52be7511e239981f6d8dd630a7d19b0a ../Body/v_pi.htm +0f65808c4345625afc4bbb02005be455 ../Body/v_pkg.htm +cd3e760ca95c5233dcc936736f966a52 ../Body/v_pl_plp.htm +0f70b27da12dc11e87ac919f355541c8 ../Body/v_pr_ar.htm +5f59c1c22ce075e031b7469e3a383cf9 ../Body/v_pr_bas.htm +39a2a3e260338880f2eb2c60213e6e1b ../Body/v_pr_cas.htm +e8ee051952b6dffff6acff80e593976e ../Body/v_pr_cir.htm +611ab04f9c2b8efa92c2722586cbb64c ../Body/v_pr_esc.htm +66d3306be5210477e59eaaec7649b40d ../Body/v_pr_gen.htm +72d60a16be39514c0c038700936d66c5 ../Body/v_pr_lev.htm +34b0e51b8f674d965f2d5a5d7f2bb092 ../Body/v_pr_lin.htm +4ad0494a99df995887bda532de49fcfa ../Body/v_pr_mis.htm +bc4c578eb4d6e540c4440a1c80f5d9d5 ../Body/v_pr_ppr.htm +a3c126bd03012cd40f5c3b75a1e922d8 ../Body/v_pr_pre.htm +41191ecdb8f0bcf43ef19b672e765aff ../Body/v_pr_rda.htm +6fa046fc712c219f99a17be93b91dbd0 ../Body/v_pr_rig.htm +536fb1363d2c6f8380ec196fc5476ab2 ../Body/v_rd_bas.htm +bacebe70e1ce94e4d0f6290dc88c382f ../Body/v_rd_def.htm +0b3c887bc8fb9b6ace04d491c83f1c22 ../Body/v_rd_eva.htm +2f14d88b9793a1baf3286a6b8153c9e8 ../Body/v_rd_sup.htm +c254294674d890b8145d30d8c2bc69ee ../Body/v_rdtabl.htm +277b1419cd26b002dc52b834da6fad1a ../Body/v_rnd_st.htm +7152a0f1c70c45420414994cdab36e25 ../Body/v_short_.htm +a96b9a8bf3e00eef8e5018b656e820c5 ../Body/v_sl_sls.htm +ff3f9131a21061d3b025bb042a9405da ../Body/v__stst_.htm +ab0f531ee26d12b1a230ae1607fa4ea4 ../Body/v_termin.htm +9954e490cbf535aa3d928cc6d58442c2 ../Body/v_t.htm +b8286fff7807e0184a49a95e1ee1a9cb ../Data/clhs.css +b8bdee6744fcfd0209f29de02fc3e021 ../Data/Map_IssW.txt +a151e1341f49a77ca493ca62f19e8d6f ../Data/Map_IssX.txt +a236d0aa11a74008ac76bc61862182f5 ../Data/Map_Sym.txt +854c94b58f1379caf26d007f345a97d2 ../Front/Contents.htm +a207e28165ef69263d1c758ddd66af87 ../Front/Help.htm +2c8cd2b3fb730145f7049ba9b41e70f9 ../Front/Hilights.htm +b9c66cdade2501e7f68f16920f26546a ../Front/index.htm +28973f6f030cf28bf716bae117505d7e ../Front/index_tx.htm +b754d216ecf0a3f4e9de56483901720d ../Front/NoNext.htm +428165281e1d9a9062da5668690ffa09 ../Front/NoPrev.htm +f98f23e3353ce4b5efa47a8dc2862572 ../Front/NoUp.htm +b1e8b95568521cf9d0cd90349a9f386e ../Front/StartPts.htm +cd84506d81856d80faa07a9b41cc9dbc ../Front/X3J13Iss.htm +2d0e5ada9321703fba9c45905413a93c ../Front/X_AllSym.htm +aceef3797dc79923cd04f0e465ef3c89 ../Front/X_Alph_9.htm +31dcac8d0cbc2a1beac9769d57eec3ce ../Front/X_Alph_A.htm +2d1cac412f37f7eaad6e17944aa4b8ff ../Front/X_Alph_B.htm +84b115ac4940261bc25e781317d0d955 ../Front/X_Alph_C.htm +36d7e433c6a905e07bbde1668abea72c ../Front/X_Alph_D.htm +7a23f561749083fa43d95ae4aeb43c71 ../Front/X_Alph_E.htm +3d42b42e555c85888d92b3456533262c ../Front/X_Alph_F.htm +d4350d583de92f71d7b9d8b43e941aff ../Front/X_Alph_G.htm +babd8c6abc173932143c2d6b9b7f288a ../Front/X_Alph_H.htm +61238510eae10ef870579b468e1baebc ../Front/X_Alph_I.htm +1bf8b2a325d9e43ca5f28cd3b7ea76d6 ../Front/X_Alph_K.htm +608aa612c5f9c0661c6de7551fc3d622 ../Front/X_Alph_L.htm +9f2e1f53070f06ae3941a384b261910b ../Front/X_Alph_M.htm +943b49a406bbee9a92248310c698e749 ../Front/X_Alph_N.htm +2fbc7f805fb81ab8fbe32a37f52dd2d5 ../Front/X_Alph_O.htm +b912dd8620cb608fd451187b86e3fbb0 ../Front/X_Alph_P.htm +e39a88c3e4507c9863cc6f1515d681ea ../Front/X_Alph_Q.htm +fa99c050c2430c9bb9edffe44347dc1d ../Front/X_Alph_R.htm +fedbe66297df792aed557b78db12e8e7 ../Front/X_Alph_S.htm +2f7d879b67c9aa366962d08a682329bc ../Front/X_Alph_T.htm +ed0c2bcec5a6ba9ddf0ebcd8a9acb494 ../Front/X_Alph_U.htm +7f6fb24415fdb665a07944500a5a08bc ../Front/X_Alph_V.htm +b823239c033ef5e2faea3649b4342629 ../Front/X_Alph_W.htm +b1c5950c8aada0fe9bbbbcbfae28e822 ../Front/X_Alph_Y.htm +6485a6cd5da18ca241a3530048b60583 ../Front/X_Alph_Z.htm +13cb5f9c6eb2d409563f710771731d99 ../Front/X_Mast_9.htm +916bdae69fdde995d2432b1f568ab5b8 ../Front/X_Mast_A.htm +b0d89a4fb15f8c2e5c3e96d98deedf51 ../Front/X_Mast_B.htm +7ff230d07e479e1dc737ecfb00afe850 ../Front/X_Mast_C.htm +e1e9169b92ec2c86dcffc8e060dd6b82 ../Front/X_Mast_D.htm +5c1717c6b92fa406101d7541cdf29cc3 ../Front/X_Mast_E.htm +bfb236e1ff9b2187b575544e50b66c69 ../Front/X_Master.htm +5b50091a2159c3faa5e672ed4e9308c8 ../Front/X_Mast_F.htm +6d1ddd6f06f130e20811a57fc4a8d590 ../Front/X_Mast_G.htm +aa68ce9cb6d3e40d1d20930493e27bd1 ../Front/X_Mast_H.htm +ce10c0964c7dff09f55378c6ecb21bc2 ../Front/X_Mast_I.htm +ebd600c8949e65648995bf43649ad0b6 ../Front/X_Mast_J.htm +144d7a0b88528f76ef82e67a7fc1caf0 ../Front/X_Mast_K.htm +613b9c7c037cf373f08018c3423f2e28 ../Front/X_Mast_L.htm +ae40967e05b74aa374ce4cac653efe27 ../Front/X_Mast_M.htm +5b899d6a7097825d0f3aa0017ef7e532 ../Front/X_Mast_N.htm +abff217c21ee6328f5b6739301e438b3 ../Front/X_Mast_O.htm +07a61af8ccfc29af7146257a2c38432d ../Front/X_Mast_P.htm +0bbfd08d39fcb1ec0f7a41e8af94bb54 ../Front/X_Mast_Q.htm +6ed56f7b0da772030beb92b1d9c0366e ../Front/X_Mast_R.htm +784755cf8d91f8a80fa82b968d08b2bd ../Front/X_Mast_S.htm +e2835e870bc8274fbd02c6e322532cf8 ../Front/X_Mast_T.htm +3a1c30fc8c2001bd138e8c9801b090ad ../Front/X_Mast_U.htm +ccb8cfeb8cf9c62b2c4cce672f5b5b14 ../Front/X_Mast_V.htm +11281205638fbd05891309c1cfb09807 ../Front/X_Mast_W.htm +f23a28bbe07db946a75eebac997800ec ../Front/X_Mast_X.htm +7c758fc70c6ce71f0697fb968cb503cc ../Front/X_Mast_Y.htm +d9df453fce0223a442f53adef389f8c9 ../Front/X_Mast_Z.htm +e7bac24d8a233bb53f4bb6192be1f1f8 ../Front/X_Perm_9.htm +6461c0e71131fb88f7d3da8aa2d19194 ../Front/X_Perm_A.htm +a5a5394e6fcedd40687e6c7e2775a932 ../Front/X_Perm_B.htm +dac8a42293397c5fa2950cdad3483dfb ../Front/X_Perm_C.htm +88139cc65ad9df48fdee03bf7b2d3cac ../Front/X_Perm_D.htm +be12e0f549e0205134c733bfbfa6ec86 ../Front/X_Perm_E.htm +10641e2840ec8c488364e8c9825ea618 ../Front/X_Perm_F.htm +8e532bc66fcfa881aa2bc5e0cf43ca84 ../Front/X_Perm_G.htm +a9d90939de999cf3e8d5c9d0b5512ea7 ../Front/X_Perm_H.htm +f64c2589d6d921f524efcb2ff7bc124b ../Front/X_Perm_I.htm +4226635172863533ea137f96c61ece75 ../Front/X_Perm_K.htm +854aad846168baee9f5a4f7a45468235 ../Front/X_Perm_L.htm +795919b1946c9eead6455c714eb9a048 ../Front/X_Perm_M.htm +9f59cc45910df959e5589da19d802b43 ../Front/X_Perm_N.htm +acfd69b21b29c155d90262e06c5d0c43 ../Front/X_Perm_O.htm +7075843aa5496b1d1f642fa5ad585b96 ../Front/X_Perm_P.htm +7cb7a13831a86ff574a4896920af3b8f ../Front/X_Perm_Q.htm +bc92deecf0171b934b081b6a658321ac ../Front/X_Perm_R.htm +a0ebbee308b90a42fbaaac1b7a53085e ../Front/X_Perm_S.htm +99a6f2bbf2eb6a2b75970e9521af9ef1 ../Front/X_Perm_T.htm +a0d828f80a1b9e15d2a929de1b45c184 ../Front/X_Perm_U.htm +f6cb1971302e81e4f8ec4925dd445dfc ../Front/X_Perm_V.htm +0c34a5d2b9271ffefce0e2dd0d61b2e7 ../Front/X_Perm_W.htm +bc963cfd5c2c6535ab4f956bbf6cf57b ../Front/X_Perm_X.htm +e88023ee762dcd7dc1d0567c9c679775 ../Front/X_Perm_Y.htm +670d816ac3f5f5f3500028fc7c49c436 ../Front/X_Perm_Z.htm +cde2c0d912457546b6f6046b72a4db6c ../Front/X_Symbol.htm +a976e221ffcc42249d4367531dbd8334 ../Graphics/CLHS_Lg.gif +1d773fd5e4fcd95ab39f92f41d0bbb81 ../Graphics/CLHS_Sm.gif +771dcba7ec9d65ff2b2fc359f35b9d36 ../Graphics/Contents.gif +335a7e9c36e88120b76a003ce5573f06 ../Graphics/Glossary.gif +e09ca144f6fd305e2904113ce813934b ../Graphics/Help.gif +4e5cf491ff18a919e79abced9fc3f419 ../Graphics/Hilights.gif +ce977f861b213721d9f24ce42624474f ../Graphics/Index.gif +0e227b69970b53dcadbf4d57ae33aeef ../Graphics/Issues.gif +78fc53fa622736d568b0ebcfee8c3167 ../Graphics/LWLarge.gif +bdad98f917cb512e856c353fc6d95c9a ../Graphics/LWSmall.gif +530683190b5bd5f91467c575360d26a6 ../Graphics/Next.gif +0ce2508dd1f97b1d87e23d21bedeb528 ../Graphics/NoNext.gif +ddaf43439a41a45eb9cd7310d9ba499d ../Graphics/NoPrev.gif +ff1675ebd50dc6921b7ecce10dc9a202 ../Graphics/NoUp.gif +dc24dd425709f3f3204228fbda399c26 ../Graphics/Prev.gif +e2bcc93a0bba7df3b723342df274ecdf ../Graphics/Quadrant.gif +72ac3591ac9e67352a6d4e902537e330 ../Graphics/StartPts.gif +0fdaa67533dc984bb7f97374249c18c8 ../Graphics/Symbols.gif +579eabef113684206f3efa28eba65e11 ../Graphics/Up.gif +f62d30980d6c62c7130c2641876df236 ../HyperSpec-Legalese.text +b655d433f671da8c1c50a8b49c331a73 ../HyperSpec-README.text +ee5f32bc211b8d1e299b4fbda8692125 ../Issues/I_Alpha.htm +80e4d38c33ccd2fab4263d580a00ecdc ../Issues/IC_ARR.htm +610ba139700b3cbade9a3aa02e780fe3 ../Issues/I_Categ.htm +fd999633b7af095405129eac93137a9d ../Issues/IC_CHA.htm +ab7da05c55f0f147e0995d7b272bcedf ../Issues/IC_CLO.htm +9528bb2356114a4a780e2917749550b2 ../Issues/IC_COL.htm +a7384e2dcd42b1e33ba140792a814eb1 ../Issues/IC_COM.htm +b8d67357040271bdc7ac688681e5c96b ../Issues/IC_CON.htm +11cf0be7b8b789c68437d96122657a0f ../Issues/IC_ENV.htm +9f5345fea85e9d529f915f95ca377c85 ../Issues/IC_FIL.htm +c403921c3fda1a302e38bafa1336d65b ../Issues/IC_FUN.htm +a825a2009aae4d9eb0d5b89ae43825bf ../Issues/IC_IO.htm +2cf6b0a6014b7b6a82ea86ea8fd68f8f ../Issues/IC_ITE.htm +659063ad477a6d731a2a9ab6a790a8bd ../Issues/IC_MIS.htm +0865d1fe5ab734c5c73a093dd401e0f7 ../Issues/IC_NUM.htm +6b807755273939765a87c61bd8477711 ../Issues/IC_STR.htm +2caee46c302ebddfa3f1ce71e180ee54 ../Issues/IC_SYM.htm +fd6c85d266efe4d404f68f25ed1390f8 ../Issues/IC_SYN.htm +97b3b16c9ea501dcc52cd808fba0c66c ../Issues/IC_TAB.htm +19bd45d4cd1ebc4e8ab492698140de8c ../Issues/IC_TYP.htm +896db8668c18c62797abfa0c1aa159d5 ../Issues/iss001.htm +57aab4282164f227d56f741818b5fcc2 ../Issues/iss001_w.htm +abbb3ef8299a3d46141677b0d09f251b ../Issues/iss002.htm +9c86d4e4edf90bb7c2b20a9a7049da41 ../Issues/iss002_w.htm +28ffab8ad67f964328f41bfbe6a2fb6c ../Issues/iss003.htm +bc5e496c0c4ef90375720a52f0da6492 ../Issues/iss003_w.htm +a024775bf3c2e372120c78a8ea0cb42a ../Issues/iss004.htm +2b55a24b35af2763692a3d68ce205441 ../Issues/iss004_w.htm +1df3fcf9cfd414b30cfc8939d5b433ba ../Issues/iss005.htm +f08cc1c4345e663a1d2399ce16023a55 ../Issues/iss005_w.htm +706009e9ae57f9b6f924758959226a02 ../Issues/iss006.htm +3ab406ac08224ce38f3acf51a04cbfb0 ../Issues/iss006_w.htm +deaa620cceb931151632c03740498837 ../Issues/iss007.htm +bbd8877d6710395abdefa55d88037847 ../Issues/iss007_w.htm +33521ec99cb465125eb5f510d1e760ab ../Issues/iss008.htm +8a26d72c911f0dbfa849e89166138bc3 ../Issues/iss008_w.htm +fa71897ee931a12c54971a440c756e40 ../Issues/iss009.htm +4cd79684bd2081792502172e32516390 ../Issues/iss009_w.htm +4eefdd28ab41c0fcbbfb2a95256ffb1e ../Issues/iss010.htm +99a1ed041889110e80331e08788ba1c7 ../Issues/iss010_w.htm +4656bd6464276e22b42a85bfc976e7ad ../Issues/iss011.htm +2a1540afef48af585a572d1a758fe3b6 ../Issues/iss011_w.htm +0d8ed209517568690e64074c2d0ca457 ../Issues/iss012.htm +cbf54d86765d70a3d101ac1b6f4f312f ../Issues/iss012_w.htm +59c38375bc685a86e3c2f2e21ea2a04f ../Issues/iss013.htm +0c0495669623d1f4bbbaf4c299e90eca ../Issues/iss013_w.htm +9bb77f2140683f3afaeab314f356de9f ../Issues/iss014.htm +5375c9182c7fef3864ba487c9f376d01 ../Issues/iss014_w.htm +7e0ac49e6055cf83676a532fd12db0b5 ../Issues/iss015.htm +f203d3f2e6962368da7f25afe75f1437 ../Issues/iss015_w.htm +0a75b0a9e62df91dab37b63c01da4be1 ../Issues/iss016.htm +cc5a1570cb4fd42dce853b24187ac1a7 ../Issues/iss016_w.htm +9e33d975f6c0bf34c0440b76885e9e25 ../Issues/iss017.htm +de72015c092a890f18c242bdfdf5a429 ../Issues/iss017_m.htm +0c96efc61570918df5092cdc4a1af348 ../Issues/iss017_w.htm +3e3f8e75b3a407f0a8805f5d433259ac ../Issues/iss018.htm +8ca8eab2acc22d6571bc794d77487e47 ../Issues/iss019.htm +e79110e3d31877bc1de361f83fe3bac8 ../Issues/iss019_w.htm +52ee93baa08b028b3d28a27df77e5aac ../Issues/iss020.htm +c48163ca8b7a601146e4997159d9c01c ../Issues/iss020_w.htm +76c2752c024800c1f615d63713352d2a ../Issues/iss021.htm +85179d5a29ae04f292f44f275e03c1a6 ../Issues/iss021_w.htm +9999a6e787b8ec037c40254e89124bd3 ../Issues/iss022.htm +4712d2526e8e35515f8da81c84f236c5 ../Issues/iss022_w.htm +b39fa153715cf1745eb57bed93666749 ../Issues/iss023.htm +9e6b8ec6642277e0536a74525a18de47 ../Issues/iss023_w.htm +4a40088268c4b7b46505e2805a2342e6 ../Issues/iss024.htm +1cf121d5f2731a6e6e5c574d28f7f675 ../Issues/iss024_w.htm +32d61df18fd3988444624ca7e449eedf ../Issues/iss025.htm +ea4f43472e6a753b68d92fb14b55246c ../Issues/iss025_w.htm +b723f1f8ad47cf00e060f42c2d198f55 ../Issues/iss026.htm +af275e48d076ae42a1e457e4c3148b0d ../Issues/iss026_m.htm +e717c76881103e35591972f4c9b74c95 ../Issues/iss026_w.htm +36b37f7e7d49dd7a31ce6248207135f0 ../Issues/iss027.htm +8bb00faa2eac7c6bd9deefaa1e1c3033 ../Issues/iss028.htm +ae3d9fa89477059ddc25ecb6c2d1f9ba ../Issues/iss029.htm +7e09a878dfd7294df30fbf5012d6ae4d ../Issues/iss030.htm +d72e8fc8f99711c0e5bfe725ea20d7b7 ../Issues/iss031.htm +07ce48901b0c9654fb7a1368e74f1c12 ../Issues/iss032.htm +22cf01481ffa943cd7dcafd464577369 ../Issues/iss033.htm +7cef497343ca69424df49947fcd04079 ../Issues/iss034.htm +9cf48ff14993ce22913e14b97a6a3d2f ../Issues/iss035.htm +4011f110cf15afea7ae8bf250798e567 ../Issues/iss036.htm +e127d642cceda5e71831ba5360ca03f1 ../Issues/iss037.htm +5e1d80cd9d75d414a40473a7a04d7357 ../Issues/iss038.htm +541343b5ee22578cd06feb472b12752e ../Issues/iss039.htm +ba1c1e30e60a7add7efdb750cd2c2b4f ../Issues/iss040.htm +52c3719344c8e67d5ac9a3d9a2e0f448 ../Issues/iss041.htm +2ed10952cc6ab30d95aebe04c9bd3b45 ../Issues/iss042.htm +432806d832a3230b2935b2ffe4b3d477 ../Issues/iss043.htm +77752b7787380ecfa6f6287c818e41a6 ../Issues/iss044.htm +a86efff202d84f554b05e332647f4447 ../Issues/iss045.htm +26d1548ede04207618264d49a2dc5fa5 ../Issues/iss046.htm +2f5a4860941048d2c4b09a40a0c31873 ../Issues/iss046_w.htm +ac8d93e3103166021477076839f6968e ../Issues/iss047.htm +b3ba933a4e8d6743a7de9da4ea156bf0 ../Issues/iss047_w.htm +53b6c0f45b039347abc67434be8021ac ../Issues/iss048.htm +b95fd52e6f5fba6244535ece9400b3f2 ../Issues/iss048_w.htm +536a1f513454247ec49f1549070382ff ../Issues/iss049.htm +89b0e44878826c093801b1627bb94ef9 ../Issues/iss049_w.htm +5faa6b254c6f95d49c0b01bbbe6908dc ../Issues/iss050.htm +24a363b839060e11589dc27dc6869079 ../Issues/iss050_w.htm +0f1ccb802412605446c4ac15fd512cbb ../Issues/iss051.htm +be1f7fd77da3ac10711155639213c782 ../Issues/iss051_w.htm +ddbf5685d3918e97dad1d6df16d0cd7c ../Issues/iss052.htm +f6ee58b64f3b13a0638613b0e0c6da7f ../Issues/iss052_w.htm +dc70bb45fa24e0251f8f5922bd80308b ../Issues/iss053.htm +36f48625b6efcbfe01a704668589a591 ../Issues/iss053_w.htm +af9462f0fca2a657007445a7720b53d9 ../Issues/iss054.htm +150db1d4d818acf6a5d9192bbc97da1a ../Issues/iss054_w.htm +a1a345932a7b5c764d4e7f40e437a79f ../Issues/iss055.htm +3f76723f33191abf7dcdf9c96105df17 ../Issues/iss055_w.htm +a1c4c39850deece2953ee2d5c87457ab ../Issues/iss056.htm +9b60995b6069f64db08e004879702c02 ../Issues/iss056_w.htm +4b3bb135ac75b921d7e431d788fe850c ../Issues/iss057.htm +74fc1ec2d01c8252daad4ab6572d7d2f ../Issues/iss057_w.htm +d606a6e14cd060ce2de94673143c99d6 ../Issues/iss058.htm +f7f97cf1d430d6a165cfb93abd2d3b18 ../Issues/iss058_w.htm +e71e013fb57fc6e1f254b6fc8843603f ../Issues/iss059.htm +1749a2d79a3aee0dd342219b9aaf22ac ../Issues/iss059_w.htm +7aa57178ec439845a84a5cf857333b90 ../Issues/iss060.htm +339134786509507cf44756b314a5b6aa ../Issues/iss060_w.htm +9f7944a3fc07c7e13a6d5dedd25aebe0 ../Issues/iss061.htm +76b4445329ad23d9a22a1c8bacfc3465 ../Issues/iss061_w.htm +c149d4a4002c0dc77ae701983ffb23d4 ../Issues/iss062.htm +208de358f59ec5cea80bea932dc492bf ../Issues/iss062_w.htm +a216c940622ddaede270a216d4d0958d ../Issues/iss063.htm +9d0e24bd92001ad51ccc1f4551ee7408 ../Issues/iss063_w.htm +58f14362b0482d020dd31390f21d9d12 ../Issues/iss064.htm +6cd1233e315470b6c3f5b9b54ce2186d ../Issues/iss064_w.htm +de2da13e20b524da954b5e16131f136b ../Issues/iss065.htm +b197299171e86b236ba2c0e51d44d561 ../Issues/iss065_w.htm +3be647caf2f962d9c38be6a02c0fa7fc ../Issues/iss066.htm +bdcdc4b5a75b83b9fadd6eee2f4793bf ../Issues/iss066_w.htm +36ed22e360565d8e4e0f971be7c7d8a2 ../Issues/iss067.htm +bb4740cd37ac6c31f508bf70881097bf ../Issues/iss067_w.htm +c03a55d330d8f919d65c6e14825d014e ../Issues/iss068.htm +d8025d0a95314db48abd4b7c444e8cd9 ../Issues/iss068_w.htm +221abaffe34057f2b6def79182341d02 ../Issues/iss069.htm +58d3c4969e5266f47545912b226e4ab2 ../Issues/iss069_w.htm +9c400e4280192591ed6bb5ef134021a6 ../Issues/iss070.htm +1729df80ea24be4f2a5d9533d354a19e ../Issues/iss070_w.htm +951a93a738a5a948b8c36f810d7e5786 ../Issues/iss071.htm +cb81d0df7d1fc713a3f5e25817584f60 ../Issues/iss071_w.htm +f6aab9643369c739aabd07aa649d5ea7 ../Issues/iss072.htm +2eb1e475deb4de9b3edbe62f4f5b59f4 ../Issues/iss072_w.htm +48adffbae24b0f3c404829166b45dac2 ../Issues/iss073.htm +0788cb4aa921d373647e95b8460a099c ../Issues/iss073_w.htm +9033a32e9b7e5bf25bd7e72ed964a3ca ../Issues/iss074.htm +8a89494edf4b34ba3c8bc1aaaa38546c ../Issues/iss074_w.htm +8090ec5cbe396c3cb362864503cceaa1 ../Issues/iss075.htm +fe7a0e63b94a9f10d84983a626a0acfd ../Issues/iss075_m.htm +77f400edbe2c48f899fb6faad4b82cbf ../Issues/iss075_w.htm +d0160b3d380c35f876cff0833389ec3a ../Issues/iss076.htm +cc65912a705be7d4ab567114e310d388 ../Issues/iss077.htm +929e3ba10c4bc6e6afd93f817a0bfa79 ../Issues/iss077_w.htm +840bb8cbf7cd1cccbb3f4f8b3ff0ee95 ../Issues/iss078.htm +4f4861131409c9db0a3ed5707c1bd45d ../Issues/iss078_w.htm +c924113ba943926a72b5e537e7ee4d14 ../Issues/iss079.htm +2c5a418b1808d36c4d830de4f2361e45 ../Issues/iss079_w.htm +ce3380fa639684f0d4c99b0caac42ad0 ../Issues/iss080.htm +59ebef7e78077028abf796aff31fed6e ../Issues/iss080_w.htm +c6c100d9014a642d309d3a7911633836 ../Issues/iss081.htm +5cd5f74df047c1c74075b6a14b13f1c8 ../Issues/iss081_w.htm +bf50d60d73485f0440b1652979a5c1c3 ../Issues/iss082.htm +4a82842aae9627efa416219b22904657 ../Issues/iss082_w.htm +76dbf3fe119d1dfa17ef361d0bce9013 ../Issues/iss083.htm +d1d876eb64282f12f14a3abb50fcad5d ../Issues/iss083_w.htm +80d92959772c6cb6e19be4b74dcd0d88 ../Issues/iss084.htm +5a0a2275995f75f54033d43c9fabbdfe ../Issues/iss084_w.htm +1870c7f8654035c7f0e7fc229004a9f0 ../Issues/iss085.htm +2fed6b8635c42af1dea493e212d74556 ../Issues/iss085_w.htm +a689f475c055081bac1e2e4bc5094ec9 ../Issues/iss086.htm +bc2d8bdf922ca242aabf1604fe8c5811 ../Issues/iss086_w.htm +0322a588041059174d07dab65099f4d2 ../Issues/iss087.htm +fb2a4253a62db0131f8d9278ce6121fb ../Issues/iss087_w.htm +e6aa91d3c985349a91bc9a08436142cb ../Issues/iss088.htm +3665b82bcf01ccb0a4c7d2a527fb38cf ../Issues/iss088_w.htm +24129388de83f294de153b620ed3b8d2 ../Issues/iss089.htm +5d1a44a6c3c453503ca3ca663ca78ef1 ../Issues/iss089_w.htm +d07039e11b95580136eb8c09cbb31f76 ../Issues/iss090.htm +83332c7da53cb04c57b55713111a1bee ../Issues/iss090_w.htm +e6a329efd96efe9a3f47807d8b379e02 ../Issues/iss091.htm +2848eeb932320a6643b3af017fc4f43d ../Issues/iss091_w.htm +eb568204be6cef218d1ff95151cd59f9 ../Issues/iss092.htm +203d649454d6f385834ad789bd9846ef ../Issues/iss092_w.htm +d4f91a32c1c4709de5dff175e02f64c4 ../Issues/iss093.htm +0d10f275e5c09d7a8952487a6246652a ../Issues/iss093_w.htm +5ddb88616cef92a0cde76984c5bbf8dc ../Issues/iss094.htm +59b91399f052b789ea1abb03afee870b ../Issues/iss094_w.htm +2e5c4c26916fe79428075a1e643c4558 ../Issues/iss095.htm +fbee5234b5b83004c6cfa198fd33d2f3 ../Issues/iss095_w.htm +874a388c6820b86632e0fb95a32085ab ../Issues/iss096.htm +0e93fb7c826eafadf4867711e9adc47f ../Issues/iss096_w.htm +2b445d657e1d3775c0cc785e2e287397 ../Issues/iss097.htm +f8d9fead42b072cf945ff54a0d9fad98 ../Issues/iss097_w.htm +7d7ce5451d9a3dceffe8f5e9a1481b4c ../Issues/iss098.htm +7755b2b1281672be3d554533705fddec ../Issues/iss098_w.htm +e7fc1964c7112a4302f8f6bbd207addc ../Issues/iss099.htm +5ddeba9c5d7fe148622ae9d8b9247b56 ../Issues/iss099_w.htm +94d9ee1cbaa689b2ed9e0e749733b8ee ../Issues/iss100.htm +6997fddfbd56356e8168d4b7145f32a5 ../Issues/iss100_w.htm +85104639f43423e8a725ffa23b6f2bc0 ../Issues/iss101.htm +006b4f9e52d201a21db7fabd1bf72274 ../Issues/iss101_w.htm +964e58fcd646edc2a66aee2e8037a3ab ../Issues/iss102.htm +3f0436d24115254810648cc9f254c86e ../Issues/iss102_w.htm +299fe10a9741f64d63d1c1c9f440ad5e ../Issues/iss103.htm +41c40c60c2b535bac4081ae0203f3f07 ../Issues/iss103_w.htm +a3637cf91332725b95150f954dc5d926 ../Issues/iss104.htm +532c3379e858a4e924e6581b933cd360 ../Issues/iss104_w.htm +86bca0bd9a10e0d7076eed26649b8faf ../Issues/iss105.htm +8131bbbb98d3669a47f81457dc9950cf ../Issues/iss105_w.htm +4b935bcacf62b4c57cc76fa1132f9778 ../Issues/iss106.htm +e2b7dee32dd246b4f62973826b5031f2 ../Issues/iss106_w.htm +533af885b369bbdd6413111fbd1d2130 ../Issues/iss107.htm +674baefca7ffdfffbe0d67a94f5612e5 ../Issues/iss107_w.htm +227c8bfa007360f5398a73cde979a981 ../Issues/iss108.htm +d876cd595ace54a310183345c94293da ../Issues/iss108_w.htm +02877f14a0ceac9c6669c7aa3bec0aa7 ../Issues/iss109.htm +6ecb7c125c8c7630b96e02e0bb235060 ../Issues/iss109_w.htm +19ec292d9fbd4df9f3423d78d13d8a90 ../Issues/iss110.htm +1b00ebba6b0a1e63cc0a4d8818ca3adb ../Issues/iss110_w.htm +96a29e756cb46a18a4d871c5609ed13a ../Issues/iss111.htm +552dca94013fb518d4a4d19d4c0fc002 ../Issues/iss111_w.htm +8906be233bb406aec4438f7385794067 ../Issues/iss112.htm +95e365a67c5c0880a11b68549a146faf ../Issues/iss112_w.htm +f70a5d3407a7665ec5fdaa410f4ff4cf ../Issues/iss113.htm +8e4f4f865f3623382b5c391a4dcca554 ../Issues/iss113_w.htm +188b7dd5ef715c862efdda2d3e29e1de ../Issues/iss114.htm +cf047de8dafa5308028c15ef2505b0ef ../Issues/iss114_w.htm +52c94b200d7ae9ea87e7ea097a572010 ../Issues/iss115.htm +d774b6396456b05873027a8b1744f194 ../Issues/iss115_w.htm +d64c36c3929a8c8851c2869a6a082adc ../Issues/iss116.htm +53a7cc14c9751b08ec8b54d1190820cf ../Issues/iss116_w.htm +52917ec70e7c00f353c041d979a96bf2 ../Issues/iss117.htm +f46d8ad25f936cdca977eee2be4d1a4b ../Issues/iss117_w.htm +69ee3d86acc867821333d17069177b8b ../Issues/iss118.htm +cee35dc7574dd1454570ed734765cfc3 ../Issues/iss118_w.htm +a7863a1f52ed7c2c991a5006d991e24a ../Issues/iss119.htm +1d2a91b3fb644bd18a8d9ca3ebe8f435 ../Issues/iss119_w.htm +c717de42febb3d7826f54e842d37ce29 ../Issues/iss120.htm +8e203ea910b1f910c450f12cf79a2f99 ../Issues/iss120_w.htm +f3909f48f4e0af861d720c7c47236d82 ../Issues/iss121.htm +6584b547f878b2358492ca35e09cdd65 ../Issues/iss121_w.htm +45966cb6d05dbd78f4d3f614e17d972e ../Issues/iss122.htm +a55840aa5a5e996ea19d3c7596e65fb2 ../Issues/iss122_w.htm +a6fcb2fe2204e3fc5a8673015b834d6b ../Issues/iss123.htm +7d98719eb691a170e7d92b1407f007b3 ../Issues/iss123_w.htm +4ca9171e1a8780a23a89dac63b519571 ../Issues/iss124.htm +10b6d43ed252a78e616cb66cc3f9ab7b ../Issues/iss124_w.htm +d00cac00297b571530527b52104d0d4b ../Issues/iss125.htm +672255655f998a6d354217da9e84137d ../Issues/iss125_w.htm +7fd3dd850983b3103f66441834ef871e ../Issues/iss126.htm +f308e18f3e7c9866af90908c0a75724b ../Issues/iss126_w.htm +ff262c20afab1771aac0347364073f79 ../Issues/iss127.htm +0820a393f150d801396cf66f73e365c7 ../Issues/iss127_w.htm +73c9eae4ffdd55ef5a0b2edf132d6ced ../Issues/iss128.htm +69aae280df033556b326fb88c97efc95 ../Issues/iss128_w.htm +552d7c6b6d3a2d965dddf41cd0b4e2e0 ../Issues/iss129.htm +4ffdfc230d5b5962cfa3a6d5606f43dd ../Issues/iss129_w.htm +0d21ca681317adbccb58d9ab705ef1bb ../Issues/iss130.htm +b481e05a0c282a773b3d911eed11d567 ../Issues/iss130_w.htm +fbc0fd3826a92a5aee2ac766cb7d5922 ../Issues/iss131.htm +bdc82a531908727eb4058f5d318258f9 ../Issues/iss131_w.htm +3000d81f7af07a03e8dbda9dd87091e8 ../Issues/iss132.htm +045acd7d739c53b99c71eadfb7878f45 ../Issues/iss132_w.htm +78396e8a2795c8ab03c88ddcfb47fedb ../Issues/iss133.htm +c507d5ab1ea83c4afa49dbc7e838119d ../Issues/iss133_w.htm +a59dc916196450d8a1d9f6803125de1c ../Issues/iss134.htm +e1f885a87e5acf23eb0724a4c9eb2af2 ../Issues/iss134_w.htm +ce01270a6b267dead8a73b745f2902b1 ../Issues/iss135.htm +c96e17573a33804e945e6459ab933910 ../Issues/iss135_w.htm +57ca9f2590dd63d523bbd208ac120333 ../Issues/iss136.htm +399d5c386409a94be742b6b24865be80 ../Issues/iss136_w.htm +71ebd021f5517328f0d8cd139b9362cf ../Issues/iss137.htm +a735d004a9f76e2337372d79a6f07926 ../Issues/iss137_w.htm +5e38d4230ae2e2c480d4897f2a5a221f ../Issues/iss138.htm +c2b36554158d6578982ed6a0edd1544e ../Issues/iss138_w.htm +82fe606a4024eb0665c63abb678306f8 ../Issues/iss139.htm +fb120c31241e37a97d20e13b4cbe973c ../Issues/iss139_w.htm +dd29e56e351e94466cb84f6b65cc1c7d ../Issues/iss140.htm +5ca7369ebe742b4e41e9fc32341eeadb ../Issues/iss140_w.htm +66048534c98e7436b123ebf926667db6 ../Issues/iss141.htm +81dccf3214d1097d904805efea6789f8 ../Issues/iss141_w.htm +45482a815c3269d12dbf774c3466952c ../Issues/iss142.htm +95f68d0a27fdb2e939f76af9f5f08fdc ../Issues/iss142_w.htm +5aec63ba2cedbbbc632c20973631d0a2 ../Issues/iss143.htm +a8c156ec297bce6b5fefcec558562b6c ../Issues/iss143_w.htm +9264553e66982c39da05a627db3b5479 ../Issues/iss144.htm +b34299dcf7f500b591606502c6e43b73 ../Issues/iss144_w.htm +a05a1feffd047a8e87ba3a5b072664a3 ../Issues/iss145.htm +4d6b0d75340152d8175612064fea83d3 ../Issues/iss145_w.htm +9b863cc8029475c4b6644e744fb2edfe ../Issues/iss146.htm +e395ba4ba37b41facc068fd7bfc02254 ../Issues/iss146_w.htm +c39bbd425d8f8420fc36c992c3bc81e2 ../Issues/iss147.htm +a3a9efc95a6b5d817b633f243066da4d ../Issues/iss147_w.htm +afdedbc6ce9d6fc7a582e365d1747def ../Issues/iss148.htm +b096c64095411ddd8ee77aff95e128e8 ../Issues/iss148_w.htm +e6280dff08acb2dbc3c7c1d84f28fbe1 ../Issues/iss149.htm +c8d3ba24f40f33c494be9f3632fc0c65 ../Issues/iss149_m.htm +ec13260561541b7af6af9203bde81a52 ../Issues/iss149_w.htm +616960893c1171577983148d19217585 ../Issues/iss150.htm +3a9b549650b98d88931c3ae17aa62f53 ../Issues/iss151.htm +3e744d84904f6779f6c7ddb4de6dabe8 ../Issues/iss151_w.htm +1af91a65c189d2e875c727d7c97ede25 ../Issues/iss152.htm +4cec3c9d4e0675a50145c0bfa4a2517b ../Issues/iss152_w.htm +7fe9ebecce0f152bbe287f944b4c4cb0 ../Issues/iss153.htm +676a51d30ebbc7961d2d6acae7ec0122 ../Issues/iss153_w.htm +fc466024aef3637f34500777fd4a0e14 ../Issues/iss154.htm +eafeca027e366c196b025dba4bc82e65 ../Issues/iss154_w.htm +982fbee00f8918dc972146f68d0bff68 ../Issues/iss155.htm +722cae848d3e53946703a7a40018eb12 ../Issues/iss155_w.htm +0f4ebda0381bab107b4cd3a628460b06 ../Issues/iss156.htm +727df7dc66744af0eb9ba4982d909f46 ../Issues/iss156_w.htm +4c8d49cb3e97409b2fabdaf6bce3059d ../Issues/iss157.htm +71721de1f7cebbdb235b5e5e103d0610 ../Issues/iss157_w.htm +238a36ca5be5fb7d19436cd523a3874e ../Issues/iss158.htm +9ce5fe502632ff8f2e69428704f7639b ../Issues/iss158_w.htm +2a521035220438ccb3664f672e25bb6b ../Issues/iss159.htm +f34a2fd0d5c0797fbb46c10e476ff01c ../Issues/iss159_m.htm +e7bbc7ecd3a8a18879650d64fa4af1fd ../Issues/iss159_w.htm +6fe0020a395f849e79d4ebfd88643633 ../Issues/iss160.htm +ecaaf8da2b60e61add393c4c585588c6 ../Issues/iss161.htm +7d3712b44910124fa2ca4237c758f8a4 ../Issues/iss161_w.htm +0bc3bb468b955114c3aa3ef1e1d7e21a ../Issues/iss162.htm +47b7b20b7187a9d04af5497231a24b8b ../Issues/iss162_w.htm +42572795d8732771c226fbcd2db4889e ../Issues/iss163.htm +d064746a45b0ee59bce2b397e03eee9d ../Issues/iss163_w.htm +10bf40432d871f80b1cef620aa29cbac ../Issues/iss164.htm +c0426ea02993193c66dd8d6abec7571c ../Issues/iss164_w.htm +4f8fc7f2a4bb3d7af6a30ca5c9a6266b ../Issues/iss165.htm +085aac3c1ba4f46aba078e1f7622ce3f ../Issues/iss165_w.htm +1905be972991ab17e3b1ee13027a4cf1 ../Issues/iss166.htm +3ca50d096b57ae4e119d54a03b613fb2 ../Issues/iss166_w.htm +9d6843a292b2a2b5312a367a0bfc9a43 ../Issues/iss167.htm +57247db2c2fb4214325a3faf6a0ccb83 ../Issues/iss167_w.htm +a852173cf633b2371e1b81272bd4617d ../Issues/iss168.htm +829cb81ba00ccbd5d94ab2c4ef97d3a6 ../Issues/iss168_w.htm +981202111293d7162199a0a3f0640612 ../Issues/iss169.htm +12891f71f384c150d4a9fdc6d857e32d ../Issues/iss169_w.htm +48da4a893d9d29b7604cf44dad9080f2 ../Issues/iss170.htm +961e2e33639981d6c2232760cc323da7 ../Issues/iss170_w.htm +c96308f94c029e0685e1cf237b7ba92e ../Issues/iss171.htm +a75e124a28883131d78d8b4c85866f2d ../Issues/iss171_w.htm +012b7c558a5aa9a26d12a9fcaf555118 ../Issues/iss172.htm +b5218758b41f9e8261bb1bc88c0d9f78 ../Issues/iss172_w.htm +9c067abc17fb3f3da97d45a7fed94016 ../Issues/iss173.htm +330e31f05a16028b7ca7bda6770ee3fd ../Issues/iss173_w.htm +7e40b03c5fd929702a1aa7b7e2886484 ../Issues/iss174.htm +7662e4e3646a4b4b4817c6390f549ec5 ../Issues/iss174_w.htm +493dd99e2c0679dd6be109a39d99cbab ../Issues/iss175.htm +391626b71ab850d63c0737abee7de6d7 ../Issues/iss175_m.htm +9d3289e24dc3948ea38473713cfbd32b ../Issues/iss175_w.htm +10b073dfa3bf6f74329daaf42397de63 ../Issues/iss176.htm +5e75df56610e780b85cab6404cd77232 ../Issues/iss176_w.htm +0d32999b91e350ce5b23f0eec54b95f6 ../Issues/iss177.htm +44d6735d8b682c524161be28b6568ca2 ../Issues/iss177_w.htm +2b7840cb4d0141db74f52e5e9f61f7ea ../Issues/iss178.htm +7d9525e40a46e99763a53836bba8b63d ../Issues/iss178_w.htm +f9e636b73db84ff9422076db253c725d ../Issues/iss179.htm +c3176f8c64e29a952c4c70124153cf14 ../Issues/iss180.htm +e140993a5f368dd53863a7577b7d3b43 ../Issues/iss180_w.htm +17be52767df9de01a1bb44cff004036f ../Issues/iss181.htm +525a901558a5f8bd32e25ad10e538755 ../Issues/iss181_w.htm +a5dcc8686249e8fa81066b0c880e2a41 ../Issues/iss182.htm +6fcabacfad2711cec3fbb0ed668a9a43 ../Issues/iss182_w.htm +51ae371bea044e7cf3383daded4aa441 ../Issues/iss183.htm +51ca41150fb5a13912a6ebc54b3c9f9f ../Issues/iss183_w.htm +5afa32ba4a7c69c3db1c15e84a0f109d ../Issues/iss184.htm +348d22358658cff8418c34f87a339a53 ../Issues/iss184_w.htm +c10dd4b7c8f065abc85cd70d64bc3deb ../Issues/iss185.htm +cc5a1b48aac3f0940fcb1abd2dfc377b ../Issues/iss185_w.htm +79aec000544c88d2582a86cc0b6311a2 ../Issues/iss186.htm +0e9cd539fe0e039b3dde61b4bd7cad6d ../Issues/iss186_w.htm +cd236929cc66c9216d72fa7d06a20f5a ../Issues/iss187.htm +b5a3ee16b63db34b117d1ab3e16455ba ../Issues/iss187_w.htm +dc26b3ef0cea57f94510bbcb49625b4e ../Issues/iss188.htm +e28cc1630a6ed697a5ce042be8ab1e97 ../Issues/iss188_w.htm +2dd716a98fc3989486dad1b15115bd1e ../Issues/iss189.htm +5051f025ebf7bff5aadc22d5924ef683 ../Issues/iss189_w.htm +1eb59d6963e04093e52b1bc346259c28 ../Issues/iss190.htm +7f370e8ab39aee76bc5fbc8b44c54cf2 ../Issues/iss190_w.htm +ddc19c71ffe66e349ae4a946dc009e51 ../Issues/iss191.htm +e1dc518ecbfc722c023aae675c1fcb58 ../Issues/iss191_w.htm +0150111b53e73acf97b1c27a34519350 ../Issues/iss192.htm +66d554935822262c0b4c10fc95ba4f1b ../Issues/iss192_w.htm +9c9f5162ed4e27869f6b8f85665debfc ../Issues/iss193.htm +0b5f68cd76391ffa74da36958bc382fc ../Issues/iss193_w.htm +2ec4ee17f44d18f570f796ddc7f1ec18 ../Issues/iss194.htm +d9f52f2394f97ec639b9822f7f073bc3 ../Issues/iss194_w.htm +0ebd308b60c1673211c41ce100cda621 ../Issues/iss195.htm +0415eb33111f60f080e2f2a476153952 ../Issues/iss195_w.htm +4c59a7e99fd41b49cdc539a4ba0f0417 ../Issues/iss196.htm +e9f7cd85a63e6a41e7d9127377edf544 ../Issues/iss196_w.htm +31ce0a7ad0290e63a2764d5d125a210e ../Issues/iss197.htm +22f0b4e4e002b20742a59a8d30480d36 ../Issues/iss197_w.htm +ca26457f6c4b6f0881ea94710d2ecb07 ../Issues/iss198.htm +6794ca8e60de55d3922d97ec3a255556 ../Issues/iss198_w.htm +30bdf8e87d116b17d01c34fb985a3347 ../Issues/iss199.htm +8186e46ccda57b5f07ffc76dae111b22 ../Issues/iss199_m.htm +e00d8b2f88ab2afc2d14581ca0d4eda2 ../Issues/iss199_w.htm +e9f6ddcb503c8a19820d140abe460767 ../Issues/iss200.htm +463e07d593d8b00e7ab70708c35cc9f8 ../Issues/iss201.htm +4df5576c762e53c3bcbbdbf6541062c6 ../Issues/iss202.htm +a79a702806fb43daa792acd70536b731 ../Issues/iss203.htm +d32bcf966890f4e518804101844c28f5 ../Issues/iss204.htm +9b16437e0ab0500a503b1b606fb07ee2 ../Issues/iss205.htm +bca610799cc62fdc5bc3259a97163f8f ../Issues/iss206.htm +9072275702c22a32b75363da32581624 ../Issues/iss207.htm +28bef22ce3376961e1e15682b7e96026 ../Issues/iss208.htm +55b562a51ac6619a1aabebcde012ac48 ../Issues/iss208_w.htm +41eff1d6ac17a5fa97d813f171a8c859 ../Issues/iss209.htm +92af53726758e20ff9dc6754c6fec4f9 ../Issues/iss209_w.htm +ddf747d90a5052662c6b02d3cb336a1a ../Issues/iss210.htm +a6508d609b813891d70f0b794f529456 ../Issues/iss210_w.htm +b5de3ee67fc3de35dde5bdb33c368cfc ../Issues/iss211.htm +98fd346e988ec01f093793fa05a48ed1 ../Issues/iss211_w.htm +0412d4607830b056ba87bb9fe7318193 ../Issues/iss212.htm +4c0a8e8277aeda6c85c7ef0fa75d49c6 ../Issues/iss212_w.htm +581aa368e00d8907b89f5edd043da055 ../Issues/iss213.htm +78150363a879f2afbce0a58762756506 ../Issues/iss213_w.htm +a7f4bf951d1b8643696e2524ec26f102 ../Issues/iss214.htm +3af2e181c47f72130a7d461be8451eb4 ../Issues/iss214_w.htm +026d533bfe2740b632ccac273dca918e ../Issues/iss215.htm +0a9bd38e5dee6443d9e46a4d8a602707 ../Issues/iss215_w.htm +7bc542b5a8d2ec8ee947674701444493 ../Issues/iss216.htm +b93d98d9550b5633ddb0c150aecd41c5 ../Issues/iss216_m.htm +66da00b06d4b9d609d6667e78890100d ../Issues/iss216_w.htm +7ad9aabf927380091a7f80a803460ef7 ../Issues/iss217.htm +c2e55e48c74a887e41fa50c87efdfef5 ../Issues/iss218.htm +eb02fe1c3f44ea446184197cf1db1341 ../Issues/iss218_w.htm +c00f5e94f96c3b0027718b48c4a738c7 ../Issues/iss219.htm +49f78cd2f46c536bdd95d047ba20f32f ../Issues/iss219_w.htm +a953c5d2b715f47b61ea4a0a4986bd72 ../Issues/iss220.htm +4628ab6a7cbc52b2ba3a2fdfe02ceda2 ../Issues/iss220_w.htm +fa9079350b21037e0026dcf93ac73e0c ../Issues/iss221.htm +3ec72cd3e485c3dfffe9091fb50225f5 ../Issues/iss221_w.htm +ac1ef10d7fdcc94019aaa23ab53c4737 ../Issues/iss222.htm +724d30557b1bc180fed3f442133d8b6a ../Issues/iss222_w.htm +a092c525b8f0ec749773b0e593aa4906 ../Issues/iss223.htm +bf82300c542c2619ad35a97713b3d3e6 ../Issues/iss223_w.htm +4aac987e9b0e744245ef9bc63d8b3d96 ../Issues/iss224.htm +7ce060e8c34085a956939354990adc55 ../Issues/iss224_w.htm +52a18d12829ef077721ca32fb00b5470 ../Issues/iss225.htm +8ad51456457552beff53aa43cfd59659 ../Issues/iss225_w.htm +b32db2cccef119145515f46de73fab6d ../Issues/iss226.htm +601f1444d241285244353f4841dd2b4e ../Issues/iss226_w.htm +ffbe86ba6df7e3e58ec4cabf19e0f758 ../Issues/iss227.htm +29a8a193515ea41c5e261a1d2f3a9115 ../Issues/iss227_w.htm +c273a9bccd7ceea85bb4f40726364e3b ../Issues/iss228.htm +3a82601167ac849be716ddf8f10d1edc ../Issues/iss228_w.htm +a409fed24798ca13c35bd56990b10475 ../Issues/iss229.htm +e4e8979565e1b10f27a394a2153e6a51 ../Issues/iss229_w.htm +19e7217743791e23fb38f9a482deb7e8 ../Issues/iss230.htm +1d32523de75c322e3ed011572a3ea363 ../Issues/iss230_m.htm +b3a5ee12dae4d8b63c24c3807ec90fa4 ../Issues/iss230_w.htm +f14969781bbcb977a66304032b31d7a0 ../Issues/iss231.htm +d14cfb417800cd01006d2abcf5441327 ../Issues/iss232.htm +4a008e76168a1ab2a8852c76563587e2 ../Issues/iss232_w.htm +7c4fed42f5fc9efc10c23d7d352fa462 ../Issues/iss233.htm +e5991f7c10310586e1b7d13ca9993947 ../Issues/iss233_w.htm +7be7c0589063a2d81772dbb1ef4dbed4 ../Issues/iss234.htm +75143fb06bd40908b5ed162b02fd62a1 ../Issues/iss234_w.htm +92a3261a67d99deed1cc652b8e3b703f ../Issues/iss235.htm +bd8830d6665477ab78f5a3f010ecfdc8 ../Issues/iss235_w.htm +8a0f0537a664e38279c83e1c30301836 ../Issues/iss236.htm +9b17c49f7e1bc917067a57aa674b983e ../Issues/iss236_w.htm +c536cde77e641f3f77fc37797d3bb231 ../Issues/iss237.htm +f913c00d0f6a03d3882999a8a14e36f1 ../Issues/iss237_w.htm +53b4d43b907ff8355c1b6e3878ab12e2 ../Issues/iss238.htm +8c94fd69b9cdfaa0a9e640a8e58a95e3 ../Issues/iss238_w.htm +9b0a33832e3a03de9525cc03f5493d8b ../Issues/iss239.htm +8352b43f4951bdb0f50420b6f2f05660 ../Issues/iss239_w.htm +7041ea2f404002840d1e1be93e09453b ../Issues/iss240.htm +39af64e455edb6cc989dc12af912ca6b ../Issues/iss240_w.htm +15e6b3f99eca33b38e0533b8b2678564 ../Issues/iss241.htm +927b402ce2bed71b4af2a6a9cf55a63a ../Issues/iss241_w.htm +205c8989b65aa0c06a175a16812c1e3a ../Issues/iss242.htm +353577716e843e2424f836ee8ec0e217 ../Issues/iss242_w.htm +0f63e0afe2adca3e1836725e3faf2758 ../Issues/iss243.htm +a81ae2784655b0fc3040747ec1014952 ../Issues/iss243_w.htm +ea20541efae2fc67cfbe3736674bad82 ../Issues/iss244.htm +6d4dbe26c93701c8d7c2ce9cb7f6e453 ../Issues/iss244_w.htm +15addd1fe3403850cc50554fa4ffee11 ../Issues/iss245.htm +ce53cef50b7c15eddf8dbf3163427c49 ../Issues/iss245_w.htm +40a77e34e8cb7094d824882209a2c42e ../Issues/iss246.htm +84ec1472f0b2079387d38ae7652fe751 ../Issues/iss246_w.htm +0d3d912da6502df668dbb343ca6dc27b ../Issues/iss247.htm +f1820ff3ce1632a0cdafd24bc42861fd ../Issues/iss247_m.htm +ad3320556f2aa0d1a90b242022a0e6a6 ../Issues/iss247_w.htm +ed52b621a58bde7f3bed76f823f5d1e9 ../Issues/iss248.htm +a9d37bd7aaff5c1147dabed5e1cb510b ../Issues/iss249.htm +18984f0f1d1f93d2f0f9be93bdc57bbc ../Issues/iss249_w.htm +ca3d410927732215d356a490d4f4a7e7 ../Issues/iss250.htm +0715380823f29c0025b8cba72db96c92 ../Issues/iss250_w.htm +584540f18925b5cd71bc2881e3271938 ../Issues/iss251.htm +67ab402b93afe605b1702957bc75571c ../Issues/iss251_w.htm +580de1bf0bb40160ba9988dc5112b9fe ../Issues/iss252.htm +8a13ada654eb32cb5038c70e6275417d ../Issues/iss252_w.htm +732417fda2ac6784bd8f10d1e8d7bc4d ../Issues/iss253.htm +d073f487dcecd32a2a447d862e63a290 ../Issues/iss253_w.htm +368bd8fe1a5c1de99b47714c344fe186 ../Issues/iss254.htm +bddcbbf8299725ebddadf95154b6ff93 ../Issues/iss254_w.htm +aec9eeca7c6f7ee9354d49e326f4cb59 ../Issues/iss255.htm +beb8f09af55de65ce839793bf0e21e2c ../Issues/iss255_w.htm +a31f4d7c5c2bf6b6f46d1b98334cf706 ../Issues/iss256.htm +1a35075bdf272c3197f75f74b8f61a82 ../Issues/iss256_w.htm +1cf715113501489ff927400f74f81866 ../Issues/iss257.htm +5f926671f11972038a2ccded85a84582 ../Issues/iss257_w.htm +43972eb88270f4522f160bd6bd9bfcf4 ../Issues/iss258.htm +22b0ed86f8f5ef51433edab3e98d569e ../Issues/iss258_w.htm +b4ed4a2dc4126f781410887ba3bb37f6 ../Issues/iss259.htm +3396981aa006599a9e1eceda983b83fd ../Issues/iss259_w.htm +4077e21f53392a918df076c77e7ca9f9 ../Issues/iss260.htm +b51771f8da041f086c95878016a008bb ../Issues/iss260_w.htm +bdfef10888db89fd75bc4980415a9996 ../Issues/iss261.htm +13b0c327ac92bfccd1fbfcc3523d747c ../Issues/iss261_m.htm +b37ad54a1af706336f3c6dea05fa5f2d ../Issues/iss261_w.htm +f83a1d9765f5d8690daf139854530030 ../Issues/iss262.htm +9631f6509f4563cf8cdd8a4f63643443 ../Issues/iss263.htm +50fe6699d7f4db818ef31d2d1bcee307 ../Issues/iss263_w.htm +c75b312294e146cba11b1a00748155ab ../Issues/iss264.htm +f43e6df000c700a8a169e4e2bc6d778f ../Issues/iss264_w.htm +a6f3c17d3676eac61c5f87db6c2b5b56 ../Issues/iss265.htm +11d6bbdf4041f2c549e3faa343b34b04 ../Issues/iss265_w.htm +33c79f5f7a61a92f60bf640728d0fea5 ../Issues/iss266.htm +8df912b625106d84e253d59384c1561f ../Issues/iss266_w.htm +d7e12e4e980ca0c663bdcd59cbd0fb47 ../Issues/iss267.htm +cd9fca7805ab9d92e399bcdf9d9f9906 ../Issues/iss267_w.htm +3160ed9663ec78aab11939c60218e7d5 ../Issues/iss268.htm +f294b5984f575aafccbd677e34da593b ../Issues/iss268_w.htm +915622ed6379cef78b8d334c4fb81255 ../Issues/iss269.htm +c07872a89a15742c6e4cc23e748ed41a ../Issues/iss269_w.htm +56c968ed1c349c79b629dd1689e38db9 ../Issues/iss270.htm +239a98ebd88acfc01866de2448609ff7 ../Issues/iss270_w.htm +aec87655d995b6f16ee1f4f35e8c24e7 ../Issues/iss271.htm +6d7a2add43b3e9410679b65e6d1092d7 ../Issues/iss271_w.htm +b4a2f3c589201617fe1a8b0f2852b25b ../Issues/iss272.htm +a1ca85ad1c10c411021a427be6e1d58b ../Issues/iss272_w.htm +a524d43f092aa21f2abc82ce95749be9 ../Issues/iss273.htm +0841e45b4746da75f9764fbe14a3f88c ../Issues/iss273_w.htm +cbc7b218d0a10675f7866d15251212a8 ../Issues/iss274.htm +1ea20e820c8b19ac1a3815d3cd1fd0e3 ../Issues/iss274_w.htm +e5cf7f9d8ede8b9476db0933ee446806 ../Issues/iss275.htm +5602f668b16be32f5c5e934301e5b240 ../Issues/iss275_w.htm +318fae207b45e07fa7a2be4ea8e4ffd2 ../Issues/iss276.htm +12cbccfdd37f31419076b5a1069a75db ../Issues/iss276_w.htm +07d0222ad14e34e199359e078a0a915a ../Issues/iss277.htm +c88b5d6bac44330d543d87abdc1f8c17 ../Issues/iss277_w.htm +e2c4974be236d433188a9b8bba5e67bd ../Issues/iss278.htm +2b4fd2dfa8c469717ca71bcb8d6c66c7 ../Issues/iss278_w.htm +f00ccb392e17fbece9a5240883c8a7b4 ../Issues/iss279.htm +dff07096d8eb35c67790c8481a3f6dc4 ../Issues/iss279_m.htm +deba767634e9ccc7dddc33a2c23390b7 ../Issues/iss279_w.htm +65287c48ac4b81e3cca3b5b346ad5438 ../Issues/iss280.htm +332a72bc00d28df53c6618bf4e879ea8 ../Issues/iss281.htm +252081a97dd627b2ba74ec137ad7f7a8 ../Issues/iss281_w.htm +21356e98ed953d1ff9d1cf967e4111e1 ../Issues/iss282.htm +2df9f38ebe43befa437cf9e17e8d954b ../Issues/iss282_w.htm +4299282c483c6286177738194c5b66d5 ../Issues/iss283.htm +c9f8c6cc6a7790e377322755cf39c7ad ../Issues/iss283_w.htm +e9cf746f172f24813fc0ecc683e1bee6 ../Issues/iss284.htm +adf4a95cfc5aee992d7a0d5532cbc421 ../Issues/iss284_w.htm +65d91f98eb48f7ec31feaa5446c2b899 ../Issues/iss285.htm +566dcfec900087f80607835493a19f56 ../Issues/iss285_w.htm +f1fa924f90ca7ce5c09cea81e22dd581 ../Issues/iss286.htm +a6e6ec66e813293a1bbac95c653e8c0c ../Issues/iss286_w.htm +46b98555499cab0bce25a2ddba25ddf2 ../Issues/iss287.htm +9af71ffe2e6b18f59bd415385bc74e86 ../Issues/iss287_w.htm +ec5ff9ec40b1950364680a1323b9e0e7 ../Issues/iss288.htm +0f681c72c69ca8664a7e8197620898a7 ../Issues/iss288_w.htm +1c8304ff8c9cbfbbcdab5740367293c1 ../Issues/iss289.htm +0498b8dead84edac522a867a4a45f92d ../Issues/iss289_w.htm +d73d0850b8c4aacabe998d3d393af409 ../Issues/iss290.htm +6e288ac0ca11778b127a7988f8a5b986 ../Issues/iss290_w.htm +0aa15cb09edfa8ab713cbb8b0ca8dc31 ../Issues/iss291.htm +b3334735b6b7e0c7a6f446aaf40aa87b ../Issues/iss291_w.htm +2cfe4d7488a4bdec882121ed9c0762ec ../Issues/iss292.htm +8aa59be472954176dbb67a6dbf416572 ../Issues/iss292_w.htm +2eb827ae7a4802a8dd28cac9d9660b93 ../Issues/iss293.htm +321587dfedd89c41dcbb1a087c98ac86 ../Issues/iss293_w.htm +31dad6fd3df422bd4662668deae9712f ../Issues/iss294.htm +d66ad2e93d39156fe09a97128c28100f ../Issues/iss294_w.htm +2a75a412810a3bb7657ff2d370a428ac ../Issues/iss295.htm +6a2a7e4ad8cfed60e5d204398c2d8b99 ../Issues/iss295_w.htm +c6c855df2246eff012637beb501e7736 ../Issues/iss296.htm +ea646600c3a545b16e6e7a69d011b551 ../Issues/iss296_w.htm +51ce6fcef4166002ad3ba286854cab2e ../Issues/iss297.htm +a4f7b96f388e07f3979a74284a02d924 ../Issues/iss297_w.htm +76f9fee7a0d292605687cbf3f47f5d36 ../Issues/iss298.htm +711b989fa7ce7407f137aa9ec8420ccb ../Issues/iss298_w.htm +850cad39a1bbcd64a57855ed9d99d114 ../Issues/iss299.htm +06f09206f99800a50feb3230f8b50e45 ../Issues/iss299_w.htm +fe02b888e00acd5cb23854731180ce3d ../Issues/iss300.htm +649fd708253197c60d4295f521ada90d ../Issues/iss300_w.htm +6653e637205670d0468a1fb28a75c243 ../Issues/iss301.htm +9d94e031b96cf4c682a1a5d9178a9b07 ../Issues/iss301_w.htm +1c8bd3fc5cad0a146b675a61af311c3f ../Issues/iss302.htm +09b0f65302a0b75ff5ad503e032fc477 ../Issues/iss302_w.htm +f34d8e6ae6f19cbad97be56797607a48 ../Issues/iss303.htm +c661d3d97c560dedf8b0421351614981 ../Issues/iss303_w.htm +5608c534253b44049be17452a0d7db49 ../Issues/iss304.htm +93e322ee279f75e8aa3969d30f51d3fc ../Issues/iss304_w.htm +b4edbb15295295ccd86dc178e8f851c0 ../Issues/iss305.htm +fb88dea5f8f36da0763d45a0e6a294d5 ../Issues/iss305_w.htm +fdc2d2edee3482187331b3f122b74244 ../Issues/iss306.htm +9cfb7b85af959a430b38b1e85df41078 ../Issues/iss306_w.htm +714e7f0d5a58c0d8017c7f206cfe7bd7 ../Issues/iss307.htm +f0cc72e7dff93024b589df43da502cf9 ../Issues/iss307_w.htm +d092cb42ad0051c22fa818082eea8aec ../Issues/iss308.htm +03a36620cf4df3bfec8e532c070cd555 ../Issues/iss308_w.htm +a86238c2735fbfb139549d5854d0cca6 ../Issues/iss309.htm +674b57a6e58c42a6d0805a2835b330e9 ../Issues/iss309_w.htm +a15872e9c37b262f9e4136a70bbbb87c ../Issues/iss310.htm +215a01d0d60370380044aaab9fa1d63e ../Issues/iss310_w.htm +c29d9f3c5c7812b2a9d7acc5e55ae2b9 ../Issues/iss311.htm +9f992de8b6f9a498fc0ad66528ad3f06 ../Issues/iss311_w.htm +0e648094c0939d5eac9a23e86f59be57 ../Issues/iss312.htm +ba8c0475a5528d6281a410f3056fd8db ../Issues/iss312_w.htm +f2e034970002910df0f2485315f1bbe8 ../Issues/iss313.htm +4e3db9e9940adbdb8e68e2b30b37809e ../Issues/iss313_m.htm +579fdcd8371b1e61c7ef457966427a22 ../Issues/iss313_w.htm +26f1869c981537e195baa5c824024aa4 ../Issues/iss314.htm +8fef35bd226b43568f13ac5a90092dc5 ../Issues/iss315.htm +ac7fbb466db813147747d4f66cb29ba7 ../Issues/iss315_w.htm +648c68863b4977d76872312acd708669 ../Issues/iss316.htm +cb2cd06d39dd147f307734c6dae1dbdb ../Issues/iss316_w.htm +20137324a7c31af212727049f3308d4a ../Issues/iss317.htm +9413e84079a2442934a7dab744207d4a ../Issues/iss317_w.htm +308614f9af529dfbeaaff93dc393c464 ../Issues/iss318.htm +57c747a6deacd388d28674dd06f60159 ../Issues/iss318_w.htm +7c9d35c6c1f69b59bb7492411cb6675e ../Issues/iss319.htm +f0cebad870e6d55772875365fe73a775 ../Issues/iss319_w.htm +b8eef57cbf6674e0063131ef21c635ed ../Issues/iss320.htm +a4ddd7312e8649a81879d629d0705a77 ../Issues/iss320_w.htm +86ec3a4bb7fe3d299d16555aa736f2c8 ../Issues/iss321.htm +a30e747b83efd9ac880523d8a083fc64 ../Issues/iss321_w.htm +f6470b5c182251742d793879cab24677 ../Issues/iss322.htm +aa8835e6895f0b0ff087d8094ff71a0d ../Issues/iss322_w.htm +f9e3195132d8e37ad7d2c6d3989321c9 ../Issues/iss323.htm +f5245bdeb0fbc96d11aaf0d8279a88a5 ../Issues/iss323_w.htm +b7db89d0af12aa1f90dd4159571dd46e ../Issues/iss324.htm +a45a156d8ae194d8d5943eab64e5931b ../Issues/iss324_w.htm +86ae561637846c08ed15a60c2bb08f1b ../Issues/iss325.htm +ff2343291acd1ad61479b69b7b6af0a5 ../Issues/iss325_w.htm +b494440167072f7e5eb09a32aeafd44a ../Issues/iss326.htm +85873c6e8e67b41faf10345d0ef03961 ../Issues/iss326_w.htm +c9e8c8fce80c5b9d3c9f6387468d3b80 ../Issues/iss327.htm +a466d5931f2c07bae5cada0c1a13c8e7 ../Issues/iss327_w.htm +8255adcd3e1eb7dc0f3f78fd289b4b33 ../Issues/iss328.htm +0ec69b621e108577debf072cacb7725e ../Issues/iss328_w.htm +73451efa3acbebd1ead1961374de545a ../Issues/iss329.htm +2754a44e9ea6339185cb7289c88717a5 ../Issues/iss329_w.htm +b2f0ea0f8285b121dc25965cd4b8f52f ../Issues/iss330.htm +f3751e0f7bf2365d5194e605d230a25b ../Issues/iss330_w.htm +6e574fd0ab8970ad58af47d30e03992a ../Issues/iss331.htm +b8c483af565247d2d03f6911fa5fe6bb ../Issues/iss331_w.htm +744db217a8193059189bf40d3c47e5ff ../Issues/iss332.htm +c829484c32534ff1860f184cc4bf8a75 ../Issues/iss332_w.htm +35569182d60abbcb36e5f25a6e1d494b ../Issues/iss333.htm +6e819912d8a363335541c0a0deebc66d ../Issues/iss333_w.htm +201e7b7a64be3e798141945dafcd913a ../Issues/iss334.htm +02cbd519adb02db707472f4e4455021c ../Issues/iss334_w.htm +8189bc8f3461e2375c3350124a9d909e ../Issues/iss335.htm +f28851deb5d32c493a590acbdad9d1a4 ../Issues/iss335_w.htm +ac13aca9e01144bfcb640ca4d4b69838 ../Issues/iss336.htm +0ba5cbe7eeaf981976d99a0dad61088a ../Issues/iss336_w.htm +922e50d38bb0cecf992a5e54a4bf4a10 ../Issues/iss337.htm +38ed6be0c3367837fe74ad2c333a7b0c ../Issues/iss337_w.htm +8952ac650f87b3df9c5698005958e921 ../Issues/iss338.htm +025b31475929ec4e982f05b1004d2b18 ../Issues/iss338_w.htm +098c7adcf7c0d1d52284735e9e5cbcb6 ../Issues/iss339.htm +7eb6561a94c97e83c5a4c3ed5281c962 ../Issues/iss339_w.htm +498807e03e5f14fe2807c38f397395ed ../Issues/iss340.htm +e0299ef18e83e3a80aab9e8f1c9ba394 ../Issues/iss340_w.htm +ea3e6ed5584ed64000a4348603a4ef35 ../Issues/iss341.htm +be7de2540feefb1a2ddfca8ceebb9a0f ../Issues/iss341_w.htm +1aec0d04d9b2177e7ebb4f7bd48f01cc ../Issues/iss342.htm +655f220e9983447fc034f6d9d16d291c ../Issues/iss342_w.htm +3981c7fe8bfc333e60040eda8e429588 ../Issues/iss343.htm +2a750deea62857634a84b2cada5efb30 ../Issues/iss343_w.htm +af93b64e66fd28da0c59d78173c9dbe2 ../Issues/iss344.htm +e83ae3a6219ce9122f7f2ccf97b84048 ../Issues/iss344_w.htm +d01d053289fd7bbccc8b3f00cf0ee892 ../Issues/iss345.htm +e1f9a0263bd87e6d4424d089e7391921 ../Issues/iss345_w.htm +d625c1f5ed55a8d01cf2b2638f348a5f ../Issues/iss346.htm +f8cec49ae7ee2d23a0d376e1b41f1930 ../Issues/iss346_w.htm +5868b4fb4c50780198b2eaa2b5196413 ../Issues/iss347.htm +7fbde7aa75ed8314ac468971b3c1db7d ../Issues/iss347_w.htm +d0549eadf0b8e1208ae44ed9e85dd1a0 ../Issues/iss348.htm +27fd04014ebd122e160071cd2475d1f3 ../Issues/iss348_w.htm +27dd0ae9ed86e8cf139f0a071109fcf4 ../Issues/iss349.htm +a23ff38827e87d93543bc4dce65bd7d0 ../Issues/iss349_w.htm +99b5d03ef74e6fa69a111961a9e10f2b ../Issues/iss350.htm +e23b00a5491f54bbb9af829a23304b13 ../Issues/iss350_m.htm +7fc69a4f096d3e5e80bec836a7cac2fd ../Issues/iss350_w.htm +78d553665785d5bbe265ddb3b5bdb628 ../Issues/iss351.htm +9a9929f5febda7b2a91b219643f3dbd8 ../Issues/iss352.htm +c2a06ca8a3e19e4600896ba6846a9f6b ../Issues/iss352_w.htm +dd528cf7e0bb37a5118481bb4b51f191 ../Issues/iss353.htm +4bf4b5218ba6ce7000e9da9598b51e9a ../Issues/iss353_w.htm +b1f3f0982fbd36f8de9f6827091c085e ../Issues/iss354.htm +840b6adac9300efdb58c48ad0fb3ce93 ../Issues/iss354_w.htm +2a7f763b08cbaa9d95c8a9688b115f15 ../Issues/iss355.htm +54ccf754ec4d3ab4fde37ae60e553c45 ../Issues/iss355_w.htm +7e02119a6fcca9fa9ae67b5ae77d42ab ../Issues/iss356.htm +b267e51a5e41092969714849116d0afe ../Issues/iss356_w.htm +a539291bb7b3f6315a98e29cdc0b034a ../Issues/iss357.htm +5c4a5d624df70d74e6e722262dea94f0 ../Issues/iss357_w.htm +a833959c3fb89919c2a2b4b403cf1412 ../Issues/iss358.htm +28543fb7d11bb384b72e5a77a32b4e2c ../Issues/iss358_w.htm +250c96661bffaf257faf30cb3f4f9da1 ../Issues/iss359.htm +4f78fd903aeb56979d45aba529a197fe ../Issues/iss359_w.htm +362685d5023ea65c012b8f04212e9c81 ../Issues/iss360.htm +b4dac618dda4f1c357a355cd2fc91e4c ../Issues/iss360_w.htm +3c296d4a011b18c9417b69b860bc562d ../Issues/iss361.htm +9a603b413aff06399322a9c06280fff3 ../Issues/iss361_w.htm +535bde81251ebec80d915d342af1dfe5 ../Issues/iss362.htm +3ffacd48968b6484cb7a856dee0c7ee2 ../Issues/iss362_w.htm +0c67acba2d4c18a1dc3080441f94b008 ../Issues/iss363.htm +45b9f4f34d7b0fa22db4d08cb41f675a ../Issues/iss363_w.htm +5e6bfd168bb7c6d3372c30081117eec0 ../Issues/iss364.htm +62bbfaeab1bf3a67ef5d55790a175c54 ../Issues/iss364_w.htm +5c0dc32de168d1e894c349dffbcbf8a7 ../Issues/iss365.htm +2a94f79d00cb6d617e6b363a5ac396a7 ../Issues/iss365_w.htm diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Contents.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Contents.htm new file mode 100644 index 00000000..5f6bed5b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Contents.htm @@ -0,0 +1,67 @@ + + + +CLHS: Chapter Index + + + + + + + + + + + +

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+ +
+ +

Chapter Index

+ +
    +
  1. Introduction
    +
  2. Syntax
    +
  3. Evaluation and Compilation
    +
  4. Types and Classes
    +
  5. Data and Control Flow
    +
  6. Iteration
    +
  7. Objects
    +
  8. Structures
    +
  9. Conditions
    +
  10. Symbols
    +
  11. Packages
    +
  12. Numbers
    +
  13. Characters
    +
  14. Conses
    +
  15. Arrays
    +
  16. Strings
    +
  17. Sequences
    +
  18. Hash Tables
    +
  19. Filenames
    +
  20. Files
    +
  21. Streams
    +
  22. Printer
    +
  23. Reader
    +
  24. System Construction
    +
  25. Environment
    +
  26. Glossary
    +
+ + + +
+ +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
+ +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

+ + diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Help.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Help.htm similarity index 68% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Help.htm rename to clones/lisp/HyperSpec-7-0/HyperSpec/Front/Help.htm index bbf3c5c2..5d0e7165 100644 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Help.htm +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Help.htm @@ -5,15 +5,15 @@ - - - - - - + + + + + + -

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

+

[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

@@ -22,12 +22,12 @@ This page contains the following kinds of information:
@@ -42,28 +42,28 @@ This page contains the following kinds of information:
-[Starting Points] +[Starting Points] Go to the list of starting points.

-[Contents] +[Contents] Go to the Table of Contents

-[Index] +[Index] Go to the Master Index

-[Glossary] +[Glossary] Go to the Glossary.

-[Symbols] +[Symbols] Go to the Symbol Index.

-[Highlights] +[Highlights] Go to a list of selected Highlights.

-[Issues] +[Issues] Go to the X3J13 Issue index.

-[Help] +[Help] Go to this text.

@@ -83,7 +83,7 @@ have emerged from this work.

In 1981, representatives of several major dialects began to pool their efforts to design -Common Lisp, +Common Lisp, an `industrial strength' dialect of Lisp that would provide stability for commercial applications.

@@ -97,29 +97,29 @@ is a standard for Common Lisp--not for the entire Lisp family.

The Common Lisp standard improves on earlier Common Lisp work by - + placing much greater emphasis on portability, clarifying many aspects of compilation semantics, and adding several major pieces of new functionality: -an object-oriented programming system, -a condition handling system, -an improved iteration facility, +an object-oriented programming system, +a condition handling system, +an improved iteration facility, and -better support for large character sets.

+better support for large character sets.

Authorship Information

 -The Common Lisp HyperSpec +The Common Lisp HyperSpec is not the ANSI Common Lisp standard, but is based on that standard -(with permission from +(with permission from ANSI and X3).

As an official reference to the Common Lisp language, -hardcopy documentation of +hardcopy documentation of ANSI Common Lisp, (American National Standard X3.226) from ANSI @@ -128,15 +128,15 @@ is always definitive.

The hypertext markup for this document was created by Kent Pitman, -with the aid of a custom program written in +with the aid of a custom program written in ANSI Common Lisp and created specifically for this task. Funding for the markup task was provided by -and copyright of the result is owned by +and copyright of the result is owned by LispWorks Ltd.

-Some additional design -documents have been included in marked up form and +Some additional design +documents have been included in marked up form and cross-referenced which are not part of the standard but may be useful in understanding it. Plaintext versions of these documents, which offer a useful historical perspective, are available to anyone by @@ -144,10 +144,10 @@ anonymous public FTP from ftp://parcftp.xerox.com/pub/cl/cleanup/.

The Java applet used in the -Symbol Index +Symbol Index (visible only in some browsers) was written by Evan Williams. -Its copyright is owned by +Its copyright is owned by LispWorks Ltd.

@@ -161,18 +161,18 @@ Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

The HTML hypertext markup that implements the hypertext features of these World Wide Web pages of the Common Lisp specification, collectively the -Common Lisp HyperSpec, +Common Lisp HyperSpec, is the property of LispWorks Ltd.

-Distribution of the Common Lisp HyperSpec as a hypertext document on +Distribution of the Common Lisp HyperSpec as a hypertext document on the Internet does not constitute consent to any use of the underlying hypertext markup for redistribution of any kind, commercial or otherwise, either via the Internet or using some other form of distribution, in hypertext or otherwise.

Permission to copy, distribute, display, and transmit the -Common Lisp HyperSpec +Common Lisp HyperSpec is granted provided that copies are not made or distributed or displayed or transmitted for direct commercial advantage, that notice is @@ -184,7 +184,7 @@ MUST appear in the copy includes:

  1. this copyright notice and its date;
  2. the main index page, - ../Front/index.htm; + ../Front/index.htm;
  3. all HTML pages to which the main index page links using relative links;
  4. all graphical (GIF) images to which it links using relative links, such as the LispWorks logo that appears on each page; and @@ -199,7 +199,7 @@ Permission to make partial copies is expressly NOT granted, EXCEPT that limited permission is granted to transmit and display a partial copy the -Common Lisp HyperSpec +Common Lisp HyperSpec for the ordinary purpose of direct viewing by a human being in the usual manner that hypertext browsers permit the viewing of @@ -215,7 +215,7 @@ granted.

    Permission to use any of the included graphical (GIF) images in any document other than the -Common Lisp HyperSpec +Common Lisp HyperSpec is expressly NOT granted.

    Acknowledgments

    @@ -239,7 +239,7 @@ may be purchased from the

    Restricted Rights Legend

    The -Common Lisp HyperSpec +Common Lisp HyperSpec is subject to the following Restricted Rights Legend:
    ``Use, duplication, or disclosure by the @@ -278,11 +278,11 @@ exactly in >HTML, although an attempt has been made to be as accurate as possible. Nevertheless, the process of translation was heuristic, and discrepancies might have resulted. -Formally, the official ANSI printed document +Formally, the official ANSI printed document is always the definitive reference.

    The -X3J13 issue documents +X3J13 issue documents are not part of the standard and are provided purely for historical perspective. It is possible that some of the documents, as included, are not the final form that X3J13 voted, @@ -292,7 +292,7 @@ or that some edits prescribed by these documents were incorrectly implemented, or that other discrepancies exist between these documents and the specification. These documents have no formal weight, -and in all cases, the hardcopy specification +and in all cases, the hardcopy specification is definitive.

    Trademarks

    @@ -318,7 +318,7 @@ in about 2300 files. It contains approximately 110,000 hyperlinks.

    Bug Reports

    Reports of discrepancies between -the Common Lisp HyperSpec +the Common Lisp HyperSpec and the hardcopy form may be sent to Kent Pitman <kmp@lispworks.com>.

    @@ -327,8 +327,8 @@ Reports of bugs in the specification itself should be addressed to

    -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Hilights.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Hilights.htm new file mode 100644 index 00000000..46bfe73b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/Hilights.htm @@ -0,0 +1,124 @@ + + + +CLHS: Selected Highlights + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +

    Selected Highlights

    + +Here are some selected points of interest within the document. +This is not a complete table of contents and in fact does not +even follow the chapter structuring; if you want to follow the normal chapter +arrangement, use the chapter index.

    + +

    + +In addition to the specification itself, this document is cross-referenced with the X3J13 design documents used to produce it. + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoNext.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoNext.htm new file mode 100644 index 00000000..379cdbd3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoNext.htm @@ -0,0 +1,32 @@ + + + +CLHS: No Next Page + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    What did you expect?

    + +You have fallen off the end.

    + +[No Next] This icon meant there was no next page.

    + + +

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoPrev.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoPrev.htm new file mode 100644 index 00000000..e513ca66 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoPrev.htm @@ -0,0 +1,31 @@ + + + +CLHS: No Prev Page + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    What did you expect?

    + +You have fallen off the end.

    + +[No Previous] This icon meant there was no previous page.

    + +

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoUp.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoUp.htm new file mode 100644 index 00000000..23ea3e11 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/NoUp.htm @@ -0,0 +1,32 @@ + + + +CLHS: No Up Page + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][Next]

    + +
    + +

    What did you expect?

    + +You have gone over the top.

    + +[No Up] This icon meant there was no parent page.

    + + +

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/StartPts.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/StartPts.htm new file mode 100644 index 00000000..3cc08ea0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/StartPts.htm @@ -0,0 +1,37 @@ + + + +CLHS: Starting Points + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +
      +[Highlights] Selected Highlights
      +[Contents] Chapter Index
      +[Index] Master Index
      +[Symbols] Symbol Index
      +[Glossary] Glossary
      +[Issues] X3J13 Issue Index
      +[Help] Help, Legalese, Trivia, etc.
      +
    + + +
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X3J13Iss.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X3J13Iss.htm new file mode 100644 index 00000000..ac7572d1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X3J13Iss.htm @@ -0,0 +1,47 @@ + + + +CLHS: X3J13 Issues + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    X3J13 Issues

    + +X3J13 made several hundred of its decisions in modular fashion through +symbolically named ``issues,'' each composed of an abstract problem description +and one or more possible resolutions for vote.

    + +These issue writeups, while not part of the Common Lisp specification, +are nevertheless useful for understanding original intent. As such, they +are cross-referenced throughout this document. However, even in the case +of an erroneously transcribed or applied decision, text in the specification +always takes precedence over text of an issue writeup.

    + +Cross-referencing occurs in two ways: At the bottom of each affected page is a +pointer to any relevant issues. Further, associated with each issue is a +table of affected pages.

    + +

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_AllSym.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_AllSym.htm new file mode 100644 index 00000000..7f48c121 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_AllSym.htm @@ -0,0 +1,1008 @@ + + + +CLHS: Alphabetical Symbol Index (Full) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Symbol Index

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_9.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_9.htm new file mode 100644 index 00000000..f86fde70 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_9.htm @@ -0,0 +1,99 @@ + + + +CLHS: Alphabetical Symbol Index (Non-Alphabetic) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (Non-Alphabetic)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_A.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_A.htm new file mode 100644 index 00000000..0734bf31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_A.htm @@ -0,0 +1,74 @@ + + + +CLHS: Alphabetical Symbol Index (A) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (A)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_B.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_B.htm new file mode 100644 index 00000000..2b600174 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_B.htm @@ -0,0 +1,75 @@ + + + +CLHS: Alphabetical Symbol Index (B) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (B)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_C.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_C.htm new file mode 100644 index 00000000..b9011f32 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_C.htm @@ -0,0 +1,141 @@ + + + +CLHS: Alphabetical Symbol Index (C) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (C)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_D.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_D.htm new file mode 100644 index 00000000..56b3891a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_D.htm @@ -0,0 +1,85 @@ + + + +CLHS: Alphabetical Symbol Index (D) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (D)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_E.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_E.htm new file mode 100644 index 00000000..0e08e243 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_E.htm @@ -0,0 +1,56 @@ + + + +CLHS: Alphabetical Symbol Index (E) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (E)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_F.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_F.htm new file mode 100644 index 00000000..9dac304d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_F.htm @@ -0,0 +1,83 @@ + + + +CLHS: Alphabetical Symbol Index (F) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (F)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_G.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_G.htm new file mode 100644 index 00000000..55277e82 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_G.htm @@ -0,0 +1,47 @@ + + + +CLHS: Alphabetical Symbol Index (G) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (G)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_H.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_H.htm new file mode 100644 index 00000000..2b2a49ef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_H.htm @@ -0,0 +1,39 @@ + + + +CLHS: Alphabetical Symbol Index (H) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (H)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_I.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_I.htm new file mode 100644 index 00000000..a1bc70e6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_I.htm @@ -0,0 +1,55 @@ + + + +CLHS: Alphabetical Symbol Index (I) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (I)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_K.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_K.htm new file mode 100644 index 00000000..406c6bbe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_K.htm @@ -0,0 +1,31 @@ + + + +CLHS: Alphabetical Symbol Index (K) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (K)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_L.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_L.htm new file mode 100644 index 00000000..45258e7a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_L.htm @@ -0,0 +1,93 @@ + + + +CLHS: Alphabetical Symbol Index (L) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (L)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_M.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_M.htm new file mode 100644 index 00000000..ea8b3a47 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_M.htm @@ -0,0 +1,101 @@ + + + +CLHS: Alphabetical Symbol Index (M) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (M)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_N.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_N.htm new file mode 100644 index 00000000..4ba8fde6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_N.htm @@ -0,0 +1,65 @@ + + + +CLHS: Alphabetical Symbol Index (N) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (N)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_O.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_O.htm new file mode 100644 index 00000000..7786cafd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_O.htm @@ -0,0 +1,36 @@ + + + +CLHS: Alphabetical Symbol Index (O) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (O)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_P.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_P.htm new file mode 100644 index 00000000..a782a747 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_P.htm @@ -0,0 +1,93 @@ + + + +CLHS: Alphabetical Symbol Index (P) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (P)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Q.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Q.htm new file mode 100644 index 00000000..6ab76534 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Q.htm @@ -0,0 +1,30 @@ + + + +CLHS: Alphabetical Symbol Index (Q) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (Q)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_R.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_R.htm new file mode 100644 index 00000000..f74ea368 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_R.htm @@ -0,0 +1,85 @@ + + + +CLHS: Alphabetical Symbol Index (R) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (R)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_S.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_S.htm new file mode 100644 index 00000000..7d51c8cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_S.htm @@ -0,0 +1,159 @@ + + + +CLHS: Alphabetical Symbol Index (S) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (S)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_T.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_T.htm new file mode 100644 index 00000000..6452be25 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_T.htm @@ -0,0 +1,56 @@ + + + +CLHS: Alphabetical Symbol Index (T) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (T)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_U.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_U.htm new file mode 100644 index 00000000..a21b8160 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_U.htm @@ -0,0 +1,50 @@ + + + +CLHS: Alphabetical Symbol Index (U) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (U)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_V.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_V.htm new file mode 100644 index 00000000..6662fc7a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_V.htm @@ -0,0 +1,37 @@ + + + +CLHS: Alphabetical Symbol Index (V) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (V)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_W.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_W.htm new file mode 100644 index 00000000..ce1a7d48 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_W.htm @@ -0,0 +1,52 @@ + + + +CLHS: Alphabetical Symbol Index (W) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (W)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Y.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Y.htm new file mode 100644 index 00000000..d2a35dfe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Y.htm @@ -0,0 +1,31 @@ + + + +CLHS: Alphabetical Symbol Index (Y) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (Y)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Z.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Z.htm new file mode 100644 index 00000000..15f16d98 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Alph_Z.htm @@ -0,0 +1,30 @@ + + + +CLHS: Alphabetical Symbol Index (Z) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Alphabetical Symbol Index (Z)

    + + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_9.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_9.htm new file mode 100644 index 00000000..5ac8dc18 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_9.htm @@ -0,0 +1,1274 @@ + + + +CLHS: Index - Non-Alphabetic + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - Non-Alphabetic

    + +
    +Newline (format directive)
+  Tilde Newline: Ignored Newline
+" (reader macro)
+  Double-Quote
+#
+  Sharpsign
+# (reader macro)
+  Sharpsign
+# (sharpsign reader macro)
+  Sharpsign Sharpsign
+## (reader macro)
+  Sharpsign Sharpsign
+  Local Macro PPRINT-POP
+#' (reader macro)
+  Sharpsign Single-Quote
+#( (reader macro)
+  Sharpsign Left-Parenthesis
+#* (reader macro)
+  Sharpsign Asterisk
+#+ (reader macro)
+  Sharpsign Plus
+#- (reader macro)
+  Sharpsign Minus
+#. (reader macro)
+  Sharpsign Dot
+#: (reader macro)
+  Sharpsign Colon
+#< (reader macro)
+  Sharpsign Less-Than-Sign
+#= (reader macro)
+  Sharpsign Equal-Sign
+#A (reader macro)
+  Sharpsign A
+#B (reader macro)
+  Sharpsign B
+#C (reader macro)
+  Sharpsign C
+#O (reader macro)
+  Sharpsign O
+#P (reader macro)
+  Sharpsign P
+#R (reader macro)
+  Sharpsign R
+#S (reader macro)
+  Sharpsign S
+#X (reader macro)
+  Sharpsign X
+#\ (reader macro)
+  Sharpsign Backslash
+#| (reader macro)
+  Sharpsign Vertical-Bar
+$ (format directive)
+  Tilde Dollarsign: Monetary Floating-Point
+% (format directive)
+  Tilde Percent: Newline
+& (format directive)
+  Tilde Ampersand: Fresh-Line
+&allow-other-keys
+  Ordinary Lambda Lists
+  Specifiers for keyword parameters
+  Suppressing Keyword Argument Checking
+  Examples of Ordinary Lambda Lists
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  System Class FUNCTION
+  Type Specifier VALUES
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Keyword Arguments in Generic Functions and Methods
+  Standard Generic Function FUNCTION-KEYWORDS
+  Macro DEFMETHOD
+  Macro DEFINE-METHOD-COMBINATION
+&aux
+  Ordinary Lambda Lists
+  Specifiers for &aux variables
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Glossary Section ``A''
+  Glossary Section ``D''
+&body
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Glossary Section ``B''
+&environment
+  Macro Lambda Lists
+  Destructuring Lambda Lists
+  Defsetf Lambda Lists
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Function ENSURE-GENERIC-FUNCTION
+  Accessor FIND-CLASS
+  Glossary Section ``C''
+  Glossary Section ``D''
+&key
+  Ordinary Lambda Lists
+  Specifiers for keyword parameters
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Too Many Arguments
+  System Class FUNCTION
+  Type Specifier VALUES
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Initialization Arguments
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Keyword Arguments in Generic Functions and Methods
+  Macro DEFINE-METHOD-COMBINATION
+&optional
+  Ordinary Lambda Lists
+  Specifiers for optional parameters
+  Specifiers for keyword parameters
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-modify-macro Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  System Class FUNCTION
+  Type Specifier VALUES
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Macro SETF, PSETF
+&rest
+  Ordinary Lambda Lists
+  A specifier for a rest parameter
+  Specifiers for keyword parameters
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-modify-macro Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Too Many Arguments
+  Macro DEFMACRO
+  System Class FUNCTION
+  Type Specifier VALUES
+  Function APPLY
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Macro SETF, PSETF
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Keyword Arguments in Generic Functions and Methods
+  Macro DEFINE-METHOD-COMBINATION
+  Glossary Section ``B''
+  Glossary Section ``R''
+&whole
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Macro DEFINE-COMPILER-MACRO
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Macro DEFINE-METHOD-COMBINATION
+'
+  Single-Quote
+' (reader macro)
+  Single-Quote
+' (sharpsign reader macro)
+  Sharpsign Single-Quote
+(
+  Left-Parenthesis
+( (format directive)
+  Tilde Left-Paren: Case Conversion
+( (reader macro)
+  Left-Parenthesis
+( (sharpsign reader macro)
+  Sharpsign Left-Parenthesis
+()
+  NIL
+  Glossary Section ``Non-alphabetic''
+(SETF CLASS-NAME)
+  Standard Generic Function (SETF CLASS-NAME)
+(SETF DOCUMENTATION)
+  Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)
+)
+  Right-Parenthesis
+) (format directive)
+  Tilde Right-Paren: End of Case Conversion
+) (reader macro)
+  Right-Parenthesis
+*
+  Function *
+  Variable *, **, ***
+* (format directive)
+  Tilde Asterisk: Go-To
+* (sharpsign reader macro)
+  Sharpsign Asterisk
+**
+  Variable *, **, ***
+***
+  Variable *, **, ***
+*BREAK-ON-SIGNALS*
+  Variable *BREAK-ON-SIGNALS*
+*break-on-warnings*
+  Removed Variables
+*COMPILE-FILE-PATHNAME*
+  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
+*COMPILE-FILE-TRUENAME*
+  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
+*COMPILE-PRINT*
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+*COMPILE-VERBOSE*
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+*DEBUG-IO*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+*DEBUGGER-HOOK*
+  Variable *DEBUGGER-HOOK*
+*DEFAULT-PATHNAME-DEFAULTS*
+  Variable *DEFAULT-PATHNAME-DEFAULTS*
+*ERROR-OUTPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+*FEATURES*
+  Variable *FEATURES*
+*features*
+  Use of Read-Time Conditionals
+  Sharpsign Plus
+  Sharpsign Minus
+*GENSYM-COUNTER*
+  Variable *GENSYM-COUNTER*
+*LOAD-PATHNAME*
+  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
+*LOAD-PRINT*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+*LOAD-TRUENAME*
+  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
+*LOAD-VERBOSE*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+*MACROEXPAND-HOOK*
+  Variable *MACROEXPAND-HOOK*
+*MODULES*
+  Variable *MODULES*
+*PACKAGE*
+  Variable *PACKAGE*
+*PRINT-ARRAY*
+  Variable *PRINT-ARRAY*
+*PRINT-BASE*
+  Variable *PRINT-BASE*, *PRINT-RADIX*
+*PRINT-CASE*
+  Variable *PRINT-CASE*
+*PRINT-CIRCLE*
+  Variable *PRINT-CIRCLE*
+*print-circle*
+  Sharpsign Equal-Sign
+  Sharpsign Sharpsign
+*PRINT-ESCAPE*
+  Variable *PRINT-ESCAPE*
+*PRINT-GENSYM*
+  Variable *PRINT-GENSYM*
+*PRINT-LENGTH*
+  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
+*PRINT-LEVEL*
+  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
+*PRINT-LINES*
+  Variable *PRINT-LINES*
+*PRINT-MISER-WIDTH*
+  Variable *PRINT-MISER-WIDTH*
+*PRINT-PPRINT-DISPATCH*
+  Variable *PRINT-PPRINT-DISPATCH*
+*PRINT-PRETTY*
+  Variable *PRINT-PRETTY*
+*PRINT-RADIX*
+  Variable *PRINT-BASE*, *PRINT-RADIX*
+*PRINT-READABLY*
+  Variable *PRINT-READABLY*
+*PRINT-RIGHT-MARGIN*
+  Variable *PRINT-RIGHT-MARGIN*
+*QUERY-IO*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+*RANDOM-STATE*
+  Variable *RANDOM-STATE*
+*READ-BASE*
+  Variable *READ-BASE*
+*read-base*
+  Sharpsign B
+  Sharpsign O
+  Sharpsign X
+  Sharpsign R
+*READ-DEFAULT-FLOAT-FORMAT*
+  Variable *READ-DEFAULT-FLOAT-FORMAT*
+*READ-EVAL*
+  Variable *READ-EVAL*
+*read-eval*
+  Sharpsign Dot
+*READ-SUPPRESS*
+  Variable *READ-SUPPRESS*
+*READTABLE*
+  Variable *READTABLE*
+*STANDARD-INPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+*STANDARD-OUTPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+*TERMINAL-IO*
+  Variable *TERMINAL-IO*
+*TRACE-OUTPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
++
+  Built-in Method Combination Types
+  Function +
+  Variable +, ++, +++
++ (sharpsign reader macro)
+  Sharpsign Plus
+++
+  Variable +, ++, +++
++++
+  Variable +, ++, +++
+,
+  Comma
+, (reader macro)
+  Comma
+-
+  Function -
+  Variable -
+- (sharpsign reader macro)
+  Sharpsign Minus
+.
+  Left-Parenthesis
+. (sharpsign reader macro)
+  Sharpsign Dot
+..
+  Re-Reading Abbreviated Expressions
+  Variable *PRINT-LINES*
+...
+  Re-Reading Abbreviated Expressions
+  Local Macro PPRINT-POP
+/
+  Function /
+  Variable /, //, ///
+/ (format directive)
+  Tilde Slash: Call Function
+//
+  Variable /, //, ///
+///
+  Variable /, //, ///
+/=
+  Function =, /=, <, >, <=, >=
+1+
+  Function 1+, 1-
+1-
+  Function 1+, 1-
+: (sharpsign reader macro)
+  Sharpsign Colon
+:abort
+  Function CLOSE
+:absolute
+  Restrictions on Examining a Pathname Directory Component
+:accessor
+  Redefining Classes
+  Accessing Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:adjustable
+  Function MAKE-ARRAY
+:after
+  Introduction to Methods
+  Standard Method Combination
+  Macro DEFMETHOD
+  Glossary Section ``A''
+:allocation
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:allow-other-keys
+  Specifiers for keyword parameters
+  Suppressing Keyword Argument Checking
+  Examples of Ordinary Lambda Lists
+  Declaring the Validity of Initialization Arguments
+  Congruent Lambda-lists for all Methods of a Generic Function
+:ansi-cl
+  Variable *FEATURES*
+  Glossary Section ``F''
+:append
+  Function OPEN
+:argument-precedence-order
+  Sorting the Applicable Methods by Precedence Order
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+:arguments
+  Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Macro DEFINE-METHOD-COMBINATION
+  Glossary Section ``D''
+:around
+  Introduction to Methods
+  Standard Method Combination
+  Built-in Method Combination Types
+  Macro DEFMETHOD
+  Macro DEFINE-METHOD-COMBINATION
+  Glossary Section ``A''
+:array
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:back
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+  Function MERGE-PATHNAMES
+:base
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:before
+  Introduction to Methods
+  Standard Method Combination
+  Macro DEFMETHOD
+  Glossary Section ``B''
+:block
+  Function PPRINT-INDENT
+:capitalize
+  Variable *PRINT-CASE*
+:case
+  Case in Pathname Components
+  Local Case in Pathname Components
+  Common Case in Pathname Components
+  Function MAKE-PATHNAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:class
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:cltl1
+  Variable *FEATURES*
+:cltl2
+  Variable *FEATURES*
+:common
+  Common Case in Pathname Components
+  Function MAKE-PATHNAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+:common-lisp
+  Variable *FEATURES*
+:compile-toplevel
+  File Compilation
+  Processing of Top Level Forms
+  Special Operator EVAL-WHEN
+:conc-name
+  Macro DEFSTRUCT
+:constructor
+  Lambda Lists
+  Boa Lambda Lists
+  Macro DEFSTRUCT
+:copier
+  Macro DEFSTRUCT
+  Function COPY-STRUCTURE
+:count
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+:create
+  Function OPEN
+:current
+  Function PPRINT-INDENT
+:declare
+  Function ENSURE-GENERIC-FUNCTION
+:default
+  System Class BROADCAST-STREAM
+  Function OPEN
+  Function COMPILE-FILE
+  Function LOAD
+  Function ROOM
+  Glossary Section ``E''
+:default-initargs
+  Inheritance of Class Options
+  Object Creation and Initialization
+  Defaulting of Initialization Arguments
+  Rules for Initialization Arguments
+  Definitions of Make-Instance and Initialize-Instance
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:defaults
+  Function MAKE-PATHNAME
+:description
+  Macro DEFINE-METHOD-COMBINATION
+:device
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+:direction
+  Function OPEN
+  Glossary Section ``C''
+:directory
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+:displaced-index-offset
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function ARRAY-DISPLACEMENT
+:displaced-to
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function ARRAY-DISPLACEMENT
+:documentation
+  Inheritance of Slots and Slot Options
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFCLASS
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+  Macro DEFINE-CONDITION
+  Macro DEFPACKAGE
+:downcase
+  Effect of Readtable Case on the Lisp Printer
+  Variable *PRINT-CASE*
+  Effect of Readtable Case on the Lisp Reader
+  Glossary Section ``C''
+:draft-ansi-cl
+  Variable *FEATURES*
+:draft-ansi-cl-2
+  Variable *FEATURES*
+:element-type
+  Function TYPEP
+  Type SIMPLE-ARRAY
+  System Class VECTOR
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function MAKE-STRING
+  Function OPEN
+  Function MAKE-STRING-OUTPUT-STREAM
+  Macro WITH-OUTPUT-TO-STRING
+:end
+  Examples of Ordinary Lambda Lists
+  Function PARSE-INTEGER
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+  Function FILL
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+  Function PARSE-NAMESTRING
+  Function WRITE-STRING, WRITE-LINE
+  Function READ-SEQUENCE
+  Function WRITE-SEQUENCE
+  Macro WITH-INPUT-FROM-STRING
+  Function READ-FROM-STRING
+  Glossary Section ``F''
+:end1
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+:end2
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+:environment
+  Safe and Unsafe Calls
+  Function ENSURE-GENERIC-FUNCTION
+  Function MAKE-LOAD-FORM-SAVING-SLOTS
+:error
+  Function OPEN
+:escape
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:execute
+  File Compilation
+  Processing of Top Level Forms
+  Special Operator EVAL-WHEN
+  Function LOAD
+:expected-type
+  Condition Type TYPE-ERROR
+:export
+  Macro DEFPACKAGE
+:external
+  Function FIND-SYMBOL
+  Macro WITH-PACKAGE-ITERATOR
+  Function INTERN
+:external-format
+  Function OPEN
+  Function STREAM-EXTERNAL-FORMAT
+  Function COMPILE-FILE
+  Function LOAD
+:fill
+  Function PPRINT-NEWLINE
+:fill-pointer
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+:format-arguments
+  Condition Type SIMPLE-CONDITION
+:from-end
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+:generic-function
+  Macro DEFINE-METHOD-COMBINATION
+:generic-function-class
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+:gensym
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:host
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+:identity
+  Macro PRINT-UNREADABLE-OBJECT
+:identity-with-one-argument
+  Macro DEFINE-METHOD-COMBINATION
+:ieee-floating-point
+  Variable *FEATURES*
+:if-does-not-exist
+  Function OPEN
+  Function LOAD
+:if-exists
+  Function OPEN
+:import-from
+  Macro DEFPACKAGE
+:include
+  Type Relationships
+  Integrating Types and Classes
+  Macro DEFSTRUCT
+:index
+  Macro WITH-INPUT-FROM-STRING
+:inherited
+  Function FIND-SYMBOL
+  Macro WITH-PACKAGE-ITERATOR
+  Function INTERN
+:init-form
+  Macro DEFCLASS
+:initarg
+  Object Creation and Initialization
+  Declaring the Validity of Initialization Arguments
+  Rules for Initialization Arguments
+  Definitions of Make-Instance and Initialize-Instance
+  Inheritance of Slots and Slot Options
+  Standard Generic Function REINITIALIZE-INSTANCE
+  Standard Generic Function SHARED-INITIALIZE
+  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
+  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:initform
+  Object Creation and Initialization
+  Initialization Arguments
+  Defaulting of Initialization Arguments
+  Rules for Initialization Arguments
+  Shared-Initialize
+  Initialize-Instance
+  Definitions of Make-Instance and Initialize-Instance
+  Reinitializing an Instance
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Standard Generic Function SHARED-INITIALIZE
+  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
+  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+  Standard Generic Function SLOT-UNBOUND
+  Macro DEFCLASS
+  Standard Generic Function INITIALIZE-INSTANCE
+  Macro DEFINE-CONDITION
+  Glossary Section ``I''
+:initial-contents
+  Sharpsign A
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Printing Other Arrays
+:initial-element
+  Function MAKE-LIST
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function MAKE-STRING
+  Function MAKE-SEQUENCE
+:initial-offset
+  Macro DEFSTRUCT
+:initial-value
+  Function REDUCE
+:input
+  Function OPEN
+:installed
+  Glossary Section ``V''
+:instance
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:interactive
+  Interactive Use of Restarts
+  Function INVOKE-RESTART-INTERACTIVELY
+  Macro RESTART-CASE
+:interactive-function
+  Interactive Use of Restarts
+  Function INVOKE-RESTART-INTERACTIVELY
+  Macro RESTART-BIND
+:intern
+  Macro DEFPACKAGE
+:internal
+  Function FIND-SYMBOL
+  Macro WITH-PACKAGE-ITERATOR
+  Function INTERN
+:invert
+  Effect of Readtable Case on the Lisp Printer
+  Effect of Readtable Case on the Lisp Reader
+  Glossary Section ``C''
+:io
+  Function OPEN
+:junk-allowed
+  Function PARSE-INTEGER
+  Function PARSE-NAMESTRING
+:key
+  Function SUBLIS, NSUBLIS
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+  Function INTERSECTION, NINTERSECTION
+  Function ADJOIN
+  Macro PUSHNEW
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+  Function SUBSETP
+  Function UNION, NUNION
+  Satisfying a Two-Argument Test
+  Satisfying a One-Argument Test
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function SORT, STABLE-SORT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function MERGE
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+:lambda-list
+  Function ENSURE-GENERIC-FUNCTION
+:length
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:level
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:line
+  Function PPRINT-TAB
+:line-relative
+  Function PPRINT-TAB
+:linear
+  Function PPRINT-NEWLINE
+:lines
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:load-toplevel
+  File Compilation
+  Processing of Top Level Forms
+  Special Operator EVAL-WHEN
+:local
+  Local Case in Pathname Components
+  Common Case in Pathname Components
+  Function MAKE-PATHNAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+:mandatory
+  Function PPRINT-NEWLINE
+:metaclass
+  Defining Classes
+  Macro DEFCLASS
+:method
+  Macro DEFGENERIC
+:method-class
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+:method-combination
+  Applying method combination to the sorted list of applicable methods
+  Built-in Method Combination Types
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+:miser
+  Function PPRINT-NEWLINE
+:miser-width
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:most-specific-first
+  Built-in Method Combination Types
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+:most-specific-last
+  Built-in Method Combination Types
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+:name
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+:named
+  Macro DEFSTRUCT
+:new-version
+  Function OPEN
+:newest
+  Pathnames as Filenames
+  The Pathname Version Component
+  Restrictions on Examining a Pathname Version Component
+  Restrictions on Constructing Pathnames
+  Function MERGE-PATHNAMES
+  Examples of Truenames
+  Function OPEN
+  Glossary Section ``V''
+:nicknames
+  Function MAKE-PACKAGE
+  Macro DEFPACKAGE
+:no-error
+  Macro HANDLER-CASE
+:off
+  Notes about The KEYWORD Package
+:oldest
+  Notes about the Pathname Version Component
+  Glossary Section ``V''
+:on
+  Notes about The KEYWORD Package
+:operands
+  Condition Type ARITHMETIC-ERROR
+:operator
+  Macro DEFINE-METHOD-COMBINATION
+:order
+  Macro DEFINE-METHOD-COMBINATION
+:output
+  Function OPEN
+:output-file
+  Function COMPILE-FILE
+  Function COMPILE-FILE-PATHNAME
+:override
+  Macro WITH-COMPILATION-UNIT
+:overwrite
+  Function OPEN
+:per-line-prefix
+  Tilde Less-Than-Sign: Logical Block
+  Macro PPRINT-LOGICAL-BLOCK
+:pixel-size
+  Examples of Keyword Arguments in Generic Functions and Methods
+:pprint-dispatch
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:pre-line-prefix
+  Macro PPRINT-LOGICAL-BLOCK
+:predicate
+  Macro DEFSTRUCT
+:prefix
+  Tilde Less-Than-Sign: Logical Block
+  Macro PPRINT-LOGICAL-BLOCK
+:preserve
+  Effect of Readtable Case on the Lisp Printer
+  Effect of Readtable Case on the Lisp Reader
+  Glossary Section ``C''
+:preserve-whitespace
+  Function READ-FROM-STRING
+:pretty
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:previous
+  Glossary Section ``V''
+:print
+  Function COMPILE-FILE
+  Function LOAD
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+:print-function
+  Macro DEFSTRUCT
+  Printing Structures
+:print-object
+  Macro DEFSTRUCT
+  Printing Structures
+:probe
+  Function OPEN
+:radix
+  Function PARSE-INTEGER
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:read-only
+  Macro DEFSTRUCT
+:readably
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:reader
+  Redefining Classes
+  Accessing Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:rehash-size
+  Function MAKE-HASH-TABLE
+:rehash-threshold
+  Function MAKE-HASH-TABLE
+:relative
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+  Function MERGE-PATHNAMES
+:rename
+  Function OPEN
+:rename-and-delete
+  Function OPEN
+:report
+  Printing Conditions
+  Interactive Use of Restarts
+  Condition Type CONDITION
+  Macro DEFINE-CONDITION
+  Macro RESTART-CASE
+:report-function
+  Interactive Use of Restarts
+  Macro RESTART-BIND
+:required
+  Macro DEFINE-METHOD-COMBINATION
+:right-margin
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+:section
+  Function PPRINT-TAB
+:section-relative
+  Function PPRINT-TAB
+:shadow
+  Macro DEFPACKAGE
+:shadowing-import-from
+  Macro DEFPACKAGE
+:size
+  Macro DEFPACKAGE
+  Function MAKE-HASH-TABLE
+:slot-names
+  Function MAKE-LOAD-FORM-SAVING-SLOTS
+:start
+  Examples of Ordinary Lambda Lists
+  Function PARSE-INTEGER
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+  Function FILL
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+  Function PARSE-NAMESTRING
+  Function WRITE-STRING, WRITE-LINE
+  Function READ-SEQUENCE
+  Function WRITE-SEQUENCE
+  Macro WITH-INPUT-FROM-STRING
+  Function READ-FROM-STRING
+  Glossary Section ``F''
+:start1
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+:start2
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+:stream
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+:suffix
+  Tilde Less-Than-Sign: Logical Block
+  Macro PPRINT-LOGICAL-BLOCK
+:supersede
+  Function OPEN
+:test
+  Function EQUALP
+  Function COMPLEMENT
+  Restart Tests
+  Macro RESTART-CASE
+  Function SUBLIS, NSUBLIS
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+  Function TREE-EQUAL
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+  Function INTERSECTION, NINTERSECTION
+  Function ADJOIN
+  Macro PUSHNEW
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+  Function SUBSETP
+  Function UNION, NUNION
+  Satisfying a Two-Argument Test
+  Satisfying a One-Argument Test
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+  Modifying Hash Table Keys
+  Visible Modifications by Language Extensions
+  Function MAKE-HASH-TABLE
+:test-function
+  Restart Tests
+  Macro RESTART-BIND
+:test-not
+  Deprecated Argument Conventions
+  Function COMPLEMENT
+  Function SUBLIS, NSUBLIS
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+  Function TREE-EQUAL
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+  Function INTERSECTION, NINTERSECTION
+  Function ADJOIN
+  Macro PUSHNEW
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+  Function SUBSETP
+  Function UNION, NUNION
+  Satisfying a Two-Argument Test
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+:type
+  Boa Lambda Lists
+  Type Specifiers
+  Integrating Types and Classes
+  Function TYPE-OF
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFSTRUCT
+  Macro DEFINE-CONDITION
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+  Macro PRINT-UNREADABLE-OBJECT
+  Glossary Section ``S''
+:unspecific
+  The Pathname Type Component
+  The Pathname Version Component
+  :UNSPECIFIC as a Component Value
+  Relation between component values NIL and :UNSPECIFIC
+  Restrictions on Examining a Pathname Device Component
+  Restrictions on Examining a Pathname Directory Component
+  Restrictions on Examining a Pathname Name Component
+  Restrictions on Examining a Pathname Type Component
+  Restrictions on Examining a Pathname Version Component
+  Merging Pathnames
+  Examples of Merging Pathnames
+  The Device part of a Logical Pathname Namestring
+  Unspecific Components of a Logical Pathname
+  Function MAKE-PATHNAME
+  Function USER-HOMEDIR-PATHNAME
+  Glossary Section ``V''
+:up
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+:upcase
+  The Standard Readtable
+  Symbols as Tokens
+  Valid Patterns for Tokens
+  Effect of Readtable Case on the Lisp Printer
+  Variable *PRINT-CASE*
+  Effect of Readtable Case on the Lisp Reader
+  Macro WITH-STANDARD-IO-SYNTAX
+  Glossary Section ``C''
+:use
+  Function MAKE-PACKAGE
+  Macro DEFPACKAGE
+:verbose
+  Function ENSURE-DIRECTORIES-EXIST
+  Function COMPILE-FILE
+  Function LOAD
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+:version
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+:wild
+  The Pathname Type Component
+  The Pathname Version Component
+  :WILD as a Component Value
+  Restrictions on Wildcard Pathnames
+  Restrictions on Examining a Pathname Device Component
+  Restrictions on Examining a Pathname Directory Component
+  Restrictions on Examining a Pathname Name Component
+  Restrictions on Examining a Pathname Type Component
+  Restrictions on Examining a Pathname Version Component
+  The Version part of a Logical Pathname Namestring
+  Wildcard Words in a Logical Pathname Namestring
+  Function MAKE-PATHNAME
+  Function PATHNAME-MATCH-P
+  Function TRANSLATE-PATHNAME
+  Function MERGE-PATHNAMES
+  Glossary Section ``V''
+  Glossary Section ``W''
+:wild-inferiors
+  :WILD as a Component Value
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+  The Directory part of a Logical Pathname Namestring
+  Function MAKE-PATHNAME
+:wild-inferors
+  Glossary Section ``W''
+:writer
+  Redefining Classes
+  Accessing Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:x3j13
+  Variable *FEATURES*
+;
+  Semicolon
+; (format directive)
+  Tilde Semicolon: Clause Separator
+; (reader macro)
+  Semicolon
+<
+  Function =, /=, <, >, <=, >=
+< (format directive)
+  Tilde Less-Than-Sign: Logical Block
+  Tilde Less-Than-Sign: Justification
+< (sharpsign reader macro)
+  Sharpsign Less-Than-Sign
+<=
+  Function =, /=, <, >, <=, >=
+=
+  Function =, /=, <, >, <=, >=
+= (sharpsign reader macro)
+  Sharpsign Equal-Sign
+>
+  Function =, /=, <, >, <=, >=
+> (format directive)
+  Tilde Greater-Than-Sign: End of Justification
+>=
+  Function =, /=, <, >, <=, >=
+? (format directive)
+  Tilde Question-Mark: Recursive Processing
+[ (format directive)
+  Tilde Left-Bracket: Conditional Expression
+\ (sharpsign reader macro)
+  Sharpsign Backslash
+] (format directive)
+  Tilde Right-Bracket: End of Conditional Expression
+^ (format directive)
+  Tilde Circumflex: Escape Upward
+_ (format directive)
+  Tilde Underscore: Conditional Newline
+`
+  Backquote
+` (reader macro)
+  Backquote
+{ (format directive)
+  Tilde Left-Brace: Iteration
+| (format directive)
+  Tilde Vertical-Bar: Page
+| (sharpsign reader macro)
+  Sharpsign Vertical-Bar
+} (format directive)
+  Tilde Right-Brace: End of Iteration
+~ (format directive)
+  Tilde Tilde: Tilde
+~$ (format directive)
+  Tilde Dollarsign: Monetary Floating-Point
+~% (format directive)
+  Tilde Percent: Newline
+~& (format directive)
+  Tilde Ampersand: Fresh-Line
+~( (format directive)
+  Tilde Left-Paren: Case Conversion
+~) (format directive)
+  Tilde Right-Paren: End of Case Conversion
+~* (format directive)
+  Tilde Asterisk: Go-To
+~/ (format directive)
+  Tilde Slash: Call Function
+~; (format directive)
+  Tilde Semicolon: Clause Separator
+~< (format directive)
+  Tilde Less-Than-Sign: Logical Block
+  Tilde Less-Than-Sign: Justification
+~> (format directive)
+  Tilde Greater-Than-Sign: End of Justification
+~? (format directive)
+  Tilde Question-Mark: Recursive Processing
+~A (format directive)
+  Tilde A: Aesthetic
+~B (format directive)
+  Tilde B: Binary
+~C (format directive)
+  Tilde C: Character
+~D (format directive)
+  Tilde D: Decimal
+~E (format directive)
+  Tilde E: Exponential Floating-Point
+~F (format directive)
+  Tilde F: Fixed-Format Floating-Point
+~G (format directive)
+  Tilde G: General Floating-Point
+~I (format directive)
+  Tilde I: Indent
+~Newline (format directive)
+  Tilde Newline: Ignored Newline
+~O (format directive)
+  Tilde O: Octal
+~P (format directive)
+  Tilde P: Plural
+~R (format directive)
+  Tilde R: Radix
+~S (format directive)
+  Tilde S: Standard
+~T (format directive)
+  Tilde T: Tabulate
+~W (format directive)
+  Tilde W: Write
+~X (format directive)
+  Tilde X: Hexadecimal
+~[ (format directive)
+  Tilde Left-Bracket: Conditional Expression
+~] (format directive)
+  Tilde Right-Bracket: End of Conditional Expression
+~^ (format directive)
+  Tilde Circumflex: Escape Upward
+~_ (format directive)
+  Tilde Underscore: Conditional Newline
+~{ (format directive)
+  Tilde Left-Brace: Iteration
+~| (format directive)
+  Tilde Vertical-Bar: Page
+~} (format directive)
+  Tilde Right-Brace: End of Iteration
+~~ (format directive)
+  Tilde Tilde: Tilde
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_A.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_A.htm new file mode 100644 index 00000000..17e58ba3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_A.htm @@ -0,0 +1,355 @@ + + + +CLHS: Index - A + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - A

    + +
    +A (format directive)
+  Tilde A: Aesthetic
+A (sharpsign reader macro)
+  Sharpsign A
+abort
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+ABORT
+  Restart ABORT
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+:abort
+  Function CLOSE
+above (loop keyword)
+  The for-as-arithmetic subclause
+  Macro LOOP
+ABS
+  Function ABS
+absolute
+  Glossary Section ``A''
+:absolute
+  Restrictions on Examining a Pathname Directory Component
+access
+  Glossary Section ``A''
+accessibility
+  Glossary Section ``A''
+accessible
+  Glossary Section ``A''
+accessor
+  Glossary Section ``A''
+:accessor
+  Redefining Classes
+  Accessing Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+ACONS
+  Function ACONS
+ACOS
+  Function ASIN, ACOS, ATAN
+ACOSH
+  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
+across (loop keyword)
+  The for-as-across subclause
+  Macro LOOP
+active
+  Glossary Section ``A''
+actual adjustability
+  Glossary Section ``A''
+actual argument
+  Glossary Section ``A''
+actual array element type
+  Glossary Section ``A''
+actual complex part type
+  Glossary Section ``A''
+actual parameter
+  Glossary Section ``A''
+actually adjustable
+  Glossary Section ``A''
+ADD-METHOD
+  Standard Generic Function ADD-METHOD
+ADJOIN
+  Function ADJOIN
+ADJUST-ARRAY
+  Function ADJUST-ARRAY
+adjustability
+  Glossary Section ``A''
+adjustable
+  Glossary Section ``A''
+:adjustable
+  Function MAKE-ARRAY
+ADJUSTABLE-ARRAY-P
+  Function ADJUSTABLE-ARRAY-P
+:after
+  Introduction to Methods
+  Standard Method Combination
+  Macro DEFMETHOD
+  Glossary Section ``A''
+after method
+  Glossary Section ``A''
+alist
+  Glossary Section ``A''
+ALLOCATE-INSTANCE
+  Standard Generic Function ALLOCATE-INSTANCE
+:allocation
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+&allow-other-keys
+  Ordinary Lambda Lists
+  Specifiers for keyword parameters
+  Suppressing Keyword Argument Checking
+  Examples of Ordinary Lambda Lists
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  System Class FUNCTION
+  Type Specifier VALUES
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Keyword Arguments in Generic Functions and Methods
+  Standard Generic Function FUNCTION-KEYWORDS
+  Macro DEFMETHOD
+  Macro DEFINE-METHOD-COMBINATION
+:allow-other-keys
+  Specifiers for keyword parameters
+  Suppressing Keyword Argument Checking
+  Examples of Ordinary Lambda Lists
+  Declaring the Validity of Initialization Arguments
+  Congruent Lambda-lists for all Methods of a Generic Function
+ALPHA-CHAR-P
+  Function ALPHA-CHAR-P
+alphabetic
+  Glossary Section ``A''
+alphanumeric
+  Glossary Section ``A''
+ALPHANUMERICP
+  Function ALPHANUMERICP
+always (loop keyword)
+  Summary of Termination Test Clauses
+  Termination Test Clauses
+  Initial and Final Execution
+  Macro LOOP
+ampersand
+  Glossary Section ``A''
+Ampersand (format directive)
+  Tilde Ampersand: Fresh-Line
+and
+  Built-in Method Combination Types
+AND
+  Type Specifier AND
+  Macro AND
+and (loop keyword)
+  Summary of Variable Initialization and Stepping Clauses
+  Summary of Conditional Execution Clauses
+  Destructuring
+  Iteration Control
+  Local Variable Initializations
+  Conditional Execution Clauses
+  Macro LOOP
+anonymous
+  Glossary Section ``A''
+:ansi-cl
+  Variable *FEATURES*
+  Glossary Section ``F''
+apparently uninterned
+  Glossary Section ``A''
+APPEND
+  Function APPEND
+append
+  Built-in Method Combination Types
+:append
+  Function OPEN
+append (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+appending (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+applicable
+  Glossary Section ``A''
+applicable handler
+  Glossary Section ``A''
+applicable method
+  Glossary Section ``A''
+applicable restart
+  Glossary Section ``A''
+apply
+  Glossary Section ``A''
+APPLY
+  Function APPLY
+APROPOS
+  Function APROPOS, APROPOS-LIST
+APROPOS-LIST
+  Function APROPOS, APROPOS-LIST
+AREF
+  Accessor AREF
+argument
+  Glossary Section ``A''
+argument evaluation order
+  Glossary Section ``A''
+argument precedence order
+  Glossary Section ``A''
+:argument-precedence-order
+  Sorting the Applicable Methods by Precedence Order
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+:arguments
+  Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Macro DEFINE-METHOD-COMBINATION
+  Glossary Section ``D''
+ARITHMETIC-ERROR
+  Condition Type ARITHMETIC-ERROR
+ARITHMETIC-ERROR-OPERANDS
+  Function ARITHMETIC-ERROR-OPERANDS, ARITHMETIC-ERROR-OPERATION
+ARITHMETIC-ERROR-OPERATION
+  Function ARITHMETIC-ERROR-OPERANDS, ARITHMETIC-ERROR-OPERATION
+:around
+  Introduction to Methods
+  Standard Method Combination
+  Built-in Method Combination Types
+  Macro DEFMETHOD
+  Macro DEFINE-METHOD-COMBINATION
+  Glossary Section ``A''
+around method
+  Glossary Section ``A''
+ARRAY
+  System Class ARRAY
+array
+  Sharpsign A
+  Glossary Section ``A''
+:array
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+array element type
+  Glossary Section ``A''
+array total size
+  Glossary Section ``A''
+ARRAY-DIMENSION
+  Function ARRAY-DIMENSION
+ARRAY-DIMENSION-LIMIT
+  Constant Variable ARRAY-DIMENSION-LIMIT
+ARRAY-DIMENSIONS
+  Function ARRAY-DIMENSIONS
+ARRAY-DISPLACEMENT
+  Function ARRAY-DISPLACEMENT
+ARRAY-ELEMENT-TYPE
+  Function ARRAY-ELEMENT-TYPE
+ARRAY-HAS-FILL-POINTER-P
+  Function ARRAY-HAS-FILL-POINTER-P
+ARRAY-IN-BOUNDS-P
+  Function ARRAY-IN-BOUNDS-P
+ARRAY-RANK
+  Function ARRAY-RANK
+ARRAY-RANK-LIMIT
+  Constant Variable ARRAY-RANK-LIMIT
+ARRAY-ROW-MAJOR-INDEX
+  Function ARRAY-ROW-MAJOR-INDEX
+ARRAY-TOTAL-SIZE
+  Function ARRAY-TOTAL-SIZE
+ARRAY-TOTAL-SIZE-LIMIT
+  Constant Variable ARRAY-TOTAL-SIZE-LIMIT
+ARRAYP
+  Function ARRAYP
+as (loop keyword)
+  Summary of Variable Initialization and Stepping Clauses
+  Summary of Termination Test Clauses
+  Summary of Miscellaneous Clauses
+  Iteration Control
+  The for-as-arithmetic subclause
+  The for-as-in-list subclause
+  The for-as-on-list subclause
+  The for-as-equals-then subclause
+  The for-as-across subclause
+  The for-as-hash subclause
+  The for-as-package subclause
+  Initial and Final Execution
+  Macro LOOP
+ASH
+  Function ASH
+ASIN
+  Function ASIN, ACOS, ATAN
+ASINH
+  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
+ASSERT
+  Macro ASSERT
+assign
+  Glossary Section ``A''
+ASSOC
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+ASSOC-IF
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+ASSOC-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+association list
+  Glossary Section ``A''
+asterisk
+  Glossary Section ``A''
+Asterisk (format directive)
+  Tilde Asterisk: Go-To
+Asterisk (sharpsign reader macro)
+  Sharpsign Asterisk
+at-sign
+  Glossary Section ``A''
+ATAN
+  Function ASIN, ACOS, ATAN
+ATANH
+  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
+atom
+  Glossary Section ``A''
+ATOM
+  Type ATOM
+  Function ATOM
+atomic
+  Glossary Section ``A''
+atomic type specifier
+  Glossary Section ``A''
+attribute
+  Glossary Section ``A''
+&aux
+  Ordinary Lambda Lists
+  Specifiers for &aux variables
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Glossary Section ``A''
+  Glossary Section ``D''
+aux variable
+  Glossary Section ``A''
+auxiliary method
+  Glossary Section ``A''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_B.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_B.htm new file mode 100644 index 00000000..0f3ae7c5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_B.htm @@ -0,0 +1,236 @@ + + + +CLHS: Index - B + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - B

    + +
    +B (format directive)
+  Tilde B: Binary
+B (sharpsign reader macro)
+  Sharpsign B
+:back
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+  Function MERGE-PATHNAMES
+backquote
+  Glossary Section ``B''
+Backquote (reader macro)
+  Backquote
+backslash
+  Glossary Section ``B''
+Backslash (sharpsign reader macro)
+  Sharpsign Backslash
+bar
+  Nonsense Words
+:base
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+base character
+  Glossary Section ``B''
+base string
+  Glossary Section ``B''
+BASE-CHAR
+  Type BASE-CHAR
+BASE-STRING
+  Type BASE-STRING
+baz
+  Nonsense Words
+:before
+  Introduction to Methods
+  Standard Method Combination
+  Macro DEFMETHOD
+  Glossary Section ``B''
+before method
+  Glossary Section ``B''
+being (loop keyword)
+  The for-as-hash subclause
+  The for-as-package subclause
+  Macro LOOP
+below (loop keyword)
+  The for-as-arithmetic subclause
+  Macro LOOP
+bidirectional
+  Glossary Section ``B''
+BIGNUM
+  Type BIGNUM
+binary
+  Glossary Section ``B''
+bind
+  Glossary Section ``B''
+binding
+  Glossary Section ``B''
+bit
+  Glossary Section ``B''
+BIT
+  Type BIT
+  Accessor BIT, SBIT
+bit array
+  Glossary Section ``B''
+bit vector
+  Required Kinds of Specialized Arrays
+  Glossary Section ``B''
+BIT-AND
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-ANDC1
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-ANDC2
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-EQV
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-IOR
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-NAND
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-NOR
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-NOT
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-ORC1
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-ORC2
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+BIT-VECTOR
+  System Class BIT-VECTOR
+bit-vector
+  Sharpsign Asterisk
+BIT-VECTOR-P
+  Function BIT-VECTOR-P
+bit-wise logical operation specifier
+  Glossary Section ``B''
+BIT-XOR
+  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
+block
+  Glossary Section ``B''
+BLOCK
+  Special Operator BLOCK
+:block
+  Function PPRINT-INDENT
+block tag
+  Glossary Section ``B''
+bnf key
+  Modified BNF Syntax
+boa lambda list
+  Glossary Section ``B''
+&body
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Glossary Section ``B''
+body parameter
+  Glossary Section ``B''
+BOOLE
+  Function BOOLE
+BOOLE-1
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-2
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-AND
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-ANDC1
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-ANDC2
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-C1
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-C2
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-CLR
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-EQV
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-IOR
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-NAND
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-NOR
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-ORC1
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-ORC2
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-SET
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+BOOLE-XOR
+  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
+boolean
+  Glossary Section ``B''
+BOOLEAN
+  Type BOOLEAN
+boolean equivalent
+  Glossary Section ``B''
+BOTH-CASE-P
+  Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P
+bound
+  Glossary Section ``B''
+bound declaration
+  Glossary Section ``B''
+bounded
+  Glossary Section ``B''
+bounding index
+  Glossary Section ``B''
+bounding index designator
+  Glossary Section ``B''
+BOUNDP
+  Function BOUNDP
+BREAK
+  Function BREAK
+break loop
+  Glossary Section ``B''
+*BREAK-ON-SIGNALS*
+  Variable *BREAK-ON-SIGNALS*
+*break-on-warnings*
+  Removed Variables
+broadcast stream
+  Glossary Section ``B''
+BROADCAST-STREAM
+  System Class BROADCAST-STREAM
+BROADCAST-STREAM-STREAMS
+  Function BROADCAST-STREAM-STREAMS
+built-in class
+  Glossary Section ``B''
+built-in type
+  Glossary Section ``B''
+BUILT-IN-CLASS
+  System Class BUILT-IN-CLASS
+BUTLAST
+  Function BUTLAST, NBUTLAST
+by (loop keyword)
+  The for-as-arithmetic subclause
+  The for-as-in-list subclause
+  The for-as-on-list subclause
+  Macro LOOP
+byte
+  Glossary Section ``B''
+BYTE
+  Function BYTE, BYTE-SIZE, BYTE-POSITION
+byte specifier
+  Glossary Section ``B''
+BYTE-POSITION
+  Function BYTE, BYTE-SIZE, BYTE-POSITION
+BYTE-SIZE
+  Function BYTE, BYTE-SIZE, BYTE-POSITION
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_C.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_C.htm new file mode 100644 index 00000000..91c6f186 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_C.htm @@ -0,0 +1,551 @@ + + + +CLHS: Index - C + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - C

    + +
    +C (format directive)
+  Tilde C: Character
+C (sharpsign reader macro)
+  Sharpsign C
+CAAAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CAAADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CAAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CAADAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CAADDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CAADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CADAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CADADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CADAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CADDAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CADDDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CADDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+cadr
+  Glossary Section ``C''
+CADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+call
+  Glossary Section ``C''
+CALL-ARGUMENTS-LIMIT
+  Constant Variable CALL-ARGUMENTS-LIMIT
+CALL-METHOD
+  Local Macro CALL-METHOD, MAKE-METHOD
+CALL-NEXT-METHOD
+  Local Function CALL-NEXT-METHOD
+:capitalize
+  Variable *PRINT-CASE*
+captured initialization form
+  Glossary Section ``C''
+car
+  Glossary Section ``C''
+CAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+case
+  Glossary Section ``C''
+CASE
+  Macro CASE, CCASE, ECASE
+:case
+  Case in Pathname Components
+  Local Case in Pathname Components
+  Common Case in Pathname Components
+  Function MAKE-PATHNAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+case in symbol names
+  Case in Symbols
+case sensitivity mode
+  Glossary Section ``C''
+catch
+  Glossary Section ``C''
+CATCH
+  Special Operator CATCH
+catch tag
+  Glossary Section ``C''
+CCASE
+  Macro CASE, CCASE, ECASE
+CDAAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDAADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDADAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDADDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDDAAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDDADR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDDAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDDDAR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDDDDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CDDDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+cddr
+  Glossary Section ``C''
+CDDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+cdr
+  Glossary Section ``C''
+CDR
+  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
+CEILING
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+cell
+  Glossary Section ``C''
+CELL-ERROR
+  Condition Type CELL-ERROR
+CELL-ERROR-NAME
+  Function CELL-ERROR-NAME
+CERROR
+  Function CERROR
+CHANGE-CLASS
+  Standard Generic Function CHANGE-CLASS
+CHAR
+  Accessor CHAR, SCHAR
+char-bit
+  Removed Operators
+char-bits
+  Removed Operators
+char-bits-limit
+  Removed Variables
+CHAR-CODE
+  Function CHAR-CODE
+CHAR-CODE-LIMIT
+  Constant Variable CHAR-CODE-LIMIT
+char-control-bit
+  Removed Variables
+CHAR-DOWNCASE
+  Function CHAR-UPCASE, CHAR-DOWNCASE
+CHAR-EQUAL
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+char-font
+  Removed Operators
+char-font-limit
+  Removed Variables
+CHAR-GREATERP
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+char-hyper-bit
+  Removed Variables
+CHAR-INT
+  Function CHAR-INT
+CHAR-LESSP
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+char-meta-bit
+  Removed Variables
+CHAR-NAME
+  Function CHAR-NAME
+CHAR-NOT-EQUAL
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR-NOT-GREATERP
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR-NOT-LESSP
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+char-super-bit
+  Removed Variables
+CHAR-UPCASE
+  Function CHAR-UPCASE, CHAR-DOWNCASE
+CHAR/=
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR<
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR<=
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR=
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR>
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHAR>=
+  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
+CHARACTER
+  System Class CHARACTER
+  Function CHARACTER
+character
+  Sharpsign Backslash
+  Glossary Section ``C''
+character code
+  Glossary Section ``C''
+character designator
+  Glossary Section ``C''
+CHARACTERP
+  Function CHARACTERP
+CHECK-TYPE
+  Macro CHECK-TYPE
+circular
+  Glossary Section ``C''
+circular list
+  Glossary Section ``C''
+Circumflex (format directive)
+  Tilde Circumflex: Escape Upward
+CIS
+  Function CIS
+CL
+  The COMMON-LISP Package
+CL-USER
+  The COMMON-LISP-USER Package
+class
+  Glossary Section ``C''
+CLASS
+  System Class CLASS
+:class
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+class designator
+  Glossary Section ``C''
+class precedence list
+  Glossary Section ``C''
+CLASS-NAME
+  Standard Generic Function CLASS-NAME
+CLASS-OF
+  Function CLASS-OF
+CLEAR-INPUT
+  Function CLEAR-INPUT
+CLEAR-OUTPUT
+  Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT
+close
+  Glossary Section ``C''
+CLOSE
+  Function CLOSE
+closed
+  Glossary Section ``C''
+closure
+  Glossary Section ``C''
+CLRHASH
+  Function CLRHASH
+:cltl1
+  Variable *FEATURES*
+:cltl2
+  Variable *FEATURES*
+coalesce
+  Glossary Section ``C''
+code
+  Glossary Section ``C''
+code-char
+  Removed Argument Conventions
+CODE-CHAR
+  Function CODE-CHAR
+coerce
+  Glossary Section ``C''
+COERCE
+  Function COERCE
+collect (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+collecting (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+colon
+  Glossary Section ``C''
+Colon (sharpsign reader macro)
+  Sharpsign Colon
+comma
+  Glossary Section ``C''
+Comma (reader macro)
+  Comma
+comment
+  Semicolon
+  Sharpsign Vertical-Bar
+:common
+  Common Case in Pathname Components
+  Function MAKE-PATHNAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+COMMON-LISP
+  Symbols in the COMMON-LISP Package
+  The COMMON-LISP Package
+COMMON-LISP-USER
+  The COMMON-LISP-USER Package
+:common-lisp
+  Variable *FEATURES*
+commonp
+  Removed Operators
+compilation
+  Glossary Section ``C''
+compilation environment
+  Glossary Section ``C''
+compilation unit
+  Glossary Section ``C''
+COMPILE
+  Function COMPILE
+compile
+  Minimal Compilation
+  Special Operator EVAL-WHEN
+  Glossary Section ``C''
+compile time
+  Glossary Section ``C''
+COMPILE-FILE
+  Function COMPILE-FILE
+compile-file
+  Minimal Compilation
+COMPILE-FILE-PATHNAME
+  Function COMPILE-FILE-PATHNAME
+compile-time definition
+  Glossary Section ``C''
+compiled code
+  Glossary Section ``C''
+compiled file
+  Glossary Section ``C''
+compiled function
+  Glossary Section ``C''
+COMPILED-FUNCTION
+  Type COMPILED-FUNCTION
+COMPILED-FUNCTION-P
+  Function COMPILED-FUNCTION-P
+*COMPILE-FILE-PATHNAME*
+  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
+*COMPILE-FILE-TRUENAME*
+  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
+*COMPILE-PRINT*
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+compiler
+  Glossary Section ``C''
+compiler macro
+  Minimal Compilation
+  Glossary Section ``C''
+compiler macro expansion
+  Glossary Section ``C''
+compiler macro form
+  Glossary Section ``C''
+compiler macro function
+  Glossary Section ``C''
+COMPILER-MACRO-FUNCTION
+  Accessor COMPILER-MACRO-FUNCTION
+:compile-toplevel
+  File Compilation
+  Processing of Top Level Forms
+  Special Operator EVAL-WHEN
+*COMPILE-VERBOSE*
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+COMPLEMENT
+  Function COMPLEMENT
+COMPLEX
+  System Class COMPLEX
+  Function COMPLEX
+complex
+  Sharpsign C
+  Printing Complexes
+  Glossary Section ``C''
+complex float
+  Glossary Section ``C''
+complex part type
+  Glossary Section ``C''
+complex rational
+  Glossary Section ``C''
+complex single float
+  Glossary Section ``C''
+COMPLEXP
+  Function COMPLEXP
+composite stream
+  Glossary Section ``C''
+compound form
+  Glossary Section ``C''
+compound type specifier
+  Glossary Section ``C''
+COMPUTE-APPLICABLE-METHODS
+  Standard Generic Function COMPUTE-APPLICABLE-METHODS
+COMPUTE-RESTARTS
+  Function COMPUTE-RESTARTS
+CONCATENATE
+  Function CONCATENATE
+concatenated stream
+  Glossary Section ``C''
+CONCATENATED-STREAM
+  System Class CONCATENATED-STREAM
+CONCATENATED-STREAM-STREAMS
+  Function CONCATENATED-STREAM-STREAMS
+:conc-name
+  Macro DEFSTRUCT
+COND
+  Macro COND
+condition
+  Glossary Section ``C''
+CONDITION
+  Condition Type CONDITION
+condition designator
+  Condition Designators
+  Glossary Section ``C''
+condition handler
+  Glossary Section ``C''
+condition reporter
+  Glossary Section ``C''
+conditional newline
+  Glossary Section ``C''
+conformance
+  Glossary Section ``C''
+conforming code
+  Conforming Programs
+  Glossary Section ``C''
+conforming implementation
+  Glossary Section ``C''
+conforming processor
+  Glossary Section ``C''
+conforming program
+  Conforming Programs
+  Glossary Section ``C''
+congruent
+  Glossary Section ``C''
+CONJUGATE
+  Function CONJUGATE
+CONS
+  System Class CONS
+  Function CONS
+cons
+  Backquote
+  Comma
+  Glossary Section ``C''
+consequences
+  Error Terminology
+CONSP
+  Function CONSP
+constant
+  Glossary Section ``C''
+constant form
+  Glossary Section ``C''
+constant object
+  Glossary Section ``C''
+constant variable
+  Glossary Section ``C''
+CONSTANTLY
+  Function CONSTANTLY
+CONSTANTP
+  Function CONSTANTP
+constituent
+  Glossary Section ``C''
+constituent trait
+  Glossary Section ``C''
+constructed stream
+  Glossary Section ``C''
+:constructor
+  Lambda Lists
+  Boa Lambda Lists
+  Macro DEFSTRUCT
+contagion
+  Glossary Section ``C''
+continuable
+  Glossary Section ``C''
+continue
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+CONTINUE
+  Restart CONTINUE
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+control form
+  Glossary Section ``C''
+CONTROL-ERROR
+  Condition Type CONTROL-ERROR
+:copier
+  Macro DEFSTRUCT
+  Function COPY-STRUCTURE
+copy
+  Glossary Section ``C''
+COPY-ALIST
+  Function COPY-ALIST
+COPY-LIST
+  Function COPY-LIST
+COPY-PPRINT-DISPATCH
+  Function COPY-PPRINT-DISPATCH
+COPY-READTABLE
+  Function COPY-READTABLE
+COPY-SEQ
+  Function COPY-SEQ
+COPY-STRUCTURE
+  Function COPY-STRUCTURE
+COPY-SYMBOL
+  Function COPY-SYMBOL
+COPY-TREE
+  Function COPY-TREE
+correctable
+  Glossary Section ``C''
+COS
+  Function SIN, COS, TAN
+COSH
+  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
+COUNT
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+:count
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+count (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+COUNT-IF
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+COUNT-IF-NOT
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+counting (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+:create
+  Function OPEN
+CTYPECASE
+  Macro TYPECASE, CTYPECASE, ETYPECASE
+:current
+  Function PPRINT-INDENT
+current input base
+  Glossary Section ``C''
+current logical block
+  Glossary Section ``C''
+current output base
+  Glossary Section ``C''
+current package
+  Glossary Section ``C''
+current pprint dispatch table
+  Glossary Section ``C''
+current random state
+  Glossary Section ``C''
+current readtable
+  Glossary Section ``C''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_D.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_D.htm new file mode 100644 index 00000000..2bcd4c49 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_D.htm @@ -0,0 +1,330 @@ + + + +CLHS: Index - D + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - D

    + +
    +D (format directive)
+  Tilde D: Decimal
+data type
+  Glossary Section ``D''
+debug I/O
+  Glossary Section ``D''
+debugger
+  Glossary Section ``D''
+*DEBUGGER-HOOK*
+  Variable *DEBUGGER-HOOK*
+*DEBUG-IO*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+DECF
+  Macro INCF, DECF
+DECLAIM
+  Macro DECLAIM
+DECLARATION
+  Declaration DECLARATION
+declaration
+  Declarations
+  Minimal Declaration Processing Requirements
+  Glossary Section ``D''
+declaration identifier
+  Declaration Identifiers
+  Glossary Section ``D''
+declaration specifier
+  Glossary Section ``D''
+declare
+  Glossary Section ``D''
+DECLARE
+  Symbol DECLARE
+:declare
+  Function ENSURE-GENERIC-FUNCTION
+decline
+  Glossary Section ``D''
+DECODE-FLOAT
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+DECODE-UNIVERSAL-TIME
+  Function DECODE-UNIVERSAL-TIME
+decoded time
+  Glossary Section ``D''
+:default
+  System Class BROADCAST-STREAM
+  Function OPEN
+  Function COMPILE-FILE
+  Function LOAD
+  Function ROOM
+  Glossary Section ``E''
+default method
+  Glossary Section ``D''
+defaulted initialization argument list
+  Glossary Section ``D''
+:default-initargs
+  Inheritance of Class Options
+  Object Creation and Initialization
+  Defaulting of Initialization Arguments
+  Rules for Initialization Arguments
+  Definitions of Make-Instance and Initialize-Instance
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+*DEFAULT-PATHNAME-DEFAULTS*
+  Variable *DEFAULT-PATHNAME-DEFAULTS*
+:defaults
+  Function MAKE-PATHNAME
+DEFCLASS
+  Macro DEFCLASS
+DEFCONSTANT
+  Macro DEFCONSTANT
+DEFGENERIC
+  Macro DEFGENERIC
+DEFINE-COMPILER-MACRO
+  Macro DEFINE-COMPILER-MACRO
+DEFINE-CONDITION
+  Macro DEFINE-CONDITION
+DEFINE-METHOD-COMBINATION
+  Macro DEFINE-METHOD-COMBINATION
+define-method-combination arguments lambda list
+  Glossary Section ``D''
+DEFINE-MODIFY-MACRO
+  Macro DEFINE-MODIFY-MACRO
+define-modify-macro lambda list
+  Glossary Section ``D''
+DEFINE-SETF-EXPANDER
+  Macro DEFINE-SETF-EXPANDER
+DEFINE-SYMBOL-MACRO
+  Macro DEFINE-SYMBOL-MACRO
+defined name
+  Glossary Section ``D''
+defining form
+  Glossary Section ``D''
+DEFMACRO
+  Macro DEFMACRO
+DEFMETHOD
+  Macro DEFMETHOD
+DEFPACKAGE
+  Macro DEFPACKAGE
+DEFPARAMETER
+  Macro DEFPARAMETER, DEFVAR
+DEFSETF
+  Macro DEFSETF
+defsetf lambda list
+  Glossary Section ``D''
+DEFSTRUCT
+  Macro DEFSTRUCT
+DEFTYPE
+  Macro DEFTYPE
+deftype lambda list
+  Glossary Section ``D''
+DEFUN
+  Macro DEFUN
+DEFVAR
+  Macro DEFPARAMETER, DEFVAR
+DELETE
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+DELETE-DUPLICATES
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+DELETE-FILE
+  Function DELETE-FILE
+DELETE-IF
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+DELETE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+DELETE-PACKAGE
+  Function DELETE-PACKAGE
+DENOMINATOR
+  Function NUMERATOR, DENOMINATOR
+denormalized
+  Glossary Section ``D''
+DEPOSIT-FIELD
+  Function DEPOSIT-FIELD
+derived type
+  Glossary Section ``D''
+derived type specifier
+  Type Specifiers
+  Glossary Section ``D''
+DESCRIBE
+  Function DESCRIBE
+DESCRIBE-OBJECT
+  Standard Generic Function DESCRIBE-OBJECT
+:description
+  Macro DEFINE-METHOD-COMBINATION
+designator
+  Glossary Section ``D''
+destructive
+  Glossary Section ``D''
+destructuring lambda list
+  Glossary Section ``D''
+DESTRUCTURING-BIND
+  Macro DESTRUCTURING-BIND
+:device
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+different
+  Glossary Section ``D''
+digit
+  Glossary Section ``D''
+digit-char
+  Removed Argument Conventions
+DIGIT-CHAR
+  Function DIGIT-CHAR
+DIGIT-CHAR-P
+  Function DIGIT-CHAR-P
+dimension
+  Glossary Section ``D''
+direct instance
+  Glossary Section ``D''
+direct subclass
+  Glossary Section ``D''
+direct superclass
+  Glossary Section ``D''
+:direction
+  Function OPEN
+  Glossary Section ``C''
+DIRECTORY
+  Function DIRECTORY
+:directory
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+DIRECTORY-NAMESTRING
+  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
+DISASSEMBLE
+  Function DISASSEMBLE
+disestablish
+  Glossary Section ``D''
+disjoint
+  Glossary Section ``D''
+dispatching macro character
+  Glossary Section ``D''
+displaced array
+  Glossary Section ``D''
+:displaced-index-offset
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function ARRAY-DISPLACEMENT
+:displaced-to
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function ARRAY-DISPLACEMENT
+distinct
+  Glossary Section ``D''
+DIVISION-BY-ZERO
+  Condition Type DIVISION-BY-ZERO
+DO
+  Macro DO, DO*
+do (loop keyword)
+  Parsing Loop Clauses
+  Summary of Unconditional Execution Clauses
+  Unconditional Execution Clauses
+  Macro LOOP
+DO*
+  Macro DO, DO*
+DO-ALL-SYMBOLS
+  Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
+DO-EXTERNAL-SYMBOLS
+  Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
+DO-SYMBOLS
+  Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
+DOCUMENTATION
+  Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)
+:documentation
+  Inheritance of Slots and Slot Options
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFCLASS
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+  Macro DEFINE-CONDITION
+  Macro DEFPACKAGE
+documentation string
+  Glossary Section ``D''
+doing (loop keyword)
+  Parsing Loop Clauses
+  Summary of Unconditional Execution Clauses
+  Unconditional Execution Clauses
+  Macro LOOP
+DOLIST
+  Macro DOLIST
+Dollarsign (format directive)
+  Tilde Dollarsign: Monetary Floating-Point
+dot
+  Left-Parenthesis
+  Local Macro PPRINT-POP
+  Glossary Section ``D''
+Dot (sharpsign reader macro)
+  Sharpsign Dot
+Dot Dot
+  Re-Reading Abbreviated Expressions
+  Variable *PRINT-LINES*
+Dot Dot Dot
+  Re-Reading Abbreviated Expressions
+  Local Macro PPRINT-POP
+DOTIMES
+  Macro DOTIMES
+dotted list
+  Glossary Section ``D''
+dotted pair
+  Glossary Section ``D''
+double float
+  Glossary Section ``D''
+DOUBLE-FLOAT
+  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
+DOUBLE-FLOAT-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+DOUBLE-FLOAT-NEGATIVE-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+double-quote
+  Glossary Section ``D''
+Double-Quote (reader macro)
+  Double-Quote
+:downcase
+  Effect of Readtable Case on the Lisp Printer
+  Variable *PRINT-CASE*
+  Effect of Readtable Case on the Lisp Reader
+  Glossary Section ``C''
+downfrom (loop keyword)
+  The for-as-arithmetic subclause
+  Macro LOOP
+downto (loop keyword)
+  The for-as-arithmetic subclause
+  Macro LOOP
+DPB
+  Function DPB
+:draft-ansi-cl
+  Variable *FEATURES*
+:draft-ansi-cl-2
+  Variable *FEATURES*
+DRIBBLE
+  Function DRIBBLE
+dynamic binding
+  Glossary Section ``D''
+dynamic environment
+  Glossary Section ``D''
+dynamic extent
+  Glossary Section ``D''
+dynamic scope
+  Glossary Section ``D''
+dynamic variable
+  Glossary Section ``D''
+DYNAMIC-EXTENT
+  Declaration DYNAMIC-EXTENT
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_E.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_E.htm new file mode 100644 index 00000000..874cb0aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_E.htm @@ -0,0 +1,292 @@ + + + +CLHS: Index - E + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - E

    + +
    +E (format directive)
+  Tilde E: Exponential Floating-Point
+each (loop keyword)
+  The for-as-hash subclause
+  The for-as-package subclause
+  Macro LOOP
+ECASE
+  Macro CASE, CCASE, ECASE
+echo stream
+  Glossary Section ``E''
+ECHO-STREAM
+  System Class ECHO-STREAM
+ECHO-STREAM-INPUT-STREAM
+  Function ECHO-STREAM-INPUT-STREAM, ECHO-STREAM-OUTPUT-STREAM
+ECHO-STREAM-OUTPUT-STREAM
+  Function ECHO-STREAM-INPUT-STREAM, ECHO-STREAM-OUTPUT-STREAM
+ED
+  Function ED
+effective method
+  Glossary Section ``E''
+EIGHTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+element
+  Glossary Section ``E''
+element type
+  Glossary Section ``E''
+:element-type
+  Function TYPEP
+  Type SIMPLE-ARRAY
+  System Class VECTOR
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function MAKE-STRING
+  Function OPEN
+  Function MAKE-STRING-OUTPUT-STREAM
+  Macro WITH-OUTPUT-TO-STRING
+else (loop keyword)
+  Summary of Conditional Execution Clauses
+  Conditional Execution Clauses
+  Macro LOOP
+ELT
+  Accessor ELT
+em
+  Glossary Section ``E''
+empty list
+  Glossary Section ``E''
+empty type
+  Glossary Section ``E''
+ENCODE-UNIVERSAL-TIME
+  function ENCODE-UNIVERSAL-TIME
+:end
+  Examples of Ordinary Lambda Lists
+  Function PARSE-INTEGER
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+  Function FILL
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+  Function PARSE-NAMESTRING
+  Function WRITE-STRING, WRITE-LINE
+  Function READ-SEQUENCE
+  Function WRITE-SEQUENCE
+  Macro WITH-INPUT-FROM-STRING
+  Function READ-FROM-STRING
+  Glossary Section ``F''
+:end1
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+:end2
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+end (loop keyword)
+  Summary of Conditional Execution Clauses
+  Conditional Execution Clauses
+  Macro LOOP
+end of file
+  Glossary Section ``E''
+END-OF-FILE
+  Condition Type END-OF-FILE
+ENDP
+  Function ENDP
+ENOUGH-NAMESTRING
+  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
+ENSURE-DIRECTORIES-EXIST
+  Function ENSURE-DIRECTORIES-EXIST
+ENSURE-GENERIC-FUNCTION
+  Function ENSURE-GENERIC-FUNCTION
+environment
+  Glossary Section ``E''
+&environment
+  Macro Lambda Lists
+  Destructuring Lambda Lists
+  Defsetf Lambda Lists
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Function ENSURE-GENERIC-FUNCTION
+  Accessor FIND-CLASS
+  Glossary Section ``C''
+  Glossary Section ``D''
+:environment
+  Safe and Unsafe Calls
+  Function ENSURE-GENERIC-FUNCTION
+  Function MAKE-LOAD-FORM-SAVING-SLOTS
+environment object
+  Glossary Section ``E''
+environment parameter
+  Glossary Section ``E''
+EQ
+  Function EQ
+EQL
+  Type Specifier EQL
+  Function EQL
+EQUAL
+  Function EQUAL
+Equal-Sign (sharpsign reader macro)
+  Sharpsign Equal-Sign
+EQUALP
+  Function EQUALP
+error
+  Glossary Section ``E''
+ERROR
+  Condition Type ERROR
+  Function ERROR
+:error
+  Function OPEN
+error output
+  Glossary Section ``E''
+error terminology
+  Error Terminology
+*ERROR-OUTPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+escape
+  Glossary Section ``E''
+:escape
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+establish
+  Glossary Section ``E''
+ETYPECASE
+  Macro TYPECASE, CTYPECASE, ETYPECASE
+EVAL
+  Function EVAL
+eval
+  Sharpsign Dot
+  Special Operator EVAL-WHEN
+EVAL-WHEN
+  Special Operator EVAL-WHEN
+eval-when
+  Processing of Top Level Forms
+evaluate
+  Glossary Section ``E''
+evaluation
+  Evaluation
+  Glossary Section ``E''
+evaluation environment
+  Glossary Section ``E''
+evaluation order
+  Special Operator LOAD-TIME-VALUE
+  Evaluation of Subforms to Places
+  Special Operator CATCH
+  Macro MULTIPLE-VALUE-SETQ
+  Order of Execution
+  The for-as-arithmetic subclause
+  Defaulting of Initialization Arguments
+  Macro ASSERT
+  Accessor LDB
+EVENP
+  Function EVENP, ODDP
+EVERY
+  Function EVERY, SOME, NOTEVERY, NOTANY
+execute
+  Glossary Section ``E''
+:execute
+  File Compilation
+  Processing of Top Level Forms
+  Special Operator EVAL-WHEN
+  Function LOAD
+execution time
+  Glossary Section ``E''
+exhaustive partition
+  Glossary Section ``E''
+exhaustive union
+  Glossary Section ``E''
+exit point
+  Glossary Section ``E''
+EXP
+  Function EXP, EXPT
+:expected-type
+  Condition Type TYPE-ERROR
+explicit return
+  Glossary Section ``E''
+explicit use
+  Glossary Section ``E''
+exponent marker
+  Glossary Section ``E''
+export
+  Glossary Section ``E''
+EXPORT
+  Function EXPORT
+:export
+  Macro DEFPACKAGE
+exported
+  Glossary Section ``E''
+expressed adjustability
+  Glossary Section ``E''
+expressed array element type
+  Glossary Section ``E''
+expressed complex part type
+  Glossary Section ``E''
+expression
+  Glossary Section ``E''
+expressly adjustable
+  Glossary Section ``E''
+EXPT
+  Function EXP, EXPT
+extended character
+  Glossary Section ``E''
+extended function designator
+  Glossary Section ``E''
+extended lambda list
+  Glossary Section ``E''
+EXTENDED-CHAR
+  Type EXTENDED-CHAR
+extension
+  Glossary Section ``E''
+extensions
+  Error Terminology
+extent
+  Glossary Section ``E''
+:external
+  Function FIND-SYMBOL
+  Macro WITH-PACKAGE-ITERATOR
+  Function INTERN
+external file format
+  Glossary Section ``E''
+external file format designator
+  Glossary Section ``E''
+external symbol
+  Internal and External Symbols
+  Glossary Section ``E''
+external-symbol (loop keyword)
+  The for-as-package subclause
+  Macro LOOP
+external-symbols (loop keyword)
+  The for-as-package subclause
+  Macro LOOP
+:external-format
+  Function OPEN
+  Function STREAM-EXTERNAL-FORMAT
+  Function COMPILE-FILE
+  Function LOAD
+externalizable object
+  Externalizable Objects
+  Glossary Section ``E''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_F.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_F.htm new file mode 100644 index 00000000..29686dc6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_F.htm @@ -0,0 +1,285 @@ + + + +CLHS: Index - F + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - F

    + +
    +F (format directive)
+  Tilde F: Fixed-Format Floating-Point
+false
+  Glossary Section ``F''
+fbound
+  Glossary Section ``F''
+FBOUNDP
+  Function FBOUNDP
+FCEILING
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+FDEFINITION
+  Accessor FDEFINITION
+feature
+  Glossary Section ``F''
+feature expression
+  Feature Expressions
+  Glossary Section ``F''
+*FEATURES*
+  Variable *FEATURES*
+*features*
+  Use of Read-Time Conditionals
+  Sharpsign Plus
+  Sharpsign Minus
+features list
+  Glossary Section ``F''
+FFLOOR
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+FIFTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+file
+  File System Concepts
+  Glossary Section ``F''
+file compiler
+  Glossary Section ``F''
+file position
+  Glossary Section ``F''
+file position designator
+  Glossary Section ``F''
+file stream
+  File Streams
+  Glossary Section ``F''
+file system
+  Glossary Section ``F''
+FILE-AUTHOR
+  Function FILE-AUTHOR
+FILE-ERROR
+  Condition Type FILE-ERROR
+FILE-ERROR-PATHNAME
+  Function FILE-ERROR-PATHNAME
+FILE-LENGTH
+  Function FILE-LENGTH
+FILE-NAMESTRING
+  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
+FILE-POSITION
+  Function FILE-POSITION
+FILE-STREAM
+  System Class FILE-STREAM
+FILE-STRING-LENGTH
+  Function FILE-STRING-LENGTH
+FILE-WRITE-DATE
+  Function FILE-WRITE-DATE
+filename
+  File System Concepts
+  Glossary Section ``F''
+FILL
+  Function FILL
+:fill
+  Function PPRINT-NEWLINE
+fill pointer
+  Glossary Section ``F''
+FILL-POINTER
+  Accessor FILL-POINTER
+fill-style conditional newline
+  Examples of using the Pretty Printer
+  Function PPRINT-NEWLINE
+:fill-pointer
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+finally (loop keyword)
+  Parsing Loop Clauses
+  Expanding Loop Forms
+  Summary of Miscellaneous Clauses
+  Order of Execution
+  Value Accumulation Clauses
+  Termination Test Clauses
+  Control Transfer Clauses
+  Initial and Final Execution
+  Macro LOOP
+FIND
+  Function FIND, FIND-IF, FIND-IF-NOT
+FIND-ALL-SYMBOLS
+  Function FIND-ALL-SYMBOLS
+FIND-CLASS
+  Accessor FIND-CLASS
+FIND-IF
+  Function FIND, FIND-IF, FIND-IF-NOT
+FIND-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+FIND-METHOD
+  Standard Generic Function FIND-METHOD
+FIND-PACKAGE
+  Function FIND-PACKAGE
+FIND-RESTART
+  Function FIND-RESTART
+FIND-SYMBOL
+  Function FIND-SYMBOL
+FINISH-OUTPUT
+  Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT
+finite
+  Glossary Section ``F''
+FIRST
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+fixnum
+  Glossary Section ``F''
+FIXNUM
+  Type FIXNUM
+FLET
+  Special Operator FLET, LABELS, MACROLET
+float
+  Printing Floats
+  Glossary Section ``F''
+FLOAT
+  System Class FLOAT
+  Function FLOAT
+FLOAT-DIGITS
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+FLOAT-PRECISION
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+FLOAT-RADIX
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+FLOAT-SIGN
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+FLOATING-POINT-INEXACT
+  Condition Type FLOATING-POINT-INEXACT
+FLOATING-POINT-INVALID-OPERATION
+  Condition Type FLOATING-POINT-INVALID-OPERATION
+FLOATING-POINT-OVERFLOW
+  Condition Type FLOATING-POINT-OVERFLOW
+FLOATING-POINT-UNDERFLOW
+  Condition Type FLOATING-POINT-UNDERFLOW
+FLOATP
+  Function FLOATP
+FLOOR
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+FMAKUNBOUND
+  Function FMAKUNBOUND
+font key
+  Font Key
+foo
+  Nonsense Words
+for (loop keyword)
+  Summary of Variable Initialization and Stepping Clauses
+  Summary of Termination Test Clauses
+  Summary of Miscellaneous Clauses
+  Destructuring
+  Iteration Control
+  The for-as-arithmetic subclause
+  The for-as-in-list subclause
+  The for-as-on-list subclause
+  The for-as-equals-then subclause
+  The for-as-across subclause
+  The for-as-hash subclause
+  The for-as-package subclause
+  Initial and Final Execution
+  Macro LOOP
+for-value
+  Glossary Section ``F''
+FORCE-OUTPUT
+  Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT
+form
+  Glossary Section ``F''
+formal argument
+  Glossary Section ``F''
+formal parameter
+  Glossary Section ``F''
+format
+  Glossary Section ``F''
+FORMAT
+  Function FORMAT
+format argument
+  Glossary Section ``F''
+format control
+  Glossary Section ``F''
+format directive
+  Glossary Section ``F''
+format string
+  Glossary Section ``F''
+:format-arguments
+  Condition Type SIMPLE-CONDITION
+FORMATTER
+  Macro FORMATTER
+FOURTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+free declaration
+  Declaration Scope
+  Glossary Section ``F''
+fresh
+  Glossary Section ``F''
+FRESH-LINE
+  Function TERPRI, FRESH-LINE
+freshline
+  Glossary Section ``F''
+from (loop keyword)
+  Parsing Loop Clauses
+  The for-as-arithmetic subclause
+  Macro LOOP
+:from-end
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+FROUND
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+FTRUNCATE
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+FTYPE
+  Declaration FTYPE
+funbound
+  Glossary Section ``F''
+FUNCALL
+  Function FUNCALL
+FUNCTION
+  System Class FUNCTION
+  Special Operator FUNCTION
+function
+  Sharpsign Single-Quote
+  Glossary Section ``F''
+function block name
+  Glossary Section ``F''
+function cell
+  Glossary Section ``F''
+function designator
+  Glossary Section ``F''
+function form
+  Glossary Section ``F''
+function name
+  Glossary Section ``F''
+FUNCTION-KEYWORDS
+  Standard Generic Function FUNCTION-KEYWORDS
+FUNCTION-LAMBDA-EXPRESSION
+  Function FUNCTION-LAMBDA-EXPRESSION
+functional evaluation
+  Glossary Section ``F''
+functional value
+  Glossary Section ``F''
+FUNCTIONP
+  Function FUNCTIONP
+further compilation
+  Glossary Section ``F''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_G.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_G.htm new file mode 100644 index 00000000..d77f4194 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_G.htm @@ -0,0 +1,114 @@ + + + +CLHS: Index - G + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - G

    + +
    +G (format directive)
+  Tilde G: General Floating-Point
+GCD
+  Function GCD
+general
+  Glossary Section ``G''
+generalized boolean
+  Glossary Section ``G''
+generalized instance
+  Glossary Section ``G''
+generalized reference
+  Glossary Section ``G''
+generalized synonym stream
+  Glossary Section ``G''
+generic function
+  Glossary Section ``G''
+generic function lambda list
+  Glossary Section ``G''
+GENERIC-FUNCTION
+  System Class GENERIC-FUNCTION
+:generic-function
+  Macro DEFINE-METHOD-COMBINATION
+:generic-function-class
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+gensym
+  Glossary Section ``G''
+GENSYM
+  Function GENSYM
+:gensym
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+*GENSYM-COUNTER*
+  Variable *GENSYM-COUNTER*
+GENTEMP
+  Function GENTEMP
+GET
+  Accessor GET
+GET-DECODED-TIME
+  Function GET-UNIVERSAL-TIME, GET-DECODED-TIME
+GET-DISPATCH-MACRO-CHARACTER
+  Function SET-DISPATCH-MACRO-CHARACTER, GET-DISPATCH-MACRO-CHARACTER
+GET-INTERNAL-REAL-TIME
+  Function GET-INTERNAL-REAL-TIME
+GET-INTERNAL-RUN-TIME
+  Function GET-INTERNAL-RUN-TIME
+GET-MACRO-CHARACTER
+  Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER
+GET-OUTPUT-STREAM-STRING
+  Function GET-OUTPUT-STREAM-STRING
+GET-PROPERTIES
+  Function GET-PROPERTIES
+GET-SETF-EXPANSION
+  Function GET-SETF-EXPANSION
+GET-UNIVERSAL-TIME
+  Function GET-UNIVERSAL-TIME, GET-DECODED-TIME
+GETF
+  Accessor GETF
+GETHASH
+  Accessor GETHASH
+global declaration
+  Declarations
+  Glossary Section ``G''
+global environment
+  Glossary Section ``G''
+global variable
+  Glossary Section ``G''
+glyph
+  Glossary Section ``G''
+go
+  Glossary Section ``G''
+GO
+  Special Operator GO
+go point
+  Glossary Section ``G''
+go tag
+  Glossary Section ``G''
+graphic
+  Glossary Section ``G''
+GRAPHIC-CHAR-P
+  Function GRAPHIC-CHAR-P
+Greater-Than-Sign (format directive)
+  Tilde Greater-Than-Sign: End of Justification
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_H.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_H.htm new file mode 100644 index 00000000..9f5e26a8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_H.htm @@ -0,0 +1,74 @@ + + + +CLHS: Index - H + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - H

    + +
    +handle
+  Glossary Section ``H''
+handler
+  Glossary Section ``H''
+HANDLER-BIND
+  Macro HANDLER-BIND
+HANDLER-CASE
+  Macro HANDLER-CASE
+hash table
+  Glossary Section ``H''
+hash-key (loop keyword)
+  The for-as-hash subclause
+  Macro LOOP
+hash-keys (loop keyword)
+  The for-as-hash subclause
+  Macro LOOP
+HASH-TABLE
+  System Class HASH-TABLE
+HASH-TABLE-COUNT
+  Function HASH-TABLE-COUNT
+HASH-TABLE-P
+  Function HASH-TABLE-P
+HASH-TABLE-REHASH-SIZE
+  Function HASH-TABLE-REHASH-SIZE
+HASH-TABLE-REHASH-THRESHOLD
+  Function HASH-TABLE-REHASH-THRESHOLD
+HASH-TABLE-SIZE
+  Function HASH-TABLE-SIZE
+HASH-TABLE-TEST
+  Function HASH-TABLE-TEST
+hash-value (loop keyword)
+  The for-as-hash subclause
+  Macro LOOP
+hash-values (loop keyword)
+  The for-as-hash subclause
+  Macro LOOP
+home package
+  Glossary Section ``H''
+:host
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+HOST-NAMESTRING
+  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_I.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_I.htm new file mode 100644 index 00000000..0948bebf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_I.htm @@ -0,0 +1,298 @@ + + + +CLHS: Index - I + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - I

    + +
    +I (format directive)
+  Tilde I: Indent
+I/O customization variable
+  Glossary Section ``I''
+identical
+  Glossary Section ``I''
+identifier
+  Glossary Section ``I''
+IDENTITY
+  Function IDENTITY
+:identity
+  Macro PRINT-UNREADABLE-OBJECT
+:identity-with-one-argument
+  Macro DEFINE-METHOD-COMBINATION
+:ieee-floating-point
+  Variable *FEATURES*
+IF
+  Special Operator IF
+if (loop keyword)
+  Summary of Conditional Execution Clauses
+  Conditional Execution Clauses
+  Macro LOOP
+:if-does-not-exist
+  Function OPEN
+  Function LOAD
+:if-exists
+  Function OPEN
+IGNORABLE
+  Declaration IGNORE, IGNORABLE
+IGNORE
+  Declaration IGNORE, IGNORABLE
+IGNORE-ERRORS
+  Macro IGNORE-ERRORS
+IMAGPART
+  Function REALPART, IMAGPART
+immutable
+  Glossary Section ``I''
+implementation
+  Glossary Section ``I''
+implementation limit
+  Glossary Section ``I''
+implementation-defined
+  Glossary Section ``I''
+implementation-dependent
+  Glossary Section ``I''
+implementation-independent
+  Glossary Section ``I''
+implicit block
+  Glossary Section ``I''
+implicit compilation
+  Glossary Section ``I''
+implicit progn
+  Glossary Section ``I''
+implicit tagbody
+  Glossary Section ``I''
+import
+  Glossary Section ``I''
+IMPORT
+  Function IMPORT
+:import-from
+  Macro DEFPACKAGE
+improper list
+  Glossary Section ``I''
+in (loop keyword)
+  The for-as-in-list subclause
+  The for-as-hash subclause
+  The for-as-package subclause
+  Macro LOOP
+IN-PACKAGE
+  Macro IN-PACKAGE
+inaccessible
+  Glossary Section ``I''
+INCF
+  Macro INCF, DECF
+:include
+  Type Relationships
+  Integrating Types and Classes
+  Macro DEFSTRUCT
+indefinite extent
+  Glossary Section ``I''
+indefinite scope
+  Glossary Section ``I''
+:index
+  Macro WITH-INPUT-FROM-STRING
+indicator
+  Glossary Section ``I''
+indirect instance
+  Glossary Section ``I''
+inherit
+  Glossary Section ``I''
+:inherited
+  Function FIND-SYMBOL
+  Macro WITH-PACKAGE-ITERATOR
+  Function INTERN
+:initarg
+  Object Creation and Initialization
+  Declaring the Validity of Initialization Arguments
+  Rules for Initialization Arguments
+  Definitions of Make-Instance and Initialize-Instance
+  Inheritance of Slots and Slot Options
+  Standard Generic Function REINITIALIZE-INSTANCE
+  Standard Generic Function SHARED-INITIALIZE
+  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
+  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+:init-form
+  Macro DEFCLASS
+:initform
+  Object Creation and Initialization
+  Initialization Arguments
+  Defaulting of Initialization Arguments
+  Rules for Initialization Arguments
+  Shared-Initialize
+  Initialize-Instance
+  Definitions of Make-Instance and Initialize-Instance
+  Reinitializing an Instance
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Standard Generic Function SHARED-INITIALIZE
+  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
+  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+  Standard Generic Function SLOT-UNBOUND
+  Macro DEFCLASS
+  Standard Generic Function INITIALIZE-INSTANCE
+  Macro DEFINE-CONDITION
+  Glossary Section ``I''
+initial pprint dispatch table
+  Glossary Section ``I''
+initial readtable
+  Glossary Section ``I''
+:initial-contents
+  Sharpsign A
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Printing Other Arrays
+:initial-element
+  Function MAKE-LIST
+  Function MAKE-ARRAY
+  Function ADJUST-ARRAY
+  Function MAKE-STRING
+  Function MAKE-SEQUENCE
+initialization argument list
+  Glossary Section ``I''
+initialization form
+  Glossary Section ``I''
+INITIALIZE-INSTANCE
+  Standard Generic Function INITIALIZE-INSTANCE
+initially (loop keyword)
+  Parsing Loop Clauses
+  Expanding Loop Forms
+  Summary of Miscellaneous Clauses
+  Order of Execution
+  Iteration Control
+  Initial and Final Execution
+  Macro LOOP
+:initial-offset
+  Macro DEFSTRUCT
+:initial-value
+  Function REDUCE
+INLINE
+  Declaration INLINE, NOTINLINE
+input
+  Glossary Section ``I''
+:input
+  Function OPEN
+INPUT-STREAM-P
+  Function INPUT-STREAM-P, OUTPUT-STREAM-P
+INSPECT
+  Function INSPECT
+:installed
+  Glossary Section ``V''
+instance
+  Introduction to Classes
+  Glossary Section ``I''
+:instance
+  Introduction to Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+int-char
+  Removed Operators
+integer
+  Glossary Section ``I''
+INTEGER
+  System Class INTEGER
+INTEGER-DECODE-FLOAT
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+INTEGER-LENGTH
+  Function INTEGER-LENGTH
+INTEGERP
+  Function INTEGERP
+:interactive
+  Interactive Use of Restarts
+  Function INVOKE-RESTART-INTERACTIVELY
+  Macro RESTART-CASE
+interactive stream
+  Glossary Section ``I''
+INTERACTIVE-STREAM-P
+  Function INTERACTIVE-STREAM-P
+:interactive-function
+  Interactive Use of Restarts
+  Function INVOKE-RESTART-INTERACTIVELY
+  Macro RESTART-BIND
+intern
+  Glossary Section ``I''
+INTERN
+  Function INTERN
+:intern
+  Macro DEFPACKAGE
+:internal
+  Function FIND-SYMBOL
+  Macro WITH-PACKAGE-ITERATOR
+  Function INTERN
+internal symbol
+  Internal and External Symbols
+  Glossary Section ``I''
+internal time
+  Internal Time
+  Glossary Section ``I''
+internal time unit
+  Glossary Section ``I''
+INTERNAL-TIME-UNITS-PER-SECOND
+  Constant Variable INTERNAL-TIME-UNITS-PER-SECOND
+interned
+  Glossary Section ``I''
+interpreted function
+  Glossary Section ``I''
+interpreted implementation
+  Glossary Section ``I''
+INTERSECTION
+  Function INTERSECTION, NINTERSECTION
+interval designator
+  Glossary Section ``I''
+into (loop keyword)
+  Local Variable Initializations
+  Value Accumulation Clauses
+  Termination Test Clauses
+  Macro LOOP
+invalid
+  Glossary Section ``I''
+INVALID-METHOD-ERROR
+  Function INVALID-METHOD-ERROR
+:invert
+  Effect of Readtable Case on the Lisp Printer
+  Effect of Readtable Case on the Lisp Reader
+  Glossary Section ``C''
+INVOKE-DEBUGGER
+  Function INVOKE-DEBUGGER
+INVOKE-RESTART
+  Function INVOKE-RESTART
+INVOKE-RESTART-INTERACTIVELY
+  Function INVOKE-RESTART-INTERACTIVELY
+:io
+  Function OPEN
+is signaled
+  Error Terminology
+ISQRT
+  Function SQRT, ISQRT
+it (loop keyword)
+  Conditional Execution Clauses
+  Notes about Loop
+  Macro LOOP
+iteration form
+  Glossary Section ``I''
+iteration variable
+  Glossary Section ``I''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_J.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_J.htm new file mode 100644 index 00000000..06772432 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_J.htm @@ -0,0 +1,34 @@ + + + +CLHS: Index - J + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - J

    + +
    +:junk-allowed
+  Function PARSE-INTEGER
+  Function PARSE-NAMESTRING
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_K.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_K.htm new file mode 100644 index 00000000..6217eead --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_K.htm @@ -0,0 +1,88 @@ + + + +CLHS: Index - K + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - K

    + +
    +key
+  Glossary Section ``K''
+&key
+  Ordinary Lambda Lists
+  Specifiers for keyword parameters
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Too Many Arguments
+  System Class FUNCTION
+  Type Specifier VALUES
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Initialization Arguments
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Keyword Arguments in Generic Functions and Methods
+  Macro DEFINE-METHOD-COMBINATION
+:key
+  Function SUBLIS, NSUBLIS
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+  Function INTERSECTION, NINTERSECTION
+  Function ADJOIN
+  Macro PUSHNEW
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+  Function SUBSETP
+  Function UNION, NUNION
+  Satisfying a Two-Argument Test
+  Satisfying a One-Argument Test
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function SORT, STABLE-SORT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function MERGE
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+keyword
+  Glossary Section ``K''
+KEYWORD
+  Type KEYWORD
+  The KEYWORD Package
+keyword parameter
+  Glossary Section ``K''
+keyword/value pair
+  Glossary Section ``K''
+KEYWORDP
+  Function KEYWORDP
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_L.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_L.htm new file mode 100644 index 00000000..89325279 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_L.htm @@ -0,0 +1,298 @@ + + + +CLHS: Index - L + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - L

    + +
    +LABELS
+  Special Operator FLET, LABELS, MACROLET
+LAMBDA
+  Symbol LAMBDA
+  Macro LAMBDA
+lambda combination
+  Glossary Section ``L''
+lambda expression
+  Glossary Section ``L''
+lambda form
+  Glossary Section ``L''
+lambda list
+  Glossary Section ``L''
+lambda list keyword
+  Glossary Section ``L''
+lambda variable
+  Glossary Section ``L''
+LAMBDA-LIST-KEYWORDS
+  Constant Variable LAMBDA-LIST-KEYWORDS
+LAMBDA-PARAMETERS-LIMIT
+  Constant Variable LAMBDA-PARAMETERS-LIMIT
+:lambda-list
+  Function ENSURE-GENERIC-FUNCTION
+LAST
+  Function LAST
+LCM
+  Function LCM
+LDB
+  Accessor LDB
+LDB-TEST
+  Function LDB-TEST
+LDIFF
+  Function LDIFF, TAILP
+leaf
+  Glossary Section ``L''
+leap seconds
+  Glossary Section ``L''
+LEAST-NEGATIVE-DOUBLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-LONG-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-SHORT-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-NEGATIVE-SINGLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-DOUBLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-LONG-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-NORMALIZED-LONG-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-SHORT-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+LEAST-POSITIVE-SINGLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+Left-Brace (format directive)
+  Tilde Left-Brace: Iteration
+Left-Bracket (format directive)
+  Tilde Left-Bracket: Conditional Expression
+Left-Paren (format directive)
+  Tilde Left-Paren: Case Conversion
+left-parenthesis
+  Glossary Section ``L''
+Left-Parenthesis (reader macro)
+  Left-Parenthesis
+Left-Parenthesis (sharpsign reader macro)
+  Sharpsign Left-Parenthesis
+length
+  Glossary Section ``L''
+LENGTH
+  Function LENGTH
+:length
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+Less-Than-Sign (format directive)
+  Tilde Less-Than-Sign: Logical Block
+  Tilde Less-Than-Sign: Justification
+Less-Than-Sign (sharpsign reader macro)
+  Sharpsign Less-Than-Sign
+LET
+  Special Operator LET, LET*
+LET*
+  Special Operator LET, LET*
+:level
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+lexical binding
+  Glossary Section ``L''
+lexical closure
+  Glossary Section ``L''
+lexical environment
+  Glossary Section ``L''
+lexical scope
+  Glossary Section ``L''
+lexical variable
+  Glossary Section ``L''
+:line
+  Function PPRINT-TAB
+:linear
+  Function PPRINT-NEWLINE
+linear-style conditional newline
+  Examples of using the Pretty Printer
+  Function PPRINT-NEWLINE
+:line-relative
+  Function PPRINT-TAB
+:lines
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+LISP
+  Packages No Longer Required
+Lisp image
+  Glossary Section ``L''
+Lisp printer
+  Glossary Section ``L''
+Lisp read-eval-print loop
+  Glossary Section ``L''
+Lisp reader
+  Glossary Section ``L''
+LISP-IMPLEMENTATION-TYPE
+  Function LISP-IMPLEMENTATION-TYPE, LISP-IMPLEMENTATION-VERSION
+LISP-IMPLEMENTATION-VERSION
+  Function LISP-IMPLEMENTATION-TYPE, LISP-IMPLEMENTATION-VERSION
+LIST
+  System Class LIST
+  Function LIST, LIST*
+list
+  Left-Parenthesis
+  Backquote
+  Comma
+  Built-in Method Combination Types
+  Glossary Section ``L''
+list designator
+  Glossary Section ``L''
+list structure
+  Glossary Section ``L''
+LIST*
+  Function LIST, LIST*
+LIST-ALL-PACKAGES
+  Function LIST-ALL-PACKAGES
+LIST-LENGTH
+  Function LIST-LENGTH
+LISTEN
+  Function LISTEN
+LISTP
+  Function LISTP
+literal
+  Glossary Section ``L''
+LOAD
+  Function LOAD
+load
+  Special Operator EVAL-WHEN
+  Glossary Section ``L''
+load time
+  Glossary Section ``L''
+load time value
+  Glossary Section ``L''
+LOAD-LOGICAL-PATHNAME-TRANSLATIONS
+  Function LOAD-LOGICAL-PATHNAME-TRANSLATIONS
+LOAD-TIME-VALUE
+  Special Operator LOAD-TIME-VALUE
+load-time-value
+  Minimal Compilation
+loader
+  Glossary Section ``L''
+*LOAD-PATHNAME*
+  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
+*LOAD-PRINT*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+:load-toplevel
+  File Compilation
+  Processing of Top Level Forms
+  Special Operator EVAL-WHEN
+*LOAD-TRUENAME*
+  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
+*LOAD-VERBOSE*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+:local
+  Local Case in Pathname Components
+  Common Case in Pathname Components
+  Function MAKE-PATHNAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+local declaration
+  Declarations
+  Glossary Section ``L''
+local precedence order
+  Glossary Section ``L''
+local slot
+  Glossary Section ``L''
+LOCALLY
+  Special Operator LOCALLY
+LOG
+  Function LOG
+LOGAND
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGANDC1
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGANDC2
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGBITP
+  Function LOGBITP
+LOGCOUNT
+  Function LOGCOUNT
+LOGEQV
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+logical block
+  Glossary Section ``L''
+logical host
+  Glossary Section ``L''
+logical host designator
+  Glossary Section ``L''
+logical pathname
+  Glossary Section ``L''
+LOGICAL-PATHNAME
+  System Class LOGICAL-PATHNAME
+  Function LOGICAL-PATHNAME
+LOGICAL-PATHNAME-TRANSLATIONS
+  Accessor LOGICAL-PATHNAME-TRANSLATIONS
+LOGIOR
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGNAND
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGNOR
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGNOT
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGORC1
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGORC2
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+LOGTEST
+  Function LOGTEST
+LOGXOR
+  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
+long float
+  Glossary Section ``L''
+LONG-FLOAT
+  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
+LONG-FLOAT-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+LONG-FLOAT-NEGATIVE-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+LONG-SITE-NAME
+  Function SHORT-SITE-NAME, LONG-SITE-NAME
+LOOP
+  Macro LOOP
+loop keyword
+  Glossary Section ``L''
+LOOP-FINISH
+  Local Macro LOOP-FINISH
+LOWER-CASE-P
+  Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P
+lowercase
+  Glossary Section ``L''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_M.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_M.htm new file mode 100644 index 00000000..c4512427 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_M.htm @@ -0,0 +1,292 @@ + + + +CLHS: Index - M + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - M

    + +
    +MACHINE-INSTANCE
+  Function MACHINE-INSTANCE
+MACHINE-TYPE
+  Function MACHINE-TYPE
+MACHINE-VERSION
+  Function MACHINE-VERSION
+macro
+  Minimal Compilation
+  Glossary Section ``M''
+macro character
+  Glossary Section ``M''
+macro expansion
+  Glossary Section ``M''
+macro form
+  Glossary Section ``M''
+macro function
+  Glossary Section ``M''
+macro lambda list
+  Glossary Section ``M''
+macro name
+  Glossary Section ``M''
+MACRO-FUNCTION
+  Accessor MACRO-FUNCTION
+MACROEXPAND
+  Function MACROEXPAND, MACROEXPAND-1
+macroexpand hook
+  Glossary Section ``M''
+MACROEXPAND-1
+  Function MACROEXPAND, MACROEXPAND-1
+*MACROEXPAND-HOOK*
+  Variable *MACROEXPAND-HOOK*
+MACROLET
+  Special Operator FLET, LABELS, MACROLET
+macrolet
+  Minimal Compilation
+MAKE-ARRAY
+  Function MAKE-ARRAY
+MAKE-BROADCAST-STREAM
+  Function MAKE-BROADCAST-STREAM
+make-char
+  Removed Operators
+MAKE-CONCATENATED-STREAM
+  Function MAKE-CONCATENATED-STREAM
+MAKE-CONDITION
+  Function MAKE-CONDITION
+MAKE-DISPATCH-MACRO-CHARACTER
+  Function MAKE-DISPATCH-MACRO-CHARACTER
+MAKE-ECHO-STREAM
+  Function MAKE-ECHO-STREAM
+MAKE-HASH-TABLE
+  Function MAKE-HASH-TABLE
+MAKE-INSTANCE
+  Standard Generic Function MAKE-INSTANCE
+MAKE-INSTANCES-OBSOLETE
+  Standard Generic Function MAKE-INSTANCES-OBSOLETE
+MAKE-LIST
+  Function MAKE-LIST
+MAKE-LOAD-FORM
+  Standard Generic Function MAKE-LOAD-FORM
+MAKE-LOAD-FORM-SAVING-SLOTS
+  Function MAKE-LOAD-FORM-SAVING-SLOTS
+MAKE-METHOD
+  Local Macro CALL-METHOD, MAKE-METHOD
+MAKE-PACKAGE
+  Function MAKE-PACKAGE
+MAKE-PATHNAME
+  Function MAKE-PATHNAME
+MAKE-RANDOM-STATE
+  Function MAKE-RANDOM-STATE
+MAKE-SEQUENCE
+  Function MAKE-SEQUENCE
+MAKE-STRING
+  Function MAKE-STRING
+MAKE-STRING-INPUT-STREAM
+  Function MAKE-STRING-INPUT-STREAM
+MAKE-STRING-OUTPUT-STREAM
+  Function MAKE-STRING-OUTPUT-STREAM
+MAKE-SYMBOL
+  Function MAKE-SYMBOL
+MAKE-SYNONYM-STREAM
+  Function MAKE-SYNONYM-STREAM
+MAKE-TWO-WAY-STREAM
+  Function MAKE-TWO-WAY-STREAM
+MAKUNBOUND
+  Function MAKUNBOUND
+:mandatory
+  Function PPRINT-NEWLINE
+mandatory-style conditional newline
+  Function PPRINT-NEWLINE
+MAP
+  Function MAP
+MAP-INTO
+  Function MAP-INTO
+MAPC
+  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
+MAPCAN
+  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
+MAPCAR
+  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
+MAPCON
+  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
+MAPHASH
+  Function MAPHASH
+MAPL
+  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
+MAPLIST
+  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
+mapping
+  Glossary Section ``M''
+MASK-FIELD
+  Accessor MASK-FIELD
+MAX
+  Function MAX, MIN
+max
+  Built-in Method Combination Types
+maximize (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+maximizing (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+MEMBER
+  Type Specifier MEMBER
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+MEMBER-IF
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+MEMBER-IF-NOT
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+MERGE
+  Function MERGE
+MERGE-PATHNAMES
+  Function MERGE-PATHNAMES
+metaclass
+  Glossary Section ``M''
+:metaclass
+  Defining Classes
+  Macro DEFCLASS
+Metaobject Protocol
+  Glossary Section ``M''
+method
+  Glossary Section ``M''
+METHOD
+  System Class METHOD
+:method
+  Macro DEFGENERIC
+method combination
+  Glossary Section ``M''
+METHOD-COMBINATION
+  System Class METHOD-COMBINATION
+METHOD-COMBINATION-ERROR
+  Function METHOD-COMBINATION-ERROR
+method-defining form
+  Glossary Section ``M''
+method-defining operator
+  Introduction to Generic Functions
+  Glossary Section ``M''
+METHOD-QUALIFIERS
+  Standard Generic Function METHOD-QUALIFIERS
+:method-class
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+:method-combination
+  Applying method combination to the sorted list of applicable methods
+  Built-in Method Combination Types
+  Function ENSURE-GENERIC-FUNCTION
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+might signal
+  Error Terminology
+MIN
+  Function MAX, MIN
+min
+  Built-in Method Combination Types
+minimal compilation
+  Glossary Section ``M''
+minimize (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+minimizing (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+Minus (sharpsign reader macro)
+  Sharpsign Minus
+MINUSP
+  Function MINUSP, PLUSP
+:miser
+  Function PPRINT-NEWLINE
+miser-style conditional newline
+  Examples of using the Pretty Printer
+  Function PPRINT-NEWLINE
+:miser-width
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+MISMATCH
+  Function MISMATCH
+MOD
+  Type Specifier MOD
+  Function MOD, REM
+modified lambda list
+  Glossary Section ``M''
+*MODULES*
+  Variable *MODULES*
+most recent
+  Glossary Section ``M''
+MOST-NEGATIVE-DOUBLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-NEGATIVE-FIXNUM
+  Constant Variable MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM
+MOST-NEGATIVE-LONG-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-NEGATIVE-SHORT-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-NEGATIVE-SINGLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-POSITIVE-DOUBLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-POSITIVE-FIXNUM
+  Constant Variable MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM
+MOST-POSITIVE-LONG-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-POSITIVE-SHORT-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+MOST-POSITIVE-SINGLE-FLOAT
+  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
+:most-specific-first
+  Built-in Method Combination Types
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+:most-specific-last
+  Built-in Method Combination Types
+  Macro DEFGENERIC
+  Macro DEFINE-METHOD-COMBINATION
+muffle-warning
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+MUFFLE-WARNING
+  Restart MUFFLE-WARNING
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+multiple escape
+  Glossary Section ``M''
+multiple values
+  Glossary Section ``M''
+MULTIPLE-VALUE-BIND
+  Macro MULTIPLE-VALUE-BIND
+MULTIPLE-VALUE-CALL
+  Special Operator MULTIPLE-VALUE-CALL
+MULTIPLE-VALUE-LIST
+  Macro MULTIPLE-VALUE-LIST
+MULTIPLE-VALUE-PROG1
+  Special Operator MULTIPLE-VALUE-PROG1
+MULTIPLE-VALUE-SETQ
+  Macro MULTIPLE-VALUE-SETQ
+MULTIPLE-VALUES-LIMIT
+  Constant Variable MULTIPLE-VALUES-LIMIT
+must signal
+  Error Terminology
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_N.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_N.htm new file mode 100644 index 00000000..8c604523 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_N.htm @@ -0,0 +1,214 @@ + + + +CLHS: Index - N + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - N

    + +
    +name
+  Glossary Section ``N''
+:name
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+NAME-CHAR
+  Function NAME-CHAR
+:named
+  Macro DEFSTRUCT
+named (loop keyword)
+  Expanding Loop Forms
+  Summary of Unconditional Execution Clauses
+  Summary of Miscellaneous Clauses
+  Iteration Control
+  Unconditional Execution Clauses
+  Control Transfer Clauses
+  Initial and Final Execution
+  Macro LOOP
+named constant
+  Glossary Section ``N''
+namespace
+  Introduction to Environments
+  Glossary Section ``N''
+namestring
+  Glossary Section ``N''
+NAMESTRING
+  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
+NBUTLAST
+  Function BUTLAST, NBUTLAST
+NCONC
+  Function NCONC
+nconc
+  Built-in Method Combination Types
+nconc (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+nconcing (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+never (loop keyword)
+  Summary of Termination Test Clauses
+  Termination Test Clauses
+  Initial and Final Execution
+  Macro LOOP
+:newest
+  Pathnames as Filenames
+  The Pathname Version Component
+  Restrictions on Examining a Pathname Version Component
+  Restrictions on Constructing Pathnames
+  Function MERGE-PATHNAMES
+  Examples of Truenames
+  Function OPEN
+  Glossary Section ``V''
+newline
+  Glossary Section ``N''
+Newline (format directive)
+  Tilde Newline: Ignored Newline
+:new-version
+  Function OPEN
+next method
+  Glossary Section ``N''
+NEXT-METHOD-P
+  Local Function NEXT-METHOD-P
+nickname
+  Glossary Section ``N''
+:nicknames
+  Function MAKE-PACKAGE
+  Macro DEFPACKAGE
+NIL
+  Type NIL
+  Constant Variable NIL
+nil
+  NIL
+  Glossary Section ``N''
+NINTERSECTION
+  Function INTERSECTION, NINTERSECTION
+NINTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+NO-APPLICABLE-METHOD
+  Standard Generic Function NO-APPLICABLE-METHOD
+NO-NEXT-METHOD
+  Standard Generic Function NO-NEXT-METHOD
+:no-error
+  Macro HANDLER-CASE
+non-atomic
+  Glossary Section ``N''
+non-constant variable
+  Glossary Section ``N''
+non-correctable
+  Glossary Section ``N''
+non-empty
+  Glossary Section ``N''
+non-generic function
+  Glossary Section ``N''
+non-graphic
+  Glossary Section ``N''
+non-list
+  Glossary Section ``N''
+non-local exit
+  Glossary Section ``N''
+non-nil
+  Glossary Section ``N''
+non-null lexical environment
+  Glossary Section ``N''
+non-simple
+  Glossary Section ``N''
+non-terminating
+  Glossary Section ``N''
+non-top-level form
+  Glossary Section ``N''
+normal return
+  Glossary Section ``N''
+normalized
+  Glossary Section ``N''
+NOT
+  Type Specifier NOT
+  Function NOT
+NOTANY
+  Function EVERY, SOME, NOTEVERY, NOTANY
+notation
+  Notational Conventions
+NOTEVERY
+  Function EVERY, SOME, NOTEVERY, NOTANY
+NOTINLINE
+  Declaration INLINE, NOTINLINE
+notinline
+  Minimal Declaration Processing Requirements
+NRECONC
+  Function REVAPPEND, NRECONC
+NREVERSE
+  Function REVERSE, NREVERSE
+NSET-DIFFERENCE
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+NSET-EXCLUSIVE-OR
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+NSTRING-CAPITALIZE
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+NSTRING-DOWNCASE
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+NSTRING-UPCASE
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+NSUBLIS
+  Function SUBLIS, NSUBLIS
+NSUBST
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+NSUBST-IF
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+NSUBST-IF-NOT
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+NSUBSTITUTE
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+NSUBSTITUTE-IF
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+NSUBSTITUTE-IF-NOT
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+NTH
+  Accessor NTH
+NTH-VALUE
+  Macro NTH-VALUE
+NTHCDR
+  Function NTHCDR
+null
+  Glossary Section ``N''
+NULL
+  System Class NULL
+  Function NULL
+null lexical environment
+  Glossary Section ``N''
+number
+  Glossary Section ``N''
+NUMBER
+  System Class NUMBER
+NUMBERP
+  Function NUMBERP
+NUMERATOR
+  Function NUMERATOR, DENOMINATOR
+numeric
+  Glossary Section ``N''
+NUNION
+  Function UNION, NUNION
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_O.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_O.htm new file mode 100644 index 00000000..b5d996f4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_O.htm @@ -0,0 +1,131 @@ + + + +CLHS: Index - O + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - O

    + +
    +O (format directive)
+  Tilde O: Octal
+O (sharpsign reader macro)
+  Sharpsign O
+object
+  Glossary Section ``O''
+object-traversing
+  Glossary Section ``O''
+ODDP
+  Function EVENP, ODDP
+of (loop keyword)
+  The for-as-hash subclause
+  The for-as-package subclause
+  Macro LOOP
+of-type (loop keyword)
+  Destructuring
+  Macro LOOP
+:off
+  Notes about The KEYWORD Package
+:oldest
+  Notes about the Pathname Version Component
+  Glossary Section ``V''
+:on
+  Notes about The KEYWORD Package
+on (loop keyword)
+  The for-as-on-list subclause
+  Macro LOOP
+open
+  Glossary Section ``O''
+OPEN
+  Function OPEN
+OPEN-STREAM-P
+  Function OPEN-STREAM-P
+:operands
+  Condition Type ARITHMETIC-ERROR
+operator
+  Glossary Section ``O''
+:operator
+  Macro DEFINE-METHOD-COMBINATION
+OPTIMIZE
+  Declaration OPTIMIZE
+optimize quality
+  Glossary Section ``O''
+&optional
+  Ordinary Lambda Lists
+  Specifiers for optional parameters
+  Specifiers for keyword parameters
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-modify-macro Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  System Class FUNCTION
+  Type Specifier VALUES
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Macro SETF, PSETF
+optional parameter
+  Glossary Section ``O''
+or
+  Built-in Method Combination Types
+OR
+  Type Specifier OR
+  Macro OR
+:order
+  Macro DEFINE-METHOD-COMBINATION
+order of evaluation
+  Special Operator LOAD-TIME-VALUE
+  Evaluation of Subforms to Places
+  Special Operator CATCH
+  Macro MULTIPLE-VALUE-SETQ
+  Order of Execution
+  The for-as-arithmetic subclause
+  Defaulting of Initialization Arguments
+  Macro ASSERT
+  Accessor LDB
+ordinary function
+  Glossary Section ``O''
+ordinary lambda list
+  Glossary Section ``O''
+otherwise
+  Macro CASE, CCASE, ECASE
+  Macro TYPECASE, CTYPECASE, ETYPECASE
+otherwise inaccessible part
+  Glossary Section ``O''
+output
+  Glossary Section ``O''
+:output
+  Function OPEN
+OUTPUT-STREAM-P
+  Function INPUT-STREAM-P, OUTPUT-STREAM-P
+:output-file
+  Function COMPILE-FILE
+  Function COMPILE-FILE-PATHNAME
+:override
+  Macro WITH-COMPILATION-UNIT
+:overwrite
+  Function OPEN
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_P.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_P.htm new file mode 100644 index 00000000..cfeb8363 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_P.htm @@ -0,0 +1,354 @@ + + + +CLHS: Index - P + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - P

    + +
    +P (format directive)
+  Tilde P: Plural
+P (sharpsign reader macro)
+  Sharpsign P
+package
+  Glossary Section ``P''
+PACKAGE
+  System Class PACKAGE
+*PACKAGE*
+  Variable *PACKAGE*
+package cell
+  Glossary Section ``P''
+package designator
+  Glossary Section ``P''
+package marker
+  Glossary Section ``P''
+package prefix
+  Glossary Section ``P''
+package registry
+  Glossary Section ``P''
+PACKAGE-ERROR
+  Condition Type PACKAGE-ERROR
+PACKAGE-ERROR-PACKAGE
+  Function PACKAGE-ERROR-PACKAGE
+PACKAGE-NAME
+  Function PACKAGE-NAME
+PACKAGE-NICKNAMES
+  Function PACKAGE-NICKNAMES
+PACKAGE-SHADOWING-SYMBOLS
+  Function PACKAGE-SHADOWING-SYMBOLS
+PACKAGE-USE-LIST
+  Function PACKAGE-USE-LIST
+PACKAGE-USED-BY-LIST
+  Function PACKAGE-USED-BY-LIST
+PACKAGEP
+  Function PACKAGEP
+PAIRLIS
+  Function PAIRLIS
+pairwise
+  Glossary Section ``P''
+parallel
+  Glossary Section ``P''
+parameter
+  Glossary Section ``P''
+parameter specializer
+  Glossary Section ``P''
+parameter specializer name
+  Glossary Section ``P''
+PARSE-ERROR
+  Condition Type PARSE-ERROR
+PARSE-INTEGER
+  Function PARSE-INTEGER
+PARSE-NAMESTRING
+  Function PARSE-NAMESTRING
+PATHNAME
+  System Class PATHNAME
+  Function PATHNAME
+pathname
+  Sharpsign P
+  Pathnames as Filenames
+  Glossary Section ``P''
+pathname designator
+  Glossary Section ``P''
+PATHNAME-DEVICE
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+PATHNAME-DIRECTORY
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+PATHNAME-HOST
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+PATHNAME-MATCH-P
+  Function PATHNAME-MATCH-P
+PATHNAME-NAME
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+PATHNAME-TYPE
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+PATHNAME-VERSION
+  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
+PATHNAMEP
+  Function PATHNAMEP
+PEEK-CHAR
+  Function PEEK-CHAR
+Percent (format directive)
+  Tilde Percent: Newline
+:per-line-prefix
+  Tilde Less-Than-Sign: Logical Block
+  Macro PPRINT-LOGICAL-BLOCK
+PHASE
+  Function PHASE
+physical pathname
+  Glossary Section ``P''
+PI
+  Constant Variable PI
+:pixel-size
+  Examples of Keyword Arguments in Generic Functions and Methods
+place
+  Glossary Section ``P''
+plist
+  Glossary Section ``P''
+Plus (sharpsign reader macro)
+  Sharpsign Plus
+PLUSP
+  Function MINUSP, PLUSP
+POP
+  Macro POP
+portable
+  Glossary Section ``P''
+POSITION
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+POSITION-IF
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+POSITION-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+potential copy
+  Glossary Section ``P''
+potential number
+  Glossary Section ``P''
+PPRINT
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+pprint dispatch table
+  Glossary Section ``P''
+PPRINT-DISPATCH
+  Function PPRINT-DISPATCH
+PPRINT-EXIT-IF-LIST-EXHAUSTED
+  Local Macro PPRINT-EXIT-IF-LIST-EXHAUSTED
+PPRINT-FILL
+  Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR
+PPRINT-INDENT
+  Function PPRINT-INDENT
+PPRINT-LINEAR
+  Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR
+PPRINT-LOGICAL-BLOCK
+  Macro PPRINT-LOGICAL-BLOCK
+PPRINT-NEWLINE
+  Function PPRINT-NEWLINE
+PPRINT-POP
+  Local Macro PPRINT-POP
+PPRINT-TAB
+  Function PPRINT-TAB
+PPRINT-TABULAR
+  Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR
+:pprint-dispatch
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+predicate
+  Glossary Section ``P''
+:predicate
+  Macro DEFSTRUCT
+:prefix
+  Tilde Less-Than-Sign: Logical Block
+  Macro PPRINT-LOGICAL-BLOCK
+:pre-line-prefix
+  Macro PPRINT-LOGICAL-BLOCK
+prepared to signal
+  Error Terminology
+present
+  Glossary Section ``P''
+present-symbol (loop keyword)
+  The for-as-package subclause
+  Macro LOOP
+present-symbols (loop keyword)
+  The for-as-package subclause
+  Macro LOOP
+:preserve
+  Effect of Readtable Case on the Lisp Printer
+  Effect of Readtable Case on the Lisp Reader
+  Glossary Section ``C''
+:preserve-whitespace
+  Function READ-FROM-STRING
+:pretty
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+pretty print
+  Glossary Section ``P''
+pretty printer
+  Glossary Section ``P''
+pretty printing stream
+  Glossary Section ``P''
+:previous
+  Glossary Section ``V''
+primary method
+  Glossary Section ``P''
+primary value
+  Glossary Section ``P''
+PRIN1
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+PRIN1-TO-STRING
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+PRINC
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+PRINC-TO-STRING
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+principal
+  Glossary Section ``P''
+PRINT
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+:print
+  Function COMPILE-FILE
+  Function LOAD
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+print name
+  Glossary Section ``P''
+PRINT-NOT-READABLE
+  Condition Type PRINT-NOT-READABLE
+PRINT-NOT-READABLE-OBJECT
+  Function PRINT-NOT-READABLE-OBJECT
+PRINT-OBJECT
+  Standard Generic Function PRINT-OBJECT
+PRINT-UNREADABLE-OBJECT
+  Macro PRINT-UNREADABLE-OBJECT
+*PRINT-ARRAY*
+  Variable *PRINT-ARRAY*
+*PRINT-BASE*
+  Variable *PRINT-BASE*, *PRINT-RADIX*
+*PRINT-CASE*
+  Variable *PRINT-CASE*
+*PRINT-CIRCLE*
+  Variable *PRINT-CIRCLE*
+*print-circle*
+  Sharpsign Equal-Sign
+  Sharpsign Sharpsign
+printer control variable
+  Multiple Possible Textual Representations
+  Glossary Section ``P''
+printer escaping
+  Glossary Section ``P''
+*PRINT-ESCAPE*
+  Variable *PRINT-ESCAPE*
+:print-function
+  Macro DEFSTRUCT
+  Printing Structures
+*PRINT-GENSYM*
+  Variable *PRINT-GENSYM*
+printing
+  Glossary Section ``P''
+*PRINT-LENGTH*
+  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
+*PRINT-LEVEL*
+  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
+*PRINT-LINES*
+  Variable *PRINT-LINES*
+*PRINT-MISER-WIDTH*
+  Variable *PRINT-MISER-WIDTH*
+:print-object
+  Macro DEFSTRUCT
+  Printing Structures
+*PRINT-PPRINT-DISPATCH*
+  Variable *PRINT-PPRINT-DISPATCH*
+*PRINT-PRETTY*
+  Variable *PRINT-PRETTY*
+*PRINT-RADIX*
+  Variable *PRINT-BASE*, *PRINT-RADIX*
+*PRINT-READABLY*
+  Variable *PRINT-READABLY*
+*PRINT-RIGHT-MARGIN*
+  Variable *PRINT-RIGHT-MARGIN*
+:probe
+  Function OPEN
+PROBE-FILE
+  Function PROBE-FILE
+process
+  Glossary Section ``P''
+processor
+  Glossary Section ``P''
+proclaim
+  Glossary Section ``P''
+PROCLAIM
+  Function PROCLAIM
+proclamation
+  Declarations
+  Glossary Section ``P''
+PROG
+  Macro PROG, PROG*
+prog tag
+  Glossary Section ``P''
+PROG*
+  Macro PROG, PROG*
+PROG1
+  Macro PROG1, PROG2
+PROG2
+  Macro PROG1, PROG2
+progn
+  Built-in Method Combination Types
+PROGN
+  Special Operator PROGN
+program
+  Glossary Section ``P''
+PROGRAM-ERROR
+  Condition Type PROGRAM-ERROR
+programmer
+  Glossary Section ``P''
+programmer code
+  Glossary Section ``P''
+PROGV
+  Special Operator PROGV
+proper list
+  Glossary Section ``P''
+proper name
+  Glossary Section ``P''
+proper sequence
+  Glossary Section ``P''
+proper subtype
+  Glossary Section ``P''
+property
+  Glossary Section ``P''
+property indicator
+  Glossary Section ``P''
+property list
+  Glossary Section ``P''
+property value
+  Glossary Section ``P''
+PROVIDE
+  Function PROVIDE, REQUIRE
+PSETF
+  Macro SETF, PSETF
+PSETQ
+  Macro PSETQ
+purports to conform
+  Glossary Section ``P''
+PUSH
+  Macro PUSH
+PUSHNEW
+  Macro PUSHNEW
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Q.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Q.htm new file mode 100644 index 00000000..86348ae7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Q.htm @@ -0,0 +1,57 @@ + + + +CLHS: Index - Q + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - Q

    + +
    +qualified method
+  Glossary Section ``Q''
+qualifier
+  Glossary Section ``Q''
+query I/O
+  Glossary Section ``Q''
+*QUERY-IO*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+Question-Mark (format directive)
+  Tilde Question-Mark: Recursive Processing
+quotation (of forms)
+  Single-Quote
+  Backquote
+  Comma
+quotation (of strings)
+  Double-Quote
+QUOTE
+  Special Operator QUOTE
+quote
+  Single-Quote
+  Backquote
+  Comma
+quoted object
+  Glossary Section ``Q''
+quux
+  Nonsense Words
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_R.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_R.htm new file mode 100644 index 00000000..2885312a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_R.htm @@ -0,0 +1,324 @@ + + + +CLHS: Index - R + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - R

    + +
    +R (format directive)
+  Tilde R: Radix
+R (sharpsign reader macro)
+  Sharpsign R
+radix
+  Glossary Section ``R''
+:radix
+  Function PARSE-INTEGER
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+RANDOM
+  Function RANDOM
+random state
+  Glossary Section ``R''
+RANDOM-STATE
+  System Class RANDOM-STATE
+RANDOM-STATE-P
+  Function RANDOM-STATE-P
+*RANDOM-STATE*
+  Variable *RANDOM-STATE*
+rank
+  Glossary Section ``R''
+RASSOC
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+RASSOC-IF
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+RASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+ratio
+  Printing Ratios
+  Glossary Section ``R''
+RATIO
+  System Class RATIO
+ratio marker
+  Glossary Section ``R''
+rational
+  Glossary Section ``R''
+RATIONAL
+  System Class RATIONAL
+  Function RATIONAL, RATIONALIZE
+RATIONALIZE
+  Function RATIONAL, RATIONALIZE
+RATIONALP
+  Function RATIONALP
+read
+  Glossary Section ``R''
+READ
+  Function READ, READ-PRESERVING-WHITESPACE
+READ-BYTE
+  Function READ-BYTE
+READ-CHAR
+  Function READ-CHAR
+READ-CHAR-NO-HANG
+  Function READ-CHAR-NO-HANG
+READ-DELIMITED-LIST
+  Function READ-DELIMITED-LIST
+READ-FROM-STRING
+  Function READ-FROM-STRING
+READ-LINE
+  Function READ-LINE
+READ-PRESERVING-WHITESPACE
+  Function READ, READ-PRESERVING-WHITESPACE
+READ-SEQUENCE
+  Function READ-SEQUENCE
+readably
+  Glossary Section ``R''
+:readably
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+*READ-BASE*
+  Variable *READ-BASE*
+*read-base*
+  Sharpsign B
+  Sharpsign O
+  Sharpsign X
+  Sharpsign R
+*READ-DEFAULT-FLOAT-FORMAT*
+  Variable *READ-DEFAULT-FLOAT-FORMAT*
+reader
+  Glossary Section ``R''
+:reader
+  Redefining Classes
+  Accessing Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+reader macro
+  Glossary Section ``R''
+reader macro function
+  Glossary Section ``R''
+READER-ERROR
+  Condition Type READER-ERROR
+*READ-EVAL*
+  Variable *READ-EVAL*
+*read-eval*
+  Sharpsign Dot
+:read-only
+  Macro DEFSTRUCT
+*READ-SUPPRESS*
+  Variable *READ-SUPPRESS*
+readtable
+  Glossary Section ``R''
+READTABLE
+  System Class READTABLE
+*READTABLE*
+  Variable *READTABLE*
+readtable case
+  Glossary Section ``R''
+readtable designator
+  Glossary Section ``R''
+READTABLE-CASE
+  Accessor READTABLE-CASE
+READTABLEP
+  Function READTABLEP
+REAL
+  System Class REAL
+REALP
+  Function REALP
+REALPART
+  Function REALPART, IMAGPART
+recognizable subtype
+  Glossary Section ``R''
+redefinition
+  Constraints on the COMMON-LISP Package for Conforming Programs
+REDUCE
+  Function REDUCE
+reference
+  Glossary Section ``R''
+registered package
+  Glossary Section ``R''
+:rehash-size
+  Function MAKE-HASH-TABLE
+:rehash-threshold
+  Function MAKE-HASH-TABLE
+REINITIALIZE-INSTANCE
+  Standard Generic Function REINITIALIZE-INSTANCE
+relative
+  Glossary Section ``R''
+:relative
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+  Function MERGE-PATHNAMES
+REM
+  Function MOD, REM
+REMF
+  Macro REMF
+REMHASH
+  Function REMHASH
+REMOVE
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+REMOVE-DUPLICATES
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+REMOVE-IF
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+REMOVE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+REMOVE-METHOD
+  Standard Generic Function REMOVE-METHOD
+REMPROP
+  Function REMPROP
+:rename
+  Function OPEN
+RENAME-FILE
+  Function RENAME-FILE
+RENAME-PACKAGE
+  Function RENAME-PACKAGE
+:rename-and-delete
+  Function OPEN
+repeat (loop keyword)
+  Summary of Termination Test Clauses
+  Iteration Control
+  Termination Test Clauses
+  Notes about Loop
+  Macro LOOP
+repertoire
+  Glossary Section ``R''
+REPLACE
+  Function REPLACE
+report
+  Glossary Section ``R''
+:report
+  Printing Conditions
+  Interactive Use of Restarts
+  Condition Type CONDITION
+  Macro DEFINE-CONDITION
+  Macro RESTART-CASE
+report message
+  Glossary Section ``R''
+:report-function
+  Interactive Use of Restarts
+  Macro RESTART-BIND
+REQUIRE
+  Function PROVIDE, REQUIRE
+:required
+  Macro DEFINE-METHOD-COMBINATION
+required parameter
+  Glossary Section ``R''
+REST
+  Accessor REST
+&rest
+  Ordinary Lambda Lists
+  A specifier for a rest parameter
+  Specifiers for keyword parameters
+  Generic Function Lambda Lists
+  Specialized Lambda Lists
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Boa Lambda Lists
+  Defsetf Lambda Lists
+  Define-modify-macro Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Too Many Arguments
+  Macro DEFMACRO
+  System Class FUNCTION
+  Type Specifier VALUES
+  Function APPLY
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Macro SETF, PSETF
+  Congruent Lambda-lists for all Methods of a Generic Function
+  Keyword Arguments in Generic Functions and Methods
+  Macro DEFINE-METHOD-COMBINATION
+  Glossary Section ``B''
+  Glossary Section ``R''
+rest list
+  Glossary Section ``R''
+rest parameter
+  Glossary Section ``R''
+restart
+  Glossary Section ``R''
+RESTART
+  System Class RESTART
+restart designator
+  Glossary Section ``R''
+restart function
+  Glossary Section ``R''
+RESTART-BIND
+  Macro RESTART-BIND
+RESTART-CASE
+  Macro RESTART-CASE
+RESTART-NAME
+  Function RESTART-NAME
+return
+  Glossary Section ``R''
+RETURN
+  Macro RETURN
+return (loop keyword)
+  Summary of Unconditional Execution Clauses
+  Unconditional Execution Clauses
+  Conditional Execution Clauses
+  Control Transfer Clauses
+  Initial and Final Execution
+  Macro LOOP
+return value
+  Glossary Section ``R''
+RETURN-FROM
+  Special Operator RETURN-FROM
+REVAPPEND
+  Function REVAPPEND, NRECONC
+REVERSE
+  Function REVERSE, NREVERSE
+Right-Brace (format directive)
+  Tilde Right-Brace: End of Iteration
+Right-Bracket (format directive)
+  Tilde Right-Bracket: End of Conditional Expression
+Right-Paren (format directive)
+  Tilde Right-Paren: End of Case Conversion
+right-parenthesis
+  Glossary Section ``R''
+Right-Parenthesis (reader macro)
+  Right-Parenthesis
+:right-margin
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+ROOM
+  Function ROOM
+ROTATEF
+  Macro ROTATEF
+ROUND
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+ROW-MAJOR-AREF
+  Accessor ROW-MAJOR-AREF
+RPLACA
+  Function RPLACA, RPLACD
+RPLACD
+  Function RPLACA, RPLACD
+run time
+  Glossary Section ``R''
+run-time compiler
+  Glossary Section ``R''
+run-time definition
+  Glossary Section ``R''
+run-time environment
+  Glossary Section ``R''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_S.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_S.htm new file mode 100644 index 00000000..94a204d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_S.htm @@ -0,0 +1,662 @@ + + + +CLHS: Index - S + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - S

    + +
    +S (format directive)
+  Tilde S: Standard
+S (sharpsign reader macro)
+  Sharpsign S
+safe
+  Error Terminology
+  Glossary Section ``S''
+safe call
+  Glossary Section ``S''
+safety
+  Minimal Declaration Processing Requirements
+same
+  Glossary Section ``S''
+SATISFIES
+  Type Specifier SATISFIES
+satisfy the test
+  Glossary Section ``S''
+SBIT
+  Accessor BIT, SBIT
+SCALE-FLOAT
+  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
+SCHAR
+  Accessor CHAR, SCHAR
+scope
+  Glossary Section ``S''
+script
+  Glossary Section ``S''
+SEARCH
+  Function SEARCH
+SECOND
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+secondary value
+  Glossary Section ``S''
+section
+  Glossary Section ``S''
+:section
+  Function PPRINT-TAB
+:section-relative
+  Function PPRINT-TAB
+self-evaluating object
+  Glossary Section ``S''
+semi-standard
+  Glossary Section ``S''
+semicolon
+  Glossary Section ``S''
+Semicolon (format directive)
+  Tilde Semicolon: Clause Separator
+Semicolon (reader macro)
+  Semicolon
+sequence
+  Glossary Section ``S''
+SEQUENCE
+  System Class SEQUENCE
+sequence function
+  Glossary Section ``S''
+sequential
+  Glossary Section ``S''
+sequentially
+  Glossary Section ``S''
+serious condition
+  Glossary Section ``S''
+SERIOUS-CONDITION
+  Condition Type SERIOUS-CONDITION
+session
+  Glossary Section ``S''
+set
+  Glossary Section ``S''
+SET
+  Function SET
+set-char-bit
+  Removed Operators
+SET-DIFFERENCE
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+SET-DISPATCH-MACRO-CHARACTER
+  Function SET-DISPATCH-MACRO-CHARACTER, GET-DISPATCH-MACRO-CHARACTER
+SET-EXCLUSIVE-OR
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+SET-MACRO-CHARACTER
+  Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER
+SET-PPRINT-DISPATCH
+  Function SET-PPRINT-DISPATCH
+SET-SYNTAX-FROM-CHAR
+  Function SET-SYNTAX-FROM-CHAR
+SETF
+  Macro SETF, PSETF
+setf expander
+  Glossary Section ``S''
+setf expansion
+  Glossary Section ``S''
+setf function
+  Glossary Section ``S''
+setf function name
+  Glossary Section ``S''
+(SETF CLASS-NAME)
+  Standard Generic Function (SETF CLASS-NAME)
+(SETF DOCUMENTATION)
+  Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)
+SETQ
+  Special Form SETQ
+SEVENTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+SHADOW
+  Function SHADOW
+shadow
+  Shadowing
+  Glossary Section ``S''
+:shadow
+  Macro DEFPACKAGE
+shadowing symbol
+  Prevention of Name Conflicts in Packages
+  Glossary Section ``S''
+shadowing symbols list
+  Glossary Section ``S''
+SHADOWING-IMPORT
+  Function SHADOWING-IMPORT
+:shadowing-import-from
+  Macro DEFPACKAGE
+shared slot
+  Glossary Section ``S''
+SHARED-INITIALIZE
+  Standard Generic Function SHARED-INITIALIZE
+sharpsign
+  Glossary Section ``S''
+Sharpsign (reader macro)
+  Sharpsign
+Sharpsign (sharpsign reader macro)
+  Sharpsign Sharpsign
+Sharpsign A (reader macro)
+  Sharpsign A
+Sharpsign Asterisk (reader macro)
+  Sharpsign Asterisk
+Sharpsign B (reader macro)
+  Sharpsign B
+Sharpsign Backslash (reader macro)
+  Sharpsign Backslash
+Sharpsign C (reader macro)
+  Sharpsign C
+Sharpsign Colon (reader macro)
+  Sharpsign Colon
+Sharpsign Dot (reader macro)
+  Sharpsign Dot
+Sharpsign Equal-Sign (reader macro)
+  Sharpsign Equal-Sign
+Sharpsign Left-Parenthesis (reader macro)
+  Sharpsign Left-Parenthesis
+Sharpsign Less-Than-Sign (reader macro)
+  Sharpsign Less-Than-Sign
+Sharpsign Minus (reader macro)
+  Sharpsign Minus
+Sharpsign O (reader macro)
+  Sharpsign O
+Sharpsign P (reader macro)
+  Sharpsign P
+Sharpsign Plus (reader macro)
+  Sharpsign Plus
+Sharpsign R (reader macro)
+  Sharpsign R
+Sharpsign Right-Parenthesis
+  Sharpsign Right-Parenthesis
+  Re-Reading Abbreviated Expressions
+Sharpsign S (reader macro)
+  Sharpsign S
+Sharpsign Sharpsign (reader macro)
+  Sharpsign Sharpsign
+  Local Macro PPRINT-POP
+Sharpsign Single-Quote (reader macro)
+  Sharpsign Single-Quote
+Sharpsign Vertical-Bar (reader macro)
+  Sharpsign Vertical-Bar
+Sharpsign Whitespace
+  Sharpsign Whitespace
+  Re-Reading Abbreviated Expressions
+Sharpsign X (reader macro)
+  Sharpsign X
+SHIFTF
+  Macro SHIFTF
+short float
+  Glossary Section ``S''
+SHORT-FLOAT
+  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
+SHORT-FLOAT-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+SHORT-FLOAT-NEGATIVE-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+SHORT-SITE-NAME
+  Function SHORT-SITE-NAME, LONG-SITE-NAME
+should signal
+  Error Terminology
+sign
+  Glossary Section ``S''
+SIGNAL
+  Function SIGNAL
+signal
+  Error Terminology
+  Glossary Section ``S''
+signature
+  Glossary Section ``S''
+SIGNED-BYTE
+  Type SIGNED-BYTE
+SIGNUM
+  Function SIGNUM
+similar
+  Glossary Section ``S''
+similarity
+  Glossary Section ``S''
+simple
+  Glossary Section ``S''
+simple array
+  Glossary Section ``S''
+simple bit array
+  Glossary Section ``S''
+simple bit vector
+  Glossary Section ``S''
+simple condition
+  Glossary Section ``S''
+simple general vector
+  Glossary Section ``S''
+simple string
+  Glossary Section ``S''
+simple vector
+  Glossary Section ``S''
+SIMPLE-ARRAY
+  Type SIMPLE-ARRAY
+SIMPLE-BASE-STRING
+  Type SIMPLE-BASE-STRING
+SIMPLE-BIT-VECTOR
+  Type SIMPLE-BIT-VECTOR
+simple-bit-vector
+  Sharpsign Asterisk
+SIMPLE-BIT-VECTOR-P
+  Function SIMPLE-BIT-VECTOR-P
+SIMPLE-CONDITION
+  Condition Type SIMPLE-CONDITION
+SIMPLE-CONDITION-FORMAT-ARGUMENTS
+  Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS
+SIMPLE-CONDITION-FORMAT-CONTROL
+  Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS
+SIMPLE-ERROR
+  Condition Type SIMPLE-ERROR
+SIMPLE-STRING
+  Type SIMPLE-STRING
+SIMPLE-STRING-P
+  Function SIMPLE-STRING-P
+SIMPLE-TYPE-ERROR
+  Condition Type SIMPLE-TYPE-ERROR
+SIMPLE-VECTOR
+  Type SIMPLE-VECTOR
+simple-vector
+  Sharpsign Left-Parenthesis
+SIMPLE-VECTOR-P
+  Function SIMPLE-VECTOR-P
+SIMPLE-WARNING
+  Condition Type SIMPLE-WARNING
+SIN
+  Function SIN, COS, TAN
+single escape
+  Glossary Section ``S''
+single float
+  Glossary Section ``S''
+SINGLE-FLOAT
+  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
+SINGLE-FLOAT-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+SINGLE-FLOAT-NEGATIVE-EPSILON
+  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
+single-quote
+  Glossary Section ``S''
+Single-Quote (reader macro)
+  Single-Quote
+Single-Quote (sharpsign reader macro)
+  Sharpsign Single-Quote
+singleton
+  Glossary Section ``S''
+SINH
+  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
+situation
+  Glossary Section ``S''
+SIXTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+:size
+  Macro DEFPACKAGE
+  Function MAKE-HASH-TABLE
+slash
+  Glossary Section ``S''
+Slash (format directive)
+  Tilde Slash: Call Function
+SLEEP
+  Function SLEEP
+slot
+  Glossary Section ``S''
+slot specifier
+  Defining Classes
+  Glossary Section ``S''
+SLOT-BOUNDP
+  Function SLOT-BOUNDP
+SLOT-EXISTS-P
+  Function SLOT-EXISTS-P
+SLOT-MAKUNBOUND
+  Function SLOT-MAKUNBOUND
+SLOT-MISSING
+  Standard Generic Function SLOT-MISSING
+SLOT-UNBOUND
+  Standard Generic Function SLOT-UNBOUND
+SLOT-VALUE
+  Function SLOT-VALUE
+:slot-names
+  Function MAKE-LOAD-FORM-SAVING-SLOTS
+SOFTWARE-TYPE
+  Function SOFTWARE-TYPE, SOFTWARE-VERSION
+SOFTWARE-VERSION
+  Function SOFTWARE-TYPE, SOFTWARE-VERSION
+SOME
+  Function EVERY, SOME, NOTEVERY, NOTANY
+SORT
+  Function SORT, STABLE-SORT
+source code
+  Glossary Section ``S''
+source file
+  Glossary Section ``S''
+space
+  Glossary Section ``S''
+SPECIAL
+  Declaration SPECIAL
+special
+  Minimal Declaration Processing Requirements
+special form
+  Glossary Section ``S''
+special operator
+  Glossary Section ``S''
+special variable
+  Glossary Section ``S''
+SPECIAL-OPERATOR-P
+  Function SPECIAL-OPERATOR-P
+specialize
+  Glossary Section ``S''
+specialized
+  Glossary Section ``S''
+specialized lambda list
+  Glossary Section ``S''
+spreadable argument list designator
+  Glossary Section ``S''
+SQRT
+  Function SQRT, ISQRT
+STABLE-SORT
+  Function SORT, STABLE-SORT
+stack allocate
+  Glossary Section ``S''
+stack-allocated
+  Glossary Section ``S''
+standard
+  Built-in Method Combination Types
+standard character
+  Standard Characters
+  Glossary Section ``S''
+standard class
+  Glossary Section ``S''
+standard generic function
+  Glossary Section ``S''
+standard input
+  Glossary Section ``S''
+standard method combination
+  Glossary Section ``S''
+standard object
+  Glossary Section ``S''
+standard output
+  Glossary Section ``S''
+standard pprint dispatch table
+  Glossary Section ``S''
+standard readtable
+  Glossary Section ``S''
+standard syntax
+  Glossary Section ``S''
+STANDARD-CHAR
+  Type STANDARD-CHAR
+STANDARD-CHAR-P
+  Function STANDARD-CHAR-P
+STANDARD-CLASS
+  System Class STANDARD-CLASS
+STANDARD-GENERIC-FUNCTION
+  System Class STANDARD-GENERIC-FUNCTION
+STANDARD-METHOD
+  System Class STANDARD-METHOD
+STANDARD-OBJECT
+  Class STANDARD-OBJECT
+*STANDARD-INPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+standardized
+  Glossary Section ``S''
+*STANDARD-OUTPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+:start
+  Examples of Ordinary Lambda Lists
+  Function PARSE-INTEGER
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+  Function FILL
+  Function REDUCE
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+  Function PARSE-NAMESTRING
+  Function WRITE-STRING, WRITE-LINE
+  Function READ-SEQUENCE
+  Function WRITE-SEQUENCE
+  Macro WITH-INPUT-FROM-STRING
+  Function READ-FROM-STRING
+  Glossary Section ``F''
+:start1
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+:start2
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+  Function SEARCH
+  Function MISMATCH
+  Function REPLACE
+startup environment
+  Glossary Section ``S''
+step
+  Glossary Section ``S''
+STEP
+  Macro STEP
+STORAGE-CONDITION
+  Condition Type STORAGE-CONDITION
+store-value
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+STORE-VALUE
+  Restart STORE-VALUE
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+stream
+  Glossary Section ``S''
+STREAM
+  System Class STREAM
+:stream
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+stream associated with a file
+  Glossary Section ``S''
+stream designator
+  Glossary Section ``S''
+stream element type
+  Glossary Section ``S''
+stream variable
+  Stream Variables
+  Glossary Section ``S''
+stream variable designator
+  Glossary Section ``S''
+STREAM-ELEMENT-TYPE
+  Function STREAM-ELEMENT-TYPE
+STREAM-ERROR
+  Condition Type STREAM-ERROR
+STREAM-ERROR-STREAM
+  Function STREAM-ERROR-STREAM
+STREAM-EXTERNAL-FORMAT
+  Function STREAM-EXTERNAL-FORMAT
+STREAMP
+  Function STREAMP
+STRING
+  System Class STRING
+  Function STRING
+string
+  Double-Quote
+  Required Kinds of Specialized Arrays
+  Glossary Section ``S''
+string designator
+  Glossary Section ``S''
+string equal
+  Glossary Section ``S''
+string stream
+  Glossary Section ``S''
+STRING-CAPITALIZE
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+string-char
+  Removed Types
+string-char-p
+  Removed Operators
+STRING-DOWNCASE
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+STRING-EQUAL
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING-GREATERP
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING-LEFT-TRIM
+  Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
+STRING-LESSP
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING-NOT-EQUAL
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING-NOT-GREATERP
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING-NOT-LESSP
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING-RIGHT-TRIM
+  Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
+STRING-STREAM
+  System Class STRING-STREAM
+STRING-TRIM
+  Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
+STRING-UPCASE
+  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
+STRING/=
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING<
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING<=
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING=
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING>
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRING>=
+  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
+STRINGP
+  Function STRINGP
+structure
+  Sharpsign S
+  Glossary Section ``S''
+structure class
+  Glossary Section ``S''
+structure name
+  Glossary Section ``S''
+STRUCTURE-CLASS
+  System Class STRUCTURE-CLASS
+STRUCTURE-OBJECT
+  Class STRUCTURE-OBJECT
+style warning
+  Glossary Section ``S''
+STYLE-WARNING
+  Condition Type STYLE-WARNING
+subclass
+  Glossary Section ``S''
+subexpression
+  Glossary Section ``S''
+subform
+  Glossary Section ``S''
+SUBLIS
+  Function SUBLIS, NSUBLIS
+subrepertoire
+  Glossary Section ``S''
+SUBSEQ
+  Accessor SUBSEQ
+SUBSETP
+  Function SUBSETP
+SUBST
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+SUBST-IF
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+SUBST-IF-NOT
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+SUBSTITUTE
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+SUBSTITUTE-IF
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+SUBSTITUTE-IF-NOT
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+subtype
+  Glossary Section ``S''
+SUBTYPEP
+  Function SUBTYPEP
+:suffix
+  Tilde Less-Than-Sign: Logical Block
+  Macro PPRINT-LOGICAL-BLOCK
+sum (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+summing (loop keyword)
+  Summary of Value Accumulation Clauses
+  Value Accumulation Clauses
+  Macro LOOP
+superclass
+  Glossary Section ``S''
+:supersede
+  Function OPEN
+supertype
+  Glossary Section ``S''
+supplied-p parameter
+  Glossary Section ``S''
+SVREF
+  Accessor SVREF
+SXHASH
+  Function SXHASH
+SYMBOL
+  System Class SYMBOL
+symbol
+  Sharpsign Colon
+  Glossary Section ``S''
+symbol (loop keyword)
+  The for-as-package subclause
+  Macro LOOP
+symbol macro
+  Minimal Compilation
+  Glossary Section ``S''
+SYMBOL-FUNCTION
+  Accessor SYMBOL-FUNCTION
+SYMBOL-MACROLET
+  Special Operator SYMBOL-MACROLET
+symbol-macrolet
+  Minimal Compilation
+SYMBOL-NAME
+  Function SYMBOL-NAME
+SYMBOL-PACKAGE
+  Function SYMBOL-PACKAGE
+SYMBOL-PLIST
+  Accessor SYMBOL-PLIST
+SYMBOL-VALUE
+  Accessor SYMBOL-VALUE
+SYMBOLP
+  Function SYMBOLP
+symbols (loop keyword)
+  The for-as-package subclause
+  Macro LOOP
+synonym stream
+  Glossary Section ``S''
+synonym stream symbol
+  Glossary Section ``S''
+SYNONYM-STREAM
+  System Class SYNONYM-STREAM
+SYNONYM-STREAM-SYMBOL
+  Function SYNONYM-STREAM-SYMBOL
+syntax type
+  Glossary Section ``S''
+SYSTEM
+  Packages No Longer Required
+system class
+  Glossary Section ``S''
+system code
+  Glossary Section ``S''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_T.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_T.htm new file mode 100644 index 00000000..078c3c8a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_T.htm @@ -0,0 +1,303 @@ + + + +CLHS: Index - T + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - T

    + +
    +t
+  Macro CASE, CCASE, ECASE
+  Macro TYPECASE, CTYPECASE, ETYPECASE
+  Glossary Section ``T''
+T
+  System Class T
+  Constant Variable T
+T (format directive)
+  Tilde T: Tabulate
+tag
+  Glossary Section ``T''
+TAGBODY
+  Special Operator TAGBODY
+tail
+  Glossary Section ``T''
+TAILP
+  Function LDIFF, TAILP
+TAN
+  Function SIN, COS, TAN
+TANH
+  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
+target
+  Glossary Section ``T''
+TENTH
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+terminal I/O
+  Glossary Section ``T''
+*TERMINAL-IO*
+  Variable *TERMINAL-IO*
+terminating
+  Glossary Section ``T''
+TERPRI
+  Function TERPRI, FRESH-LINE
+tertiary value
+  Glossary Section ``T''
+:test
+  Function EQUALP
+  Function COMPLEMENT
+  Restart Tests
+  Macro RESTART-CASE
+  Function SUBLIS, NSUBLIS
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+  Function TREE-EQUAL
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+  Function INTERSECTION, NINTERSECTION
+  Function ADJOIN
+  Macro PUSHNEW
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+  Function SUBSETP
+  Function UNION, NUNION
+  Satisfying a Two-Argument Test
+  Satisfying a One-Argument Test
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+  Modifying Hash Table Keys
+  Visible Modifications by Language Extensions
+  Function MAKE-HASH-TABLE
+:test-function
+  Restart Tests
+  Macro RESTART-BIND
+:test-not
+  Deprecated Argument Conventions
+  Function COMPLEMENT
+  Function SUBLIS, NSUBLIS
+  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
+  Function TREE-EQUAL
+  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
+  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
+  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
+  Function INTERSECTION, NINTERSECTION
+  Function ADJOIN
+  Macro PUSHNEW
+  Function SET-DIFFERENCE, NSET-DIFFERENCE
+  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
+  Function SUBSETP
+  Function UNION, NUNION
+  Satisfying a Two-Argument Test
+  Function COUNT, COUNT-IF, COUNT-IF-NOT
+  Function FIND, FIND-IF, FIND-IF-NOT
+  Function POSITION, POSITION-IF, POSITION-IF-NOT
+  Function SEARCH
+  Function MISMATCH
+  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
+  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
+  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
+THE
+  Special Operator THE
+the (loop keyword)
+  The for-as-hash subclause
+  The for-as-package subclause
+  Macro LOOP
+then (loop keyword)
+  The for-as-equals-then subclause
+  Macro LOOP
+thereis (loop keyword)
+  Summary of Termination Test Clauses
+  Termination Test Clauses
+  Initial and Final Execution
+  Macro LOOP
+THIRD
+  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
+throw
+  Glossary Section ``T''
+THROW
+  Special Operator THROW
+tilde
+  Glossary Section ``T''
+Tilde (format directive)
+  Tilde Tilde: Tilde
+Tilde A (format directive)
+  Tilde A: Aesthetic
+Tilde Ampersand (format directive)
+  Tilde Ampersand: Fresh-Line
+Tilde Asterisk (format directive)
+  Tilde Asterisk: Go-To
+Tilde B (format directive)
+  Tilde B: Binary
+Tilde C (format directive)
+  Tilde C: Character
+Tilde Circumflex (format directive)
+  Tilde Circumflex: Escape Upward
+Tilde D (format directive)
+  Tilde D: Decimal
+Tilde Dollarsign (format directive)
+  Tilde Dollarsign: Monetary Floating-Point
+Tilde E (format directive)
+  Tilde E: Exponential Floating-Point
+Tilde F (format directive)
+  Tilde F: Fixed-Format Floating-Point
+Tilde G (format directive)
+  Tilde G: General Floating-Point
+Tilde Greater-Than-Sign (format directive)
+  Tilde Greater-Than-Sign: End of Justification
+Tilde I (format directive)
+  Tilde I: Indent
+Tilde Left-Brace (format directive)
+  Tilde Left-Brace: Iteration
+Tilde Left-Bracket (format directive)
+  Tilde Left-Bracket: Conditional Expression
+Tilde Left-Paren (format directive)
+  Tilde Left-Paren: Case Conversion
+Tilde Less-Than-Sign (format directive)
+  Tilde Less-Than-Sign: Logical Block
+  Tilde Less-Than-Sign: Justification
+Tilde Newline (format directive)
+  Tilde Newline: Ignored Newline
+Tilde O (format directive)
+  Tilde O: Octal
+Tilde P (format directive)
+  Tilde P: Plural
+Tilde Percent (format directive)
+  Tilde Percent: Newline
+Tilde Question-Mark (format directive)
+  Tilde Question-Mark: Recursive Processing
+Tilde R (format directive)
+  Tilde R: Radix
+Tilde Right-Brace (format directive)
+  Tilde Right-Brace: End of Iteration
+Tilde Right-Bracket (format directive)
+  Tilde Right-Bracket: End of Conditional Expression
+Tilde Right-Paren (format directive)
+  Tilde Right-Paren: End of Case Conversion
+Tilde S (format directive)
+  Tilde S: Standard
+Tilde Semicolon (format directive)
+  Tilde Semicolon: Clause Separator
+Tilde Slash (format directive)
+  Tilde Slash: Call Function
+Tilde T (format directive)
+  Tilde T: Tabulate
+Tilde Tilde (format directive)
+  Tilde Tilde: Tilde
+Tilde Underscore (format directive)
+  Tilde Underscore: Conditional Newline
+Tilde Vertical-Bar (format directive)
+  Tilde Vertical-Bar: Page
+Tilde W (format directive)
+  Tilde W: Write
+Tilde X (format directive)
+  Tilde X: Hexadecimal
+time
+  Glossary Section ``T''
+TIME
+  Macro TIME
+time zone
+  Glossary Section ``T''
+to (loop keyword)
+  Parsing Loop Clauses
+  The for-as-arithmetic subclause
+  Macro LOOP
+token
+  Glossary Section ``T''
+top level form
+  Glossary Section ``T''
+TRACE
+  Macro TRACE, UNTRACE
+trace output
+  Glossary Section ``T''
+*TRACE-OUTPUT*
+  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
+TRANSLATE-LOGICAL-PATHNAME
+  Function TRANSLATE-LOGICAL-PATHNAME
+TRANSLATE-PATHNAME
+  Function TRANSLATE-PATHNAME
+tree
+  Glossary Section ``T''
+tree structure
+  Glossary Section ``T''
+TREE-EQUAL
+  Function TREE-EQUAL
+true
+  Glossary Section ``T''
+truename
+  Glossary Section ``T''
+TRUENAME
+  Function TRUENAME
+TRUNCATE
+  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
+two-way stream
+  Glossary Section ``T''
+TWO-WAY-STREAM
+  System Class TWO-WAY-STREAM
+TWO-WAY-STREAM-INPUT-STREAM
+  Function TWO-WAY-STREAM-INPUT-STREAM, TWO-WAY-STREAM-OUTPUT-STREAM
+TWO-WAY-STREAM-OUTPUT-STREAM
+  Function TWO-WAY-STREAM-INPUT-STREAM, TWO-WAY-STREAM-OUTPUT-STREAM
+type
+  Glossary Section ``T''
+TYPE
+  Declaration TYPE
+:type
+  Boa Lambda Lists
+  Type Specifiers
+  Integrating Types and Classes
+  Function TYPE-OF
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFSTRUCT
+  Macro DEFINE-CONDITION
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+  Macro PRINT-UNREADABLE-OBJECT
+  Glossary Section ``S''
+type declaration
+  Glossary Section ``T''
+type equivalent
+  Glossary Section ``T''
+type expand
+  Glossary Section ``T''
+type specifier
+  Glossary Section ``T''
+TYPE-ERROR
+  Condition Type TYPE-ERROR
+TYPE-ERROR-DATUM
+  Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE
+TYPE-ERROR-EXPECTED-TYPE
+  Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE
+TYPE-OF
+  Function TYPE-OF
+TYPECASE
+  Macro TYPECASE, CTYPECASE, ETYPECASE
+TYPEP
+  Function TYPEP
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_U.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_U.htm new file mode 100644 index 00000000..053ed338 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_U.htm @@ -0,0 +1,171 @@ + + + +CLHS: Index - U + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - U

    + +
    +unbound
+  Glossary Section ``U''
+unbound variable
+  Glossary Section ``U''
+UNBOUND-SLOT
+  Condition Type UNBOUND-SLOT
+UNBOUND-SLOT-INSTANCE
+  Function UNBOUND-SLOT-INSTANCE
+UNBOUND-VARIABLE
+  Condition Type UNBOUND-VARIABLE
+undefined consequences
+  Error Terminology
+undefined function
+  Glossary Section ``U''
+UNDEFINED-FUNCTION
+  Condition Type UNDEFINED-FUNCTION
+Underscore (format directive)
+  Tilde Underscore: Conditional Newline
+UNEXPORT
+  Function UNEXPORT
+unintern
+  Glossary Section ``U''
+UNINTERN
+  Function UNINTERN
+uninterned
+  Glossary Section ``U''
+UNION
+  Function UNION, NUNION
+universal time
+  Universal Time
+  Glossary Section ``U''
+UNLESS
+  Macro WHEN, UNLESS
+unless (loop keyword)
+  Summary of Conditional Execution Clauses
+  Conditional Execution Clauses
+  Macro LOOP
+unqualified method
+  Glossary Section ``U''
+UNREAD-CHAR
+  Function UNREAD-CHAR
+unregistered package
+  Glossary Section ``U''
+unsafe
+  Error Terminology
+  Glossary Section ``U''
+unsafe call
+  Glossary Section ``U''
+UNSIGNED-BYTE
+  Type UNSIGNED-BYTE
+:unspecific
+  The Pathname Type Component
+  The Pathname Version Component
+  :UNSPECIFIC as a Component Value
+  Relation between component values NIL and :UNSPECIFIC
+  Restrictions on Examining a Pathname Device Component
+  Restrictions on Examining a Pathname Directory Component
+  Restrictions on Examining a Pathname Name Component
+  Restrictions on Examining a Pathname Type Component
+  Restrictions on Examining a Pathname Version Component
+  Merging Pathnames
+  Examples of Merging Pathnames
+  The Device part of a Logical Pathname Namestring
+  Unspecific Components of a Logical Pathname
+  Function MAKE-PATHNAME
+  Function USER-HOMEDIR-PATHNAME
+  Glossary Section ``V''
+unspecified consequences
+  Error Terminology
+unspecified values
+  Error Terminology
+until (loop keyword)
+  Summary of Termination Test Clauses
+  Termination Test Clauses
+  Macro LOOP
+UNTRACE
+  Macro TRACE, UNTRACE
+UNUSE-PACKAGE
+  Function UNUSE-PACKAGE
+UNWIND-PROTECT
+  Special Operator UNWIND-PROTECT
+:up
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+:upcase
+  The Standard Readtable
+  Symbols as Tokens
+  Valid Patterns for Tokens
+  Effect of Readtable Case on the Lisp Printer
+  Variable *PRINT-CASE*
+  Effect of Readtable Case on the Lisp Reader
+  Macro WITH-STANDARD-IO-SYNTAX
+  Glossary Section ``C''
+UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
+  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
+UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+upfrom (loop keyword)
+  The for-as-arithmetic subclause
+  Macro LOOP
+upgrade
+  Glossary Section ``U''
+upgraded array element type
+  Glossary Section ``U''
+upgraded complex part type
+  Glossary Section ``U''
+UPGRADED-ARRAY-ELEMENT-TYPE
+  Function UPGRADED-ARRAY-ELEMENT-TYPE
+UPGRADED-COMPLEX-PART-TYPE
+  Function UPGRADED-COMPLEX-PART-TYPE
+UPPER-CASE-P
+  Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P
+uppercase
+  Glossary Section ``U''
+upto (loop keyword)
+  The for-as-arithmetic subclause
+  Macro LOOP
+use
+  Glossary Section ``U''
+:use
+  Function MAKE-PACKAGE
+  Macro DEFPACKAGE
+use list
+  Glossary Section ``U''
+USE-PACKAGE
+  Function USE-PACKAGE
+use-value
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+USE-VALUE
+  Restart USE-VALUE
+  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
+USER
+  Packages No Longer Required
+user
+  Glossary Section ``U''
+USER-HOMEDIR-PATHNAME
+  Function USER-HOMEDIR-PATHNAME
+using (loop keyword)
+  The for-as-hash subclause
+  Macro LOOP
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_V.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_V.htm new file mode 100644 index 00000000..8acb5ea8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_V.htm @@ -0,0 +1,97 @@ + + + +CLHS: Index - V + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - V

    + +
    +valid array dimension
+  Glossary Section ``V''
+valid array index
+  Glossary Section ``V''
+valid array row-major index
+  Glossary Section ``V''
+valid fill pointer
+  Glossary Section ``V''
+valid logical pathname host
+  Glossary Section ``V''
+valid pathname device
+  Glossary Section ``V''
+valid pathname directory
+  Glossary Section ``V''
+valid pathname host
+  Glossary Section ``V''
+valid pathname name
+  Glossary Section ``V''
+valid pathname type
+  Glossary Section ``V''
+valid pathname version
+  Glossary Section ``V''
+valid physical pathname host
+  Glossary Section ``V''
+valid sequence index
+  Glossary Section ``V''
+value
+  Glossary Section ``V''
+value cell
+  Glossary Section ``V''
+VALUES
+  Type Specifier VALUES
+  Accessor VALUES
+VALUES-LIST
+  Function VALUES-LIST
+variable
+  Glossary Section ``V''
+VECTOR
+  System Class VECTOR
+  Function VECTOR
+vector
+  Sharpsign Left-Parenthesis
+  Glossary Section ``V''
+VECTOR-POP
+  Function VECTOR-POP
+VECTOR-PUSH
+  Function VECTOR-PUSH, VECTOR-PUSH-EXTEND
+VECTOR-PUSH-EXTEND
+  Function VECTOR-PUSH, VECTOR-PUSH-EXTEND
+VECTORP
+  Function VECTORP
+:verbose
+  Function ENSURE-DIRECTORIES-EXIST
+  Function COMPILE-FILE
+  Function LOAD
+  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
+  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
+:version
+  Function MAKE-PATHNAME
+  Function WILD-PATHNAME-P
+vertical-bar
+  Glossary Section ``V''
+Vertical-Bar (format directive)
+  Tilde Vertical-Bar: Page
+Vertical-Bar (sharpsign reader macro)
+  Sharpsign Vertical-Bar
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_W.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_W.htm new file mode 100644 index 00000000..a0fd5646 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_W.htm @@ -0,0 +1,145 @@ + + + +CLHS: Index - W + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - W

    + +
    +W (format directive)
+  Tilde W: Write
+WARN
+  Function WARN
+WARNING
+  Condition Type WARNING
+warning
+  Error Terminology
+WHEN
+  Macro WHEN, UNLESS
+when (loop keyword)
+  Summary of Conditional Execution Clauses
+  Conditional Execution Clauses
+  Macro LOOP
+while (loop keyword)
+  Summary of Termination Test Clauses
+  Termination Test Clauses
+  Macro LOOP
+whitespace
+  Glossary Section ``W''
+&whole
+  Macro Lambda Lists
+  Lambda-list-directed Destructuring by Lambda Lists
+  Define-method-combination Arguments Lambda Lists
+  Macro DEFINE-COMPILER-MACRO
+  Constant Variable LAMBDA-LIST-KEYWORDS
+  Macro DEFINE-METHOD-COMBINATION
+wild
+  Glossary Section ``W''
+:wild
+  The Pathname Type Component
+  The Pathname Version Component
+  :WILD as a Component Value
+  Restrictions on Wildcard Pathnames
+  Restrictions on Examining a Pathname Device Component
+  Restrictions on Examining a Pathname Directory Component
+  Restrictions on Examining a Pathname Name Component
+  Restrictions on Examining a Pathname Type Component
+  Restrictions on Examining a Pathname Version Component
+  The Version part of a Logical Pathname Namestring
+  Wildcard Words in a Logical Pathname Namestring
+  Function MAKE-PATHNAME
+  Function PATHNAME-MATCH-P
+  Function TRANSLATE-PATHNAME
+  Function MERGE-PATHNAMES
+  Glossary Section ``V''
+  Glossary Section ``W''
+WILD-PATHNAME-P
+  Function WILD-PATHNAME-P
+:wild-inferiors
+  :WILD as a Component Value
+  Restrictions on Examining a Pathname Directory Component
+  Directory Components in Non-Hierarchical File Systems
+  The Directory part of a Logical Pathname Namestring
+  Function MAKE-PATHNAME
+:wild-inferors
+  Glossary Section ``W''
+with (loop keyword)
+  Summary of Variable Initialization and Stepping Clauses
+  Summary of Miscellaneous Clauses
+  Order of Execution
+  Iteration Control
+  Local Variable Initializations
+  Value Accumulation Clauses
+  Initial and Final Execution
+  Macro LOOP
+WITH-ACCESSORS
+  Macro WITH-ACCESSORS
+WITH-COMPILATION-UNIT
+  Macro WITH-COMPILATION-UNIT
+WITH-CONDITION-RESTARTS
+  Macro WITH-CONDITION-RESTARTS
+WITH-HASH-TABLE-ITERATOR
+  Macro WITH-HASH-TABLE-ITERATOR
+WITH-INPUT-FROM-STRING
+  Macro WITH-INPUT-FROM-STRING
+WITH-OPEN-FILE
+  macro WITH-OPEN-FILE
+WITH-OPEN-STREAM
+  Macro WITH-OPEN-STREAM
+WITH-OUTPUT-TO-STRING
+  Macro WITH-OUTPUT-TO-STRING
+WITH-PACKAGE-ITERATOR
+  Macro WITH-PACKAGE-ITERATOR
+WITH-SIMPLE-RESTART
+  Macro WITH-SIMPLE-RESTART
+WITH-SLOTS
+  Macro WITH-SLOTS
+WITH-STANDARD-IO-SYNTAX
+  Macro WITH-STANDARD-IO-SYNTAX
+write
+  Glossary Section ``W''
+WRITE
+  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
+WRITE-BYTE
+  Function WRITE-BYTE
+WRITE-CHAR
+  Function WRITE-CHAR
+WRITE-LINE
+  Function WRITE-STRING, WRITE-LINE
+WRITE-SEQUENCE
+  Function WRITE-SEQUENCE
+WRITE-STRING
+  Function WRITE-STRING, WRITE-LINE
+WRITE-TO-STRING
+  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
+writer
+  Glossary Section ``W''
+:writer
+  Redefining Classes
+  Accessing Slots
+  Inheritance of Slots and Slot Options
+  Macro DEFCLASS
+  Macro DEFINE-CONDITION
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_X.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_X.htm new file mode 100644 index 00000000..8e163619 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_X.htm @@ -0,0 +1,37 @@ + + + +CLHS: Index - X + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - X

    + +
    +X (format directive)
+  Tilde X: Hexadecimal
+X (sharpsign reader macro)
+  Sharpsign X
+:x3j13
+  Variable *FEATURES*
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Y.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Y.htm new file mode 100644 index 00000000..5bce903b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Y.htm @@ -0,0 +1,37 @@ + + + +CLHS: Index - Y + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - Y

    + +
    +Y-OR-N-P
+  Function Y-OR-N-P, YES-OR-NO-P
+YES-OR-NO-P
+  Function Y-OR-N-P, YES-OR-NO-P
+yield
+  Glossary Section ``Y''
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Z.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Z.htm new file mode 100644 index 00000000..e32cd207 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Mast_Z.htm @@ -0,0 +1,33 @@ + + + +CLHS: Index - Z + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index - Z

    + +
    +ZEROP
+  Function ZEROP
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Master.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Master.htm new file mode 100644 index 00000000..caf097df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Master.htm @@ -0,0 +1,29 @@ + + + +CLHS: Index + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + +

    Index

    + +Index entries are partitioned by their initial character.

    A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | Non-Alphabetic

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_9.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_9.htm new file mode 100644 index 00000000..682de1a1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_9.htm @@ -0,0 +1,148 @@ + + + +CLHS: Permuted Symbol Index (Non-Alphabetic) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (Non-Alphabetic)

    + +
    +                   &allow-other-keys
+                   &aux
+                   &body
+                   &environment
+                   &key
+                   &optional
+                   &rest
+                   &whole
+                   *
+                 do*
+                let*
+               list*
+               prog*
+                   **
+                   ***
+                   *break-on-signals*
+                   *compile-file-pathname*
+                   *compile-file-truename*
+                   *compile-print*
+                   *compile-verbose*
+                   *debug-io*
+                   *debugger-hook*
+                   *default-pathname-defaults*
+                   *error-output*
+                   *features*
+                   *gensym-counter*
+                   *load-pathname*
+                   *load-print*
+                   *load-truename*
+                   *load-verbose*
+                   *macroexpand-hook*
+                   *modules*
+                   *package*
+                   *print-array*
+                   *print-base*
+                   *print-case*
+                   *print-circle*
+                   *print-escape*
+                   *print-gensym*
+                   *print-length*
+                   *print-level*
+                   *print-lines*
+                   *print-miser-width*
+                   *print-pprint-dispatch*
+                   *print-pretty*
+                   *print-radix*
+                   *print-readably*
+                   *print-right-margin*
+                   *query-io*
+                   *random-state*
+                   *read-base*
+                   *read-default-float-format*
+                   *read-eval*
+                   *read-suppress*
+                   *readtable*
+                   *standard-input*
+                   *standard-output*
+                   *terminal-io*
+                   *trace-output*
+                   +
+                  1+
+                   ++
+                   +++
+                   -
+                   /
+                   //
+                   ///
+                   /=
+               char/=
+             string/=
+           bit-andc1
+            bit-orc1
+             boole-1
+         boole-andc1
+            boole-c1
+          boole-orc1
+            logandc1
+             logorc1
+       macroexpand-1
+multiple-value-prog1
+               prin1
+               prog1
+                   1+
+                   1-
+               prin1-to-string
+           bit-andc2
+            bit-orc2
+             boole-2
+         boole-andc2
+            boole-c2
+          boole-orc2
+            logandc2
+             logorc2
+               prog2
+                   <
+               char<
+             string<
+                   <=
+               char<=
+             string<=
+                  /=
+                  <=
+                   =
+                  >=
+              char/=
+              char<=
+               char=
+              char>=
+            string/=
+            string<=
+             string=
+            string>=
+                   >
+               char>
+             string>
+                   >=
+               char>=
+             string>=
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_A.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_A.htm new file mode 100644 index 00000000..3045a730 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_A.htm @@ -0,0 +1,100 @@ + + + +CLHS: Permuted Symbol Index (A) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (A)

    + +
    +                        abort
+                        abs
+                   with-accessors
+                        acons
+                        acos
+                        acosh
+                        add-method
+                        adjoin
+                        adjust-array
+                        adjustable-array-p
+                   copy-alist
+                   list-all-packages
+                     do-all-symbols
+                   find-all-symbols
+                        allocate-instance
+                       &allow-other-keys
+                        alpha-char-p
+                        alphanumericp
+                        and
+                    bit-and
+                  boole-and
+                    bit-andc1
+                  boole-andc1
+                    bit-andc2
+                  boole-andc2
+                        append
+                     no-applicable-method
+                compute-applicable-methods
+                        apply
+                        apropos
+                        apropos-list
+                        aref
+              row-major-aref
+simple-condition-format-arguments
+                   call-arguments-limit
+                        arithmetic-error
+                        arithmetic-error-operands
+                        arithmetic-error-operation
+                 adjust-array
+                        array
+                   make-array
+                 simple-array
+                 *print-array*
+                        array-dimension
+                        array-dimension-limit
+                        array-dimensions
+                        array-displacement
+                        array-element-type
+               upgraded-array-element-type
+                        array-has-fill-pointer-p
+                        array-in-bounds-p
+             adjustable-array-p
+                        array-rank
+                        array-rank-limit
+                        array-row-major-index
+                        array-total-size
+                        array-total-size-limit
+                        arrayp
+                        ash
+                        asin
+                        asinh
+                        assert
+                        assoc
+                        assoc-if
+                        assoc-if-not
+                        atan
+                        atanh
+                        atom
+                   file-author
+                       &aux
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_B.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_B.htm new file mode 100644 index 00000000..12b0bc34 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_B.htm @@ -0,0 +1,97 @@ + + + +CLHS: Permuted Symbol Index (B) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (B)

    + +
    +        *print-base*
+         *read-base*
+               base-char
+               base-string
+        simple-base-string
+               bignum
+ destructuring-bind
+       handler-bind
+multiple-value-bind
+       restart-bind
+               bit
+               bit-and
+               bit-andc1
+               bit-andc2
+               bit-eqv
+               bit-ior
+               bit-nand
+               bit-nor
+               bit-not
+               bit-orc1
+               bit-orc2
+               bit-vector
+        simple-bit-vector
+               bit-vector-p
+        simple-bit-vector-p
+               bit-xor
+               block
+pprint-logical-block
+              &body
+               boole
+               boole-1
+               boole-2
+               boole-and
+               boole-andc1
+               boole-andc2
+               boole-c1
+               boole-c2
+               boole-clr
+               boole-eqv
+               boole-ior
+               boole-nand
+               boole-nor
+               boole-orc1
+               boole-orc2
+               boole-set
+               boole-xor
+               boolean
+               both-case-p
+               boundp
+          slot-boundp
+      array-in-bounds-p
+               break
+              *break-on-signals*
+               broadcast-stream
+          make-broadcast-stream
+               broadcast-stream-streams
+               built-in-class
+               butlast
+  package-used-by-list
+      division-by-zero
+               byte
+          read-byte
+        signed-byte
+      unsigned-byte
+         write-byte
+               byte-position
+               byte-size
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_C.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_C.htm new file mode 100644 index 00000000..539f644d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_C.htm @@ -0,0 +1,208 @@ + + + +CLHS: Permuted Symbol Index (C) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (C)

    + +
    +                        boole-c1
+                        boole-c2
+                              caaaar
+                              caaadr
+                              caaar
+                              caadar
+                              caaddr
+                              caadr
+                              caar
+                              cadaar
+                              cadadr
+                              cadar
+                              caddar
+                              cadddr
+                              caddr
+                              cadr
+               multiple-value-call
+                              call-arguments-limit
+                              call-method
+                              call-next-method
+                      nstring-capitalize
+                       string-capitalize
+                              car
+                              case
+                      handler-case
+                    readtable-case
+                      restart-case
+                       *print-case*
+                         both-case-p
+                        lower-case-p
+                        upper-case-p
+                              catch
+                              ccase
+                              cdaaar
+                              cdaadr
+                              cdaar
+                              cdadar
+                              cdaddr
+                              cdadr
+                              cdar
+                              cddaar
+                              cddadr
+                              cddar
+                              cdddar
+                              cddddr
+                              cdddr
+                              cddr
+                              cdr
+                              ceiling
+                              cell-error
+                              cell-error-name
+                              cerror
+                              change-class
+                         base-char
+                              char
+                         code-char
+                        digit-char
+                     extended-char
+                         name-char
+                         peek-char
+                         read-char
+              set-syntax-from-char
+                     standard-char
+                       unread-char
+                        write-char
+                              char-code
+                              char-code-limit
+                              char-downcase
+                              char-equal
+                              char-greaterp
+                              char-int
+                              char-lessp
+                              char-name
+                         read-char-no-hang
+                              char-not-equal
+                              char-not-greaterp
+                              char-not-lessp
+                        alpha-char-p
+                        digit-char-p
+                      graphic-char-p
+                     standard-char-p
+                              char-upcase
+                              char/=
+                              char<
+                              char<=
+                              char=
+                              char>
+                              char>=
+                              character
+           get-dispatch-macro-character
+                    get-macro-character
+          make-dispatch-macro-character
+           set-dispatch-macro-character
+                    set-macro-character
+                              characterp
+                              check-type
+                       *print-circle*
+                              cis
+                     built-in-class
+                       change-class
+                              class
+                         find-class
+                     standard-class
+                    structure-class
+update-instance-for-different-class
+update-instance-for-redefined-class
+                              class-name
+                              class-of
+                              clear-input
+                              clear-output
+                              close
+                        boole-clr
+                              clrhash
+                         char-code
+                              code-char
+                         char-code-limit
+                              coerce
+                define-method-combination
+                       method-combination
+                       method-combination-error
+                              compilation-speed
+                         with-compilation-unit
+                              compile
+                              compile-file
+                              compile-file-pathname
+                             *compile-file-pathname*
+                             *compile-file-truename*
+                             *compile-print*
+                             *compile-verbose*
+                              compiled-function
+                              compiled-function-p
+                              compiler-macro
+                       define-compiler-macro
+                              compiler-macro-function
+                              complement
+                              complex
+                     upgraded-complex-part-type
+                              complexp
+                              compute-applicable-methods
+                              compute-restarts
+                              concatenate
+                              concatenated-stream
+                         make-concatenated-stream
+                              concatenated-stream-streams
+                              cond
+                              condition
+                       define-condition
+                         make-condition
+                      serious-condition
+                       simple-condition
+                      storage-condition
+                       simple-condition-format-arguments
+                       simple-condition-format-control
+                         with-condition-restarts
+                              conjugate
+                              cons
+                              consp
+                              constantly
+                              constantp
+                              continue
+      simple-condition-format-control
+                              control-error
+                              copy-alist
+                              copy-list
+                              copy-pprint-dispatch
+                              copy-readtable
+                              copy-seq
+                              copy-structure
+                              copy-symbol
+                              copy-tree
+                              cos
+                              cosh
+                              count
+                   hash-table-count
+                              count-if
+                              count-if-not
+                      *gensym-counter*
+                              ctypecase
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_D.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_D.htm new file mode 100644 index 00000000..c2f2581e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_D.htm @@ -0,0 +1,126 @@ + + + +CLHS: Permuted Symbol Index (D) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (D)

    + +
    +               file-write-date
+               type-error-datum
+                          debug
+                         *debug-io*
+                   invoke-debugger
+                         *debugger-hook*
+                          decf
+                          declaim
+                          declaration
+                          declare
+                          decode-float
+                  integer-decode-float
+                          decode-universal-time
+                      get-decoded-time
+                    *read-default-float-format*
+                         *default-pathname-defaults*
+        *default-pathname-defaults*
+                          defclass
+                          defconstant
+                          defgeneric
+                          define-compiler-macro
+                          define-condition
+                          define-method-combination
+                          define-modify-macro
+                          define-setf-expander
+                          define-symbol-macro
+                          defmacro
+                          defmethod
+                          defpackage
+                          defparameter
+                          defsetf
+                          defstruct
+                          deftype
+                          defun
+                          defvar
+                          delete
+                          delete-duplicates
+                          delete-file
+                          delete-if
+                          delete-if-not
+                          delete-package
+                     read-delimited-list
+                          denominator
+                          deposit-field
+                          describe
+                          describe-object
+                          destructuring-bind
+                 pathname-device
+                     nset-difference
+                      set-difference
+      update-instance-for-different-class
+                          digit-char
+                          digit-char-p
+                    float-digits
+                    array-dimension
+                    array-dimension-limit
+                    array-dimensions
+                   ensure-directories-exist
+                          directory
+                 pathname-directory
+                          directory-namestring
+                          disassemble
+              copy-pprint-dispatch
+                   pprint-dispatch
+               set-pprint-dispatch
+            *print-pprint-dispatch*
+                      get-dispatch-macro-character
+                     make-dispatch-macro-character
+                      set-dispatch-macro-character
+                    array-displacement
+                          division-by-zero
+                          do
+                          do*
+                          do-all-symbols
+                          do-external-symbols
+                          do-symbols
+                          documentation
+                          dolist
+                          dotimes
+                          double-float
+           least-negative-double-float
+least-negative-normalized-double-float
+           least-positive-double-float
+least-positive-normalized-double-float
+            most-negative-double-float
+            most-positive-double-float
+                          double-float-epsilon
+                          double-float-negative-epsilon
+                     char-downcase
+                  nstring-downcase
+                   string-downcase
+                          dpb
+                          dribble
+                   delete-duplicates
+                   remove-duplicates
+                          dynamic-extent
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_E.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_E.htm new file mode 100644 index 00000000..40cd5325 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_E.htm @@ -0,0 +1,117 @@ + + + +CLHS: Permuted Symbol Index (E) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (E)

    + +
    +                      ecase
+                      echo-stream
+                 make-echo-stream
+                      echo-stream-input-stream
+                      echo-stream-output-stream
+                      ed
+                      eighth
+                array-element-type
+               stream-element-type
+       upgraded-array-element-type
+                      elt
+                      encode-universal-time
+                      end-of-file
+                      endp
+                      enough-namestring
+                      ensure-directories-exist
+                      ensure-generic-function
+                     &environment
+         double-float-epsilon
+double-float-negative-epsilon
+           long-float-epsilon
+  long-float-negative-epsilon
+          short-float-epsilon
+ short-float-negative-epsilon
+         single-float-epsilon
+single-float-negative-epsilon
+                      eq
+                      eql
+                 char-equal
+             char-not-equal
+                      equal
+               string-equal
+           string-not-equal
+                 tree-equal
+                      equalp
+                  bit-eqv
+                boole-eqv
+           arithmetic-error
+                 cell-error
+              control-error
+                      error
+                 file-error
+       invalid-method-error
+   method-combination-error
+              package-error
+                parse-error
+              program-error
+               reader-error
+               simple-error
+          simple-type-error
+               stream-error
+                 type-error
+                 type-error-datum
+                 type-error-expected-type
+                 cell-error-name
+           arithmetic-error-operands
+           arithmetic-error-operation
+                     *error-output*
+              package-error-package
+                 file-error-pathname
+               stream-error-stream
+               ignore-errors
+               *print-escape*
+                      etypecase
+                      eval
+                *read-eval*
+                      eval-when
+                      evenp
+                      every
+                 nset-exclusive-or
+                  set-exclusive-or
+  pprint-exit-if-list-exhausted
+   ensure-directories-exist
+                 slot-exists-p
+               pprint-exit-if-list-exhausted
+                      exp
+          define-setf-expander
+             get-setf-expansion
+           type-error-expected-type
+                      export
+      function-lambda-expression
+                      expt
+          vector-push-extend
+                      extended-char
+              dynamic-extent
+               stream-external-format
+                   do-external-symbols
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_F.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_F.htm new file mode 100644 index 00000000..35257e84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_F.htm @@ -0,0 +1,162 @@ + + + +CLHS: Permuted Symbol Index (F) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (F)

    + +
    +                                 fboundp
+                                 fceiling
+                                 fdefinition
+                                *features*
+                                 ffloor
+                         deposit-field
+                            mask-field
+                                 fifth
+                         compile-file
+                          delete-file
+                          end-of-file
+                           probe-file
+                          rename-file
+                       with-open-file
+                                 file-author
+                                 file-error
+                                 file-error-pathname
+                                 file-length
+                                 file-namestring
+                         compile-file-pathname
+                        *compile-file-pathname*
+                                 file-position
+                                 file-stream
+                                 file-string-length
+                        *compile-file-truename*
+                                 file-write-date
+                                 fill
+                          pprint-fill
+                                 fill-pointer
+                       array-has-fill-pointer-p
+                                 find
+                                 find-all-symbols
+                                 find-class
+                                 find-if
+                                 find-if-not
+                                 find-method
+                                 find-package
+                                 find-restart
+                                 find-symbol
+                            loop-finish
+                                 finish-output
+                                 first
+                                 fixnum
+                   most-negative-fixnum
+                   most-positive-fixnum
+                                 flet
+                          decode-float
+                          double-float
+                                 float
+                  integer-decode-float
+           least-negative-double-float
+             least-negative-long-float
+least-negative-normalized-double-float
+  least-negative-normalized-long-float
+ least-negative-normalized-short-float
+least-negative-normalized-single-float
+            least-negative-short-float
+           least-negative-single-float
+           least-positive-double-float
+             least-positive-long-float
+least-positive-normalized-double-float
+  least-positive-normalized-long-float
+ least-positive-normalized-short-float
+least-positive-normalized-single-float
+            least-positive-short-float
+           least-positive-single-float
+                            long-float
+            most-negative-double-float
+              most-negative-long-float
+             most-negative-short-float
+            most-negative-single-float
+            most-positive-double-float
+              most-positive-long-float
+             most-positive-short-float
+            most-positive-single-float
+                           scale-float
+                           short-float
+                          single-float
+                                 float-digits
+                          double-float-epsilon
+                            long-float-epsilon
+                           short-float-epsilon
+                          single-float-epsilon
+                   *read-default-float-format*
+                          double-float-negative-epsilon
+                            long-float-negative-epsilon
+                           short-float-negative-epsilon
+                          single-float-negative-epsilon
+                                 float-precision
+                                 float-radix
+                                 float-sign
+                                 floating-point-inexact
+                                 floating-point-invalid-operation
+                                 floating-point-overflow
+                                 floating-point-underflow
+                                 floatp
+                                 floor
+                                 fmakunbound
+                 update-instance-for-different-class
+                 update-instance-for-redefined-class
+                                 force-output
+                       make-load-form
+                       make-load-form-saving-slots
+                                 format
+                 stream-external-format
+             *read-default-float-format*
+                simple-condition-format-arguments
+                simple-condition-format-control
+                                 formatter
+                                 fourth
+                                 fresh-line
+                          return-from
+                      set-syntax-from-char
+                            read-from-string
+                      with-input-from-string
+                                 fround
+                                 ftruncate
+                                 ftype
+                                 funcall
+                        compiled-function
+                  compiler-macro-function
+                  ensure-generic-function
+                                 function
+                         generic-function
+                           macro-function
+                standard-generic-function
+                          symbol-function
+                       undefined-function
+                                 function-keywords
+                                 function-lambda-expression
+                        compiled-function-p
+                                 functionp
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_G.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_G.htm new file mode 100644 index 00000000..c18a0831 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_G.htm @@ -0,0 +1,56 @@ + + + +CLHS: Permuted Symbol Index (G) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (G)

    + +
    +           gcd
+    ensure-generic-function
+           generic-function
+  standard-generic-function
+           gensym
+    *print-gensym*
+          *gensym-counter*
+           gentemp
+           get
+           get-decoded-time
+           get-dispatch-macro-character
+           get-internal-real-time
+           get-internal-run-time
+           get-macro-character
+           get-output-stream-string
+           get-properties
+           get-setf-expansion
+           get-universal-time
+           getf
+           gethash
+           go
+           graphic-char-p
+      char-greaterp
+  char-not-greaterp
+    string-greaterp
+string-not-greaterp
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_H.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_H.htm new file mode 100644 index 00000000..5cdbace6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_H.htm @@ -0,0 +1,48 @@ + + + +CLHS: Permuted Symbol Index (H) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (H)

    + +
    +             handler-bind
+             handler-case
+read-char-no-hang
+       array-has-fill-pointer-p
+             hash-table
+        make-hash-table
+             hash-table-count
+        with-hash-table-iterator
+             hash-table-p
+             hash-table-rehash-size
+             hash-table-rehash-threshold
+             hash-table-size
+             hash-table-test
+        user-homedir-pathname
+   *debugger-hook*
+*macroexpand-hook*
+    pathname-host
+             host-namestring
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_I.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_I.htm new file mode 100644 index 00000000..3df42f3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_I.htm @@ -0,0 +1,120 @@ + + + +CLHS: Permuted Symbol Index (I) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (I)

    + +
    +                identity
+          assoc-if
+          count-if
+         delete-if
+           find-if
+                if
+         member-if
+         nsubst-if
+    nsubstitute-if
+       position-if
+         rassoc-if
+         remove-if
+          subst-if
+     substitute-if
+    pprint-exit-if-list-exhausted
+          assoc-if-not
+          count-if-not
+         delete-if-not
+           find-if-not
+         member-if-not
+         nsubst-if-not
+    nsubstitute-if-not
+       position-if-not
+         rassoc-if-not
+         remove-if-not
+          subst-if-not
+     substitute-if-not
+                ignorable
+                ignore
+                ignore-errors
+                imagpart
+           lisp-implementation-type
+           lisp-implementation-version
+                import
+      shadowing-import
+          array-in-bounds-p
+          built-in-class
+                in-package
+                incf
+         pprint-indent
+array-row-major-index
+ floating-point-inexact
+         shared-initialize
+                initialize-instance
+                inline
+          clear-input
+      *standard-input*
+           with-input-from-string
+    echo-stream-input-stream
+    make-string-input-stream
+ two-way-stream-input-stream
+                input-stream-p
+                inspect
+       allocate-instance
+     initialize-instance
+        machine-instance
+           make-instance
+   reinitialize-instance
+   unbound-slot-instance
+         update-instance-for-different-class
+         update-instance-for-redefined-class
+           make-instances-obsolete
+           char-int
+                integer
+          parse-integer
+                integer-decode-float
+                integer-length
+                integerp
+                interactive-stream-p
+ invoke-restart-interactively
+                intern
+            get-internal-real-time
+            get-internal-run-time
+                internal-time-units-per-second
+                intersection
+            map-into
+                invalid-method-error
+ floating-point-invalid-operation
+                invoke-debugger
+                invoke-restart
+                invoke-restart-interactively
+         *debug-io*
+         *query-io*
+      *terminal-io*
+  with-standard-io-syntax
+            bit-ior
+          boole-ior
+                isqrt
+with-hash-table-iterator
+   with-package-iterator
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_K.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_K.htm new file mode 100644 index 00000000..44406a03 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_K.htm @@ -0,0 +1,36 @@ + + + +CLHS: Permuted Symbol Index (K) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (K)

    + +
    +            &key
+&allow-other-keys
+             keyword
+             keywordp
+    function-keywords
+ lambda-list-keywords
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_L.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_L.htm new file mode 100644 index 00000000..9022cfb8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_L.htm @@ -0,0 +1,143 @@ + + + +CLHS: Permuted Symbol Index (L) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (L)

    + +
    +                          labels
+                          lambda
+                 function-lambda-expression
+                          lambda-list-keywords
+                          lambda-parameters-limit
+                          last
+                          lcm
+                          ldb
+                          ldb-test
+                          ldiff
+                          least-negative-double-float
+                          least-negative-long-float
+                          least-negative-normalized-double-float
+                          least-negative-normalized-long-float
+                          least-negative-normalized-short-float
+                          least-negative-normalized-single-float
+                          least-negative-short-float
+                          least-negative-single-float
+                          least-positive-double-float
+                          least-positive-long-float
+                          least-positive-normalized-double-float
+                          least-positive-normalized-long-float
+                          least-positive-normalized-short-float
+                          least-positive-normalized-single-float
+                          least-positive-short-float
+                          least-positive-single-float
+                   string-left-trim
+                     file-length
+              file-string-length
+                  integer-length
+                          length
+                     list-length
+                   *print-length*
+                     char-lessp
+                 char-not-lessp
+                   string-lessp
+               string-not-lessp
+                          let
+                          let*
+                   *print-level*
+          array-dimension-limit
+               array-rank-limit
+         array-total-size-limit
+           call-arguments-limit
+                char-code-limit
+        lambda-parameters-limit
+          multiple-values-limit
+                    fresh-line
+                     read-line
+                    write-line
+                   pprint-linear
+                   *print-lines*
+                          lisp-implementation-type
+                          lisp-implementation-version
+                  apropos-list
+                     copy-list
+                          list
+                     make-list
+           multiple-value-list
+              package-use-list
+          package-used-by-list
+           read-delimited-list
+                   values-list
+                          list*
+                          list-all-packages
+           pprint-exit-if-list-exhausted
+                   lambda-list-keywords
+                          list-length
+                          listen
+                          listp
+                          load
+                     make-load-form
+                     make-load-form-saving-slots
+                          load-logical-pathname-translations
+                         *load-pathname*
+                         *load-print*
+                          load-time-value
+                         *load-truename*
+                         *load-verbose*
+                          locally
+                          log
+                          logand
+                          logandc1
+                          logandc2
+                          logbitp
+                          logcount
+                          logeqv
+                   pprint-logical-block
+                          logical-pathname
+                translate-logical-pathname
+                     load-logical-pathname-translations
+                          logical-pathname-translations
+                          logior
+                          lognand
+                          lognor
+                          lognot
+                          logorc1
+                          logorc2
+                          logtest
+                          logxor
+           least-negative-long-float
+least-negative-normalized-long-float
+           least-positive-long-float
+least-positive-normalized-long-float
+                          long-float
+            most-negative-long-float
+            most-positive-long-float
+                          long-float-epsilon
+                          long-float-negative-epsilon
+                          long-site-name
+                          loop
+                          loop-finish
+                          lower-case-p
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_M.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_M.htm new file mode 100644 index 00000000..f88583e1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_M.htm @@ -0,0 +1,136 @@ + + + +CLHS: Permuted Symbol Index (M) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (M)

    + +
    +                   machine-instance
+                   machine-type
+                   machine-version
+          compiler-macro
+   define-compiler-macro
+     define-modify-macro
+     define-symbol-macro
+      get-dispatch-macro-character
+               get-macro-character
+     make-dispatch-macro-character
+      set-dispatch-macro-character
+               set-macro-character
+          compiler-macro-function
+                   macro-function
+                   macroexpand
+                   macroexpand-1
+                  *macroexpand-hook*
+                   macrolet
+            symbol-macrolet
+               row-major-aref
+         array-row-major-index
+                   make-array
+                   make-broadcast-stream
+                   make-concatenated-stream
+                   make-condition
+                   make-dispatch-macro-character
+                   make-echo-stream
+                   make-hash-table
+                   make-instance
+                   make-instances-obsolete
+                   make-list
+                   make-load-form
+                   make-load-form-saving-slots
+                   make-method
+                   make-package
+                   make-pathname
+                   make-random-state
+                   make-sequence
+                   make-string
+                   make-string-input-stream
+                   make-string-output-stream
+                   make-symbol
+                   make-synonym-stream
+                   make-two-way-stream
+                   makunbound
+              slot-makunbound
+                   map
+                   map-into
+                   mapc
+                   mapcan
+                   mapcar
+                   mapcon
+                   maphash
+                   mapl
+                   maplist
+      *print-right-margin*
+                   mask-field
+          pathname-match-p
+                   max
+                   member
+                   member-if
+                   member-if-not
+                   merge
+                   merge-pathnames
+               add-method
+              call-method
+         call-next-method
+              find-method
+              make-method
+                   method
+     no-applicable-method
+           no-next-method
+            remove-method
+          standard-method
+            define-method-combination
+                   method-combination
+                   method-combination-error
+           invalid-method-error
+              next-method-p
+                   method-qualifiers
+compute-applicable-methods
+                   min
+                   minusp
+            *print-miser-width*
+                   mismatch
+              slot-missing
+                   mod
+            define-modify-macro
+                  *modules*
+                   most-negative-double-float
+                   most-negative-fixnum
+                   most-negative-long-float
+                   most-negative-short-float
+                   most-negative-single-float
+                   most-positive-double-float
+                   most-positive-fixnum
+                   most-positive-long-float
+                   most-positive-short-float
+                   most-positive-single-float
+                   muffle-warning
+                   multiple-value-bind
+                   multiple-value-call
+                   multiple-value-list
+                   multiple-value-prog1
+                   multiple-value-setq
+                   multiple-values-limit
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_N.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_N.htm new file mode 100644 index 00000000..fcc3ce59 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_N.htm @@ -0,0 +1,137 @@ + + + +CLHS: Permuted Symbol Index (N) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (N)

    + +
    +          y-or-n-p
+    cell-error-name
+          char-name
+         class-name
+     long-site-name
+       package-name
+       restart-name
+    short-site-name
+        symbol-name
+               name-char
+           pathname-name
+     directory-namestring
+        enough-namestring
+          file-namestring
+          host-namestring
+               namestring
+         parse-namestring
+           bit-nand
+         boole-nand
+               nbutlast
+               nconc
+         least-negative-double-float
+          most-negative-double-float
+  double-float-negative-epsilon
+    long-float-negative-epsilon
+   short-float-negative-epsilon
+  single-float-negative-epsilon
+          most-negative-fixnum
+         least-negative-long-float
+          most-negative-long-float
+         least-negative-normalized-double-float
+         least-negative-normalized-long-float
+         least-negative-normalized-short-float
+         least-negative-normalized-single-float
+         least-negative-short-float
+          most-negative-short-float
+         least-negative-single-float
+          most-negative-single-float
+        pprint-newline
+          call-next-method
+            no-next-method
+               next-method-p
+       package-nicknames
+               nil
+               nintersection
+               ninth
+               no-applicable-method
+     read-char-no-hang
+               no-next-method
+        yes-or-no-p
+           bit-nor
+         boole-nor
+least-negative-normalized-double-float
+least-positive-normalized-double-float
+least-negative-normalized-long-float
+least-positive-normalized-long-float
+least-negative-normalized-short-float
+least-positive-normalized-short-float
+least-negative-normalized-single-float
+least-positive-normalized-single-float
+      assoc-if-not
+           bit-not
+      count-if-not
+     delete-if-not
+       find-if-not
+     member-if-not
+               not
+     nsubst-if-not
+nsubstitute-if-not
+   position-if-not
+     rassoc-if-not
+     remove-if-not
+      subst-if-not
+ substitute-if-not
+          char-not-equal
+        string-not-equal
+          char-not-greaterp
+        string-not-greaterp
+          char-not-lessp
+        string-not-lessp
+         print-not-readable
+         print-not-readable-object
+               notany
+               notevery
+               notinline
+               nreconc
+               nreverse
+               nset-difference
+               nset-exclusive-or
+               nstring-capitalize
+               nstring-downcase
+               nstring-upcase
+               nsublis
+               nsubst
+               nsubst-if
+               nsubst-if-not
+               nsubstitute
+               nsubstitute-if
+               nsubstitute-if-not
+               nth
+               nth-value
+               nthcdr
+               null
+               number
+               numberp
+               numerator
+               nunion
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_O.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_O.htm new file mode 100644 index 00000000..4e4ff602 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_O.htm @@ -0,0 +1,76 @@ + + + +CLHS: Permuted Symbol Index (O) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (O)

    + +
    +              describe-object
+    print-not-readable-object
+                 print-object
+      print-unreadable-object
+              standard-object
+             structure-object
+        make-instances-obsolete
+                       oddp
+                 class-of
+                  type-of
+                   end-of-file
+                *break-on-signals*
+                       open
+                  with-open-file
+                  with-open-stream
+                       open-stream-p
+      arithmetic-error-operands
+      arithmetic-error-operation
+floating-point-invalid-operation
+               special-operator-p
+                       optimize
+                      &optional
+        nset-exclusive-or
+                       or
+         set-exclusive-or
+                     y-or-n-p
+                   yes-or-no-p
+                   bit-orc1
+                 boole-orc1
+                   bit-orc2
+                 boole-orc2
+                &allow-other-keys
+                       otherwise
+                 clear-output
+                finish-output
+                 force-output
+                *error-output*
+             *standard-output*
+                *trace-output*
+           echo-stream-output-stream
+           make-string-output-stream
+        two-way-stream-output-stream
+                       output-stream-p
+                   get-output-stream-string
+                  with-output-to-string
+        floating-point-overflow
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_P.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_P.htm new file mode 100644 index 00000000..f734fd26 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_P.htm @@ -0,0 +1,219 @@ + + + +CLHS: Permuted Symbol Index (P) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (P)

    + +
    +      adjustable-array-p
+            alpha-char-p
+array-has-fill-pointer-p
+       array-in-bounds-p
+            bit-vector-p
+             both-case-p
+     compiled-function-p
+            digit-char-p
+          graphic-char-p
+            hash-table-p
+          input-stream-p
+    interactive-stream-p
+            lower-case-p
+           next-method-p
+           open-stream-p
+         output-stream-p
+                packagep
+        pathname-match-p
+               pathnamep
+                   plusp
+                     pop
+              pprint-pop
+          random-state-p
+     simple-bit-vector-p
+         simple-string-p
+         simple-vector-p
+           slot-exists-p
+      special-operator-p
+         standard-char-p
+            upper-case-p
+         wild-pathname-p
+                y-or-n-p
+             yes-or-no-p
+                delete-package
+                  find-package
+                    in-package
+                  make-package
+                       package
+         package-error-package
+                rename-package
+                symbol-package
+                 unuse-package
+                   use-package
+                      *package*
+                       package-error
+                       package-error-package
+                  with-package-iterator
+                       package-name
+                       package-nicknames
+                       package-shadowing-symbols
+                       package-use-list
+                       package-used-by-list
+                       packagep
+              list-all-packages
+                       pairlis
+                lambda-parameters-limit
+                       parse-error
+                       parse-integer
+                       parse-namestring
+      upgraded-complex-part-type
+             pprint-dispatch
+          compile-file-pathname
+            file-error-pathname
+               logical-pathname
+                  make-pathname
+                       pathname
+     translate-logical-pathname
+             translate-pathname
+          user-homedir-pathname
+         *compile-file-pathname*
+                 *load-pathname*
+              *default-pathname-defaults*
+                       pathname-device
+                       pathname-directory
+                       pathname-host
+                       pathname-match-p
+                       pathname-name
+                  wild-pathname-p
+          load-logical-pathname-translations
+               logical-pathname-translations
+                       pathname-type
+                       pathname-version
+                       pathnamep
+                 merge-pathnames
+            pathname-type
+                       peek-char
+   internal-time-units-per-second
+                       phase
+                       pi
+                symbol-plist
+                       plusp
+              floating-point-inexact
+              floating-point-invalid-operation
+              floating-point-overflow
+              floating-point-underflow
+                  fill-pointer
+        array-has-fill-pointer-p
+                       pop
+                pprint-pop
+                vector-pop
+                  byte-position
+                  file-position
+                       position
+                       position-if
+                       position-if-not
+                 least-positive-double-float
+                  most-positive-double-float
+                  most-positive-fixnum
+                 least-positive-long-float
+                  most-positive-long-float
+                 least-positive-normalized-double-float
+                 least-positive-normalized-long-float
+                 least-positive-normalized-short-float
+                 least-positive-normalized-single-float
+                 least-positive-short-float
+                  most-positive-short-float
+                 least-positive-single-float
+                  most-positive-single-float
+                       pprint
+                  copy-pprint-dispatch
+                       pprint-dispatch
+                   set-pprint-dispatch
+                *print-pprint-dispatch*
+                       pprint-exit-if-list-exhausted
+                       pprint-fill
+                       pprint-indent
+                       pprint-linear
+                       pprint-logical-block
+                       pprint-newline
+                       pprint-pop
+                       pprint-tab
+                       pprint-tabular
+                 float-precision
+                  read-preserving-whitespace
+                *print-pretty*
+                       prin1
+                       prin1-to-string
+                       princ
+                       princ-to-string
+                      pprint
+                       print
+              *compile-print*
+                 *load-print*
+                      *print-array*
+                      *print-base*
+                      *print-case*
+                      *print-circle*
+                      *print-escape*
+                      pprint-exit-if-list-exhausted
+                      pprint-fill
+                      *print-gensym*
+                      pprint-indent
+                      *print-length*
+                      *print-level*
+                      pprint-linear
+                      *print-lines*
+                      pprint-logical-block
+                      *print-miser-width*
+                      pprint-newline
+                       print-not-readable
+                       print-not-readable-object
+                       print-object
+                      *print-pprint-dispatch*
+                      *print-pretty*
+                      *print-radix*
+                      *print-readably*
+                      *print-right-margin*
+                      pprint-tab
+                      pprint-tabular
+                       print-unreadable-object
+                       probe-file
+                       proclaim
+                       prog
+                       prog*
+        multiple-value-prog1
+                       prog1
+                       prog2
+                       progn
+                       program-error
+                       progv
+                   get-properties
+                unwind-protect
+                       provide
+                       psetf
+                       psetq
+                       push
+                vector-push
+                vector-push-extend
+                       pushnew
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Q.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Q.htm new file mode 100644 index 00000000..b2ec896e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Q.htm @@ -0,0 +1,33 @@ + + + +CLHS: Permuted Symbol Index (Q) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (Q)

    + +
    +method-qualifiers
+      *query-io*
+       quote
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_R.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_R.htm new file mode 100644 index 00000000..fddc138e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_R.htm @@ -0,0 +1,116 @@ + + + +CLHS: Permuted Symbol Index (R) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (R)

    + +
    +              float-radix
+             *print-radix*
+                    random
+               make-random-state
+                    random-state
+                   *random-state*
+                    random-state-p
+              array-rank
+              array-rank-limit
+                    rassoc
+                    rassoc-if
+                    rassoc-if-not
+                    ratio
+                    rational
+                    rationalize
+                    rationalp
+                    read
+                   *read-base*
+                    read-byte
+                    read-char
+                    read-char-no-hang
+                   *read-default-float-format*
+                    read-delimited-list
+                   *read-eval*
+                    read-from-string
+                    read-line
+                    read-preserving-whitespace
+                    read-sequence
+                   *read-suppress*
+          print-not-readable
+          print-not-readable-object
+             *print-readably*
+                    reader-error
+               copy-readtable
+                    readtable
+                   *readtable*
+                    readtable-case
+                    readtablep
+                    real
+       get-internal-real-time
+                    realp
+                    realpart
+update-instance-for-redefined-class
+                    reduce
+         hash-table-rehash-size
+         hash-table-rehash-threshold
+                    reinitialize-instance
+                    rem
+                    remf
+                    remhash
+                    remove
+                    remove-duplicates
+                    remove-if
+                    remove-if-not
+                    remove-method
+                    remprop
+                    rename-file
+                    rename-package
+                    replace
+                    require
+                   &rest
+                    rest
+               find-restart
+             invoke-restart
+                    restart
+        with-simple-restart
+                    restart-bind
+                    restart-case
+             invoke-restart-interactively
+                    restart-name
+            compute-restarts
+     with-condition-restarts
+                    return
+                    return-from
+                    revappend
+                    reverse
+             *print-right-margin*
+             string-right-trim
+                    room
+                    rotatef
+                    round
+                    row-major-aref
+              array-row-major-index
+                    rplaca
+                    rplacd
+       get-internal-run-time
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_S.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_S.htm new file mode 100644 index 00000000..ebb16cb5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_S.htm @@ -0,0 +1,266 @@ + + + +CLHS: Permuted Symbol Index (S) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (S)

    + +
    +                          safety
+                          satisfies
+           make-load-form-saving-slots
+                          sbit
+                          scale-float
+                          schar
+                          search
+  internal-time-units-per-second
+                          second
+                     copy-seq
+                     make-sequence
+                     read-sequence
+                          sequence
+                    write-sequence
+                          serious-condition
+                    boole-set
+                          set
+                          set-difference
+                          set-dispatch-macro-character
+                          set-exclusive-or
+                          set-macro-character
+                          set-pprint-dispatch
+                          set-syntax-from-char
+                          setf
+                   define-setf-expander
+                      get-setf-expansion
+           multiple-value-setq
+                          setq
+                          seventh
+                          shadow
+                          shadowing-import
+                  package-shadowing-symbols
+                          shared-initialize
+                          shiftf
+least-negative-normalized-short-float
+           least-negative-short-float
+least-positive-normalized-short-float
+           least-positive-short-float
+            most-negative-short-float
+            most-positive-short-float
+                          short-float
+                          short-float-epsilon
+                          short-float-negative-epsilon
+                          short-site-name
+                    float-sign
+                          signal
+                *break-on-signals*
+                          signed-byte
+                          signum
+                          simple-array
+                          simple-base-string
+                          simple-bit-vector
+                          simple-bit-vector-p
+                          simple-condition
+                          simple-condition-format-arguments
+                          simple-condition-format-control
+                          simple-error
+                     with-simple-restart
+                          simple-string
+                          simple-string-p
+                          simple-type-error
+                          simple-vector
+                          simple-vector-p
+                          simple-warning
+                          sin
+least-negative-normalized-single-float
+           least-negative-single-float
+least-positive-normalized-single-float
+           least-positive-single-float
+            most-negative-single-float
+            most-positive-single-float
+                          single-float
+                          single-float-epsilon
+                          single-float-negative-epsilon
+                          sinh
+                     long-site-name
+                    short-site-name
+                          sixth
+              array-total-size
+                     byte-size
+        hash-table-rehash-size
+               hash-table-size
+              array-total-size-limit
+                          sleep
+                  unbound-slot
+                          slot-boundp
+                          slot-exists-p
+                  unbound-slot-instance
+                          slot-makunbound
+                          slot-missing
+                          slot-unbound
+                          slot-value
+    make-load-form-saving-slots
+                     with-slots
+                          software-type
+                          software-version
+                          some
+                          sort
+                   stable-sort
+                          space
+                          special
+                          special-operator-p
+              compilation-speed
+                          speed
+                          sqrt
+                          stable-sort
+                          standard
+                          standard-char
+                          standard-char-p
+                          standard-class
+                          standard-generic-function
+                         *standard-input*
+                     with-standard-io-syntax
+                          standard-method
+                          standard-object
+                         *standard-output*
+              make-random-state
+                   random-state
+                  *random-state*
+                   random-state-p
+                          step
+                          storage-condition
+                          store-value
+                broadcast-stream
+             concatenated-stream
+                     echo-stream
+                     file-stream
+           make-broadcast-stream
+        make-concatenated-stream
+                make-echo-stream
+        make-string-input-stream
+       make-string-output-stream
+             make-synonym-stream
+             make-two-way-stream
+                          stream
+                   string-stream
+                  synonym-stream
+                  two-way-stream
+                with-open-stream
+                          stream-element-type
+                          stream-error
+                          stream-error-stream
+                          stream-external-format
+                     echo-stream-input-stream
+                  two-way-stream-input-stream
+                     echo-stream-output-stream
+                  two-way-stream-output-stream
+                    input-stream-p
+              interactive-stream-p
+                     open-stream-p
+                   output-stream-p
+                broadcast-stream-streams
+             concatenated-stream-streams
+               get-output-stream-string
+                  synonym-stream-symbol
+                          streamp
+         broadcast-stream-streams
+      concatenated-stream-streams
+                     base-string
+        get-output-stream-string
+                     make-string
+                 prin1-to-string
+                 princ-to-string
+                read-from-string
+              simple-base-string
+                   simple-string
+                          string
+          with-input-from-string
+           with-output-to-string
+                    write-string
+                 write-to-string
+                          string-capitalize
+                          string-downcase
+                          string-equal
+                          string-greaterp
+                     make-string-input-stream
+                          string-left-trim
+                     file-string-length
+                          string-lessp
+                          string-not-equal
+                          string-not-greaterp
+                          string-not-lessp
+                     make-string-output-stream
+                   simple-string-p
+                          string-right-trim
+                          string-stream
+                          string-trim
+                          string-upcase
+                          string/=
+                          string<
+                          string<=
+                          string=
+                          string>
+                          string>=
+                          stringp
+                     copy-structure
+                          structure
+                          structure-class
+                          structure-object
+                          style-warning
+                          sublis
+                          subseq
+                          subsetp
+                          subst
+                          subst-if
+                          subst-if-not
+                          substitute
+                          substitute-if
+                          substitute-if-not
+                          subtypep
+                    *read-suppress*
+                          svref
+                          sxhash
+                     copy-symbol
+                     find-symbol
+                     make-symbol
+                          symbol
+           synonym-stream-symbol
+                          symbol-function
+                   define-symbol-macro
+                          symbol-macrolet
+                          symbol-name
+                          symbol-package
+                          symbol-plist
+                          symbol-value
+                          symbolp
+                   do-all-symbols
+              do-external-symbols
+                       do-symbols
+                 find-all-symbols
+        package-shadowing-symbols
+                     make-synonym-stream
+                          synonym-stream
+                          synonym-stream-symbol
+         with-standard-io-syntax
+                      set-syntax-from-char
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_T.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_T.htm new file mode 100644 index 00000000..f2edf824 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_T.htm @@ -0,0 +1,106 @@ + + + +CLHS: Permuted Symbol Index (T) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (T)

    + +
    +                       t
+                pprint-tab
+                  hash-table
+             make-hash-table
+                  hash-table-count
+             with-hash-table-iterator
+                  hash-table-p
+                  hash-table-rehash-size
+                  hash-table-rehash-threshold
+                  hash-table-size
+                  hash-table-test
+                pprint-tabular
+                       tagbody
+                       tailp
+                       tan
+                       tanh
+                       tenth
+                      *terminal-io*
+                       terpri
+            hash-table-test
+                   ldb-test
+                       the
+                       third
+     hash-table-rehash-threshold
+                       throw
+      decode-universal-time
+      encode-universal-time
+           get-decoded-time
+     get-internal-real-time
+      get-internal-run-time
+         get-universal-time
+                       time
+              internal-time-units-per-second
+                  load-time-value
+                 prin1-to-string
+                 princ-to-string
+           with-output-to-string
+                 write-to-string
+                 array-total-size
+                 array-total-size-limit
+                       trace
+                      *trace-output*
+                       translate-logical-pathname
+                       translate-pathname
+ load-logical-pathname-translations
+      logical-pathname-translations
+                  copy-tree
+                       tree-equal
+           string-left-trim
+          string-right-trim
+                string-trim
+                       truename
+         *compile-file-truename*
+                 *load-truename*
+                       truncate
+                  make-two-way-stream
+                       two-way-stream
+                       two-way-stream-input-stream
+                       two-way-stream-output-stream
+         array-element-type
+                 check-type
+   lisp-implementation-type
+               machine-type
+              pathname-type
+              software-type
+        stream-element-type
+                       type
+upgraded-array-element-type
+ upgraded-complex-part-type
+                simple-type-error
+                       type-error
+                       type-error-datum
+                       type-error-expected-type
+                       type-of
+                       typecase
+                       typep
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_U.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_U.htm new file mode 100644 index 00000000..185c79e0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_U.htm @@ -0,0 +1,64 @@ + + + +CLHS: Permuted Symbol Index (U) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (U)

    + +
    +            slot-unbound
+                 unbound-slot
+                 unbound-slot-instance
+                 unbound-variable
+                 undefined-function
+  floating-point-underflow
+                 unexport
+                 unintern
+                 union
+with-compilation-unit
+   internal-time-units-per-second
+          decode-universal-time
+          encode-universal-time
+             get-universal-time
+                 unless
+                 unread-char
+           print-unreadable-object
+                 unsigned-byte
+                 untrace
+                 unuse-package
+                 unwind-protect
+            char-upcase
+         nstring-upcase
+          string-upcase
+                 update-instance-for-different-class
+                 update-instance-for-redefined-class
+                 upgraded-array-element-type
+                 upgraded-complex-part-type
+                 upper-case-p
+         package-use-list
+                 use-package
+                 use-value
+         package-used-by-list
+                 user-homedir-pathname
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_V.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_V.htm new file mode 100644 index 00000000..531a3a2a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_V.htm @@ -0,0 +1,63 @@ + + + +CLHS: Permuted Symbol Index (V) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (V)

    + +
    +          load-time-value
+                nth-value
+               slot-value
+              store-value
+             symbol-value
+                use-value
+           multiple-value-bind
+           multiple-value-call
+           multiple-value-list
+           multiple-value-prog1
+           multiple-value-setq
+                    values
+           multiple-values-limit
+                    values-list
+            unbound-variable
+                    variable
+                bit-vector
+         simple-bit-vector
+             simple-vector
+                    vector
+                bit-vector-p
+         simple-bit-vector-p
+             simple-vector-p
+                    vector-pop
+                    vector-push
+                    vector-push-extend
+                    vectorp
+           *compile-verbose*
+              *load-verbose*
+lisp-implementation-version
+            machine-version
+           pathname-version
+           software-version
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_W.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_W.htm new file mode 100644 index 00000000..d337925d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_W.htm @@ -0,0 +1,65 @@ + + + +CLHS: Permuted Symbol Index (W) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (W)

    + +
    +                warn
+         muffle-warning
+         simple-warning
+          style-warning
+                warning
+       make-two-way-stream
+            two-way-stream
+            two-way-stream-input-stream
+            two-way-stream-output-stream
+           eval-when
+                when
+read-preserving-whitespace
+               &whole
+   *print-miser-width*
+                wild-pathname-p
+                with-accessors
+                with-compilation-unit
+                with-condition-restarts
+                with-hash-table-iterator
+                with-input-from-string
+                with-open-file
+                with-open-stream
+                with-output-to-string
+                with-package-iterator
+                with-simple-restart
+                with-slots
+                with-standard-io-syntax
+                write
+                write-byte
+                write-char
+           file-write-date
+                write-line
+                write-sequence
+                write-string
+                write-to-string
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_X.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_X.htm new file mode 100644 index 00000000..cf68dc68 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_X.htm @@ -0,0 +1,32 @@ + + + +CLHS: Permuted Symbol Index (X) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (X)

    + +
    +  bit-xor
+boole-xor
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Y.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Y.htm new file mode 100644 index 00000000..c6d6387b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Y.htm @@ -0,0 +1,32 @@ + + + +CLHS: Permuted Symbol Index (Y) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (Y)

    + +
    +y-or-n-p
+yes-or-no-p
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Z.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Z.htm new file mode 100644 index 00000000..d7b13c55 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Perm_Z.htm @@ -0,0 +1,32 @@ + + + +CLHS: Permuted Symbol Index (Z) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + +

    Permuted Symbol Index (Z)

    + +
    +division-by-zero
+            zerop
+
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Symbol.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Symbol.htm similarity index 62% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Symbol.htm rename to clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Symbol.htm index 1256baf4..68b35267 100644 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Symbol.htm +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/X_Symbol.htm @@ -5,13 +5,13 @@ - - - - + + + + -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    @@ -27,8 +27,8 @@ There are 978 symbols in the COMMON-LISP package.

    A A permuted index includes each n-word entry up to n times, at points corresponding to the use of each word in the entry as the sort key. For example, a symbol FOO-BAR would occur twice, once under FOO and BAR. This allows you to use any word in the symbol's name to search for that symbol.

    A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | Non-Alphabetic

    -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/index.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/index.htm new file mode 100644 index 00000000..8f9290c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/index.htm @@ -0,0 +1,58 @@ + + + +Common Lisp HyperSpec (TM) + + + + + + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)]

    + +
    + +
    +Welcome to the Common Lisp HyperSpec.
    +I hope it serves your need.

    +--Kent Pitman, X3J13 Project Editor +

    + +
    + +[Starting Points] +Here are some useful starting points:

    + + [Highlights][Contents][Index][Symbols][Glossary][Issues] + +

    + +[Help] A text-only version of this cover sheet +is available. + + +

    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Front/index_tx.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/index_tx.htm new file mode 100644 index 00000000..bcef9924 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Front/index_tx.htm @@ -0,0 +1,46 @@ + + + +Common Lisp HyperSpec (TM) - text only + + + + + + + + + +

    [LISPWORKS] Common Lisp HyperSpec (TM)

    + +
    + +
    +Welcome to the Common Lisp HyperSpec.
    +I hope it serves your need.

    +--Kent Pitman, X3J13 Project Editor +

    + +
    + +Here are some useful starting points:

    + +

    + +A flashier version of this cover sheet +is available. + +
    + +Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    + + + diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/CLHS_Lg.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/CLHS_Lg.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/CLHS_Lg.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/CLHS_Lg.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/CLHS_Sm.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/CLHS_Sm.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/CLHS_Sm.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/CLHS_Sm.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Contents.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Contents.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Contents.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Contents.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Glossary.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Glossary.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Glossary.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Glossary.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Help.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Help.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Help.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Help.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Hilights.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Hilights.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Hilights.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Hilights.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Index.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Index.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Index.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Index.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Issues.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Issues.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Issues.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Issues.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/LWLarge.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/LWLarge.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/LWLarge.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/LWLarge.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/LWSmall.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/LWSmall.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/LWSmall.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/LWSmall.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Next.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Next.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Next.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Next.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/NoNext.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/NoNext.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/NoNext.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/NoNext.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/NoPrev.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/NoPrev.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/NoPrev.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/NoPrev.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/NoUp.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/NoUp.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/NoUp.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/NoUp.gif diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Prev.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Prev.gif similarity index 100% rename from clones/lisp/www.lispworks.com/documentation/HyperSpec/Graphics/Prev.gif rename to clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Prev.gif diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Quadrant.gif b/clones/lisp/HyperSpec-7-0/HyperSpec/Graphics/Quadrant.gif new file mode 100644 index 0000000000000000000000000000000000000000..ecd6e89641b0f0c644f4ad8362d8cdc21fa06ca5 GIT binary patch literal 1701 zcmV;W23q+?Nk%w1VNU_20Du4h|Ns90001li0000_0i^%{0{@JUsmtvTqnxzbi?iOm z`wxcVNS5Y_D!|IN?hD8AOxN~}=lag~{tpZaUx=ach)gP%%%*c#d`hR(s`ZM!MYG(l z_X`eh!{oC0jJA!_?6&(YUBl<}x}7G!>-T(gz7H5EIQ2J}6hQQa=(TA0ROslEfOP=Z z7^zr^S<`rlSG4dt1x9_^W#xC0xw% zTGT5#th`LC%Lmc$Qi!l0uy!UtLA>{q+^=5KU=~eSv{JKZOO^WihjHknq$+xb3To9= zz8@vCKEmqN&C4KN!!ki>whY>nWz#BI>o%@jvS8=hz00*O-o1P|>Fo;K<>AAt2$7a)GjSp|V&kr=3q~-O*ox|_6-=;g%NJI;eUO3c$S6)a_AL_3W9i|hZW398MA)Hcj8&9EDCGKn_27`Oi2=WceS&K2yKT7m}OSTDvGuV4Kpn%BQOo+t2h+<`eJ z!37g>T?!6A3~|H~Puyz2)FDi-!aizd>t6NR8zjC9C-$*iZPqrjVI{|vGQ%Uc9N5Zf z!R&2;8v`M89QJKHA-mj~mh)$K!Ry;@9cx;2du9dAbGxK4T@TG$we>XAb58qfhDx`A zC8PkurgXZrM`tPVTfJ@9ehD0?ridQ#nzBL2 zyzxCVpEYS1tC{`1!O7eBYTpAJK9qF*NWA$SqXMJ$<7aoh;l@`Jzxc~D-2G|in`?{! z)@^<4tDpT0s5Sv64|4?c)|BoCi~Ok%XU>2i$Pmc2^bL@LX{*xv4k!WTS?q8*`rvFZ zD4G9-28EANp=Ve~Arra=h9r}r`TAoq9G*mnoUx(*cz7!d+J=TI^P%^EcoiX@5Q)}N z;tZMiE-1E7iU}bi%c%GeC;#3Mi+C{N3c1)tE&dRU>an7QZZkz7y0C`CGUL#^*h0p^ z@q}}Xq3y`XJ0#u_kArbziq_brI;K#J$N^+!{5T>(^3i>STx1{{=}0<4GLno$Bqigd zNUX&|5r@g7=h)RL7+P`^o-_{mT7ff5NOF{U!rLmyVhL87!H|7w7P+QJDBi^`5z$!S zNN_o}xKYoSmjYKmCiw_b7R&6JUpm9`tGjPJi_AO!MrcP^M8zKcv(TrzB_^ z>r}#ua; + + +CLHS: Array + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Array issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CHA.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CHA.htm new file mode 100644 index 00000000..8cf0c50e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CHA.htm @@ -0,0 +1,77 @@ + + + +CLHS: Character + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Character issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CLO.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CLO.htm new file mode 100644 index 00000000..f2b547b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CLO.htm @@ -0,0 +1,79 @@ + + + +CLHS: Object System + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Object System issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COL.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COL.htm new file mode 100644 index 00000000..92075226 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COL.htm @@ -0,0 +1,65 @@ + + + +CLHS: List and Sequence + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    List and Sequence issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COM.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COM.htm new file mode 100644 index 00000000..39513706 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_COM.htm @@ -0,0 +1,227 @@ + + + +CLHS: Compiler + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Compiler issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CON.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CON.htm new file mode 100644 index 00000000..ca930d02 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_CON.htm @@ -0,0 +1,59 @@ + + + +CLHS: Condition + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Condition issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ENV.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ENV.htm new file mode 100644 index 00000000..a49328fa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ENV.htm @@ -0,0 +1,55 @@ + + + +CLHS: Programming Environment + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Programming Environment issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FIL.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FIL.htm new file mode 100644 index 00000000..9defba46 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FIL.htm @@ -0,0 +1,65 @@ + + + +CLHS: Pathname and File + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Pathname and File issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FUN.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FUN.htm new file mode 100644 index 00000000..510db414 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_FUN.htm @@ -0,0 +1,47 @@ + + + +CLHS: Function + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Function issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_IO.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_IO.htm new file mode 100644 index 00000000..624e86c1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_IO.htm @@ -0,0 +1,111 @@ + + + +CLHS: Stream and I/O + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Stream and I/O issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ITE.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ITE.htm new file mode 100644 index 00000000..c97ebe34 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_ITE.htm @@ -0,0 +1,47 @@ + + + +CLHS: Iteration + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Iteration issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_MIS.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_MIS.htm new file mode 100644 index 00000000..e0bbf66c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_MIS.htm @@ -0,0 +1,69 @@ + + + +CLHS: Miscellaneous + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Miscellaneous issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_NUM.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_NUM.htm new file mode 100644 index 00000000..30f25b9a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_NUM.htm @@ -0,0 +1,49 @@ + + + +CLHS: Number + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Number issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_STR.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_STR.htm new file mode 100644 index 00000000..c011aa8c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_STR.htm @@ -0,0 +1,57 @@ + + + +CLHS: Structure + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Structure issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYM.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYM.htm new file mode 100644 index 00000000..0859ef04 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYM.htm @@ -0,0 +1,65 @@ + + + +CLHS: Symbol and Package + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Symbol and Package issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYN.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYN.htm new file mode 100644 index 00000000..4ab6eac2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_SYN.htm @@ -0,0 +1,81 @@ + + + +CLHS: Syntax + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Syntax issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TAB.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TAB.htm new file mode 100644 index 00000000..ae2dd83e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TAB.htm @@ -0,0 +1,39 @@ + + + +CLHS: Hash Table + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Hash Table issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TYP.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TYP.htm new file mode 100644 index 00000000..d329ae33 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/IC_TYP.htm @@ -0,0 +1,43 @@ + + + +CLHS: Type System + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Type System issues

    + +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Alpha.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Alpha.htm new file mode 100644 index 00000000..4a2d1a22 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Alpha.htm @@ -0,0 +1,758 @@ + + + +CLHS: Issue Index (Alphabetic) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +Alphabetical index of X3J13 issues:

    +

    +A listing of X3J13 issues organized by category is also available.

    +

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Categ.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Categ.htm new file mode 100644 index 00000000..a40001e6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/I_Categ.htm @@ -0,0 +1,64 @@ + + + +CLHS: Issue Index (Categorized) + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + +

    Issue Index

    +

    +An alphabetical listing of X3J13 issues is also available.

    +

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001.htm new file mode 100644 index 00000000..bd801e99 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue &ENVIRONMENT-BINDING-ORDER:FIRST Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue &ENVIRONMENT-BINDING-ORDER:FIRST Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue &ENVIRONMENT-BINDING-ORDER:FIRST:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001_w.htm new file mode 100644 index 00000000..efb3656c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss001_w.htm @@ -0,0 +1,133 @@ + + + +CLHS: Issue &ENVIRONMENT-BINDING-ORDER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue &ENVIRONMENT-BINDING-ORDER Writeup

    + +
    Status: Proposal FIRST passed, Nov 89 X3J13
    
+
    
+Forum:		Cleanup
    
+Issue:		&ENVIRONMENT-BINDING-ORDER
    
+References:	CLtL p. 145-146, 63
    
+                Issue DEFMACRO-LAMBDA-LIST
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 24 Oct 1989, Sandra Loosemore
    
+		V3, 02 Nov 1989, Sandra Loosemore (comments from Moon)
    
+
    
+
    
+Problem Description:
    
+
    
+Issue DEFMACRO-LAMBDA-LIST states that &ENVIRONMENT can appear once
    
+anywhere at top level of a macro lambda list, but doesn't say anything
    
+about the order in which the &ENVIRONMENT variable is bound relative
    
+to the other lambda-list variables.
    
+
    
+Some implementations treat &ENVIRONMENT as a mechanism for naming the
    
+second argument to the macro function, in which case it is bound
    
+before any of the variables in the actual destructuring pattern.
    
+Other implementations bind it with the other lambda parameters in the
    
+usual left-to-right order.
    
+
    
+The binding order of &WHOLE parameters is not an issue.  This is
    
+because a &WHOLE parameter must appear first in the lambda list, so
    
+there is no difference between binding it first or binding it
    
+left-to-right.  The relative binding order of &WHOLE and &ENVIRONMENT
    
+parameters is not an issue because neither one can include init forms
    
+where the binding of the other might be visible.
    
+
    
+There are two proposals, FIRST and LEFT-TO-RIGHT.
    
+
    
+
    
+Proposal (&ENVIRONMENT-BINDING-ORDER:FIRST):
    
+
    
+Clarify that the &ENVIRONMENT parameter is bound along with &WHOLE
    
+before any of other variables in the lambda list, regardless of where
    
+&ENVIRONMENT appears in the lambda list.
    
+
    
+  Rationale:
    
+
    
+  This proposal provides a convenient explanation for the special
    
+  treatment of &WHOLE and &ENVIRONMENT at top-level in a DEFMACRO-style
    
+  lambda list.  Basically, these two parameters are stripped out and
    
+  used to name the two arguments to the macro function, then the binding
    
+  of the remaining arguments is handled exactly the same as at
    
+  non-top-level or in a DESTRUCTURING-BIND.  It is also very
    
+  straightforward to implement this model (as opposed to having
    
+  special parsing code for destructuring top-level DEFMACRO lambda
    
+  lists).
    
+
    
+
    
+Proposal (&ENVIRONMENT-BINDING-ORDER:LEFT-TO-RIGHT):
    
+
    
+Clarify that the all lambda variables in a DEFMACRO-style lambda list
    
+are bound left-to-right, including the &WHOLE and &ENVIRONMENT parameters.
    
+
    
+  Rationale:
    
+
    
+  This is more consistent with the order in which variables in ordinary 
    
+  lambda lists are bound.
    
+
    
+
    
+Current Practice:
    
+
    
+Lucid CL, Utah CL, and KCL implement proposal FIRST.  CMU CL
    
+implements proposal LEFT-TO-RIGHT.
    
+
    
+Symbolics Genera implements proposal FIRST.  Specifically, &WHOLE is
    
+bound first, followed by &ENVIRONMENT, then the destructuring
    
+variables in the order listed.
    
+
    
+
    
+Cost to implementors:
    
+
    
+The changes are probably localized but potentially hairy.  It is
    
+possible that in some implementations it might be easier to completely
    
+replace the code which handles lambda-list parsing and destructuring
    
+than to try to patch it.  Proposal FIRST is probably easier to
    
+implement initially but the cost of converting an existing
    
+implementation is probably about the same for both proposals.
    
+
    
+
    
+Cost to users:
    
+
    
+There are probably few user programs that would be affected by a
    
+change in the binding order of &ENVIRONMENT parameters.
    
+
    
+
    
+Benefits:
    
+
    
+The language specification is made more precise.
    
+
    
+
    
+Discussion:
    
+
    
+Moon says:
    
+  I believe LEFT-TO-RIGHT is more clean, but I don't have strong feelings.
    
+  I am equally in favor of either of the two presented proposals or an
    
+  EXPLICITLY-VAGUE proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002.htm new file mode 100644 index 00000000..46cef601 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue ACCESS-ERROR-NAME Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ACCESS-ERROR-NAME Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ACCESS-ERROR-NAME:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002_w.htm new file mode 100644 index 00000000..efca242f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss002_w.htm @@ -0,0 +1,59 @@ + + + +CLHS: Issue ACCESS-ERROR-NAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ACCESS-ERROR-NAME Writeup

    + +
    Issue: ACCESS-ERROR-NAME
    
+Edit history: no proposal circulated prior to meeting
    
+
    
+
    
+  David Moon moved, and Dick Gabriel seconded, to
    
+  Eliminate
    
+    (OR (FIND-SYMBOL "CELL-ERROR"
    
+                     (FIND-PACKAGE
    
+                         "COMMON-LISP"))
    
+        (FIND-SYMBOL "ACCESS-ERROR"
    
+                     (FIND-PACKAGE
    
+                         "COMMON-LISP")))
    
+
    
+    Ditto for CELL-ERROR-NAME and/or
    
+              ACCESS-ERROR-NAME
    
+
    
+    Introduce UNBOUND-VARIABLE-NAME,
    
+              UNDEFINED-FUNCTION-NAME,
    
+              UNBOUND-SLOT-NAME.
    
+
    
+  The amendment passed 9-8.
    
+
    
+  Straw vote showed that one person felt strongly about their vote.
    
+
    
+  Larry moved, and Dan seconded, to roll back the previous motion to
    
+  CELL-ERROR.  The motion passed 12-5.
    
+
    
+/n
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003.htm new file mode 100644 index 00000000..9390d0b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ADJUST-ARRAY-DISPLACEMENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ADJUST-ARRAY-DISPLACEMENT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ADJUST-ARRAY-DISPLACEMENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003_w.htm new file mode 100644 index 00000000..d41c2280 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss003_w.htm @@ -0,0 +1,128 @@ + + + +CLHS: Issue ADJUST-ARRAY-DISPLACEMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ADJUST-ARRAY-DISPLACEMENT Writeup

    + +
    Issue:        ADJUST-ARRAY-DISPLACEMENT
    
+Reference:    ADJUST-ARRAY (CLtL p.297)
    
+Category:     Clarification
    
+Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
    
+              Version 2 by Masinter
    
+              Version 3 by Masinter, 5-Jun-87 (respond to comments)
    
+              Version 4 by Masinter, 23-Nov-87
    
+
    
+Problem Description:
    
+
    
+The interaction of ADJUST-ARRAY and displaced arrays is insufficiently specified
    
+in the case where the array being adjusted is displaced.  
    
+
    
+Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
    
+
    
+Interaction of adjusting and displacement:
    
+
    
+Suppose we are adjusting array A, which is perhaps displaced to B before the
    
+ADJUST-ARRAY call and perhaps to C after the call.
    
+
    
+(1) A is not displaced before or after: The dimensions of A are altered, and the
    
+contents rearranged as appropriate.  Additional elements of A are taken from the
    
+:INITIAL-ELEMENT.  The use of :INITIAL-CONTENTS causes all old contents to be
    
+discarded.
    
+
    
+(2) A is not displaced before, but is displaced to C after.  As specified in
    
+CLtL, none of the original contents of A appears in A afterwards; A now contains
    
+the contents of C, without any rearrangement of C.
    
+
    
+(3) A is displaced to B before the call, and is displaced to C after the call.
    
+(B and C may be the same.) As in case (2), the contents of B do not appear in A
    
+afterward (unless such contents also happen to be in C).  If
    
+:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it defaults
    
+to zero; the old offset (into B) is not retained.
    
+
    
+(4) A is displaced to B before the call, but not displaced afterward.  A gets a
    
+new "data region", and contents of B are copied into it as appropriate to
    
+maintain the existing old contents; additional elements of A are taken from the
    
+:INITIAL-ELEMENT.  However, the use of :INITIAL-CONTENTS causes all old contents
    
+to be discarded.
    
+
    
+If array X is displaced to array Y, and array Y is displaced to array Z, and
    
+array Y is altered by ADJUST-ARRAY, array X must now refer to the adjusted
    
+contents of Y.  This means that an implementation may not collapse the chain to
    
+make X refer to Z directly and forget that the chain of reference passes through
    
+array Y.  (Cacheing techniques are of course permitted, as long as they preserve
    
+the semantics specified here and in CLtL.)
    
+
    
+If X is displaced to Y, it is an error to adjust Y in such a way that it no
    
+longer has enough elements to satisfy X.  This error may be signalled at the
    
+time of the adjustment, but this is not required.
    
+
    
+Note: Omitting the :DISPLACED-TO argument to ADJUST-ARRAY is equivalent to
    
+specifying :DISPLACED-TO NIL; in either case, the array is not displaced after
    
+the call and case (1) or (4) hold.
    
+
    
+Rationale:
    
+
    
+This interaction must be clarified.  This set of rules was proposed some time
    
+ago, as a result of discussions on the Common Lisp mailing list, and this model
    
+has been adopted by many Common Lisp implementations.
    
+
    
+Current Practice:
    
+
    
+Many implementations currently follow the model proposed here, although they
    
+differ in some detail. For example, Symbolics Common Lisp behaves as indicated
    
+except for case (4); in that case, it never copies the contents of B, and all
    
+elements are taken from the :INITIAL-ELEMENT.
    
+
    
+Cost to implementors:
    
+
    
+Some existing implementations may have to be changed, but adopting any other
    
+model would be worse.  Public-domain code implementing this model is available
    
+from CMU.
    
+
    
+Cost to users:
    
+
    
+This is a relatively uncommon situation, which is the reason it didn't occur to
    
+the original language designers to specify how it works.  Any user code that
    
+cares about this issue probably already follows the proposed model.
    
+
    
+Benefits:
    
+
    
+Clarification of a situation that is currently not addressed by the standard.
    
+
    
+Discussion:
    
+
    
+The cleanup committee supports this clarification.
    
+
    
+Some consideration was given to adding DISPLACED-ARRAY-P or ARRAY-DISPLACED-TO
    
+and ARRAY-DISPLACED-INDEX-OFFSET which would allow access to information as to
    
+whether an array was or was not displaced. However, these are not part of the
    
+current proposal.
    
+
    
+A similar issue arises with ADJUST-ARRAY and fill pointers, and will be the
    
+subject of a separate issue.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004.htm new file mode 100644 index 00000000..37f4d703 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ADJUST-ARRAY-FILL-POINTER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ADJUST-ARRAY-FILL-POINTER Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ADJUST-ARRAY-FILL-POINTER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004_w.htm new file mode 100644 index 00000000..ba1bed4e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss004_w.htm @@ -0,0 +1,127 @@ + + + +CLHS: Issue ADJUST-ARRAY-FILL-POINTER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ADJUST-ARRAY-FILL-POINTER Writeup

    + +
    Issue:        ADJUST-ARRAY-FILL-POINTER
    
+References:   ADJUST-ARRAY (p297)
    
+Category:     CLARIFICATION
    
+Edit history: 15-Mar-88, Version 1 by Pitman
    
+
    
+Problem Description:
    
+
    
+  CLtL does not specify clearly the effect of ADJUST-ARRAY on the fill
    
+  pointer.
    
+
    
+Proposal (ADJUST-ARRAY-FILL-POINTER:MINIMAL):
    
+
    
+  Clarify that the :FILL-POINTER keyword argument to ADJUST-ARRAY is treated
    
+  as follows...
    
+
    
+  If :FILL-POINTER argument is not given, then the fill-pointer of the array
    
+  to be adjusted (if any) is left alone. It is an error to adjust an array
    
+  to a size smaller than its fill pointer without specifying the :FILL-POINTER
    
+  option so that its fill-pointer is properly adjusted in the process.
    
+
    
+  If supplied, the :FILL-POINTER argument must be either an integer between 0
    
+  and the new size of the array, the symbol T (indicating that the new size
    
+  of the array should be used), or the symbol NIL (indicating that the fill
    
+  pointer should left as it is -- as if the :FILL-POINTER option had not been
    
+  specified).
    
+
    
+  An error is signalled if a non-NIL value for :FILL-POINTER is supplied and
    
+  the array to be adjusted does not already have a fill pointer.
    
+
    
+Test Case:
    
+
    
+  (SETQ A1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
    
+  (SETQ A2 (ADJUST-ARRAY A1 4))
    
+  (FILL-POINTER A1) => 3
    
+  (FILL-POINTER A2) => 3
    
+
    
+  (SETQ B1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
    
+  (SETQ B2 (ADJUST-ARRAY B1 2 :FILL-POINTER 1))
    
+  (FILL-POINTER B1) => 1
    
+  (FILL-POINTER B2) => 1
    
+
    
+  (SETQ C1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
    
+  (SETQ C2 (ADJUST-ARRAY C1 2 :FILL-POINTER T))
    
+  (FILL-POINTER C1) => 2
    
+  (FILL-POINTER C2) => 2
    
+
    
+  (SETQ D1 (MAKE-ARRAY 5 :ADJUSTABLE T))
    
+  (SETQ D2 (ADJUST-ARRAY D1 2 :FILL-POINTER 2)) signals an error.
    
+
    
+  (SETQ E1 (MAKE-ARRAY 5 :FILL-POINTER T :ADJUSTABLE T))
    
+  (SETQ E2 (ADJUST-ARRAY E1 4)) is an error.
    
+
    
+Rationale:
    
+
    
+  This behavior must be more clearly defined if portable programs are going
    
+  to be able to depend on it.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Lisp implements the proposal. In case "E", it does not signal an
    
+  error. It simply leaves the illegal fill-pointer in place so that the
    
+  programmer can correct it using (SETF (FILL-POINTER E2) ...)
    
+
    
+Cost to Implementors:
    
+
    
+  Probably most implementations do not deviate significantly from the proposed
    
+  behavior. The cost to implementors is probably very slight.
    
+
    
+Cost to Users:
    
+
    
+  None. This clarifies a fuzzy area in the manual which users cannot currently
    
+  depend upon.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The interaction between ADJUST-ARRAY and fill-pointers would continue to be
    
+  hazy, and portable programs would not be able to rely upon that behavior
    
+  being consistent across implementations.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  There is little if any aesthetic impact of this change.
    
+
    
+Discussion:
    
+
    
+  Pitman volunteered to write this issue up for the Cleanup committee. He's
    
+  not very passionate about the details one way or another, but figures it's
    
+  a good idea that they be clarified.
    
+
    
+
    
+   The cleanup committee didn't object.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005.htm new file mode 100644 index 00000000..2ad8813f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005_w.htm new file mode 100644 index 00000000..1ec987b4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss005_w.htm @@ -0,0 +1,270 @@ + + + +CLHS: Issue ADJUST-ARRAY-NOT-ADJUSTABLE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ADJUST-ARRAY-NOT-ADJUSTABLE Writeup

    + +
    X3J13 accepted v11 Jun 89 on vote of N-1...
    
+
    
+Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
    
+References:   ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
    
+              MAKE-ARRAY (pp286-289), simple arrays (p28, 289),
    
+              simple strings with fill pointers (p299),
    
+              VECTOR-PUSH-EXTEND (p296)
    
+Category:     CLARIFICATION and CHANGE
    
+Edit history: 22-Apr-87, Version 1 by Pitman
    
+              15-Nov-88, Versions 2a,2b,2c by Pitman
    
+              02-Dec-88, Version 3 by Pitman
    
+              11-Jan-89, Version 4 by Pitman
    
+              16-Jan-89, Version 5, by Gabriel.  Amended at the meeting to shorten.
    
+              23-Jan-89, Version 6, by Moon.  Shorten without the bug introduced
    
+                        by the amendment, add clarification of SIMPLE-ARRAY type.
    
+              15-Feb-89, Version 7, by Pitman. Minor changes per comments from
    
+                        RPG and Dalton.
    
+              11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
    
+              17-Mar-89, Version 9, by Moon, fix wording and examples to make it
    
+                        clear that the semantics of simple-array is unchanged.
    
+               6-Jun-89, Version 10, by Moon and Gabriel, do over.
    
+              23-Jun-89, Version 11, by Moon, two little corrections
    
+
    
+Problem Description:
    
+
    
+  There are a number of unclear passages in CLtL related to simple arrays
    
+  and adjustable arrays.  There is disagreement on precisely how these
    
+  passages are to be interpreted, and no one is happy with the fact that
    
+  ADJUST-ARRAY works only on an implementation-dependent subset of arrays.
    
+
    
+  The description of the :ADJUSTABLE option to MAKE-ARRAY on p288 says that
    
+  ``the argument, if specified and not NIL, indicates that it must be
    
+  possible to alter the array's size dynamically after it is created. This
    
+  argument defaults to NIL.''  The description of the :ADJUSTABLE option
    
+  does not say what MAKE-ARRAY will do if the argument is unsupplied or
    
+  explicitly NIL.
    
+
    
+  The description of ADJUSTABLE-ARRAY-P on p293 says that it is true ``if
    
+  the argument (which must be an array) is adjustable, and otherwise
    
+  false.'' However, the description of MAKE-ARRAY makes it clear that this
    
+  is not necessarily the same as asking if the array was created with
    
+  :ADJUSTABLE T.  If ADJUSTABLE-ARRAY-P returns NIL, you know that
    
+  :ADJUSTABLE NIL was supplied (or no :ADJUSTABLE option was supplied), but
    
+  if ADJUSTABLE-ARRAY-P returns T, then there is no information about
    
+  whether :ADJUSTABLE was used.
    
+
    
+  The description of ADJUST-ARRAY on pp297-298 says that it is ``not
    
+  permitted to call ADJUST-ARRAY on an array that was not created with the
    
+  :ADJUSTABLE option.'' This is inconsistent with ADJUSTABLE-ARRAY-P.
    
+
    
+  The definition of SIMPLE-ARRAY on p.28 says ``an array that is not
    
+  displaced to another array, has no fill pointer, and is not to have its
    
+  size adjusted dynamically after creation is called a simple array.''
    
+  It is left unclear whether this is an implication or an equivalence,
    
+  i.e. whether there can be other simple arrays as well.
    
+  CLtL p.299 appears to refer to simple strings with fill pointers,
    
+  suggesting that it is an implication, but similar language is used for
    
+  equivalences in other parts of CLtL.
    
+
    
+Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY)
    
+
    
+  1. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER, 
    
+  and :DISPLACED-TO arguments each either unspecified or false, the
    
+  resulting array is a simple array.  (This just repeats what CLtL
    
+  says on page 289, it's here to aid in understanding the next point.)
    
+      
    
+  2. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
    
+  :FILL-POINTER, or :DISPLACED-TO arguments true, whether the
    
+  resulting array is simple is unspecified.
    
+
    
+  3. It is permitted to call ADJUST-ARRAY on any array.  (Remove the
    
+  restriction documented at the bottom of p.297.)
    
+
    
+  4. If ADJUST-ARRAY is applied to an array created with :ADJUSTABLE true,
    
+  the array returned is EQ to its first argument.  It is not specified
    
+  whether ADJUST-ARRAY returns an array EQ to its first argument for any
    
+  other arrays.  If the array returned by ADJUST-ARRAY is not EQ to its
    
+  first argument, the original array is unchanged and does not share
    
+  storage with the new array.
    
+
    
+  5. The predicate ADJUSTABLE-ARRAY-P is true if and only if ADJUST-ARRAY
    
+  will return a value EQ to this array when given this array as its first
    
+  argument.
    
+
    
+Clarifications and Logical Consequences:
    
+
    
+  a. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
    
+     definitely returns NIL.
    
+
    
+  b. There is no specified way to create an array that is non-simple.
    
+
    
+  c. The definition of SIMPLE-ARRAY on p.28 is taken to be an implication,
    
+     not an equivalence.  This is either a clarification or a change depending
    
+     on one's prior reading of that definition.
    
+
    
+  d. The meaning of ADJUSTABLE-ARRAY-P is changed.
    
+
    
+  e. As with such functions as DELETE and NCONC, textbooks should
    
+     instruct programmers to be careful to receive the value returned by
    
+     ADJUST-ARRAY, as it might not be EQ to the first argument.
    
+
    
+  f. VECTOR-PUSH-EXTEND still signals an error if given a non-adjustable
    
+     array.  ADJUST-ARRAY's new feature of making a copy cannot be used
    
+     by VECTOR-PUSH-EXTEND, since there is no way to return the copy to
    
+     the caller.
    
+
    
+Rationale:
    
+
    
+  Points 3 and 4 eliminate the problem of ADJUST-ARRAY only working on a
    
+  subset of arrays, by changing it to work on all arrays.  It remains
    
+  implementation-dependent whether the array is modified in place or
    
+  copied, i.e. whether the result is EQ to the argument, however many other
    
+  functions in Common Lisp have similar implementation-dependent behavior.
    
+  Implementation-dependent storage allocation or reuse is considered
    
+  more benign than implementation-dependent applicability of an operation.
    
+
    
+  Point 3 recognizes that ADJUST-ARRAY offers features that are offered by
    
+  no other function and which are useful in cases involving non-adjustable
    
+  arrays (for what amounts to copying).  This change would allow an
    
+  expression such as:
    
+
    
+    (SETQ X (ADJUST-ARRAY X ...))
    
+
    
+  to work reliably. Those desiring the old behavior could do:
    
+
    
+    (IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
    
+            (NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
    
+        (ERROR "Array cannot be adjusted."))
    
+  
    
+  to get the old style error checking.
    
+
    
+  Point 5 recycles the name ADJUSTABLE-ARRAY-P as a test for whether an
    
+  array is adjusted in place or by copying.
    
+
    
+  Point 2 preserves the raison d'etre of simple arrays, which is to provide
    
+  a portable interface to implementation-dependent specialized arrays that
    
+  trade decreased functionality for faster access.  A proposed alternative
    
+  was to specify a way to create an array that is guaranteed not to be
    
+  simple.  This would have made (typep (make-array ...) 'simple-array)
    
+  return the same value in all implementations, but would have required
    
+  large changes to some implementations and would be of little benefit to
    
+  users.  Users need to know that certain arrays are simple, so they can
    
+  put in declarations and get higher performance, but users have no need to
    
+  be able to create arrays that are definitely non-simple (for lower
    
+  performance) or definitely non-adjustable.
    
+
    
+Examples:
    
+
    
+  1. The following program is conforming.
    
+  
    
+    (defun double (a)
    
+      (adjust-array a (* (length a) 2)))
    
+  
    
+    (double (make-array 30))
    
+
    
+  2. The following program is conforming.  In no implementation is the
    
+  type declaration violated.
    
+
    
+    (let ((a (make-array 100)))
    
+      (declare (simple-array a))
    
+      (frob a))
    
+
    
+  3. The following program is non-conforming.  The consequences of this
    
+  program are undefined because the type declaration is violated in some
    
+  implementations.
    
+
    
+    (let ((a (make-array 100 :adjustable t)))
    
+      (declare (simple-array a))
    
+      (frob a))
    
+
    
+Current Practice:
    
+
    
+  Every correct CLtL implementation conforms to points 1 and 2.  It is
    
+  unlikely that any implementation currently exists that conforms to points
    
+  3, 4, and 5.  Points 3 and 4 involve additions to an implementation to
    
+  support the copying form of ADJUST-ARRAY.  Point 5 may involve a change
    
+  to ADJUSTABLE-ARRAY-P or may be able to use the existing implementation
    
+  of the function.
    
+
    
+  Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
    
+  and ignores adjustability in deciding whether an array is a SIMPLE-ARRAY.
    
+  The arrays that are internally simple in Symbolics Genera are a different
    
+  subset of arrays from the type SIMPLE-ARRAY, because simplicity in that
    
+  implementation depends on the rank and total-size as well as on the
    
+  fill-pointer and displacement, thus Genera does not use the type
    
+  SIMPLE-ARRAY for anything.
    
+
    
+  Lucid, IIM, Ibuki, and Symbolics Cloe make :ADJUSTABLE NIL arrays
    
+  non-adjustable in all cases, and make every array non-simple that CLTL
    
+  does not require to be simple.
    
+
    
+  Macintosh Allegro Common Lisp v1.2 makes :ADJUSTABLE NIL arrays
    
+  non-adjustable in all cases, makes all arrays of rank other than 1
    
+  non-simple (violating point 1), and makes every array non-simple that
    
+  CLTL does not require to be simple.
    
+
    
+Cost to Implementors:
    
+
    
+  The change to ADJUSTABLE-ARRAY-P is easy.  The change to ADJUST-ARRAY may
    
+  involve some complex coding but should not be a large task.  No changes
    
+  are required to anything connected with SIMPLE-ARRAY.
    
+
    
+Cost to Users:
    
+
    
+  None in code that does not call ADJUSTABLE-ARRAY-P.  This is a fully
    
+  upward-compatible change from the user's standpoint.
    
+
    
+Benefits:
    
+
    
+  Programs that use simple arrays and/or adjust arrays will be easier
    
+  to port, as the language specification for these features will be
    
+  clearer.  More programs will be able to call ADJUST-ARRAY, as its use
    
+  will not be restricted to a subset of arrays.
    
+
    
+Non-Benefits:
    
+
    
+  Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
    
+  an error would not get the desired signal.  A few programs might have
    
+  porting problems due to variation among implementations of whether the
    
+  result of ADJUST-ARRAY is EQ to the first argument.
    
+
    
+Aesthetics:
    
+
    
+  Most people believe the status quo is unaesthetic.  Having an aspect of
    
+  the language more clearly specified is an aesthetic improvement.
    
+  Allowing ADJUST-ARRAY on all arrays is an aesthetic improvement.
    
+
    
+Discussion:
    
+
    
+  There are at least 110 messages of discussion preceding this version of the
    
+  proposal.  It does not seem feasible to summarize them here.
    
+
    
+  Dick Gabriel, Dave Moon, and Guy Steele support this proposal.
    
+
    
+  Some commentors would like to get rid of ADJUSTABLE-ARRAY-P, since
    
+  ADJUST-ARRAY now works on all arrays.  Other commentors have said that
    
+  ADJUSTABLE-ARRAY-P is still needed in some applications, such as user
    
+  written functions that behave like VECTOR-PUSH-EXTEND, and hence should
    
+  be kept; the concept of "adjustable array" is still meaningful.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006.htm new file mode 100644 index 00000000..48ad00e8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ALLOCATE-INSTANCE:ADD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ALLOCATE-INSTANCE:ADD Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ALLOCATE-INSTANCE:ADD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006_w.htm new file mode 100644 index 00000000..aa179337 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss006_w.htm @@ -0,0 +1,112 @@ + + + +CLHS: Issue ALLOCATE-INSTANCE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ALLOCATE-INSTANCE Writeup

    + +
    Issue:         ALLOCATE-INSTANCE
    
+
    
+References:    88-002R p.1-41
    
+               89-003 p.3-35
    
+
    
+Related issues: LOAD-OBJECTS
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  30-Apr-90, Version 1 by Moon
    
+
    
+Problem description:
    
+
    
+  The function page for the generic function ALLOCATE-INSTANCE was
    
+  accidentally omitted from 88-002R.
    
+
    
+Proposal (ALLOCATE-INSTANCE:ADD):
    
+
    
+  Add a generic function ALLOCATE-INSTANCE that takes one required
    
+  argument, a class, plus initialization arguments, and returns one value,
    
+  a freshly created instance of the given class.  The class argument must
    
+  be an actual class, not a class name, and must not be a built-in class.
    
+
    
+  The object returned by ALLOCATE-INSTANCE is "uninitialized"; when the
    
+  class is a standard class, this means the slots are unbound; when the
    
+  class is a structure class, this means the slots' values are unspecified.
    
+
    
+  Common Lisp does not specify how to add methods to ALLOCATE-INSTANCE;
    
+  this capability might be added by the Metaobject Protocol.
    
+
    
+  This is Symbolics issue #32 and Loosemore's issue #6 of 27 Feb 90.
    
+
    
+Examples:
    
+
    
+  (DEFCLASS MYCLASS () (A B C))
    
+  (ALLOCATE-INSTANCE (FIND-CLASS 'MYCLASS))
    
+  (SLOT-BOUNDP * 'B) => NIL
    
+
    
+Rationale:
    
+
    
+  Some of the authors of 88-002R say the omission of ALLOCATE-INSTANCE was
    
+  simply a mistake.  Note that LOAD-OBJECTS:MAKE-LOAD-FORM assumes the
    
+  existence of ALLOCATE-INSTANCE and that user-written MAKE-LOAD-FORM
    
+  methods that return two values will typically use ALLOCATE-INSTANCE in
    
+  the first value.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0 does not provide ALLOCATE-INSTANCE (although
    
+  it does exist in an internal package).  Lucid 4.0.0 Beta-1 provides
    
+  ALLOCATE-INSTANCE.
    
+
    
+Cost to Implementors:
    
+
    
+  Any CLOS implementation needs ALLOCATE-INSTANCE or something like it
    
+  internally, so implementing this proposal is largely a matter of
    
+  exporting the symbol from the COMMON-LISP package and documenting it.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  MAKE-LOAD-FORM would be considerably less useful.
    
+
    
+Performance impact:
    
+
    
+  None other than the impact of adding a symbol to the COMMON-LISP package.
    
+
    
+Benefits:
    
+
    
+  Missing piece of CLOS provided.
    
+
    
+Esthetics:
    
+
    
+  Neutral.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007.htm new file mode 100644 index 00000000..7e44773d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ALLOW-LOCAL-INLINE:INLINE-NOTINLINE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ALLOW-LOCAL-INLINE:INLINE-NOTINLINE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ALLOW-LOCAL-INLINE:INLINE-NOTINLINE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007_w.htm new file mode 100644 index 00000000..65ce4fa9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss007_w.htm @@ -0,0 +1,166 @@ + + + +CLHS: Issue ALLOW-LOCAL-INLINE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ALLOW-LOCAL-INLINE Writeup

    + +
    Forum:		Compiler
    
+Issue:		ALLOW-LOCAL-INLINE
    
+References:	CLtL p. 156, 159
    
+Related issues: PROCLAIM-INLINE-WHERE
    
+Category:	CLARIFICATION
    
+Edit History:   21 Sept. 88 V1 by David Gray
    
+                27 Oct.  88 V2 by David Gray - new proposal
    
+		 9 Nov.  88 V3 by David Gray - expanded problem
    
+			description and discussion sections.
    
+		30 Dec.  88 V4 by Sandra Loosemore -- suggestions from Pitman
    
+ 
    
+Problem Description:
    
+
    
+  The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
    
+  on 10/12/88) clarifies the use of INLINE proclamations, but there
    
+  remains a similar problem with the use of a local (DECLARE (INLINE
    
+  ...)):  how can the compiler expand the function inline if it didn't
    
+  know that the necessary information should have been saved when the
    
+  function was compiled?
    
+
    
+  Note that an INLINE proclamation does two things:
    
+
    
+    (1) It tells the compiler to do extra things when it sees the
    
+        function -definition-, to make it possible to code the function
    
+	inline.
    
+
    
+    (2) It tells the compiler to code -calls- to the function inline.
    
+
    
+  In order for local INLINE declarations to be useful, we need part 1
    
+  without part 2.
    
+ 
    
+Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE
    
+
    
+  Clarify that to define a function FOO which is not INLINE by default
    
+  but for which (DECLARE (INLINE FOO)) will make FOO be locally inlined,
    
+  the proper definition sequence is:
    
+    
    
+   (PROCLAIM '(INLINE foo))
    
+   (DEFUN foo ...)
    
+   (PROCLAIM '(NOTINLINE foo))
    
+
    
+  The INLINE proclamation preceding the DEFUN ensures that compiler will
    
+  save the information necessary for inline expansion, and the NOTINLINE
    
+  proclamation following the DEFUN prevents it from being expanded
    
+  inline everywhere.  
    
+
    
+  Note that while implementations are never required to perform inline
    
+  expansion of function calls, many implementations that do support
    
+  inline expansion will not be able to respond to local INLINE requests
    
+  if this technique is not followed.
    
+
    
+ Rationale:
    
+
    
+  Local INLINE declarations are of little use without some way of
    
+  alerting the compiler to the possibility of inline expansion before
    
+  the function is compiled.  This seems the simplest solution since it
    
+  just clarifies existing practice instead of adding a new feature to
    
+  the language.
    
+
    
+  A compiler could use some heuristic to save the definitions of functions
    
+  that are short enough to look like good candidates for inline expansion,
    
+  but then the user is never sure what to expect.  It is possible that a
    
+  compiler could simply save all definitions (assuming availability
    
+  of adequate storage space) but we shouldn't require that.
    
+
    
+ Test Cases/Examples: 
    
+
    
+  Given the following input to COMPILE-FILE, does F1 get expanded inline
    
+  in F2, and does F3 get expanded inline in F4?
    
+
    
+    (defun f1 (a) (+ a 100))
    
+    (defun f2 (b) (declare (inline f1)) (f1 b))
    
+    (proclaim '(inline f3))
    
+    (defun f3 (a) (+ a 100))
    
+    (proclaim '(notinline f3))
    
+    (defun f4 (b) (f3 b))			;F3 is not inline.
    
+    (defun f5 (c) (declare (inline f3)) (f3 c)) ;F3 is locally inline.
    
+    (defun f6 (c) (f3 c)) 			;The local effect is not 
    
+						;  persistent.
    
+ 
    
+ Current Practice:
    
+ 
    
+  In the example above, using Symbolics, Lucid, or Explorer, F1 is not
    
+  expanded in F2, but F3 is expanded in F5.
    
+
    
+ Cost to implementors:
    
+ 
    
+  None, since this is a clarification in accordance with current
    
+  practice.
    
+
    
+ Cost to users:
    
+  
    
+  None.
    
+
    
+ Benefits:
    
+
    
+  Users will be able to use (DECLARE (INLINE ...)) with greater assurance
    
+  that it will really do something.
    
+
    
+ Costs of Non-Adoption: 
    
+
    
+  Users will not know how to reliably request inline expansion on a
    
+  local basis.  This technique is not obvious, and even the need
    
+  for it likely to be apparent only to people who understand something
    
+  about how the compiler does inline expansion.
    
+
    
+ Discussion:
    
+
    
+  Version 1 of this issue included proposal
    
+  ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE to make an addition to the
    
+  language:
    
+    (PROCLAIM '(ALLOW-INLINE foo))
    
+  This was met with a lack of enthusiasm since it was pointed out that
    
+  the same effect could be obtained by using a combination of INLINE and
    
+  NOTINLINE.
    
+
    
+  This is may not be completely true, however, since people's thinking
    
+  about NOTINLINE has evolved in the direction of a declaration that
    
+  tells the compiler "assume nothing about this function".  Thus, a
    
+  NOTINLINE proclamation might suppress some optimizations that would
    
+  have occurred if there had never been an INLINE and NOTINLINE.
    
+
    
+  Ideally, it would be nice to have multiple levels of control instead
    
+  of just INLINE or NOTINLINE -- something like:
    
+    * always inline
    
+    * maybe inline (let the compiler decide)
    
+    * just save the definition for possible local inline
    
+    * default
    
+    * never inline
    
+
    
+  Pitman has said that he generally approves of the direction of this
    
+  proposal, but he has also expressed concerns about how the persistance
    
+  of INLINE proclamations may cause confusion when functions are redefined
    
+  in an incremental development environment.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008.htm new file mode 100644 index 00000000..9035f59b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ALLOW-OTHER-KEYS-NIL:PERMIT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ALLOW-OTHER-KEYS-NIL:PERMIT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ALLOW-OTHER-KEYS-NIL:PERMIT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008_w.htm new file mode 100644 index 00000000..8619112d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss008_w.htm @@ -0,0 +1,175 @@ + + + +CLHS: Issue ALLOW-OTHER-KEYS-NIL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ALLOW-OTHER-KEYS-NIL Writeup

    + +
    Issue:        ALLOW-OTHER-KEYS-NIL
    
+Forum:	      Cleanup
    
+References:   :ALLOW-OTHER-KEYS (pp62-63)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 22-Aug-90, Version 1 by Pitman
    
+	      23-Aug-90, Version 2 by Pitman (merge RWK's comments)
    
+	      23-Aug-90, Version 3 by Pitman (merge Moon's comments)
    
+	      13-Mar-91, Version 4 by Pitman (comments from JonL, Barmar)
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+  CLtL specifies that a keyword argument pair of :ALLOW-OTHER-KEYS is
    
+  always permissible when the value is non-null, in which case all other
    
+  keyword arguments in that actual call are allowed regardless of the 
    
+  formal &KEY parameter).  It doesn't specify any particular meaning 
    
+  when the value for :ALLOW-OTHER-KEYS is null; consequently such an
    
+  actual argument pair will be in error unless there is a formal &KEY
    
+  parameter of that name to receive it.
    
+
    
+  The fact that :ALLOW-OTHER-KEYS NIL either does not work or does not
    
+  work reliably causes some coding to be more cumbersome than necessary.
    
+  For example, a function that might be written as:
    
+    (DEFUN FOO-MEMBER (ITEM LIST PERMISSIVE-P &REST OPTIONS)
    
+      (APPLY #'MEMBER ITEM LIST :ALLOW-OTHER-KEYS PERMISSIVE-P OPTIONS))
    
+  must in fact be written as:
    
+    (DEFUN FOO-MEMBER (ITEM LIST PERMISSIVE-P &REST OPTIONS)
    
+      (IF PERMISSIVE-P
    
+	  (APPLY #'MEMBER ITEM LIST :ALLOW-OTHER-KEYS T OPTIONS)
    
+	  (APPLY #'MEMBER ITEM LIST OPTIONS)))
    
+  because :ALLOW-OTHER-KEYS NIL is not given the `obvious' meaning.
    
+
    
+  Some people have raised concerns about the permissibility and semantics
    
+  of :ALLOW-OTHER-KEYS (including :ALLOW-OTHER-KEYS NIL) if either
    
+  &ALLOW-OTHER-KEYS is used or an explicit &KEY argument such as
    
+  ALLOW-OTHER-KEYS is specified.  Some clarification about such issues
    
+  is probably warranted.
    
+
    
+Proposal (ALLOW-OTHER-KEYS-NIL:PERMIT):
    
+
    
+  1. Define that :ALLOW-OTHER-KEYS is always permitted as an argument
    
+     to any function which has specified &KEY in the lambda list of its
    
+     definition.
    
+
    
+     If the value is non-NIL, then other non-matching keywords are
    
+     also tolerated (i.e., ignored). If the value is NIL, then other 
    
+     non-matching keyword are not tolerated (i.e., an error should be
    
+     signalled in accordance with rules for argument mismatches 
    
+     established by other proposals) unless &ALLOW-OTHER-KEYS was used.
    
+
    
+  2. Clarify that if the receiving argument list specifies an argument which 
    
+     would be flagged by :ALLOW-OTHER-KEYS, then :ALLOW-OTHER-KEYS has both 
    
+     its special-cased meaning (identifying whether additional keywords are 
    
+     permitted) and its normal meaning (data flow into the function in 
    
+     question).
    
+
    
+Rationale:
    
+
    
+  1. There can't be any reasonable use for :ALLOW-OTHER-KEYS as a keyword
    
+     to designate `real' information coming into the function since the 
    
+     keyword is already reserved just in case the value it carries with
    
+     it will be non-NIL.  As such, there is no ambiguity about the
    
+     programmer's intent in the case of :ALLOW-OTHER-KEYS NIL.  Failing
    
+     to admit :ALLOW-OTHER-KEYS NIL just makes it unnecessarily clumsy
    
+     to write functions like FOO-MEMBER (see Problem Description).
    
+     It also defeats the purpose of there being a value associated with
    
+     :ALLOW-OTHER-KEYS in the first place.
    
+
    
+  2. This allows functions which do their own keyword processing on &REST
    
+     arguments to respect this flag, as well as being conceptually the most
    
+     uniform meaning.
    
+
    
+Test Case:
    
+
    
+  #1: ((LAMBDA (&KEY) T) :ALLOW-OTHER-KEYS NIL)
    
+
    
+  #2: (DEFUN FOO-MEMBER (ITEM LIST PERMISSIVE-P &REST OPTIONS)
    
+	(APPLY #'MEMBER ITEM LIST :ALLOW-OTHER-KEYS PERMISSIVE-P OPTIONS))
    
+      (FOO-MEMBER 'X '(Z Y X) NIL)
    
+
    
+  #3: ((LAMBDA (&KEY ALLOW-OTHER-KEYS) ALLOW-OTHER-KEYS)
    
+       :ALLOW-OTHER-KEYS 6 :FRED 7)
    
+
    
+  #4: ((LAMBDA (&KEY ALLOW-OTHER-KEYS) ALLOW-OTHER-KEYS)
    
+       :ALLOW-OTHER-KEYS NIL :FRED 7)
    
+
    
+  #5: ((LAMBDA (&KEY ((:ALLOW-OTHER-KEYS FOO))) FOO)
    
+       :ALLOW-OTHER-KEYS 6 :FRED 7)
    
+
    
+Current Practice:
    
+
    
+  #1: Symbolics Genera 8.0 and Sun Common Lisp 3.0.1 signal an error.
    
+      Symbolics Genera 8.1 returns T, which is consistent with proposal 
    
+      PERMIT.
    
+
    
+  #2: Symbolics Genera 8.0 and Sun Common Lisp 3.0.1 signal an error.
    
+      Symbolics Genera 8.1 returns (X), which is consistent with proposal
    
+      PERMIT.
    
+
    
+  #3: Sun Common Lisp 3.0.1 signals an error.
    
+      Symbolics Genera 8.0 and 8.1 return 6, which is consistent with 
    
+      proposal PERMIT.
    
+
    
+  #4: Symbolics Genera 8.0, Symbolics Genera 8.1, and Sun Common Lisp 3.0.1
    
+      signal an error, which is consistent with proposal PERMIT.
    
+
    
+  #5: Sun Common Lisp 3.0.1 signals an error.
    
+      Symbolics Genera 8.0 and 8.1 return 6, which is consistent with
    
+      proposal PERMIT.
    
+
    
+Cost to Implementors:
    
+
    
+  Relatively small.
    
+
    
+Cost to Users:
    
+
    
+  None.  Currently, a valid user program must avoid stepping on this
    
+  error situation.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  See aesthetics.
    
+
    
+Benefits:
    
+
    
+  See aesthetics.
    
+
    
+Aesthetics:
    
+
    
+  This simplifies the user model by making the value associated with
    
+  :ALLOW-OTHER-KEYS be what controls whether other keys are permitted,
    
+  rather than by making the presence of the sequence ``:ALLOW-OTHER-KEYS T''
    
+  in the arglist what controls it.  In the status quo, the description of
    
+  how :ALLOW-OTHER-KEYS works is like no other keyword in the language.
    
+
    
+Discussion:
    
+
    
+  Pitman, RWK, and Moon support this proposal.
    
+
    
+  RWK comments: ``Together with my addenda above, [this] proposal 
    
+   means that &KEY without &ALLOW-OTHER-KEYS implies a "hidden" 
    
+   keyword argument of :ALLOW-OTHER-KEYS that the &KEY processing 
    
+   checks.  In all other regards, it is a perfectly ordinary keyword 
    
+   argument.''
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009.htm new file mode 100644 index 00000000..397ea96f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue AREF-1D Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue AREF-1D Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue AREF-1D:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009_w.htm new file mode 100644 index 00000000..af6549d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss009_w.htm @@ -0,0 +1,131 @@ + + + +CLHS: Issue AREF-1D Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue AREF-1D Writeup

    + +
    Issue:        AREF-1D
    
+References:   Arrays (pp286-298)
    
+Category:     ENHANCEMENT
    
+Edit history: 22-Apr-87, Version 1 by Pitman
    
+              02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
    
+              6-Jun-87, Versions 3, 4 by Masinter (editorial)
    
+              11-Jun-87, Version 5, to X3J13 (no changes)
    
+               6-Jul-87, Version 6, by Masinter
    
+              14-Nov-87, Version 7, by Masinter (update discussion)
    
+
    
+Problem Description:
    
+
    
+It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY efficiently
    
+in Common Lisp because they take arguments of varying rank. Currently, you have
    
+to make a displaced array to work with temporarily and then throw away the
    
+displaced array when you're done. In many cases, this is bothersome because
    
+there is no a priori reason why they should have to cons at all.
    
+
    
+Proposal (AREF-1D:ROW-MAJOR-AREF):
    
+
    
+Introduce a new function ROW-MAJOR-AREF that allows one-dimensional access to
    
+the storage backing up a given array assuming the normal row-major storage
    
+layout.
    
+
    
+ROW-MAJOR-AREF is valid for use with SETF.
    
+
    
+row-major-aref array index              [Function]
    
+
    
+This accesses and returns the element of array specified by index when the
    
+elements of array are considered in row-major order. Array may be an array of
    
+any dimensionality. row-major-aref may be used with setf. For reference, the
    
+following sets of expressions are equivalent:
    
+
    
+(row-major-aref array index) ==
    
+    (aref (make-array (array-total-size array)
    
+                      :displaced-to array
    
+                      :element-type (array-element-type array))
    
+          index)
    
+
    
+and
    
+
    
+(aref array .. subscripts ..) ==
    
+    (row-major-aref array (array-row-major-index array .. subscripts ..))
    
+
    
+Rationale:
    
+
    
+Common Lisp requires row-major storage layout of arrays and has a number of
    
+operators that allow users to exploit that order. ROW-MAJOR-AREF is a useful,
    
+simple addition.
    
+
    
+LISTARRAY and FILLARRAY, for example, could be trivially defined by loops that
    
+had the following form:
    
+
    
+    (DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
    
+      ... (ROW-MAJOR-AREF ARRAY I) ...)
    
+
    
+Currently, the only really efficient way to write this would involve something
    
+like:
    
+
    
+    (ECASE (ARRAY-RANK ARRAY1)
    
+      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
    
+      ((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
    
+	     (SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
    
+      ((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
    
+	     (DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
    
+	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
    
+      ...some finite number of clauses...)
    
+
    
+Current Practice:
    
+
    
+Many implementations have this primitive under some other name for use
    
+internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
    
+
    
+Adoption Cost:
    
+
    
+This change is fairly localized. In implementations that already use this
    
+primitive internally, it's little more than a matter of changing the name of or
    
+otherwise releasing the existing primitive. In some implementations, it might
    
+involve writing a small amount of code or compiler work to make ROW-MAJOR-AREF
    
+work efficiently.
    
+
    
+Benefits:
    
+
    
+This gives users efficient access to something to which they already have
    
+inefficient access.
    
+
    
+Conversion Cost:
    
+
    
+This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely to be
    
+used by any current program.
    
+
    
+Aesthetics:
    
+
    
+This allows certain programs to be written in a more aesthetic way.
    
+
    
+Discussion:
    
+
    
+This issue was conditionally passed at X3J13/June 1987, pending clarification of
    
+some details. Those clarifications have been made in this version.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010.htm new file mode 100644 index 00000000..4a8e3661 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010_w.htm new file mode 100644 index 00000000..3d2757cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss010_w.htm @@ -0,0 +1,93 @@ + + + +CLHS: Issue ARGUMENT-MISMATCH-ERROR-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ARGUMENT-MISMATCH-ERROR-AGAIN Writeup

    + +
    Issue:         ARGUMENT-MISMATCH-ERROR-AGAIN
    
+Forum:         Cleanup
    
+References:    ARGUMENT-MISMATCH-ERROR, draft 10.156 pp.3-44, 3-48
    
+Category:      CHANGE
    
+Edit history:  9-Dec-91, Version 1 by Moon
    
+Status:        Accepted 10-Dec-91; 10-1
    
+
    
+Problem description:
    
+  
    
+  ARGUMENT-MISMATCH-ERROR left out two cases of argument mismatch error:
    
+  (1) a mismatch between a destructuring lambda list and the tree being destructured;
    
+  (2) an odd number of arguments supplied to the keyword parameters.
    
+
    
+  In the current specification, these are both "the consequences are undefined."
    
+  This is inconsistent with the handling of the other five argument mismatch errors.
    
+
    
+Proposal (ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT):
    
+
    
+  Add two new subsections to section 3.5, with wording analogous to the subsections
    
+  already present, to cover these cases, as follows:
    
+
    
+  (1) After the existing sentence "The pattern and the \term{macro form} must have
    
+  compatible \term{tree structure}; that is, their \term{tree structure} must be
    
+  equivalent, or it must differ only in that some \term{leaves} of the pattern
    
+  match \term{non-atomic} \term{objects} of the \term{macro form}." add "In a safe
    
+  call, an error of type program-error must be signaled; otherwise, the situation
    
+  has undefined consequences." followed by the boilerplate about the exact point of
    
+  the signal.
    
+
    
+  (2) Add the following: "An odd number of arguments must not be supplied for the
    
+  keyword parameters. In a \term{safe} \term{call}, an error \oftype{program-error}
    
+  must be signaled unless either \keyref{allow-other-keys} was used in the
    
+  \term{function}'s definition, or ``\f{:allow-other-keys \term{true}}'' was used
    
+  in the \term{call}; otherwise, the \term{situation} has undefined consequences."
    
+  followed by the boilerplate about the exact point of the signal. 
    
+
    
+  Move some text now on page 3-44 to the new subsection of 3.5 dealing with destructuring.
    
+
    
+Rationale:
    
+  
    
+  Consistency.
    
+
    
+Current practice:
    
+
    
+  CLtL did not require this level of error checking, so it's entirely 
    
+  likely that there are implementations which do not conform.
    
+
    
+Cost to Implementors:
    
+
    
+  The cost of adding additional error checking in some implementations.
    
+
    
+Cost to Users:
    
+
    
+  More robust code.
    
+
    
+Cost of non-adoption:
    
+
    
+  Less safety when users use defmacro; inconsistency in the specification.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011.htm new file mode 100644 index 00000000..7bec7086 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011.htm @@ -0,0 +1,42 @@ + + + +CLHS: Issue ARGUMENT-MISMATCH-ERROR-MOON:FIX Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ARGUMENT-MISMATCH-ERROR-MOON:FIX Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ARGUMENT-MISMATCH-ERROR-MOON:FIX:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011_w.htm new file mode 100644 index 00000000..b54737b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss011_w.htm @@ -0,0 +1,112 @@ + + + +CLHS: Issue ARGUMENT-MISMATCH-ERROR-MOON Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ARGUMENT-MISMATCH-ERROR-MOON Writeup

    + +
    Issue:        ARGUMENT-MISMATCH-ERROR-MOON
    
+Reference:    dpANS 12.24
    
+                3.5 Error Checking in Function Calls
    
+                3.5.1.1 Safe and Unsafe Calls
    
+                3.5.1.2 Too Few Arguments
    
+                3.5.1.3 Too Many Arguments
    
+                3.5.1.4 Unrecognized Keyword Arguments
    
+                3.5.1.5 Invalid Keyword Arguments
    
+                3.5.1.6 Odd Number of Keyword Arguments
    
+                3.5.1.7 Destructuring Mismatch
    
+              X3J13/92-3212 David Moon comment #12
    
+Category:     EDITORIAL
    
+Edit History: Version 1, 12/13/92, Kim Barrett
    
+              Version 2, 5/23/93, Sandra Loosemore (amendment from minutes)
    
+Status:       Proposal FIX passed without objection, March 1993
    
+
    
+Problem Description:
    
+
    
+ There are several problems in section 3.5 "Error Checking in Function Calls"
    
+ beginning on page 3-51:
    
+
    
+ a) The portions of section 3.5.1.1 referring to generic functions and
    
+ call-next-method say "safe" when they should say "safe or system code". The
    
+ generic function, an applicable method, or the method combination might be
    
+ defined in system code.
    
+
    
+ b) The word "otherwise" beginning the second paragraph of section 3.5.1.2
    
+ doesn't make sense. It should be replaced by "If too few arguments are
    
+ supplied". Similar corrections are required in sections 3.5.1.3, 3.5.1.4,
    
+ 3.5.1.5, and 3.5.1.6, but *not* 3.5.1.7.
    
+
    
+ c) The third paragraphs of sections 3.5.1.2, 3.5.1.3, 3.5.1.4, 3.5.1.5,
    
+ 3.5.1.6, and 3.5.1.7 are each completely redundant and should be deleted.
    
+
    
+ d) The first paragraph of section 3.5.1.7 refers to "Section mm.nn". Relevant
    
+ information does not seem to be in section 3.4.4 or 3.4.5; was this section
    
+ omitted entirely?
    
+
    
+Proposal (ARGUMENT-MISMATCH-ERROR-MOON:FIX):
    
+
    
+ a. In the first of the specific cases in 3.5.1.1 (generic function), change
    
+ the second use of the term \term{safe} to be "\term{safe code} or
    
+ \term{system code}".  Similarly in the last of the specific cases
    
+ (call-next-method).
    
+
    
+ b. At the beginning of the second paragraph of each of 3.5.1.2 through
    
+ 3.5.1.6, change the phrase "Otherwise, in a \term{safe call}" to "If this
    
+ \term{situation} occurs in a \term{safe call}".
    
+
    
+ c. Delete the third paragraphs of sections 3.5.1.2 through 3.5.1.7.
    
+
    
+ d. Repatriate the missing section reference.
    
+
    
+ e. In the first paragraph of each of 3.5.1.2 and 3.5.1.3, add a period
    
+ following the first occurance of "\term{function}".
    
+
    
+Editorial Impact:
    
+
    
+ A small number of explicitly specified edits.
    
+
    
+Rationale:
    
+
    
+Examples:
    
+
    
+Current Practice:
    
+
    
+Cost to Implementors:
    
+
    
+Cost to Users:
    
+
    
+Performance Impact:
    
+
    
+Benefits:
    
+
    
+Aesthetics:
    
+
    
+Discussion:
    
+
    
+ Proposal item (e) was noted as being needed while preparing the other items.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012.htm new file mode 100644 index 00000000..dc5b3e3d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012_w.htm new file mode 100644 index 00000000..f5124001 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss012_w.htm @@ -0,0 +1,355 @@ + + + +CLHS: Issue ARGUMENT-MISMATCH-ERROR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ARGUMENT-MISMATCH-ERROR Writeup

    + +
    Issue:         ARGUMENT-MISMATCH-ERROR
    
+Forum:         Cleanup
    
+References:    ANSI CL spec (Aug 29, 1989 draft) pp.4-11,4-12,4-13,4-15,1-10
    
+               88-002R p.1-26 (appears also on p.4-20 of ANSI CL draft) 
    
+Category:      CHANGE
    
+Edit history:  1-Feb-90, Version 1 by Moon
    
+               9-May-90, Version 2 by Moon 
    
+                (address another inconsistency, found by Kim Barrett)
    
+               30-Oct-90, Version 3 by Pitman 
    
+                (first attempt to formalize X3J13 amendments to v2)
    
+               01-Nov-90, Version 4 by Pitman (comments by Moon, Barrett)
    
+	       01-Nov-90, Version 5 by Pitman (more comments by Moon, Barrett)
    
+               24-Feb-91, Version 6 by Loosemore (propose more amendments)
    
+               14-Mar-91, Version 7 by Loosemore (change item 11)
    
+Status:        v2+amendments (reflected in v5) accepted by X3J13, June 1990
    
+
    
+Problem description:
    
+  
    
+  The draft ANSI Common Lisp specification is inconsistent about what kind 
    
+  of error handling occurs when a function is called with arguments that 
    
+  do not match its definition.
    
+  
    
+   1. For too few arguments, p.4-11 says "there must be at least n passed
    
+   arguments," which probably (page 1-10) means "the consequences are
    
+   undefined" if there are too few arguments.
    
+   
    
+   2. For too many arguments, p.4-12 says "an error of type error is 
    
+   signalled."
    
+   
    
+   3. For unrecognized keyword arguments, p.4-13 says "the consequences 
    
+   are undefined."  On the other hand, p.4-15 says "and error would be
    
+   signalled."
    
+   
    
+   4. For keyword argument names that are not symbols, p.4-13 says "the
    
+   consequences are undefined."
    
+ 
    
+   5. For unrecognized keyword arguments supplied to generic functions, 
    
+   p.4-20 and 88-002R p.1-26 say "an error is signalled."
    
+ 
    
+  This is Symbolics issue #5.
    
+
    
+Proposal (ARGUMENT-MISMATCH-ERROR:MUST-SIGNAL-WHEN-SAFE-OR-SYSTEM):
    
+  
    
+  Define that an error must be signalled in cases 1, 2, 3, and 5 of the
    
+  argument mismatch situations in the problem description if the caller,
    
+  the callee, and the point of functional evaluation all appear in a
    
+  context where a `safe' optimization setting is in effect (i.e., 
    
+  SAFETY=3).  In all other scenarios for these situations, the 
    
+  consequences are undefined.
    
+
    
+  Case 4 is treated the same, except that when :allow-other-keys t or
    
+  &allow-other-keys is involved, error detection is optional (i.e., the
    
+  consequences are undefined if the keyword argument names are not symbols).
    
+
    
+  If any of the caller, the callee, or the point of functional evaluation
    
+  was not user code, and was instead supplied by the implementation as a
    
+  pre-defined definition, or as automatically generated code (e.g., as
    
+  in method combination), then it must be treated as safe unless some 
    
+  user code involved in the scenario is not safe.
    
+
    
+  Clarify that a reference to the symbolic name of the function or to the 
    
+  contents of the symbol-function of a symbol does not count as a functional
    
+  evaluation.  For the purposes of this definition, functional evaluation
    
+  occurs either explicitly due to a use of the FUNCTION special form, or 
    
+  implicitly due to the use of a function name in the car of a normal
    
+  functional form.
    
+
    
+  The naive model which is intended is that the user can rely on error 
    
+  checking in these situations if he has taken all reasonable steps to
    
+  ensure that the situations will be safe.
    
+
    
+  The exact time that the error will be signalled is implementation-dependent,
    
+  but will always be prior to the execution of the body of the function being
    
+  called.
    
+  
    
+Clarifications:
    
+
    
+  The error might be signalled at compile time or at run time.  If the
    
+  error is signalled at run time, it might be signalled by either the
    
+  caller or the callee.
    
+
    
+  The reason that this terminology is used, and not the normal, "should
    
+  signal" terminology is because system code may be involved, and the
    
+  user may not know in general whether system code was compiled `safe'
    
+  or `unsafe'.  An implication of this definition is that all code
    
+  compiled by the system will behave as if compiled safe unless some
    
+  user code involved in the scenario is not. So, for example, if a user
    
+  calls MAPCAR from safe code and passes a function which was compiled
    
+  safe, the system is required to ensure that MAPCAR will make a safe
    
+  call as well.
    
+
    
+
    
+Proposal (ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS):
    
+
    
+  Amend proposal MUST-SIGNAL-WHEN-SAFE-OR-SYSTEM as follows:
    
+
    
+  (1) Clarify that if the callee is a generic function, the generic function
    
+      definition (if it was defined explicitly), the method definitions for 
    
+      all applicable methods, and the method-combination definition must all
    
+      be safe for the callee to be considered safe.
    
+  
    
+  (2) Clarify that for a form (COERCE <lambda-expression> 'FUNCTION),
    
+      the value of the OPTIMIZE SAFETY quality in the global environment
    
+      at the time the COERCE is executed applies to the resulting function.
    
+  
    
+  (3) Clarify that for a form (ENCLOSE <lambda-expression> <environment>),
    
+      the value of the OPTIMIZE SAFETY quality in the <environment> 
    
+      argument applies to the resulting function.
    
+  
    
+  (4) Clarify that for GENERIC-FUNCTION, GENERIC-FLET, and GENERIC-LABELS
    
+      forms, the value of the OPTIMIZE SAFETY quality in the environment 
    
+      in which the form appears applies to the resulting generic functions 
    
+      and method definitions.
    
+  
    
+  (5) Clarify that for a form (ENSURE-GENERIC-FUNCTION . arguments), the
    
+      value of the OPTIMIZE SAFETY quality in the environment passed as
    
+      the :environment keyword applies to the resulting generic function.
    
+  
    
+  (6) Clarify that for a form (COMPILE <name> <lambda-expression>), the
    
+      value of the OPTIMIZE SAFETY quality in the global environment at
    
+      the time the COMPILE is executed applies to the resulting 
    
+      compiled function.
    
+  
    
+  (7) Clarify that for a form (COMPILE <name>), if the original definition
    
+      of the function was at a `safe' optimization setting, then the
    
+      resulting compiled function must also be `safe'.
    
+  
    
+      Rationale: although many implementations do not save the information
    
+      about the global environment for interpreted functions, this is
    
+      consistent with the idea that safety is a lexical property that is
    
+      captured at the time code promotion occurs.  Implementations that do
    
+      not save the necessary information must treat interpreted functions
    
+      as being always "safe".
    
+  
    
+  (8) Clarify that "automatically generated code" does not apply to the
    
+      expansions of macros defined in the standard, which inherit safety
    
+      from the environment in which the macro call appears.
    
+  
    
+      Rationale:  this term isn't very well defined.  
    
+  
    
+  (9) Replace the words "supplied by the implementation as a pre-defined
    
+      definition" with "supplied by the implementation and part of the
    
+      Common Lisp standard".
    
+  
    
+      Rationale:  the original wording prohibits implementations from
    
+      providing *any* functions that do no argument checking, even
    
+      internal functions that users might accidentally get their hands on
    
+      as well as officially supported extensions.  There's no good 
    
+      reason to prohibit this, since presumably users have to ask for 
    
+      these unsafe functions explicitly.
    
+
    
+ (10) Clarify that a call to a method via CALL-NEXT-METHOD must be 
    
+      considered `safe' if the generic function, applicable methods,
    
+      method-combination, and the definition and efunctuation of the
    
+      CALL-NEXT-METHOD itself are all `safe'.
    
+
    
+ (11) Specify that if CALL-NEXT-METHOD is called with arguments, the ordered
    
+      set of applicable methods for the changed set of arguments for
    
+      CALL-NEXT-METHOD must be the same as the ordered set of applicable
    
+      methods for the original arguments to the generic function, or an error
    
+      should be signaled.  [This is a change -- 88-002R p2-13 says this
    
+      situation must always be detected.]
    
+
    
+      Clarify that the comparison between the set of methods applicable to the
    
+      new arguments and the set applicable to the original arguments is
    
+      insensitive to order differences among methods with the same
    
+      specializers.
    
+
    
+ (12) Clarify that if CALL-NEXT-METHOD is called with arguments that specify
    
+      a different ordered set of applicable methods and there is no next
    
+      method available, the test for different methods and the associated
    
+      error signalling (when present) takes precedence over calling
    
+      NO-NEXT-METHOD.
    
+     
    
+
    
+Examples:
    
+
    
+ A. Given ...
    
+
    
+    (declaim (optimize (safety 3)))
    
+
    
+    (defun     foo (x)                  (print 'test-failed) x)
    
+    (defun     bar (&key x)             (print 'test-failed) x)
    
+    (defmethod baz ((a integer) &key x) (print 'test-failed) x)
    
+
    
+    (defun funcall-it (x) (funcall x))
    
+   
    
+    Then every implementation must arrange for an error to be signalled
    
+    no later than the body (i.e., before (print 'test-failed) is executed)
    
+    if the following forms also occur in safe code:
    
+
    
+     A.1:  (foo)
    
+     A.2:  (foo 1 2)
    
+     A.3:  (bar :y 1)
    
+     A.4:  (bar 1 2)
    
+     A.5:  (baz 1 :y 7)
    
+     A.6:  (funcall #'foo)
    
+     A.7:  (funcall 'foo)
    
+     A.8:  (mapcar #'foo '(1 2) '(1 2))
    
+     A.9:  (mapcar 'foo '(1 2) '(1 2))
    
+     A.8:  (mapcar #'1+ '(1 2) '(1 2))
    
+     A.9:  (mapcar '1+ '(1 2) '(1 2))
    
+     A.10: (funcall-it #'foo)
    
+     A.10: (funcall-it 'foo)
    
+     A.11: (funcall-it #'1+)
    
+     A.12: (funcall-it '1+)
    
+     A.13: (let ((x (locally (declare (optimize (safety 0))) 'foo)))
    
+             (funcall-it x))
    
+     A.14: (let ((x (locally (declare (optimize (safety 0))) '1+)))
    
+             (funcall-it x))
    
+     A.15: (let ((x (locally (declare (optimize (safety 0)))
    
+		      (symbol-function 'foo))))
    
+             (funcall-it x))
    
+     A.16: (let ((x (locally (declare (optimize (safety 0)))
    
+		      (symbol-function '1+))))
    
+             (funcall-it x))
    
+
    
+ B. Here are some examples of situations that might signal an error, but 
    
+    are not required to signal an error.  In effect, the consequences are
    
+    undefined in these cases, even if the surrounding code is declared safe:
    
+
    
+          ;; Functional evaluation is not safe:
    
+    B.1:  (let ((x (locally (declare (optimize (safety 2))) #'foo)))
    
+            (funcall-it x))
    
+    B.2:  (let ((x (locally (declare (optimize (safety 2))) #'1+)))
    
+            (funcall-it x))
    
+
    
+          ;; Point of call is not safe:
    
+    B.3:  (let ((x #'foo))
    
+            (locally (declare (optimize (safety 2)))
    
+              (funcall x)))
    
+    B.4:  (let ((x #'1+))
    
+            (locally (declare (optimize (safety 2)))
    
+              (funcall x)))
    
+
    
+          ;; Callee is not safe:
    
+          (locally (declare (optimize (safety 2)))
    
+            (defun foo1 (x) x))
    
+    B.5:  (foo1)
    
+    B.6:  (mapcar #'foo1 '(1 2) '(1 2))
    
+    B.6:  (funcall-it 'foo1)
    
+
    
+Rationale:
    
+  
    
+  It's important for the document to be consistent and always say the
    
+  same thing about each individual error situation.  It also seems
    
+  important for the five error situations to be treated equally.
    
+  
    
+  Further, it's important that programmers be able to debug their code
    
+  conveniently in a safe environment.  Once they start tampering with
    
+  safety, they may run immediately into situations that expose
    
+  variations in how implementations deal with function calling, but
    
+  where safety is uniformly requested by the code, they should be able
    
+  to insulate themselves from such differences.
    
+
    
+  An exception is made in the name of efficiency for case 4 when
    
+  :ALLOW-OTHER-KEYS T or &ALLOW-OTHER-KEYS is used.
    
+
    
+Current practice:
    
+
    
+  CLtL did not require this level of error checking, so it's entirely 
    
+  likely that there are implementations which do not conform.
    
+
    
+  Symbolics Genera conforms to this proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  Some implementations already implement most or all of this, so their
    
+  cost will be minimal.
    
+
    
+  A few implementations may not implement this.  The cost will vary
    
+  depending on the implementation. In some cases, it could take a fairly
    
+  substantial amount of work to make these changes.
    
+
    
+  An implementation not willing to make these changes might prefer to
    
+  identify itself as implementing only a low-safety subset of the
    
+  language, and simply refuse to compile code which was declared high
    
+  safety.  This might be appropriate for certain delivery situations.
    
+
    
+Cost to Users:
    
+
    
+  More robust code.
    
+
    
+Cost of non-adoption:
    
+
    
+  The specification document will not even be self-consistent.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Language consistency.
    
+
    
+Aesthetics:
    
+
    
+  This is an improvement over the inconsistent situation which preceded it.
    
+
    
+Discussion:
    
+
    
+  The idea of making this merely "undefined" was discussed and rejected
    
+  at the June 1990 meeting.  There was consensus that signalling an
    
+  error was fine, but the main sticking points were saying under what
    
+  situations the user could depend on such signalling, and at what time
    
+  the signalling might be permitted to occur.  The following `amendment'
    
+  to the previous proposal was proposed and adopted, with the intent
    
+  that it be clarified later:
    
+
    
+    "should signal"
    
+           +
    
+    [ efunctuation ]
    
+    [ caller       ]  [ system or safe ]
    
+    [ callee       ]
    
+           +
    
+    "and no later than the body of the callee"
    
+
    
+  Versions 3-5 were an attempt to clarify what was voted upon.
    
+
    
+  Version 6 is an attempt to fix some lingering problems in the
    
+  writeup from version 5, mostly related to other situations in which
    
+  function promotion can occur that were not dealt with explicitly
    
+  in version 5.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013.htm new file mode 100644 index 00000000..2721f940 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013.htm @@ -0,0 +1,50 @@ + + + +CLHS: Issue ARGUMENTS-UNDERSPECIFIED:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ARGUMENTS-UNDERSPECIFIED:SPECIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ARGUMENTS-UNDERSPECIFIED:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013_w.htm new file mode 100644 index 00000000..8c77563d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss013_w.htm @@ -0,0 +1,105 @@ + + + +CLHS: Issue ARGUMENTS-UNDERSPECIFIED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ARGUMENTS-UNDERSPECIFIED Writeup

    + +
    Issue:        ARGUMENTS-UNDERSPECIFIED
    
+References:   LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363), 
    
+              MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
    
+              MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
    
+              SET (p 92)
    
+              Issue: RANGE-OF-START-END-PARAMETERS.
    
+Category:     CLARIFICATION
    
+Edit history: 26-Aug-88, Version 1 by Chapman
    
+               4-Sep-88, version 2 by Masinter
    
+              19-Sept-88, Version 3 by Chapman
    
+              21-Sep-88, Version 4 by Masinter
    
+ 
    
+Problem Description:
    
+ 
    
+The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
    
+MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER 
    
+are not clear about the types of the arguments supplied to these 
    
+constructs.
    
+ 
    
+Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
    
+ 
    
+Clarify that the arguments for the listed constructs are as follows:
    
+ 
    
+Construct                Argument	                 Type
    
+LOGBITP                   index		      non-negative integer
    
+MAKE-DISPATCH-MACRO-CHARACTER 	char		      character
    
+MAKE-HASH-TABLE            size	 	      non-negative integer
    
+MAKE-SEQUENCE              size		      non-negative integer
    
+MAKE-SEQUENCE              type		      type specifier
    
+MAKE-STRING                size                non-negative integer
    
+MAKE-STRING                initial-element	 string-char
    
+NTHCDR                     n		           non-negative integer
    
+SET-SYNTAX-FROM-CHAR       to-char,from-char   characters
    
+READ and others            eof-value	      any value
    
+SET                        value		      any value
    
+ 
    
+(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
    
+their respective SIZE arguments; for example, MAKE-STRING may detect an error if
    
+SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. Some additional 
    
+restriction on the range of characters which can have syntax in readtables 
    
+and are allowable to MAKE-DISPATCH-MACRO-CHARACTER SET-SYNTAX-FROM-CHAR might
    
+be required in some other proposal.)
    
+ 
    
+Rationale:
    
+ 
    
+This clarification allows predictible results to occur when 
    
+arguments are supplied to these constructs.
    
+ 
    
+Current Practice:
    
+
    
+This proposal seems to be in line with current implementations.
    
+
    
+Cost to Implementors:
    
+ 
    
+None, since this is consistent with current practice.
    
+ 
    
+Cost to Users:
    
+None, since this is consistent with current practice.
    
+ 
    
+Benefits:
    
+ 
    
+This clarification will assist users in writing portable code.
    
+ 
    
+Aesthetics:
    
+ 
    
+The standard would be less clean were the allowed ranges of its functions not
    
+specified.
    
+ 
    
+Discussion:
    
+
    
+There is a separate cleanup proposal RANGE-OF-START-END-PARAMETERS which
    
+addresses a possible incompatible change. This proposal contains what we
    
+think are non-controversial clarifications.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014.htm new file mode 100644 index 00000000..bd0a02ab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014.htm @@ -0,0 +1,53 @@ + + + +CLHS: Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014_w.htm new file mode 100644 index 00000000..4a976703 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss014_w.htm @@ -0,0 +1,135 @@ + + + +CLHS: Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS Writeup

    + +
    Issue:        ARRAY-DIMENSION-LIMIT-IMPLICATIONS
    
+Forum:	      Editorial
    
+References:   FIXNUM-NON-PORTABLE
    
+Category:     CHANGE
    
+Edit history: 01-Mar-91, Version 1 by Pitman
    
+	      13-Mar-91, Version 2 by Pitman
    
+		(comments by Moon, Barrett, and JonL)
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  Issue FIXNUM-NON-PORTABLE constrains ARRAY-DIMENSION-LIMIT to be 
    
+  a fixnum, but this means that
    
+     (MAKE-ARRAY (LIST (1- MOST-POSITIVE-FIXNUM) 2))
    
+  is a valid program.  This in turn implies that:
    
+     (ROW-MAJOR-AREF (MAKE-ARRAY (LIST (1- MOST-POSITIVE-FIXNUM) 2)) n)
    
+  might need bignum values of N to access all elements of the array.
    
+
    
+Proposal (ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM):
    
+
    
+  Constrain the upper bound on ARRAY-TOTAL-SIZE-LIMIT
    
+  (and ARRAY-RANK-LIMIT, by implication) in the same ways as
    
+  ARRAY-DIMENSION-LIMIT is constrained.
    
+ 
    
+  Clarify that the subscript arguments to AREF and to ROW-MAJOR-AREF
    
+  must be fixnums.
    
+
    
+Example:
    
+
    
+  (MAKE-ARRAY (LIST MOST-POSITIVE-FIXNUM 2)) would be an error.
    
+
    
+Rationale:
    
+
    
+  This makes it safe for users to declare subscripts for ROW-MAJOR-AREF to
    
+  be fixnums without knowing the nature of the array internals.  Without 
    
+  this, in principle, an implementation could support bignum arithmetic
    
+  internally for multi-dimensional arrays, and some situations involving
    
+  ROW-MAJOR-AREF would have to presume that bignum arithmetic was needed
    
+  in order to `keep up'.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera makes the array dimension limit smaller than the
    
+  most positive fixnum, so is not affected.
    
+
    
+Cost to Implementors:
    
+
    
+  None.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some situations would be left fuzzy, and might keep users from making 
    
+  certain fixnum declarations where desirable.
    
+
    
+Benefits:
    
+
    
+  See above. 
    
+
    
+Aesthetics:
    
+
    
+  Slight improvement--language is more consistent.
    
+
    
+Discussion:
    
+
    
+  Pitman thinks he supports this.
    
+
    
+  Version 1 of this proposal had two parts:
    
+    1. to allow ARRAY-DIMENSION-LIMIT to be a bignum (the smallest bignum)
    
+       in implementations which wanted to permit the full fixnum range 
    
+       for array size.
    
+    2. the text of the proposal as it now stands.
    
+  Part 1 was removed as controversial in v2 based on conversation which 
    
+  followed, which is summarized here.
    
+ 
    
+  Barrett said of version 1:
    
+    ``I think the second item of the proposal is ok.
    
+      I think the first item is unnecessary.''
    
+ 
    
+  Moon says of version 1:
    
+    ``... I do agree that ARRAY-TOTAL-SIZE-LIMIT should have
    
+      been required to be a fixnum. Maybe ROW-MAJOR-AREF didn't exist
    
+      when FIXNUM-NON-PORTABLE was written?''
    
+ 
    
+  JonL says (in reply to Moon):
    
+ 
    
+     ``Nope -- the relevant dates were March 1988 and January 1989.  
    
+       In fact, ROW-MAJOR-AREF was suggested (I think) by GLS's 
    
+       suggestions list from 6-Dec-85.  We probably just overlooked 
    
+       ARRAY-TOTAL-SIZE-LIMIT in January 1989 [but as I recall, that
    
+       issue accepted then had been argued about for two years or
    
+       more; so the original presentation of FIXNUM-NON-PORTABLE may
    
+       have occurred before ROW-MAJOR-AREF's.]
    
+       History aside, I too agree that ARRAY-TOTAL-SIZE-LIMIT should 
    
+       have been required to be a fixnum.''
    
+ 
    
+  Note that the effect of removing part 1 of the v1 proposal is that
    
+  the status quo is retained for the case that
    
+     (MAKE-ARRAY MOST-POSITIVE-FIXNUM)
    
+  is never a valid program in any implementation because of the
    
+  constraints that currently exist on ARRAY-DIMENSION-LIMIT.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015.htm new file mode 100644 index 00000000..f16d1745 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015.htm @@ -0,0 +1,47 @@ + + + +CLHS: Issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015_w.htm new file mode 100644 index 00000000..aa7268aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss015_w.htm @@ -0,0 +1,480 @@ + + + +CLHS: Issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS Writeup

    + +
    Status:		Passed, Jan 89 X3J13
    
+
    
+Forum:         Cleanup
    
+
    
+Issue:         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
    
+
    
+References:    Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
    
+               Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
    
+                          ARRAY-ELEMENT-TYPE, CLtL p. 291
    
+               The type-specifiers:
    
+                          ARRAY,  SIMPLE-ARRAY,  VECTOR,  SIMPLE-VECTOR
    
+                          COMPLEX
    
+
    
+Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1, 13-May-88, JonL
    
+               Version 2, 23-May-88, JonL  
    
+                (typo fixes, comments from moon, rearrange some discussion)
    
+               Version 3, 02-Jun-88, JonL  
    
+                (flush alternate proposal ["flush-upgrading"]; consequently,
    
+                 move more of discussion back to discussion section.
    
+               Version 4, 01-Oct-88, Jan Pedersen & JonL
    
+                (reduce discussion, and "cleanup" wordings)
    
+               (Version 5 edit history missing)
    
+               Version 6, 6-Oct-88, Moon
    
+                (fix typos, cover subtypep explicitly, add complex,
    
+                 change name of UPGRADE-ARRAY-ELEMENT-TYPE)
    
+               Version 7, 7-Oct-88, JonL (more name and wording changes)
    
+               Version 8,  8-Oct-88, Masinter (wording, discussion)
    
+               Version 9, 31-Oct-88, JonL (major re-wording to accommodate
    
+		 recent discussion; esp. re-introduce and clarify "upgrading")
    
+
    
+
    
+Problem description:
    
+
    
+ CLtL occasionally draws a distinction between type-specifiers "for
    
+ declaration" and "for discrimination";  see CLtL, section 4.5 "Type 
    
+ Specifiers That Specialize" (p.45 and following)  The phrase 
    
+ "for declaration"  encompasses type-specifiers passed in as the 
    
+ :element-type argument to  MAKE-ARRAY, passed in as the <result-type> 
    
+ argument to COERCE, and used in THE and DECLARE type declarations.  The 
    
+ phrase "for discrimination" refers to the type-specifiers passed in as 
    
+ the <type> argument(s) to TYPEP and SUBTYPEP.
    
+
    
+ One consequence of this distinction is that a variable declared to be of 
    
+ type <certain-type>, and all of whose assigned objects are created in 
    
+ accordance with that type, may still have none of its values ever satisfy 
    
+ the TYPEP predicate with that type-specifier.   One type-specifier with 
    
+ this property is  
    
+         (ARRAY <element-type>) 
    
+ for various implementation dependent values of <element-type>.  For
    
+ example, in most implementations of CL, an array X created with an
    
+ element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
    
+ satisfy
    
+        (TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
    
+        (TYPEP X '(ARRAY T)) 
    
+ but (almost) never will it satisfy 
    
+        (TYPEP X '(ARRAY (SIGNED-BYTE 5))).
    
+
    
+ This is entirely permissible within the scope of standardization on
    
+ MAKE-ARRAY, where an implementation is required only to construct up the
    
+ result out of "the most specialized [element] type that can nevertheless
    
+ accommodate elements of the given type [the :element-type argument]"
    
+ (see CLtL, p287).  That is, an implementation may in fact only provide a 
    
+ very small number of equivalence classes of element-types for storing 
    
+ arrays, corresponding to its repertoire of specialized storage techniques;
    
+ and it is explicitly permitted to "upgrade" any element-type request into 
    
+ one of its built-in repertoire (see also  CLtL, p45, second and third
    
+ paragraphs under Section 4.5.)
    
+
    
+ As a practical matter, almost every existing implementation does some 
    
+ serious upgrading of the :element-type argument given to MAKE-ARRAY.  
    
+ Yet the difference between "for declaration" and "for discrimination" 
    
+ has been very confusing to many people.  Similarly, portability is
    
+ hindered when users do not know just how a given implementation does 
    
+ upgrading.
    
+ 
    
+ The type specifier (COMPLEX <part-type>) also falls in the  domain of CLtL
    
+ Section 4.5.  Currently, only one implementation actually provides any kind 
    
+ of specialized storage for complex parts; and in this case, the practical
    
+ matter is less urgent, since the kind of upgrading happening is so obvious 
    
+ as to cause little or no confusion.
    
+
    
+
    
+Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
    
+
    
+ Short Summary:
    
+
    
+  ** Eliminate the distinction between type-specifiers "for declaration" and
    
+     "for discrimination".  In short, change the meaning of array and
    
+     complex type specifiers in favor of the "for declaration" meaning.
    
+
    
+  ** Change the meaning of TYPEP to be in accord with "for declaration"
    
+     meaning of type-specifiers.
    
+
    
+  ** Add an implementation-dependent function that reveals how a given 
    
+     type-specifier for array element-types is upgraded.  Add another such 
    
+     function that reveals how a given type-specifier for complex parts is
    
+     upgraded.
    
+
    
+  ** Clarify that "upgrading" implies a movement upwards in the type-
    
+     hierarchy lattice; i.e., if <type> upgrades to <Type>, then
    
+     <Type> must be a super-type of <type>.
    
+
    
+  ** Clarify that upgrading an array element-type is independent of any 
    
+     other property of arrays, such as rank, adjustability, fill-pointers, 
    
+     etc.  
    
+
    
+  ** Clarify how SUBTYPEP thus behaves on array type-specifiers.  
    
+
    
+  ** Define how SUBTYPEP behaves on complex type-specifiers.  
    
+
    
+ Note that despite this issue's name, the detailed specifications herein 
    
+ apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
    
+ arrays are actually implemented.
    
+
    
+ Details:
    
+
    
+  First, some definitions: Two type-specifiers <type1> and <type2> are said 
    
+  to be "type-equivalent" if and only if each one specifies a subtype of the
    
+  other one.  For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different 
    
+  type- specifiers that always refer to the same sets of things; hence they 
    
+  are type-equivalent.  But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not 
    
+  type- equivalent since the former refers to a proper subset of the latter.
    
+  Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
    
+  if their specified intersection is null.  For example, INTEGER and FLOAT 
    
+  are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and 
    
+  (INTEGER 7 10) are type-disjoint because the specified ranges have no
    
+  elements in common.
    
+
    
+ *. Eliminate the distinction between types "for declaration" and "for 
    
+    discrimination".  In particular, elminate any such reference in the 
    
+    discussion of array and complex type-specifiers; this would include 
    
+    documentation patterned after the discussion in section 4.5, pp. 45-7, 
    
+    especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
    
+    Change the meaning of (ARRAY <element-type>), as well as any of the
    
+    subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the 
    
+    "for declaration" meaning.  Make the similar simplification for the 
    
+    <part-type> specifiers in the COMPLEX type-specifier.
    
+
    
+ *. Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not 
    
+    *, to be true if and only if <x> is an array that could be the result 
    
+    of giving <type> as the :element-type argument to MAKE-ARRAY.  While
    
+    (ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
    
+    refers only to those arrays that can result from giving <type> as the
    
+    :element-type argument to the function MAKE-ARRAY.  Change the meanings
    
+    for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.
    
+
    
+    Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly.  Thus,
    
+    (COMPLEX <type>) refers to all complex numbers that can result from 
    
+    giving numbers of type <type> to the function COMPLEX, plus all other 
    
+    complex numbers of the same specialized representation.  Remember that
    
+    both the real and the imaginary parts of any such complex number must 
    
+    satisfy:
    
+                (TYPEP <real-or-imag-part> '<type>). 
    
+
    
+ *. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
    
+    returns the element type of the most specialized array representation
    
+    capable of holding items of the given argument type.   Note that except
    
+    for storage allocation consequences, it could be defined as:
    
+
    
+      (DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
    
+        (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
    
+
    
+    Since element-type upgrading is a fundamental operation implicit in 
    
+    almost every existing implementation of MAKE-ARRAY, the purpose of this 
    
+    added function is primarily to reveal how an implementation does its
    
+    upgrading.
    
+
    
+    Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
    
+    returns the part type of the most specialized complex number
    
+    representation that can hold parts of the given argument type.
    
+
    
+ *. Clarify that "upgrading" implies a movement upwards in the type-
    
+    hierarchy lattice.  Specifically, the type-specifier <type> must be
    
+    a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>).  Furthermore, if 
    
+    <type1> is a subtype of <type2>, then:
    
+            (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
    
+    must also be a subtype of:
    
+            (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).  
    
+    Note however, that two type-disjoint types can in fact be upgraded into 
    
+    the same thing.
    
+
    
+    Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
    
+    for the array; in particular, any documentation patterned after 
    
+    the sentence on p. 291 begining "This set may be larger than the 
    
+    set requested when the array was created; for example . . ." should
    
+    be embellished with this clarification.
    
+
    
+    Similarly, the type-specifier <type> must be a subtype of 
    
+    (UPGRADED-COMPLEX-PART-TYPE <type>).
    
+
    
+ *. Clarify that upgrading an array element-type is independent of any 
    
+    other property of arrays, such as rank, adjustability, fill-pointers, 
    
+    displacement etc.  For all such properties other than rank this should 
    
+    be obvious (since they are not expressible in the language of 
    
+    type-specifiers); but note that unless it is also independent of rank, 
    
+    it would not be consistently possible to displace arrays to those of 
    
+    differing rank.
    
+
    
+ *. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:  
    
+
    
+    For all type-specifiers <type1> and <type2> other than *, require 
    
+    (ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only 
    
+    if they refer to arrays of exactly the same specialized representation; 
    
+    and require them to be type-disjoint if and only if they refer to arrays 
    
+    of different, distinct specialized representations.  This definition
    
+    follows that implicitly prescribed in CLtL.
    
+
    
+    As a consequence of the preceding change to TYPEP and of the definition 
    
+    of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers 
    
+                (ARRAY <type1>)  and 
    
+                (ARRAY <type2>)
    
+    are type-equivalent if and only if
    
+                (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)  and
    
+                (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>) 
    
+    are type-equivalent.  This is another way of saying that `(ARRAY <type>)
    
+    and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
    
+    set of specialized array representations.
    
+
    
+    This defines the behavior of SUBTYPEP on array type-specifiers; namely:
    
+                (SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
    
+    is true if and only if
    
+                (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)  and
    
+                (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
    
+    are type-equivalent.
    
+
    
+ *. Define SUBTYPEP on COMPLEX type-specifiers as follows: 
    
+
    
+    For all type-specifiers <type1> and <type2> other than *, 
    
+            (SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
    
+    is  T T  if:
    
+      1. <type1> is a subtype of <type2>, or
    
+      2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
    
+         to (UPGRADED-COMPLEX-PART-TYPE '<type2>);  in this case,
    
+         (COMPLEX <type1>) and (COMPLEX <type2>) both refer to the 
    
+         same specialized representation.
    
+   The result is  NIL T  otherwise.
    
+
    
+ The small differences between the SUBTYPEP specification for ARRAY and 
    
+ for COMPLEX are necessary because there is no creation function for 
    
+ complexes which allows one to specify the resultant part type independently
    
+ of the actual types of the parts.  Thus in the case of COMPLEX, we must 
    
+ refer to the actual type of the parts, although a number can be a member 
    
+ of more than one type; e.g., 17 is of type (MOD 18) as well as of type
    
+ (MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
    
+ The form:
    
+     (SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
    
+ must be true in all implementations; but:
    
+     (SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
    
+ is true only in implementations that do not have a specialized array
    
+ representation for single-floats distinct from that for other floats.
    
+
    
+
    
+Examples:
    
+
    
+ Let <aet-x> and <aet-y> be two distinct type specifiers that are
    
+ definitely not type-equivalent in a given implementation, but for which
    
+ make-array will return an object of the same array type.  This will be
    
+ an implementation dependent search, but in every implementation that
    
+ the proposer has tested, there will be some such types; often,
    
+ (SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
    
+
    
+ Thus, in each case, both of the following forms return T T:
    
+
    
+  (subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
    
+            (array-element-type (make-array 0 :element-type '<aet-y>)))
    
+
    
+  (subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
    
+            (array-element-type (make-array 0 :element-type '<aet-x>)))
    
+
    
+ To eliminate the distinction between "for declaration" and "for
    
+ discrimination" both of the following should be true:
    
+
    
+  [A]
    
+   (typep (make-array 0 :element-type '<aet-x>)
    
+          '(array <aet-x>))
    
+   (typep (make-array 0 :element-type '<aet-y>)
    
+          '(array <aet-y>))
    
+
    
+ Since (array <aet-x>) and (array <aet-y>) are different names for
    
+ exactly the same set of objects, these names should be type-equivalent.
    
+ That implies that the following set of tests should also be true:
    
+
    
+  [B]
    
+   (subtypep '(array <aet-x>) '(array <aet-y>))
    
+   (subtypep '(array <aet-y>) '(array <aet-x>))
    
+
    
+ Additionally, to show that un-equivalent type-specifiers that use the
    
+ same specialized array type should be equivalent as element-type
    
+ specifiers, the following type tests should be true:
    
+
    
+  [C]
    
+   (typep (make-array 0 :element-type '<aet-y>)
    
+          '(array <aet-x>))
    
+   (typep (make-array 0 :element-type '<aet-x>)
    
+          '(array <aet-y>))
    
+
    
+
    
+Rationale:
    
+
    
+ This proposal legitimizes current practice, and removes the obscure and
    
+ un-useful distinction between type-specifiers "for declaration" and
    
+ "for discrimination".  The suggested changes to the interpretation of
    
+ array and complex type-specifiers follow from defining type-specifiers
    
+ as names for collections of objects, on TYPEP being a set membership
    
+ test, and SUBTYPEP a subset test on collections of objects.
    
+
    
+
    
+Current Practice:
    
+
    
+ Every vendor's implementation that the proposer has queried has a finite 
    
+ set of specialized array representations, such that two non-equivalent 
    
+ element types can be found that use the same specialized array 
    
+ representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
    
+ and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
    
+ tests [A] and [C] part 2; this is a consequence of implementing the
    
+ distinction between "for declaration" and "for discrimination".  Lucid
    
+ and Xerox both pass test [B], and the other implementations fail it.
    
+ The Explorer returns NIL for all six tests in [A], [B], and [C].
    
+
    
+ Allegedly, the PCLS implementation does no "upgrading"; each array
    
+ "remembers" exactly the type-specifier handed to the MAKE-ARRAY call
    
+ that created it.  Thus the test cases are not applicable to PCLS,
    
+ since the precondition cannot be met (i.e., find two non-type-equivalent
    
+ type-specifiers that are non-trivially upgraded by make-array).
    
+
    
+ The TI Explorer offers specialized representation for complexes;
    
+ part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.
    
+
    
+Cost to Implementors:
    
+
    
+ This proposal is an incompatible change to the current language
    
+ specification, but only a small amount of work should be required in
    
+ each vendor's implementation of TYPEP and SUBTYPEP.
    
+
    
+Cost to Users:
    
+
    
+ Because of the prevalence of confusion in this area, it seems unlikely
    
+ that any user code will have to be changed.  In fact, it is more likely
    
+ that some of the vendors will cease to get bug reports about MAKE-ARRAY
    
+ returning a result that isn't of "the obvious type".  Since the change
    
+ is incompatible, some user code might have to be changed.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+ Continuing confusion in the user community.
    
+
    
+
    
+Benefits:
    
+
    
+ It will greatly reduce confusion in the user community.  The fact that
    
+ (MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type 
    
+ (ARRAY <type>) has been very confusing to almost everyone.  
    
+
    
+ Portability of applications will be increased slightly, since
    
+ the behavior of 
    
+     (TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
    
+  will no longer be implementation-dependent. 
    
+
    
+
    
+Esthetics:
    
+
    
+ Reducing the confusing distinction between type-specifiers "for
    
+ declaration" and "for discrimination" is a simplifying step -- it is a
    
+ much simpler rule to state that the type-specifiers actually describe
    
+ the collections of data they purport to name.  Thus this is a step
    
+ towards increased elegance.
    
+
    
+
    
+Discussion:
    
+
    
+ This issue was prompted by a lengthy discussion on the Common Lisp
    
+ mailing list.  See for example a series of exchanges started on Thu, 
    
+ 17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
    
+ under the subject line of "Types in CL".  See also the exchange started 
    
+ Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
    
+ under the subject line of "TYPEP warp implications"
    
+
    
+ Although the types STRING,  BIT-VECTOR,  SIMPLE-STRING, and 
    
+ SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
    
+ specifically discussed in this proposal.  The reason is that 
    
+ they are not type-specifiers "that specialize", but are merely 
    
+ abbreviations as follows:
    
+   STRING             ==  (VECTOR STRING-CHAR)
    
+   SIMPLE-STRING      ==  (SIMPLE-ARRAY STRING-CHAR (*))
    
+   BIT-VECTOR         ==  (VECTOR BIT)
    
+   SIMPLE-BIT-VECTOR  ==  (SIMPLE-ARRAY BIT (*))
    
+ Thus their semantics could be affected only in an implementation that
    
+ doesn't support a specific "specialized storage" type for arrays of
    
+ bits and vectors of string-chars.  But in fact, every CL implementation 
    
+ must appear to support "specialized storage" for bit-arrays and strings,
    
+ even if it means nothing more than remembering the fact that such an
    
+ array was created with that element-type.  This is required in order
    
+ for strings, bit-vectors,  and bit-arrays to be disjoint datatypes 
    
+ (see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found 
    
+ in CLtL p.293, Section 17.4, and in CLtL p.299.)
    
+
    
+ We considered the possibility of flushing the permission to "upgrade";
    
+ for example, it could be made a requirement that:
    
+     (ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
    
+ always be equal to <type> (or, at least type-equivalent to <type>)
    
+ for all valid type specifiers <type>.  This has several problems: it
    
+ increases the storage requirement for many kinds of arrays, and hides
    
+ a relevant part of the underlying implementation for no apparently 
    
+ good reason.  However, it would increase portability, since it would be 
    
+ much more difficult, for example, to write a program that created an
    
+ array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it 
    
+ assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
    
+ Under this proposal, it is valid for an implementation of MAKE-ARRAY 
    
+ to have arrays "remember" the type-equivalence class of the original 
    
+ :element-type argument; such an implementation would satisfy all of 
    
+ the  constraints listed above.
    
+
    
+ We considered a suggestion to restrict the set of "known" array element 
    
+ types; this would gain portability at the expense of limiting the 
    
+ language.
    
+
    
+ We considered leaving out of the proposal the addition of the two
    
+ functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
    
+ But it was noted that every implementation of CL supports exactly
    
+ that functionality somewhere in its implementation of MAKE-ARRAY; and
    
+ exposing this to the user would be a good thing.  Furthermore, the
    
+ existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
    
+ on "upgrading" and SUBTYPEP implications easier.  Finally, there would
    
+ be no other way at all to pinpoint just how complex parts are upgraded,
    
+ since there is no type information available except for the actual
    
+ types of the parts.
    
+
    
+ Since this proposal contains the implication:
    
+     (ARRAY <type1>)  is-type-equivalent-to  (ARRAY <type2>)
    
+     ==> 
    
+      <type1>  is-type-equivalent-to  <type2>
    
+ then the question naturally arises "Does the reverse implication hold?"  
    
+ That is, should two non-EQ but type-equivalent type-specifiers <type1>
    
+ and <type2> always give rise to the same array types?   For example, 
    
+ consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these 
    
+ are type-equivalent (see CLtL section 2.1.3).  One may desire to implement 
    
+ (ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently.  Say, for example 
    
+ that the former is packed into 16-bit half-words, whereas the latter is 
    
+ packed into 32-bit words; but for either kind of packing, the result of 
    
+ AREF is an ordinary "single-float".  The whole point of the type-specifier
    
+ to make-array is merely to specify a packing technique for "packed float" 
    
+ arrays.  This "krinkle", however, will not be addressed by the proposal 
    
+ herein; it should simply be remembered that the implication above goes 
    
+ only one way, and is not an "if-and-only-if" link.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016.htm new file mode 100644 index 00000000..9b2549f0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ASSERT-ERROR-TYPE:ERROR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ASSERT-ERROR-TYPE:ERROR Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ASSERT-ERROR-TYPE:ERROR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016_w.htm new file mode 100644 index 00000000..4c2ead20 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss016_w.htm @@ -0,0 +1,99 @@ + + + +CLHS: Issue ASSERT-ERROR-TYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ASSERT-ERROR-TYPE Writeup

    + +
    Status:       Proposal ERROR accepted 12/91
    
+Issue:        ASSERT-ERROR-TYPE
    
+Forum:        Cleanup
    
+References:   ASSERT (Condition System, Revision #18, p27)
    
+Category:     CHANGE
    
+Edit history: 15-Mar-91, Version 1 by Pitman
    
+
    
+Problem Description:
    
+
    
+  The condition system proposal says that ASSERT signals SIMPLE-ERROR
    
+  if the datum is omitted.  This unnecessarily restricts an 
    
+  implementation's options.
    
+
    
+Proposal (ASSERT-ERROR-TYPE:ERROR):
    
+
    
+  Define that if the datum is omitted, ASSERT signals ERROR.
    
+
    
+Test Case:
    
+
    
+  (HANDLER-CASE (HANDLER-CASE (ASSERT NIL) (SIMPLE-ERROR 1)) (ERROR 2))
    
+
    
+  Under Conditions System revision #18, this must return 1.
    
+  Under proposal ASSERT-ERROR-TYPE:ERROR, this might return either 1 or 2.
    
+
    
+Rationale:
    
+
    
+  This leaves an implementation free to experiment with error types 
    
+  specific to assertions.  Since the user is free to specify whatever
    
+  type he needs, he can always work around any implementation-specific
    
+  type in any way he wants.
    
+
    
+Current Practice:
    
+
    
+  In Symbolics Genera 8.1, the test case returns 1.
    
+
    
+Cost to Implementors:
    
+
    
+  None.  (Since SIMPLE-ERROR is a subtype of ERROR, no change is forced.
    
+  This just adds flexibility to implementations which want to do this 
    
+  differently.
    
+
    
+Cost to Users:
    
+
    
+  Little or none.  There are probably very few people who are 
    
+  specifically doing HANDLER-CASE for SIMPLE-ERROR with the intent
    
+  of specifically catching ASSERT.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Implementations have their hands tied unnecessarily.
    
+
    
+Benefits:
    
+
    
+  Aesthetics.  Implementation flexibility.
    
+
    
+Aesthetics:
    
+
    
+  Makes language more consistent in that this was the only place where
    
+  SIMPLE-ERROR was forced in a situation where the user wasn't supplying
    
+  a format string.
    
+
    
+Discussion:
    
+
    
+  This issue was raised by Barrett several meetings ago, but was never
    
+  formally written up.
    
+
    
+  Pitman supports this.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017.htm new file mode 100644 index 00000000..0ac79285 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue ASSOC-RASSOC-IF-KEY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ASSOC-RASSOC-IF-KEY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ASSOC-RASSOC-IF-KEY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_m.htm new file mode 100644 index 00000000..5b403d2e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue ASSOC-RASSOC-IF-KEY Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue ASSOC-RASSOC-IF-KEY Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_w.htm new file mode 100644 index 00000000..d3b8f92b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss017_w.htm @@ -0,0 +1,104 @@ + + + +CLHS: Issue ASSOC-RASSOC-IF-KEY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ASSOC-RASSOC-IF-KEY Writeup

    + +
    Issue:        ASSOC-RASSOC-IF-KEY
    
+References:   ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
    
+              RASSOC-IF-NOT (p281)
    
+Category:     ENHANCEMENT
    
+Edit history: 22-Apr-87, Version 1 by Pitman
    
+              20-Nov-87, Versions 2,3 by Masinter
    
+              23-Nov-87, Version 4 by Masinter
    
+
    
+Problem Description:
    
+
    
+The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT do not
    
+mention a :KEY option, although ASSOC and RASSOC have one. 
    
+
    
+This is often reported as an inconsistency in Common Lisp.
    
+
    
+Proposal (ASSOC-RASSOC-IF-KEY:YES):
    
+
    
+Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
    
+If not supplied, it should default to #'IDENTITY as do the :KEY keywords for
    
+other -IF and -IF-NOT functions. The function, as with the :KEY argument for
    
+ASSOC and RASSOC, is applied to the CAR of the pair in the association list for
    
+ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
    
+RASSOC-IF-NOT.
    
+
    
+Documentation impact:
    
+
    
+A better description of the intent might be to say that the car /contains/ the
    
+key of the association, and by default the car /is/ the key of the association.
    
+
    
+Example:
    
+
    
+(assoc-if #'zerop pathnames :key #'pathname-version)
    
+
    
+could be used to search a list indexed by pathnames finding one with zero
    
+version. 
    
+
    
+Rationale:
    
+
    
+This is an inconsistency in the language that is simple to fix.
    
+
    
+Current Practice:
    
+
    
+Symbolics implements :KEY for the -IF and -IF-NOT assoc functions. Others follow
    
+the book and allow :KEY only for ASSOC.
    
+
    
+Cost to Common Lisp implementors:
    
+
    
+A small amount of additional code is necessary to support this in
    
+implementations not already offering it as an extension.
    
+
    
+Cost to Common Lisp users:
    
+
    
+The change is essentially upward compatible with user code.
    
+
    
+Benefits:
    
+
    
+This would make the set of -IF and -IF-NOT functions be more regular in their
    
+calling conventions.
    
+
    
+Aesthetics:
    
+
    
+All the other -IF and -IF-NOT variations of list operations omit the :TEST and
    
+:TEST-NOT keywords, but allow :KEY. For example, consider the family of MEMBER,
    
+MEMBER-IF, and MEMBER-IF-NOT. Although this introduces additional mechanism, it
    
+does so in a way that probably makes it easier to think about which functions do
    
+what, so it would likely be seen as a simplification.
    
+
    
+Discussion:
    
+
    
+The omission of :KEY in this situation in CLtL was probably an oversight.
    
+
    
+The cleanup committee supports this proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss018.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss018.htm new file mode 100644 index 00000000..c28db05e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss018.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue ASSOC-RASSOC-IF-KEY:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ASSOC-RASSOC-IF-KEY:YES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ASSOC-RASSOC-IF-KEY:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019.htm new file mode 100644 index 00000000..0b8faddc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue BOA-AUX-INITIALIZATION:ERROR-ON-READ Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue BOA-AUX-INITIALIZATION:ERROR-ON-READ Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue BOA-AUX-INITIALIZATION:ERROR-ON-READ:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019_w.htm new file mode 100644 index 00000000..ebdadfe0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss019_w.htm @@ -0,0 +1,167 @@ + + + +CLHS: Issue BOA-AUX-INITIALIZATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue BOA-AUX-INITIALIZATION Writeup

    + +
    Forum:		Public Review
    
+Issue:		BOA-AUX-INITIALIZATION
    
+References:	Loosemore's public review comment #26
    
+		Boa lambda lists, Section 3.4.6, page 3-48
    
+		DEFSTRUCT :TYPE slot option, page 8-4
    
+		DEFSTRUCT slot-initform, page 8-3
    
+                CLtL-2 p 482
    
+                Issue UNINITIALIZED-ELEMENTS
    
+Category:	CLARIFICATION/CHANGE
    
+Edit history:	26 Dec 1992, Version 1 by Loosemore
    
+Status:         Proposal ERROR-ON-READ failed 7-3 on letter ballot 93-302.
    
+		Proposal ERROR-ON-READ passed 7-0 at October 1993 meeting.
    
+
    
+
    
+Problem description:
    
+
    
+  In the discussion of BOA constructor lambda lists on page 3-48
    
+  says that, for a slot whose name is given as an &AUX variable
    
+  without an initialization form, the "slot is not initialized; its
    
+  initial value is implementation-defined."  The corresponding
    
+  passage from CLtL says the initial value is "undefined" rather
    
+  than "implementation-defined".
    
+
    
+  It is not clear whether and when errors about the uninitialized slot
    
+  might be detected.  If the slot is given an "implementation-defined"
    
+  value, for example, is it permissible for the implementation to
    
+  signal an error at instance creation time if the slot :TYPE for
    
+  the uninitialized slot doesn't match the type of the value that
    
+  particular implementation has chosen?  Or is it permissible for
    
+  implementations to signal an error if an attempt is later made to
    
+  read the slot's value before it has been explicitly assigned a 
    
+  (type-correct) value?
    
+
    
+
    
+Proposal (BOA-AUX-INITIALIZATION:ERROR-ON-READ):
    
+
    
+  Make BOA constructors with &AUX variables without an initialization
    
+  form treat the corresponding slots in the same way as slots defined 
    
+  without an slot-initform; the consequences are undefined if an attempt
    
+  is later made to read the slot's value before a value is explicitly 
    
+  assigned.
    
+
    
+  Clarify that, if such a slot has a :TYPE option specified, there can
    
+  be no type mismatch error when initialization of the slot is suppressed
    
+  in this way.
    
+
    
+
    
+Rationale:
    
+
    
+  This makes the treatment of uninitialized structure slots consistent.
    
+  It also makes it permissible for implementations to diagnose references
    
+  to uninitialized structure slots in high-safety code, which is helpful
    
+  in debugging.  (See issue UNINITIALIZED-ELEMENTS.)
    
+
    
+  The interpretation of the &AUX syntax in BOA constructors was carefully
    
+  chosen to permit the default structure slot initializations to be
    
+  overridden completely.  There are some circumstances -- such as when
    
+  setting up complicated circular data structures -- when there is
    
+  simply no appropriate value that could be used as a default.  While
    
+  one could simply specify the DEFSTRUCT definition without slot-initforms
    
+  for those slots to get the right behavior, one would also lose the 
    
+  benefit of type-checking on accesses to the slot since DEFSTRUCT
    
+  syntax allows one to specify the :TYPE option only if a slot-initform
    
+  is also specified.
    
+
    
+
    
+Current practice:
    
+
    
+  At least one implementation (CMU CL) signals a type mismatch error at
    
+  instance creation time if the slot type you specified doesn't match
    
+  that of the value that particular implementation has chosen to store
    
+  in these slots.
    
+
    
+  Other implementations either do no type checking, or defer type 
    
+  checking until when the slot's value is read.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Those implementations that now do type-checking at instance creation
    
+  time will have to be changed.  This is probably not a huge change.
    
+
    
+
    
+Cost to users:
    
+
    
+  Some user code may be broken by this change; but such code is already
    
+  nonportable.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Making the language more consistent is a good idea.
    
+
    
+
    
+Editorial impact:
    
+
    
+  Tweaking two sentences on page 3-48.
    
+
    
+
    
+Discussion:
    
+
    
+  The consensus of the public review committee was that this proposal
    
+  was the best of the alternatives.
    
+
    
+  Clarifying that we really want the initial value of these slots to be
    
+  "implementation-defined" would have the problem that it would be
    
+  impossible for users to portably specify a slot :TYPE other than T.
    
+
    
+  The possibility of having the standard specify an explicit value (NIL) 
    
+  for uninitialized slots was also mentioned, but this was considered 
    
+  unaesthetic; it would still weaken type-checking to some extent, make 
    
+  it harder to detect uninitialized slots, and be inconsistent with other
    
+  parts of the language.
    
+
    
+  Rob MacLachlan says, about CMU CL's behavior:
    
+
    
+    Our interpretation is that the slot type declaration must encompass
    
+    all values that the slot can be created with.  This is important,
    
+    since we want all possible values of the slot accessor to be of that
    
+    type.
    
+
    
+  (In other words, it appears they want to do type-checking when the
    
+  slots are written rather than when they are read, since writing is
    
+  a less frequent operation.)  
    
+
    
+
    
+
    
+
    
+
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020.htm new file mode 100644 index 00000000..a4777391 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue BREAK-ON-WARNINGS-OBSOLETE:REMOVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue BREAK-ON-WARNINGS-OBSOLETE:REMOVE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue BREAK-ON-WARNINGS-OBSOLETE:REMOVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020_w.htm new file mode 100644 index 00000000..3fb2e38c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss020_w.htm @@ -0,0 +1,92 @@ + + + +CLHS: Issue BREAK-ON-WARNINGS-OBSOLETE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue BREAK-ON-WARNINGS-OBSOLETE Writeup

    + +
    Status:       Passed, as amended, Mar 89 X3J13
    
+Issue:        BREAK-ON-WARNINGS-OBSOLETE
    
+Forum:	      Cleanup
    
+References:   *BREAK-ON-WARNINGS* (CLtL p432, CL Condition System p40)
    
+	      *BREAK-ON-SIGNALS* (CL Condition System p25)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 07-Mar-89, Version 1 by Pitman
    
+			 8-Apr-89, Version 2 by Masinter (as amended; update discussion)
    
+
    
+Problem Description:
    
+
    
+  With the advent of *BREAK-ON-SIGNALS*, *BREAK-ON-WARNINGS* is
    
+  redundant and unnecessary.
    
+
    
+Proposal (BREAK-ON-WARNINGS-OBSOLETE:REMOVE):
    
+
    
+  Remove *BREAK-ON-WARNINGS*.
    
+
    
+Test Case:
    
+
    
+  N/A
    
+
    
+Rationale:
    
+
    
+  This will lead to simplification of the description of WARN.
    
+
    
+  Not only are the two variables overkill, but they have an effect
    
+  in an identifiably but uselessly distinct place.
    
+
    
+Current Practice:
    
+
    
+  Most have *BREAK-ON-WARNINGS*.
    
+
    
+Cost to Implementors:
    
+
    
+  slight.
    
+
    
+Cost to Users:
    
+
    
+  Users will have to write (SETQ *BREAK-ON-SIGNALS* 'WARNING)
    
+  rather than (SETQ *BREAK-ON-WARNINGS* T).
    
+
    
+  Since this is mainly done interactively and not in programs,
    
+  the cost is slight.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The definition of WARN will be gratuitously cluttered.
    
+
    
+Benefits:
    
+
    
+  Cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  Slight improvement.
    
+
    
+Discussion:
    
+
    
+  Pitman thinks this is a good idea, but doesn't think a lot of time
    
+  should be wasted discussing the issue if there is strong opposition.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021.htm new file mode 100644 index 00000000..424891e4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021_w.htm new file mode 100644 index 00000000..7a9aa574 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss021_w.htm @@ -0,0 +1,177 @@ + + + +CLHS: Issue BROADCAST-STREAM-RETURN-VALUES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue BROADCAST-STREAM-RETURN-VALUES Writeup

    + +
    Issue:        BROADCAST-STREAM-RETURN-VALUES
    
+Forum:        X3J13 Letter Ballot
    
+References:   BROADCAST-STREAM (X3J13/92-102, p21-7)
    
+Category:     CLARIFICATION
    
+Edit history: 16-Jun-93, Version 1 by Pitman
    
+              17-Jun-93, Version 2 by Loosemore
    
+			(fix bugs, separate incompatible changes)
    
+Status:	      Proposal CLARIFY-MINIMALLY passed 9-2 on letter ballot 93/304
    
+
    
+Problem Description:
    
+
    
+  The description of the return value for output operations applied 
    
+  to broadcast streams doesn't work well for certain kinds of operations,
    
+  STREAM-ELEMENT-TYPE being an example.
    
+
    
+  The zero-argument stream case is important, too, because 
    
+    (MAKE-BROADCAST-STREAM)
    
+  is a commonly-used portable way to create a null output stream.
    
+
    
+  Proposal CLARIFY-MINIMALLY makes explicit the "results from the last 
    
+  stream" rule from CLtL, and specifies behavior for the cases where there
    
+  are no streams.  Proposal INCOMPATIBLE-CHANGES replaces this rule with
    
+  behavior that makes more sense.
    
+
    
+
    
+Proposal (BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY):
    
+
    
+  STREAM-ELEMENT-TYPE returns the value from the last component stream, or
    
+  T if there are no streams.
    
+
    
+  FRESH-LINE returns the value from the last component stream, or NIL
    
+  if there are no streams.
    
+
    
+  The following functions return the value from the last component stream,
    
+  or the indicated value if there are no component streams:
    
+
    
+    FILE-LENGTH [0]
    
+    FILE-POSITION [0]
    
+    FILE-STRING-LENGTH [1]
    
+    STREAM-EXTERNAL-FORMAT [:DEFAULT]
    
+
    
+  STREAMP and OUTPUT-STREAM-P always return true for broadcast streams.
    
+  OPEN-STREAM-P tests whether the broadcast stream is open, not whether its
    
+  component streams are open.  INPUT-STREAM-P and INTERACTIVE-STREAM-P 
    
+  return an implementation-defined boolean value.
    
+
    
+  For these input operations, the consequences are undefined if the indicated
    
+  operation is performed.  (However, implementations that wish to are permitted
    
+  to extend the behavior.)
    
+  
    
+    READ-BYTE
    
+    READ-CHAR
    
+    READ-CHAR-NO-HANG
    
+    PEEK-CHAR
    
+    UNREAD-CHAR
    
+    READ-LINE
    
+    LISTEN
    
+    CLEAR-INPUT
    
+
    
+
    
+Proposal (BROADCAST-STREAM-RETURN-VALUES:INCOMPATIBLE-CHANGES):
    
+
    
+  STREAM-ELEMENT-TYPE returns the type-specifier-equivalent of 
    
+  `(AND ,x1 ,x2 ...), where each Xi is the result for each component stream.
    
+
    
+  FRESH-LINE returns the OR of the results for each component stream.
    
+  
    
+  For the following, if the streams are of the same element type and 
    
+  individually return the same result, that result is returned.  
    
+  Otherwise, the consequences are undefined.  (If there are no streams,
    
+  the result shown in brackets is returned.)
    
+  
    
+    FILE-LENGTH [0]
    
+    FILE-POSITION [0]
    
+    FILE-STRING-LENGTH [1]
    
+    STREAM-EXTERNAL-FORMAT [:DEFAULT]
    
+
    
+  STREAMP and OUTPUT-STREAM-P always return true for broadcast streams.
    
+  OPEN-STREAM-P tests whether the broadcast stream is open, not whether its
    
+  component streams are open.  INPUT-STREAM-P and INTERACTIVE-STREAM-P 
    
+  return an implementation-defined boolean value.
    
+
    
+  For these input operations, the consequences are undefined if the indicated
    
+  operation is performed.  (However, implementations that wish to are permitted
    
+  to extend the behavior.)
    
+  
    
+    READ-BYTE
    
+    READ-CHAR
    
+    READ-CHAR-NO-HANG
    
+    PEEK-CHAR
    
+    UNREAD-CHAR
    
+    READ-LINE
    
+    LISTEN
    
+    CLEAR-INPUT
    
+  
    
+
    
+Test Case:
    
+
    
+  Not provided.
    
+
    
+Rationale:
    
+
    
+  These values provide plausible defaults for the cases where there is likely
    
+  to be no controversy, without trying to define the cases in the gray areas.
    
+
    
+Current Practice:
    
+
    
+  Not provided.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably relatively small.
    
+
    
+Cost to Users:
    
+
    
+  None.  This change doesn't affect anything already guaranteed to the user.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Broadcast streams are hard to use reliably in many situations.
    
+
    
+Benefits:
    
+
    
+  Better program portability.
    
+
    
+Editorial Impact:
    
+
    
+  Small.  A number of small, localized edits.
    
+
    
+Aesthetics:
    
+
    
+  Mostly neutral.
    
+
    
+Discussion:
    
+  
    
+  This addresses Barrett comment #12 (First Public Review).
    
+  Pitman thinks it's a good idea to clarify this somehow and is mostly
    
+  happy with the above, but might be satisfied with other variations on
    
+  this theme, as long as they were intuitive, implementable, etc.
    
+
    
+  Loosemore notes that we have already approved a previous issue
    
+  (PATHNAME-STREAM) to make coercing a broadcast stream to a pathname 
    
+  have undefined consequences.  Likewise, we have already decided that
    
+  calling CLOSE on a broadcast stream closes only the broadcast stream
    
+  and not its component streams.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022.htm new file mode 100644 index 00000000..21aed2c8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue BUTLAST-NEGATIVE:SHOULD-SIGNAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue BUTLAST-NEGATIVE:SHOULD-SIGNAL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue BUTLAST-NEGATIVE:SHOULD-SIGNAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022_w.htm new file mode 100644 index 00000000..7d87098e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss022_w.htm @@ -0,0 +1,93 @@ + + + +CLHS: Issue BUTLAST-NEGATIVE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue BUTLAST-NEGATIVE Writeup

    + +
    Issue:        BUTLAST-NEGATIVE
    
+Forum:	      Editorial
    
+References:   BUTLAST (p271), NBUTLAST (p271)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 01-Mar-91, Version 1 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  What happens if the second argument to BUTLAST and NBUTLAST is negative?
    
+
    
+Proposal (BUTLAST:SHOULD-SIGNAL):
    
+
    
+  Specify that if the second argument, N, to BUTLAST or NBUTLAST is negative, 
    
+  then an error `should be signalled'.
    
+
    
+Test Cases:
    
+
    
+  1. (BUTLAST '(A B C) -2)
    
+
    
+  2. (LET ((X (LIST 'A 'B 'C)))
    
+       (NBUTLAST X -2))
    
+
    
+Rationale:
    
+
    
+  Mostly this precludes implementations from adopting other, 
    
+  variant interpretations.
    
+
    
+Current Practice:
    
+
    
+  1. Symbolics Genera returns (A B C NIL NIL).
    
+
    
+  2. Symbolics Genera signals an error.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  None.  Portable programs cannot currently rely on any particular 
    
+  behavior.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Users would be confused about what to expect because implementations might
    
+  adopt creative interpretations (such as Genera's) which are not supported
    
+  in other implementations and so become a barrier to portability.
    
+
    
+Benefits:
    
+
    
+  Tighter spec.
    
+
    
+Aesthetics:
    
+
    
+  Genera's alternate interpretation of BUTLAST is arguably aesthetic, but
    
+  does not extend well to NBUTLAST.  The interpretation proposed here makes
    
+  BUTLAST and NBUTLAST more consistent.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023.htm new file mode 100644 index 00000000..b0850765 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CHANGE-CLASS-INITARGS:PERMIT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHANGE-CLASS-INITARGS:PERMIT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHANGE-CLASS-INITARGS:PERMIT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023_w.htm new file mode 100644 index 00000000..7d40f070 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss023_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue CHANGE-CLASS-INITARGS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CHANGE-CLASS-INITARGS Writeup

    + +
    Issue:          CHANGE-CLASS-INITARGS
    
+Reference:      X3J13/92-102, dpANS 12.24
    
+                  CHANGE-CLASS (p.7-38)
    
+                  UPDATE-INSTANCE-FOR-DIFFERENT-CLASS (p.7-34)
    
+                  MAKE-INSTANCE (p.7-50)
    
+                  Section 7.1.2 Declaring the Validity of Initialization
    
+                    Arguments (p.7.2)
    
+                  Section 7.2.2 Initializing Newly Added Local Slots (p.7-9)
    
+                X3J13/92-2513, Kim Barrett comment #13
    
+                AMOP (p.33, p.310)
    
+Category:       Change
    
+Edit History:   Version 1, 8/31/91, Kim Barrett
    
+                Version 2, 9/6/91, Kim Barrett (Moon's comments)
    
+                Version 3, 1/7/93, Kim Barrett (update references)
    
+Status:         Proposal PERMIT passed 7-1, March 1993
    
+
    
+Problem Description:
    
+
    
+ Because CHANGE-CLASS does not accept initargs, certain kinds of instance
    
+ updates must now go through a two-step process of first calling CHANGE-CLASS
    
+ and then calling REINITIALIZE-INSTANCE.  If CHANGE-CLASS accepted initargs,
    
+ the explicit reinitialization step would be unnecessary.
    
+
    
+Proposal (CHANGE-CLASS-INITARGS:PERMIT):
    
+
    
+ 1. Change the syntax for CHANGE-CLASS to
    
+
    
+        CHANGE-CLASS instance new-class &key &allow-other-keys
    
+
    
+ and modify the two method signatures currently specified accordingly:
    
+
    
+        CHANGE-CLASS
    
+           (instance standard-object) (new-class standard-class) &rest initargs
    
+
    
+        CHANGE-CLASS (instance t) (new-class symbol) &rest initargs
    
+
    
+ with the initargs parameter described in the same way as the corresponding
    
+ parameter to UPDATE-INSTANCE-FOR-DIFFERENT-CLASS.
    
+
    
+ 2. Change the last paragraph of the description of CHANGE-CLASS to include
    
+ the initargs in the arguments passed to the reinvocation, by adding the
    
+ phrase "and the \param{initargs}" to the end of the last sentence.
    
+
    
+ 3. Change the description of the process by which newly added local slots are
    
+ initialized to specify that CHANGE-CLASS also passes the initargs to
    
+ UPDATE-INSTANCE-FOR-DIFFERENT-CLASS.  This involves adding mention of the
    
+ initargs to the 2nd paragraph of "Initializing Newly Added Local Slots" and
    
+ striking the 3rd paragraph.
    
+
    
+Editorial Impact:
    
+
    
+ Several small changes to one function description and one small concept
    
+ section. 
    
+
    
+Rationale:
    
+
    
+ Makes CHANGE-CLASS more consistant with other parts of the various
    
+ initialization protocols, and removes the need for a somewhat awkward idiom.
    
+
    
+Current Practice:
    
+
    
+ Lucid 4.0 and Apple MCL 2.0p2 appear to follow the current specification,
    
+ with CHANGE-CLASS not accepting initargs.
    
+
    
+ Chestnut's Lisp-to-C translator contains a compile-time switch that permits
    
+ the user to select whether CHANGE-CLASS accepts initargs or not.
    
+
    
+Cost to Implementors:
    
+
    
+ The generic function definition and any methods on CHANGE-CLASS would need to
    
+ be changed to deal with the initargs.  Implementors might want to change some
    
+ places that might currently call CHANGE-CLASS followed by
    
+ REINITIALIZE-INSTANCE to just call CHANGE-CLASS with initargs, and this might
    
+ require some other changes as well.  The number of occurances of CHANGE-CLASS
    
+ is likely small, so it probably isn't too difficult.
    
+
    
+Cost to Users:
    
+
    
+ Similar to the cost to implementors.  However, users of multiple
    
+ implementations will also have to deal with the different rates at which
    
+ vendors incorporate this change.
    
+
    
+Performance Impact:
    
+
    
+ None.
    
+
    
+Aesthetics:
    
+
    
+ Eliminating the need for an awkward idiom is an improvement.
    
+
    
+Discussion:
    
+
    
+ This issue was raised informally some time ago by Gregor and others, but it
    
+ appears that no formal proposal was ever made.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024.htm new file mode 100644 index 00000000..860b024a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHAR-NAME-CASE:X3J13-MAR-91 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHAR-NAME-CASE:X3J13-MAR-91 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHAR-NAME-CASE:X3J13-MAR-91:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024_w.htm new file mode 100644 index 00000000..bfa7b3ae --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss024_w.htm @@ -0,0 +1,223 @@ + + + +CLHS: Issue CHAR-NAME-CASE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CHAR-NAME-CASE Writeup

    + +
    Issue:        CHAR-NAME-CASE
    
+Forum:	      Editorial
    
+References:   CHAR-NAME (p242), NAME-CHAR (p243), #\ (p353)
    
+Category:     Clarification
    
+Edit history: 01-Mar-91, Version 1 by Pitman
    
+	      08-Apr-91, Version 2 by Pitman
    
+Status:	      X3J13 passed option X3J13-MAR-91 on a 9-3 vote, March 1991.
    
+
    
+Problem Description:
    
+
    
+  In what case is a char name?  Specifically,
    
+
    
+  1. Which of (NAME-CHAR "SPACE"), (NAME-CHAR "Space"), (NAME-CHAR "space")
    
+     is a legitimate way to name the Space character?  [CLtL seems to 
    
+     make this clear, but then later says things that make one wonder.]
    
+
    
+  2. Does (CHAR-NAME #\Space) yield "Space", "SPACE, or "space" ?
    
+
    
+  CLtL, p353, says:
    
+
    
+      #\name reads in a character object whose name is name
    
+      (actually, whose name is (string-upcase name); therefore the
    
+      syntax is case insensitive).
    
+
    
+  This would seem to imply that (CHAR-NAME #\Space) => "SPACE"
    
+  and further that only because of the syntax does lookup of
    
+  #\Space succeed, which would imply that (NAME-CHAR "Space")
    
+  should fail.
    
+
    
+  CLtL, p243 (for NAME-CHAR), says:
    
+
    
+      If the name is the same as the name of a character object (as 
    
+      determined by STRING-EQUAL), that object is returned.
    
+
    
+  CLtL, p242 (for CHAR-NAME), says:
    
+
    
+      Graphic characters may or may not have names.
    
+
    
+  This would seem to `license' an implementation to give names to chars
    
+  like "A" and "$" if they wanted.  But that can't really work in
    
+  general because "A" and "a" if compared by STRING-EQUAL will seem 
    
+  the same, when in fact two different characters are almost surely 
    
+  implied.
    
+
    
+Proposal (CHAR-NAME-CASE:X3J13-MAR-91):
    
+
    
+ Specify that all character names are two or more characters long.
    
+
    
+ Specify that CHAR-NAME returns names of characters in the case
    
+ mentioned in the description of CHAR-NAME (i.e., "Tab", "Page",
    
+ "Rubout", "Linefeed", "Return", "Backspace", "Newline", "Space").
    
+
    
+Proposal (CHAR-NAME-CASE:ANY-IN-CAPITALIZE-OUT):
    
+
    
+  1. Define that NAME-CHAR is case-sensistive for names one character long,
    
+     but case-insensitive for longer names.
    
+
    
+  2. Define that if CHAR-NAME returns a string, that string is either
    
+	  a long name (a string of length greater than one) in 
    
+	  capitalized (i.e., uppercase initial) format
    
+      OR  a short name (a string one character long) which contains only
    
+	  one character, which has the same character code as the argument
    
+	  to CHAR-NAME.
    
+
    
+  Test case:
    
+
    
+   1. a. (NAME-CHAR "SPACE") => #\Space
    
+      b. (NAME-CHAR "Space") => #\Space
    
+      c. (NAME-CHAR "space") => #\Space  
    
+      d. (MEMBER (NAME-CHAR "A") '(NIL #\A)) => true
    
+      e. (MEMBER (NAME-CHAR "a") '(NIL #\a)) => true
    
+
    
+   2. a. (EQUAL (CHAR-NAME #\Space) "Space") => true
    
+      b. (MEMBER (CHAR-NAME #\a) '(NIL "a") :test #'EQUAL) => true
    
+      c. (MEMBER (CHAR-NAME #\A) '(NIL "A") :test #'EQUAL) => true
    
+
    
+  Rationale:
    
+
    
+   A primary purpose of these operators is to support input 
    
+   (e.g., the #\ reader macro) and and output (e.g., PRIN1 and 
    
+   FORMAT's ~@C) of characters.
    
+
    
+   1. It would be confusing for "Space" and "SPACE" to map to different
    
+      characters, and just plain frustrating for one to be valid
    
+      while the other was useless.
    
+
    
+   2. It is most useful for this to return a known case so that users
    
+      who care about the presentation are saved from calling STRING-UPCASE,
    
+      STRING-CAPITALIZE, or STRING-DOWNCASE even when the result might 
    
+      already come back that way.  The most common thing to do with a name
    
+      is to print it (e.g., when printing a character), so capitalization
    
+      makes the most sense.
    
+
    
+Proposal (CHAR-NAME-CASE:CASE-SENSITIVE):
    
+
    
+  1. Define that NAME-CHAR is case-sensitive.
    
+
    
+  2. Define that CHAR-NAME returns the names "Space" and "Newline"
    
+     (and "Rubout", "Page", "Tab", "Backspace", "Return", and "Linefeed"
    
+      if they are supported by the implementation) in uppercase initial.
    
+
    
+  3. Define that #\ is case-sensitive.
    
+
    
+  4. Define that the names "SPACE" and "space" are synonyms for "Space".
    
+     Define that the names "NEWLINE" and "newline" are synonyms for "Newline".
    
+     And likewise for "Rubout", "Page", "Tab", "Backspace", "Return",
    
+     and "Linefeed" if they are supported.
    
+
    
+  Test case:
    
+
    
+   1. a. (NAME-CHAR "SPACE") => #\Space
    
+      b. (NAME-CHAR "Space") => NIL
    
+      c. (NAME-CHAR "Space") => NIL
    
+      d. (MEMBER (NAME-CHAR "A") '(NIL #\A)) => true
    
+      e. (MEMBER (NAME-CHAR "a") '(NIL #\a)) => true
    
+
    
+   2. a. (EQUAL (CHAR-NAME #\Space) "SPACE") => true
    
+      b. (MEMBER (CHAR-NAME #\a) '(NIL "a") :test #'EQUAL) => true
    
+      c. (MEMBER (CHAR-NAME #\A) '(NIL "A") :test #'EQUAL) => true
    
+
    
+  Rationale:
    
+
    
+   1. This leaves flexibility for other languages or notations
    
+      which have long names for glyphs that make some kind of case.
    
+      e.g.,
    
+	    (NAME-CHAR "ALPHA")
    
+      might want to be distinguished from
    
+	    (NAME-CHAR "alpha")
    
+      in Greek, with the former representing an uppercase character
    
+      and the latter representing a lowercase character.
    
+
    
+      The choice of uppercase initial means that when printing #\xxx,
    
+      no case conversion is needed.  Saving the time and in some
    
+      implementations the space required to do case conversion.
    
+
    
+   2. This assures that (NAME-CHAR (CHAR-NAME x)) => x, 
    
+      when (CHAR-NAME x) is not NIL.
    
+
    
+   3. This is necessary in order for #\ALPHA and #\alpha to be 
    
+      distinguishable.
    
+
    
+   4. This keeps compatibility concerns for existing usages of
    
+      #\space, #\SPACE, #\newline, and #\NEWLINE from becoming
    
+      the overwhelming issue.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera implements ANY-IN-CAPITALIZE-OUT.
    
+
    
+Cost to Implementors:
    
+
    
+  Both proposals are probably relatively cheap to implement.
    
+
    
+Cost to Users:
    
+
    
+  ANY-IN-CAPITALIZE-OUT is probably very low cost because it is 
    
+  more tolerant of deviations which almost surely already exists between
    
+  implementations, and among users who have made various assumptions
    
+  about what implementations might or should do.
    
+
    
+  CASE-SENSITIVE is a slightly incompatible change, but
    
+  probably a lot of programs don't use either of these functions.
    
+  Of those that do, some usages don't depend on anything other
    
+  than that (NAME-CHAR (CHAR-NAME x)) will work.  In any case, most
    
+  applications that uses these are probably fairly easily to check
    
+  by hand even though mechanical checking probably would not work 
    
+  very well.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Divergence among implementations.  Potential portability problems
    
+  from skews of interpretations.  New implementations would not know
    
+  clearly what their rights and responsibilities were.
    
+
    
+Benefits:
    
+
    
+  A clearer specification.
    
+
    
+Aesthetics:
    
+
    
+  ANY-IN-CAPITALIZE-OUT is less aesthetic because it has a special
    
+  case for one-character strings.
    
+
    
+  CASE-SENSITIVE is generally more aesthetic.
    
+
    
+Discussion:
    
+
    
+  KMP thinks that mostly it's a good idea to resolve this clearly one
    
+  way or another, and isn't incredibly fussy about the details.  He has
    
+  a mild preference for proposal CASE-SENSITIVE because it leaves the
    
+  greatest flexibility to the international community which has the
    
+  English alphabet forced upon them all too often already.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025.htm new file mode 100644 index 00000000..4232ace0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CHARACTER-LOOSE-ENDS:FIX Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-LOOSE-ENDS:FIX Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-LOOSE-ENDS:FIX:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025_w.htm new file mode 100644 index 00000000..2f99534f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss025_w.htm @@ -0,0 +1,98 @@ + + + +CLHS: Issue CHARACTER-LOOSE-ENDS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CHARACTER-LOOSE-ENDS Writeup

    + +
    Issue:         CHARACTER-LOOSE-ENDS
    
+
    
+References:    CLtL p.354, pp.51-2
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon (for Steele)
    
+
    
+Problem description:
    
+
    
+  The issues passed on the character proposal did not explicitly address
    
+  the following, but they no longer make sense in light of the new
    
+  character scheme that has been adopted.
    
+
    
+  The #nnn\x reader syntax creates a character with font attribute nnn,
    
+  but there is no longer a font attribute.
    
+
    
+  COERCE coerces an integer to a character by calling INT-CHAR, but the
    
+  INT-CHAR function no longer exists.
    
+
    
+  This is Symbolics issue #26.
    
+
    
+Proposal (CHARACTER-LOOSE-ENDS:FIX):
    
+
    
+  Remove the #nnn\x reader syntax; an implementation can define it as an
    
+  extension.
    
+
    
+  Remove coercion from integer to character.
    
+
    
+Rationale:
    
+
    
+  Presumably the character subcommittee simply overlooked these points and
    
+  the above proposal would have passed with the other character proposals
    
+  if it had been proposed.
    
+
    
+Current practice:
    
+
    
+  I don't know.
    
+
    
+Cost to Implementors:
    
+
    
+  Easy.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  These two features will still be in the language, but their specification
    
+  will not make any sense.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Consistent language.
    
+
    
+Esthetics:
    
+
    
+  Consistent language.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026.htm new file mode 100644 index 00000000..096778ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_m.htm new file mode 100644 index 00000000..c9957e1a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue CHARACTER-PROPOSAL Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_w.htm new file mode 100644 index 00000000..40f04af6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss026_w.htm @@ -0,0 +1,389 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CHARACTER-PROPOSAL Writeup

    + +
    This is KMP's plain-text transcription of the issues which comprise
    
+the Character Proposal.  This isn't what was voted on, but it may be
    
+easier to use than the one that was, since it's not full of TeX codes.
    
+================================================================================
    
+
    
+Proposal 2.0.1: [Passed 03/89]
    
+
    
+ The terminology introduced in this proposal will be included
    
+ in the language specification at the discretion of the editor.
    
+
    
+Proposal 2.1.1: [Alternative A, Passed as Modified 03/89]
    
+
    
+ Remove all discussion of attributes from
    
+ the language specification.  Add the following discussion:
    
+   ``Earlier versions of Common LISP incorporated FONT and BITS as
    
+     attributes of character objects.  These and other supported
    
+     attributes are considered implementation-defined attributes and
    
+     if supported by an implementation effect the action of selected
    
+     functions.''
    
+ All types, constants and functions dealing with the BITS and
    
+ FONT attributes are either removed or modified as follows:
    
+
    
+   * Modify CHAR-=: If two characters differ in any implementation-defined
    
+     attributes, then they are not CHAR-=.
    
+
    
+   * Modify CHAR-<: If two characters have identical implementation-defined
    
+     attributes, then their ordering by CHAR< is consistent with the
    
+     numerical ordering by the predicate < on their code. (Similarly for
    
+     CHAR>, CHAR>= and CHAR<=.)
    
+
    
+   * Modify CHAR-EQUAL: The effect, if any, on CHAR-EQUAL of each 
    
+     implementation-defined attribute has to be specified as part of the
    
+     definition of that attribute (and similarly for CHAR-NOT-EQUAL,
    
+     CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP).
    
+
    
+   * Modify CHAR-UPCASE and CHAR-DOWNCASE: The effect of CHAR-UPCASE and
    
+     CHAR-DOWNCASE is to preserve implementation-defined attributes.
    
+
    
+   * Modify READ: It is implementation dependent which attributes are
    
+     removed from symbol names. It is implementation dependent which
    
+     attributes are removed from characters within double quotes.
    
+
    
+   * Modify INTERN: It is implementation dependent which 
    
+     implementation-defined attributes are removed. 
    
+
    
+   * Modify DIGIT-CHAR: remove the optional FONT argument.
    
+
    
+   * Modify CODE-CHAR: remove the optional FONT and BIT arguments.
    
+
    
+   * Remove CHAR-FONT-LIMIT
    
+
    
+   * Remove CHAR-BITS-LIMIT
    
+
    
+   * Remove INT-CHAR
    
+
    
+   * Remove CHAR-INT
    
+     <<This removal is later rescinded by 2.1.2. See below. -kmp 2-Aug-89>>
    
+
    
+   * Remove CHAR-BITS
    
+
    
+   * Remove CHAR-FONT
    
+
    
+   * Remove MAKE-CHAR
    
+
    
+   * Remove CHAR-CONTROL-BIT
    
+
    
+   * Remove CHAR-META-BIT
    
+
    
+   * Remove CHAR-SUPER-BIT
    
+
    
+   * Remove CHAR-HYPER-BIT
    
+
    
+   * Remove CHAR-BIT
    
+
    
+   * Remove SET-CHAR-BIT
    
+
    
+   * Remove STRING-CHAR and STRING-CHAR-P
    
+
    
+   * Modify readtable: If implementation-defined attributes are supported,
    
+     an implementation need not (but may) allow for such characters to have
    
+     syntax descriptions in the readtable. Otherwise, all characters are
    
+     representable in the readtable.
    
+
    
+Proposal 2.1.2: [Alternative B, Passed as Modified 03/89]
    
+
    
+ This is identical to all of Alternative A (above) except that the function
    
+ CHAR-INT is retained. CHAR-INT returns a non-negative integer encoding the
    
+ character object.  The manner in which the integer is computed is 
    
+ implementation dependent. In contrast to SXHASH, the result is not
    
+ guaranteed independent of the particular "incarnation" or "core image".
    
+
    
+Proposal 2.2.1: [Passed 03/89]
    
+
    
+ The discussion of standard characters is replaced by the following:
    
+
    
+  Common LISP requires all implementations to support and document
    
+  a STANDARD character subrepertoire.  The Common LISP standard character
    
+  subrepertoire consists of a newline, #\Newline; the graphic space
    
+  character #\Space; and the following additional ninety-four graphic
    
+  characters or their equivalents:
    
+
    
+  Note: #\Space and #\Newline are omitted.  Graphic labels and 
    
+   descriptions are from ISO 6937/2.  The first letter of the
    
+   graphic Id categorizes the character as follows:
    
+   L - Latin, N - Numeric, S - Special.
    
+
    
+  Id   Glyph    Name or description     Id   Glyph    Name or description
    
+
    
+  LA01   a      small a                 ND01   1      digit 1
    
+  LA02   A      capital A               ND02   2      digit 2
    
+  LB01   b      small b                 ND03   3      digit 3
    
+  LB02   B      capital B               ND04   4      digit 4
    
+  LC01   c      small c                 ND05   5      digit 5
    
+  LC02   C      capital C               ND06   6      digit 6
    
+  LD01   d      small d                 ND07   7      digit 7
    
+  LD02   D      capital D               ND08   8      digit 8
    
+  LE01   e      small e                 ND09   9      digit 9
    
+  LE02   E      capital E               ND10   0      digit 0
    
+  LF01   f      small f                 SC03   $      dollar sign
    
+  LF02   F      capital F               SP02   !      exclamation mark
    
+  LG01   g      small g                 SP04   "      quotation mark
    
+  LG02   G      capital G               SP05   '      apostrophe
    
+  LH01   h      small h                 SP06   (      left parenthesis
    
+  LH02   H      capital H               SP07   )      right parenthesis
    
+  LI01   i      small i                 SP08   ,      comma
    
+  LI02   I      capital I               SP09   _      low line
    
+  LJ01   j      small j                 SP10   -      hyphen or minus sign
    
+  LJ02   J      capital J               SP11   .      full stop, period
    
+  LK01   k      small k                 SP12   /      solidus
    
+  LK02   K      capital K               SP13   :      colon
    
+  LL01   l      small l                 SP14   ;      semicolon
    
+  LL02   L      capital L               SP15   ?      question mark
    
+  LM01   m      small m                 SA01   +      plus sign
    
+  LM02   M      capital M               SA03   <      less-than sign
    
+  LN01   n      small n                 SA04   =      equals sign
    
+  LN02   N      capital N               SA05   >      greater-than sign
    
+  LO01   o      small o                 SM01   #      number sign
    
+  LO02   O      capital O               SM02   %      percent sign
    
+  LP01   p      small p                 SM03   &      ampersand
    
+  LP02   P      capital P               SM04   *      asterisk
    
+  LQ01   q      small q                 SM05   @      commercial at
    
+  LQ02   Q      capital Q               SM06   [      left square bracket
    
+  LR01   r      small r                 SM07   \      reverse solidus
    
+  LR02   R      capital R               SM08   ]      right square bracket
    
+  LS01   s      small s                 SM11   {      left curly bracket
    
+  LS02   S      capital S               SM13   |      vertical bar
    
+  LT01   t      small t                 SM14   }      right curly bracket
    
+  LT02   T      capital T               SD13   `      grave accent
    
+  LU01   u      small u                 SD15   ^      circumflex accent
    
+  LU02   U      capital U               SD19   ~      tilde
    
+  LV01   v      small v
    
+  LV02   V      capital V
    
+  LW01   w      small w
    
+  LW02   W      capital W
    
+  LX01   x      small x
    
+  LX02   X      capital X
    
+  LY01   y      small y
    
+  LY02   Y      capital Y
    
+  LZ01   z      small z
    
+  LZ02   Z      capital Z
    
+
    
+Proposal 2.3.1: [Passed as Modified 03/89]
    
+
    
+ The following type definitions are added:
    
+
    
+ Define BASE-CHARACTER as (UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR)
    
+ and EXTENDED-CHARACTER as type (AND CHARACTER (NOT BASE-CHARACTER)).
    
+ Characters of type BASE-CHARACTER are referred to as ``base characters''.
    
+ Characters of type EXTENDED-CHARACTER are referred to as 
    
+ ``extended characters.''
    
+
    
+Proposal 2.3.2: [Passed 03/89]
    
+
    
+ The STRING type is defined as a union type.  More precisely, a string
    
+ is a specialized vector whose elements are of type CHARACTER or a
    
+ subtype of CHARACTER.  STRING used as a type specifier for object 
    
+ creation means (VECTOR CHARACTER).
    
+
    
+Proposal 2.3.3: [Passed as Modified 03/89]
    
+
    
+ The following string subtypes are distinguished with standardized names.
    
+   * BASE-STRING is equivalent to (VECTOR BASE-CHARACTER).
    
+     Strings of type BASE-STRING are referred to as ``base strings.''
    
+   * BASE-STRING is valid as a type specifier that abbreviates.
    
+
    
+Proposal 2.3.4: [Passed as Modified 03/89]
    
+
    
+ Define SIMPLE-STRING as a union type.  A simple string is a specialized
    
+ simple one dimensional array whose elements are of type CHARACTER or a
    
+ subtype of CHARACTER.  SIMPLE-STRING used as a type specifier for object
    
+ creation means (SIMPLE-ARRAY CHARACTER size).
    
+
    
+Proposal 2.3.5: [Passed as Modified 03/89]
    
+
    
+ The following simple string subtypes are distinguished with standardized
    
+ names:
    
+  * SIMPLE-BASE-STRING is equivalent to (SIMPLE-ARRAY BASE-CHARACTER (*)).
    
+    SIMPLE-BASE-STRING is a subtype of BASE-STRING.
    
+  * SIMPLE-BASE-STRING is valid as a type specifier that abbreviates.
    
+
    
+Proposal 2.3.6: [Passed 03/89]
    
+
    
+ Extend the MAKE-STRING function to allow an ELEMENT-TYPE keyword argument:
    
+  * MAKE-STRING size &KEY :initial-element :element-type   [Function]
    
+    This returns a simple string of length SIZE, each of whose characters
    
+    has been initialized to the :INITIAL-ELEMENT argument.  If an
    
+    :INITIAL-ELEMENT argument is not specified, then the string will be
    
+    initialized in an implementation-dependent way.  The :ELEMENT-TYPE
    
+    argument names the type of the elements of the string; a string is
    
+    constructed of the most specialized type that can accommodate elements
    
+    of the given type.  If :ELEMENT-TYPE is omitted, the type CHARACTER
    
+    is the default.
    
+
    
+Proposal 2.4.1: [Passed 03/89]
    
+
    
+ Common LISP character codes are composed from a character script and
    
+ a character label.  The convention by which a character label and
    
+ character script compose a character code is implementation dependent.
    
+
    
+Proposal 2.4.2: [Passed as Modified 06/89]
    
+
    
+ An implementation must document the scripts it supports. For each script
    
+ supported the documentation must include at least the following:
    
+
    
+  * Character Labels, Glyphs, and Descriptions.  Character labels must
    
+    be uniquely named using only Latin capital letters A-Z, hyphen and
    
+    digits 0-9.
    
+
    
+  * Effect of CHAR-UPCASE and CHAR-DOWNCASE.
    
+
    
+  * Reader canonicalization and format directives.
    
+    Note: Any mechanisms by which the READ function treats distinct
    
+          characters as equivalent.
    
+
    
+  * Effect of character predicates. In particular,
    
+    - CHAR-EQUAL and other case-insensitive character predicates.
    
+    - ALPHA-CHAR-P
    
+    - LOWER-CASE-P
    
+    - UPPER-CASE-P
    
+    - BOTH-CASE-P
    
+    - GRAPHIC-CHAR-P
    
+    - ALPHANUMERICP
    
+
    
+  * Interaction with File I/O.  In particular, the coded character
    
+    sets (e.g., ISO8859/1-1987) and external encoding schemes 
    
+    supported are documented.
    
+
    
+Proposal 2.4.3: [Passed as Modified 06/89]
    
+
    
+ Every character repertoire name is a type specifier and a subtype of
    
+ type CHARACTER.
    
+
    
+Proposal 2.5.2: [Passed as Modified 06/89]
    
+
    
+ Add an additional keyword argument to OPEN and a new function to query
    
+ external file format:
    
+
    
+   * :EXTERNAL-FORMAT keyword argument on OPEN which specifies an 
    
+     implementation recognized scheme for representing characters in files.
    
+
    
+     The default value is :DEFAULT and is implementation defined but must
    
+     support the base characters.
    
+
    
+     If the argument is not recognized by the implementation, an error is
    
+     signalled. This argument is provided for input, output, and bidirectional
    
+     streams.  It is an error to write a character which cannot be represented
    
+     using the given file format. (This excludes the #\Newline character.
    
+     Implementations must provide appropriate line division behavior for all
    
+     character streams.)
    
+
    
+   * STREAM-EXTERNAL-FORMAT stream   [Function]
    
+
    
+     STREAM-EXTERNAL-FORMAT returns the implementation recognized format of
    
+     the specified file.
    
+
    
+Proposal 2.5.4: [Alternative A, Passed 06/89]
    
+
    
+ The default for the :ELEMENT-TYPE argument of OPEN is CHARACTER.
    
+
    
+Proposal 2.5.6: [Passed as Modified 06/89]
    
+
    
+ Modify the following functions:
    
+
    
+   * WITH-OUTPUT-TO-STRING.  A new keyword argument :ELEMENT-TYPE is added
    
+     which defaults to CHARACTER. If a string argument is provided, the
    
+     :ELEMENT-TYPE argument is ignored. A string argument of NIL means
    
+     no initial string argument is provided. If no string argument is
    
+     provided, produces a stream that accepts all characters of the
    
+     indicated type and returns a string of the indicated element type.
    
+
    
+   * MAKE-STRING-OUTPUT-STREAM.  A new keyword argument :ELEMENT-TYPE is
    
+     added which defaults to CHARACTER. MAKE-STRING-OUTPUT-STREAM returns
    
+     an output stream that accepts all characters of the indicated type
    
+     and returns (via GET-OUTPUT-STREAM-STRING) a string of the indicated
    
+     type.
    
+
    
+Proposal 2.5.7: [Passed as Modified 06/89]
    
+
    
+ Add the following function:
    
+   * FILE-STRING-LENGTH file-stream object  [Function]
    
+
    
+     FILE-STRING-LENGTH returns a non-negative integer which represents
    
+     the difference between what (FILE-POSITION file-stream) would be
    
+     after writing the OBJECT and its current value, or NIL if this cannot
    
+     be determined.  OBJECT must be a string or character.
    
+
    
+     This return value depends on the current state of the stream, that
    
+     is, two calls to FILE-STRING-LENGTH with the same stream and object
    
+     may return different values.
    
+
    
+ 
    
+Misc effects on CLtL...
    
+
    
+Proposal 2.6.1: [Passed 03/89]
    
+
    
+ Chapter 2 Data Types (Page 12)
    
+
    
+  Replace:
    
+     provides for a
    
+     rich character set, including ways to represent characters of various
    
+     type styles.
    
+  with:
    
+     provides support for international language characters as well
    
+     as characters used in specialized arenas, eg. mathematics.
    
+
    
+Proposal 2.6.2: [Passed as Modified 03/89]
    
+
    
+ Chapter 2 Symbols (Page 25)
    
+
    
+  Clarify:
    
+     A symbol may have any character in its print name.
    
+
    
+Proposal 2.6.3: [Passed 03/89]
    
+
    
+ Chapter 10 Symbols (Page 163)
    
+
    
+  Replace:
    
+     It is ordinarily not permitted to alter a symbol's print name.
    
+  with:
    
+     It is an error to alter a symbol's print name.
    
+
    
+Proposal 2.6.4: [Passed 03/89]
    
+
    
+ Chapter 10 The Print Name (Page 168)
    
+
    
+  Replace:
    
+     It is an extremely bad idea to modify a string being used
    
+     as the print name of a symbol.
    
+  with:
    
+     It is an error to modify a string being used
    
+     as the print name of a symbol.
    
+
    
+Proposal 2.6.5: [Passed 03/89]
    
+
    
+ Chapter 14 Simple Sequence Functions (Page 249, make-sequence)
    
+
    
+  Append:
    
+     If type STRING is specified, the result is equivalent to MAKE-STRING.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss027.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss027.htm new file mode 100644 index 00000000..eec43f83 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss027.htm @@ -0,0 +1,57 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-1-1 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-1-1 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-1-1:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss028.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss028.htm new file mode 100644 index 00000000..432d2dfe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss028.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-1-2 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-1-2 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-1-2:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss029.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss029.htm new file mode 100644 index 00000000..f943d933 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss029.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-2-1 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-2-1 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-2-1:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss030.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss030.htm new file mode 100644 index 00000000..260a7640 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss030.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-3-1 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-3-1 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-3-1:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss031.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss031.htm new file mode 100644 index 00000000..516bbd3c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss031.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-3-2 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-3-2 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-3-2:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss032.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss032.htm new file mode 100644 index 00000000..a65392b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss032.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-3-3 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-3-3 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-3-3:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss033.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss033.htm new file mode 100644 index 00000000..8cc16fac --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss033.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-3-4 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-3-4 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-3-4:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss034.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss034.htm new file mode 100644 index 00000000..48f4685a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss034.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-3-5 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-3-5 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-3-5:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss035.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss035.htm new file mode 100644 index 00000000..d558df71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss035.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-3-6 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-3-6 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-3-6:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss036.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss036.htm new file mode 100644 index 00000000..0f3a51df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss036.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-4-1 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-4-1 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-4-1:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss037.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss037.htm new file mode 100644 index 00000000..f8f5e303 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss037.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-4-2 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-4-2 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-4-2:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss038.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss038.htm new file mode 100644 index 00000000..98a9fe00 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss038.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-4-3 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-4-3 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-4-3:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss039.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss039.htm new file mode 100644 index 00000000..06650ae2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss039.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-5-2 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-5-2 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-5-2:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss040.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss040.htm new file mode 100644 index 00000000..3038c43d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss040.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-5-6 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-5-6 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-5-6:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss041.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss041.htm new file mode 100644 index 00000000..fab523e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss041.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-5-7 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-5-7 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-5-7:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss042.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss042.htm new file mode 100644 index 00000000..37ffad8d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss042.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-6-1 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-6-1 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-6-1:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss043.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss043.htm new file mode 100644 index 00000000..1457650c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss043.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-6-2 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-6-2 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-6-2:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss044.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss044.htm new file mode 100644 index 00000000..09ecedfa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss044.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-6-3 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-6-3 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-6-3:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss045.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss045.htm new file mode 100644 index 00000000..ac139021 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss045.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CHARACTER-PROPOSAL:2-6-5 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-PROPOSAL:2-6-5 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CHARACTER-PROPOSAL:2-6-5:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046.htm new file mode 100644 index 00000000..310bfb8a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046.htm @@ -0,0 +1,45 @@ + + + +CLHS: Issue CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046_w.htm new file mode 100644 index 00000000..dfc168f2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss046_w.htm @@ -0,0 +1,205 @@ + + + +CLHS: Issue CHARACTER-VS-CHAR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CHARACTER-VS-CHAR Writeup

    + +
    Issue:        CHARACTER-VS-CHAR
    
+Forum:	      Editorial
    
+References:   Character Proposal 2.3.1,  MAKE-DISPATCH-MACRO-CHARACTER (p363),
    
+	      GET-MACRO-CHARACTER (p362), SET-MACRO-CHARACTER (p362)
    
+	      GET-DISPATCH-MACRO-CHARACTER (p364), 
    
+	      SET-DISPATCH-MACRO-CHARACTER (p364)
    
+Category:     CHANGE
    
+Edit history: 12-Nov-90, Version 1 by Pitman
    
+	      14-Nov-90, Version 2 by Pitman (minor mods to Rationale, Discussion)
    
+	      15-Mar-91, Version 3 by Pitman (one new proposal, some endorsements)
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+ Character proposal 2.3.1 adds the names BASE-CHARACTER and
    
+ EXTENDED-CHARACTER.  These are naming-wise inconsistent with
    
+ STANDARD-CHAR.
    
+
    
+Proposal (CHAR-VS-CHARACTER:INCONSISTENTLY-STATUS-QUO)
    
+
    
+ Leave things as they are.
    
+
    
+Proposal (CHAR-VS-CHARACTER:LESS-INCONSISTENT-SHORT)
    
+
    
+ Rename BASE-CHARACTER to BASE-CHAR. 
    
+ Rename EXTENDED-CHARACTER to EXTENDED-CHAR. 
    
+
    
+Proposal (CHAR-VS-CHARACTER:LESS-INCONSISTENT-LONG)
    
+
    
+ Rename STANDARD-CHAR to STANDARD-CHARACTER.
    
+
    
+Proposal (CHAR-VS-CHARACTER:CONSISTENTLY-CHAR)
    
+
    
+ Rename BASE-CHARACTER to BASE-CHAR.
    
+ Rename EXTENDED-CHARACTER to EXTENDED-CHAR.
    
+
    
+ Rename MAKE-DISPATCH-MACRO-CHARACTER to MAKE-DISPATCH-MACRO-CHAR.
    
+ Rename SET-MACRO-CHARACTER to SET-MACRO-CHAR. 
    
+ Rename GET-DISPATCH-MACRO-CHARACTER to GET-DISPATCH-MACRO-CHAR.
    
+ Rename SET-DISPATCH-MACRO-CHARACTER to SET-DISPATCH-MACRO-CHAR.
    
+ Rename GET-MACRO-CHARACTER to GET-MACRO-CHAR.
    
+
    
+Proposal (CHAR-VS-CHARACTER:REALLY-FIX-THINGS-UP)
    
+
    
+ Rename BASE-CHARACTER to BASE-CHAR.
    
+ Rename EXTENDED-CHARACTER to EXTENDED-CHAR.
    
+
    
+ Rename MAKE-DISPATCH-MACRO-CHARACTER to MAKE-DISPATCH-MACRO-CHAR.
    
+
    
+ Remove the functions GET-MACRO-CHARACTER, SET-MACRO-CHARACTER,
    
+  GET-DISPATCH-MACRO-CHARACTER, and SET-DISPATCH-MACRO-CHARACTER. 
    
+
    
+ Create setfable functions MACRO-CHAR and DISPATCH-MACRO-CHAR, 
    
+ such that:
    
+
    
+  - (MACRO-CHAR c [r]) means what (GET-MACRO-CHARACTER x r) 
    
+    used to mean.
    
+    
    
+    (SETF (MACRO-CHAR c [r]) (VALUES fn [nt])) means what
    
+    (SET-MACRO-CHARACTER c fn nt r) used to mean.
    
+
    
+  - (DISPATCH-MACRO-CHAR d s [r]) means what 
    
+    (GET-DISPATCH-MACRO-CHAR d s [r]) used to mean.
    
+
    
+  - (SETF (DISPATCH-MACRO-CHAR d s [r]) fn) means what
    
+    (SET-DISPATCH-MACRO-CHAR d s fn [r]) used to mean.
    
+
    
+Rationale:
    
+
    
+ We've enumerated the positions that people were likely to have
    
+ so that they could refer succinctly to their position by name.
    
+
    
+  INCONSISTENTLY-STATUS-QUO:  Leaves the language unchanged.
    
+
    
+  LESS-INCONSISTENT-SHORT:  Changes only that part of the language
    
+    which is not in CLtL, and which users probably aren't using
    
+    much yet anyway.  At least makes all the type names use
    
+    "-CHAR" consistently.  (Stops short of addressing why there
    
+    is a name SET-SYNTAX-FROM-CHAR but another name 
    
+    GET-MACRO-CHARACTER only to preserve the status quo.)
    
+
    
+  LESS-INCONSISTENT-LONG:  Changes only one name  At least makes
    
+    all the type names use "CHARACTER" consistently.  (Stops
    
+    short of addressing why there is a name SET-SYNTAX-FROM-CHAR
    
+    but another name GET-MACRO-CHARACTER only to preserve the 
    
+    status quo.)
    
+
    
+  CONSISTENTLY-CHAR:  Changes even some things which were in
    
+    CLtL, but does so in a manner that is predictably consistent:
    
+    The word "CHARACTER" is shortened to "CHAR" whenever it appears
    
+    hyphenated together with other words.  This would be harder
    
+    on existing programs, but easier for new users.
    
+
    
+  REALLY-FIX-THINGS-UP:  Like CONSISTENTLY-CHAR, but also takes 
    
+    advantage of a last opportunity to make the language use SETF more
    
+    consistently.  Probably the reason this didn't originally use SETF
    
+    was the lack of clarity in the managing of multiple values.
    
+    Also, SET-MACRO-CHARACTER and SET-DISPATCH-MACRO-CHARACTER are the
    
+    only two symbols in CL which begin with the substring "SET-" but
    
+    are not set-manipulation primitives.
    
+
    
+Current Practice:
    
+
    
+ No one does this.
    
+
    
+Cost to Implementors:
    
+
    
+ Small, in all cases.
    
+
    
+Cost to Users:
    
+
    
+ INCONSISTENTLY-STATUS-QUO:  None.
    
+
    
+ LESS-INCONSISTENT-SHORT:  Very small.
    
+
    
+ LESS-INCONSISTENT-LONG:  Small.
    
+
    
+ CONSISTENTLY-CHAR and REALLY-FIX-THINGS-UP: It's very easy to
    
+   write the requisite compatibility functions in order to support the
    
+   old names during a transition period.  With all the other things
    
+   people are having to do to convert, this is relatively little extra
    
+   burden.
    
+
    
+Cost of Non-Adoption:
    
+
    
+ See aesthetics.
    
+
    
+Benefits:
    
+
    
+ Aesthetic and Mnemonic.
    
+
    
+Aesthetics:
    
+
    
+ If this is adopted...      The affected parts of the language will be...
    
+
    
+ INCONSISTENTLY-STATUS-QUO  glaringly unaesthetic
    
+ LESS-INCONSISTENT-SHORT    tolerable, but not pretty
    
+ LESS-INCONSISTENT-LONG	    tolerable, but not pretty
    
+ CONSISTENTLY-CHAR          reasonable
    
+ REALLY-FIX-THINGS-UP       very pretty
    
+
    
+Discussion:
    
+
    
+ KMP prefers (in decreasing order of preference) REALLY-FIX-THINGS-UP,
    
+ then CONSISTENTLY-CHAR, then LESS-INCONSISTENT-SHORT or 
    
+ LESS-INCONSISTENT-LONG, then INCONSISTENTLY-STATUS-QUO.
    
+ Scott Cyphers (Symbolics) concurs with this ordering, except his first 
    
+ choice would be for the [non-existent] option REALLY-FIX-THINGS-UP-CHARACTER.
    
+ Scott McKay (Symbolics) likes CONSISTENTLY-CHAR but would thinks 
    
+ REALLY-FIX-THINGS-UP would be ok.
    
+
    
+ Bob Cassels at Symbolics asked why there isn't a CONSISTENTLY-CHARACTER
    
+ option.  KMP replies:
    
+  In general, we have tried to spell out words in the language. There
    
+  are, of course, some glaring exceptions.  However, I feel that
    
+  certain English words (like "paren", "char", "info", and "demo") 
    
+  have acquired such high frequency usage in the Computer Science 
    
+  arena that we are basically just waiting for the dictionary-makers
    
+  to catch up with the natural-language phenomenon of shortening of
    
+  higher frequency words by its speakers.  As such, I feel the issue
    
+  is not one of either "char" or "character" being more correct, but
    
+  rather one of choosing the names in such a way that users can 
    
+  reliably remember which name is used in which situation.
    
+
    
+ Masinter supports REALLY-FIX-THINGS-UP.
    
+
    
+ Moon and Sandra prefer the long name CHARACTER to the short name CHAR.
    
+ (Moon voiced implicit support for LESS-INCONSISTENT-LONG, even though
    
+ the option didn't exist yet.)
    
+
    
+ JonL says he and others at Lucid think that changing a lot of names at
    
+ this point is a bad idea.  [It is for this reason that option
    
+ LESS-INCONSISTENT-LONG was added in v3 of this proposal--to offer a 
    
+ minimalist fix that might satisfy them.]
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047.htm new file mode 100644 index 00000000..a7407492 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CLASS-OBJECT-SPECIALIZER:AFFIRM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLASS-OBJECT-SPECIALIZER:AFFIRM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CLASS-OBJECT-SPECIALIZER:AFFIRM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047_w.htm new file mode 100644 index 00000000..b771b401 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss047_w.htm @@ -0,0 +1,102 @@ + + + +CLHS: Issue CLASS-OBJECT-SPECIALIZER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLASS-OBJECT-SPECIALIZER Writeup

    + +
    Issue:		CLASS-OBJECT-SPECIALIZER
    
+References:	Draft 8.81, p.4-15
    
+		Draft 8.81, Glossary
    
+		88-002R
    
+Category:	CHANGE
    
+Edit history:	Version 1, 28-Mar-91, Kim Barrett
    
+Status:		Proposal AFFIRM was approved at the 3/91 meeting
    
+
    
+Problem description:
    
+
    
+ It was recently noted that the 8.81 draft defines parameter specializer names
    
+ to include class objects.  This inclusion seems to be without basis in
    
+ decisions made by X3J13, and the editor believes it to be an editorial error.
    
+
    
+ However, there has been previous discussion of exactly this question on the
    
+ clos mailing list, in which the general consensus seemed to be that class
    
+ objects should be permitted as parameter specializer names.
    
+
    
+Proposal (CLASS-OBJECT-SPECIALIZER:AFFIRM):
    
+
    
+ Affirm the wording in the 8.81 draft on page 4-15, which states that a class
    
+ object may be used as a parameter specializer name.
    
+
    
+Examples:
    
+
    
+  (defclass foo-class () ())
    
+  (defmethod foo-method ((x #.(find-class foo-class))) x)
    
+
    
+Rationale:
    
+
    
+ Not affirming the draft's wording would make parameter specializer names
    
+ inconsistent with other parts of the language, since the use of class objects
    
+ and class names are generally interchangeable when used as type specifiers.
    
+
    
+ The draft already says this.
    
+
    
+Current Practice:
    
+
    
+ Lucid 4.0 and Chestnut's Lisp to C translator support this.
    
+
    
+ Several other implementations probably also support this.
    
+
    
+Cost to Implementors:
    
+
    
+ Likely small.
    
+
    
+Cost to Users:
    
+
    
+ None.  This is an upwardly compatible change.
    
+
    
+Cost of non-adoption:
    
+
    
+ Some applications may already depend on this.  In the mail discussion of this
    
+ question it was mentioned that CLIM may be using class objects as parameter
    
+ specializer names.
    
+
    
+Performance impact:
    
+
    
+ None.
    
+
    
+Editorial impact:
    
+
    
+ None if accepted, since the draft already contains the necessary words.
    
+
    
+Esthetics:
    
+
    
+ Avoiding inconsistancy regarding the distinction between class objects and
    
+ class names when used as type specifiers is more esthetic.
    
+
    
+Discussion:
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048.htm new file mode 100644 index 00000000..0842c963 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048_w.htm new file mode 100644 index 00000000..669fd42b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss048_w.htm @@ -0,0 +1,157 @@ + + + +CLHS: Issue CLOS-CONDITIONS-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLOS-CONDITIONS-AGAIN Writeup

    + +
    Date: Fri, 8 Jun 90 19:55 EDT
    
+From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
+Subject: Issue: CLOS-CONDITIONS-AGAIN (Version 6)
    
+To: X3J13@mcc.com
    
+Message-ID: <19900608235525.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
    
+
    
+This version includes the amendment that was passed at the X3J13 meeting today.
    
+
    
+Issue:         CLOS-CONDITIONS-AGAIN
    
+
    
+References:    ANSI CL draft specification, page 5-4
    
+
    
+Related issues: CLOS-CONDITIONS
    
+
    
+Category:      ADDITION and CHANGE
    
+
    
+Edit history:  30-Apr-90, Version 1 by Moon (for Pitman)
    
+               30-Apr-90, Version 2 by Moon (deal with slots)
    
+	        2-May-90, Version 3 by Pitman (minor wording clarifications)
    
+                2-May-90, Version 4 by Moon (final check for typos)
    
+                5-Jun-90, Version 5 by Moon (mention multiple inheritance)
    
+                8-Jun-90, Version 6, by Moon (as amended at X3J13 meeting)
    
+
    
+Problem description:
    
+
    
+  The condition system should not be too tightly integrated into CLOS, for
    
+  two reasons:  Some implementations already have a native condition system
    
+  that is not based on CLOS, and it should be possible to integrate the
    
+  native conditions and the ANSI CL conditions.  Some people would like to
    
+  define an ANSI Common Lisp subset that does not contain CLOS but does
    
+  contain conditions.
    
+
    
+  The problem areas are the use of DEFCLASS, MAKE-INSTANCE, and DEFMETHOD
    
+  to define and create conditions, rather than using more abstract macros
    
+  that conceal the implementation of conditions in terms of CLOS, and
    
+  exposure of the implementation of condition slots as CLOS slots.  If user
    
+  code was written in a more abstract way, it could run in a subset language
    
+  that did not contain CLOS.
    
+
    
+  This is Symbolics issue #7.
    
+
    
+Proposal (CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET):
    
+	  
    
+  1. Specify that conforming code must use DEFINE-CONDITION (not DEFCLASS)
    
+  to define conditions, and MAKE-CONDITION (not MAKE-INSTANCE) to make
    
+  conditions.  (These two operators already exist in ANSI Common Lisp.)
    
+
    
+  2. Specify that conforming code must use the :REPORT option of
    
+  DEFINE-CONDITION (not DEFMETHOD for PRINT-OBJECT) to define a condition
    
+  reporter.
    
+
    
+  3. Specify that conforming code must not use SLOT-VALUE, SLOT-BOUNDP,
    
+  SLOT-MAKUNBOUND, or WITH-SLOTS on condition objects.  Instead it must
    
+  call the accessor functions defined by DEFINE-CONDITION.
    
+
    
+  4. Clarify that this proposal does not rule out the use of multiple
    
+  parent-types in DEFINE-CONDITION.
    
+
    
+Rationale:
    
+
    
+  1. The reasons are two:
    
+     - permit flexibility in making the native class system compatible
    
+       with the ANSI CL one
    
+     - permit dialects that don't want CLOS to be available to run most
    
+       common condition-related code.
    
+
    
+  2. The reasons are three:
    
+     - isolate the report part without forcing the user to deal with the
    
+       case of *PRINT-ESCAPE* being true.
    
+     - keep a CL subset from having to implement DEFMETHOD to get this
    
+       important functionality.
    
+     - don't define two ways to do the same thing.
    
+
    
+  3. Using the existing accessor functions seems more conservative than
    
+     requiring non-CLOS subsets to implement an ersatz SLOT-VALUE function.
    
+
    
+     Note also that the requirement here (in #3) is on conforming -code-.
    
+     An -implementation- can permit the use of SLOT-VALUE, SLOT-BOUNDP,
    
+     SLOT-MAKUNBOUND, and/or WITH-SLOTS as an extension and still be 
    
+     conforming.  Programs which used such an extension would not be
    
+     conforming and might not be portable to all implementations.
    
+
    
+  4. There is no substitute for multiple inheritance, and given the
    
+     limited set of operations that can be performed on conditions, it
    
+     is easy to fake it.
    
+
    
+Current practice:
    
+
    
+  1. DEFINE-CONDITION and MAKE-CONDITION are already in the language.
    
+
    
+  2. The :REPORT option to DEFINE-CONDITION exists.
    
+
    
+  3. Some implementations support use of WITH-SLOTS and some do not.
    
+     Programs that use WITH-SLOTS are not yet portable.
    
+
    
+  4. DEFINE-CONDITION is already specified to support multiple inheritance.
    
+
    
+Cost to Implementors:
    
+
    
+  Trivial.
    
+
    
+Cost to Users:
    
+
    
+  They have to write their programs in terms of the condition abstractions
    
+  if they want them to be portable.
    
+
    
+Cost of non-adoption:
    
+
    
+  Condition-using programs will not be portable to Common Lisp subsets that
    
+  don't have CLOS.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  See rationale.
    
+
    
+Esthetics:
    
+
    
+  Abstraction is more esthetic than revealing the implementation.
    
+
    
+Discussion:
    
+
    
+  Pitman and Moon support this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049.htm new file mode 100644 index 00000000..1a5326a0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue CLOS-CONDITIONS:INTEGRATE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLOS-CONDITIONS:INTEGRATE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CLOS-CONDITIONS:INTEGRATE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049_w.htm new file mode 100644 index 00000000..a65e1490 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss049_w.htm @@ -0,0 +1,261 @@ + + + +CLHS: Issue CLOS-CONDITIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLOS-CONDITIONS Writeup

    + +
    Status: DRAFT
    
+Issue:        CLOS-CONDITIONS
    
+References:   Condition System (Revision 18)
    
+Category:     ADDITION
    
+Edit history: 26-Sep-88, Version 1 by Pitman
    
+	      06-Oct-88, Version 2 by Pitman
    
+	      09-Oct-88, Version 3 by Pitman
    
+	      10-Mar-89, Version 4 by Pitman (remove unsupported options)
    
+
    
+Problem Description:
    
+
    
+  The description of the Common Lisp condition system presupposes
    
+  only DEFSTRUCT and not DEFCLASS because it was written when
    
+  CLOS had not been adopted. It is stylistically out of step with
    
+  CLOS in a few places and places some restrictions which are not
    
+  necessary if CLOS can be presupposed.
    
+
    
+Proposal (CLOS-CONDITIONS:INTEGRATE):
    
+
    
+  1. Define that condition types are CLOS classes.
    
+
    
+  2. Define that condition objects are CLOS instances.
    
+
    
+  3. Functions such as SIGNAL, which take arguments of class names, are
    
+     permitted to take class objects. Such class objects must still be
    
+     subclasses of CONDITION.
    
+
    
+  4. Define that slots in condition objects are normal CLOS slots. Note
    
+     that WITH-SLOTS can be used to provide more convenient access to the
    
+     slots where slot accessors are undesirable.
    
+
    
+  5. Incompatibly change the syntax of a slot in DEFINE-CONDITION
    
+     to be compatible with a DEFCLASS slot specification.
    
+
    
+     An implication of this change is that forms like
    
+      (DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
    
+     would have to be written
    
+      (DEFINE-CONDITION FOO (BAR)
    
+	((A :INITARG :A :READER FOO-A :INITFORM 1)
    
+	 (B :INITARG :B :READER FOO-B :INITFORM 2)))
    
+
    
+  6. Permit multiple parent-types to be named in the list of parent types.
    
+     Define that these parent types are treated the same as the superior
    
+     class list in a CLOS DEFCLASS expression.
    
+
    
+  7. Eliminate the :CONC-NAME option to DEFINE-CONDITION.
    
+
    
+  8. Define that condition reporting is mediated through the PRINT-OBJECT
    
+     method for the condition type (class) in question, with *PRINT-ESCAPE*
    
+     always being NIL. Specifying (:REPORT fn) in the definition of a
    
+     condition type C is equivalent to doing 
    
+      (DEFMETHOD PRINT-OBJECT ((X c) STREAM)
    
+	(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
    
+
    
+Rationale:
    
+
    
+  These changes are consistent with the intent of the X3J13 endorsement
    
+  of CLOS and the Common Lisp Condition System.
    
+
    
+  Although items 5 and 7 are incompatible with the interim condition
    
+  handling which we've been working with, the overall proposal significantly
    
+  improves compatibility with CLOS.
    
+
    
+  This compatibility will make the language seem less fragmented, and
    
+  probably more learnable because there will be fewer paradigms to learn.
    
+
    
+  Also, items 5 and 7 in particular are an improvement for reasons
    
+  unrelated to CLOS if only because they get rid of the need for symbol
    
+  concatenation, a process which has been seen to cause problems because
    
+  of the transient nature of the binding of *PACKAGE*.
    
+
    
+Examples:
    
+
    
+  Slot specifiers...
    
+
    
+    A slot specifier of X is still valid but is incompatibly
    
+    changed to mean what CLOS has it mean; no :INITARG or 
    
+    :READER would be supplied.
    
+  
    
+    A slot specifier of (X) is still valid but is incompatibly
    
+    changed to mean what CLOS has it mean; no :INITARG or 
    
+    :READER would be supplied.
    
+
    
+    A slot specifier of (X V) would no longer be valid.
    
+    
    
+    In addition, other slot specifiers such as
    
+     (X :INITARG :EX :TYPE FIXNUM)
    
+    are permitted as in DEFCLASS.
    
+
    
+ Conc names ...
    
+
    
+   (DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
    
+   would be rewritten
    
+   (DEFINE-CONDITION FOOBAR (FOO BAR)
    
+     ((X :INITARG :X :READER FUBAR-X)
    
+      (Y :INITARG :Y :READER FUBAR-Y)))
    
+
    
+ Report methods ...
    
+
    
+   (DEFINE-CONDITION OOPS (ERROR) ())
    
+   (DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
    
+     (IF *PRINT-ESCAPE* 
    
+	 (CALL-NEXT-METHOD)
    
+	 (FORMAT STREAM "Oops! Something went wrong.")))
    
+   (ERROR 'OOPS)
    
+   >>Error: Oops! Something went wrong.
    
+
    
+
    
+Current Practice:
    
+
    
+  Some implementations supporting CLOS probably already do this,
    
+  or something very similar.
    
+
    
+Cost to Implementors:
    
+
    
+  If you really have CLOS, this is very straightforward.
    
+
    
+Cost to Users:
    
+
    
+  Small, but tractable.
    
+
    
+  The main potential problems are:
    
+
    
+   - :CONC-NAME. There is nothing that keeps an implementation from
    
+     continuing to support :CONC-NAME for a short while until old code
    
+     has been upgraded.
    
+
    
+   - The incompatible change to slot syntax. Again, it is possible to
    
+     unambiguously recognize a 2-list as old-style syntax and an
    
+     implementation can provide interim compatibility support during
    
+     a transition period.
    
+
    
+  Even if implementations did not provide the recommended compatibility
    
+  support, users could trivially shadow DEFINE-CONDITION and provide the
    
+  support themselves, expanding into the native DEFINE-CONDITION in the
    
+  proper syntax.
    
+
    
+  In any case, the total number of uses of DEFINE-CONDITION at this 
    
+  point is probably quite small. Searching for them and repairing
    
+  each by hand is probably not an expensive operation.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Conditions will seem harder to manipulate than other user-defined types.
    
+
    
+  People will wonder if CLOS is really something we're committed to.
    
+
    
+Benefits:
    
+
    
+  A more regular, more learnable language.
    
+
    
+Aesthetics:
    
+
    
+  Improved.
    
+
    
+Discussion:
    
+
    
+  Gregor, Pierson, Moon, and Pitman support this proposal.
    
+
    
+  People seem to disagree about the status that CLOS might occupy
    
+  in the upcoming standard. In spite of a vote of support, they seem
    
+  to think it might be optional in some way. Passing this proposal
    
+  establishes a clear precedent for the full integration of CLOS into
    
+  the emerging language.
    
+
    
+  The sense of the cleanup committee was that it was acceptable for
    
+  a vendor to identify a CLOS-free subset of Common Lisp, but that since
    
+  the position of X3J13 seems to be that no resources should be devoted
    
+  to work on subsets, it was inappropriate for us to work out the details
    
+  of that subset ourselves.  Since nothing about this proposal would
    
+  impede such a subset, we took that to be adequate basis for presenting
    
+  this single proposal.
    
+
    
+  Moon thinks we might want to add condition types for the errors
    
+  CLOS might signal. Richard Mlynarik thinks we should add a generic
    
+  function, REPORT-CONDITION, which is used for reporting conditions.
    
+  Both of these issues should probably be pursued under separate cover.
    
+
    
+
    
+!
    
+"One comment is that you should explicitly mention bootstrapping
    
+concerns under cost to implementors.  If you just leave it out,
    
+someone may think it is a difficult problem. "
    
+
    
+"This isn't any sort of clarification.  The actual clarification required
    
+-- which has been requested several times, and not just by myself -- is
    
+what the *METACLASS* of condition types is.
    
+
    
+Condition types may be "CLOS classes" without being STANDARD-CLASSes
    
+Condition objects may be "CLOS instances" without being STANDARD-OBJECTs.
    
+Just what are "normal CLOS slots"?  As I see it, the "normalcy" or
    
+otherwise of slots is determined by the metaclass.
    
+
    
+
    
+My opinion for some time has been that condition types should not be
    
+STANDARD-CLASSes but instead something like READ-ONLY-CLASS.
    
+Conceptually, It Is An Error to modify the slots of condition objects,
    
+which are supposed to be immutable descriptions of part of the state of
    
+a computation.  Implementationally,
    
+(setf (slot-value <condition-object> <slot-name>) <new-value>) should
    
+signal an error.
    
+
    
+(I also think that conditions in particular have a strong need for
    
+something like :REQUIRED-INIT-KEYWORDS, but that's another story.)
    
+
    
+Even if you decide to make condition classes' metaclass STANDARD-CLASS,
    
+the point is that you need to state this, so that users may define
    
+condition classes and mixins using DEFCLASS."
    
+
    
+"I do not agree that it is a -necessary- thing to specify the Meta-Class
    
+of conditions because all intended uses of conditions can be done
    
+without this information.
    
+
    
+I agree that it is a -possibly useful- thing to do, but there is a down
    
+side to it -- it would unnecessarily tie the hands of people who want
    
+implementation flexibility for one reason or another."
    
+
    
+"... If we don't specify the metaclass, then users
    
+won't know what other classes they can mix in when defining condition
    
+classes.  It may seem weird, but I can imagine someone wanting to mix
    
+in an arbitrary class into a condition class.
    
+
    
+I think we should just say that the class CONDITION is an instance of
    
+STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard
    
+classes.  Sure it might be nice to do the read only class thing but I
    
+don't think this is a good time to design a special purpose metaclass
    
+for this.  "
    
+
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050.htm new file mode 100644 index 00000000..f834a068 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050_w.htm new file mode 100644 index 00000000..74db59e0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss050_w.htm @@ -0,0 +1,81 @@ + + + +CLHS: Issue CLOS-ERROR-CHECKING-ORDER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLOS-ERROR-CHECKING-ORDER Writeup

    + +
    Issue:        CLOS-ERROR-CHECKING-ORDER
    
+Reference:    dpANS 12.24
    
+                Section 7.6.5 Keyword Arguments in Generic Functions and Methods
    
+                Section 7.6.6 Method Selection and Combination
    
+                no-applicable-method, p.7-47
    
+              X3J13/92-3248 David Moon comment #48
    
+Category:     CLARIFICATION/CHANGE
    
+Edit History: Version 1, 12/13/92, Kim Barrett
    
+Status:	      Proposal NO-APPLICABLE-METHOD-FIRST passed (10+1)-0 on
    
+              letter ballot 93-302.
    
+
    
+Problem Description:
    
+
    
+ There is no specification of the ordering between the check for
    
+ no-applicable-method and the check for unexpected keyword arguments.
    
+ Specifically, section 7.6.5 states that if a generic function is passed a
    
+ keyword argument that no applicable method accepts, an error should be
    
+ signaled, while section 7.6.6 states that if there are no applicable methods
    
+ then the generic function no-applicable-methods is called.
    
+
    
+Proposal (CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST):
    
+
    
+ Check for no applicable method first.  Change the end of the last paragraph
    
+ of section 7.6.6 from
    
+
    
+    If a \term{generic function} is called and no \term{methods} are
    
+    \term{applicable}, the \term{generic function} \funref{no-applicable-method}
    
+    is invoked.
    
+
    
+ to
    
+
    
+    If a \term{generic function} is called and no \term{methods} are
    
+    \term{applicable}, the \term{generic function} \funref{no-applicable-method}
    
+    is invoked, with the \term{results} from that call being used as the
    
+    \term{results} of the call to the original \term{generic function}.  Calling
    
+    \funref{no-applicable-method} takes precedence over checking for acceptable
    
+    keyword arguments; \SeeSection{... section name for 7.6.5 ...}.
    
+
    
+Editorial Impact:
    
+
    
+ Changing or adding a couple of lines of text.
    
+
    
+Rationale:
    
+
    
+ It was clearly intended that the call to no-applicable-methods be for value,
    
+ rather than for effect.  It just wasn't actually specified that way anywhere.
    
+
    
+ Adopting the suggested order would remove an ambiguity from the specification
    
+ and would make the no-applicable-method feature a little more useful.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051.htm new file mode 100644 index 00000000..ffa78d14 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CLOS-MACRO-COMPILATION:MINIMAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLOS-MACRO-COMPILATION:MINIMAL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CLOS-MACRO-COMPILATION:MINIMAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051_w.htm new file mode 100644 index 00000000..2d759605 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss051_w.htm @@ -0,0 +1,195 @@ + + + +CLHS: Issue CLOS-MACRO-COMPILATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLOS-MACRO-COMPILATION Writeup

    + +
    Forum:		Compiler
    
+Issue:		CLOS-MACRO-COMPILATION
    
+References:	CLOS chapters 1 & 2 (88-002R)
    
+		CLOS chapter 3 (89-003)
    
+		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    
+		Issue DEFINING-MACROS-NON-TOP-LEVEL
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 10 Mar 1989, Sandra Loosemore
    
+		V2, 13 Mar 1989, Sandra Loosemore
    
+		V3, 21 Mar 1989, Sandra Loosemore (fix error language)
    
+		V4, 11 Jun 1989, Sandra Loosemore (Gregor's amendment)
    
+		V5, 23 Jun 1989, Sandra Loosemore (wording changes per Pitman)
    
+Status:		Proposal MINIMAL passed, June 89
    
+		Recommendation to drafting committee:  clarify that the 
    
+		provisions listed under DEFCLASS are intended to affect 
    
+		warnings emitted by the compiler.
    
+
    
+
    
+Problem Description:
    
+
    
+Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
    
+DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
    
+to those for DEFSTRUCT or DEFMACRO?
    
+
    
+A part of the problem is that we do not currently have a full
    
+understanding of all the issues involved.  In particular, work on
    
+defining the CLOS meta-object protocol is still in progress.  The goal
    
+of this proposal is to say enough about the behavior of these macros
    
+in the standard so that users can use them portably in compiled code,
    
+but to leave as much of the behavior as possible unspecified to avoid
    
+placing undue restrictions on the meta-object protocol.
    
+
    
+
    
+Proposal CLOS-MACRO-COMPILATION:MINIMAL:
    
+
    
+ State that top-level calls to the CLOS defining macros have the
    
+ following compile-time side-effects.  Any other compile-time behavior
    
+ is explicitly left unspecified.
    
+
    
+  DEFCLASS:
    
+  
    
+  * The class name may appear in subsequent type declarations.
    
+  
    
+  * The class name can be used as a specializer in subsequent 
    
+    DEFMETHOD forms.
    
+  
    
+  DEFGENERIC:
    
+  
    
+  * The generic function can be referenced in subsequent DEFMETHOD forms.  
    
+
    
+  * DEFGENERIC does not arrange for the generic function to be callable
    
+    at compile time.
    
+  
    
+  DEFMETHOD:
    
+  
    
+  * DEFMETHOD does not arrange for the method to be callable at compile
    
+    time.  If there is a generic function with the same name defined at
    
+    compile time, compiling a DEFMETHOD does not add the method to that 
    
+    generic function.  (That is, the method is added to the generic
    
+    function only when the DEFMETHOD is actually executed.)
    
+
    
+    The error-signalling behavior described in the specification of
    
+    DEFMETHOD in CLOS chapter 2 (if the function isn't a generic function
    
+    or if the lambda-list is not congruent) happens only when the defining
    
+    form is executed, not at compile time.
    
+
    
+    The forms in EQL specializers are evaluated when the defining form
    
+    is executed.  The compiler is permitted to build in knowledge
    
+    about what the form in an EQL specializer will evaluate to in cases
    
+    where the ultimate result can be syntactically inferred without
    
+    actually evaluating it.
    
+
    
+  DEFINE-METHOD-COMBINATION:
    
+  
    
+  * The method combination can be used in subsequent DEFGENERIC forms.  
    
+
    
+    The body of a DEFINE-METHOD-COMBINATION form is evaluated no earlier 
    
+    than when the defining macro is executed and possibly as late as 
    
+    generic function invocation time.  The compiler may attempt to
    
+    evaluate these forms at compile time but must not depend on being able
    
+    to do so.
    
+
    
+ Rationale:
    
+
    
+  The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
    
+  DEFTYPE.  
    
+
    
+  DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
    
+  function definition to the compile-time environment.  Since generic
    
+  functions may be freely redefined between compile and run time (just
    
+  like any other function), a method may end up "belonging" to a
    
+  different generic function at load time than at compile time.  This
    
+  is why it is inappropriate to signal errors about congruency problems
    
+  (etc) until the method is actually added to the generic function at
    
+  run time.
    
+
    
+
    
+Current Practice:
    
+
    
+  The items listed under DEFCLASS in proposal MINIMAL are fairly standard
    
+  programming style.
    
+
    
+  Flavors does not support compile-time instantiation of classes.  It
    
+  does not make method combinations available at compile-time either, but
    
+  Moon considers that to be a bad design choice.
    
+
    
+Cost to implementors:
    
+
    
+  Unknown.
    
+
    
+Cost to users:
    
+
    
+  Unknown, but probably fairly small.
    
+
    
+  Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
    
+  definitions will make sure they are fully defined at compile-time.
    
+  Alternatively, the definitions could be placed in a separate file,
    
+  which is loaded before compiling the file that depends on those
    
+  definitions.
    
+
    
+Benefits:
    
+
    
+  Programmers can rely on programs that use the CLOS defining macros 
    
+  being able to compile correctly in all implementations, without having
    
+  to wrap explicit EVAL-WHENs around every macro call.
    
+
    
+Discussion:
    
+
    
+  This writeup is based on discussions between Moon, Gray, and
    
+  Loosemore, who are mostly in agreement on the things presented in
    
+  proposal MINIMAL.  We have purposely avoided saying anything about
    
+  whether meta-objects representing the classes, methods, etc. get
    
+  created at compile-time, or whether such meta-objects are fully or
    
+  partially defined.  The basic questions addressed by this issue are
    
+  what kinds of things can be defined and then used during compilation
    
+  of the same file that defines them, and what restrictions might apply.
    
+
    
+  These proposals are not completely compatible with the meta-object 
    
+  protocol document (89-003).  Gregor Kiczales says:
    
+    No one believes that what is written in draft 10 of the MOP is valid.
    
+
    
+  Sandra Loosemore says:
    
+    Although I admit I don't understand all of the issues involved with
    
+    the meta-object protocol, I prefer proposal MINIMAL over 
    
+    NOT-SO-MINIMAL.  I don't think leaving the issue of whether or not
    
+    classes can be instantiated at compile-time unspecified places an
    
+    undue burden on users, and it does leave more freedom for the
    
+    meta-object protocol to decide what the right behavior really is.
    
+
    
+  Dick Gabriel notes:
    
+    The question I have about the process going on with respect to the
    
+    CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
    
+    CLOS under various compilation/evaluation situations is being
    
+    over-specified. 
    
+
    
+    At this stage of the game I worry that we might go a little too far in
    
+    one direction in specification when we are actually engaged in design
    
+    work. This isn't intended to be a criticism of any committees, but I
    
+    would feel a lot more comfortable with a conservative specification
    
+    that defined well-formed programs being loaded or compiled in fresh
    
+    Common Lisps with a pretty simple eval-when model that is easier to
    
+    specify and which makes it easy for all but the hairiest
    
+    compilation-environment-frobbing programs to be written.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052.htm new file mode 100644 index 00000000..d7fe93f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052_w.htm new file mode 100644 index 00000000..04c658eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss052_w.htm @@ -0,0 +1,165 @@ + + + +CLHS: Issue CLOSE-CONSTRUCTED-STREAM Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLOSE-CONSTRUCTED-STREAM Writeup

    + +
    Status:	DRAFT
    
+Forum:	Cleanup
    
+Issue:         CLOSE-CONSTRUCTED-STREAM
    
+
    
+References:    Close (CLtL p. 332), WITH-OPEN-STREAM 
    
+	(CLtL p 330), make-synonym-stream, make-broadcast-stream,
    
+	make-concatenated-stream, make-two-way-stream,
    
+	make-echo-stream, make-string-input-stream,
    
+	make-string-output-stream, with-input-from-string,
    
+	with-output-from-string
    
+
    
+Related issues: CLOSED-STREAM-OPERATIONS
    
+
    
+Category:      Clarification/Change
    
+
    
+Edit history:  Masinter,  6-Jan-89, Version 1
    
+               Masinter, 12-Jan-89, Version 2
    
+
    
+Problem description:
    
+
    
+First some terminology:
    
+
    
+A "composite" stream is one created with MAKE-SYNONYM-STREAM, 
    
+MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, 
    
+MAKE-ECHO-STREAM. 
    
+
    
+The "constituents" of a composite stream are the streams it points to:
    
+the SYMBOL-VALUE of the symbol given to MAKE-SYNONYM-STREAM
    
+the streams given to MAKE-BROADCAST-STREAM or MAKE-CONCATENATED-STREAM
    
+the input-stream and output-stream given to MAKE-TWO-WAY-STREAM or MAKE-ECHO-STREAM.
    
+
    
+A "constructed" stream is either a composite stream or one created with 
    
+MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM, WITH-INPUT-FROM-STRING,
    
+ WITH-OUTPUT-FROM-STRING.
    
+
    
+The function "CLOSE" is currently described in 21.3, which starts "This
    
+section contains discussion of only those operations that are common to all
    
+streams."  This would seem to imply that they apply to constructed streams. 
    
+
    
+The definition of CLOSE "The argument must be a stream. No further input/output
    
+ operations may be performed on it. ... "  It further states "... and it is 
    
+permissible to close an already closed stream."
    
+
    
+However, the behavior on the constructed streams is not well defined, and
    
+implementations (apparently) differ.
    
+
    
+Proposal (CLOSE-CONSTRUCTED-STREAM:IS-ERROR): 
    
+
    
+It "is an error" to call CLOSE on a constructed stream. CLOSE might signal an
    
+error, or the result of CLOSE could cause the constituent streams to be closed,
    
+etc, but the effect is implementation-dependent.
    
+
    
+Proposal: (CLOSE-CONSTRUCTED-STREAM:SIGNALS-ERROR)
    
+
    
+Calling CLOSE on a constructed stream signals an error.
    
+
    
+Proposal (CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY):
    
+
    
+The effect of CLOSE on a constructed stream is to close the "argument" stream
    
+only. No i/o operations are permitted after the call to CLOSE on the stream
    
+given to CLOSE; There is no effect on the constituents of composite streams.
    
+
    
+For streams created with MAKE-STRING-OUTPUT-STREAM, the result of
    
+GET-OUTPUT-STREAM-STRING is unspecified after CLOS. For composite streams,
    
+the call to CLOSE has no effect on any of the constituent streams.
    
+
    
+The "links" to the constituents may be broken; if the proposal in STREAM-ACCESS 
    
+passes, the results of the accessor functions there are unspecified after the
    
+call to CLOSE.)
    
+
    
+Proposal: (CLOSE-CONSTRUCTED-STREAM:CLOSE-CONSTITUENTS)
    
+
    
+CLOSE first closes its argument; it then operates recursively on the constituents
    
+of composite streams.
    
+
    
+Examples:
    
+
    
+>>not written; sorry<<
    
+
    
+Rationale:
    
+
    
+Specifying seems better than not saying what happens, even if it is
    
+"implementation-dependent".
    
+
    
+Current practice:
    
+
    
+Implementations seem to vary widely.
    
+
    
+Cost to Implementors:
    
+
    
+Varying, depending on the current level of conformance. Making the changes
    
+themselves is probably trivial (to the "close" method for each kind of
    
+constructed stream type) but it is possible that system code might depend
    
+on the behavior.
    
+
    
+Cost to Users:
    
+
    
+Likely small; we've not found any good uses for CLOSE on composite streams.
    
+
    
+Cost of non-adoption:
    
+
    
+Continued minor ambiguity
    
+
    
+Performance impact:
    
+
    
+near zero
    
+
    
+Benefits:
    
+
    
+The language would be more well specified.
    
+
    
+Esthetics:
    
+
    
+Well-specified languages are usually easier to deal with.
    
+
    
+Discussion:
    
+
    
+Signalling an error is reasonable if no Common Lisp program ever needs to
    
+call CLOSE on a composite stream. We could not come up with a legitimate
    
+case where you wouldn't instead close the underlying stream if that's what
    
+you wanted.
    
+
    
+Allowing the result to be implementation dependent is the "status quo". 
    
+
    
+ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it
    
+harder to accidentally close a stream that wasn't intended. It
    
+seems counterintuitive and yet it probably wouldn't be harmful
    
+if it were well-defined that this was what it did.
    
+
    
+CLOSE-CONSTITUENTS could be an incompatible change for some
    
+implementations. It makes more sense for things like broadcast streams
    
+(which are usually non-interactive) than it does for echo streams
    
+(which are sometimes interactive).
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053.htm new file mode 100644 index 00000000..d630e38d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053.htm @@ -0,0 +1,46 @@ + + + +CLHS: Issue CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053_w.htm new file mode 100644 index 00000000..65a53883 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss053_w.htm @@ -0,0 +1,166 @@ + + + +CLHS: Issue CLOSED-STREAM-OPERATIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CLOSED-STREAM-OPERATIONS Writeup

    + +
    Status: Passed Jan 89 X3J13 with amendment to specify that CLOSE on a
    
+closed stream returns NIL. At Mar 89 X3J13, amendment was withdrawn;
    
+this version stands.
    
+
    
+Forum:          Cleanup
    
+Issue:          CLOSED-STREAM-OPERATIONS
    
+References:     CLOSE (CLtL p 332)
    
+Category:       CLARIFICATION
    
+Edit history:   26-Aug-88, Version 1 by Chapman
    
+                 8-Oct-88, Version 2 by Masinter
    
+                13-Oct-88, Version 3 by van Roggen
    
+                 1-Dec-88, Version 4 by Pitman
    
+                 5-Dec-88, Version 5 by Masinter (separate other issues)
    
+Related Issues: STREAM-ACCESS, STREAM-INFO, INPUT-STREAM-P-CLOSED,
    
+			CLOSE-CONSTRUCTED-STREAMS, PATHNAME-STREAM
    
+ 
    
+Problem Description:
    
+ 
    
+ The description of CLOSE is not completely clear about the functions
    
+ which are allowed to be performed on a closed stream.
    
+ 
    
+ On p332 it says:
    
+
    
+  ``The stream is closed. No further Input/output operations may be
    
+    performed on it. However, certain inquiry operations may still
    
+    be performed, ...''
    
+
    
+  but the list of inquiry operations is not specified.
    
+ 
    
+Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
    
+ 
    
+ Clarify the behavior of the following functions on closed streams:
    
+
    
+  * STREAMP is unaffected by whether its stream argument is open or closed.
    
+ 
    
+  * If CLOSE is called on a stream which is open, it will return T.
    
+    However, if CLOSE is called on a stream which is closed, it
    
+    will succeed without error but the return value is not specified.
    
+ 
    
+  * PATHNAME is valid on either an open or closed stream. Since some
    
+    implementations cannot provide the truename of a file until the
    
+    file is closed, it would in principle be possible for PATHNAME in
    
+    some implementations to return more specific information after the
    
+    stream is closed. For consistency, however, PATHNAME is prohibited
    
+    from doing this. PATHNAME must return the same pathname after a
    
+    file is closed as it did before. (The passed proposal in issue
    
+    PATHNAME-STREAM still stands.)
    
+ 
    
+  * TRUENAME is valid on either an open or closed stream. Since some
    
+    implementations cannot provide the truename of a file until the
    
+    file is closed, it is permissible TRUENAME to return more specific
    
+    information after the stream is closed.
    
+ 
    
+  * MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
    
+    PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, 
    
+    FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, 
    
+    ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
    
+    For any of these operations, using a stream, S, as an argument 
    
+    where appropriate is equivalent to using (PATHNAME s). See the
    
+    description of PATHNAME above to understand the consequences of this.
    
+ 
    
+  * PROBE-FILE and DIRECTORY are valid on either open or closed streams.
    
+    For either of these operations, using a stream, S, as an argument 
    
+    where appropriate is equivalent to using (PATHNAME s). See the
    
+    description of PATHNAME above to understand the consequences of this.
    
+    In this case of these operators however, closed stream may well be the
    
+    most reliable arguments in some cases, since treatment of open streams
    
+    to the file system may vary considerably between implementations.
    
+    For example, in some operating systems, open files are written under
    
+    temporary names and not renamed until close and/or are held invisible
    
+    until a close is performed. In general, any code with an intent to be
    
+    highly portable should tread lightly when using PROBE-FILE or
    
+    DIRECTORY.
    
+ 
    
+Rationale:
    
+ 
    
+ One can consider many characteristics of a stream to be independent of
    
+ the ability to do I/O.  Being able to determine a stream's direction and
    
+ its name is often useful for debugging.  A number of the descriptions in
    
+ CLtL imply (weakly) the ability to work on closed streams.  Functions
    
+ such as OPEN and DIRECTORY don't really depend on the stream, but on
    
+ the name of the stream.
    
+ 
    
+Current Practice:
    
+ 
    
+ At least two implementations differ in which functions are allowed to be
    
+ performed on a closed stream.
    
+ 
    
+Cost to Implementors:
    
+ 
    
+ Unknown, but likely to be small in most implementations.
    
+
    
+ A nontrivial amount of work may be necessary if the pathname information
    
+ is held  externally and is normally deleted when the stream is closed. 
    
+ The implementation will have to copy the information at some time for later
    
+ inquiries.
    
+
    
+Cost to Users:
    
+
    
+ Likely to be small; users of an implementation forced to change
    
+ by this proposal might have to make some modifications to make their
    
+ programs portable.
    
+ 
    
+Benefits:
    
+ 
    
+ These clarifications will assist users in writing portable code.
    
+ 
    
+Aesthetics:
    
+ 
    
+ Most people will probably see these clarifications as an improvement
    
+ in aesthetics.
    
+ 
    
+Discussion:
    
+
    
+ There are some separate, but related, issues regarding what CLOSE
    
+ should do on composite streams or constructed streams such as
    
+ created by MAKE-BROADCAST-STREAM. These issues will be addressed
    
+ in a separate issue (CLOSE-CONSTRUCTED-STREAMS).
    
+
    
+ There was some discussion on whether INPUT-STREAM-P and OUTPUT-STREAM-P
    
+ should return "false" on a stream that had been closed. The issue
    
+ STREAM-ACCESS contains a proposal to add a function OPEN-STREAM-P
    
+ which might be useful for the same purpose. This issue was separated
    
+ out into a separate issue (INPUT-STREAM-P-CLOSED).
    
+
    
+ The other functions in proposal STREAM-ACCESS:PROVIDE should
    
+ work on closed streams.
    
+
    
+ The functions in STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS should
    
+ not be requred to work on closed streams.
    
+
    
+
    
+
    
+
    
+     ----- End Forwarded Messages -----
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054.htm new file mode 100644 index 00000000..2848fc25 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054_w.htm new file mode 100644 index 00000000..605fd689 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss054_w.htm @@ -0,0 +1,90 @@ + + + +CLHS: Issue COERCING-SETF-NAME-TO-FUNCTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COERCING-SETF-NAME-TO-FUNCTION Writeup

    + +
    Issue:          COERCING-SETF-NAME-TO-FUNCTION
    
+Reference:      X3J13/92-102, dpANS 12.24
    
+                  COERCE, p.4-30..32
    
+                X3J13/89-520, Issue FUNCTION-NAME
    
+                X3J13/88-413, Issue FUNCTION-TYPE
    
+                X3J13/92-3101, Kim Barrett comment #1
    
+Category:       ADDITION
    
+Edit History:   Version 1, 06/15/91, Kim Barrett
    
+                Version 2, 06/22/91, Kim Barrett (summarize discussion)
    
+                Version 3, 01/06/93, Kim Barrett (update references)
    
+                Version 4, 01/06/93, Kim Barrett (name the proposal)
    
+Status:         Proposal ALL-FUNCTION-NAMES accepted, Mar 1993
    
+
    
+Problem Description:
    
+
    
+ COERCE doesn't currently provide a means of converting a SETF function name to
    
+ a function object, as it does for functions named by symbols.  FUNCTION-TYPE
    
+ was written too early to cover this, and FUNCTION-NAME didn't correct it.
    
+
    
+Proposal (COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES):
    
+
    
+ Change the argument permitted by COERCE when the type argument is FUNCTION to
    
+ treat all function names as it currently treats symbols.  The following change
    
+ to the 12.24 draft is required:
    
+
    
+ In the description of the COERCE function, the first paragraph of the section
    
+ for the FUNCTION result-type (p.4-31) says:
    
+
    
+    If the \param{result-type} is \typeref{function},
    
+    and \param{object} is any \term{symbol} that is \term{fbound} 
    
+    but that is globally defined neither as a \term{macro name} nor as
    
+    a \term{special operator}, then the \param{result} is the
    
+    \term{functional value} of \param{object}.
    
+
    
+ Change the occurance of the term \term{symbol} to instead be
    
+ \term{function name}, so that the sentence reads:
    
+
    
+    If the \param{result-type} is \typeref{function},
    
+    and \param{object} is any \term{function name} that is \term{fbound} 
    
+    but that is globally defined neither as a \term{macro name} nor as
    
+    a \term{special operator}, then the \param{result} is the
    
+    \term{functional value} of \param{object}.
    
+
    
+Editorial Impact:
    
+
    
+ Single term change.
    
+
    
+Rationale:
    
+
    
+ This corrects an apparent oversight in the FUNCTION-NAME proposal.
    
+
    
+Discussion:
    
+
    
+ Moon and others feel that (COERCE symbol 'FUNCTION) is questionable, but that
    
+ it would be better to make a small upwardly compatible change for consistancy
    
+ rather than leaving things inconsistant, and that even worse would be the now
    
+ incompatible change involved in the removal of the coercion of symbols to
    
+ functions.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055.htm new file mode 100644 index 00000000..9de9d840 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COLON-NUMBER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COLON-NUMBER Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COLON-NUMBER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055_w.htm new file mode 100644 index 00000000..4658c387 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss055_w.htm @@ -0,0 +1,94 @@ + + + +CLHS: Issue COLON-NUMBER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COLON-NUMBER Writeup

    + +
    Issue:        COLON-NUMBER
    
+References:   Parsing of Numbers and Symbols (p339-341, 343-344)
    
+Category:     CLARIFICATION
    
+Edit history: 22-Oct-87, Version 1 by Pitman
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+  CLtL is unclear about whether a colon followed by a potential number
    
+  is a potential number. There are passages which seem to address this
    
+  issue unambiguously but fail.
    
+
    
+Proposal (COLON-NUMBER:UNDEFINED):
    
+
    
+  Clarify that syntax involving a leading colon followed by a potential
    
+  number is not well-defined. That is, use of notation such as :1, :1/2,
    
+  and :2^3 in a position where an expression appropriate for READ is
    
+  expected is an error.
    
+
    
+Rationale:
    
+
    
+  This makes the status quo apparent.
    
+
    
+Current Practice:
    
+
    
+  Some implementations, such as Symbolics Lisp, claim the right to 
    
+  interpret this as an ``is an error'' situation where their
    
+  upward-compatible extension is to parse ``:1'' as the number 1
    
+  (incidentally, but uninterestingly, expressed in the KEYWORD package).
    
+
    
+  Other implementations tokenize ``:1'' as a single token, identify it
    
+  as a symbol, and then parse it as :\1 would be parsed.
    
+
    
+Adoption Cost:
    
+
    
+  None. This clarification forces no implementations to change.
    
+
    
+Benefits:
    
+
    
+  Programmer expectations that any useful behavior can be portably relied
    
+  upon in this pathological case should be soundly trounced.
    
+
    
+Conversion Cost:
    
+
    
+  Slight. Some users may have mistakenly believed that this was an aspect
    
+  of the language that was guaranteed and may have written programs that
    
+  exploited that belief. Such incidences are probably very rare, however.
    
+  Also, even in the few cases where such code fortuitously worked,
    
+  implementations are likely to continue to support it so such code will
    
+  probably continue to fortuitously work in many of those rare situations.
    
+
    
+Aesthetics:
    
+
    
+  Arguably a slight improvement in visual aesthetics. What was already 
    
+  a pretty marginal syntax is discouraged.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this clarification. He thinks this issue is not a big
    
+  deal, but it does crop up often enough to be a nuisance. It would be
    
+  nice to have everyone acknowledge a unified position, even if that only
    
+  meant agreeing to disagree.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056.htm new file mode 100644 index 00000000..4c118c06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COMMON-FEATURES:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMMON-FEATURES:SPECIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COMMON-FEATURES:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056_w.htm new file mode 100644 index 00000000..e917e22c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss056_w.htm @@ -0,0 +1,153 @@ + + + +CLHS: Issue COMMON-FEATURES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMMON-FEATURES Writeup

    + +
    Issue:        COMMON-FEATURES
    
+Forum:	      Cleanup
    
+References:   None
    
+Category:     Addition
    
+Edit history: 01-Mar-91, Version 1 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  The Common Lisp dialect defined by this standard needs a feature which 
    
+  uniquely identifies it in *FEATURES* so that it can be distinguished
    
+  from other similar dialects (e.g., those described in CLtL1 and CLtL2).
    
+
    
+Proposal (COMMON-FEATURES:SPECIFY):
    
+
    
+  Specify the following meanings for features:
    
+
    
+    :CLTL1
    
+
    
+      An implementation which purports to support a LISP package that
    
+      implements Common Lisp according to the 1984 specification 
    
+      ``Common Lisp: The Language'' should place this feature on *FEATURES*.
    
+      This feature is -not- precluded by any of the features :CLTL2,
    
+      :X3J13, :DRAFT-ANSI-CL, or :ANSI-CL.
    
+
    
+    :CLTL2
    
+
    
+      An implementation which purports to support a COMMON-LISP package
    
+      that implements Common Lisp according to Steele's 1990 book, 
    
+      ``Common Lisp: The Language, Second Edition'' (CLtL2) should have place
    
+      feature on *FEATURES*.  This feature -is- precluded by any of the
    
+      features :DRAFT-ANSI-CL or :ANSI-CL.
    
+
    
+    :X3J13
    
+
    
+      An implementation which purports to support a COMMON-LISP package
    
+      that corresponds to some unpublished working draft, or some mix of
    
+      features that approximates an expected X3J13 Draft should place
    
+      this feature on *FEATURES*.
    
+
    
+      If this feature appears, :CLTL2 should not appear unless the
    
+      implementation is compatible with and includes as a subset, the 
    
+      dialect described by CLtL2.
    
+
    
+    :DRAFT-ANSI-CL
    
+
    
+      If and when this specification has gone out for public review,
    
+      implementations which purport to implement the full draft standard
    
+      should place this keyword on *FEATURES*.
    
+
    
+      If subsequent drafts are produced before a final standard, additional
    
+      keywords to identify those drafts will be identified at that time.
    
+
    
+      This feature is precluded by :ANSI-CL unless the draft ANSI specification
    
+      and the final ANSI specification are completely compatible.
    
+
    
+    :ANSI-CL
    
+
    
+      If and when this specification is approved as an ANSI standard,
    
+      implementations which purport to implement that ANSI standard
    
+      should place this keyword on *FEATURES*.
    
+
    
+    :COMMON-LISP
    
+
    
+      This feature must appear in *FEATURES* for any implementation that
    
+      has one or more of the features :X3J13, :DRAFT-ANSI-CL, or :ANSI-CL.
    
+      This feature might appear in *FEATURES* for any implementation that
    
+      has one or more of the features :CLTL2 and :CLTL1.
    
+
    
+Examples:
    
+
    
+  #+ANSI-CL FOO     ;Sees FOO only in an ANSI standard Common Lisp.
    
+  #-ANSI-CL FOO     ;Sees FOO only in a Common Lisp which is not an ANSI standard.
    
+
    
+  #+DRAFT-ANSI-CL FOO ; Sees FOO only in a DRAFT ANSI standard Common Lisp.
    
+  #+DRAFT-ANSI-CL FOO ; Sees FOO only in a DRAFT ANSI standard Common Lisp.
    
+
    
+  #+CLTL1 (LISP:REQUIRE ...) ; Sees the (LISP:REQUIRE ...) 
    
+			     ;only if CLtL1 compatibility support is available.
    
+
    
+Rationale:
    
+
    
+  Users need this to get a foothold as they try to port between dialects
    
+  in transition.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera does not have any of these features.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Users will have to figure out `more imaginative' ways of determining
    
+  this kind of information which they commonly want to know.  In many
    
+  cases, they will add features with names like these themselves, 
    
+  sometimes according to differing criteria, so that if two applications
    
+  which follow such a strategy are loaded into the same environment, they
    
+  might manage to confuse each other if one adds a feature that it thinks
    
+  is not standard and the other intentionally doesn't add the same feature,
    
+  only to find that it's there anyway.
    
+
    
+Benefits:
    
+
    
+  See above.
    
+
    
+Aesthetics:
    
+
    
+  Features lists are not really about aesthetics--they're about survival.
    
+  But nevertheless, giving a standard meaning to terms which name standard
    
+  dialects seems like a plus.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal, but would consider any other reasonable
    
+  alternative that addressed the same issues in a serious way.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057.htm new file mode 100644 index 00000000..c0c406b6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue COMMON-TYPE:REMOVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMMON-TYPE:REMOVE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMMON-TYPE:REMOVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057_w.htm new file mode 100644 index 00000000..b780b64f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss057_w.htm @@ -0,0 +1,95 @@ + + + +CLHS: Issue COMMON-TYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMMON-TYPE Writeup

    + +
    Issue:         COMMON-TYPE
    
+
    
+References:    CLtL p.35, p.76
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1, 20-Mar-89, by Moon
    
+
    
+Problem description:
    
+  
    
+  The type COMMON is defined in a very peculiar way and does not seem to
    
+  be useful for anything.  It can be extended by users using DEFSTRUCT,
    
+  but not DEFTYPE nor DEFCLASS, but it cannot be extended by implementations.
    
+  Whether certain types such as NUMBER and ARRAY are subtypes of COMMON
    
+  is implementation-dependent.  The goal of having the COMMON type was
    
+  probably to improve portability, but it is unclear how it could actually
    
+  be used in that way.
    
+
    
+Proposal (COMMON-TYPE:REMOVE):
    
+
    
+  Remove COMMON and COMMONP from the language.
    
+
    
+Rationale:
    
+  
    
+  Keeping the definition of COMMON accurate in the new specification, in
    
+  the face of changes elsewhere in the language such as the introduction
    
+  of CLOS and the possible introduction of character registries, is
    
+  difficult when no one is sure what COMMON is for.  If no one uses COMMON,
    
+  it would be less work to just get rid of it.
    
+
    
+Current practice:
    
+  
    
+  Every implementation probably implements COMMON.  Moon has never seen it
    
+  used except in a program to test whether its implementation matched CLtL.
    
+
    
+Cost to Implementors:
    
+
    
+  None.
    
+
    
+Cost to Users:
    
+
    
+  None unless they are actually using COMMON.
    
+
    
+Cost of non-adoption:
    
+  
    
+  Implementors would have to maintain COMMON.  Users would have to try to
    
+  understand it, or figure out that they didn't care about it.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Simpler language.
    
+
    
+Esthetics:
    
+
    
+  Simpler language.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058.htm new file mode 100644 index 00000000..d80a7631 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058_w.htm new file mode 100644 index 00000000..686e6ecd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss058_w.htm @@ -0,0 +1,89 @@ + + + +CLHS: Issue COMPILE-ARGUMENT-PROBLEMS-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILE-ARGUMENT-PROBLEMS-AGAIN Writeup

    + +
    Issue:		COMPILE-ARGUMENT-PROBLEMS-AGAIN
    
+References:	COMPILE-ARGUMENT-PROBLEMS, draft 10.156 p.3-52
    
+Category:	CHANGE
    
+Edit History:   9-Dec-91, Version 1, by Moon
    
+Status:         Passed 10-Dec-91; 11-0 on part 1, 9-1-1 on part 2
    
+
    
+Problem Description:
    
+
    
+  Cleanup COMPILE-ARGUMENT-PROBLEMS:CLARIFY created a couple of problems:
    
+
    
+  (1) It says "The consequences of calling COMPILE on a function that is already
    
+  compiled are unspecified" but the spec doesn't provide any way to create a
    
+  function that is guaranteed not to be compiled already.  In fact the example
    
+  at the top of page 3-52 is invalid because of this.
    
+
    
+  (2) It says the consequences are undefined "if the function to be compiled was
    
+  defined interpretively in a non-null lexical environment", but a non-null
    
+  lexical environment doesn't imply a closure. It might just have declarations in
    
+  it. The original motivation was "Many implementations cannot correctly compile
    
+  functions that are defined interpretively in a non-null lexical environment,
    
+  because the compiler and interpreter use different representations for
    
+  closures."
    
+
    
+Proposal (COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX):
    
+
    
+  (1) Remove the quoted text and specify that COMPILE either returns the function
    
+  it is given or returns an equivalent function, but in any case returns a
    
+  COMPILED-FUNCTION.
    
+
    
+  (2) Replace the quoted text with "if the lexical environment surrounding the
    
+  function to be compiled contains any bindings other than macros, symbol macros,
    
+  or declarations".
    
+
    
+Rationale:
    
+
    
+  (1) Given a function that is already compiled, COMPILE can simply return it.
    
+
    
+  (2) Bindings that minimal compilation would remove shouldn't prevent COMPILE
    
+  from working, since no closure would be required.
    
+
    
+Cost to implementors:
    
+
    
+  (1) Trivial.
    
+  (2) Might require some work, depending on what the interpreter does with
    
+  macros in the lexical environment of an interpreted function.
    
+
    
+Cost to users:
    
+
    
+  None.  This is an upward-compatible change.
    
+
    
+Benefits:
    
+
    
+  (1) Users don't have to insert extra COMPILED-FUNCTION-P checks.
    
+  (2) Make the language less restrictive.
    
+
    
+Discussion:
    
+
    
+  Parts 1 and 2 should be voted separately.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059.htm new file mode 100644 index 00000000..200b775b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059.htm @@ -0,0 +1,51 @@ + + + +CLHS: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059_w.htm new file mode 100644 index 00000000..aa8fe8d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss059_w.htm @@ -0,0 +1,252 @@ + + + +CLHS: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS Writeup

    + +
    Forum:		Compiler
    
+Issue:		COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    
+References:	CLtL pages 66-70, 143
    
+Category:	CLARIFICATION
    
+Edit history:   V1, 07 Oct 1987 Sandra Loosemore
    
+                V2, 15 Oct 1987 Sandra Loosemore
    
+                V3, 15 Jan 1988 Sandra Loosemore
    
+		V4, 06 May 1988 Sandra Loosemore
    
+		V5, 20 May 1988 Sandra Loosemore
    
+		V6, 09 Jun 1988 Sandra Loosemore
    
+		V7, 16 Dec 1988 Sandra Loosemore
    
+			(Comments from Pitman, change DEFCONSTANT, etc.)
    
+		V8, 31 Dec 1988 Sandra Loosemore
    
+			(CLOS additions, etc.)
    
+		V9, 23 Jan 1989 Sandra Loosemore
    
+			(remove the CLOS additions again)
    
+Status: Proposal CLARIFY passed Jan 89
    
+
    
+
    
+Problem Description:
    
+
    
+Standard programming practices assume that, when calls to defining
    
+macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
    
+certain side-effects occur that affect how subsequent forms in the
    
+file are compiled.  However, these side-effects are not mentioned in
    
+CLtL, except for a passing mention that macro definitions must be
    
+``seen'' by the compiler before it can compile calls to those macros
    
+correctly.  In order to write portable programs, users must know
    
+exactly which defining macros have compile-time side-effects and what
    
+those side-effects are. 
    
+
    
+Inter-file compilation dependencies are distinct from, and not
    
+addressed by, this issue. 
    
+
    
+
    
+Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
    
+
    
+(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
    
+    within a file being processed by COMPILE-FILE, normally have
    
+    compile-time side effects which affect how subsequent forms in the
    
+    same file are compiled.  A convenient model for explaining how these
    
+    side effects happen is that the defining macro expands into one or
    
+    more EVAL-WHEN forms, and that the calls which cause the compile-time
    
+    side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
    
+    ...) form.
    
+
    
+(2) The affected defining macros and their specific side effects are
    
+    as follows.  In each case, it is identified what users must do to
    
+    ensure that their programs are conforming, and what compilers must do
    
+    in order to correctly process a conforming program.
    
+
    
+    DEFTYPE: Users must ensure that the body of a DEFTYPE form is
    
+    evaluable at compile time if the type is referenced in subsequent type
    
+    declarations.  The compiler must ensure that the DEFTYPE'd type
    
+    specifier is recognized in subsequent type declarations.  If the
    
+    expansion of a type specifier is not defined fully at compile time
    
+    (perhaps because it expands into an unknown type specifier or a
    
+    SATISFIES of a named function that isn't defined in the compile-time
    
+    environment), an implementation may ignore any references to this type
    
+    in declarations and/or signal a warning.
    
+    
    
+    DEFMACRO, DEFINE-MODIFY-MACRO: The compiler must store macro
    
+    definitions at compile time, so that occurrences of the macro later on
    
+    in the file can be expanded correctly.  Users must ensure that the
    
+    body of the macro is evaluable at compile time if it is referenced
    
+    within the file being compiled.
    
+     
    
+    DEFUN: DEFUN is not required to perform any compile-time side effects.
    
+    In particular, DEFUN does not make the function definition available
    
+    at compile time.  An implementation may choose to store information
    
+    about the function for the purposes of compile-time error-checking
    
+    (such as checking the number of arguments on calls), or to enable the
    
+    function to be expanded inline.
    
+     
    
+    DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
    
+    named by these forms have been proclaimed special.  However, it must
    
+    not evaluate the initial value form or SETQ the variable at compile
    
+    time.
    
+     
    
+    DEFCONSTANT: The compiler must recognize that the symbol names a
    
+    constant.  An implementation may choose to evaluate the value-form at
    
+    compile time, load time, or both.  Therefore users must ensure that
    
+    the value-form is evaluable at compile time (regardless of whether or
    
+    not references to the constant appear in the file) and that it always
    
+    evaluates to the same value.  
    
+
    
+    DEFSETF, DEFINE-SETF-METHOD: The compiler must make SETF methods
    
+    available so that it may be used to expand calls to SETF later on in
    
+    the file.  Users must ensure that the body of DEFINE-SETF-METHOD and
    
+    the complex form of DEFSETF are evaluable at compile time if the
    
+    corresponding place is referred to in a subsequent SETF in the same
    
+    file.  The compiler must make these SETF methods available to 
    
+    compile-time calls to GET-SETF-METHOD when its environment argument is
    
+    a value received as the &ENVIRONMENT parameter of a macro.
    
+     
    
+    DEFSTRUCT: The compiler must make the structure type name recognized
    
+    as a valid type name in subsequent declarations (as for DEFTYPE) and
    
+    make the structure slot accessors known to SETF.  In addition, the
    
+    compiler must save enough information about the structure type so that
    
+    further DEFSTRUCT definitions can :INCLUDE a structure type defined
    
+    earlier in the file being compiled.  The functions which DEFSTRUCT
    
+    generates are not defined in the compile time environment, although
    
+    the compiler may save enough information about the functions to code
    
+    subsequent calls inline.  The #S reader syntax may or may not be 
    
+    available at compile time.  
    
+
    
+    DEFINE-CONDITION: The rules are essentially the same as those for
    
+    DEFSTRUCT; the compiler must make the condition type recognizable as a
    
+    valid type name, and it must be possible to reference the condition
    
+    type as the parent-type of another condition type in a subsequent
    
+    DEFINE-CONDITION in the file being compiled.
    
+    
    
+    DEFPACKAGE:  All of the actions normally performed by this macro at load
    
+    time must also be performed at compile time.
    
+    
    
+
    
+(3) The compile-time side effects may cause information about the
    
+    definition to be stored differently than if the defining macro had
    
+    been processed in the "normal" way (either interpretively or by loading
    
+    the compiled file).
    
+    
    
+    In particular, the information stored by the defining macros at
    
+    compile time may or may not be available to the interpreter (either
    
+    during or after compilation), or during subsequent calls to COMPILE or
    
+    COMPILE-FILE.  For example, the following code is nonportable because
    
+    it assumes that the compiler stores the macro definition of FOO where
    
+    it is available to the interpreter:
    
+    
    
+        (defmacro foo (x) `(car ,x))
    
+        (eval-when (eval compile load)
    
+            (print (foo '(a b c))))
    
+    
    
+    A portable way to do the same thing would be to include the macro
    
+    definition inside the EVAL-WHEN:
    
+    
    
+        (eval-when (eval compile load)
    
+            (defmacro foo (x) `(car ,x))
    
+            (print (foo '(a b c))))
    
+
    
+
    
+
    
+Rationale:
    
+
    
+The proposal generally reflects standard programming practices.  The
    
+primary purpose of the proposal is to make an explicit statement that
    
+CL supports the behavior that most programmers expect and many
    
+implementations already provide.
    
+
    
+The primary point of controversy on this issue has been the treatment
    
+of the initial value form by DEFCONSTANT, where there is considerable
    
+variance between implementations.  The effect of the current wording is
    
+to legitimize all of the variants.
    
+
    
+
    
+Current Practice:
    
+
    
+Many (probably most) Common Lisp implementations, including VaxLisp
    
+and Lucid Lisp, are already largely in conformance.  
    
+
    
+In VaxLisp, macro definitions that occur as a side effect of compiling
    
+a DEFMACRO form are available to the compiler (even on subsequent
    
+calls to COMPILE or COMPILE-FILE), but are not available to the
    
+interpreter (even within the file being compiled).
    
+ 
    
+By default, Kyoto Common Lisp evaluates *all* top level forms as they
    
+are compiled, which is clearly in violation of the behavior specified
    
+on p 69-70 of CLtL.  There is a flag to disable the compile-time
    
+evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make
    
+their definitions available at compile-time either.
    
+
    
+
    
+Cost to implementors:
    
+
    
+The intent of the proposal is specifically not to require the compiler
    
+to have special knowledge about each of these macros.  In
    
+implementations whose compilers do not treat these macros as special
    
+forms, it should be fairly straightforward to use EVAL-WHENs in their
    
+expansions to obtain the desired compile-time side effects.
    
+
    
+
    
+Cost to users:
    
+
    
+Since CLtL does not specify whether and what compile-time side-effects
    
+happen, any user code which relies on them is, strictly speaking,
    
+nonportable.  In practice, however, most programmers already expect
    
+most of the behavior described in this proposal and will not find it
    
+to be an incompatible change.
    
+
    
+
    
+Benefits:
    
+
    
+Adoption of the proposal will provide more definite guidelines on how
    
+to write programs that will compile correctly under all CL
    
+implementations.
    
+
    
+
    
+Discussion:
    
+
    
+Reaction to a preliminary version of this proposal on the common-lisp
    
+mailing list was overwhelmingly positive.  More than one person
    
+responded with comments to the effect of "but doesn't CLtL already
    
+*say* that somewhere?!?"  Others have since expressed a more lukewarm
    
+approval.
    
+
    
+It has been suggested that this proposal should also include PROCLAIM.
    
+However, since PROCLAIM is not a macro, its compile-time side effects
    
+cannot be handled using the EVAL-WHEN mechanism.  A separate proposal
    
+seems more appropriate.
    
+
    
+Item (3) allows for significant deviations between implementations.
    
+While there is some sentiment to the effect that the compiler should
    
+store definitions in a manner identical to that of the interpreter,
    
+other people believe strongly that compiler side-effects should be
    
+completely invisible to the interpreter.  The author is of the opinion
    
+that since this is a controversial issue, further attempts to restrict
    
+this behavior should be considered as separate proposals.
    
+
    
+It should be noted that user-written code-analysis programs must
    
+generally treat these defining macros as special forms and perform
    
+similar "compile-time" actions in order to correctly process
    
+conforming programs.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060.htm new file mode 100644 index 00000000..1512d46f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060_w.htm new file mode 100644 index 00000000..c7ea75b0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss060_w.htm @@ -0,0 +1,122 @@ + + + +CLHS: Issue COMPILE-FILE-OUTPUT-FILE-DEFAULTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILE-FILE-OUTPUT-FILE-DEFAULTS Writeup

    + +
    Forum:		Public Review
    
+Issue:		COMPILE-FILE-OUTPUT-FILE-DEFAULTS
    
+References:	Loosemore's public review comment #6
    
+		COMPILE-FILE
    
+		COMPILE-FILE-PATHNAME
    
+                MERGE-PATHNAMES
    
+Category:	CLARIFICATION
    
+Edit history:	21 Dec 1992, Version 1 by Loosemore
    
+Status:		Proposal INPUT-FILE passed 11-0 on letter ballot 93-302
    
+
    
+
    
+Problem description:
    
+
    
+  It's stated that the input-file pathname to COMPILE-FILE is merged
    
+  against *DEFAULT-PATHNAME-DEFAULTS*, but nothing is said about
    
+  merging of the :OUTPUT-FILE pathname argument.  
    
+
    
+  Some existing Common Lisp implementations appear to merge it against 
    
+  the (merged) input-file pathname, and others appear to merge it against 
    
+  *DEFAULT-PATHNAME-DEFAULTS*.  In practice, this means that users always
    
+  have to do their own explicit merging before passing a pathname as the
    
+  :OUTPUT-FILE argument, which is a nuisance.
    
+
    
+  The discussion of pathname merging in CLtL (page 641 in CLtL-2)
    
+  presents a general model that seems appropriate:
    
+
    
+  "This is especially useful for cases such as a program that has
    
+  an input file and an output file....  Unspecified components of the
    
+  output pathname will come from the input pathname, except that 
    
+  the type should not default not to the type of the input but to
    
+  the appropriate default type for output from this program."
    
+
    
+  However, this paragraph appears in a mangled form in draft 12.24
    
+  (the second paragraph of the description section on page 19-35),
    
+  which might be taken to imply that MERGE-PATHNAMES is supposed to
    
+  automagically determine an appropriate default type.
    
+
    
+
    
+Proposal (COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE):
    
+
    
+  Clarify that the defaults for the output-file argument are taken 
    
+  from the pathname that results from merging the specified
    
+  input-file argument with *DEFAULT-PATHNAME-DEFAULTS*, except that
    
+  the type should to default to the appropriate default type for
    
+  compiled files.
    
+
    
+  Instruct the editor to fix the problem noted with the cited
    
+  paragraph in the MERGE-PATHNAMES description (for example, by
    
+  restoring the CLtL wording).
    
+  
    
+
    
+Rationale:
    
+
    
+  This seems like the right model.
    
+
    
+
    
+Current practice:
    
+
    
+  Varies, as noted in the problem description.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Some implementations will have to change, but it's not a huge
    
+  change.
    
+
    
+
    
+Cost to users:
    
+
    
+  None, since implementations already vary.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Specifying this behavior is more aesthetic than leaving it 
    
+  unspecified.
    
+
    
+
    
+Editorial impact:
    
+
    
+  The change requires adding a sentence or two to the dictionary
    
+  entry for COMPILE-FILE and replacing one paragraph in that for
    
+  MERGE-PATHNAMES.
    
+
    
+
    
+Discussion:
    
+
    
+  If the issue to extend COMPILE-FILE to accept an open stream as
    
+  an input-file argument passes (Pitmans' public review comment #14),
    
+  obviously the input file cannot provide any defaults if it is
    
+  an open stream that cannot be coerced to a pathname.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061.htm new file mode 100644 index 00000000..4c60e62f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COMPILE-FILE-PACKAGE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILE-FILE-PACKAGE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COMPILE-FILE-PACKAGE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061_w.htm new file mode 100644 index 00000000..1cbb0f37 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss061_w.htm @@ -0,0 +1,84 @@ + + + +CLHS: Issue COMPILE-FILE-PACKAGE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILE-FILE-PACKAGE Writeup

    + +
    Issue:		COMPILE-FILE-PACKAGE
    
+References:	CLtL p. 182, 183
    
+Category:	CHANGE, CLARIFICATION
    
+Edit History:   1 Sep 1988, Sandra Loosemore (initial version)
    
+		21 Sep 1988, Sandra Loosemore (minor tweak to current practice)
    
+
    
+
    
+Problem Description:
    
+
    
+The variable *PACKAGE* is rebound by the function LOAD, so that its
    
+old value will be restored in spite of any calls to IN-PACKAGE
    
+appearing in the file being loaded.  Since COMPILE-FILE must evaluate
    
+any top-level calls to IN-PACKAGE that it sees, it may also alter the
    
+value of *PACKAGE*.  It is inconsistent to have COMPILE-FILE and LOAD
    
+behave differently regarding the rebinding of this variable.
    
+
    
+
    
+Proposal COMPILE-FILE-PACKAGE:REBIND:
    
+
    
+Require COMPILE-FILE to rebind *PACKAGE* before processing the file.
    
+
    
+
    
+Rationale:
    
+
    
+This makes COMPILE-FILE and LOAD more consistent.  It is a more
    
+compatible solution than either requiring LOAD not to rebind
    
+*PACKAGE*, or removing the specialness of IN-PACKAGE and the other
    
+package functions.
    
+
    
+
    
+Current Practice:
    
+
    
+Lucid Common Lisp, the TI Explorer, and VaxLisp already implement this 
    
+proposal.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Trivial.
    
+
    
+
    
+Cost to users:
    
+
    
+I find it hard to believe that users would consider COMPILE-FILE altering
    
+the value of *PACKAGE* as a useful side effect.
    
+
    
+
    
+Benefits:
    
+
    
+The language is made more uniform.
    
+
    
+
    
+Discussion:
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062.htm new file mode 100644 index 00000000..6eeef348 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062_w.htm new file mode 100644 index 00000000..f41d31bf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss062_w.htm @@ -0,0 +1,94 @@ + + + +CLHS: Issue COMPILE-FILE-PATHNAME-ARGUMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILE-FILE-PATHNAME-ARGUMENTS Writeup

    + +
    Issue:              COMPILE-FILE-PATHNAME-ARGUMENTS
    
+References:         COMPILE-FILE, COMPILE-FILE-PATHNAME
    
+Related issues:     COMPILER-VERBOSITY
    
+                    PATHNAME-LOGICAL
    
+Category:           CLARIFICATION, CHANGE
    
+Edit history:       v1, 13 Feb 1991, Sandra Loosemore
    
+                    v2, 11 Mar 1991, Sandra Loosemore (suggestion from kmp)
    
+
    
+Problem description:
    
+
    
+  If an implementation extends COMPILE-FILE to recognize additional
    
+  implementation-specific keyword arguments, COMPILE-FILE-PATHNAME
    
+  must also support those additional arguments.  However, there is a
    
+  discrepancy between the standard keyword arguments accepted by
    
+  the two functions, as they are currently documented.  (COMPILE-FILE
    
+  has been extended to accept :VERBOSE and :PRINT keyword arguments.)
    
+
    
+Proposal (COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT):
    
+
    
+  Change the specification of the arguments to COMPILE-FILE-PATHNAME to
    
+
    
+  COMPILE-FILE-PATHNAME pathname &key :output-file &allow-other-keys
    
+
    
+
    
+Rationale:
    
+
    
+  The intent was clearly to enable COMPILE-FILE-PATHNAME to be applied
    
+  to any argument list acceptable to COMPILE-FILE.  Documenting
    
+  COMPILE-FILE-PATHNAME with &ALLOW-OTHER-KEYS fixes the problem without
    
+  worrying about future extensions and changes to COMPILE-FILE getting
    
+  things out of sync again.
    
+
    
+Current Practice:
    
+
    
+  Few implementations support COMPILE-FILE-PATHNAME or the extensions
    
+  to COMPILE-FILE yet.
    
+
    
+Cost to Implementors:
    
+
    
+  Trivial.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  COMPILE-FILE-PATHNAME can't be used reliably for what it was intended
    
+  to be used for.
    
+
    
+Performance impact:
    
+
    
+  Minor.
    
+
    
+Benefits:
    
+
    
+  A pointless inconsistency in the language is removed.
    
+
    
+Esthetics:
    
+
    
+  Looks OK to me.
    
+
    
+Discussion:
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063.htm new file mode 100644 index 00000000..226d2cce --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063_w.htm new file mode 100644 index 00000000..2a01382b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss063_w.htm @@ -0,0 +1,278 @@ + + + +CLHS: Issue COMPILE-FILE-SYMBOL-HANDLING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILE-FILE-SYMBOL-HANDLING Writeup

    + +
    Forum:		Compiler
    
+Issue:		COMPILE-FILE-SYMBOL-HANDLING
    
+References:	CLtL p. 182
    
+		Issue IN-PACKAGE-FUNCTIONALITY (passed)
    
+		Issue CONSTANT-COMPILABLE-TYPES (passed)
    
+		Issue DEFPACKAGE (passed)
    
+Category:	CHANGE/CLARIFICATION 
    
+Edit History:   V1, 01 Feb 1989, Sandra Loosemore
    
+		V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
    
+		V3, 18 Apr 1989, Sandra Loosemore (new proposal)
    
+		V4, 15 Jun 1989, Sandra Loosemore (minor wording changes)
    
+		V5, 04 Jul 1989, Sandra Loosemore (incorporate amendments)
    
+Status:		Passed, as amended, June 89
    
+		Recommendation to drafting committee:  in item 1b, clarify
    
+		that the "first" top-level form may appear as the first
    
+		form inside a top-level PROGN, as the result of macro
    
+		expansion, etc.
    
+		
    
+
    
+
    
+Problem Description:
    
+
    
+It is not clear how COMPILE-FILE is supposed to specify to LOAD how
    
+symbols in the compiled file should be interned.  In particular, what
    
+happens if the value of *PACKAGE* is different at load-time than it
    
+was at compile-time, or if any of the packages referenced in the file
    
+are defined differently?
    
+
    
+There are two models currently being used to implement this behavior:
    
+
    
+  (1) Symbols appearing in the output file produced by COMPILE-FILE
    
+      are qualified with package prefixes in the same way that PRINT
    
+      would qualify them.  Symbols that are accessible in *PACKAGE*
    
+      at compile-time are looked up in *PACKAGE* at load-time.  (This
    
+      is the "current-package" model.)
    
+
    
+  (2) Symbols appearing in the output file produced by COMPILE-FILE
    
+      are always qualified with the name of their home package,
    
+      regardless of the value of *PACKAGE*.  (This is the
    
+      "home-package" model.)
    
+
    
+
    
+Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:
    
+
    
+  In order to guarantee that compiled files can be loaded correctly,
    
+  users must ensure that the packages referenced in the file are defined
    
+  consistently at compile and load time.  Conforming Common Lisp programs
    
+  must satisfy the following requirements:
    
+  
    
+  (1) The value of *PACKAGE* when a top-level form in the file is processed
    
+      by COMPILE-FILE must be the same as the value of *PACKAGE* when the
    
+      code corresponding to that top-level form in the compiled file is
    
+      executed by the loader.  In particular:
    
+
    
+      (a) Any top-level form in a file which alters the value of *PACKAGE*
    
+          must change it to a package of the same name at both compile and
    
+          load time.
    
+
    
+      (b) If the first nonatomic top-level form in the file is not a call to
    
+          IN-PACKAGE, then the value of *PACKAGE* at the time LOAD is
    
+          called must be a package with the same name as the package that
    
+          was the value of *PACKAGE* at the time COMPILE-FILE was called.
    
+
    
+  (2) For all symbols appearing lexically within a top-level form that
    
+      were accessible in the package that was the value of *PACKAGE*
    
+      during processing of that top-level form at compile time, but
    
+      whose home package was another package, at load time there must
    
+      be a symbol with the same name that is accessible in both the
    
+      load-time *PACKAGE* and in the package with the same name as the
    
+      compile-time home package. 
    
+  
    
+  (3) For all symbols in the compiled file that were external symbols in
    
+      their home package at compile time, there must be a symbol with the
    
+      same name that is an external symbol in the package with the same name
    
+      at load time.
    
+        
    
+  If any of these conditions do not hold, the package in which LOAD looks
    
+  for the affected symbols is unspecified.  Implementations are permitted 
    
+  to signal an error or otherwise define this behavior.
    
+  
    
+  A symbol S appearing in the source code is similar as a constant to 
    
+  a symbol S' in the compiled code if:
    
+
    
+    o  Their print names are similar as constants
    
+
    
+  And, either
    
+
    
+    o  S is accessible in *PACKAGE* at compile time, and S' is accessible in
    
+       *PACKAGE* at load time
    
+
    
+  Or
    
+
    
+    o  S' is accessible in the package that is similar as a constant to the
    
+       home package of symbol S.
    
+
    
+  The "similar as constants" relationship for interned symbols has nothing
    
+  to do with *READTABLE* or how the function READ would parse the 
    
+  characters in the print name of the symbol.
    
+
    
+
    
+  Rationale:
    
+
    
+    This proposal is merely an explicit statement of the status quo,
    
+    namely that users cannot depend on any particular behavior if the
    
+    package environment at load time is inconsistent with what existed
    
+    at compile time. 
    
+
    
+    This proposal supports both the current-package and home-package
    
+    models as implementation techniques. 
    
+
    
+Current Practice:
    
+
    
+  PSL/PCLS implements the home-package model, as does A-Lisp.  Utah
    
+  Common Lisp implements the current-package model, but the chief
    
+  compiler hacker says he thinks that the home-package model
    
+  actually makes more sense, and agrees that any program that behaves
    
+  differently under the two proposals is broken. 
    
+
    
+  The TI Explorer currently implements the home-package model, after
    
+  trying it both ways.
    
+  
    
+  KCL also implements the home-package model.
    
+  
    
+  Lucid Lisp appears to implement the current-package model.
    
+
    
+  Symbolics Genera implements the current-package model.  Symbolics
    
+  Cloe probably does also.
    
+  
    
+  Coral also implements the current-package model.
    
+  
    
+  
    
+Cost to implementors:
    
+
    
+  Proposal NEW-REQUIRE-CONSISTENCY is intended to be compatible with either
    
+  of the two models, but it may not be entirely compatible with the 
    
+  details of current implementations.
    
+
    
+  In particular, some implementations that use the current-package
    
+  model appear to restrict IN-PACKAGE to being the first top-level
    
+  form in the file and dump all symbols referenced in the file after
    
+  the entire file has been processed (so that the value of *PACKAGE*
    
+  used to determine whether to qualify symbols in the output file is
    
+  the same for all symbols in the file).  Under this proposal, these
    
+  implementations would have to note when the value of *PACKAGE*
    
+  changes during processing of a top-level form.
    
+
    
+
    
+Cost to users:
    
+
    
+  Any user program that would break under proposal NEW-REQUIRE-CONSISTENCY
    
+  is probably already nonportable, since this proposal is intended to
    
+  leave the behavior unspecified where it would differ under the
    
+  two implementation models.
    
+
    
+  For a discussion of how the two models treat nonportable or erroneous
    
+  programs, see the "Analysis" section below.
    
+  
    
+  
    
+Benefits:
    
+
    
+  COMPILE-FILE's treatment of symbols is made explicit in the standard.
    
+  
    
+  
    
+Analysis:
    
+
    
+  The two implementation models differ in the following situations.
    
+  Proposal NEW-REQUIRE-CONSISTENCY, in effect, says that valid programs do
    
+  not cause any of these situations to occur, and the behavior in such
    
+  cases is unspecified (allowing both models to be used as valid
    
+  implementation techniques).
    
+  
    
+  (1) The situation where the file does not contain a IN-PACKAGE
    
+      and where the compile-time value of *PACKAGE* is a package with a
    
+      different name than the load-time value of *PACKAGE*.
    
+      
    
+      The current-package model would intern the names of symbols that 
    
+      were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
    
+      
    
+      The home-package model would intern the names of symbols that
    
+      were accessible in *PACKAGE* at compile time in the package with
    
+      the same name as their compile-time home package.
    
+      
    
+      In general, programs must be compiled in the "right" package, so
    
+      that the compiler can find and apply the correct macro expansions,
    
+      type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
    
+      As a result of macroexpansion or other transformations applied by
    
+      the compiler, the compiled file may contain symbol references that
    
+      were not present in the source file.  The current-package model may
    
+      cause problems because these references may be resolved to be
    
+      symbols other than the ones that were intended.  The home-package
    
+      model is more likely to find the correct symbols at load time.
    
+          
    
+  (2) The situation where there is a symbol accessible in the
    
+      compile-time value of *PACKAGE* but with another home package, and
    
+      where at load time there is not a symbol with the same name that
    
+      is accessible in both packages.  This situation might occur, for
    
+      example, if at compile time there is a symbol that is external in
    
+      its home package and that package is used by *PACKAGE*, but where
    
+      there is no such external symbol in that package at load time, or
    
+      the load-time *PACKAGE* does not use the other package.
    
+      
    
+      The current-package model would find or create a symbol accessible
    
+      in *PACKAGE*.
    
+      
    
+      The home-package model would find or create a symbol accessible in
    
+      a package with the same name as the symbol's compile-time home
    
+      package.
    
+      
    
+      Some people feel that the behavior of the current-package model is
    
+      more intuitive in this situation, and that it is more forgiving of
    
+      differences between the compile-time and load-time package
    
+      structures.  Others feel that the behavior of the home-package
    
+      model is more intuitive, and that if there have been significant
    
+      changes to the package structures, it is probably an indication
    
+      that the file needs to be recompiled anyway, since the compiler
    
+      might have picked up macro definitions and the like from the
    
+      wrong package. 
    
+  
    
+  (3) The situation where a symbol is external in its home package
    
+      and where there is no such external symbol in that package at load
    
+      time.
    
+      
    
+      The current-package model would quietly find or create the symbol
    
+      in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
    
+      time.  Otherwise, it will signal an error.
    
+      
    
+      The home-package model would always just quietly find or create the 
    
+      symbol as internal in its home package.
    
+      
    
+      Not complaining when a symbol that is supposed to be external
    
+      isn't can be seen as a violation of modularity.  However, it seems
    
+      like this argument should apply equally to symbols whose home
    
+      package is *PACKAGE* as symbols whose home package is somewhere
    
+      else.
    
+          
    
+
    
+Discussion:
    
+
    
+There has been some further and lengthy discussion on the question of
    
+whether this proposal overspecifies the behavior of COMPILE-FILE and
    
+LOAD.  At least one person would like the standard to say nothing on
    
+this issue beyond a statement of the goal that loading a compiled file
    
+should exhibit the same behavior as loading its source file.  We have
    
+also considered another approach to the problem that would place more
    
+stringent requirements on conforming programs and fewer requirements
    
+on implementations.  Neither of these alternatives seems to have much
    
+support, though.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064.htm new file mode 100644 index 00000000..694addec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064_w.htm new file mode 100644 index 00000000..d982787c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss064_w.htm @@ -0,0 +1,255 @@ + + + +CLHS: Issue COMPILED-FUNCTION-REQUIREMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILED-FUNCTION-REQUIREMENTS Writeup

    + +
    Forum:		Compiler
    
+Issue:		COMPILED-FUNCTION-REQUIREMENTS
    
+References:	CLtL p. 32, 76, 112, 143, 438-439
    
+		Issue FUNCTION-TYPE (passed)
    
+		Issue COMPILER-LET-CONFUSION (passed)
    
+		Issue EVAL-WHEN-NON-TOP-LEVEL (passed)
    
+		Issue LOAD-TIME-EVAL (passed)
    
+		Issue COMPILE-ENVIRONMENT-CONSISTENCY
    
+		Issue COMPILE-ARGUMENT-PROBLEMS (passed)
    
+Category:	CLARIFICATION, CHANGE
    
+Edit History:   V1, 3 Jan 1989 Sandra Loosemore
    
+		V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
    
+		V3, 10 Feb 1989, Sandra Loosemore (new proposal)
    
+		V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
    
+			with other pending proposals)
    
+		V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
    
+		V6, 30 May 1989, Sandra Loosemore (fix proposal TIGHTEN to
    
+			apply only to COMPILE-FILE)
    
+		V7, 22 Jun 1989, Sandra Loosemore (restore FLUSH again)
    
+		V8, 04 Jul 1989, Sandra Loosemore (amendments from meeting)
    
+Status:		Proposal TIGHTEN passed, as amended, June 89
    
+
    
+
    
+Problem Description:
    
+
    
+There is confusion about what functions might be or must be of type
    
+COMPILED-FUNCTION, and what attributes must be true of
    
+COMPILED-FUNCTIONs.  Is the distinction between COMPILED-FUNCTIONs and
    
+other functions only one of representation, or can user programs infer
    
+anything about COMPILED-FUNCTIONs?  Are implementations required to
    
+distinguish between compiled and non-compiled functions?
    
+
    
+CLtL defines a COMPILED-FUNCTION as "a compiled code object".  (Issue
    
+FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
    
+FUNCTION.)  Although it is not explicitly stated, CLtL implies that
    
+compiled code must conform to certain rules; in particular, it states
    
+that all macros are expanded at compile time, and specifies different
    
+behavior for the COMPILER-LET and the EVAL-WHEN special forms
    
+depending on whether they are interpreted or compiled.
    
+
    
+The description of COMPILE in CLtL says that "a compiled-function object
    
+[is] produced".  It is not clear to everyone whether this implies that
    
+COMPILED-FUNCTION-P must be true of such functions.  CLtL says nothing
    
+about whether functions defined in files compiled with COMPILE-FILE and
    
+subsequently loaded must be of type COMPILED-FUNCTION.
    
+
    
+There are two proposals, FLUSH and TIGHTEN.
    
+
    
+Proposal TIGHTEN presents a simple model of the compilation process.  A
    
+minimal compiler could be implemented to perform a code walk to apply
    
+the indicated transformations to the function source code.  Of course,
    
+most compilers will perform other transformations as well, such as
    
+translating the Lisp source code into a representation that is more
    
+compact or which can be executed more efficiently.
    
+
    
+Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
    
+
    
+  (1) Remove the type specifier COMPILED-FUNCTION and the predicate
    
+      COMPILED-FUNCTION-P from the language.
    
+  
    
+  (2) Remove the language from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY
    
+      that says "it is an error" to try to COMPILE a function that
    
+      was defined interpretively in a non-null lexical environment.
    
+      Instead, state that if COMPILE cannot compile the function,
    
+      it should simply behave as an identity operation.
    
+
    
+  Rationale:
    
+
    
+    Some people think the wording of proposal TIGHTEN is too vague and
    
+    does not provide an adequate definition of what COMPILED-FUNCTIONs
    
+    are.  Some people think that since proposal TIGHTEN does not require
    
+    COMPILE to produce a COMPILED-FUNCTION, its specification is too 
    
+    weak to be of much use to users.
    
+
    
+    Since we are unable to reach concensus on what a COMPILED-FUNCTION
    
+    really is, or how to construct one, it seems better to remove it
    
+    from the language entirely.
    
+  
    
+
    
+Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
    
+
    
+  (1) Clarify that if a function is of type COMPILED-FUNCTION, the
    
+      following are guaranteed about the function:
    
+  
    
+      - All macro calls appearing lexically within the function have 
    
+        already been expanded and will not be expanded again when the
    
+        function is called.  (See CLtL p. 143.)  The process of
    
+        compilation effectively turns MACROLET and SYMBOL-MACROLET
    
+        constructs into PROGNs with all instances of the local macros
    
+        in the body fully expanded.
    
+  
    
+      - If the function contains lexically nested LOAD-TIME-VALUE forms,
    
+        these have already been pre-evaluated and will not be evaluated
    
+        again when the function is called.
    
+  
    
+  (2) Implementations are free to classify all functions as 
    
+      COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
    
+      listed in item (1).  It is also permissible for functions that are
    
+      not COMPILED-FUNCTIONs to satisfy the above criteria.
    
+  
    
+  (3) Clarify when functions are defined in a file which is compiled
    
+      with COMPILE-FILE, and the compiled file is subsequently LOADed,
    
+      objects of type COMPILED-FUNCTION result.
    
+  
    
+  (4) Clarify that COMPILE must produce an object of type
    
+      COMPILED-FUNCTION.
    
+  
    
+  
    
+  Rationale:
    
+  
    
+  This proposal allows users to count on both COMPILE and COMPILE-FILE 
    
+  always producing objects that are COMPILED-FUNCTION-P.
    
+  
    
+  Some specific properties are assigned to compiled functions.  Users
    
+  would be able to rely on any function which is of type
    
+  COMPILED-FUNCTION having really been (at least partially) compiled.
    
+  
    
+  It also states what many people believe to be the minimum functionality 
    
+  required of a compiler.
    
+  
    
+   
    
+Current Practice:
    
+ 
    
+It appears that most implementations currently distinguish compiled
    
+versus non-compiled functions on the basis of representation.  It seems
    
+unlikely that any implementation would have problems satisfying the
    
+stated minimum requirements for compilation.
    
+  
    
+Lucid uses the same representation for both compiled and non-compiled
    
+functions, except there is a bit in the header used to distinguish them.
    
+
    
+A-Lisp uses the same representation for both compiled and interpreted
    
+functions and currently labels them both as COMPILED-FUNCTION, but the
    
+implementation of COMPILED-FUNCTION-P could be easily fixed to
    
+distinguish "real" compiled functions.
    
+
    
+On the TI Explorer, the COMPILE function can return an object of
    
+either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
    
+consists of two components -- an environment and a COMPILED-FUNCTION.
    
+There is confusion about whether microcoded functions should be
    
+considered compiled or not.
    
+
    
+In Utah Common Lisp, COMPILED-FUNCTION-P currently returns true of all
    
+function objects, but there is an internal tag field in the object
    
+which allows real compiled functions to be distinguished from
    
+interpreted functions.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Unknown, but probably not too great.  Many implementations will
    
+probably have to make some minor changes to representation of
    
+functions and/or to the definition of COMPILED-FUNCTION-P, but
    
+probably most of those changes are necessary to support the
    
+FUNCTION-TYPE proposal anyway.
    
+
    
+
    
+Cost to users:
    
+
    
+Probably minimal.  Since the COMPILED-FUNCTION type specifier is
    
+currently ill-defined, it is hard to imagine that existing programs
    
+can portably rely on any interpretation of what it means that is
    
+inconsistent with what is presented here.
    
+
    
+
    
+Benefits:
    
+
    
+The specification of what the compiler must do is made more explicit.
    
+
    
+
    
+Discussion:
    
+
    
+This writeup originally contained an additional proposal,
    
+TIGHTEN-COMPILE.  A straw vote at the March 1989 meeting indicated
    
+that an earlier version of proposal TIGHTEN had the most support.
    
+However, a number of people still have a strong preference for
    
+proposal FLUSH.  
    
+
    
+Recent mail on the cl-compiler list has indicated that Moon, Loosemore
    
+and MacLachlan favor flushing COMPILED-FUNCTION; White and Burke have
    
+no objection to doing so; and that Pitman would like to see the type
    
+retained with both COMPILE and COMPILE-FILE required to produce
    
+compiled functions.  Nobody has explicitly stated a preference for
    
+proposal TIGHTEN in this round of discussion.
    
+
    
+Loosemore would also prefer to see the type retained, but thinks that
    
+since we have been unable to reach a consensus on what the
    
+compiled-function type means or how to construct an object of this
    
+type, we are much better off not saying anything about it at all in
    
+the standard, than standardizing a definition that is too vague to
    
+be of any use to users, or that some people believe is wrong.
    
+
    
+The FIXNUM and BIGNUM types were also defined in CLtL solely on the
    
+basis of distinguished representations, and that this definition has
    
+proved inadequate for just about all portable usages of these type
    
+specifiers.  Defining COMPILED-FUNCTION solely on the basis of
    
+distinguished representation seems like a bad idea.
    
+
    
+David Gray notes:
    
+  We make good use of the type COMPILED-FUNCTION in our implementation,
    
+  but all of the accessor functions for objects of that type are
    
+  non-standard, which makes me wonder if it might be best to just remove
    
+  this type from the standard along with BIGNUM.
    
+
    
+One use of the COMPILED-FUNCTION type is in declarations.  A-Lisp and
    
+Lucid, for example, can compile FUNCALL more efficiently if it can be
    
+determined that the function is of type COMPILED-FUNCTION.  However,
    
+in order for such declarations to be really useful, there should be a
    
+way to construct an object which is guaranteed to be of type
    
+COMPILED-FUNCTION.
    
+
    
+Moon says:
    
+  I much prefer the option FLUSH...
    
+  This type has no portable meaning and never should have existed.
    
+
    
+Pierson says:
    
+  What I (and believe Kent) want is a guarantee that [COMPILE] won't
    
+  signal an error; if nothing else works COMPILE will simply apply
    
+  #'IDENTITY to the symbol's function.  Specifically, it should be
    
+  legal and safe to attempt to speed up my current program(s) by
    
+  doing:
    
+
    
+    (DO-SYMBOLS (SYM <my-package>)
    
+    	(WHEN (FBOUNDP SYM) (COMPILE SYM)))
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065.htm new file mode 100644 index 00000000..61adb7bb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue COMPILER-DIAGNOSTICS:USE-HANDLER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILER-DIAGNOSTICS:USE-HANDLER Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILER-DIAGNOSTICS:USE-HANDLER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065_w.htm new file mode 100644 index 00000000..2d44a94c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss065_w.htm @@ -0,0 +1,229 @@ + + + +CLHS: Issue COMPILER-DIAGNOSTICS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILER-DIAGNOSTICS Writeup

    + +
    Forum:          Compiler
    
+Issue:          COMPILER-DIAGNOSTICS
    
+References:     CLtL p. 438-439, 62, 69, 160, 161
    
+                Condition System, Revision #18
    
+                S:>KMP>cl-conditions.text.34
    
+                Issue GC-MESSAGES
    
+                Issue RETURN-VALUES-UNSPECIFIED
    
+                Issue COMPILER-VERBOSITY
    
+                Issue CONDITION-RESTARTS
    
+Category:       CLARIFICATION, ENHANCEMENT
    
+Edit History:   V1, 15 Oct 1988, Sandra Loosemore
    
+                V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
    
+                V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
    
+                V4, 01 Nov 1988, Sandra Loosemore (fix typos)
    
+                V5, 15 Dec 1988, Dan L. Pierson   (new condition types)
    
+                V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
    
+                V7, 16 Dec 1988, Dan L. Pierson   (minor cleanup)
    
+                V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
    
+                V9, 26 Jan 1989, Sandra Loosemore (simplify)
    
+                V10, 22 Mar 1989, Sandra Loosemore (error terminology)
    
+                V11, 11 Apr 1989, Kent Pitman (changes per X3J13)
    
+                V12, 21-Jun-89, Moon (changes to point 4 only: return a
    
+                        status value from COMPILE also, make the status
    
+                        value provide more detail)
    
+		V13, 22-Jun-89, Loosemore (fix one of the fixes)
    
+		V14, 04-Jul-89, Loosemore (amendments from June meeting)
    
+Status:         Passed V11 March 89
    
+		Passed V14 June 89
    
+     
    
+Problem Description:
    
+
    
+It is unclear whether various diagnostics issued by the compiler are 
    
+supposed to be true errors and warnings, or merely messages.
    
+
    
+In some implementations, COMPILE-FILE handles even serious error
    
+situations (such as syntax errors) by printing a message and then
    
+trying to recover and continue compiling the rest of the file, rather
    
+than by signalling an error.  While this user interface style is just
    
+as acceptable as invoking the debugger, it means that a normal return
    
+from COMPILE-FILE does not necessarily imply that the file was
    
+successfully compiled.
    
+
    
+Many compilers issue warnings about programming style issues (such as
    
+binding a variable that is never used but not declared IGNORE).
    
+Sometimes these messages obscure warnings about more serious problems,
    
+and there should be some way to differentiate between the two.  For
    
+example, it should be possible to suppress the style warnings.
    
+
    
+Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the 
    
+return value from COMPILE-FILE should be.
    
+
    
+
    
+Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
    
+
    
+(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
    
+    of WARNING.
    
+
    
+(2) Clarify that ERROR and WARNING conditions may be signalled within 
    
+    COMPILE or COMPILE-FILE, including arbitrary errors which may 
    
+    occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...) 
    
+    forms or macro expansion.
    
+
    
+    Considering only those conditions signalled -by- the compiler (as
    
+    opposed to -within- the compiler),
    
+
    
+    (a) Conditions of type ERROR may be signalled by the compiler in
    
+        situations where the compilation cannot proceed without
    
+        intervention.
    
+
    
+        Examples:
    
+            file open errors
    
+            syntax errors
    
+
    
+    (b) Conditions of type WARNING may be signalled by the compiler in 
    
+        situations where the standard explicitly states that a warning must,
    
+        should, or may be signalled; and where the compiler can determine 
    
+        that a situation with undefined consequences or that would cause
    
+        an error to be signalled would result at runtime.
    
+
    
+        Examples:
    
+            violation of type declarations
    
+            SETQ'ing or rebinding a constant defined with DEFCONSTANT
    
+            calls to built-in Lisp functions with wrong number of arguments
    
+                or malformed keyword argument lists
    
+            referencing a variable declared IGNORE
    
+            unrecognized declaration specifiers
    
+
    
+    (c) The compiler is permitted to signal diagnostics about matters of
    
+        programming style as conditions of type STYLE-WARNING.  Although 
    
+        STYLE-WARNINGs -may- be signalled in these situations, no 
    
+        implementation is -required- to do so.  However, if an 
    
+        implementation does choose to signal a condition, that condition 
    
+        will be of type STYLE-WARNING and will be signalled by a call to 
    
+        the function WARN.
    
+
    
+        Examples:
    
+            redefinition of function with different argument list
    
+            calls to function with wrong number of arguments
    
+            unreferenced local variables not declared IGNORE
    
+            declaration specifiers described in CLtL but ignored by 
    
+                the compiler
    
+
    
+(3) State that both COMPILE and COMPILE-FILE are permitted (but not
    
+    required) to establish a handler for ERROR.  For example, they
    
+    might issue a warning, and restart compilation from some
    
+    implementation-dependent point in order to let the compilation
    
+    proceed without manual intervention.
    
+
    
+(4) Specify that COMPILE and COMPILE-FILE return three values.  The first
    
+    value from COMPILE is not changed by this proposal.  The first value
    
+    from COMPILE-FILE is the truename of the output file, or NIL if the 
    
+    file could not be created.
    
+    
    
+    The second value is NIL if no compiler diagnostics were issued, and
    
+    true otherwise.
    
+
    
+    The third value is NIL if no compiler diagnostics other than style
    
+    warnings were issued.  A non-NIL value indicates that there were 
    
+    "serious" compiler diagnostics issued, or that other conditions of
    
+    type ERROR or WARNING (but not STYLE-WARNING) were signalled during
    
+    compilation.
    
+
    
+
    
+Rationale:
    
+
    
+Introducing the STYLE-WARNING condition allows handlers to distinguish
    
+between potentially serious problems and mere kibitzing on the part of
    
+the compiler.
    
+
    
+The second and third return values from COMPILE and COMPILE-FILE give
    
+some indication of whether there were serious problems encountered in
    
+compiling the file.
    
+
    
+
    
+Current Practice:
    
+
    
+No implementation behaves exactly as specified in this proposal.
    
+
    
+In VaxLisp, COMPILE-FILE handles most compile-time errors without
    
+invoking the debugger.  (It gives up on that top-level form and moves on
    
+to the next one.)  Instead of signalling errors or warnings, it simply
    
+prints them out as messages.
    
+
    
+In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
    
+serious problems.  COMPILE-FILE returns the pathname for the output file.
    
+
    
+Symbolics Genera usually tries to keep compiling when it encounters errors;
    
+so does Symbolics Cloe.
    
+
    
+On the TI Explorer, the compiler tries to catch most errors and turn
    
+them into warnings (except for errors on opening a file), but the user
    
+can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
    
+to enter the debugger on an error signalled during reading, macro
    
+expansion, or compile-time evaluation.  The true name of the output
    
+file is returned as the first value.  A second value indicates whether
    
+any errors or warnings were reported.
    
+
    
+IIM Common Lisp's compiler handles errors using a resignalling mechanism
    
+similar to what is described here.
    
+
    
+
    
+Cost to implementors:
    
+
    
+The cost to implementors is not trivial but not particularly high.  This
    
+proposal tries to allow implementations considerable freedom in what
    
+kinds of conditions the compiler must detect and how they are handled,
    
+while still allowing users some reasonably portable ways to deal with
    
+compile-time errors.
    
+
    
+
    
+Cost to users:
    
+
    
+This is a compatible extension.  This proposal may cause users to see
    
+some small differences in the user interface to the compiler, but
    
+implementations already vary quite widely in their approaches.  Some
    
+users will probably have to make some minor changes to their code.
    
+
    
+Adding the STYLE-WARNING type may cause conflicts with programs
    
+already using that name.
    
+
    
+
    
+Benefits:
    
+
    
+Users are given a way to detect and handle compilation errors, which
    
+would simplify the implementation of portable code-maintenance
    
+utilities.  The behavior of the compiler in error situations is made
    
+more uniform across implementations.
    
+
    
+
    
+Discussion:
    
+
    
+The issue of whether the compiler may print normal progress messages
    
+is discussed in detail in a separate issue, COMPILER-VERBOSITY.
    
+
    
+Explicit calls to ERROR don't really justify warnings to be signalled
    
+at compile-time, but we assume implementors have some common sense
    
+about when it's appropriate to do so.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066.htm new file mode 100644 index 00000000..ac83993b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue COMPILER-LET-CONFUSION:ELIMINATE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILER-LET-CONFUSION:ELIMINATE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILER-LET-CONFUSION:ELIMINATE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066_w.htm new file mode 100644 index 00000000..a881a856 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss066_w.htm @@ -0,0 +1,396 @@ + + + +CLHS: Issue COMPILER-LET-CONFUSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILER-LET-CONFUSION Writeup

    + +
    Issue:		COMPILER-LET-CONFUSION
    
+Forum:	        Compiler
    
+References:	CLtL p. 112
    
+		Issue DEFINE-OPTIMIZER
    
+Category:	CHANGE
    
+Edit History:   V1, 27 Sep 1988, Sandra Loosemore (initial version)
    
+                V2, 04 Oct 1988, Sandra Loosemore (add another example)
    
+		V3, 31 Oct 1988, Sandra Loosemore (only proposal ELIMINATE)
    
+	        V4, 08 Jan 1989, Kent M. Pitman (new alternative)
    
+		V5, 09 Jan 1989, Sandra Loosemore (discussion)
    
+		V6, 08 Mar 1989, Sandra Loosemore (general updating)
    
+		V7, 13 Mar 1989, Sandra Loosemore (fix bug from V6)
    
+		V8, 23 Mar 1989, Sandra Loosemore (fix another bug, add
    
+					to discussion)
    
+Status:		Proposal ELIMINATE passed March 89.
    
+
    
+Problem Description:
    
+
    
+ The description of the COMPILER-LET special form in CLtL is confusing
    
+ to many people.  There are no examples provided to make it clear how it
    
+ is supposed to be used. The only description which is offered is overly
    
+ concrete, which has led to confusion about the intent of COMPILER-LET,
    
+ and about its implementability.
    
+ 
    
+ The intent of COMPILER-LET was to permit information to be communicated
    
+ between macros by use of dynamic variables at macroexpansion time.
    
+ It was not necessary to the intended uses of COMPILER-LET that such
    
+ variables ever be bound at execution time.  
    
+ 
    
+ Unfortunately, probably because some implementations did not primitively
    
+ support COMPILER-LET at the time CLtL was written, an exception was 
    
+ permitted to make COMPILER-LET `more or less work' in interpreters: 
    
+ the COMPILER-LET variables were permitted to be bound at execution time.
    
+ The problem was further compounded by the fact that CLtL presented this
    
+ exception as part of COMPILER-LET's contract rather than as an 
    
+ implementation note, and by the fact that no examples of actually using
    
+ COMPILER-LET correctly are provided.
    
+
    
+ One particular case where problems have resulted is a situation like
    
+   (compiler-let ((*v* 1))
    
+     #'(lambda () (m)))
    
+ where M is a macro that refers to *V*.  In some implementations, M is
    
+ not macroexpanded until the dynamic extent of the *V* binding has
    
+ ended.
    
+ 
    
+ Subtle bugs can be introduced because of the different handling of the
    
+ variable bindings in the interpreter and the compiler.  In compiled
    
+ code, the bindings are only lexically visible during the expansion of
    
+ macros at compile time, while in interpreted code the bindings have
    
+ dynamic scope and may also be seen during ordinary evaluation if
    
+ evaluation and macroexpansion happen "in parallel".
    
+ 
    
+ Further compatibility problems can result from the value forms being
    
+ evaluated in a null lexical environment in the compiler and the ordinary
    
+ lexical environment in the interpreter.
    
+ 
    
+Background and Analysis:
    
+
    
+ It should be clear up front that COMPILER-LET is not computationally
    
+ essential. Most (if not all) uses of it can be rewritten using MACROLET
    
+ or SYMBOL-MACROLET.
    
+
    
+ A typical use of COMPILER-LET might be:
    
+
    
+  (defvar *local-type-declarations* '())
    
+     
    
+  (defmacro local-type-declare (declarations &body forms)
    
+    `(compiler-let ((*local-type-declarations* 
    
+		      (append ',declarations *local-type-declarations*)))
    
+       ,@forms))
    
+     
    
+  (defmacro typed-var (var)
    
+    (let ((type (assoc var *local-type-declarations*)))
    
+      (if type `(the ,(cadr type) ,var) var)))
    
+     
    
+  (defun f (x y)
    
+    (local-type-declare ((x fixnum) (y float))
    
+      (+ (typed-var x) (typed-var y))))
    
+    
    
+
    
+ The same thing could be accomplished using MACROLET:
    
+  
    
+  (defmacro local-type-declare (declarations &body forms)
    
+    (local-type-declare-aux declarations forms))
    
+    
    
+  (defmacro typed-var (var) var)
    
+
    
+  (eval-when (eval compile load)
    
+    (defun local-type-declare-aux (declarations forms)
    
+      `(macrolet ((typed-var (var)
    
+		    (let ((type  (assoc var ',declarations)))
    
+		      (if type `(the ,(cadr type) ,var) var)))
    
+		  (local-type-declare (new-declarations &body new-forms)
    
+		    (local-type-declare-aux
    
+		      (append new-declarations ',declarations)
    
+		      new-forms)))
    
+	 ,@forms)))
    
+
    
+
    
+ A further alternative would be to use SYMBOL-MACROLET (this particular
    
+ implementation assumes that issue DEFINING-MACROS-NON-TOP-LEVEL passes):
    
+
    
+  (let ((temp  (gensym)))
    
+    (defmacro local-type-declare (declarations &body forms &environment env)
    
+      `(symbol-macrolet ((,temp  ',(append declarations
    
+					  (symbol-macro-value temp env))))
    
+         ,@forms))
    
+    (defmacro typed-var (var &environment env)
    
+      (let ((type  (assoc var (symbol-macro-value temp env))))
    
+	(if type `(the ,(cadr type) ,var) var)))
    
+    )
    
+			  
    
+  (defun symbol-macro-value (symbol env &optional default)
    
+    (multiple-value-bind (expansion macro-p) (macroexpand symbol env)
    
+      (if macro-p (eval expansion) default)))
    
+
    
+ 
    
+ Opinion is divided as to which is more understandable.  Some
    
+ people find the COMPILER-LET idiom more understandable (assuming that
    
+ it can be made to work consistently in compiled and interpreted
    
+ code), while others find it just as natural to use MACROLET or 
    
+ SYMBOL-MACROLET.
    
+
    
+ The issues are these:
    
+
    
+  - Is it possible to implement COMPILER-LET in a usefully consistent
    
+    way in all implementations?
    
+
    
+  - Are the benefits of providing a useful and compatible implementation
    
+    of COMPILER-LET worth any associated cost?
    
+
    
+ Two proposals are presented below:
    
+
    
+  - Option REPAIR argues that COMPILER-LET provides interesting
    
+    functionality that can be implemented in a manner that is usefully
    
+    consistent across implementations, and that the associated cost
    
+    is low enough for it to be worthwhile to do so.
    
+
    
+  - Option ELIMINATE argues that COMPILER-LET complicates the language
    
+    and that providing this construct is not worth the associated 
    
+    implementation cost.
    
+
    
+
    
+Proposal (COMPILER-LET-CONFUSION:REPAIR):
    
+
    
+  Strike the existing definition of COMPILER-LET. Redefine it as follows:
    
+  
    
+  COMPILER-LET						  [Special form]
    
+  
    
+    COMPILER-LET is similar to LET, but it always makes special 
    
+    bindings and makes those bindings visible only during 
    
+    macroexpansion of forms in the body, not during the runtime
    
+    execution of those forms.  
    
+
    
+    If proposal DEFINE-OPTIMIZER:NEW-FACILITY is accepted, then
    
+    optimizer functions are also executed in a dynamic environment
    
+    in which COMPILER-LET bindings are visible.
    
+
    
+    The intent is that some macros might macroexpand into calls to
    
+    COMPILER-LET in which the body would the contain references to
    
+    macros which access the variables in the COMPILER-LET.
    
+  
    
+    The initial value forms of the bindings, if any, are always 
    
+    evaluated in a null lexical context, regardless of whether the
    
+    COMPILER-LET expression is being interpreted or compiled.
    
+  
    
+    The initial value forms of the bindings, if any, are evaluated in
    
+    a dynamic context where the bindings of any lexically enclosing
    
+    COMPILER-LET are visible, and where dynamic execution-time 
    
+    environment may or may not be visible.
    
+  
    
+    Implementation Note: Permitting the execution-time dynamic
    
+    environment to be visible when initializing COMPILER-LET variables
    
+    is a concession to some interpreters which may have to do this in
    
+    order to keep the cost down. Where feasible, implementors should
    
+    try not to make the runtime environment visible.
    
+
    
+  Rationale:
    
+
    
+    This gives a consistent description of COMPILER-LET which separates
    
+    issues of intent from those of implementation in a way that makes it
    
+    possible for portable code to make serious use of it, and which does
    
+    not force gratuitous incompatibilities between interpreters and
    
+    compilers.
    
+
    
+    This description of COMPILER-LET can be implemented without undue
    
+    cost by all implementations. See "Cost to Implementors" for details.
    
+
    
+  Cost to Implementors:
    
+
    
+    Modest, but nontrivial in some implementations.
    
+
    
+    In compiled code, and in interpreters doing a one-time semantic
    
+    prepass, it should be fairly easy for COMPILER-LET to cause the 
    
+    variables to get bound (using PROGV) during semantic analysis.
    
+
    
+    In interpreters which do not do a semantic-prepass, it is necessary
    
+    to fully macroexpand the body. Assuming the presence of a
    
+    SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
    
+    could look like:
    
+      (DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
    
+        (SETQ BINDINGS ;; Assure no non-atom bindings
    
+	      (MAPCAR #'(LAMBDA (BINDING) 
    
+		          (IF (ATOM BINDING) (LIST BINDING) BINDING))
    
+		      BINDINGS))
    
+        (PROGV (MAPCAR #'CAR BINDINGS)
    
+	       (MAPCAR #'(LAMBDA (BINDING) (EVAL (CADR BINDING))) BINDINGS)
    
+	  (SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
    
+    This reduces the problem of writing a program capable of doing a
    
+    full macroexpansion. Many systems already have such a facility.
    
+    Pitman wrote such a facility in Cloe Runtime in order support 
    
+    SYMBOL-MACROLET (before it was christened a special form); it was
    
+    about 750 lines of relatively straightforward, well-commented code.
    
+
    
+  Cost to Users:
    
+
    
+    Code currently depending on this feature is either non-existent or
    
+    already not portable (due to wide variation in implementation 
    
+    strategy for COMPILER-LET).
    
+
    
+    Most users will probably be happy for any interpretation which offers
    
+    them a future shot at portability.
    
+
    
+    Some users have indicated they dislike interpreters which do a semantic
    
+    prepass, because they like to be able to dynamically redefine macros
    
+    while debugging.
    
+
    
+
    
+Proposal (COMPILER-LET-CONFUSION:ELIMINATE):
    
+
    
+  Remove COMPILER-LET from the language.
    
+  
    
+  Rationale:
    
+
    
+    Some people think that having one less special form would simplify the
    
+    language.  The revised COMPILER-LET semantics, which require
    
+    COMPILER-LET to make special bindings which are only visible during
    
+    expansion of macros which appear lexically within its body, are
    
+    not shared by any other feature in the language, and require a
    
+    fairly complex implementation technique.  There are other
    
+    constructs which are strictly lexical that can be readily used
    
+    to solve the same kinds of problems that COMPILER-LET is intended to
    
+    be used for.
    
+
    
+  Cost to Implementors:
    
+  
    
+    Minimal.  Implementations could continue to support COMPILER-LET as
    
+    an extension.
    
+  
    
+  Cost to Users:
    
+  
    
+    Code currently depending on this feature is either non-existent or
    
+    already not portable (due to wide variation in implementation 
    
+    strategy for COMPILER-LET).
    
+
    
+    People who use COMPILER-LET would have to rewrite their programs to use
    
+    some other construct.  As discussed above, most uses of COMPILER-LET
    
+    for communication between macros can be handled using MACROLET or
    
+    SYMBOL-MACROLET, though some perspicuity may be lost in the process.
    
+
    
+
    
+Current Practice:
    
+  
    
+ Some implementations have implemented the description in CLtL. 
    
+ Users of those implementations (quite reasonably) can't figure how to 
    
+ use COMPILER-LET and so don't use it much.
    
+
    
+ Some implementations whose interpreters include a preprocessor to
    
+ expand all macros have already implemented something similar to proposal
    
+ COMPILER-LET-CONFUSION:REPAIR.  Users of such implementations
    
+ probably use COMPILER-LET somewhat more often since it has an
    
+ intelligible behavior, but their code is not portable since it relies
    
+ on behaviors which are either contrary to or not guaranteed by CLtL.
    
+
    
+Benefits:
    
+
    
+ Either way, a potential area of incompatibility between compiled and
    
+ interpreted code would be eliminated.
    
+
    
+ Either way, a potential area of portability trouble would be very
    
+ drastically reduced (in the case of the REPAIR option) or eliminated
    
+ (in the case of the ELIMINATE option).
    
+
    
+Discussion:
    
+
    
+ Pitman strongly favors COMPILER-LET-CONFUSION:REPAIR.  He argues 
    
+ against the idea of using MACROLET instead of COMPILER-LET, saying:
    
+
    
+  This is a little misleading because it's like saying you can
    
+  do without LET given that you have FLET. You can, but you lose some things
    
+  in the process:
    
+ 
    
+  Just as rewriting a LET using FLET might slow your computation, so too
    
+  a rewrite of COMPILER-LET using MACROLET might slow things down. However,
    
+  compilation speed is generally not weighted as heavily as execution speed
    
+  by many people, so the loss of speed here may not be as important.
    
+ 
    
+  Just as rewriting a LET using FLET might obscure the simplicity of your
    
+  intent, so too rewriting COMPILER-LET using MACROLET might obscure your
    
+  intent. You'd probably get used to recognizing idioms if you used it often
    
+  enough. Certainly this would be true if you didn't have LET. However,
    
+  COMPILER-LET is used less often, so not having it would mean that the
    
+  code you wrote instead would be much harder to read because people
    
+  wouldn't have the necessary familiarity with the idioms involved and so
    
+  wouldn't always understand them.
    
+ 
    
+ Sandra Loosemore responds:
    
+
    
+  The argument that using MACROLET is more inefficient than COMPILER-LET
    
+  is questionable.  Both of the suggested implementation techniques for
    
+  COMPILER-LET involve considerable overhead.
    
+
    
+  If COMPILER-LET were not part of the language, people wouldn't think in
    
+  terms of rewriting COMPILER-LETs as MACROLETs; instead, they'd think of
    
+  how to use MACROLET in the first place to solve their problems.  This
    
+  is what people who now use implementations with broken COMPILER-LETs
    
+  already do.  Since MACROLET is now used much more frequently than
    
+  COMPILER-LET, that argues that people are much more familiar with 
    
+  MACROLET idioms than COMPILER-LET idioms.
    
+
    
+  Also, note that the intent of the revised COMPILER-LET definition is
    
+  to make the binding only lexically visible within the body.  Using
    
+  special binding for this purpose is troublesome.  Both the MACROLET
    
+  and SYMBOL-MACROLET solutions are completely lexical and avoid all
    
+  the problems associated with special binding.
    
+
    
+Glenn Burke thinks it needs to be emphasized that the code-walker
    
+mentioned in the REPAIR proposal does not need to be portable.  He
    
+says:
    
+
    
+  The present wording makes it sound like a piece of cake to do with
    
+  portable code, when the reality is that a good fraction of CL cleanup
    
+  effort has involved the lack of capability of producing such a beast.
    
+  Without one or more of a number of proposals being accepted, a fully
    
+  correct portable code walker cannot be built, in my belief.
    
+
    
+  I object to the flippant attitude of just "presupposing" this
    
+  "trivial" function which "we know how to do".
    
+
    
+We have considered a number of other options on this issue, including
    
+a variety of proposals that would redefine COMPILER-LET to store
    
+information about the variable bindings in the lexical environment, and
    
+either having MACROEXPAND-1 make the special bindings or provide a
    
+function which could be used to access them directly.
    
+
    
+Kent Pitman says:
    
+  People have suggested that if it comes to making an incompatible change
    
+  on this one, it's probably better to just remove the feature and let
    
+  people continue to provide it compatibly where they think it's useful.
    
+  Even though I think the COMPILER-SYMBOL-VALUE thing is technically
    
+  doable, I find myself swayed by arguments that it's not the correct
    
+  avenue for us to pursue at this time.
    
+
    
+David Moon says:
    
+  I think COMPILER-LET-CONFUSION:REPAIR should be split into four proposals.
    
+  First, one that gives the general framework for repairing but doesn't
    
+  say anything about how the interpreter implements COMPILER-LET, other
    
+  than to say that an additional proposal is needed to cover that.  Then
    
+  three proposals for how the interpreter implements COMPILER-LET:
    
+   (1) The interpreter always does a "semantic pre-pass" like the compiler.
    
+   (2) The interpreter expands all macros inside COMPILER-LET before
    
+       evaluating any of the code inside COMPILER-LET.
    
+   (3) COMPILER-LET passes the variable bindings to MACROEXPAND-1
    
+       through the lexical environment, and the time when the interpreter
    
+       expands macros is not changed.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067.htm new file mode 100644 index 00000000..939e09e7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue COMPILER-VERBOSITY:LIKE-LOAD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILER-VERBOSITY:LIKE-LOAD Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILER-VERBOSITY:LIKE-LOAD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067_w.htm new file mode 100644 index 00000000..0c8db49d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss067_w.htm @@ -0,0 +1,136 @@ + + + +CLHS: Issue COMPILER-VERBOSITY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILER-VERBOSITY Writeup

    + +
    Forum:	    	Compiler
    
+Issue:		COMPILER-VERBOSITY
    
+References:	CLtL p. 438-329; 426
    
+		issue COMPILER-DIAGNOSTICS
    
+Category:	ENHANCEMENT
    
+Edit History:   V1, 25 Oct 1988, Sandra Loosemore
    
+    	    	V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
    
+    	    	V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
    
+    	    	V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
    
+		V5, 06 Jan 1989, Sandra Loosemore (update discussion)
    
+		V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
    
+Status:		Ready for release
    
+
    
+
    
+Problem Description:
    
+
    
+Implementations vary widely in the amount of information that is printed
    
+out by COMPILE-FILE.  In some situations, it would be useful to control
    
+how much information is printed.
    
+
    
+
    
+Proposal COMPILER-VERBOSITY:LIKE-LOAD:
    
+
    
+Introduce special variables, *COMPILE-VERBOSE* and *COMPILE-PRINT*,
    
+with implementation-dependent initial values.
    
+
    
+Add :VERBOSE and :PRINT keyword arguments to the function
    
+COMPILE-FILE, analogous to those for the function LOAD.
    
+
    
+The :VERBOSE argument (which defaults to the value of
    
+*COMPILE-VERBOSE*), if true, permits COMPILE-FILE to print a message
    
+in the form of a comment to *STANDARD-OUTPUT* indicating what file is
    
+being compiled and other useful information.
    
+
    
+The :PRINT argument (which defaults to the value of *COMPILE-PRINT*),
    
+if true, causes information about top-level forms in the file being
    
+compiled to be printed to *STANDARD-OUTPUT*.  Exactly what is printed
    
+will vary from implementation to implementation, but nevertheless some
    
+information will be printed.
    
+
    
+Introduce a special variable *LOAD-PRINT*, which has an initial value of
    
+NIL.  State that the default value of the :PRINT argument to LOAD is
    
+*LOAD-PRINT* (rather than NIL).
    
+
    
+
    
+Rationale:
    
+
    
+This proposal makes COMPILE-FILE behave like LOAD.  There is already
    
+some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
    
+which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
    
+
    
+Adding the *LOAD-PRINT* variable allows the printing of messages by
    
+LOAD to be controlled either on a global or a per-call basis.
    
+
    
+
    
+Current Practice:
    
+
    
+COMPILE-FILE prints out progress messages in nearly all
    
+implementations.
    
+
    
+Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
    
+either be a stream to send messages to, or NIL to suppress messages.
    
+The default value is T, which sends messages to "the standard terminal
    
+device".
    
+
    
+On the TI Explorer, COMPILE-FILE displays the name of the function
    
+being compiled when the option :VERBOSE T is given or special variable
    
+COMPILER:COMPILER-VERBOSE is true.  (In other words, they use :VERBOSE
    
+to mean what this proposal says to use :PRINT for.)
    
+
    
+Symbolics Cloe already has a *LOAD-PRINT* variable.
    
+
    
+
    
+Cost to implementors:
    
+
    
+This is an incompatible change for some implementations.  While the
    
+changes required should be conceptually simple, their implementation
    
+may involve a significant amount of grunt work.  At least two
    
+implementations already provide some similar mechanism for suppressing
    
+messages.
    
+
    
+
    
+Cost to users:
    
+
    
+Some (non-portable) user code may break in implementations where this
    
+is an incompatible change.
    
+
    
+No user code should be broken by the addition of the *LOAD-PRINT*
    
+variable, since the default behavior for the :PRINT keyword to LOAD 
    
+is unchanged.
    
+
    
+
    
+Benefits:
    
+
    
+Users are given a portable way to control how much information is printed
    
+by COMPILE-FILE.
    
+
    
+
    
+Discussion:
    
+
    
+This issue addresses an extension to the language.  If this proposal
    
+is not accepted, the standard will simply continue not to say anything
    
+about whether COMPILE-FILE can print progress messages, or what stream
    
+such messages are directed to.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068.htm new file mode 100644 index 00000000..7db1c26a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue COMPILER-WARNING-STREAM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPILER-WARNING-STREAM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPILER-WARNING-STREAM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068_w.htm new file mode 100644 index 00000000..6406cf08 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss068_w.htm @@ -0,0 +1,98 @@ + + + +CLHS: Issue COMPILER-WARNING-STREAM Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPILER-WARNING-STREAM Writeup

    + +
    Status: passed, June 87
    
+Issue:        COMPILER-WARNING-STREAM
    
+References:   COMPILE (p438), COMPILE-FILE (p439)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: Version 1 by Pitman 02/27/87
    
+              Version 2 at committee meeting 15-Mar-87
    
+              Version 3 Masinter 15-Mar-87
    
+              Version 4 by Fahlman, incorporate Dribble
    
+              Version 5 by Masinter, 29-May-87, revert to Version 3
    
+              Version 6 by Masinter,  5-Jun-87, minor formatting
    
+              
    
+
    
+Problem Description:
    
+
    
+ The description of the COMPILE and COMPILE-FILE functions does not
    
+ explicitly permit them to print warnings. If this is to be allowed, it
    
+ should be an explicitly expressed part of the contract.
    
+
    
+Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
    
+
    
+ COMPILE and COMPILE-FILE are permitted to output warnings; warnings
    
+ should go to the stream that is the value of *ERROR-OUTPUT*.
    
+
    
+Rationale:
    
+
    
+ Compiler warning output is a widely accepted extension to the
    
+ compilation. Warnings that come via the WARN function will go to the
    
+ stream that is the value of *ERROR-OUTPUT*.
    
+
    
+Current Practice:
    
+
    
+ Some implementations send compiler warning output to *ERROR-OUTPUT*.
    
+ Other implementations send it to *STANDARD-OUTPUT*.
    
+
    
+Adoption Cost:
    
+
    
+ In most cases, the change to the compiler to redirect output is expected to be very slight.
    
+
    
+Benefits:
    
+
    
+ Currently, it is difficult to redirect the output of COMPILE and
    
+ COMPILE-FILE because it isn't clear where it's directed.
    
+
    
+Conversion Cost:
    
+
    
+ Most user programs that care are probably already tolerant of both
    
+ situations or naively expect that output will go to *ERROR-OUTPUT*. As
    
+ such, most users will probably perceive this as a clarification.
    
+
    
+Aesthetics:
    
+
    
+ Most users will probably perceive this change as a simplification
    
+ because it will allow the kind of warning that comes from WARN and the
    
+ kind of warning that comes from compilation to be conceptually grouped.
    
+
    
+Discussion:
    
+
    
+ This was a problem in adapting MACSYMA to Common Lisp because Macsyma
    
+ provides alternate user interfaces to the compiler which it needs to be
    
+ able to control.
    
+
    
+ The committee considered extending the proposal to describe the
    
+ interaction with DRIBBLE on the warning output, but found that DRIBBLE
    
+ was so underspecified as to make the task impossible. DRIBBLE should be
    
+ considered in a separate proposal.
    
+
    
+ The cleanup committee supports this change as stated.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069.htm new file mode 100644 index 00000000..581dffb9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COMPLEX-ATAN-BRANCH-CUT:TWEAK Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPLEX-ATAN-BRANCH-CUT:TWEAK Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COMPLEX-ATAN-BRANCH-CUT:TWEAK:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069_w.htm new file mode 100644 index 00000000..45513190 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss069_w.htm @@ -0,0 +1,119 @@ + + + +CLHS: Issue COMPLEX-ATAN-BRANCH-CUT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPLEX-ATAN-BRANCH-CUT Writeup

    + +
    Forum:         Cleanup
    
+Issue:         COMPLEX-ATAN-BRANCH-CUT
    
+References:    CLtL p.208, 212
    
+Related issues: IEEE-ATAN-BRANCH-CUT
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1, 13-Dec-88, Steele
    
+
    
+Problem description:
    
+
    
+The formula that defines ATAN results in a branch cut that is at
    
+variance with the recommendations of Prof. W. Kahan and with the
    
+implementations of that function in many computing systems and
    
+calculators.
    
+
    
+Proposal (COMPLEX-ATAN-BRANCH-CUT:TWEAK):
    
+  
    
+Replace the formula
    
+
    
+	arctan z = - i log ((1+iz) sqrt (1/(1+z^2)))
    
+
    
+with the formula
    
+
    
+	arctan z = (log (1+iz) - log (1-iz)) / (2i)
    
+
    
+This leaves the branch cuts pretty much in place; the only change is
    
+that the upper branch cut (on the positive imaginary axis above i)
    
+is continuous with quadrant I, where the old formula has it continuous
    
+with quadrant II.
    
+
    
+Examples:
    
+
    
+(atan #c(0 2)) => #c(-1.57... 0.549...)	;Current
    
+(atan #c(0 2)) => #c(1.57... -0.549...)	;Proposed
    
+
    
+Note: 1.57... = pi/2, and 0.549... = (log 3)/2.
    
+
    
+Rationale:
    
+
    
+Compatibility with what seems to be becoming standard practice.
    
+
    
+  
    
+Current practice:
    
+
    
+(atan #c(0 2)) => #c(-1.57... 0.549...)	;Symbolics CL
    
+(atan #c(0 2)) => #c(-1.57... 0.549...)	;Allegro CL 1.1 (Macintosh)
    
+(atan #c(0 2)) => #c(-1.57... 0.549...)	;Sun-4 CL 2.1.3 of 10-Nov-88
    
+(atan #c(0 2)) => #c(1.57... -0.549...)	;Sun CL 2.0.3 of 30-Jun-87
    
+(atan #c(0 2)) => #c(1.57... 0.549...)	;KCL of 3-Jun-87
    
+
    
+Note that in KCL the upper branch cut is thus continuous with
    
+quadrant I, but its lower branch cut is continuous with quadrant III!
    
+
    
+Cost to Implementors:
    
+
    
+ATAN must be rewritten.  It is not a very difficult fix.
    
+
    
+Cost to Users:
    
+
    
+It is barely conceivable that some user code could depend on this.
    
+Note that the proposed change invalidates the identities
    
+	arctan i z = i arctanh z
    
+and	arctanh i z = i arctan z
    
+on the upper branch cut.
    
+
    
+The compatibility note on p. 210 of CLtL gave users fair warning that
    
+a change of this kind might be adopted.
    
+
    
+Cost of non-adoption:
    
+
    
+Incompatibility with HP calculators.
    
+
    
+Benefits:
    
+
    
+Numerical analystsmay find the new definition easier to use.
    
+
    
+Esthetics:
    
+
    
+A toss-up, except to those who care.
    
+
    
+Discussion:
    
+
    
+Steele has sent a letter to W. Kahan at Berkeley to get any last
    
+comments he may have on the matter.
    
+
    
+Paul Penfield of MIT, after whose article the Common Lisp branch
    
+cuts were originally patterned, endorses this change.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070.htm new file mode 100644 index 00000000..683b9259 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070_w.htm new file mode 100644 index 00000000..14900c61 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss070_w.htm @@ -0,0 +1,194 @@ + + + +CLHS: Issue COMPLEX-ATANH-BOGUS-FORMULA Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPLEX-ATANH-BOGUS-FORMULA Writeup

    + +
    Date: Wed, 20 Sep 89 11:24:48 EDT
    
+From: gls@Think.COM (Guy Steele)
    
+Message-Id: <8909201524.AA21857@verdi.think.com>
    
+To: x3j13@sail.stanford.edu
    
+Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
    
+Subject: Issue COMPLEX-ATANH-BOGUS-FORMULA
    
+
    
+
    
+I hate to bring *anything* up at this late date, but while working over the
    
+numbers chapter second edition I have been going over this branch cut stuff
    
+one more time, with even greater care, and have discovered that the formula
    
+for ATANH on page 209 and again on page 213 is completely bogus.  What that
    
+computes is not anything like a hyperbolic arc tangent.  It would seem that
    
+I must have mistranscribed the APL formula in Penfield's article.
    
+
    
+CLtL has:   arctanh z = log ((1+z) sqrt(1 - (1 / z^2)))
    
+
    
+Should be:  arctanh z = log ((1+z) sqrt(1 / (1 - z^2)))
    
+
    
+Note that they differ in the transposition of two operators.  (Boy, am I
    
+embarrassed.)
    
+
    
+Clearly this must be corrected.  In the meantime I have found a more
    
+definitive treatment of complex branch cuts by W. Kahan, and I propose to
    
+follow his recommendations.  This involves correcting the formula for
    
+ATANH, and adopting new formulas for ACOS and ACOSH that are equivalent to
    
+the ones we have now but more perspicuous.
    
+
    
+I would appreciate knowing very soon on an informal basis whether anyone
    
+objects to this change, so that I can include some discussion of it in the
    
+second edition.  (Of course I'm not asking for a vote until we have an
    
+official meeting.)
    
+
    
+--Guy
    
+----------------------------------------------------------------
    
+Status:	       New proposal
    
+Forum:         Cleanup
    
+Issue:         COMPLEX-ATANH-BOGUS-FORMULA
    
+References:    CLtL pp. 209, 212, 213
    
+	       Penfield, P. "Principal Values and Branch Cuts in
    
+		Complex APL", Proc. APL 81 Conference Proceedings,
    
+		Association for Computing Machinery, 1981
    
+	       Kahan, W. "Branch Cuts for Complex Elementary
    
+		Functions, or Much Ado About Nothing's Sign Bit"
    
+		in Iserles and Powell (eds.) "The State of the Art
    
+		in Numerical Analysis", pp. 165-211, Clarendon
    
+		Press, 1987
    
+Related issues: COMPLEX-ATAN-BRANCH-CUT, IEEE-ATAN-BRANCH-CUT
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1, 20-SEP-89, Steele
    
+
    
+
    
+Problem description:
    
+
    
+The formula that defines ATANH in CLtL is incorrect, apparently
    
+because of a mistranscription of a formula from Penfield's article.
    
+
    
+CLtL has:   arctanh z = log ((1+z) sqrt(1 - (1 / z^2)))
    
+
    
+Should be:  arctanh z = log ((1+z) sqrt(1 / (1 - z^2)))
    
+
    
+However, given the change to ATAN in issue COMPLEX-ATAN-BRANCH-CUT,
    
+it seems simpler to follow Kahan's recommendation and define
    
+
    
+	arctanh z = (log(1+z) - log(1-z))/2
    
+
    
+thereby preserving the identity  i arctan z = arctanh iz .
    
+
    
+Kahan also notes that Penfield's formula for arccosh (CLtL p. 213)
    
+
    
+	arccosh z = log(z + (z + 1) sqrt((z-1)/(z+1)))
    
+
    
+has a gratuitous removable singularity at z=-1 and recommends
    
+
    
+	arccosh z = 2 log(sqrt((z+1)/2) + sqrt((z-1)/2))
    
+
    
+which has the same values and is also well-defined at z=-1.
    
+
    
+Finally, Kahan recommends a different defining formula for acos
    
+that is more similar to that of acosh (but less similar to that
    
+of asin).
    
+
    
+
    
+Proposal (COMPLEX-ATANH-BRANCH-CUT:TWEAK-MORE):
    
+  
    
+(1) Replace the erroneous formula
    
+
    
+	arctanh z = log ((1+z) sqrt(1 - (1 / z^2)))
    
+with
    
+	arctanh z = (log(1+z) - log(1-z))/2
    
+
    
+(2) Note that  i arctan z = arctanh iz .
    
+
    
+(3) Replace the gratuitously singular formula
    
+
    
+	arccosh z = log(z + (z + 1) sqrt((z-1)/(z+1)))
    
+with
    
+	arccosh z = 2 log(sqrt((z+1)/2) + sqrt((z-1)/2))
    
+
    
+(4) Adopt the formula (already in CLtL)
    
+
    
+	arccos z = (pi / 2) - arcsin z
    
+
    
+as the official definition of arccos, and also note that the
    
+formulas
    
+
    
+	arccos z = -i log(z + i sqrt(1 - z^2))
    
+
    
+(already in CLtL) and
    
+
    
+	arccos z = 2 log(sqrt((1+z)/2) + i sqrt((1-z)/2)) / i
    
+
    
+(recommended by Kahan) are equivalent.
    
+
    
+
    
+
    
+Rationale:
    
+
    
+Compatibility with what seems to be becoming standard practice.
    
+
    
+  
    
+Current practice:
    
+
    
+Implementations I have checked have a correct implementation
    
+of ATANH rather than slavishly following the bogus CLtL formula.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+ATANH must be rewritten.  It is not a very difficult fix.
    
+
    
+Possibly ACOSH must be rewritten.  It is not a very difficult fix.
    
+
    
+
    
+Cost to Users:
    
+
    
+The compatibility note on p. 210 of CLtL gave users fair warning that
    
+a change of this kind might be adopted.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+Possible incorrect implementations of ATANH.
    
+
    
+Incompatibility with HP calculators.
    
+
    
+
    
+Benefits:
    
+
    
+Numerical analysts may find the new definition easier to use.
    
+
    
+
    
+Esthetics:
    
+
    
+A toss-up, except to those who care.
    
+
    
+
    
+Discussion:
    
+
    
+Kahan's article not only discussed formulas but also gives specific
    
+implementation techniques for use with IEEE 754 arithmetic.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071.htm new file mode 100644 index 00000000..8ae865da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue COMPLEX-RATIONAL-RESULT:EXTEND Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPLEX-RATIONAL-RESULT:EXTEND Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue COMPLEX-RATIONAL-RESULT:EXTEND:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071_w.htm new file mode 100644 index 00000000..66aecc26 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss071_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue COMPLEX-RATIONAL-RESULT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPLEX-RATIONAL-RESULT Writeup

    + +
    Issue:         COMPLEX-RATIONAL-RESULT
    
+
    
+References:    CLtL p.203
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  Version 1, 20-Mar-89, by Moon
    
+               Version 2, 08-Apr-89, by Steele
    
+               Version 3, 28-Apr-89, by Steele
    
+
    
+Problem description:
    
+  
    
+  Referring to irrational and transcendental functions, CLtL says:
    
+    
    
+    When the arguments to a function in this section are all rational and
    
+    the true mathematical result is also (mathematically) rational, then
    
+    unless otherwise noted an implementation is free to return either an
    
+    accurate result of type rational or a single-precision floating-point
    
+    approximation.  If the arguments are all rational but the result cannot
    
+    be expressed as a rational number, then a single-precision
    
+    floating-point approximation is always returned.
    
+
    
+  Referring to EXPT, CLtL says:
    
+
    
+    If the base-number is of type RATIONAL and the power-number is an
    
+    INTEGER, the calculation will be exact and the result will be of
    
+    type RATIONAL; otherwise a floating-point approximation may result.
    
+
    
+  What about arguments of type (complex rational)?
    
+
    
+Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
    
+
    
+  Extend the paragraph quoted above as follows to cover the components
    
+  of complex numbers.  If the arguments to a function are all of type
    
+  (OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
    
+  (mathematically) a complex number with rational real and imaginary
    
+  parts, then unless otherwise noted an implementation is free to return
    
+  either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
    
+  a single-precision floating-point approximation of type SINGLE-FLOAT
    
+  (permissible only if the imaginary part of the true mathematical
    
+  result is zero) or (COMPLEX SINGLE-FLOAT). If the arguments are
    
+  all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
    
+  expressed as a rational or complex rational number, then the returned
    
+  value will be of type SINGLE-FLOAT (permissible only if the imaginary
    
+  part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).
    
+
    
+  For EXPT of a (COMPLEX RATIONAL) to an integer power, the
    
+  calculation must be exact and the result will be of type
    
+  (OR RATIONAL (COMPLEX RATIONAL)).
    
+
    
+Examples:
    
+
    
+[a]  (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
    
+			           or approximately 3.0 (unlikely)
    
+[b]  (abs #c(3/5 4/5)) => 1 or approximately 1.0
    
+[c]  (expt #c(2 2) 3) => #c(-16 16)
    
+[d]  (expt #c(2 2) 4) => -64 
    
+
    
+Rationale:
    
+  
    
+  This seems most consistent with the treatment of real numbers.
    
+
    
+Current practice:
    
+  
    
+			[a]			[b]	[c]		[d]
    
+Symbolics Genera 7.4	#c(3.00... 1.40...e-7)	1	#c(-16 16)	-64
    
+Sun Common Lisp 3.0.1	#c(3.0 2.61...e-16)	1.0	#c(-16 16)	-64
    
+KCL of 9/16/86 on VAX	#c(3.0s0 -1.40...s-7)	1.0s0	#c(-16 16)	-64
    
+Allegro CL (Mac II)	#c(3.0 2.05...e-16)	1.0	#c(-16 16)	-64
    
+
    
+Cost to Implementors:
    
+
    
+  Only EXPT would have to change, since the type of the other results
    
+  is at the discretion of the implementation.
    
+
    
+Cost to Users:
    
+
    
+  Probably none, but it is hard to predict.
    
+
    
+Cost of non-adoption:
    
+  
    
+  Slightly less self-consistent language.
    
+
    
+Performance impact:
    
+
    
+  None of any significance.
    
+
    
+Benefits/Esthetics:
    
+
    
+  More self-consistent language.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072.htm new file mode 100644 index 00000000..e843791b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COMPUTE-APPLICABLE-METHODS:GENERIC Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COMPUTE-APPLICABLE-METHODS:GENERIC Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COMPUTE-APPLICABLE-METHODS:GENERIC:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072_w.htm new file mode 100644 index 00000000..4d129e78 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss072_w.htm @@ -0,0 +1,98 @@ + + + +CLHS: Issue COMPUTE-APPLICABLE-METHODS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COMPUTE-APPLICABLE-METHODS Writeup

    + +
    Issue:         COMPUTE-APPLICABLE-METHODS
    
+
    
+References:    88-002R p.2-19
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  2-May-90, Version 1 by Moon
    
+
    
+Problem description:
    
+
    
+  COMPUTE-APPLICABLE-METHODS is documented as a regular function but it
    
+  should be a generic function, because the metaobject protocol wants to
    
+  allow different generic function classes to do it differently.
    
+
    
+  This is Symbolics issue #30 and Loosemore issue #22 of 27 Feb 90.
    
+
    
+Proposal (COMPUTE-APPLICABLE-METHODS:GENERIC):
    
+
    
+  Change COMPUTE-APPLICABLE-METHODS from "Function" to "Standard Generic
    
+  Function."
    
+
    
+Test Case:
    
+
    
+  (typep #'compute-applicable-methods 'generic-function) => t
    
+
    
+Rationale:
    
+
    
+  Needed for metaobject protocol.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0 and Lucid 4.0.0 Beta-1 implement the proposal,
    
+  however the test case returns nil in Lucid due to an unrelated bug.
    
+  Other CLOS implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+  Easy.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  This will have to be changed later when the metaobject protocol is put in
    
+  either as a standard or as an implementation-supplied extension.
    
+
    
+Performance impact:
    
+
    
+  None of consequence.
    
+
    
+Benefits:
    
+
    
+  Corrects a technical error in 88-002R.
    
+
    
+Esthetics:
    
+
    
+  Neutral.
    
+
    
+Discussion:
    
+
    
+  Gregor says this is correct.
    
+
    
+  Originally Moon thought there were also problems with SLOT-BOUNDP,
    
+  SLOT-EXISTS-P, and SLOT-MAKUNBOUND, but it turns out that those problems
    
+  were corrected before 88-002R was published.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073.htm new file mode 100644 index 00000000..66377c9c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue CONCATENATE-SEQUENCE:SIGNAL-ERROR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONCATENATE-SEQUENCE:SIGNAL-ERROR Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CONCATENATE-SEQUENCE:SIGNAL-ERROR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073_w.htm new file mode 100644 index 00000000..4cb870ce --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss073_w.htm @@ -0,0 +1,178 @@ + + + +CLHS: Issue CONCATENATE-SEQUENCE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONCATENATE-SEQUENCE Writeup

    + +
    Issue:        CONCATENATE-SEQUENCE
    
+Forum:	      Editorial
    
+References:   CONCATENATE (p249), COERCE (p51),
    
+	      MAKE-SEQUENCE (p249), MAP (p249), MERGE (p260),
    
+	      Issue SUBTYPEP-TOO-VAGUE
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 01-Mar-91, Version 1 by Pitman 
    
+	        (only about (CONCATENATE 'SEQUENCE ...))
    
+	      15-Mar-91, Version 2 by Pitman 
    
+	        (generalize per JonL, Moon, Barmar, MacLachlan)
    
+	      17-Mar-91, Version 3 by Pitman 
    
+	        (clarify for MacLachlan; also, include MAKE-SEQUENCE)
    
+	      31-May-91, Version 4 by Pitman (amendments per X3J13)
    
+Status:	      X3J13 passed v3 with amendments on 10-1 vote, Mar 91.
    
+	      v4 reflects those amendments.
    
+
    
+Problem Description:
    
+
    
+  CLtL (p249) says that the RESULT-TYPE argument to CONCATENATE
    
+   ``must be a subtype of SEQUENCE, as for the function COERCE''
    
+
    
+  CLtL (p51) says:
    
+   ``Any sequence type may be converted to any other sequence
    
+     type, provided the new sequence can contain all actual
    
+     elements of the old sequence ... If the sequence is already
    
+     the specified type, it may be returned without copying it; 
    
+     in this, (COERCE sequence type) differs from 
    
+     (CONCATENATE type sequence), for the latter is required to
    
+     copy the argument seqeunce.  In particular, if one specifies
    
+     SEQUENCE, then the argument may simply be returned if it 
    
+     already is a sequence.
    
+
    
+  The passage about CONCATENATE suggests that sequence subtypes 
    
+  valid to COERCE are valid to CONCATENATE.  But the type SEQUENCE
    
+  is a subtype of SEQUENCE that is clearly permissible to COERCE.
    
+
    
+  COERCE, MAKE-SEQUENCE, MAP, and MERGE are also impacted similarly.
    
+
    
+Terminology:
    
+
    
+  Draft 8.81 of the specification defines the following term:
    
+
    
+    recognizable subtype n. (of a <type>)
    
+     a <subtype> of the <type> which can be reliably detected 
    
+     to be such by the <implementation>.
    
+
    
+  The intent is that SUBTYPEP will be described as a function which 
    
+  returns "T, T" when the first type argument is a "recognizable subtype"
    
+  of the second.
    
+
    
+Proposal (CONCATENATE-SEQUENCE:X3J13-MAR-91):
    
+
    
+  1. Specify that CONCATENATE, MAKE-SEQUENCE, MAP, and MERGE are
    
+     defined only when the target type argument is either a 
    
+     recognizable subtype of LIST or a recognizable subtype of
    
+     VECTOR.  [MAP is also permitted to special case NIL as a
    
+     target type in a manner consisting with existing practice.]
    
+     Otherwise, an error is signaled.
    
+
    
+  2. Specify that if COERCE receives a target type argument which is 
    
+     a recognizable subtype of SEQUENCE, but which is neither a 
    
+     recognizable subtype of LIST nor a recognizable subtype of
    
+     VECTOR, then the argument to be coerced must already be 
    
+     of that type (in which case, COERCE behaves like IDENTITY for that
    
+     argument).  Otherwise, an error is signaled.
    
+
    
+  3. a. Specify that if COERCE, CONCATENATE, MAKE-SEQUENCE, MAP,
    
+	or MERGE receives a target type argument which is any subtype
    
+	of LIST, then the result is of type LIST.
    
+
    
+     b. Specify that if COERCE receives a target type argument that
    
+        is a subtype of array, and the object is already of that type,
    
+	COERCE returns that object as its result.
    
+
    
+     c. For COERCE in situations not covered by 3b, 
    
+	CONCATENATE, MAKE-SEQUENCE, MAP and MERGE 
    
+	when the target type argument is a subtype of ARRAY:
    
+
    
+	 * If the implementation can determine the element type
    
+ 	   specified for the target type, the element type of the
    
+	   resulting array is the upgraded array element type of 
    
+	   the specified element type.
    
+
    
+	 * Else if the implementation can determine that the element
    
+	   type is unspecified, (or ``*'') the element type of the
    
+	   resulting array defaults as for MAKE-ARRAY (to T).
    
+
    
+	 * Else an error is signaled.
    
+
    
+Rationale:
    
+
    
+  This gives users a sense of what they can expect at minimum,
    
+  and also gives implementors a sense for how they can go about 
    
+  making extensions without violating user expectations.
    
+
    
+  Note that although that specific terminology is not used, the
    
+  specific constraints on recognizable subtypes are effectively 
    
+  spelled out in issue SUBTYPEP-TOO-VAGUE.
    
+
    
+Test Case:
    
+
    
+ #1: (CONCATENATE 'SEQUENCE '(A B C) "DEF")
    
+
    
+ #2: (COERCE '#1=#(1 0 1) '(OR NULL (EQL (1 0 1))))
    
+
    
+ #3: (FLET ((SAME-TYPE-P (X Y)
    
+	      (VALUES (AND (SUBTYPEP X Y) (SUBTYPEP Y X)))))
    
+       (SAME-TYPE-P 
    
+	 (ARRAY-ELEMENT-TYPE (MAKE-SEQUENCE '(ARRAY (UNSIGNED-BYTE 5)) 3))
    
+	 (UPGRADED-ARRAY-ELEMENT-TYPE '(UNSIGNED-BYTE 5))))
    
+     => T  ;or signals an error, if (UNSIGNED-BYTE 5) is not upgradable.
    
+
    
+Current Practice:
    
+
    
+ Symbolics Genera seems to approximately implement this proposal, 
    
+ although it isn't quite right on the LIST side (e.g., it fails on test
    
+ case #2).
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  None.  This was already not portable.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The language is left ambiguous.
    
+
    
+Benefits:
    
+
    
+  A tighter specification--better portability.
    
+
    
+Aesthetics:
    
+
    
+  Negligible.
    
+
    
+Discussion:
    
+
    
+ Pitman supports this.
    
+
    
+ An earlier version of this proposal worried specifically about the case
    
+ of function CONCATENATE and specifically about the argument named SEQUENCE
    
+ but it was shown that the problem was bigger along both axes, so v2 starts
    
+ over trying to do things a different way.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074.htm new file mode 100644 index 00000000..f80ed3af --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONDITION-ACCESSORS-SETFABLE:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONDITION-ACCESSORS-SETFABLE:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONDITION-ACCESSORS-SETFABLE:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074_w.htm new file mode 100644 index 00000000..6e35683b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss074_w.htm @@ -0,0 +1,71 @@ + + + +CLHS: Issue CONDITION-ACCESSORS-SETFABLE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONDITION-ACCESSORS-SETFABLE Writeup

    + +
    Issue:		CONDITION-ACCESSORS-SETFABLE
    
+Forum:		Cleanup
    
+References:	Condition System, version 18
    
+Category:	CLARIFICATION
    
+Edit History:	Version 1, 1/3/90 by Kim A. Barrett
    
+
    
+Problem Description:
    
+  It is presently unspecified whether the accessor functions defined for the
    
+  various standard condition classes may be used as places for SETF.
    
+
    
+Proposal (CONDITION-ACCESSORS-SETFABLE:NO):
    
+  The effect of using accessor functions defined for the various standard
    
+  (i.e., pre-defined) condition classes as places for SETF is undefined.
    
+
    
+Rational:
    
+  Conditions are used to record state at a particular point in time.  Allowing
    
+  them to be modified at some later time makes little sense.  The Condition
    
+  System does say that it is an error to attempt to assign a condition's slots
    
+  by using SETF.
    
+
    
+Current Practice:
    
+  IIM does not make these functions be setfable.
    
+
    
+Cost to Implementors:
    
+  Implementations might want to change all the DEFINE-CONDITIONs to use
    
+  :READER rather than :ACCESSOR when defining the accessor methods on the
    
+  slots is fairly trivial--however technically this issue itself does not
    
+  force the need for that change.  Fixing any code which currently depends
    
+  on being able to SETF one of these accessors might be more work in some
    
+  implementations.
    
+
    
+Cost to Users:
    
+  Programs which currently depend on being able to SETF these accessors are
    
+  already non-portable.
    
+
    
+Benifits:
    
+  Users will know what to expect.
    
+
    
+Discussion:
    
+  Pitman and Barrett supports proposal NO.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075.htm new file mode 100644 index 00000000..9202df2b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONDITION-RESTARTS:BUGGY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONDITION-RESTARTS:BUGGY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONDITION-RESTARTS:BUGGY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_m.htm new file mode 100644 index 00000000..5ce62e51 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue CONDITION-RESTARTS Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue CONDITION-RESTARTS Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_w.htm new file mode 100644 index 00000000..763599cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss075_w.htm @@ -0,0 +1,253 @@ + + + +CLHS: Issue CONDITION-RESTARTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONDITION-RESTARTS Writeup

    + +
    Status:	Version 2, Passed, Jun 89 X3J13
    
+	Version 3, as amended & passed Nov 89 X3J13
    
+
    
+Issue:        CONDITION-RESTARTS
    
+Forum:	      Cleanup
    
+References:   Common Lisp Condition System
    
+Category:     CHANGE
    
+Edit history: 18-Jan-89, Version 1 by Pitman
    
+              26-Jun-89, Version 2 by Pitman and Barrett
    
+	       3-Dec-89, Version 3 by Masinter (as amended Nov 89 X3J13)
    
+
    
+Problem Description:
    
+
    
+  It was noted in the condition system document itself, and many people have
    
+  complained privately, that a major weakness of the condition system is the
    
+  inability to know whether a particular restart is associated with a 
    
+  particular signalling action.  Also, there has been an interest in
    
+  disabling an established restart in some situations.
    
+
    
+  The problem being addressed shows itself in situations involving recursive
    
+  errors. The programmer wants to make sure that a restart obtained from
    
+  FIND-RESTART or COMPUTE-RESTARTS is in fact present for the purpose of
    
+  handling some particular error that he is actively focussed on, and not
    
+  for some other (outer) error which he was not actively trying to handle.
    
+
    
+  Also, some implementors have wondered whether it was appropriate to
    
+  implement restarts as objects with dynamic extent.  It would be good
    
+  to make this clear so that users are not surprised when porting programs.
    
+
    
+Proposal (CONDITION-RESTARTS:PERMIT-ASSOCIATION):
    
+
    
+  1. Define that during the dynamic extent of a call to SIGNAL with a
    
+     particular condition, the effect of calling SIGNAL again on that
    
+     condition object for a distinct abstract event is not defined.
    
+
    
+     For example, although a handler MAY resignal a condition in order to
    
+     allow outer handlers first shot at handling the condition, two
    
+     distinct asynchronous keyboard events may not signal an EQ condition
    
+     object at the same time.
    
+
    
+  2. Define that restarts have dynamic extent.
    
+
    
+  3. Introduce a macro WITH-CONDITION-RESTARTS which can be used to
    
+     dynamically bind the association between a condition and a set
    
+     of restarts.
    
+ 
    
+     WITH-CONDITION-RESTARTS condition-form restarts-form &BODY forms
    
+								[Macro]
    
+
    
+      Evaluates CONDITION-FORM and RESTARTS-FORM, the results of which
    
+      should be a condition C and a list of restarts (R1 R2 ...),
    
+      respectively. Then evaluates the body of forms in implicit-progn
    
+      style, returning the result of the last form, or NIL if there
    
+      are no forms. While in the dynamic context of the body,
    
+      an attempt to find a restart Ri which is associated with a
    
+      condition Ci (see #4 below), as in (FIND-RESTART rI cI), will 
    
+      consider the restarts R1, R2, etc. if (EQ CI C).
    
+
    
+     Usually this macro is not used explicitly in code, since
    
+     RESTART-CASE handles most of the common cases in a way that is
    
+     syntactically more concise.
    
+
    
+  4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
    
+     and STORE-VALUE to permit an optional condition object as an argument.
    
+
    
+     When the extra argument is not supplied, these functions behave
    
+     exactly as defined before. (Restarts are considered without
    
+     prejudice to whether they have been associated with conditions.)
    
+
    
+     When this argument is supplied, only those restarts which are
    
+     associated with the given condition or restarts which are not
    
+     associated with any condition are considered. In all other
    
+     respects, the behavior is the same. [However, see #7 for related
    
+     developments.]
    
+
    
+     Passing a condition argument of NIL is treated the same as passing
    
+     no condition argument.
    
+
    
+  5. Extend the definition of RESTART-CASE to say that if the form to
    
+     do the signalling is a list whose car is any of SIGNAL, ERROR,
    
+     CERROR, or WARN (or is a form which macroexpands into such a
    
+     list), then WITH-CONDITION-RESTARTS is implicitly intended to
    
+     associate the restarts with the condition to be signalled.
    
+
    
+     That is, for example,
    
+        (RESTART-CASE (SIGNAL FRED)
    
+          (A ...)
    
+          (B ...))
    
+     is equivalent to
    
+        (RESTART-CASE
    
+            (WITH-CONDITION-RESTARTS FRED 
    
+                                     (LIST (FIND-RESTART 'A) 
    
+                                           (FIND-RESTART 'B))
    
+              (SIGNAL FRED))
    
+          (A ...)
    
+          (B ...))
    
+
    
+  6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
    
+     to signal and to make restarts available, use the equivalent of
    
+     WITH-CONDITION-RESTARTS to associate the conditions they signal with
    
+     the defined restarts, so that users can make reliable tests not only
    
+     for the restarts being available, but also for them being available
    
+     for the right reasons.
    
+
    
+  7. Add a :TEST keyword to RESTART-CASE clauses and a :TEST-FUNCTION
    
+     keyword to RESTART-BIND clauses (in the same general style as the
    
+     :INTERACTIVE and :INTERACTIVE-FUNCTION keywords).  These permit
    
+     association of a function of one argument with a restart such
    
+     that if this function returns false, then functions such as
    
+     FIND-RESTART, COMPUTE-RESTARTS, and INVOKE-RESTART [see #4 above]
    
+     will not consider the restart to be active. The argument to the
    
+     test function is the value of the optional condition argument
    
+     most of these functions accept (or nil for invoke-restart, since
    
+     it doesn't have that argument). The default test function is
    
+
    
+       #'(LAMBDA (C) (DECLARE (IGNORE C)) T).
    
+
    
+Rationale:
    
+
    
+  1. The ability to recycle a condition object (including the ability to
    
+     resignal a condition) means that the same condition object might be
    
+     simultaneously active for two different purposes. In such a case, no
    
+     test (not even EQ) would suffice to determine whether a particular
    
+     restart belonged with a particular signalling action, since the
    
+     condition could not uniquely identify the signalling action. By
    
+     making the programmer responsible for assuring that that a given
    
+     condition may not be concurrently signalled for two conceptually
    
+     distinct purposes, this sticky area is avoided.
    
+
    
+  2. There are no known reasons for restarts to not have dynamic extent.
    
+     Important optimizations may be possible by allowing implementors this
    
+     flexibility.
    
+
    
+  3. This is is the minimal level of support needed to set up an 
    
+     association between restarts and conditions.
    
+
    
+  4. This provides a natural interface for retrieving and using the
    
+     information about the associations between conditions and restarts.
    
+
    
+  5. This provides a natural interface for the most common case of
    
+     wanting to signal a restart with some associated conditions.
    
+
    
+  6. This is a logical consequence of 5.
    
+
    
+  7. Programmers and implementors have asked for a way of
    
+     "filtering" restarts so that they are not visible in some contexts.
    
+
    
+Test Case:
    
+
    
+  (HANDLER-BIND ((ERROR #'(LAMBDA (C) (SIGNAL C) ...))) (SIGNAL "Test"))
    
+  was permissible and continues to be. However,
    
+  (HANDLER-BIND ((ERROR #'(LAMBDA (C) (SIGNAL FRED) ...))) (SIGNAL FRED))
    
+  may be undefined (depending on the programmer's intent) because the
    
+  two uses of FRED are not cooperating and may not represent conceptually
    
+  distinct situations.
    
+
    
+  (RESTART-CASE 
    
+      (WITH-CONDITION-RESTARTS FOO (LIST (FIND-RESTART 'ALPHA))
    
+        (RESTART-CASE
    
+            (INVOKE-RESTART 'ALPHA)
    
+          (ALPHA () 2)))
    
+    (ALPHA () 1)))
    
+  => 2
    
+
    
+  (LET ((FOO (MAKE-CONDITION 'SIMPLE-CONDITION)))
    
+    (RESTART-CASE 
    
+        (WITH-CONDITION-RESTARTS FOO (LIST (FIND-RESTART 'ALPHA))
    
+          (RESTART-CASE
    
+              (INVOKE-RESTART (FIND-RESTART 'ALPHA FOO))
    
+            (ALPHA () 2)))
    
+      (ALPHA () 1)))
    
+  => 1
    
+
    
+  (RESTART-CASE 
    
+      (WITH-CONDITION-RESTARTS FOO (LIST (FIND-RESTART 'ALPHA))
    
+        (RESTART-CASE
    
+            (INVOKE-RESTART 'ALPHA)
    
+          (ALPHA () :TEST (LAMBDA (C) (DECLARE (IGNORE C)) NIL)
    
+            2)))
    
+    (ALPHA () 1)))
    
+  => 1
    
+
    
+Current Practice:
    
+
    
+  Presumably no implementation does this yet.
    
+
    
+Cost to Implementors:
    
+
    
+  Several small, relatively modular changes.
    
+
    
+  The specific details of how the association is made between conditions
    
+  and restarts is left up to the implementation.  It is recommended (e.g.,
    
+  for the sake of the garbage collector) that the association be external
    
+  to the condition, however, since the condition might persist for long
    
+  afterward and the restart information has no value beyond the dynamic
    
+  extent during which the actual signalling is occurring.
    
+
    
+Cost to Users:
    
+
    
+  Except for the change to the recyclability of restarts, this change is 
    
+  upward compatible.
    
+
    
+  Probably very few if any users currently take advantage of recycling
    
+  restarts, so the cost to users of this change is very slight.
    
+  
    
+Cost of Non-Adoption:
    
+
    
+  Use of restarts would not be nearly as reliable.
    
+
    
+Benefits:
    
+
    
+  It would be possible to write code which was considerably more robust.
    
+
    
+Aesthetics:
    
+
    
+  Some people might consider this proposal to make things slightly better
    
+  because it avoids some ambiguities. Others might consider it to make
    
+  things slightly worse because it adds additional complexity.
    
+
    
+Discussion:
    
+
    
+  Pitman and Barrett support this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss076.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss076.htm new file mode 100644 index 00000000..8b6903cd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss076.htm @@ -0,0 +1,47 @@ + + + +CLHS: Issue CONDITION-RESTARTS:PERMIT-ASSOCIATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONDITION-RESTARTS:PERMIT-ASSOCIATION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CONDITION-RESTARTS:PERMIT-ASSOCIATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077.htm new file mode 100644 index 00000000..e3b711f4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue CONDITION-SLOTS:HIDDEN Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONDITION-SLOTS:HIDDEN Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CONDITION-SLOTS:HIDDEN:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077_w.htm new file mode 100644 index 00000000..88617e47 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss077_w.htm @@ -0,0 +1,153 @@ + + + +CLHS: Issue CONDITION-SLOTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONDITION-SLOTS Writeup

    + +
    Issue:         CONDITION-SLOTS
    
+
    
+References:    Condition System, version 18
    
+               Issue CLOS-CONDITIONS
    
+               Issue PACKAGE-CLUTTER
    
+               ANSI CL draft pp.5-4, 5-5
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  3-Jan-90, Version 1 by Barrett
    
+               30-Apr-90, Version 2 by Moon (rewrite, just one proposal,
    
+                 extend to cover all specified objects that have slots)
    
+
    
+Problem description:
    
+
    
+  Pages 5-4 and 5-5 of the ANSI CL draft specification from last fall refer
    
+  to slots of specified conditions.  However these slots were not put into
    
+  the specification in a consistent way.
    
+
    
+  CLOS-CONDITIONS:INTEGRATE, which was adopted by X3J13, changed condition
    
+  slots to be the same as CLOS slots, but did not say that the specified
    
+  conditions have any specified slots.  However, some people have taken it
    
+  to mean that the condition classes defined by the standard all contain
    
+  slots whose names are external symbols in the CL package which are
    
+  STRING= to the specified initargs for creating conditions.  The ANSI CL
    
+  draft specification was edited in some places as if this were true.
    
+
    
+  Revision 18 of the conditions document, which was adopted by X3J13,
    
+  refers to initialization arguments and accessors, but carefully avoids
    
+  naming the slots themselves.  The philosophy of that document was that
    
+  slots are only defined for programmer defined conditions, and that the
    
+  only sanctioned interface for the standard condition classes is through
    
+  the use of the defined accessor functions.
    
+
    
+  A related, more general issue that PACKAGE-CLUTTER:REDUCE failed to
    
+  address is whether there are naming restrictions on
    
+  implementation-dependent slots of specified classes.
    
+
    
+  This is Symbolics issue #8 and Loosemore issue #15 of 27 Feb 90.
    
+
    
+Proposal (CONDITION-SLOTS:HIDDEN):
    
+
    
+  1. Clarify that no specified condition classes have any specified slots.
    
+  The implementation of the required information storage by the specified
    
+  condition classes is implementation-dependent.  We need to be clear that
    
+  specified conditions are not required to have any particular slots with
    
+  any particular names.  They -are- required to be the type of object that
    
+  is able to have slots.  User-defined conditions -are- required to have
    
+  slots with the names mentioned in the DEFINE-CONDITION form.
    
+
    
+  2. Table 5-1 in the ANSI CL draft specification should not contain slot
    
+  names, because they will not necessarily be accessible via WITH-SLOTS in
    
+  the way people might infer.  Instead, the table should mention initargs
    
+  and accessors.  For example, :FORMAT-STRING and
    
+  SIMPLE-CONDITION-FORMAT-STRING -- but not the symbol FORMAT-STRING.
    
+          
    
+  3. Define that it is unspecified whether slots are involved in the
    
+  operation of specified functions on instances of specified classes,
    
+  except when slots are explicitly specified by the standard.
    
+
    
+  4. Define that if in a particular implementation a specified class has
    
+  slots that are not specified by the standard, the names of these slots
    
+  must not be external symbols of packages defined in the standard nor
    
+  otherwise accessible in the USER package.
    
+
    
+Rationale:
    
+
    
+  Allowing the information storage to be implementation-dependent is
    
+  essential to compatibility with existing systems, which may not represent
    
+  this information in the "obvious" way.
    
+
    
+  Specifying slots for the condition classes would require putting the slot
    
+  names into the COMMON-LISP package, adding many symbols.
    
+
    
+  Part 4 of the proposal repairs an omission in PACKAGE-CLUTTER:REDUCE.  It
    
+  is necessary if users are to be able to define a subclass of a condition
    
+  class (which is necessary whenever users define their own conditions) and
    
+  give slots to their class without potentially interfering with
    
+  implementation-defined slots.
    
+
    
+Current practice:
    
+
    
+  Parts 1 through 3 are likely to be consistent with all existing
    
+  implementations.  Part 4 is not known to be specifically violated by any
    
+  implementation, but it might well be violated by accident.  I have not
    
+  tested any implementations specifically.
    
+
    
+Cost to Implementors:
    
+
    
+  Easy, all they have to do is keep slot names out of user visible packages.
    
+
    
+Cost to Users:
    
+
    
+  Easy, all they have to do is use the specified accessors rather than
    
+  SLOT-VALUE or WITH-SLOTS to access information in conditions.
    
+
    
+Cost of non-adoption:
    
+
    
+  Substantially increased size of the COMMON-LISP package and considerable
    
+  extra work on the ANSI CL specification to document all the slots.
    
+  Porting problems for any code that defines its own condition types
    
+  because of slot name collisions.
    
+
    
+Performance impact:
    
+
    
+  None of any consequence.  SLOT-VALUE might be faster than calling an
    
+  accessor in some implementations (although in most implementations it is
    
+  slower, when not called from a method), but access to a slot of a
    
+  condition never occurs in important inner loops.
    
+
    
+Benefits:
    
+
    
+  Conditions will be specified as originally intended.
    
+
    
+Esthetics:
    
+
    
+  Abstraction is better than mandating one particular implementation
    
+  of information storage.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078.htm new file mode 100644 index 00000000..3665be53 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONS-TYPE-SPECIFIER:ADD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONS-TYPE-SPECIFIER:ADD Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONS-TYPE-SPECIFIER:ADD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078_w.htm new file mode 100644 index 00000000..f8ba1254 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss078_w.htm @@ -0,0 +1,136 @@ + + + +CLHS: Issue CONS-TYPE-SPECIFIER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONS-TYPE-SPECIFIER Writeup

    + +
    Issue:        CONS-TYPE-SPECIFIER
    
+Forum:	      EDITORIAL
    
+References:   Issue PRETTY-PRINT-INTERFACE,
    
+	      Issue ATOMIC-TYPE-SPECIFIER-LIST,
    
+	      Issue RECURSIVE-DEFTYPE
    
+Category:     ADDITION
    
+Edit history: 05-Feb-91, Version 1 by Pitman
    
+	      15-Mar-91, Version 2 by Pitman
    
+	      08-Apr-91, Version 3 by Pitman 
    
+	        (integrate amendment to option ADD from Mar-91 meeting)
    
+Status:	      X3J13 passed option ADD on a vote of 12-1, March 1991.
    
+
    
+Problem Description:
    
+
    
+  The description of the pretty printer dispatching mechanism is complicated
    
+  by the fact that dispatch cannot be described in terms of `type specifiers'.
    
+  In fact, the pretty printer dispatches on either a type specifier -or- a
    
+  list whose car is CONS.
    
+
    
+Proposal (CONS-TYPE-SPECIFIER:ADD):
    
+
    
+  Permit the CONS type specifier to be a type specifier that specializes,
    
+  with the syntax:
    
+
    
+    (CONS [type-specifier-1 [type-specifier-2]])
    
+
    
+  Either type specifier may be *, which means the same as T.
    
+  Either the second type specifier or both type specifiers may be omitted.
    
+  Omitted type specifiers default to T.
    
+
    
+  Extend the CONS pretty printer dispatcher to treat (CONS) the same as CONS.
    
+
    
+Test Case:
    
+
    
+  (TYPEP '(A B C) 'CONS)   => T			; Already true
    
+  (TYPEP '(A B C) '(CONS T)) => T		; New with this proposal
    
+  (TYPEP '(A B C) '(CONS SYMBOL)) => T		; New with this proposal
    
+  (TYPEP '(A B C) '(CONS INTEGER)) => NIL	; New with this proposal
    
+  (TYPEP '(A B C) '(CONS T T)) => T		; New with this proposal
    
+  (TYPEP '(A B C) '(CONS SYMBOL SYMBOL)) => NIL	; New with this proposal
    
+  (TYPEP '(A B C) '(CONS SYMBOL (CONS SYMBOL (CONS SYMBOL))))
    
+   => T						; New with this proposal
    
+  (TYPEP '(A B C) '(CONS SYMBOL (CONS SYMBOL (CONS SYMBOL NIL))))
    
+   => NIL					; New with this proposal
    
+  (TYPEP '(A B C) '(CONS SYMBOL (CONS SYMBOL (CONS SYMBOL NULL))))
    
+   => T						; New with this proposal
    
+
    
+Rationale:
    
+
    
+  This will make the description of the pretty printer simpler with no 
    
+  substantial overhead for other parts of the system.
    
+
    
+  This same approach was taken for EQL type specifiers in CLOS, so that
    
+  all method specializers could have corresponding type specifiers.
    
+
    
+Current Practice:
    
+
    
+  Probably no one implements this.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Extra conceptual overhead in the specification.  A new term will have to be
    
+  devised for pprint `type specifiers' in order to avoid telling lies all over
    
+  the place about some things being type specifiers that really aren't (or to 
    
+  avoid being overly verbose all over the place if we decide to tell the full
    
+  truth every time the issue comes up.)
    
+
    
+Benefits:
    
+
    
+  This new type specifier might be turn out to be useful in its own right in
    
+  some applications.
    
+
    
+Aesthetics:
    
+
    
+  I think this improves the aesthetics.
    
+
    
+Discussion:
    
+
    
+  This was discussed previously and discarded.  But having looked at the 
    
+  complexity it introduces in to the specification, I think it needs to be
    
+  reopened.
    
+
    
+  The question of what (TYPEP '(A B C) '(CONS)) returns was spun off as
    
+  a separate issue named ATOMIC-TYPE-SPECIFIER-LIST.
    
+
    
+  Barmar got briefly excited about the idea of 
    
+   (deftype proper-list (&optional (element-type t))
    
+     `(or null (cons ,element-type proper-list)))
    
+  but others didn't like it.  A separate issue RECURSIVE-DEFTYPE addresses
    
+  this.
    
+
    
+  Allan Wechsler (Symbolics) notes that 
    
+    (deftype list-of-length (length)
    
+      (if (= 0 length)
    
+	  'null
    
+	  `(cons t (list-of-length ,(- length 1)))))
    
+  would in principle be reasonable under this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079.htm new file mode 100644 index 00000000..1df5dbf9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONSTANT-CIRCULAR-COMPILATION:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANT-CIRCULAR-COMPILATION:YES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONSTANT-CIRCULAR-COMPILATION:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079_w.htm new file mode 100644 index 00000000..530bc692 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss079_w.htm @@ -0,0 +1,220 @@ + + + +CLHS: Issue CONSTANT-CIRCULAR-COMPILATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANT-CIRCULAR-COMPILATION Writeup

    + +
    Option YES passed 17-0-1 at meeting of Mar-89.
    
+-----
    
+Forum:		Compiler
    
+Issue:		CONSTANT-CIRCULAR-COMPILATION
    
+References:	Issue CONSTANT-COLLAPSING
    
+		Issue QUOTE-SEMANTICS
    
+Category:	CLARIFICATION, ADDITION
    
+Edit History:   V1, 07 Nov 1988, Sandra Loosemore
    
+		V2, 14 Nov 1988, Cris Perdue
    
+		V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
    
+		V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
    
+		V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
    
+		V6, 08 Feb 1989, Sandra Loosemore (replace FLAG with YES)
    
+                V7, 11 Mar 1989, Sandra Loosemore (error terminology)
    
+		V8, 18 Mar 1989, Sandra Loosemore (changes per Moon, Masinter)
    
+Status:		Ready for release
    
+
    
+
    
+Problem Description:
    
+
    
+CLtL does not specify whether constants containing circular or
    
+recursive references may be compiled.  It is also not clear whether
    
+the compiler must preserve sharing of EQL substructures; that is, whether
    
+subobjects that are EQL in the source code must remain EQL after being
    
+compiled.
    
+
    
+The proposals below apply to constants appearing in a file compiled by
    
+COMPILE-FILE.  If proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE
    
+passes, then the same constraints would apply to all constants.  The
    
+minimal scope over which sharing would be required to be detected is
    
+over a single call to EVAL or COMPILE.
    
+
    
+In the proposals that follow, "preserving EQLness" means that
    
+subobjects that are EQL in the source code must remain EQL after being
    
+compiled; that is, things don't get "less EQL" after compilation.
    
+(Note that coalescing of constants implies that things may get "more
    
+EQL".)
    
+
    
+
    
+Proposal CONSTANT-CIRCULAR-COMPILATION:NO
    
+
    
+State that conforming programs must not contain circular objects
    
+appearing as constants to be compiled.  The consequences of compiling
    
+a program containing such an object with COMPILE-FILE and/or LOADing
    
+the output produced by COMPILE-FILE for such a program [and, if we
    
+accept proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE, compiling it
    
+with COMPILE or evaluating it interpretively] are undefined.
    
+
    
+State that the compiler is not required to preserve EQLness of
    
+substructures.
    
+
    
+  Rationale:
    
+
    
+  This proposal would not require any existing implementation to change.
    
+
    
+  Disallowing portable programs from containing circular constants
    
+  allows compiled file loaders to use somewhat simpler implementation
    
+  strategies (for example, to build constants in a strict bottom-up
    
+  fashion).
    
+
    
+
    
+Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
    
+
    
+State that conforming programs must not contain circular objects
    
+appearing as constants to be compiled.  The consequences of compiling
    
+a program containing such an object with COMPILE-FILE and/or LOADing
    
+the output produced by COMPILE-FILE for such a program [and, if we
    
+accept proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE, compiling it
    
+with COMPILE or evaluating it interpretively] are undefined.
    
+
    
+State that the compiler is required to preserve EQLness of
    
+substructures within a file compiled with COMPILE-FILE.
    
+
    
+  Rationale:
    
+
    
+  Disallowing portable programs from containing circular constants
    
+  allows compiled file loaders to use somewhat simpler implementation
    
+  strategies (for example, to build constants in a strict bottom-up
    
+  fashion).
    
+
    
+  Some programs (such as PCL) have come to depend on COMPILE-FILE 
    
+  preserving the EQLness of uninterned symbols, and it is cleaner
    
+  to require sharing to be preserved in general instead of making
    
+  symbols be a special case.  Requiring sharing to be preserved still
    
+  allows loaders to build constants bottom-up.
    
+
    
+
    
+Proposal CONSTANT-CIRCULAR-COMPILATION:YES
    
+
    
+State that objects containing circular references may legitimately
    
+appear as constants to be compiled.  State that the compiler is
    
+required to preserve EQLness of substructures within a file compiled
    
+with COMPILE-FILE.
    
+
    
+  Rationale:
    
+
    
+  Users seem to expect this functionality, and some implementations 
    
+  already provide it.
    
+
    
+
    
+Current Practice:
    
+
    
+A-Lisp preserves EQLness of substructures (since it makes an effort to
    
+collapse isomorphic structures) but signals an error if an attempt is
    
+made to compile a circular constant.  PSL and Utah Common Lisp both
    
+get stuck in an infinite loop if an attempt is made to compile a
    
+reentrant structure.  The TI Explorer compiler is able to reproduce
    
+recursive lists and arrays, but currently hangs in a loop on a
    
+circular list.  Neither the Explorer nor Symbolics Genera 7.x detects
    
+EQLness of list CDRs.  Lucid handles circular constants correctly.
    
+Franz uses a flag to control whether or not to attempt to detect
    
+circular constants.  KCL handles circular structures, but only detects
    
+sharing of top-level structure (it does not traverse constants to look
    
+for shared substructure).
    
+
    
+
    
+Cost to implementors:
    
+
    
+We know of no implementation that would have to change under proposal
    
+NO.  
    
+
    
+For proposal YES, some implementations would require sweeping
    
+changes; in some cases a completely different dumper/loader strategy
    
+would have to be implemented.
    
+
    
+The cost of proposal PRESERVE-SHARING-ONLY would fall somewhere in
    
+between.
    
+
    
+
    
+Cost to users:
    
+
    
+The situation now is that programs which depend upon circularity or
    
+sharing of substructure being preserved by the compiler are already
    
+nonportable.  Proposal NO simply formalizes the status quo.  Proposal
    
+YES would offer users functionality that is currently not portable.
    
+
    
+Portable CommonLoops reportedly requires EQLness of uninterned symbols
    
+to be preserved across a file, and would break under proposal NO.
    
+According to Cris Perdue:
    
+
    
+  I am told that support for PCL requires the kinds of guarantees about
    
+  uninterned symbols [that say EQLness will be preserved].  Jim Kempf
    
+  here at Sun tells me he believes that this is true.  John Foderaro
    
+  said that Franz made their compiler give this behavior in order to
    
+  support PCL.
    
+
    
+  Jim Kempf says he believes that certain GENSYMs appear in multiple
    
+  pieces of initialization code across a file in PCL, and the
    
+  initialization code only works if symbols EQ at compile time map to
    
+  symbols that are EQ at load time.
    
+
    
+
    
+Benefits:
    
+
    
+An area of ambiguity in the language is removed.
    
+
    
+
    
+Discussion:
    
+
    
+The issue of compiler speed is largely a red herring on this issue;
    
+the overhead of detecting circularities is generally quite small.  The
    
+main question is whether we should require some implementations to
    
+completely redo their compiler/loader interface in order to support
    
+circular constants.  
    
+
    
+It has been argued that any "serious" implementation will support
    
+circular constants anyway, because of customer demand.  However, since
    
+there appears to be only one implementation (Lucid) that now
    
+implements proposal YES in its full generality, perhaps the demand for
    
+this feature is not really all that strong.
    
+
    
+Earlier drafts of this writeup contained a proposal FLAG which would
    
+have added a variable *COMPILE-CIRCLE*, similar to *PRINT-CIRCLE*.
    
+However, there were unresolved problems about what would happen if the
    
+value of this variable were altered within the file being compiled,
    
+and it was generally agreed that this proposal didn't have any
    
+particular advantages over proposal YES and just introduced
    
+unnecessary hairiness.
    
+
    
+Since it is usually fairly simple to detect circular constants,
    
+Loosemore would support an amendment to proposals NO and
    
+PRESERVE-SHARING-ONLY to change the word "undefined" to "unspecified",
    
+adding:
    
+
    
+  Implementations must either correctly handle the circular reference
    
+  or signal an error.  
    
+
    
+This is similar to the language which is already used in proposal
    
+CONSTANT-COMPILABLE-TYPES:SPECIFY.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080.htm new file mode 100644 index 00000000..56aea000 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONSTANT-COLLAPSING:GENERALIZE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANT-COLLAPSING:GENERALIZE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONSTANT-COLLAPSING:GENERALIZE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080_w.htm new file mode 100644 index 00000000..b556cec6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss080_w.htm @@ -0,0 +1,148 @@ + + + +CLHS: Issue CONSTANT-COLLAPSING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANT-COLLAPSING Writeup

    + +
    Forum:		Compiler
    
+Issue:		CONSTANT-COLLAPSING
    
+References:	CLtL p. 78, 87
    
+		Issue CONSTANT-MODIFICATION
    
+		Issue CONSTANT-COMPILABLE-TYPES
    
+		Issue EQUAL-STRUCTURE
    
+		Issue QUOTE-SEMANTICS
    
+Category:	CHANGE
    
+Edit History:   V1, 07 Nov 1988, Sandra Loosemore
    
+		V2, 12 Dec 1988, Sandra Loosemore
    
+		V3, 03 Jan 1989, Sandra Loosemore
    
+		V4, 06 Jan 1989, Sandra Loosemore
    
+		V5, 11 Mar 1989, Sandra Loosemore
    
+		V6, 22 Mar 1989, Sandra Loosemore (comments from Moon)
    
+Status:		Ready for release
    
+
    
+
    
+Problem Description:
    
+
    
+CLtL states that an implementation is permitted to "collapse" or
    
+coalesce constants appearing in code to be compiled if they are EQUAL.
    
+The definition of EQUAL does not permit coalescing of more general
    
+isomorphic data structures (such as arrays), which is often desirable.
    
+
    
+This proposal deals only with changing the test which is used to
    
+determine whether two constants may be coalesced.  Issue
    
+QUOTE-SEMANTICS deals with whether coalescing may be performed only by
    
+COMPILE-FILE, or by COMPILE and EVAL as well.  If proposal
    
+QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE passes, then coalescing could be
    
+performed on all constants.
    
+
    
+This proposal uses the terms "source code", "compiled code", and
    
+"similar as constants" that are defined in proposal
    
+CONSTANT-COMPILABLE-TYPES:SPECIFY.
    
+
    
+The term "coalesce" is defined as follows.  Suppose A and B are two
    
+objects used as quoted constants in the source code, and that A' and
    
+B' are the corresponding objects in the compiled code.  If A' and B'
    
+are EQL but A and B were not EQL, then we say that A and B have been
    
+coalesced by the compiler.
    
+
    
+
    
+Proposal CONSTANT-COLLAPSING:GENERALIZE:
    
+
    
+State that an implementation is permitted to coalesce constants
    
+appearing in code to be compiled if and only if they are similar as
    
+constants, unless the objects involved are of type SYMBOL, PACKAGE,
    
+STRUCTURE, or STANDARD-OBJECT.
    
+
    
+
    
+Rationale:
    
+
    
+There is little reason why implementations should not be allowed to
    
+perform more general collapsing of objects, since the arguments
    
+against doing so also apply to collapsing of EQUAL objects, which
    
+is already permitted.  The arguments for coalescing of EQUAL data
    
+structures (primarily space reduction) also apply to coalescing of
    
+data structures that are equivalent under a more general coalescing
    
+predicate.
    
+
    
+Objects of type SYMBOL and PACKAGE cannot be coalesced because the fact
    
+that they are named, interned objects means they are already as
    
+coalesced as it is useful for them to be.  Uninterned symbols could
    
+perhaps be coalesced, but that was thought to be more dangerous than
    
+useful.  Objects of type STRUCTURE and STANDARD-OBJECT could be
    
+coalesced if a "similar as a constant" predicate were defined for them;
    
+it would be a generic function.  Currently LOAD-OBJECTS only defines how
    
+COMPILE-FILE and LOAD work together to construct an object in the
    
+compiled code that is equivalent to the object in the source code,
    
+and a different mechanism would have to be added to permit coalescence.
    
+
    
+
    
+Current Practice:
    
+
    
+Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
    
+and certain other data types that are defined internally as structures
    
+(RANDOM-STATEs, for example).  Lucid Common Lisp also uses a more
    
+general coalescing predicate than EQUAL.
    
+
    
+
    
+Cost to implementors:
    
+
    
+For implementations that currently coalesce based on EQUAL or that do
    
+no coalescing, there is no associated implementation cost.
    
+
    
+For implementations that currently coalesce things that this proposal
    
+forbids them to coalesce (such as STRUCTUREs or uninterned symbols),
    
+the implementation cost is probably small.
    
+
    
+
    
+Cost to users:
    
+
    
+Programs that depend on objects not being coalesced except when they
    
+are EQUAL may break under this proposal.  The only way one would be
    
+able to detect that coalescing has taken place is if objects that were
    
+not EQL in the source file become EQL after compilation; accessors on
    
+the objects would return the same values regardless of whether or not
    
+coalescing has taken place.
    
+
    
+
    
+Benefits:
    
+
    
+Collapsing of isomorphic arrays may lead to significant memory savings
    
+in some applications.
    
+
    
+
    
+Discussion:
    
+
    
+This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
    
+
    
+Some people believe that if the definition of EQUAL weren't "broken",
    
+there wouldn't be any need for this proposal.
    
+
    
+There is no inherent reason why the "coalescing predicate" must be the
    
+same as the relationship used by the compiler/loader to construct
    
+equivalent copies of objects of constants, but making the same rules
    
+be applied in both situations simplifies the language somewhat.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081.htm new file mode 100644 index 00000000..83c3f984 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANT-COMPILABLE-TYPES:SPECIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONSTANT-COMPILABLE-TYPES:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081_w.htm new file mode 100644 index 00000000..d96f81b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss081_w.htm @@ -0,0 +1,373 @@ + + + +CLHS: Issue CONSTANT-COMPILABLE-TYPES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANT-COMPILABLE-TYPES Writeup

    + +
    Forum:		Compiler
    
+Issue:		CONSTANT-COMPILABLE-TYPES
    
+References:	CLtL pp. 56, 77-80, 324
    
+		Issue CONSTANT-MODIFICATION
    
+		Issue CONSTANT-CIRCULAR-COMPILATION
    
+		Issue CONSTANT-COLLAPSING
    
+		Issue QUOTE-SEMANTICS
    
+		Issue LOAD-OBJECTS
    
+		Issue CONSTANT-FUNCTION-COMPILATION
    
+Category:	CLARIFICATION, ADDITION
    
+Edit history:	11/07/88, V1 by Cris Perdue
    
+		11/14/88, V2 by Cris Perdue
    
+		11/22/88, V3 by Cris Perdue
    
+		12/20/88, V4 by Cris Perdue
    
+		01/06/89, V5 by Sandra Loosemore (minor editorial
    
+			clarifications, expand discussion)
    
+		03/05/89, V6 by Cris Perdue (more response to comments,
    
+			especially from Moon and and from Loosemore)
    
+                03/05/89, V7 by Loosemore (more editorial tweaks)
    
+		03/13/89, V8 by Loosemore (discussion)
    
+		03/22/89, V9 by Loosemore (restructure)
    
+		04/03/89, V10 by Loosemore (amendment)
    
+Status:		Proposal SPECIFY passed March 1989.
    
+
    
+Problem description:
    
+
    
+CLtL does not specify what objects can be in compiled constants and it
    
+does not say what relationship there is to be between the constant
    
+passed to the compiler and the one that is established by compiling
    
+and then loading its file.  Relevant remarks in CLtL concerning file
    
+compilation and the definition of QUOTE suggest that the compiler
    
+handles constants in ways that are not actually possible.
    
+
    
+
    
+Introduction to the proposal:
    
+
    
+The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
    
+what types can appear in compiled constants, and what it means when
    
+they appear.
    
+
    
+The key is a definition of an equivalence relationship between Lisp
    
+objects, "similarity as constants".  Code passed through the file
    
+compiler and then loaded must behave as though quoted constants in it
    
+are "similar" to quoted constants in the corresponding source code.
    
+
    
+Issue CONSTANT-COLLAPSING addresses the issue of whether, for two
    
+objects that are not EQL in the source code (but which are similar as
    
+constants), the corresponding objects in the compiled code may be
    
+EQL.
    
+
    
+Issue CONSTANT-CIRCULAR-COMPILATION addresses the issue of whether,
    
+for two objects that are EQL in the source code, the corresponding
    
+objects in the compiled code must also be EQL.
    
+
    
+Comments within the text of the proposal are enclosed in double angle
    
+brackets, <<like this>>.
    
+
    
+
    
+Proposal:  CONSTANT-COMPILABLE-TYPES:SPECIFY
    
+
    
+An object may be used as a quoted constant processed by COMPILE-FILE
    
+if the compiler can guarantee that the resulting constant established
    
+by loading the compiled file is "similar as a constant" to the
    
+original.
    
+
    
+Some types of objects, such as streams, are not supported in constants
    
+processed by the file compiler.  Such objects may not portably appear
    
+as constants in code processed with COMPILE-FILE.  Conforming
    
+implementations are required to handle such objects either by having
    
+the compiler and/or loader reconstruct an equivalent copy of the
    
+object in some implementation-specific manner; or by having the
    
+compiler signal an error.
    
+
    
+Of the types supported in constants, some are treated as aggregate
    
+objects.  For these types, being similar as constants is defined
    
+recursively.  We say that an object of these types has certain "basic
    
+attributes", and to be similar as a constant to another object, the
    
+values of the corresponding attributes of the two objects must also be
    
+similar as constants.
    
+
    
+This kind of definition has problems with any circular or "infinitely
    
+recursive" object such as a list that is an element of itself.  We use
    
+the idea of depth-limited comparison, and say that two objects are
    
+similar as constants if they are similar at all finite levels.  This
    
+idea is implicit in the definitions below, and applies in all the
    
+places where attributes of two objects are required to be similar as
    
+constants.
    
+
    
+The following terms are used throughout this proposal:
    
+
    
+  The term "constant" refers to a quoted or self-evaluating constant,
    
+  not a named (defconstant) constant.
    
+
    
+  The term "source code" is used to refer to the objects constructed
    
+  when COMPILE-FILE calls READ, and additional objects constructed by
    
+  macroexpansion during COMPILE-FILE.
    
+
    
+  The term "compiled code" is used to refer to objects constructed by 
    
+  LOAD.
    
+
    
+Two objects are defined to be "similar as a constant" if and only if
    
+they are both of one of the types listed below and satisfy the
    
+additional requirements listed for that type.
    
+
    
+Number
    
+
    
+  Two numbers are similar as constants if they are of the same type
    
+  and represent the same mathematical value.
    
+  
    
+Character
    
+
    
+  Two characters are similar as constants if they both represent
    
+  the same character.
    
+
    
+  <<Note that this definition has to depend on the results of the
    
+  Character Set proposals.  The intent is that this be compatible with
    
+  how EQL is defined on characters.>>
    
+
    
+Symbol
    
+
    
+  Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
    
+  and loader handle interned symbols.
    
+
    
+  An uninterned symbol in the source code is similar as a constant
    
+  to an uninterned symbol in the compiled code if their print names
    
+  are similar as constants.
    
+
    
+Package
    
+
    
+  A package in the source code is similar as a constant to a package in
    
+  the compiled code if their names are similar as constants.  Note that
    
+  the loader finds the corresponding package object as if by calling
    
+  FIND-PACKAGE with the package name as an argument.  An error is
    
+  signalled if no package of that name exists at load time.
    
+
    
+Random-state
    
+
    
+  Let us say that two random-states are functionally equivalent if 
    
+  applying RANDOM to them repeatedly always produces the same 
    
+  pseudo-random numbers in the same order.  
    
+  
    
+  Two random-states are similar as constants if and only if copies of
    
+  them made via MAKE-RANDOM-STATE are functionally equivalent.
    
+
    
+  Note that a constant random-state object cannot be used as the "state"
    
+  argument to the function RANDOM (because RANDOM side-effects this
    
+  data structure).
    
+
    
+Cons
    
+
    
+  Two conses are similar as constants if the values of their respective
    
+  CAR and CDR attributes are similar as constants.
    
+
    
+Array
    
+
    
+  Two arrays are similar as constants if the corresponding values each
    
+  of the following attributes are similar as constants:
    
+
    
+  For 1-dimensional arrays:
    
+  LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.
    
+
    
+  For arrays of other dimensions:
    
+  ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.
    
+
    
+  In addition, if the array in the source code is a SIMPLE-ARRAY, then
    
+  the corresponding array in the compiled code must also be a
    
+  SIMPLE-ARRAY.  If the array in the source code is displaced, has a
    
+  fill pointer, or is adjustable, the corresponding array in the
    
+  compiled code is permitted to lack any or all of these qualities.
    
+
    
+Hash Table   
    
+
    
+  Two hash tables are similar as constants if they meet the following
    
+  three requirements:
    
+
    
+  (1) They both have the same test (e.g., they are both EQL hash tables).
    
+
    
+  (2) There is a unique one-to-one correspondence between the keys of
    
+      the two tables, such that the corresponding keys are similar as
    
+      constants.
    
+
    
+  (3) For all keys, the values associated with two corresponding keys
    
+      are similar as constants.
    
+
    
+  If there is more than one possible one-to-one correspondence between
    
+  the keys of the two tables, the results are unspecified.  A conforming
    
+  program cannot use such a table as a constant.
    
+
    
+Pathname
    
+
    
+  Two pathnames are similar as constants if all corresponding pathname
    
+  components are similar as constants.
    
+
    
+Stream, Readtable, Method
    
+
    
+  Objects of these types are not supported in compiled constants.
    
+
    
+Function
    
+
    
+  Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
    
+  loader handle constant functions.
    
+
    
+
    
+Structure, Standard-object
    
+
    
+  <<There is a cl-cleanup issue, LOAD-OBJECTS, pending which proposes
    
+  a mechanism for dealing with objects.>>
    
+
    
+
    
+Rationale:
    
+
    
+For the benefit of users, this proposal tries to define a fairly large
    
+set of types that all Common Lisp implementations are to handle.  It
    
+also attempts to leave room for implementations to differ.  Some
    
+implementations have made opposing choices because the language
    
+doesn't specify one over the other.  Some implementations already
    
+handle constants that this proposal defines as not valid in Common
    
+Lisp programs, and that is useful to users of those systems.
    
+Different implementors have different amounts of resources to apply to
    
+their system, and implementations differ in their whole approach in
    
+some cases.
    
+
    
+This proposal appears to reflect user demand and appears not to exceed
    
+the capabilities of most implementations of the language.
    
+
    
+
    
+Current practice:
    
+
    
+>From Gail Zacharias (Nov 14): "Coral pretty much implements this
    
+proposal (I think we currently coalesce hash table keys, but that's
    
+just a bug that will be fixed).  We also fasdump packages (using the
    
+package name) and compiled functions (but not foreign functions).  For
    
+symbols, we dump the name, and if (roughly speaking) the symbol would
    
+get printed with a package prefix, we also dump the package name and
    
+load the symbol into that package (otherwise it gets loaded into the
    
+current load-time package)."
    
+
    
+>From David Gray (Nov 9): "The Explorer can compile constant functions,
    
+read tables, and hash tables; an error is signalled for a stream.  A
    
+package object used to break the compiler but in release 5 it has been
    
+fixed to generate instructions to call FIND-PACKAGE on the package
    
+name at load time."  (Nov 15): [The Explorer does not guarantee
    
+retention of displaced-to and displaced-index-offset attributes.]
    
+"The Explorer also does not currently support dumping closures (either
    
+compiled or evaluated), although non-closure compiled functions can be
    
+dumped."
    
+
    
+>From David Moon (Jan 24): "Symbolics Genera current practice: aside
    
+from some current bugs we have with circular structures of certain
    
+types and with preserving the identity of CONSes under EQ, this is
    
+more or less consistent with our current practice, if you made the
    
+changes implied by my earlier comments.  We preserve the :displaced-to
    
+and :fill-pointer array attributes.  I doubt that we do what the
    
+proposal says for hash-tables, readtables, and random-states.  We
    
+support dumping compiled and interpreted functions, but not closures,
    
+which in effect means we don't support dumping functions."
    
+
    
+>From Sandra Loosemore (Mar 3): "UCL currently can handle only
    
+constants that are of type number, character, symbol, cons,
    
+simple-vector, or string (which it turns into simple-string).  It
    
+signals an error if an attempt is made to compile any other kind of
    
+object as a constant."
    
+
    
+
    
+Adoption cost:
    
+
    
+Not known.  Probably moderate or low -- for most implementations.  The
    
+cost would be to implementors rather than users since this part of the
    
+language is currently underspecified.  The author believes the cost
    
+will be reasonable for KCL, an implementation where there is some
    
+concern about this issue.
    
+
    
+This proposal is close to compatible with the Franz, Lucid, Coral,
    
+Texas Instruments, and Symbolics implementations.  It is probably
    
+compatible or nearly compatible with other "Lisp Machine"
    
+implementations.
    
+
    
+
    
+Benefits:
    
+
    
+Users would be able to use aggregate objects in constants with
    
+confidence about the behavior of their code.
    
+
    
+
    
+Conversion cost:
    
+
    
+Where this proposal *requires* different behavior than an existing
    
+implementation, there is a conversion cost for users of that
    
+implementation.  It appears that this cost will be small, less than
    
+the cost of leaving things unspecified.
    
+
    
+
    
+Esthetics:
    
+
    
+Since there is no adequate definition at present, a fuller definition
    
+would be more esthetic.
    
+
    
+
    
+Discussion:
    
+
    
+This proposal does leave some user-visible attributes of objects
    
+unspecified across the compile-and-load process, except that they must
    
+be consistent with the attributes that must be retained.  This
    
+situation is a compromise between the desire for full specification on
    
+the one hand, and on the other hand the desire to leave freedom for
    
+different implementations to remain different and to support some
    
+optimizations such as compacting hash tables and "simplifying" arrays.
    
+
    
+Proposals will be entertained for tighter specification of datatypes
    
+such as arrays.
    
+
    
+The definition of similarity for random-states supports the
    
+possibility of random states that are immutable because of being in
    
+compiled constants.
    
+
    
+Readtables need not be supported by an implementation.  If a readtable
    
+contains only symbols to represent functions, here is Cris Perdue's
    
+suggested spec for similarity of readtables:
    
+
    
+  Character syntax type for each character in the table;
    
+  function for each readmacro character, mappings for
    
+  dispatch macros; whether terminating or nonterminating
    
+  for each readmacro.
    
+
    
+Interest has been expressed by a number of people including users, in
    
+support for user-definable "dumping" of CLOS objects and structure
    
+instances.  The cleanup issue LOAD-OBJECTS deals with this.
    
+
    
+This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
    
+
    
+Earlier versions of this proposal specified an additional constraint
    
+on uninterned symbols, requiring EQLness to be preserved across the
    
+entire file.  However, this special case was removed because it was
    
+thought that including it in this issue made its presentation
    
+unnecessarily complicated, since preservation of EQLness is really a
    
+separate issue (CONSTANT-CIRCULAR-COMPILATION).  A consequence of the
    
+decision to remove the special casing for uninterned symbols is that,
    
+unless we accept one of the two CONSTANT-CIRCULAR-COMPILATION
    
+proposals that requires EQLness of constants to be preserved, the
    
+behavior for uninterned symbols will be rather strange.  PCL will
    
+reportedly break if uninterned symbols that are EQL in the source code
    
+do not remain EQL in the compiled code.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082.htm new file mode 100644 index 00000000..841a5c68 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONSTANT-FUNCTION-COMPILATION:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANT-FUNCTION-COMPILATION:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONSTANT-FUNCTION-COMPILATION:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082_w.htm new file mode 100644 index 00000000..80e67087 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss082_w.htm @@ -0,0 +1,142 @@ + + + +CLHS: Issue CONSTANT-FUNCTION-COMPILATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANT-FUNCTION-COMPILATION Writeup

    + +
    Forum:		Compiler
    
+Issue:		CONSTANT-FUNCTION-COMPILATION
    
+References:	Issue CONSTANT-COMPILABLE-TYPES
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 22 Mar 1989, Sandra Loosemore (split from issue
    
+			CONSTANT-COMPILABLE-TYPES)
    
+Status:		**DRAFT**
    
+
    
+
    
+Problem Description:
    
+
    
+Can objects of type FUNCTION (or some subset of FUNCTIONs) appear as
    
+quoted or self-evaluating constants in compiled code?  
    
+
    
+There are two questions that must be answered:
    
+
    
+- How does one test whether a particular function is a member of the
    
+  subset of functions that are dumpable?
    
+
    
+- For those functions that are dumpable, how do COMPILE-FILE and LOAD
    
+  arrange for an "equivalent" copy of the function in the source code to
    
+  be created in the compiled code?
    
+
    
+This writeup uses terminology from issue CONSTANT-COMPILABLE-TYPES:
    
+"source code", "compiled code", and "similar as constants".
    
+
    
+
    
+Proposal CONSTANT-FUNCTION-COMPILATION:NO:
    
+
    
+  Objects of type FUNCTION are not supported in compiled constants.
    
+
    
+ Rationale:
    
+
    
+  Nobody has been able to come up with a well-defined specification of
    
+  how the compiler and loader would be required to reconstruct
    
+  function constants that would work for all functions.
    
+
    
+  Nobody has been able to come up with a well-defined specification of
    
+  some subset of functions that could be dumped.
    
+
    
+
    
+Current Practice:
    
+
    
+  Coral can dump compiled functions, but not foreign functions.
    
+  
    
+  The TI Explorer cannot dump closures (either compiled or evaluated),
    
+  but can dump non-closure compiled functions.
    
+
    
+  Symbolics Genera can't dump closures either.
    
+
    
+  Kyoto Common Lisp can't dump any functions.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  None.  Implementations that can dump (some subset of) functions may
    
+  continue to do so, since issue CONSTANT-COMPILABLE-TYPES permits
    
+  implementations to extend the notion of "similar as constants".
    
+
    
+
    
+Cost to users:
    
+
    
+  None.  Programs that depend on being able to dump functions are
    
+  already nonportable, since not all implementations can dump all
    
+  functions and there is no portable way to construct or test for
    
+  functions that are dumpable in those implementations.
    
+
    
+
    
+Benefits:
    
+
    
+  Users will know what to (or what not to) expect when using functions
    
+  in compiled constants.
    
+
    
+
    
+Discussion:
    
+
    
+This issue was split from issue CONSTANT-COMPILABLE-TYPES because it
    
+appeared to be controversial enough to merit separate discussion.
    
+
    
+Cris Perdue originally suggested:
    
+
    
+  Only function constants that are not compiled-functions and do not
    
+  close over any (lexical) variables are supported in compiled
    
+  constants.
    
+
    
+  Two such functions are similar as constants if their
    
+  SOURCE-LAMBDA-EXPRESSIONs are similar as constants.
    
+
    
+Dick Gabriel responded:
    
+
    
+  I guess I pretty strongly object to leaving functions out of the list
    
+  of constants that can appear in compiled code. The part that's
    
+  disturbing is that such non-Lispy things like arrays, hashtables, and
    
+  pathnames get better treatment than functions, the most Lispy part of
    
+  Common Lisp. I wonder how many implementations will be forced to come
    
+  within an inch of the required functionality to implement a first-rate
    
+  CLOS?
    
+
    
+  The specification of the subset of functions that are acceptable as
    
+  compiled constants cannot be tested for within Common Lisp itself.
    
+
    
+  I suggest we ask implementors (Lucid included) to bite the bullet and
    
+  handle this case correctly. Won't our grandchildren appreciate us
    
+  treating Common Lisp like Lisp and not like PASCAL?
    
+
    
+If we were to specify that all functions could appear as constants, we
    
+would also need to clarify whether the closed-over variable bindings
    
+become immutable, and also deal with whether bindings that are closed
    
+over more than one function retain their uniqueness.  Also, the cost
    
+to implementors to add support for dumping non-interpreted functions
    
+may be quite high.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083.htm new file mode 100644 index 00000000..8237f72e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083.htm @@ -0,0 +1,52 @@ + + + +CLHS: Issue CONSTANT-MODIFICATION:DISALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANT-MODIFICATION:DISALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue CONSTANT-MODIFICATION:DISALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083_w.htm new file mode 100644 index 00000000..03b143f1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss083_w.htm @@ -0,0 +1,100 @@ + + + +CLHS: Issue CONSTANT-MODIFICATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANT-MODIFICATION Writeup

    + +
    Forum:		Compiler
    
+Issue:		CONSTANT-MODIFICATION
    
+References:	CLtL p. 78, 87
    
+		Issue CONSTANT-COLLAPSING
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 07 Nov 1988, Sandra Loosemore
    
+		V2, 12 Dec 1988, Sandra Loosemore
    
+
    
+
    
+
    
+Problem Description:
    
+
    
+CLtL states that an implementation is permitted to "collapse"
    
+constants appearing in code to be compiled if they are EQUAL.  This
    
+implicit sharing of compiled data structures may result in
    
+unpredictable behavior if destructive operations are performed.
    
+However, CLtL does not explicitly allow or disallow destructive
    
+operations on constants.  
    
+
    
+
    
+Proposal CONSTANT-MODIFICATION:DISALLOW:
    
+
    
+Clarify that it is an error to destructively modify objects which are 
    
+self-evaluating forms or which appear inside of a QUOTE special form.
    
+
    
+
    
+Rationale:
    
+
    
+Disallowing modification of constants consistently in all situations,
    
+rather than just in compiled code, is proposed because in some
    
+compiled-only situations it may be difficult to distinguish between
    
+"compiled" and "interpreted" code.
    
+
    
+
    
+Current Practice:
    
+
    
+Many implementations "collapse" compiled constants.
    
+
    
+Many implementations treat compiled constants as read-only.  In
    
+PSL/PCLS, for example, quoted data structures in compiled code are
    
+copied into a part of memory that is not scanned by the garbage
    
+collector.  The TI Explorer's loader also copies constants into a
    
+write-protected memory area.
    
+
    
+
    
+Cost to implementors:
    
+
    
+None.
    
+
    
+
    
+Cost to users:
    
+
    
+User programs which perform destructive operations on constants are
    
+already nonportable.
    
+
    
+
    
+Benefits:
    
+
    
+Many novice programmers do not realize that modifying quoted data
    
+structures is an error in many implementations.  Including an explicit
    
+statement in the standard that doing so is a bad idea will reduce
    
+confusion.
    
+
    
+
    
+Discussion:
    
+
    
+The issue of whether implementations are permitted to copy constants
    
+seen by EVAL or COMPILE is discussed separately as issue QUOTE-MAY-COPY.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084.htm new file mode 100644 index 00000000..78b84a06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONSTANTP-DEFINITION:INTENTIONAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANTP-DEFINITION:INTENTIONAL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONSTANTP-DEFINITION:INTENTIONAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084_w.htm new file mode 100644 index 00000000..869e7b84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss084_w.htm @@ -0,0 +1,461 @@ + + + +CLHS: Issue CONSTANTP-DEFINITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANTP-DEFINITION Writeup

    + +
    Issue:            CONSTANTP-DEFINITION
    
+References:       CONSTANTP (p324)
    
+Related issues:   CONSTANTP-ENVIRONMENT
    
+                  SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS
    
+Category:         CLARIFICATION/CHANGE
    
+Edit history:     v1, 07 Mar 1991, Sandra Loosemore
    
+		  v2, 12 Mar 1991, Kent Pitman
    
+                  v3, 14 Mar 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The specification of CONSTANTP in CLtL says:
    
+
    
+    CONSTANTP object       [Function]
    
+
    
+    If the predicate CONSTANTP is true of an object, then that object,
    
+    when considered as a form to be evaluated, always evaluates to the
    
+    same thing; it is a constant.  This includes self-evaluating objects
    
+    such as numbers, characters, strings, bit-vectors and keywords,
    
+    as well as constant symbols declared by DEFCONSTANT, such as
    
+    NIL, T, and PI.  In addition, a list whose car is QUOTE, such as
    
+    (QUOTE FOO), is considered to be constant.
    
+
    
+    If CONSTANTP is false of an object, then that object, considered
    
+    as a form, might or might not always evaluate to the same thing.
    
+
    
+  Some have interpreted this definition to mean what the first sentence
    
+  says, with the rest of the definition being merely an elaboration.
    
+
    
+  Others have interpreted that the definition seeks to identify a 
    
+  specific set of things which are considered to be constants for the
    
+  purpose of this function, namely
    
+   * a self-evaluating object
    
+   * a symbol naming a defined constant (built-in or declared by DEFCONSTANT)
    
+   * a list whose car is the symbol QUOTE
    
+
    
+  Most implementors have implemented tests only for these specific items
    
+  although there is little first-hand evidence about whether this was
    
+  because they felt restricted from implementing other cases or whether
    
+  they just didn't have the ambition to think up or implement additional
    
+  cases.  At least one implementor has implemented a small number of 
    
+  additional cases.
    
+
    
+  Some users have assumed that this was an exhaustive list of the
    
+  situations for which CONSTANTP must return true, and have written code
    
+  which purports to depend on that fact.
    
+
    
+  Some users have assumed that this was not an exhaustive list of the
    
+  situations for which CONSTANTP must return true, and have written code
    
+  which would perform better if other kinds of constant forms were 
    
+  detectable as well.
    
+
    
+  Of the two authors of this proposal, neither Pitman nor Loosemore
    
+  believes there is an ambiguity, but their opinions diverge.  And since
    
+  users and implementors have in good faith interpreted this wording
    
+  differently, then by definition there must be an ambiguity.
    
+
    
+Terminology:
    
+
    
+  For the purposes of this discussion, a `simple constant form' will
    
+  be defined as the union of these three items:
    
+   * a self-evaluating object
    
+   * a symbol naming a defined constant (built-in or declared by DEFCONSTANT)
    
+   * a list whose car is the symbol QUOTE
    
+
    
+Background:
    
+  
    
+  The description of CONSTANTP in the draft standard (version 8.81) 
    
+  contained a bug because it did not acknowledge that (QUOTE xxx) would
    
+  reliably be detected as a constant by CONSTANTP.  The amended text of
    
+  the definition, which is the current definition in the draft 
    
+  specification at the time this proposal is written, says:
    
+
    
+    CONSTANTP object			[Function]
    
+
    
+    Returns <true> if its argument can be determined by the
    
+    <implementation> to be a <constant form>; otherwise, 
    
+    it returns <false>.
    
+
    
+    The following items are considered constant forms:
    
+
    
+    * <constant objects> (such as <numbers>, <characters>, and
    
+      the various kinds of <arrays>) are always considered
    
+      <constant forms>.
    
+
    
+    * <constant variables>, such as <keywords>, symbols defined
    
+      by Common Lisp as constant (such as NIL, T, and PI),
    
+      and symbols defined by the user as constant using DEFCONSTANT
    
+      are always considered <constant forms>.
    
+
    
+    * QUOTE <forms> are considered <constant forms>.
    
+
    
+    * an <implementation> is permitted to, but not required to,
    
+      detect additional <constant forms>.  Examples of such forms
    
+      that might be detected are: (SQRT PI), (+ 3 2),
    
+      (LENGTH '(A B C)), and (LET ((X 7)) (ZEROP X)).
    
+
    
+  The glossary definition of <constant form> says:
    
+
    
+    constant form  n.  any <form> for which <evaluation> 
    
+      always <yields> the same <value> and which neither
    
+      affects nor is affected by the <environment> in which 
    
+      it is <evaluated>.
    
+
    
+  [Loosemore has criticized this definition as being overly vague on the
    
+   issue of whether a <constant form> may affect or be affected by
    
+   the objects accessible in that environment.  Pitman says this is
    
+   just an oversight.]
    
+
    
+  At issue is both whether these descriptions accurately capture the
    
+  intent of CLtL, and whether even if they do, the definition should
    
+  be amended.
    
+
    
+
    
+Proposal (CONSTANTP-DEFINITION:EXACT):
    
+
    
+  Clarify that CONSTANTP returns true if and only if its argument is
    
+  a `simple constant form' (see definition above).
    
+
    
+  Rationale:
    
+
    
+    CONSTANTP is typically used to implement some simple kinds of
    
+    code motion optimizations and side-effects analysis, for example
    
+    in computing the expansion of a macro or compiler-macro.  Permitting
    
+    CONSTANTP to return false for the three situations listed would
    
+    inhibit these kinds of optimizations in the obvious situations
    
+    where they were intended to be applied.  Permitting CONSTANTP to 
    
+    return true in other situations could cause these applications to
    
+    perform semantically invalid "optimizations".  
    
+
    
+    There is also a compatibility problem if CONSTANTP is permitted to
    
+    be sensitive to the lexical environment in which the form appears 
    
+    (see the cost to users section below).
    
+
    
+
    
+Proposal (CONSTANTP-DEFINITION:INTENTIONAL):
    
+
    
+  1. Clarify that if the predicate CONSTANTP is true of an object, 
    
+     then that object, when considered as a form to be evaluated, 
    
+     is a <constant form>.
    
+
    
+  2. Clarify that if CONSTANTP is false of an object, then that
    
+     object, considered as a form, might or might not be a
    
+     <constant form>.
    
+
    
+  3. a. Clarify that the other text in CLtL's definition of CONSTANTP 
    
+	is intended only as examples and to outline a minimal level
    
+	of expectation for users.  Explicitly permit implementations 
    
+	of CONSTANTP to return true for additional situations not listed
    
+	among those examples, but which satisfy (1).
    
+
    
+     b. Clarify that among the actions which an implementation is 
    
+        permitted to take is to macro expand and to do function 
    
+        inlining, but not to do expansion of compiler macros.
    
+
    
+  4. a. Clarify that execution of a <constant form> neither affects nor 
    
+        is affected by the run-time environment, except that it is 
    
+        sensitive to the presence of DEFCONSTANT.
    
+
    
+     b. Clarify that execution of a <constant form> neither affects nor 
    
+        is affected by either the state of any object except those objects 
    
+        which are otherwise inaccessible parts of objects created by the 
    
+        form itself.
    
+
    
+     That is, a form for which CONSTANTP previously returned NIL 
    
+     might at some point return T, but not vice versa.
    
+
    
+  Rationale:
    
+
    
+    Paragraphs (1) and (2) of this proposal are taken word-for-word
    
+    from CLtL (with the appropriate substitution to the new glossary
    
+    term) and Pitman thinks they speak for themselves.
    
+
    
+
    
+Proposal (CONSTANTP-DEFINITION:ADD-ARGUMENT):
    
+
    
+  Add an optional SIMPLE-P argument to CONSTANTP, which defaults to T.
    
+  [Any effect of issue CONSTANT-ENVIRONMENT is assumed to precede the
    
+   effect of this issue, so unless the ENVIRONMENT argument proposed 
    
+   by that issue would precede the SIMPLE-P argument proposed here.]
    
+
    
+  Define that if the SIMPLE-P argument is true, CONSTANTP 
    
+  behaves according to proposal EXACT, and that otherwise 
    
+  it behaves according to proposal INTENTIONAL.
    
+
    
+  Rationale:
    
+
    
+    This permits CONSTANTP to satisfy both needs, and allows programmers
    
+    to make their intent clear.
    
+
    
+
    
+Proposal (CONSTANTP-DEFINITION:RENAME):
    
+
    
+  Rename CONSTANTP to SIMPLE-CONSTANT-FORM-P.
    
+
    
+  Clarify that SIMPLE-CONSTANT-FORM-P returns true if and only if its argument
    
+  is one of the three kinds of things listed in the problem description.
    
+
    
+  Rationale:
    
+
    
+    This doesn't preclude an extension named CONSTANTP which does
    
+    more work to recognize other kinds of constant forms.
    
+
    
+
    
+Proposal (CONSTANTP-DEFINITION:EXTEND-SLIGHTLY):
    
+
    
+  Extend the definition of `simple constant form' to include a fourth case:
    
+    (VALUES x1 x2 ... xN)
    
+  where every xI is a `simple constant form.'
    
+
    
+Test Cases:
    
+
    
+  These cases are not evaluable forms, but rather objects that are
    
+  offered as arguments to the indicated functionality:
    
+
    
+  #1:  37
    
+
    
+       True under all proposals.  This is self-evaluating and hence
    
+       a `simple constant form'.
    
+
    
+  #2:  PI
    
+
    
+       True under all proposals.  This is the name of a defined constant
    
+       and hence a `simple constant form'.
    
+
    
+  #3:  'FOO
    
+
    
+       True under all proposals.  This is a QUOTE form and hence a 
    
+       `simple constant form.'
    
+
    
+  #4:  (VALUES 37 PI 'FOO)
    
+
    
+       True under proposals EXACT, INTENTIONAL, ADD-ARGUMENT, and RENAME
    
+       iff proposal EXTEND-SLIGHTLY is also adopted.  Otherwise, false.
    
+
    
+  #5:  (PROGN NIL)
    
+
    
+       Might be either true or false under proposal INTENTIONAL, or under
    
+       proposal ADD-ARGUMENT when the SIMPLE-P argument is true.  Otherwise,
    
+       must return false.
    
+
    
+  #6:  ;after a non-macro/non-inline DEFUN of START-WW-III
    
+       (PROGN (START-WW-III) NIL) 
    
+
    
+       False under all proposals.
    
+
    
+  #7:  (SQRT PI)
    
+
    
+       Might be either true or false under proposal INTENTIONAL, or under
    
+       proposal ADD-ARGUMENT when the SIMPLE-P argument is true.  Otherwise,
    
+       must return false.
    
+
    
+  #7:  (LET ((X 7)) (ZEROP X))
    
+
    
+       Might be either true or false under proposal INTENTIONAL, or under
    
+       proposal ADD-ARGUMENT when the SIMPLE-P argument is true.  Otherwise,
    
+       must return false.
    
+
    
+  #8:  ;after (DEFMACRO FOO () 37)
    
+       (FOO) 
    
+
    
+       Might be either true or false under proposal INTENTIONAL, or under
    
+       proposal ADD-ARGUMENT when the SIMPLE-P argument is true.  Otherwise,
    
+       must return false.
    
+
    
+  #9:  ;in (SYMBOL-MACROLET ((FOO MOST-POSITIVE-FIXNUM)) ...)
    
+       FOO
    
+
    
+       Might be either true or false under proposal INTENTIONAL, or under
    
+       proposal ADD-ARGUMENT when the SIMPLE-P argument is true.  Otherwise,
    
+       must return false.
    
+
    
+ #10:  (LET ((X (CONS 'X 'Y))) (CDR (RPLACA X 'Z)))
    
+
    
+       Might be either true or false under proposal INTENTIONAL, or under
    
+       proposal ADD-ARGUMENT when the SIMPLE-P argument is true.  Otherwise,
    
+       must return false.
    
+
    
+
    
+Current Practice:
    
+
    
+  Utah Common Lisp, KCL, CMU Common Lisp, Chestnut's Lisp-to-C
    
+  translator, and IIM all implement proposal EXACT (and proposal
    
+  INTENTIONAL, since it is compatible).
    
+
    
+  Symbolics Genera implements proposal EXACT+EXTEND-SLIGHTLY
    
+  (and proposal INTENTIONAL, since it is compatible), except
    
+  that (CONSTANTP ''(#,X)) returns NIL.  The implementors indicate
    
+  that the intent was to implemention INTENTIONAL and that so far
    
+  they've just been busy with other things.
    
+
    
+  From empirical observation, it appears that Lucid and Allegro also
    
+  implement proposal EXACT (and proposal INTENTIONAL, since it is
    
+  compatible).
    
+
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.  Here's a portable definition of CONSTANTP that
    
+  conforms with proposal RENAME:
    
+
    
+  (defun simple-constant-form-p (x &optional env)
    
+    (cond ((symbolp x) (eq (variable-information x env) :constant))
    
+          ((consp x) (eq (car x) 'quote))
    
+          (t t)))
    
+
    
+  Proposal EXTEND-SLIGHTLY modifies that definition in this way:
    
+
    
+  (defun simple-constant-form-p (x &optional env)
    
+    (cond ((symbolp x) (eq (variable-information x env) :constant))
    
+          ((consp x) (or (eq (car x) 'quote)
    
+			 (and (eq (car x) 'values)
    
+			      (every #'simple-constant-form-p (cdr x)))))
    
+          (t t)))
    
+
    
+
    
+Cost to Users:
    
+
    
+  If there are user programs that depend on CONSTANTP recognizing 
    
+  either more than just `simple constant forms' OR only
    
+  `simple constant forms' they're already nonportable.
    
+  
    
+  The portable uses of CONSTANTP currently include those which depend
    
+  on it returning true for `simple constant forms' but which are not
    
+  hurt by it returning true for other kinds of constant forms.
    
+
    
+  Many applications that now use CONSTANTP assume that the value it returns
    
+  is not sensitive to the lexical environment in which the form appears.
    
+  (Since CONSTANTP has not previously been specified to accept an 
    
+  environment argument, it is hard to see how any other interpretation
    
+  could be made.)  Proposals INTENTIONAL and ADD-ARGUMENT represent an 
    
+  incompatible change in this respect.  All calls to CONSTANTP within 
    
+  user programs would have to be examined to see whether an environment 
    
+  argument must be passed.  This also requires that something other than 
    
+  EVAL (like FUNCALL of ENCLOSE) be used to compute the value of something 
    
+  that is CONSTANTP.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+  Users will be confused about what to expect.
    
+  Implementors will be confused about what to implement.
    
+  The editor will be frustrated by the mess that must be documented.
    
+
    
+  
    
+Performance impact:
    
+
    
+  For the typical program, the performance impact is not major.
    
+
    
+  However, it is conceivable that there are cases where recognizing only
    
+  `simple constant forms' could have a substantial performance penalty
    
+  on certain otherwise-portable uses of DEFINE-COMPILER-MACRO which tried
    
+  to base decisions about whether code-motion was appropriate on the return
    
+  value of this function, and which found that such code motion was 
    
+  inhibited by this function being required to return NIL for constant
    
+  forms that were not simple constant forms but that the implementation 
    
+  would have been capable of recognizing as constant. e.g., consider
    
+  the following hypothetical example (which doesn't use &environment
    
+  only because the status of an environment argument to CONSTANTP is still
    
+  a pending issue).
    
+
    
+  (defun foo (&key x y) (foo-positional x y))
    
+
    
+  (define-compiler-macro foo (&whole form &rest key-value-pairs)
    
+    (cond ((= (length key-value-pairs) 4)
    
+	   (cond ((and (eq (nth 0 key-value-pairs) :x)
    
+		       (eq (nth 2 key-value-pairs) :y))
    
+                  `(foo-positional ,(nth 1 key-value-pairs)
    
+				   ,(nth 3 key-value-pairs)))
    
+		 ((and (eq (nth 0 key-value-pairs) :y)
    
+		       (eq (nth 2 key-value-pairs) :x)
    
+		       (or (constantp (nth 1 key-value-pairs))
    
+			   (constantp (nth 3 key-value-pairs))))
    
+		  `(foo-positional ,(nth 3 key-value-pairs)
    
+				   ,(nth 1 key-value-pairs)))
    
+		 (t form)))
    
+	  ...))
    
+
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided: everyone can finally know
    
+  what this function can be depended upon to do.
    
+
    
+
    
+Esthetics:
    
+
    
+  Having a well-defined CONSTANTP function is better than having
    
+  a vague CONSTANTP function.
    
+
    
+
    
+Discussion:
    
+
    
+  Loosemore wrote and supports option EXACT.
    
+
    
+  Pitman believes that the consensus among the Symbolics developers
    
+  is for proposal INTENTIONAL.  Regardless of the outcome of the four
    
+  `main' proposals, Symbolics would prefer to see option EXTEND-SLIGHTLY
    
+  passed.
    
+
    
+  Loosemore notes:
    
+
    
+    There is a danger with this issue in trying to make CONSTANTP into
    
+    something over-complicated and over-featurized.  I don't think that
    
+    the original purpose of this function was to do anything more than
    
+    perform some quick tests to detect the "obvious" situations, and
    
+    trying to extend it into some kind of more sophisticated code-walking
    
+    program analysis tool is likely to break more applications than it
    
+    would help.
    
+
    
+  In response to Pitman's urging for more leeway for CONSTANTP to
    
+  return true, JonL notes:
    
+
    
+    Years ago, I suggested a function CONSTANT-EXPRESSION-P which would be
    
+    modeled after the similar term in Interlisp; it would try to do the
    
+    more complicated-albeit-heuristic processing to notice forms like
    
+    (+ 3 (- 9 <symbolic-constant>)).  Didn't get a lot of interest then.
    
+    Although I think your last example [test case item #10] strains
    
+    even our best SSC's, I would still say "Keep it up!"
    
+
    
+  Barrett raised the issue about expansion of compiler-macros under
    
+  proposal INTENTIONAL.  Pitman replied:
    
+
    
+    Sandra talked about the issue of needless extra hair, and I guess this
    
+    is where I draw the line.  The semantics of the form are fully
    
+    specified without compiler macros, and I'd like to keep compiler
    
+    macros packaged away in a corner without having them clutter every
    
+    single operator.  So it seemed simplest to just say they don't get
    
+    used by CONSTANTP.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085.htm new file mode 100644 index 00000000..c24a34ee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONSTANTP-ENVIRONMENT:ADD-ARG Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONSTANTP-ENVIRONMENT:ADD-ARG Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONSTANTP-ENVIRONMENT:ADD-ARG:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085_w.htm new file mode 100644 index 00000000..1496036e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss085_w.htm @@ -0,0 +1,136 @@ + + + +CLHS: Issue CONSTANTP-ENVIRONMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONSTANTP-ENVIRONMENT Writeup

    + +
    Issue:               CONSTANTP-ENVIRONMENT
    
+References:          CONSTANTP
    
+Related issues:      COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    
+                     DEFCONSTANT-SPECIAL
    
+                     SUBTYPEP-ENVIRONMENT
    
+                     SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS
    
+                     CONSTANTP-DEFINITION
    
+Category:            CHANGE, ADDITION
    
+Edit history:        v1, 12 Feb 1991, Sandra Loosemore
    
+                     v2, 15 Feb 1991, Sandra Loosemore (comments from KAB)
    
+                     v3, 13 Mar 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  It is permitted for DEFCONSTANT to note the definition of the constant
    
+  at compile-time in such a way that the definition is visible only to
    
+  the file compiler and not to the evaluator.  This can lead to
    
+  incorrect behavior in user code that uses CONSTANTP, for example in
    
+  macro expansion functions.  Such code needs to explicitly indicate in
    
+  some way whether it wishes to deal with constant definitions in the
    
+  environment seen by the file compiler (the "remote environment"), or
    
+  in the current environment.
    
+
    
+Proposal (CONSTANTP-ENVIRONMENT:ADD-ARG):
    
+
    
+  Add an optional environment argument to the function CONSTANTP.  If
    
+  the argument is NIL or not supplied, it defaults to the null lexical 
    
+  and the current global environment.
    
+
    
+  CONSTANTP may use the environment to determine whether a symbol has
    
+  been globally defined as a constant (as with DEFCONSTANT).
    
+
    
+  Unless at least one of proposals CONSTANTP-DEFINITION:INTENTIONAL, 
    
+  CONSTANTP-DEFINITION:ADD-ARGUMENT, or 
    
+  SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED is accepted,
    
+  the value returned by CONSTANTP may not depend on lexical information
    
+  in the environment.
    
+
    
+Examples:
    
+
    
+   ???
    
+
    
+Rationale:
    
+
    
+  It solves the problem in a way that is consistent with the way it is
    
+  handled in other places in the language.
    
+
    
+Current Practice:
    
+
    
+  Chestnut's Lisp-to-C translator implements this proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  The cost of adding the environment argument is quite small.
    
+  In implementations that do not support remote environments, the argument
    
+  can simply be ignored.
    
+
    
+Cost to Users:
    
+
    
+  The behavior of existing programs that call CONSTANTP without an 
    
+  environment argument will not be affected.  However, there is some
    
+  motivation for users to change calls to CONSTANTP to pass an environment
    
+  argument where appropriate, since in implementations that do support 
    
+  remote environments, calling CONSTANTP without an environment argument
    
+  might result in NIL being returned for some things that could otherwise
    
+  have been detected as constant.
    
+
    
+Cost of non-adoption:
    
+
    
+  Some programs will work incorrectly.
    
+
    
+Performance impact:
    
+
    
+  Minor.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Looks OK to me.
    
+
    
+Discussion:
    
+
    
+  If proposal SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED
    
+  is accepted, CONSTANTP needs to accept an environment argument so that
    
+  it can detect when a defined constant has been lexically shadowed by a 
    
+  symbol macro.
    
+
    
+  If proposal CONSTANTP-DEFINITION:INTENTIONAL or ADD-ARGUMENT passes,
    
+  CONSTANTP needs to accept an environment argument so that it can perform
    
+  the additional kinds of analysis these proposals permit (such as
    
+  macroexpansion) in the correct lexical environment.
    
+
    
+  Proposal CONSTANTP-ENVIRONMENT:ADD-ARG only extends the syntax of
    
+  CONSTANTP and permits CONSTANTP to use *global* information in the
    
+  environment.  Issues SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS and
    
+  CONSTANTP-DEFINITION include proposals that would require that 
    
+  CONSTANTP also be sensitive to *lexical* information in the environment.
    
+  The costs to users and implementors that this would involve are
    
+  potentially much higher, but are more properly costs associated with
    
+  those other proposals, not CONSTANTP-ENVIRONMENT:ADD-ARG.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086.htm new file mode 100644 index 00000000..1de7074f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086_w.htm new file mode 100644 index 00000000..e088a6c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss086_w.htm @@ -0,0 +1,142 @@ + + + +CLHS: Issue CONTAGION-ON-NUMERICAL-COMPARISONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue CONTAGION-ON-NUMERICAL-COMPARISONS Writeup

    + +
    Issue:         CONTAGION-ON-NUMERICAL-COMPARISONS
    
+
    
+References:    CLtL p.194
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1, 14-Sep-88, Moon
    
+
    
+Problem description:
    
+
    
+The numerical contagion rules specified on CLtL p.194 make it impossible
    
+for the numerical comparison functions to be transitive when given
    
+arguments of mixed floating and rational types (see example below).
    
+
    
+Proposal (CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE):
    
+	  
    
+Instead of using the same contagion rule both for combining functions
    
+and for comparing functions, make the present rule apply only to
    
+combining functions and add the following rule:  When rational and
    
+floating-point numbers are compared by a numerical function, the
    
+function RATIONAL is called to convert the floating-point number to a
    
+rational and then an exact comparison is performed.  In the case of
    
+complex numbers (RATIONAL is for some unknown reason only allowed on
    
+reals), the real and imaginary parts are handled individually.
    
+
    
+It is of course valid to use a more efficient implementation than
    
+actually calling RATIONAL, as long as the result of the comparison is
    
+the same.
    
+
    
+Test Cases/Examples:
    
+
    
+(defvar a (/ 10.0 single-float-epsilon))
    
+
    
+(= a (1+ (floor a)))
    
+should be NIL, since 
    
+(= a (floor a))
    
+is certainly T and
    
+(= (floor a) (1+ (floor a)))
    
+is certainly NIL.  However, by the rule of floating-point contagion,
    
+(= a (1+ (floor a)))
    
+is the same as 
    
+(= a (float (1+ (floor a)) a))
    
+and the latter form is certainly T.
    
+
    
+To understand this example better, it helps to realize that
    
+(= a (+ a 1.0))
    
+is always true, by the definition of single-float-epsilon.
    
+
    
+Here is a second example:
    
+
    
+(defvar i (floor a))
    
+
    
+(<= a (+ i 1)) is T.
    
+(< (+ i 1) (+ i 2)) is T.
    
+(<= (+ i 2) a) is T by CLtL, NIL by this proposal.
    
+Thus CLtL requires
    
+  a <= i+1 < i+2 <= a
    
+which ought to imply
    
+  a < a
    
+which is absurd.
    
+
    
+Rationale:
    
+
    
+Transitivity of = and of < are important to many algorithms.  What CLtL
    
+says now was probably not intentional, but just the result of thinking
    
+that comparing and combining could be lumped together without really
    
+thinking about it.
    
+
    
+Without this change, it is impossible to extend the :TEST argument to
    
+MAKE-HASH-TABLE to allow = or EQUALP, since there could be two table
    
+entries with rational keys that are not =, then GETHASH could be
    
+presented with a floating-point argument that is = to both keys.
    
+
    
+Current practice:
    
+
    
+Lucid is said to implement the proposal.  As far as I know all other
    
+implementations do what CLtL currently says.
    
+
    
+Cost to Implementors:
    
+
    
+This requires a change in what is likely to be intricate and
    
+implementation-dependent code.  However, the total effort should
    
+be small compared to the cost of writing that code originally.
    
+
    
+Cost to Users:
    
+
    
+This is an incompatible change.  It's difficult to know if any users
    
+are depending on the current behavior.  It seems likely that most users
    
+would expect the proposed behavior, and may be wondering why their
    
+programs don't quite work when the numbers get large.
    
+
    
+Cost of non-adoption:
    
+
    
+Comparison functions in Common Lisp will be non-transitive.
    
+
    
+Benefits:
    
+
    
+Comparison functions in Common Lisp will be transitive.
    
+
    
+Esthetics:
    
+
    
+Having two rules of floating-point contagion may seem less esthetic,
    
+but I'm certain that having the comparison functions behave in a more
    
+mathematically correct fashion outweighs that esthetically.
    
+
    
+Discussion:
    
+
    
+Everyone who has expressed an opinion has thought this was the right
    
+thing for years, but we never got around to writing it up as a cleanup
    
+proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087.htm new file mode 100644 index 00000000..bb1cba4e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COPY-SYMBOL-COPY-PLIST:COPY-LIST Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COPY-SYMBOL-COPY-PLIST:COPY-LIST Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COPY-SYMBOL-COPY-PLIST:COPY-LIST:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087_w.htm new file mode 100644 index 00000000..073e1c80 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss087_w.htm @@ -0,0 +1,80 @@ + + + +CLHS: Issue COPY-SYMBOL-COPY-PLIST Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COPY-SYMBOL-COPY-PLIST Writeup

    + +
    Issue:		COPY-SYMBOL-COPY-PLIST
    
+References:	COPY-SYMBOL (p 169), COPY-LIST (p 268), COPY-TREE (p
    
+		269).
    
+Category:	CLARIFICATION
    
+Edit history:	10-Jan-89, Version 1 by Margolin
    
+
    
+Problem Description:
    
+
    
+The description of COPY-SYMBOL, where the COPY-PROPS optional argument
    
+is non-NIL, says that a copy of the property list is used as the new
    
+symbol's property list.  However, there are several ways in which a list
    
+may be copied, most notably COPY-LIST and COPY-TREE, and the description
    
+doesn't say which mechanism should be used.
    
+
    
+Proposal (COPY-SYMBOL-COPY-PLIST:COPY-LIST)
    
+
    
+Clarify that when COPY-SYMBOL copies the property list of the symbol, it
    
+is as if (COPY-LIST (SYMBOL-PLIST sym)) were used as the new symbol's
    
+property list.
    
+
    
+Rationale:
    
+
    
+COPY-LIST is the simplest list-copying primitive.  The result of this
    
+copy is that GET returns EQL results for the two symbols until one of
    
+the property lists is altered, but altering either of the property lists
    
+doesn't affect the other.  This is current practice in the
    
+implementations I tested, and probably what most users assume.
    
+
    
+Current Practice:
    
+
    
+Symbolics Genera and Sun Common Lisp currently implement this.  I
    
+suspect most others do, too.
    
+
    
+Cost to Implementors:
    
+
    
+Little or none.
    
+
    
+Cost to Users:
    
+
    
+None unless they've been assuming some other type of copy.
    
+
    
+Benefits:
    
+
    
+Less ambiguity.
    
+
    
+Aesthetics:
    
+
    
+Well, I like it.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088.htm new file mode 100644 index 00000000..f40e64b7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue COPY-SYMBOL-PRINT-NAME:EQUAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue COPY-SYMBOL-PRINT-NAME:EQUAL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue COPY-SYMBOL-PRINT-NAME:EQUAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088_w.htm new file mode 100644 index 00000000..a629624a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss088_w.htm @@ -0,0 +1,91 @@ + + + +CLHS: Issue COPY-SYMBOL-PRINT-NAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue COPY-SYMBOL-PRINT-NAME Writeup

    + +
    Issue:        COPY-SYMBOL-PRINT-NAME
    
+References:   COPY-SYMBOL (p. 169)
    
+Category:     CLARIFICATION
    
+Edit history: 1-MAR-89, Version 1 by Chapman
    
+              15-MAR-89, Version 2 by Chapman
    
+ 
    
+Problem Description:
    
+ 
    
+The description of COPY-SYMBOL states that it "returns a new uninterned
    
+symbol with the same print name as sym (its first argument)". The words
    
+"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
    
+ 
    
+Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
    
+ 
    
+The description of COPY-SYMBOL should read as follows:
    
+"COPY-SYMBOL returns an uninterned
    
+symbol whose print name is STRING= to
    
+the print name of the symbol that is the first argument to COPY-SYMBOL."
    
+ 
    
+Suggested implementation note:
    
+The string should not be copied unnecessarily. In this case, the uninterned
    
+symbol's print name would be EQ to the print name of the argument symbol.
    
+ 
    
+Rationale:
    
+ 
    
+This clarification resolves any possibility of ambiguity.
    
+ 
    
+Current Practice:
    
+ 
    
+Medley did this: the symbol names didn't really have a string header and
    
+some symbol names (the "initial symbols" ) had a different place for
    
+storing the actual characters than symbols created later. Unfortunately,
    
+that means that SYMBOL-NAME has to CONS.
    
+It wasn't so much a problem for Interlisp since most of the "string"
    
+functions in Interlisp will take symbols, but in Common Lisp, it is a
    
+performance hit. Poor design, but there's no reason to require SYMBOL-NAME
    
+to return EQ strings. 
    
+In this case, the strings aren't EQ even though the string characters are
    
+shared. (Think of it as strings displaced to a shared area.)
    
+ 
    
+ 
    
+Adoption Cost:
    
+ 
    
+?
    
+ 
    
+Benefits:
    
+ 
    
+Less ambiguity in the specification, and potentially more portable code.
    
+ 
    
+Conversion Cost:
    
+ 
    
+?
    
+ 
    
+Aesthetics:
    
+ 
    
+None.
    
+ 
    
+Discussion:
    
+ 
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089.htm new file mode 100644 index 00000000..ec76ab4c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089.htm @@ -0,0 +1,42 @@ + + + +CLHS: Issue DATA-IO:ADD-SUPPORT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DATA-IO:ADD-SUPPORT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DATA-IO:ADD-SUPPORT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089_w.htm new file mode 100644 index 00000000..aca4c7b7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss089_w.htm @@ -0,0 +1,296 @@ + + + +CLHS: Issue DATA-IO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DATA-IO Writeup

    + +
    This is a new issue.  It arose from an investigation of features
    
+that are plausibly needed but missing from draft ANSI Common Lisp.
    
+This issue seems sufficiently simple and noncontroversial that
    
+I would like to see it on the agenda for the June X3J13 meeting.
    
+
    
+This issue has been amended based on last minute discussion.  Clarify
    
+that "readable" is defined in terms of "similar as constants" as
    
+defined in issue CONSTANT-COMPILABLE-TYPES.  This modifies point 1a and
    
+adds new points 1d, 1e, and 1f.  The interaction between *PRINT-READABLY*
    
+and other printer control variables has been tightened; this modifies
    
+point 1c and deletes the old points 1d and 1e.
    
+
    
+Issue:          DATA-IO
    
+References:     CLtL pp.360, 370, 382
    
+Related issues: CONSTANT-COMPILABLE-TYPES
    
+Category:       ADDITION
    
+Edit history:   Version 1,  9-May-89, by Moon
    
+                Version 2, 10-May-89, by Moon
    
+                        (clarify ambiguities, add PRINT-UNREADABLE-OBJECT)
    
+                Version 3, 18-May-89, by Moon (respond to KMP's comments)
    
+                Version 4, 21-May-89, by Moon (almost-final cleanup)
    
+                Version 5, 22-May-89, by Pitman (``never say never'')
    
+                Version 6, 23-May-89, by Moon (final cleanup)
    
+                Version 7, 18-Jun-89, by Moon (more fixes based on
    
+                        discussion in the cleanup subcommittee)
    
+                Version 8, 23-Jun-89, by Moon (fixes based on discussion)
    
+
    
+Problem description:
    
+
    
+  Storing data in textual form in files, as Lisp expressions, is common
    
+  practice but has some pitfalls.  Files can be unreadable if #<...> syntax
    
+  is written by the printer, or if the reader syntax or package varies
    
+  between writing and reading.  Files of data intended to be carried from
    
+  one Lisp implementation to another can fail to read correctly if
    
+  implementation-dependent syntax extensions get used when not intended.
    
+
    
+  CLtL p.370 recommends that unreadable objects be printed with #<...>
    
+  syntax including implementation-dependent information.  Now that users
    
+  can write their own PRINT-OBJECT methods, a way is needed for such
    
+  methods to print this syntax without any implementation-dependent coding.
    
+
    
+Proposal (DATA-IO:ADD-SUPPORT):
    
+
    
+  1a. Add a new variable *PRINT-READABLY*.  Add a corresponding keyword
    
+  argument :READABLY to WRITE.  The default value of *PRINT-READABLY* is
    
+  NIL.  If *PRINT-READABLY* is true, then printing any object produces a
    
+  printed representation that the reader will accept.  The reader will
    
+  produce an object that is "similar as a constant" to the object that
    
+  was printed.  The term "similar as a constant" is defined in the
    
+  already accepted compiler issue CONSTANT-COMPILABLE-TYPES:SPECIFY.
    
+
    
+  If *PRINT-READABLY* is true and printing a readable printed
    
+  representation is not possible, the printer signals an error of type
    
+  PRINT-NOT-READABLE rather than using an unreadable syntax such as #<...>.
    
+  The printed representation produced when *PRINT-READABLY* is true might
    
+  or might not be the same as the printed representation produced when
    
+  *PRINT-READABLY* is false.
    
+
    
+  1b. All methods for PRINT-OBJECT must obey *PRINT-READABLY*.  This
    
+  includes both user-defined methods and implementation-defined methods.
    
+
    
+  1c. If *PRINT-READABLY* is true and another printer control variable
    
+  (*PRINT-LENGTH*, *PRINT-LEVEL*, *PRINT-ESCAPE*, *PRINT-GENSYM*,
    
+  *PRINT-ARRAY*, or an implementation-defined printer control variable)
    
+  would cause the requirements of point 1a to be violated, that other
    
+  printer control variable is ignored.
    
+
    
+  1d. The printing of interned symbols is not affected by *PRINT-READABLY*,
    
+  regardless of the outcome of issue COMPILE-FILE-SYMBOL-HANDLING
    
+  (referenced by issue CONSTANT-COMPILABLE-TYPES).
    
+
    
+  1e. Note that the "similar as a constant" rule for readable printing
    
+  implies that #A or #( syntax cannot be used for arrays of element-type
    
+  other than T.  An implementation will have to use another syntax or
    
+  signal a PRINT-NOT-READABLE error.  A PRINT-NOT-READABLE error will not
    
+  be signalled for strings or bit-vectors.
    
+
    
+  1f. Readable printing of structures and standard-objects is controlled
    
+  by their PRINT-OBJECT method, not by their MAKE-LOAD-FORM method.
    
+  "Similarity as a constant" for these objects is application dependent
    
+  and hence is defined to be whatever these methods do.
    
+
    
+  2. Add a new reader control variable, *READ-EVAL*, whose default value is
    
+  T.  If *READ-EVAL* is NIL, the #. reader macro signals an error.  If
    
+  *READ-EVAL* is false and *PRINT-READABLY* is true, any PRINT-OBJECT
    
+  method that would output a #. reader macro either outputs something
    
+  different or signals an error of type PRINT-NOT-READABLE.
    
+
    
+  3. Add a new macro:
    
+
    
+  WITH-STANDARD-IO-SYNTAX &body body                             [Macro]
    
+  
    
+    Within the dynamic extent of <body>, all reader/printer control
    
+    variables, including any implementation-defined ones not specified by
    
+    Common Lisp, are bound to values that produce standard read/print
    
+    behavior.  The values for Common Lisp specified variables are:
    
+
    
+      *PACKAGE*                            The USER package
    
+      *PRINT-ARRAY*                        T
    
+      *PRINT-BASE*                         10
    
+      *PRINT-CASE*                         :UPCASE
    
+      *PRINT-CIRCLE*                       NIL
    
+      *PRINT-ESCAPE*                       T
    
+      *PRINT-GENSYM*                       T
    
+      *PRINT-LENGTH*                       NIL
    
+      *PRINT-LEVEL*                        NIL
    
+      *PRINT-PRETTY*                       NIL
    
+      *PRINT-RADIX*                        NIL
    
+      *PRINT-READABLY*                     T
    
+      *READ-BASE*                          10
    
+      *READ-DEFAULT-FLOAT-FORMAT*          SINGLE-FLOAT
    
+      *READ-EVAL*                          T
    
+      *READ-SUPPRESS*                      NIL
    
+      *READTABLE*                          The standard readtable
    
+
    
+    The values returned by WITH-STANDARD-IO-SYNTAX are the values
    
+    of the last body form, or NIL if there are no body forms.
    
+
    
+  4. Add a new macro:
    
+
    
+  PRINT-UNREADABLE-OBJECT (object stream &key type identity)      [Macro]
    
+                           &body body
    
+
    
+    Output a printed representation of <object> on <stream>, beginning with
    
+    "#<" and ending with ">".  Everything output to <stream> by the <body>
    
+    forms is enclosed in the angle brackets.  If :type is true, the body
    
+    output is preceded by a brief description of the object's type and a
    
+    space character.  If :identity is true, the body output is followed by
    
+    a space character and a representation of the object's identity,
    
+    typically a storage address.
    
+
    
+    If *PRINT-READABLY* is true, PRINT-UNREADABLE-OBJECT signals an error
    
+    of type PRINT-NOT-READABLE without printing anything.
    
+
    
+    The <object>, <stream>, :type, and :identity arguments are all evaluated
    
+    normally.  :type and :identity default to false.  It is valid to omit
    
+    the <body> forms.  If :type and :identity are both true and there are no
    
+    <body> forms, only one space character separates the type and the identity.
    
+
    
+    The value returned by PRINT-UNREADABLE-OBJECT is NIL.
    
+
    
+  5. Add a new condition type:
    
+
    
+  PRINT-NOT-READABLE                                             [Type]
    
+
    
+    Errors which occur during output while *PRINT-READABLY* is true, as a
    
+    result of attempting to output a printed representation that cannot be
    
+    read back, should inherit from this type.  This is a subtype of ERROR.
    
+    The init keyword :OBJECT is supported to initialize the slot containing
    
+    the object being printed, which can be accessed using
    
+    PRINT-NOT-READABLE-OBJECT.
    
+
    
+Examples:
    
+
    
+  ;; Example #1: Reliable Write-Read
    
+
    
+  (WITH-OPEN-FILE (FILE pathname :DIRECTION :OUTPUT)
    
+    (WITH-STANDARD-IO-SYNTAX
    
+      (PRINT DATA FILE)))
    
+
    
+  ; ... Later, in another Lisp:
    
+
    
+  (WITH-OPEN-FILE (FILE pathname :DIRECTION :INPUT)
    
+    (WITH-STANDARD-IO-SYNTAX
    
+      (SETQ DATA (READ FILE))))
    
+
    
+  ;; Example #2: Use of PRINT-UNREADABLE-OBJECT
    
+  ;; Note that in this example, the precise form of the output
    
+  ;; is really implementation-dependent.
    
+
    
+  (DEFMETHOD PRINT-OBJECT ((OBJ AIRPLANE) STREAM)
    
+    (PRINT-UNREADABLE-OBJECT (OBJ STREAM :TYPE T :IDENTITY T)
    
+      (PRINC (TAIL-NUMBER OBJ) STREAM)))
    
+
    
+  (PRINT MY-AIRPLANE)
    
+  #<Airplane NW0773 36000123135>        ;in Implementation A
    
+  ;or
    
+  #<FAA:AIRPLANE NW0773 17>             ;in Implementation B
    
+
    
+Rationale:
    
+
    
+  1. *PRINT-READABLY* is important so that errors involving data with no
    
+  readable printed representation are detected when writing the file, not
    
+  later on when the file is read.
    
+
    
+  *PRINT-READABLY* is different from *PRINT-ESCAPE* because output printed
    
+  with escapes only has to be generally recognizable by humans, whereas
    
+  output printed readably has to be reliably recognizable by computers.
    
+
    
+  2. Binding *READ-EVAL* to NIL is useful when reading data that came from
    
+  an untrusted source, such as a network or a user-supplied data file, to
    
+  prevent the #. reader macro from being exploited as a "Trojan horse" to
    
+  cause arbitrary forms to be evaluated.
    
+
    
+  3. Providing the WITH-STANDARD-IO-SYNTAX macro to bind all the variables,
    
+  instead of using LET and explicit bindings of the existing variables,
    
+  ensures that nothing is overlooked and avoids problems with
    
+  implementation-defined reader/printer control variables.
    
+
    
+  If the user wishes to use a non-standard value for some variable, such as
    
+  *PACKAGE* or *READ-EVAL*, it can be bound by LET inside the body of
    
+  WITH-STANDARD-IO-SYNTAX.  Similarly, if the user dislikes the somewhat
    
+  arbitrary choices of values for *PRINT-CIRCLE* and *PRINT-PRETTY*, they
    
+  can be bound to the preferred values inside the body.
    
+
    
+  4. PRINT-UNREADABLE-OBJECT allows user-written PRINT-OBEJCT methods to
    
+  adhere to implementation-specific style without requiring users to write
    
+  implementation-dependent code.
    
+
    
+  5. Defining a specific condition type associated with *PRINT-READABLY*
    
+  makes it possible for programs to handle the condition and recognize
    
+  the offending object.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera has had these features for many years, except with
    
+  different names.  For instance, WITH-STANDARD-IO-SYNTAX is named
    
+  WITH-STANDARD-IO-ENVIRONMENT and binds *PACKAGE* to a non-standard
    
+  package.  The proposed new names are better than the Genera names.
    
+
    
+  Genera's WITH-STANDARD-IO-ENVIRONMENT also disables #., to prevent trojan
    
+  horses, since #. could evaluate an arbitrary form.  This is particularly
    
+  important for network protocols.  WITH-STANDARD-IO-SYNTAX does not bind
    
+  *READ-EVAL* to NIL, because that would prevent using #. in the printer
    
+  for common datatypes, which is current practice in some implementations
    
+  for printing PATHNAMEs or RANDOM-STATEs.
    
+
    
+  In Genera, PRINT-UNREADABLE-OBJECT is called SYS:PRINTING-RANDOM-OBJECT
    
+  and takes slightly different arguments. In PCL, PRINT-UNREADABLE-OBJECT
    
+  is called PCL:PRINTING-RANDOM-THING.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small, these features are all easy to add.  If #. is output by any
    
+  system-supplied print methods, they might want to invent a different
    
+  syntax, however that is not required by this proposal.
    
+
    
+Cost to Users:
    
+
    
+  None if they don't use the feature.  Otherwise just the cost of
    
+  supporting *PRINT-READABLY* or using PRINT-UNREADABLE-OBJECT in their
    
+  PRINT-OBJECT methods.
    
+
    
+Cost of non-adoption:
    
+
    
+  There will be no reliable, standard way to write data into a file.
    
+
    
+Performance impact:
    
+
    
+  Negligible.  Entering WRITE may be slightly slower since there is
    
+  one more keyword argument to parse and one more special variable
    
+  to bind before calling PRINT-OBJECT.
    
+
    
+Benefits:
    
+
    
+  Data can be written into files reliably without resorting to
    
+  implementation-specific programming.
    
+
    
+Esthetics:
    
+
    
+  Mildly improved.
    
+
    
+Discussion:
    
+
    
+  Pitman and Moon support this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090.htm new file mode 100644 index 00000000..438ef09e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090_w.htm new file mode 100644 index 00000000..71612094 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss090_w.htm @@ -0,0 +1,102 @@ + + + +CLHS: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED Writeup

    + +
    Issue:         DATA-TYPES-HIERARCHY-UNDERSPECIFIED
    
+
    
+References:    CLtL 33-35 (data types)
    
+	       CLtL 312 (DEFSTRUCT :INCLUDE option)
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  24-Mar-88, version 1 by Steele
    
+		 4-Sep-88, version 2 by X3J13 June 88
    
+
    
+Problem description:
    
+
    
+The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
    
+RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
    
+ARRAY, NUMBER, or CHARACTER.  The same is true of DEFSTRUCT types.  With
    
+the arrival of CLOS, lack of disjointness will be inconvenient because one
    
+cannot reliably use generic function dispatch on these types.
    
+
    
+
    
+Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
    
+
    
+Remove the third and antepenultimate bulleted items from section 2.15 is
    
+CLtL and replace with the following:
    
+
    
+  * The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
    
+  PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
    
+  by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
    
+
    
+Also, in the discussion of the DEFSTRUCT :INCLUDE option, it is an error for
    
+the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
    
+CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
    
+RANDOM-STATE.
    
+
    
+Rationale:
    
+
    
+It would be useful to extend sequence functions to operate on streams
    
+or hash tables, for example, through the CLOS generic function mechanism.
    
+This is not possible under the current specification.
    
+
    
+Current practice:
    
+
    
+Some implementations in effect use DEFSTRUCT to define data structures
    
+such as hash tables and random-states.
    
+
    
+Cost to Implementors:
    
+
    
+Small or nonexistent.  The main reason this disjointness was not specified
    
+in CLtL was the possibility that structures might not be easily
    
+distinguishable: a stupid concern over a slight efficiency.  This
    
+implementation freedom apparently has not been exploited in practice.
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+Cost of non-adoption:
    
+
    
+CLOS will be less useful.
    
+
    
+Benefits:
    
+
    
+CLOS will be more useful.
    
+
    
+Esthetics:
    
+
    
+This makes the type system simpler and easier to understand.
    
+
    
+Discussion:
    
+
    
+This suggestion originated in the CLOS committee.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091.htm new file mode 100644 index 00000000..1afcf83f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEBUGGER-HOOK-VS-BREAK:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEBUGGER-HOOK-VS-BREAK:CLARIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEBUGGER-HOOK-VS-BREAK:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091_w.htm new file mode 100644 index 00000000..4a0c573b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss091_w.htm @@ -0,0 +1,110 @@ + + + +CLHS: Issue DEBUGGER-HOOK-VS-BREAK Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEBUGGER-HOOK-VS-BREAK Writeup

    + +
    Issue:        DEBUGGER-HOOK-BREAK
    
+Forum:	      Editorial
    
+References:   BREAK (pp432-433), *DEBUGGER-HOOK* (Conditions, Rev18, p42)
    
+Category:     CHANGE
    
+Edit history: 01-Mar-91, Version 1 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  According to v18 of the Conditions Proposal (p42), when INVOKE-DEBUGGER 
    
+  is executed, ``If the variable *DEBUGGER-HOOK* is not NIL, it will be 
    
+  funcalled ...''
    
+
    
+  According to p432-433 of CLtL, when BREAK is called, ``A particular 
    
+  implementation may choose, according to its own style and needs, when
    
+  BREAK is called to go into a debugger different from the one used for 
    
+  handling errors.''
    
+
    
+  It isn't clear whether BREAK is affected by *DEBUGGER-HOOK*, or whether
    
+  it uses *DEBUGGER-HOOK* to implement any use of an alternate debugger.
    
+
    
+Proposal (DEBUGGER-HOOK-BREAK:CLARIFY):
    
+
    
+  1. Define the debugger implemented by BREAK is not affected by
    
+     the value of *DEBUGGER-HOOK* upon entry.
    
+
    
+  2. Define that BREAK binds the value of *DEBUGGER-HOOK* to NIL.
    
+
    
+Test Case:
    
+
    
+  (BLOCK FOO
    
+    (LET ((*DEBUGGER-HOOK* #'(LAMBDA (C D) (RETURN-FROM FOO NIL))))
    
+      (BREAK)))
    
+
    
+  enters a breakpoint rather than just returning NIL.
    
+
    
+Rationale:
    
+
    
+  1. BREAK's primary role is to provide access to Lisp debugging.
    
+     Anyone who wants to enter the debugger through *DEBUGGER-HOOK*
    
+     can use INVOKE-DEBUGGER.
    
+
    
+  2. *DEBUGGER-HOOK* provides an application/end-user-oriented 
    
+     debugging interface, while BREAK provides a Lisp debugging
    
+     interface.  Since BREAK will generally lead to the typing 
    
+     of Lisp expressions rather than application-specific commands,
    
+     it makes sense for the Lisp debugging environment to be visible
    
+     here rather than the application debugging environment.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera returns NIL from the test case and would have to change.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.  They just have to make BREAK bind *DEBUGGER-HOOK* to NIL
    
+  before doing anything else.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Users would not know what to expect when moving from implementation to
    
+  implementation.
    
+
    
+Benefits:
    
+
    
+  Less ambiguity in the spec.
    
+
    
+Aesthetics:
    
+
    
+  Negligible.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal, but would consider any reasonable 
    
+  alternative which made the expected behavior explicit.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092.htm new file mode 100644 index 00000000..b7aafbd4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DECLARATION-SCOPE:NO-HOISTING Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECLARATION-SCOPE:NO-HOISTING Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DECLARATION-SCOPE:NO-HOISTING:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092_w.htm new file mode 100644 index 00000000..ec7696f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss092_w.htm @@ -0,0 +1,384 @@ + + + +CLHS: Issue DECLARATION-SCOPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECLARATION-SCOPE Writeup

    + +
    Proposal DECLARATION-SCOPE:NO-HOISTING was accepted at the January 1989 meeting.
    
+
    
+Issue:         DECLARATION-SCOPE
    
+
    
+References:    Declaration Syntax (CLtL, Section 9.1, pp. 153-157)
    
+	       LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66)
    
+               Cleanup issue FLET-DECLARATIONS (accepted)
    
+               Cleanup issue DECLARE-TYPE-FREE (accepted)
    
+
    
+Category:      CHANGE/CLARIFICATION
    
+
    
+Edit history:  V1: Hornig@Symbolics.COM -- 5 January 1988
    
+               Version 2, Moon, 2-Feb-1988 (edits based on discussion)
    
+               Version 3, Moon, 18-Sep-88, for private discussion between JonL and Moon
    
+               Version 4, JonL, 15-Nov-88 add 2nd proposal; major rewrite.
    
+
    
+
    
+Problem description:
    
+
    
+The description of the scope of declarations made with DECLARE is 
    
+unclear (although unambiguous) and arguably a mistake.  At issue is
    
+whether the scope of some or all of the declarations at the head of
    
+a special form includes code appearing in any non-body part of that 
    
+special form.  CLtL p.155 attempts to address the issue by classifying 
    
+declarations into two classes -- "pervasive" and "non-pervasive" -- but 
    
+it does not succeed very well.
    
+
    
+A particular question of interest is whether the initial value forms for 
    
+LET, LET*, FLET, LABELS, DO, PROG etc. are included.  The rules of CLtL,
    
+on some cases, are clear enough to see that a declaration inside the 
    
+special form is "hoisted" up and around the whole form, so as to include 
    
+all the "initial value" forms (and "stepper" forms and "result" forms for 
    
+those constructs that have them).  This means that lexical argument 
    
+variable X in the following function is inaccessible inside the initial 
    
+value forms of the LET:
    
+  (defun bar (x y)	    ;[1] 1st instance of x
    
+    (let ((old-x x)	    ;[2] 2nd instance of x -- same as 1st instance?
    
+	  (x y))	    ;[3] 3rd instance
    
+      (declare (special x))
    
+      (list old-x x)))
    
+The declaration intended for the binding of X[3] also alters the
    
+scoping of the reference of X[2]; likely, this was not an intended 
    
+consequence. [This is a simplification of the example on CLtL p.155].
    
+
    
+In this discussion, the term "body" will include any "stepper" or 
    
+"result" forms, such as might be found in a DO or DO-mumble-SYMBOLS
    
+construct.  The reasoning for this is that such forms are always 
    
+included in the scope of all name bindings (if any) being established 
    
+by the special form.  They form an extended part of the "body".
    
+
    
+
    
+
    
+Proposal (DECLARATION-SCOPE:NO-HOISTING)
    
+
    
+Specify that the scope of a declaration located at the head of a special 
    
+form or lambda expression is as follows:
    
+  (1) it always includes the body forms [as well as any "stepper" or 
    
+      "result" forms]
    
+  (2) it also includes the scope of the name binding, if any, to which 
    
+      it applies [LET, LAMBDA, FLET, DO, etc. introduce "name bindings"; 
    
+      LOCALLY doesn't.];
    
+
    
+This very straightforward prescription depends on one rather subtle
    
+point, namely that the scope of name bindings is an already solved
    
+question.  Whether or not a particular declaration affects an initial
    
+value form (such as for LET or LET*) depends _solely_ on whether it is
    
+applied to a variable or function (name) being bound whose scope
    
+includes such forms.  In this sense, the above specification limits the
    
+scope of declarations for name bindings to be exactly the scope of the
    
+name binding itself -- i.e. "like variable".  Thus there would be no
    
+"hoisting" of the special declarations in the example cited in the
    
+problem description.  [See the Discussion section for a review of the 
    
+CL rules on variable/function-name scoping in special forms.]
    
+
    
+Those declarations not correlated with any name binding do not cover any
    
+of the initial-value forms; their scope simply includes the body (as well 
    
+as any "stepper" or "result" forms).  In a sense, the above specification 
    
+limits the scope of these kinds of declarations to be the same as an
    
+arbitrary name binding in a LET or FLET construct -- i.e. "like variable".
    
+[See also the issue DECLARE-TYPE-FREE.]
    
+
    
+Thus there is to be no "hoisting" for declarations in special forms or 
    
+lambda expressions; the only initial value forms affected by a declaration 
    
+will be those included indirectly, by the effect, if any, that a 
    
+declaration has on a name binding. 
    
+
    
+A question may arise as to what it means for a declaration to "apply to", 
    
+or "be correlated to" a name binding.  As stated above about variable
    
+scoping, this is an already solved question in Common Lisp; it is not 
    
+the purpose of this proposal to alter, clarify or in any other way bear 
    
+upon the basic _applicability_ rules of declarations in Common Lisp.  
    
+However, a few reminders about these rules will help one understand the 
    
+above specification:
    
+  --  SPECIAL and TYPE declarations never apply to function bindings;
    
+  --  INLINE and FTYPE declarations never apply to variable bindings; 
    
+  --  OPTIMIZE never applies to either kind of binding;
    
+  --  (<declaration> X) never applies to a binding of Y.
    
+The specific rules are for the most part distributed throughout the 
    
+individual declaration definitions.  The name-applicibility issue for 
    
+bindings must be specified independently of how the declaration scoping 
    
+issue is decided, and should not be confused with that scoping issue.
    
+
    
+
    
+
    
+Proposal (DECLARATION-SCOPE:LIMITED-HOISTING)
    
+
    
+Specify that the scope of a declaration located at the head of a special 
    
+form or lambda expression is as follows:
    
+  (1) it always includes the body forms [as well as any "stepper" or 
    
+      "result" forms]
    
+  (2) if the declaration is applicable to a name binding in that form,
    
+      then it is limited to exactly the scope of that name binding [LET, 
    
+      LAMBDA, FLET, etc. introduce "name bindings"; LOCALLY doesn't.];
    
+  (3) if the declaration is not applicable to a name binding in that form,
    
+      then it includes all the initial value forms, in addition to the
    
+      body forms.
    
+
    
+This very straightforward prescription depends on one rather subtle 
    
+point, namely that the scope of name bindings is an already solved 
    
+question.  This applies not only to LET and LET* variables, but to the 
    
+&optional, &key and &aux variables of LAMBDA-Expressions.  In this sense, 
    
+the above specification limits the scope of declarations for name bindings 
    
+to be exactly the scope of the name binding itself.  Thus there would be 
    
+no "hoisting" of the special declarations in the example cited in the
    
+problem description.
    
+
    
+Those declarations not correlated with any name binding act as if they
    
+were included in a new LOCALLY construct wrapped around the entire
    
+special form.  Thus they are not scoped like an arbitrary variable
    
+(or, "name binding") in that special form, but rather are "hoisted" up.
    
+
    
+Whether or not a declaration is "hoisted" up around the special form in 
    
+which it occurs depends on whether or not it is "captured en passant" by 
    
+a correlated name binding.
    
+
    
+A question may arise as to what it means for a declaration to "apply to", 
    
+or "be correlated to" a name binding.  As stated above about variable
    
+scoping, this is an already solved question in Common Lisp; it is not 
    
+the purpose of this proposal to alter, clarify or in any other way bear 
    
+upon the basic _applicability_ rules of declarations in Common Lisp.  
    
+However, a few reminders about these rules will help one understand the 
    
+above specification:
    
+  --  SPECIAL and TYPE declarations never apply to function bindings;
    
+  --  INLINE and FTYPE declarations never apply to variable bindings; 
    
+  --  OPTIMIZE never applies to either kind of binding;
    
+  --  (<declaration> X) never applies to a binding of Y.
    
+The specific rules are for the most part distributed throughout the 
    
+individual declaration definitions.  The name-applicibility issue for 
    
+bindings must be specified independently of how the declaration scoping 
    
+issue is decided, and should not be confused with that scoping issue.
    
+
    
+
    
+Examples:
    
+
    
+;;; The following example is from a common-lisp mailing list discussion
    
+;;;  (from code suggested by Pavel Curtis).   The question is whether or
    
+;;;  not the special declaration in FOO applies to the  (1+ x) form.
    
+
    
+(setf (symbol-value 'x) 6)
    
+(defun foo (x)				;a lexical binding of X
    
+  (print x)
    
+  (let ((x (1+ x)))			;is the second X special or not?
    
+    (declare (special x))		;`normal' declaration
    
+    (bar))
    
+  (1+ x))
    
+(defun bar () (print (locally (declare (special x)) x)))
    
+
    
+(foo 10)  will  printout of 10 and 11 by either proposal herein
    
+(foo 10)  will  printout of 10 and 7 by CLtL style "hoisting"
    
+
    
+
    
+;;; The following example is due to Jim Boyce, of Lucid Inc.  It shows how
    
+;;;  the "hoisting" of the declaration inadvertently causes it to act more
    
+;;;  like a proclamation than a declaration; namely, the declaration is
    
+;;;  applied to two different variables (which happen to have the same
    
+;;;  name) -- the first variable is the lexical one bound on line [1] and
    
+;;;  the second variables is bound on line [3].  Whereas lexical scoping
    
+;;;  rules would say that the reference in line [2] is to the variable
    
+;;;  bound on line [1], the effect of the "hoisted" declaration is to
    
+;;;  make the line [1]'s variable inaccessible in the initial value forms.
    
+
    
+(setf (symbol-value 'x) 6)
    
+
    
+(defun bar (x y)	    ;[1] 1st instance of x
    
+  (let ((old-x x)	    ;[2] 2nd instance of x -- same as 1st instance?
    
+        (x y))		    ;[3] 3rd instance
    
+    (declare (special x))
    
+    (list old-x x)))
    
+
    
+(bar 'first 'second)	==>  (first second)    ;by either proposal herein
    
+(bar 'first 'second)	==>  (6 second)        ;by "hoisting", a la CLtL.
    
+
    
+
    
+Rationale:
    
+
    
+These semantics are simpler to understand.  Almost everyone feels that
    
+the example of CLtL p.155 is very unnatural.  LIMITED-HOISTING is less 
    
+of a change to CLtL semantics; but NO-HOISTING seems more natural to 
    
+most people since it restores a closer equivalence between LET forms 
    
+and LAMBDA-expressions.  Also, several vendors report that customers 
    
+frequently seem to assume the semantics of NO-HOISTING.
    
+
    
+
    
+Current practice:
    
+
    
+Most implementations implement the rules in CLtL, as exemplified by
    
+the example on p.155.  Symbolics currently implements rules based on
    
+Zetalisp which are different from both this proposal and Common Lisp.
    
+Symbolics plans to change to Common Lisp rules in the future.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Modest; some minor fixes will be necessary to to compilers, interpreters 
    
+and "code walkers" that parse declarations.
    
+
    
+
    
+Cost to Users:
    
+
    
+Modest.  It is mostly moot since users tend to avoid the "hoisting"
    
+situations on special declarations.
    
+
    
+It is possible to mechanically examine a program to determine whether
    
+its behavior would change under the new rules.  This permits an
    
+implementation to provide a transition tool to ease conversion to the
    
+new definition.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+Serious non-portability of code, since not every implementor seems to 
    
+agree on how to read the disputed rules of CLtL pp. 153-157; continuing
    
+confusion in the user community.
    
+
    
+
    
+Performance impact:
    
+
    
+None.
    
+
    
+Benefits:
    
+
    
+Elimination of confusion; increase of portability between implementations.
    
+
    
+
    
+Esthetics:
    
+
    
+Simplifies the scoping issue; eliminates special-case scoping rules for
    
+SPECIAL declarations.
    
+
    
+
    
+
    
+Discussion:
    
+
    
+Only the SPECIAL declaration has semantic import for CL; both
    
+proposals specify an incompatible change for this case, to "retract"
    
+the expansive scope stated or implied in CLtL.  All other declarations
    
+are considered "advice" to an optimizing compiler, and should have
    
+no semantic effect on correct programs.  However, programmers making
    
+use of such declarations may notice a larger difference in the
    
+NO-HOISTING proposal, since some of their INLINE, OPTIMIZE, TYPE,
    
+etc. declarations will no longer apply to the initial-value forms.
    
+
    
+
    
+One idiom which will be adversely affected by both of these proposals is:
    
+   (let ((*a* *a*))
    
+     ;; rebind *a* to it's "old" value
    
+     (declare (special *a*))
    
+     ...)
    
+where *a* has not been proclaimed special.  This idiom would likely
    
+have to be written as:
    
+   (let ((*a* (locally (declare (special *a*)) *a*)))
    
+     ;; rebind *a* to it's "old" value
    
+     (declare (special *a*))
    
+     ...)
    
+or [preferably!] *a* should be proclaimed special.  Similar idiots 
    
+like this may be in use for LAMBDA-Expressions, or DEFUNs etc.
    
+
    
+
    
+On the other hand, the inadvertent "shadowing" which prevents the 
    
+following LET's initial value forms from referencing the input argument
    
+is handily solved by either proposal herein.  If neither of these 
    
+proposals is not adopted, then the intent of the code for BAR:
    
+  (defun bar (x y)	      ;[1] 1st instance of x
    
+    (let ((old-x x)	      ;[2] 2nd instance of x -- same as 1st instance?
    
+	  (x y))	      ;[3] 3rd instance
    
+      (declare (special x))
    
+      (list old-x x)))
    
+would likely have to be expressed by introducing new LET contours:
    
+  (defun bar (x y)	      ;[1] 1st instance of x
    
+    (let ((old-x x))	      ;[2] 2nd instance of x -- same as 1st instance?
    
+      (let ((x y))	      ;[3] 3rd instance
    
+        (declare (special x))
    
+        (list old-x x))))
    
+
    
+
    
+The source of additional confusion  has long been that TYPE declarations 
    
+had to be treated differently from all other declarations; this was because 
    
+of the prohibition found on p158 of CLtL.  Given the acceptance of the
    
+DECLARE-TYPE-FREE proposal, it no longer is necessary to make an exception 
    
+for it, nor to categorize declarations into "pervasive" and "non-pervasive", 
    
+or  "free" and "bound".
    
+
    
+
    
+It is not the purpose of this proposal to alter, clarify or in any 
    
+other way bear upon the scoping rules of variables in Common Lisp.
    
+However, a few reminders about these rules will help one understand 
    
+the above prescription.  Except LET*, PROG*, DO*, LABELS, and MACROLET,
    
+all the other special forms of CLtL p154 which admit declarations have 
    
+the property that the scope of the name binding does not include any
    
+initial value form.  As a review of these scopes, note:
    
+  -- for LET, FLET, MULTIPLE-VALUE-BIND, none of the initial value 
    
+     forms are included in the variables' (or functions') scope;
    
+  -- for DO-<mumble>-SYMBOLS, the initial value forms are not included,
    
+     but the optional result forms are included;
    
+  -- for DO, DOLIST, and DOTIMES, the initial value forms are not 
    
+     included, but the stepper forms and the optional result forms 
    
+     are included;
    
+  -- for LET*, PROG*, and DO*, a variable's scope also includes the 
    
+     remaining initial value forms, for subsequent variable bindings;
    
+  -- for LABELS and MACROLET, a function name's scope includes all the 
    
+     code forms for the functions being defined by the special form 
    
+     [a compiler writer must know how not to get into an infinite loop 
    
+     of substitutions when there are 'in-line' declarations on these 
    
+     mutually recursive names];
    
+  -- for a LAMBDA application, none of the explicit value forms are  
    
+     included in the bound variable scoping;  however, the 'initform'
    
+     code (if any) for &optional, &key, and &aux bindings are included 
    
+     in the same way as LET* does;
    
+  -- for DEFUN, DEFMACRO, DEFTYPE and DEFSETF follow the rules for
    
+     LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66).
    
+     
    
+Remember also that new name bindings "shadow" (after a fashion) any 
    
+higher level binding or declarations.  E.g., presuming that no 
    
+proclamations are in effect, consider the inner let bindings of:
    
+   (locally (declare (special x) (float y)) 
    
+     (let ((x 5) (y 10)) 
    
+       (print (+ x y))))
    
+then x is bound as local (not special); and y is bound with no particular
    
+type information [because the 'y' being bound is a different variable
    
+than the 'y' declared float in the outer scope].
    
+
    
+
    
+It has been suggested that compilers could be a bit more helpful in 
    
+detecting anomalous bindings, such as in the LET* following:
    
+  (defun bar (x y)
    
+    (let* ((old-x x)
    
+           (x y)
    
+           (new-x x))
    
+      (declare (special x))
    
+      (list old-x x new-x)))
    
+The collection of variables named X in the LET* binding and initial
    
+forms includes both local (lexical) and special ones.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093.htm new file mode 100644 index 00000000..28dabf64 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093_w.htm new file mode 100644 index 00000000..6583eb21 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss093_w.htm @@ -0,0 +1,149 @@ + + + +CLHS: Issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES Writeup

    + +
    Status:	Passed, Jan 89 X3J13
    
+
    
+Issue:         DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
    
+
    
+References:    Array type specifiers, pp. 45-46
    
+
    
+Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE,
    
+                SYMBOL-MACROLET-DECLARE
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1,  7-Oct-88, Pierson
    
+               Version 2, 13-Jan-89, Pierson (Moon and JonL comments)
    
+    	       Version 3, 13-Jan-89, Pierson (Pitman comments)
    
+
    
+Problem description:
    
+
    
+In principle, array type specifiers could be used both for declaring
    
+the storage format of the array and for implicitly declaring the types
    
+of the elements held by those arrays. Unfortunately, the current 
    
+definition of the meaning of array type specifiers does not explicitly
    
+specify that the latter use of these declarations is legitimate.
    
+
    
+Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
    
+
    
+Within the lexical scope of an array type declaration, all references
    
+to array elements are assumed to satisfy the exact declared element
    
+type.  It is an error if this is ever violated.  A compiler may treat
    
+the code within the scope of the array type declaration as if each
    
+access of an array element was surrounded by an appropriate THE form.
    
+
    
+Examples:
    
+
    
+(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
    
+(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
    
+
    
+(DEFUN FROB (AN-ARRAY)
    
+  (DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
    
+  (SETF (AREF AN-ARRAY 1) 31)		; OK
    
+  (SETF (AREF AN-ARRAY 2) 127)		; Should signal an error
    
+  (SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
    
+  (LET ((FOO 0))
    
+    (DECLARE (TYPE (SIGNED-BYTE 5) FOO))
    
+    (SETF FOO (AREF AN-ARRAY 0))))	; Declared to be safe
    
+
    
+(FROB *ONE-ARRAY*)			; Legal call, should signal an error
    
+(FROM *ANOTHER-ARRAY*)			; Is probably an undetectable error
    
+
    
+Note that the above definition of FROB is equivalent to:
    
+
    
+(DEFUN FROB (AN-ARRAY)
    
+  (DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
    
+  (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
    
+  (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
    
+  (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
    
+	(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
    
+  (LET ((FOO 0))
    
+    (DECLARE (TYPE (SIGNED-BYTE 5) FOO))
    
+    (SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
    
+
    
+Given an implementation in which fixnums are 29 bits but fixnum arrays
    
+are upgraded to signed 32-bit arrays, the following should be compiled
    
+with all fixnum arithmetic:
    
+
    
+(DEFUN BUMP-COUNTERS (COUNTERS)
    
+  (DECLARE (TYPE (ARRAY FIXNUM *) BUMP-COUNTERS))
    
+  (DOTIMES (I (LENGTH COUNTERS))
    
+    (INCF (AREF COUNTERS I))))
    
+
    
+Test Cases:
    
+
    
+TBS
    
+
    
+Rationale:
    
+
    
+This mandates a useful and commonly expected behavior.  It complements
    
+proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
    
+type specifiers as they refer to arrays as a whole.  
    
+
    
+This proposal is consistent with SYMBOL-MACROLET-DECLARE:ALLOW and
    
+DECLARATION-SCOPE:LEXICAL.
    
+
    
+Current practice:
    
+
    
+???
    
+
    
+Cost to Implementors:
    
+
    
+TBS
    
+
    
+Cost to Users:
    
+
    
+Probably none; while this is technically a change, code that declares
    
+an array to contain one thing and depends on it containing something
    
+else is blatantly buggy.
    
+
    
+Cost of non-adoption:
    
+
    
+Users will continue to expect declaration syntax to be more useful
    
+than it really is.
    
+
    
+Performance impact:
    
+
    
+None.
    
+
    
+Benefits:
    
+
    
+Array type declarations will behave in a more useful and intuitive way.
    
+
    
+Aesthetics:
    
+
    
+Improved because the meaning of type declarations will coincide more
    
+clearly with their appearance.
    
+
    
+Discussion:
    
+
    
+Pierson and Pitman support this proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094.htm new file mode 100644 index 00000000..66735861 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094_w.htm new file mode 100644 index 00000000..b66a2630 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss094_w.htm @@ -0,0 +1,143 @@ + + + +CLHS: Issue DECLARE-FUNCTION-AMBIGUITY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECLARE-FUNCTION-AMBIGUITY Writeup

    + +
    Forum:        Cleanup
    
+Issue:        DECLARE-FUNCTION-AMBIGUITY
    
+
    
+References:   CLtL pp 43 (Table 4-1), 158-159
    
+		Issue FUNCTION-TYPE (passed X3J13/June 1988)
    
+
    
+Category:     CHANGE
    
+
    
+Edit history: #1, 21 Sept 1988, Walter van Roggen
    
+              #2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
    
+              #3, 30-Sep-88, Masinter
    
+              #4,  5-Dec-88, Masinter (append Oct x3j13 comments)
    
+
    
+Problem description:
    
+
    
+CLtL permits confusing and ambiguous FUNCTION declarations.  One can say
    
+  (DECLARE (FUNCTION F (VECTOR INTEGER) T))
    
+to indicate that the function binding for F is of a certain type.  Yet
    
+one can also say
    
+  (DECLARE (FUNCTION X Y Z))
    
+to indicate that the variables X, Y, and Z have values which are functions.
    
+
    
+The former is an abbreviation for
    
+  (DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
    
+The latter is an abbreviation for
    
+  (DECLARE (TYPE FUNCTION X Y Z))
    
+
    
+The ambiguity arises in a case like
    
+  (DECLARE (FUNCTION F NIL STRING))
    
+However, it would be an error to declare the type of the constant NIL to be a
    
+FUNCTION, so technically there is no ambiguity--there is just a peculiar
    
+special case.
    
+
    
+Using the same declaration for two completely different purposes can lead
    
+ to confusion among people writing or reading such code.
    
+
    
+It is now more useful to declare that variables have a value which
    
+is of type FUNCTION, since the type FUNCTION has a more well-specified
    
+meaning.
    
+
    
+Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
    
+
    
+The declaration (FUNCTION name argtypes valtypes) is no longer permitted
    
+to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
    
+
    
+The declaration (FUNCTION var1 var2) would just be an abbreviation for
    
+(TYPE FUNCTION var1 var2).
    
+
    
+Rationale:
    
+
    
+Continuing to allow all the predefined atomic type specifiers as declaration
    
+abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
    
+In other words, all the normal type declarations describe variable bindings;
    
+only the FTYPE declaration describes function bindings.  This is a more
    
+uniform solution than making an exception to table 4-1.
    
+
    
+Since the old use of the FUNCTION declaration for function bindings was just
    
+an abbreviation for the FTYPE declaration, no expressivity is lost.
    
+Furthermore one is able to say that a variable's value is of type FUNCTION,
    
+something that hadn't been clearly possible without using the TYPE declaration.
    
+
    
+Current Practice:
    
+
    
+Many current implementations treat FUNCTION declarations 
    
+only as abbreviations for FTYPE declarations, primarily because
    
+the proposal FUNCTION-TYPE has not been widely implemented.
    
+
    
+Cost to Implementors:
    
+
    
+Likely to be small to those implementations that heed these kinds of
    
+declarations; none for those that don't.
    
+
    
+Cost to Users:
    
+
    
+Existing uses of the FUNCTION declaration for function bindings will need
    
+to be changed to FTYPE declarations.
    
+
    
+Cost of Non-Adoption:
    
+
    
+People will continue to be confused by function declarations.
    
+
    
+Benefits:
    
+
    
+A simpler language.
    
+
    
+Esthetics:
    
+
    
+
    
+Discussion:
    
+
    
+Making it clear that only FTYPE declarations describe function bindings will
    
+make it easier to add new kinds of declarations that support incremental or
    
+additional descriptions, as is needed for describing methods.
    
+
    
+Since all cases can be disambiguated after all, compatibility considerations
    
+might deem this proposal to be unnecessary.  However, making declarations
    
+simpler and less confusing is possibly more important than compatibility.
    
+
    
+There is no consensus on the cleanup committee.
    
+
    
+Comments from October 1988 X3J13 meeting:
    
+
    
+...    opposed but not vehemently--the incompatible change is gratuitous
    
+...    prefer to document the
    
+	 issue rather than change it."
    
+...    a number of implementations accidentally implement
    
+   	 this incorrectly. They first check the type table and then handle
    
+	 the elaborate function declaration style. But, as it happens,
    
+	 they never reach the code for the second case because function is
    
+	 in the type table!
    
+...    Having both styles is worse than having either one or the other.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095.htm new file mode 100644 index 00000000..c48440c5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DECLARE-MACROS:FLUSH Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECLARE-MACROS:FLUSH Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DECLARE-MACROS:FLUSH:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095_w.htm new file mode 100644 index 00000000..7e60ab65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss095_w.htm @@ -0,0 +1,242 @@ + + + +CLHS: Issue DECLARE-MACROS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECLARE-MACROS Writeup

    + +
    Issue:        DECLARE-MACROS 
    
+References:   Declaration Syntax (p154)
    
+Category:     CHANGE
    
+Edit history: 22-Oct-87, Version 1 by Pitman
    
+               9-Nov-87, Version 2 by Masinter
    
+               5-Feb-88, Version 3 by Pitman
    
+
    
+Problem Description:
    
+
    
+  It is permissible for a macro call to expand into a declaration and be
    
+  recognized as such. This linguistic feature provides some useful
    
+  flexibility, but has a number of disadvantages:
    
+
    
+  * Operations on the executable portion of a body of code inside a 
    
+    binding form (such as inserting an additional form) is a complicated
    
+    operation. This is because one or more trial macro expansions must be
    
+    done in order to pass over any declarations or documentation string
    
+    and find the beginning of the body.
    
+
    
+  * In order to find the end of the declarations, MACROEXPAND must be
    
+    called until a non-macro form is seen or until a macro does not expand
    
+    into a macro. In some interpreters which do macro expansion on the fly,
    
+    this may cause inefficiency because macro expansion of the first form
    
+    in a body must be done twice. In implementations where this is 
    
+    optimized, the implementor may resent the fact that an optimization is
    
+    needed in the first place.
    
+
    
+  * Various code analysis tools have been shown to have been significantly
    
+    slowed down by the need to expand macros in order to determine whether
    
+    a binding is SPECIAL when analyzing a variable binding form. This is
    
+    particularly serious when macro invocations are deeply nested; the
    
+    number of macro expansions can be exponential in the depth of nesting
    
+    unless a macro-expansion caching mechanism is added. 
    
+
    
+  * User macros must be very careful about finding declarations in a body
    
+    of code by doing proper macro expansion. Often, however, naive users
    
+    don't realize this and so unknowingly write buggy code. This problem can
    
+    be (and is) defined away as simply a programmer error, but this is a
    
+    place where we could fairly straightforwardly redefine the language to
    
+    better accommodate what has been shown to be a common expectation of the
    
+    naive user.
    
+
    
+Proposal (DECLARE-MACROS:FLUSH):
    
+
    
+   Under this proposal, it would not be "permissible for a macro call to
    
+   expand into a declaration and be recognized as such, provided that the
    
+   macro call appears where a declaration may legitimately appear." (CLtL
    
+   p. 154). Macros could not legitimately expand into declarations; the only
    
+   valid declarations would be a list whose CAR is the symbol DECLARE.
    
+
    
+   It would still be possible for a macro call to expand into a PROCLAIM
    
+   form, however.
    
+
    
+Rationale:
    
+
    
+  The ability to have a macro form expand into a declaration has been shown
    
+  to be useful in some situations.  More often, however, the presence of
    
+  this feature has been seen to cause problems elsewhere in the language.
    
+  Ultimately, its benefits have not outweighed its costs.
    
+
    
+Current Practice:
    
+
    
+  Most or all implementations support the old behavior even though few
    
+  user programs probably need it.
    
+
    
+  Some user macros are careful about finding declarations in a body of code
    
+  by doing proper macro expansion, but some probably cheat and look just
    
+  for explicit uses of DECLARE. The cheat probably works most of the time.
    
+
    
+Cost to implementors:
    
+
    
+  The nature of this change is such that implementations which did not
    
+  choose to change would simply be supporting an implementation-dependent
    
+  extension (except for some `minor' worry about destructive modification
    
+  due to macro expanding while *MACROEXPAND-HOOK* is set to something
    
+  which implemented displacing macros).
    
+
    
+  In any case, there might be several places in which the interpreter,
    
+  compiler, and system macros had knowledge about doing macro expansion
    
+  before declaration processing. The change is not trivial, but most of
    
+  its complexity is likely to be in finding the places which need change
    
+  and not in making the actual change.
    
+
    
+Cost to users:
    
+
    
+  Most users probably do not write macros which expand into DECLARE forms
    
+  so most users are probably not affected.
    
+
    
+  Users who do exploit this feature probably know that they do. In any
    
+  case, compilers could be made to detect cases where this feature is
    
+  being exploited and warn about it.
    
+
    
+  Franz and Gold Hill are notable exceptions to the claim that users may
    
+  not want this. Both claim to make a reasonable amount of use of macros
    
+  which expand into different SPEED and SAFETY declarations, usually
    
+  dependent on a global switch.
    
+
    
+  Rewrites must be devised on a case-by-case basis. A common sort of
    
+  rewrite would take the form:
    
+
    
+   Old code:  (DEFMACRO SPEEDY ()
    
+		`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0))))
    
+   	      (LET (..bindings..) (SPEEDY) ..body..)
    
+
    
+   New code:  (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
    
+		`(LET ,BVL
    
+		   (DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
    
+		   ,@FORMS))
    
+	      (SPEEDY-LET (..bindings..) ..body..)
    
+
    
+  Another tactic would be:
    
+
    
+   Old code: (EVAL-WHEN (EVAL COMPILE LOAD)
    
+	       (DEFVAR *SPEEDY* NIL))
    
+	     (DEFMACRO USE-STANDARD-SPEED-AND-SAFETY ()
    
+	       (IF *SPEEDY*
    
+		   `(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
    
+		   `(DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))))
    
+	     (DEFUN FOO ()
    
+	       (USE-STANDARD-SPEED-AND-SAFETY)
    
+	       ...)
    
+   New code: (EVAL-WHEN (EVAL COMPILE LOAD)
    
+	       (DEFVAR *STANDARD-SPEED-AND-SAFETY* '((SPEED 0) (SAFETY 3))))
    
+	     (DEFUN FOO ()
    
+	       (DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*))
    
+	       ...)
    
+
    
+  Still a third tactic would be to actually shadow DEFUN, LET, etc. with
    
+  variants that process macro expansions and then to build code in a
    
+  package that used the revised DEFUN, LET, etc. eg,
    
+
    
+    (DEFUN PARSE-BODY (BODY ENV)
    
+      (LET ((DECLS '())
    
+	    (DOC   '()))
    
+	(DO () ((NULL (CDR BODY)))
    
+	  (LET ((EXP (MACROEXPAND (POP BODY) ENV)))
    
+	    (COND ((AND (STRINGP EXP) BODY)
    
+		   (UNLESS (NULL DOC)
    
+		     (WARN "More than one documentation string was seen."))
    
+		   (PUSH EXP DOC))
    
+		  ((AND (NOT (ATOM EXP)) (EQ (CAR EXP) 'DECLARE))
    
+		   (PUSH EXP DECLS))
    
+		  (T
    
+		   (PUSH EXP BODY)
    
+		   (RETURN NIL)))))
    
+	(VALUES BODY (NREVERSE DECLS) (NREVERSE DOC))))
    
+
    
+   (DEFMACRO MY:DEFUN (NAME LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
    
+		       &ENVIRONMENT ENV)
    
+     (MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
    
+	 (PARSE-BODY DECLS-DOC-AND-FORMS ENV)
    
+       `(DEFUN ,NAME ,BVL ,@DECLS ,@DOC-STRINGS ,@FORMS)))
    
+
    
+   (DEFMACRO MY:LET (BINDINGS &BODY DECLS-DOC-AND-FORMS
    
+		     &ENVIRONMENT ENV)
    
+     (MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
    
+	 (PARSE-BODY DECLS-DOC-AND-FORMS ENV)
    
+       `(LET ,BINDINGS ,@FORMS)))
    
+
    
+   ...etc.
    
+
    
+  LAMBDA cannot be done this way, of course, since it is not a macro (or
    
+  even a special form). Support for expanding declarations in a LAMBDA
    
+  would have to be provided either by using implementation-specific support
    
+  (such as Zetalisp's ``lambda macros'') or by a workaround such as a
    
+  macro like:
    
+
    
+   (DEFMACRO LAMBDA (LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
    
+		     &ENVIRONMENT ENV)
    
+     (MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
    
+	 (PARSE-BODY DECLS-DOC-AND-FORMS ENV)
    
+       `#'(LAMBDA ,BINDINGS ,@FORMS)))
    
+
    
+  Note that unlike the other examples, LAMBDA need not be (and in fact,
    
+  may not be) in the "MY" package in order for this to work since the
    
+  FUNCTION special form will generally only recognize LISP:LAMBDA.
    
+
    
+Benefits:
    
+
    
+  The efficiency of some tools may be improved.
    
+  User macros which must do minor surgery on bodies of code will be
    
+  easier to write.
    
+
    
+Aesthetics:
    
+
    
+  This change simplifies the semantics of the language slightly and
    
+  probably tends to better support the assumptions of naive programmers
    
+  writing macros.
    
+
    
+  In some cases involving complicated extensions to declarations, it
    
+  may be slightly harder to express such extensions in a modular way.
    
+  Experience thus far has shown such cases to be rare, however.
    
+
    
+Discussion:
    
+
    
+  Symbolics took an in-house poll of people who take advantage of the
    
+  feature and it was generally agreed that in most cases where this
    
+  feature is used at all, that it would be just as easy to work around
    
+  using the sample rewrite techniques cited above.
    
+
    
+  Moon `credits' Pitman for (against some opposition) pushing this
    
+  `feature' down everyone's throats in the original CL design process.
    
+  Pitman admits this was an expensive mistake. Moon and Pitman support
    
+  this change as an important simplification to the language.
    
+
    
+  The cleanup committee unanimously endorsed this proposal.
    
+
    
+  In discussion at the Nov-87 X3J13 meeting, Franz and Gold Hill
    
+  mentioned that they use this feature a lot and were not entirely
    
+  happy about its going away.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096.htm new file mode 100644 index 00000000..6a6f22e1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DECLARE-TYPE-FREE:LEXICAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECLARE-TYPE-FREE:LEXICAL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DECLARE-TYPE-FREE:LEXICAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096_w.htm new file mode 100644 index 00000000..ccbbb573 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss096_w.htm @@ -0,0 +1,414 @@ + + + +CLHS: Issue DECLARE-TYPE-FREE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECLARE-TYPE-FREE Writeup

    + +
    Status:		Proposal LEXICAL passed Jan 89 X3J13
    
+Forum:         Cleanup
    
+Issue:         DECLARE-TYPE-FREE
    
+References:    CLtL p.158
    
+               DECLARATION-SCOPE
    
+Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
    
+               DECLARATION-SCOPE
    
+               SPECIAL-TYPE-SHADOWING
    
+Category:      CLARIFICATION/ADDITION
    
+
    
+Edit history:  Version 1, 18-Sep-88, Moon
    
+               Version 2, 22-Sep-88, Moon
    
+                (small edits to reflect mail discussion)
    
+               Version 3, 22-Sep-88, Masinter
    
+               Version 4, 27-Sep-88, JonL 
    
+               Version 5, 30-Sep-88, Masinter (cost to implementors)
    
+               Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
    
+               Version 7,  5-Dec-88, Masinter (scope->extent)
    
+               Version 8,  7-Dec-88, Masinter (back to scope)
    
+               Version 9,  2-Jan-89, Moon (2 proposals, to clarify discussion)
    
+               Version 10, 12-Jan-89, Masinter (add back lost v.6 phrase 
    
+                                                re nested declarations)
    
+
    
+
    
+Problem description:
    
+
    
+  Section 9.2 of CLtL, p158, says that a declaration specifier like
    
+  (TYPE type var1 var2 ...) "... affects only variable bindings".  
    
+  Since declarations can occur in contexts other than establishing 
    
+  "variable bindings", most people interpret this statement to mean 
    
+  that type declarations not in such context are either (1) completely 
    
+  to be ignored, or (2) invalid CL  syntax.  Thus both of the following 
    
+  forms would be suspect in that the type declarations could not have 
    
+  any effect:
    
+
    
+    (if (and (typep x 'fixnum) (typep y 'fixnum))
    
+        (locally (declare (fixnum x y))             ;LOCALLY does not bind
    
+          ...algorithm using x and y...)            ; any variables.
    
+        ...similar algorithm using x and y...)
    
+
    
+    (let ((y 'foo))
    
+      (setq y 10)
    
+      (let ((x 5))                                  ;'y' is not being bound in
    
+        (declare (fixnum y))                        ; this particular context.
    
+        (incf y)
    
+         ...random algorithm...))
    
+
    
+
    
+Proposal (DECLARE-TYPE-FREE:ALLOW):
    
+  
    
+  Specify that a type declaration does not only "affect variable bindings";
    
+  rather, type declarations are legal in all declarations. The interpretation
    
+  of a type declaration is that, during the execution of any expression 
    
+  within the scope of the declaration,  it is an error for the value of
    
+  the declared variable not to be of the declared type. For declarations
    
+  that are associated with variable bindings, the type declaration also
    
+  applies to the initial binding of the variable. In the special case
    
+  of a declaration for which there are no executable expressions
    
+  within the scope of the declaration (e.g., (locally (declare (integer x)))),
    
+  the result is as if there were executable expressions.
    
+
    
+  In this proposal, a type declaration affects not only variable
    
+  references within its scope, but also affects variable references that
    
+  are outside the scope of the declaration but dynamically inside the
    
+  execution of a form that is itself inside the scope of the
    
+  declaration.  Such references can exist when the variable is SPECIAL
    
+  or when the declaration is not attached to the variable's binding, so
    
+  that the scope of the declaration does not include the entire scope
    
+  of the variable.
    
+
    
+  Clarify that if nested type declarations refer to the same variable,
    
+  then the value of the variable must be a member of the intersection of
    
+  the declared types.
    
+
    
+
    
+Proposal (DECLARE-TYPE-FREE:LEXICAL):
    
+
    
+  Specify that a type declaration does not only "affect variable bindings";
    
+  rather, type declarations are legal in all declarations. The interpretation
    
+  of a type declaration is that, during the execution of any reference to the
    
+  declared variable within the scope of the declaration, it is an error for
    
+  the value of the declared variable not to be of the declared type; and
    
+  during the execution of any SETQ of the declared variable within the scope
    
+  of the declaration, it is an error for the newly assigned value of the
    
+  declared variable not to be of the declared type; and at the moment the
    
+  scope of the declaration is entered, it is an error for the value of the
    
+  declared variable not to be of the declared type.
    
+
    
+  In this proposal, a type declaration affects only variable references within
    
+  its scope, and the meaning of "free" and "variable-binding-associated" type
    
+  declarations can be described identically.
    
+
    
+  This proposal is equivalent to saying that the meaning of a type declaration
    
+  is equivalent to changing each reference to <var> within the scope of the
    
+  declaration to (THE <type> <var>), changing each expression assigned to the
    
+  variable within the scope of the declaration to (THE <type> <new-value>),
    
+  and executing (THE <type> <var>) at the moment the scope of the declaration
    
+  is entered.
    
+
    
+  Clarify that if nested type declarations refer to the same variable,
    
+  then the value of the variable must be a member of the intersection of
    
+  the declared types.
    
+
    
+Examples:
    
+
    
+;; this is an error under DECLARE-TYPE-FREE:ALLOW:
    
+;; the assertion that x is a fixnum is violated between the two 
    
+;; calls to (zap)
    
+;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
    
+
    
+        (let ((x 12) (y 'foo))
    
+          (flet ((zap () (rotatef x y)))
    
+            (locally (declare (fixnum x))
    
+              (zap)
    
+              (zap)
    
+              x)))
    
+
    
+;; this is an error under both proposals
    
+
    
+        (let ((x 12) (y 'foo))
    
+          (flet ((zap () (rotatef x y)))
    
+            (locally (declare (fixnum x))
    
+              (zap)
    
+              (print x)
    
+	      (zap)
    
+              x)))
    
+
    
+;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
    
+;; the assertion that x is a fixnum
    
+;; is violated during the call to zap, even though few 
    
+;; implementations will be able to check:
    
+;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
    
+
    
+        (let ((x 12) (y 'foo))
    
+          (flet ((zap ()
    
+                   (rotatef x y)
    
+                   (rotatef x y)))
    
+            (locally (declare (fixnum x))
    
+              (zap)
    
+              x)))
    
+
    
+;; this is an error under both proposals, even though the
    
+;; violation of the type constraint happens after the form
    
+;; with the declaration is exited.
    
+
    
+   (let ((f (let ((x 3))
    
+              (declare (fixnum x))
    
+              #'(lambda (z) (incf x z)))))
    
+     (funcall f 4.3))
    
+
    
+
    
+Rationale:
    
+
    
+  This proposal enables optimizing compilers to make use of the otherwise
    
+  ignored type information.  Many people have often asked for it, and
    
+  there is no strong reason to forbid it.
    
+  
    
+  DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
    
+  more freedom for optimizing compilers.  DECLARE-TYPE-FREE:LEXICAL is easier
    
+  to understand but allows a specialized representation only where the scope
    
+  of the variable is the same as the scope of the declaration or the compiler
    
+  can prove that there are no relevant other references to the variable.
    
+
    
+Current practice:
    
+
    
+  Lucid Common Lisp allows "free" type declarations;  under some 
    
+  circumstances the compiler issues a warning message that such usage 
    
+  is an extension to Common Lisp.
    
+
    
+Cost to Implementors:
    
+
    
+  Implementations that might currently warn about such declarations
    
+  would have to remove the warning; otherwise, it is valid to ignore 
    
+  type declarations.
    
+
    
+Cost to Users:
    
+
    
+  None, this is a compatible addition.
    
+
    
+Cost of non-adoption:
    
+
    
+  Common Lisp will be less self-consistent.
    
+
    
+Benefits:
    
+
    
+  Programmers will be able to use type declaration to express their
    
+  intent, rather than having to manually insert THE wrappers around 
    
+  every reference.
    
+
    
+
    
+Esthetics:
    
+
    
+  It is a simpler interpretation for type declaration specifiers, with
    
+  fewer special cases; hence reduces the number of exceptions in the
    
+  language.
    
+
    
+Discussion:
    
+
    
+  Another cleanup issue, DECLARATION-SCOPE, addresses the scope of 
    
+  declarations. This proposal carefully uses the phrase "within the 
    
+  scope of the declaration" to avoid confounding the two issues. 
    
+
    
+  This issue has been discussed at the Fort Collins X3J13 meeting in
    
+  November 1987, and at length on the various electronic mailing lists.
    
+
    
+  At least one current implementation is able to generate more efficient
    
+  code when declarations are associated with a particular binding, since
    
+  it then has the option to choose type-specific specialized storage for 
    
+  the runtime value of the variable.  So, for example, 
    
+
    
+      (let ((x v)) (declare (type float x)) (+ x x))
    
+
    
+  is sometimes more efficient than
    
+
    
+      (let ((x v)) (locally (declare (type float x)) (+ x x)))
    
+
    
+  However, the local type declarations allowed by this proposal do
    
+  provide some useful information, even if it is not the *most* useful.
    
+  It is possible for a sufficiently "smart" compiler to infer the 
    
+  equivalent of a "binding declaration" when it can ascertain that the 
    
+  type of the binding value -- 'v' above -- is commensurate with the 
    
+  type locally declared over the scope of usage of the variable.
    
+
    
+  It may be useful for a compiler to issue a warning whenever it finds
    
+  nested type declarations referring to the same variable and the
    
+  intersection of the declared types is null.
    
+
    
+  Documentation might want to discuss the style implications of
    
+  nested declarations intersecting. The interesting cases are:
    
+   - An inner declaration could be a subtype of an outer one.
    
+     This is the most useful case and probably the only one to
    
+     be encouraged in code written by humans. e.g.,
    
+       (locally (declare (type number x))
    
+         (locally (declare (type integer x))
    
+           ...use X as integer...))
    
+   - An outer declaration could be a subtype of an inner one.
    
+     This is useless but harmless. It might happen as the result
    
+     of certain macro situations. e.g.,
    
+       (locally (declare (type integer x))
    
+         (locally (declare (type number x))
    
+           ...use X as integer...))
    
+   - Two types may only partially overlap. This would presumably
    
+     happen only as the result of a macro expansion.
    
+       (locally (declare (type fixnum x))
    
+         (locally (declare (type (or bit package) x))
    
+           ...use X as BIT...))
    
+
    
+*start*
    
+05268 00024 USm
    
+GV-Info: X3J13-mailer@SAIL.Stanford.EDU at  7-Apr-89 15:28:47 from AG
    
+Return-Path: <X3J13-mailer@SAIL.Stanford.EDU>
    
+Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 07 APR 89 14:36:21 PDT
    
+Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Apr 89  14:20:08 PDT
    
+Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 573609; Fri 7-Apr-89 17:19:10 EDT
    
+Date: Fri, 7 Apr 89 17:18 EDT
    
+From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
+Subject: Did you blow it?
    
+To: Guy Steele <gls@Think.COM>, rpg@lucid.com
    
+cc: x3j13@sail.stanford.edu
    
+In-Reply-To: <8904071720.AA18178@verdi.think.com>
    
+Message-ID: <19890407211851.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
    
+
    
+    Date: Fri, 7 Apr 89 13:20:57 EDT
    
+    From: Guy Steele <gls@Think.COM>
    
+
    
+       Date: Thu, 6 Apr 89 15:19:42 PDT
    
+       From: Richard P. Gabriel <rpg@lucid.com>
    
+
    
+       When I read the effect of Issue: DECLARE-TYPE-FREE on page 223, I
    
+       completely flipped. I think you might have gotten it wrong.
    
+
    
+He did.
    
+
    
+       You say that in this code:
    
+
    
+       (defun f (x)
    
+	 (declare (type float x))
    
+	 (let ((x 'a)) ...)
    
+	  ...)
    
+
    
+       The declaration affects both bindings of x. This cannot make any sense
    
+       at all.  I don't have marked which version of this issue passed, but I
    
+       think neither implies this. The most that is implied is that if you
    
+       say this:
    
+
    
+       (defun f (x)
    
+	 ...
    
+	 (let ((y 'a))
    
+	  (declare (type float x))
    
+	  ...)
    
+	 ...)
    
+
    
+       then the declaration applies to variable references within the let-y
    
+       and not to within some larger scope.
    
+
    
+       I hope you are wedged, because otherwise the proposal is wedged.
    
+
    
+    I also hope I am wedged.  I am taking the liberty of cc'ing this
    
+    to X3J13 so that others can let me know what they think.
    
+
    
+    I believe I was confused by this paragraph from proposal
    
+    DECLARE-TYPE-FREE:LEXICAL, passed January 1989:
    
+
    
+      This proposal is equivalent to saying that the meaning of a type declaration
    
+      is equivalent to changing each reference to <var> within the scope of the
    
+      declaration to (THE <type> <var>), changing each expression assigned to the
    
+      variable within the scope of the declaration to (THE <type> <new-value>),
    
+      and executing (THE <type> <var>) at the moment the scope of the declaration
    
+      is entered.
    
+
    
+    The ambiguity concerns whether in
    
+
    
+       (defun f (x)
    
+	 (declare (type float x))
    
+	 x     ;reference 1
    
+	 (let ((x 'a)) ...)
    
+	   x   ;reference 2
    
+	   ...)
    
+
    
+    the two references are construed to be to the same *variable*.
    
+    (I readily grant that they refer to different *bindings*.)
    
+    I assumed that they were contrued to be the same variable,
    
+    in which case I believe that what I wrote on page 223 of the
    
+    CLtL II draft is a correct conclusion.
    
+
    
+The phrase "within the scope of the declaration" quoted above is
    
+supposed to be a precisely defined phrase.  The passed cleanup
    
+issue DECLARATION-SCOPE was supposed to define that phrase.
    
+Unfortunately, there is a problem: the precise language in version
    
+2 of the proposal was replaced with much less precise language 
    
+in version 4, which was the version that was voted upon.
    
+The version 2 language was:
    
+  
    
+  The scope of a `bound' declaration is exactly the scope of the
    
+  associated lexical variable or function.  If the declaration is
    
+  associated with a special variable, the scope is the scope the variable
    
+  would have had if it had not been special.
    
+  
    
+  `Free' declarations are scoped as if they appeared in a new LOCALLY form
    
+  which surrounded the entire special form at the beginning of whose body
    
+  the declaration appears.  This is the same as what CLtL p.155 defines to
    
+  be the scope of `pervasive' declarations.
    
+
    
+This answers your question about special variables.  I think that
    
+for declarations that concern variable or function bindings, but are
    
+not actually attached to a binding (i.e. are used free), the correct
    
+scope is the same as the scope of a non-special binding of that name
    
+surrounding the form to which the binding is attached; the language
    
+about LOCALLY quoted above is out of date.
    
+
    
+Gurg.  Your example above is misindented.  If you meant
    
+
    
+       (defun f (x)
    
+	 (declare (type float x))
    
+	 x     ;reference 1
    
+	 (let ((x 'a))
    
+	   x   ;reference 2
    
+	   ...)
    
+
    
+then the scope of the declaration does not include (let ((x 'a)) x ...)
    
+because type declarations are not "pervasive".  Thus what you wrote
    
+on p.223 of CLtL is wrong.
    
+
    
+But if you meant
    
+
    
+       (defun f (x)
    
+	 (declare (type float x))
    
+	 x     ;reference 1
    
+	 (let ((x 'a)) ...)
    
+	 x   ;reference 2
    
+	 ...)
    
+
    
+then the example does not address the question since reference 1
    
+and reference 2 are clearly both in the scope of the type declaration.
    
+
    
+    Now that you have pointed it out, I agree that a more likely
    
+    and more desirable interpretation is that the references are
    
+    considered to be to different variables.  Question: what if x
    
+    had been proclaimed SPECIAL?  Then what would the interpretation be?
    
+
    
+A special declaration should not affect the scope of a type declaration.
    
+Now, the version of DECLARATION-SCOPING that actually passed does not
    
+actually say that.  But I don't think any other position is arguable.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097.htm new file mode 100644 index 00000000..fba1e404 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097.htm @@ -0,0 +1,68 @@ + + + +CLHS: Issue DECLS-AND-DOC Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECLS-AND-DOC Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DECLS-AND-DOC:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097_w.htm new file mode 100644 index 00000000..3d32f14e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss097_w.htm @@ -0,0 +1,35 @@ + + + +CLHS: Issue DECLS-AND-DOC Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECLS-AND-DOC Writeup

    + +
    The vote on this was kind of strange.  At the X3J13 meeting, a subcommittee
    
+of Barrett, Loosemore, and Pitman was empowered to `fix things'.
    
+See the associated mail for how that was done.  Currently there is no write-up
    
+of what we did.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098.htm new file mode 100644 index 00000000..5f12aff7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098_w.htm new file mode 100644 index 00000000..58367434 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss098_w.htm @@ -0,0 +1,116 @@ + + + +CLHS: Issue DECODE-UNIVERSAL-TIME-DAYLIGHT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DECODE-UNIVERSAL-TIME-DAYLIGHT Writeup

    + +
    Issue:        DECODE-UNIVERSAL-TIME-DAYLIGHT
    
+References:   DECODE-UNIVERSAL-TIME (p445)
    
+Category:     CLARIFICATION
    
+Edit history: 20-Jun-88, Version 1 by Pitman
    
+		30-Sep-88, Version 2 by Masinter
    
+
    
+Problem Description:
    
+
    
+  The description of DECODE-UNIVERSAL-TIME does not say what happens with
    
+  TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
    
+  its behavior differs depending on whether a time zone is explicitly passed,
    
+  some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
    
+  likewise.
    
+
    
+  Even if all implementations did the same thing, it should still be clarified
    
+  whether an implementation were permitted to return dsp=NIL tz=n rather than
    
+  dsp=T tz=n+1 for time zones in which daylight savings time was believed to
    
+  be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
    
+  daylight-savings-time-p means "daylight savings time is in effect" or
    
+  just "daylight savings time is not known to not be in effect".
    
+
    
+  These tools appear to be more portable than they are.
    
+
    
+Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):
    
+
    
+  Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
    
+  daylight savings information if a timezone is explicitly specified.
    
+
    
+Rationale:
    
+
    
+  This makes things consistent with ENCODE-UNIVERSAL-TIME.
    
+
    
+Test Case:
    
+
    
+  ;; ### This test case relies on time zone not changing in real
    
+  ;; ###   time, in defiance of warning in note at bottom
    
+  ;; ###   of p445.
    
+
    
+  (LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
    
+	 (RECENTLY (GET-UNIVERSAL-TIME))
    
+	 (A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
    
+	 (B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
    
+    (LIST A B (EQUAL A B)))
    
+
    
+Under this proposal, this would return ((T 5) (NIL 5) NIL) in EDT, for example. 
    
+
    
+Current Practice:
    
+
    
+ Symbolics Genera, Symbolics Cloe, Lucid 3.0 and Envos Medley seem to 
    
+ implement this proposal. Some other implementations do not.
    
+
    
+Cost to Implementors:
    
+
    
+  The cost of changing this should be trivial.
    
+
    
+Cost to Users:
    
+
    
+  This feature is already not well-defined since no portable program can rely
    
+  on the current behavior, so the cost is small.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The time primitives are considerably less useful if this point is not
    
+  clearly spelled out.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  Anything that improves the intelligibility of language primitives improves
    
+  language aesthetics.
    
+
    
+Discussion:
    
+
    
+  An alternative would be to specify that, unlike ENCODE-UNIVERSAL-TIME,
    
+  DECODE-UNIVERSAL-TIME treats daylight savings information the same
    
+  regardless of whether a time zone argument is explicitly or not. This seems 
    
+  actually to be what was intended originally.
    
+
    
+  This problem arose while trying to port Macsyma between different
    
+  Common Lisp implementations. The cleanup committee does not have
    
+  a strong opinion on this matter, as long as the behavior is specified.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099.htm new file mode 100644 index 00000000..2a184bb3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFCONSTANT-SPECIAL:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFCONSTANT-SPECIAL:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFCONSTANT-SPECIAL:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099_w.htm new file mode 100644 index 00000000..707508ae --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss099_w.htm @@ -0,0 +1,119 @@ + + + +CLHS: Issue DEFCONSTANT-SPECIAL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFCONSTANT-SPECIAL Writeup

    + +
    Forum:		Compiler
    
+Issue:		DEFCONSTANT-SPECIAL
    
+References:	CLtL p. 68-69, 55-56
    
+		Issue DEFCONSTANT-NOT-WIRED
    
+		Issue PROCLAIM-LEXICAL
    
+		Issue SYNTACTIC-ENVIRONMENT-ACCESS
    
+		Issue SPECIAL-VARIABLE-TEST
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 15 Nov 1988, Sandra Loosemore
    
+		V2, 22 Nov 1988, Sandra Loosemore
    
+		V3, 30 Dec 1988, Sandra Loosemore
    
+		V4, 23 Jan 1989, Sandra Loosemore (amendment)
    
+Status: Proposal DOESNT-MATTER passed Jan 1989
    
+
    
+
    
+Problem Description:
    
+
    
+It is unclear whether DEFCONSTANT is supposed to proclaim the variable
    
+SPECIAL.  Page 56 says that symbols defined by DEFCONSTANT "may not be
    
+further assigned to or bound".  Page 69 says that "further assignment
    
+to or binding of that special variable is an error" but permits
    
+compilers to "choose to issue warnings about bindings of the lexical
    
+variable of the same name".  Does this mean that it is legal (but
    
+perhaps only questionable style) to lexically rebind constants?  If
    
+so, this would seem to imply that they must not be proclaimed SPECIAL
    
+(since CLtL provides no way to override a SPECIAL proclamation).
    
+
    
+Some people think that DEFCONSTANT is supposed to proclaim the
    
+variable SPECIAL because CLtL says that DEFVAR does, and that
    
+DEFPARAMETER is like DEFVAR, and DEFCONSTANT is like DEFPARAMETER.
    
+Also, the use of the phrase "that special variable" rather than "the
    
+special variable of the same name" might indicate that the variable
    
+really is supposed to be special.
    
+
    
+
    
+Proposal DEFCONSTANT-SPECIAL:DOESNT-MATTER:
    
+
    
+Clarify that it is an error to rebind constant symbols as either
    
+lexical or special variables.  (In other words, a reference to a
    
+symbol declared with DEFCONSTANT always refers to its global value.)
    
+
    
+
    
+Rationale:
    
+
    
+Clarifying that lexical rebinding (as well as special rebinding) of
    
+constants "is an error" seems to be the behavior that most users
    
+expect.  One serious problem that might arise from allowing constants
    
+to be rebound lexically is that it would not be reliable to include
    
+symbolic constants in macro expansions, because the user might have
    
+rebound them to something else.
    
+
    
+
    
+Current Practice:
    
+
    
+Most implementations apparently proclaim the variable special anyway.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Minor.
    
+
    
+
    
+Cost to users:
    
+
    
+Probably none.  Since many implementations do proclaim the variable to
    
+be special (while at the same time forbidding special binding), there
    
+is probably no user code that depends upon lexical rebinding of
    
+DEFCONSTANTs.
    
+
    
+
    
+Benefits:
    
+
    
+An area of confusion in the language is removed.
    
+
    
+
    
+Discussion:
    
+
    
+This issue is primarily a documentation clarification.  It arose
    
+during a discussion of what the DEFCONSTANT macro might expand into.
    
+As far as users are concerned, it makes no difference whether
    
+constants are special or lexical, as long as all rebinding is
    
+prohibited.  The only situation where the distinction might become
    
+important is if a function is added to the language to test whether a
    
+variable has been proclaimed special.
    
+
    
+The "problem description" section of the writeup on issue
    
+PROCLAIM-LEXICAL (version 8) also appears to assume that constants
    
+declared with DEFCONSTANT are not special.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100.htm new file mode 100644 index 00000000..d3cff7f0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFGENERIC-DECLARE:ALLOW-MULTIPLE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFGENERIC-DECLARE:ALLOW-MULTIPLE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFGENERIC-DECLARE:ALLOW-MULTIPLE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100_w.htm new file mode 100644 index 00000000..c877e303 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss100_w.htm @@ -0,0 +1,93 @@ + + + +CLHS: Issue DEFGENERIC-DECLARE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFGENERIC-DECLARE Writeup

    + +
    Issue:         DEFGENERIC-DECLARE
    
+
    
+References:    88-002R p.2-27
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+               30-Apr-90, Version 2 by Moon (update current practice)
    
+
    
+Problem description:
    
+
    
+  DEFGENERIC only allows DECLARE to appear once, which is inconsistent with
    
+  DEFUN, which allows any number of DECLAREs.
    
+
    
+  This is Symbolics issue #23.
    
+
    
+Proposal (DEFGENERIC-DECLARE:ALLOW-MULTIPLE):
    
+
    
+  Allow the DECLARE option to appear multiple times in a DEFGENERIC form.
    
+  The multiple declarations are appended together.
    
+
    
+Rationale:
    
+
    
+  Programmers rely on the syntactic analogy between DEFGENERIC and DEFUN.
    
+
    
+  Note that some implementations allow several implementation-dependent
    
+  declarations in DEFGENERIC, so the list of declarations in a DEFGENERIC
    
+  could be quite long.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0 only allows DECLARE to appear once.
    
+  Lucid 4.0.0 Beta-1 allows DECLARE to appear multiple times.
    
+
    
+Cost to Implementors:
    
+
    
+  Easy.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  DEFGENERIC would be inconsistent with all other forms that allow DECLARE
    
+  to be used to specify declarations.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  More consistent language.
    
+
    
+Esthetics:
    
+
    
+  More consistent language.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101.htm new file mode 100644 index 00000000..216e8fe0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101.htm @@ -0,0 +1,45 @@ + + + +CLHS: Issue DEFINE-COMPILER-MACRO:X3J13-NOV89 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFINE-COMPILER-MACRO:X3J13-NOV89 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFINE-COMPILER-MACRO:X3J13-NOV89:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101_w.htm new file mode 100644 index 00000000..aa871894 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss101_w.htm @@ -0,0 +1,350 @@ + + + +CLHS: Issue DEFINE-COMPILER-MACRO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFINE-COMPILER-MACRO Writeup

    + +
    Forum:          Cleanup
    
+Issue:          DEFINE-COMPILER-MACRO
    
+Related Issues: Issue DEFINE-OPTIMIZER
    
+                Issue SYNTACTIC-ENVIRONMENT-ACCESS
    
+                Issue LISP-SYMBOL-REDEFINITION
    
+                Issue DEFINING-MACROS-NON-TOP-LEVEL
    
+                Issue EVAL-WHEN-NON-TOP-LEVEL
    
+References:     CLtL p. 151, p. 152
    
+Category:       ADDITION
    
+Edit-History:   28-Jun-89, Version 1 by JonL White and Steve Haflich
    
+                12-Jul-89, Version 2 by Loosemore
    
+                24-Oct-89, Version 3 by Loosemore
    
+                19-Oct-90, Version 4 by Loosemore
    
+Status:         Version 2 (proposal NEW-FACILITY) passed at June 89 meeting
    
+                Version 4 (proposal X3J13-NOV89) passed at Nov 89 meeting
    
+                    (replaces proposal NEW-FACILITY)
    
+
    
+
    
+Problem Description:
    
+
    
+Occasionally one would like to define a macro which is expanded only
    
+"in the compiler", but which would not normally affect the actions of
    
+the interpreter.  For example, the OSS/Generator proposal has several
    
+functions for which it would like to specify some alternative source
    
+code sequences for the compiler to compiler, rather than just
    
+compiling a closed-call to the function.
    
+
    
+Also, it is occasionally desirable for a macro expansion to be
    
+different based on the various compiler optimization qualities (e.g.,
    
+SPEED, SAFETY, and so on); but if the expansion is for the interpreter
    
+rather than the compiler, then such variation based on compiler
    
+optimizers is not needed.
    
+
    
+So-called "compiler optimizers" are just a special case of macro-like
    
+expansions, which are limited to being done "in the compiler" and
    
+which are generally required to produce semantically equivalent code
    
+to replace an apparent function call.  There is a need for a facility
    
+that at least covers this capability.
    
+
    
+
    
+
    
+
    
+Proposal: (DEFINE-COMPILER-MACRO:X3J13-NOV89):
    
+
    
+Add the concept of "compiler macros" to the language, along with the
    
+defining macro DEFINE-COMPILER-MACRO and accessor function
    
+COMPILER-MACRO-FUNCTION.
    
+
    
+
    
+(1) What compiler macros are
    
+
    
+  The purpose of this facility is to permit selective source-code
    
+  transformations as optimization advice to the compiler.  When a
    
+  nonatomic form is being processed (as by the compiler), if the
    
+  operator names a compiler macro then that compiler macro may be
    
+  invoked on the form, and the resulting expansion recursively processed
    
+  in preference to performing the usual processing on the original form
    
+  according to its normal interpretation as a function or macro call.
    
+
    
+  A compiler macro function, like an ordinary macro function, is a
    
+  function of two arguments: the entire call form and the environment.
    
+  Unlike an ordinary macro, a compiler macro can decline to provide an
    
+  expansion merely by returning a value that is EQL to the original
    
+  form.  The consequences are undefined if a compiler macro function
    
+  destructively modifies any part of its form argument.
    
+
    
+  The form passed to the compiler macro function can either be a list
    
+  whose CAR is the function name, or a list whose CAR is FUNCALL and
    
+  whose CADR is a list (FUNCTION <name>); note that this affects
    
+  destructuring of the form argument by the compiler macro function.
    
+  DEFINE-COMPILER-MACRO arranges for destructuring of arguments to be
    
+  performed correctly for both possible formats.
    
+
    
+
    
+(2) Naming of compiler macros
    
+
    
+  Compiler macros may be defined for function names that name macros as
    
+  well as functions.  It is not permitted to define a compiler macro for
    
+  names which are external symbols in the COMMON-LISP package; see issue
    
+  LISP-SYMBOL-REDEFINITION.
    
+
    
+  Compiler macro definitions are strictly global.  There is no provision
    
+  for defining local compiler macros in the way that MACROLET defines
    
+  local macros.  Lexical bindings of a function name shadow any compiler
    
+  macro definition associated with the name as well as its global
    
+  function or macro definition.
    
+
    
+  Note that the presence of a compiler macro definition does not affect
    
+  the values returned by FUNCTION-INFORMATION, or other accessors such
    
+  as FBOUNDP or MACROEXPAND.  Compiler macros are global and the function
    
+  COMPILER-MACRO-FUNCTION is sufficient to resolve their interaction
    
+  with other lexical and global definitions.
    
+
    
+
    
+(3) When compiler macros might/must/must not be used
    
+
    
+  The presence of a compiler macro definition for a function or macro
    
+  indicates that it is desirable for the compiler to use the expansion
    
+  of the compiler macro instead of the original function call or macro
    
+  call form.  However, it is not required for any language processor
    
+  (compiler, evaluator, or other code walker) to actually invoke compiler
    
+  macro functions, or to make use of the resulting expansion.
    
+
    
+  There two situations in which a compiler macro definition must not be
    
+  applied by any language processor:
    
+
    
+      - The global function name binding associated with the compiler
    
+        macro is shadowed by lexical rebinding of the function name.
    
+
    
+      - The function name has been declared or proclaimed NOTINLINE and
    
+        the call form appears within the scope of the declaration.
    
+
    
+  When a compiler macro function is called as part of processing by the
    
+  evaluator or compiler, it is invoked by calling the function that is
    
+  the value of *MACROEXPAND-HOOK*.
    
+
    
+  When COMPILE-FILE chooses to expand a top-level compiler macro call,
    
+  the expansion is also treated as a top-level form for the purposes of
    
+  EVAL-WHEN processing, in the same way as the expansion of an ordinary
    
+  macro.
    
+
    
+
    
+
    
+(4) Specification of DEFINE-COMPILER-MACRO
    
+
    
+  DEFINE-COMPILER-MACRO name lambda-list
    
+        [[ {declaration}* | doc-string ]] {form}*                [macro]
    
+
    
+  DEFINE-COMPILER-MACRO is the normal mechanism for defining a compiler
    
+  macro function.  Its syntax resembles that of DEFMACRO.  The function
    
+  is defined in the lexical environment in which the DEFINE-COMPILER-MACRO
    
+  form appears; see issue DEFINING-MACROS-NON-TOP-LEVEL.
    
+
    
+  The <name> must be a function name.
    
+
    
+  The <lambda-list> supports destructuring and may include &ENVIRONMENT
    
+  and &WHOLE, in the same way as a DEFMACRO lambda-list.  The &WHOLE
    
+  argument is bound to the form argument that is passed to the compiler
    
+  macro function.  The remaining lambda-list parameters are specified
    
+  as if this form contained the function name in the CAR and the actual
    
+  arguments in the CDR, but if the CAR of the actual form is the symbol
    
+  FUNCALL, then the destructuring of the the arguments will actually be
    
+  performed using its CDDR instead.
    
+
    
+  When a call to DEFINE-COMPILER-MACRO appears at top-level in a file
    
+  being compiled by COMPILE-FILE, the compiler macro definition is made
    
+  known to the file compiler (analagous to the way top-level DEFMACRO
    
+  calls are handled).
    
+
    
+
    
+
    
+
    
+(5) Specification of COMPILER-MACRO-FUNCTION
    
+
    
+  COMPILER-MACRO-FUNCTION name &optional env                       [function]
    
+
    
+  This is the accessor for the compiler macro definition associated
    
+  with a given name.
    
+
    
+  The <name> argument must be a function name.  If there is a compiler
    
+  macro definition associated with that name in the given environment
    
+  <env>, COMPILER-MACRO-FUNCTION returns that function; otherwise it
    
+  returns NIL.
    
+
    
+  If there is a local function or macro named <name> defined in the
    
+  environment <env>, this definition shadows any global compiler macro
    
+  definition for that <name> and COMPILER-MACRO-FUNCTION must return
    
+  NIL.
    
+
    
+  SETF may be used with COMPILER-MACRO-FUNCTION to install a compiler
    
+  macro function for the name <name>, analogously to using SETF on
    
+  MACRO-FUNCTION.  The value must be a function of two arguments, as
    
+  described above.  It is also permissible to provide a value of NIL to
    
+  remove any existing compiler macro definition.  The <env> argument to
    
+  COMPILER-MACRO-FUNCTION must be omitted when it appears as a SETF
    
+  place.
    
+
    
+
    
+
    
+
    
+Proposal: (DEFINE-COMPILER-MACRO:NEW-FACILITY):
    
+
    
+Introduce a new facility by additions as follows:
    
+
    
+Macro:
    
+
    
+DEFINE-COMPILER-MACRO name lambda-list {doc-string} {declarations}* {form}*
    
+
    
+  This is just like DEFMACRO except the definition isn't stored in the
    
+  symbol function cell of 'name', and isn't seen by MACROEXPAND-1 (but
    
+  is seen by COMPILER-MACROEXPAND-1 -- see below).  Like DEFMACRO, the
    
+  lambdalist may include &ENVIRONMENT and &WHOLE.  The definition is
    
+  "global"; there is no explicit provision for defining local compiler
    
+  macros in the way that MACROLET defines local macros.
    
+
    
+  A toplevel call to DEFINE-COMPILER-MACRO in a file being compiled by
    
+  COMPILE-FILE has an effect on the compilation environment similar to
    
+  what a call to DEFMACRO would have, except it is noticed as a
    
+  "compiler macro".
    
+
    
+
    
+Function:
    
+
    
+COMPILER-MACRO-FUNCTION name &OPTIONAL env
    
+
    
+  If 'name' is a symbol that has been defined as a compiler macro, then
    
+  calling COMPILER-MACRO-FUNCTION on it returns the macro expansion
    
+  function; otherwise it returns NIL.  'name' must be a symbol.  The
    
+  local lexical environment may override a global definition for 'name'
    
+  by defining a local function or local macro (such as by FLET,
    
+  MACROLET, etc.), in which case NIL is returned; the optional argument
    
+  'env' is provided so that clients may pass in &environment objects for
    
+  this purpose.
    
+
    
+  SETF may be used with COMPILER-MACRO-FUNCTION to install a function as
    
+  the expansion function for the compiler macro 'name', analogously to
    
+  using SETF on MACRO-FUNCTION.  SETF'ing to NIL removes any existing
    
+  compiler macro definition.  Like MACRO-FUNCTION, the SETF value (if not
    
+  NIL) must be a function of two arguments:  the entire macro call, and
    
+  the environment.  The second argument to COMPILER-MACRO-FUNCTION must
    
+  be omitted when it is SETFed.
    
+
    
+
    
+Functions:
    
+
    
+COMPILER-MACROEXPAND form &OPTIONAL env
    
+COMPILER-MACROEXPAND-1 form &OPTIONAL env
    
+
    
+  This is just like MACROEXPAND and MACROEXPAND-1 (see CLtL p.151)
    
+  except that the expander function is obtained as if by a call to
    
+  COMPILER-MACRO-FUNCTION on the CAR of 'form' rather than by a call to
    
+  MACRO-FUNCTION.  There are three cases wherein no expansion happens:
    
+
    
+    (1) There is no compiler macro definition for the CAR of 'form';
    
+    (2) There is such a definition but there is also a NOTINLINE
    
+        declaration, either globally or in the lexical environment 'env';
    
+    (3) A global compiler macro definition is shadowed by a local
    
+        function or macro definition (such as by FLET, LABELS, or MACROLET).
    
+
    
+  Note that if there is no expansion, the original form is returned as
    
+  the first value, and NIL as the second value.
    
+
    
+  When COMPILER-MACROEXPAND-1 discovers that there is to be an expansion
    
+  it does it by calling the function in *MACROEXPAND-HOOK* (see CltL p.152).
    
+
    
+
    
+The purpose of this facility is to permit selective source-code
    
+transformations based on whether the compiler is processing the code.
    
+When the compiler is about to compile a nonatomic form, it first calls
    
+COMPILER-MACROEXPAND-1 repeatedly until there is no more expansion
    
+(there might not be any to begin with).  Then it continues its
    
+remaining processing, which may include calling MACROEXPAND-1 etc.
    
+
    
+The compiler is required to expand compiler macros; it is unspecified
    
+whether the interpreter does so.  The intention is that only the
    
+compiler will do so, but the range of possible "compiled-only"
    
+implementation strategies precludes any firm specification.
    
+
    
+Note that a compiler macro may decline to provide any expansion merely
    
+by returning the original form; this is useful when using the facility
    
+to put "compiler optimizers" on various function names.  For example,
    
+here is a compiler macro that "optimizes" the 0- and 1-argument cases of
    
+a function called PLUS:
    
+
    
+    (define-compiler-macro plus (&whole form &rest args)
    
+        (case (length args)
    
+            (0 0)
    
+            (1 (car args))
    
+            (t form)))
    
+
    
+The issue LISP-SYMBOL-REDEFINITION precludes user definition of any
    
+compiler macros for symbols external in the Lisp package that have a
    
+definition as a function, macro, or special form.
    
+
    
+Note that compiler macros do not appear in information returned by
    
+FUNCTION-INFORMATION; they are global, and their interaction
    
+with other lexical and global definitions can be reconstructed by
    
+COMPILER-MACRO-FUNCTION.  It is up to code-walking programs to decide
    
+whether to invoke compiler macro expansion.
    
+
    
+
    
+  Rationale:
    
+
    
+  Many implementations have it.  Many users have requested a way to add
    
+  source-code "optimizers" to the compiler.
    
+
    
+  Other than INLINE declarations for functions there is no other way to
    
+  customize how calls to a specific function are compiled.  DEFMACRO is
    
+  not usable for this purpose since it requires use of the
    
+  symbol-function cell, which would prevent the functional definition
    
+  from being active in the compilation environment.
    
+
    
+
    
+
    
+Current Practice:
    
+
    
+Lucid, Franz, and Symbolics have very similar facilities.  Hunoz about
    
+the others?
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Minor: implement a method for storing named expansion functions, and
    
+tweak the compiler in one or two places.
    
+
    
+
    
+Cost to Users:
    
+
    
+None.  This is an upward-compatible addition.
    
+
    
+
    
+Benefits:
    
+
    
+Increased portability for clients of the existing facilities.
    
+
    
+
    
+Discussion:
    
+
    
+There has been extensive discussion under the issue DEFINE-OPTIMIZER.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102.htm new file mode 100644 index 00000000..951e2359 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102_w.htm new file mode 100644 index 00000000..8efa90eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss102_w.htm @@ -0,0 +1,144 @@ + + + +CLHS: Issue DEFINE-CONDITION-SYNTAX Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFINE-CONDITION-SYNTAX Writeup

    + +
    Issue:		DEFINE-CONDITION-SYNTAX
    
+Forum:		Cleanup
    
+References:	Condition System, Version 18
    
+		CLOS Specification, 88-002R
    
+		Issue CLOS-CONDITIONS
    
+		Issue CONDITION-ACCESSORS-SETFABLE
    
+Category:	CHANGE/CLARIFICATION
    
+Edit History:	Version 1, 1/3/90 by Kim A. Barrett
    
+
    
+Problem Description:
    
+  Issue CLOS-CONDITIONS incompatibly changed the slot specification syntax
    
+  for DEFINE-CONDITION to match the slot specification syntax for DEFCLASS.
    
+  This leaves us with two defining macros whose general forms are very
    
+  similar but which have small idiosyncratic differences.
    
+
    
+Notes on voting:
    
+ Vote for just 1 of MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS, or
    
+   MORE-LIKE-DEFINE-CONDITION.
    
+ In addition, vote yes or no to EMPHASIZE-READ-ONLY.
    
+
    
+Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS):
    
+  Define the syntax for DEFINE-CONDITION to be
    
+
    
+    DEFINE-CONDITION name ({supertype}*) [({slot}*) {option}*]
    
+
    
+    option ::= (:DEFAULT-INITARGS initarg-list) |
    
+	       (:DOCUMENTATION string) |
    
+	       (:REPORT exp)
    
+
    
+  The :default-initarg option is defined in the same way as for DEFCLASS.  The
    
+  :documentation and :report options are unchanged.
    
+
    
+  If no supertypes are specified, then the condition being defined inherits
    
+  directly from CONDITION.
    
+
    
+Proposal (DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS):
    
+  As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but make the slot
    
+  specification list required.
    
+
    
+Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFINE-CONDITION):
    
+  As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but change the syntax of
    
+  DEFCLASS so that the slot specification list is optional.
    
+
    
+Proposal (DEFINE-CONDITION-SYNTAX:EMPHASIZE-READ-ONLY)
    
+  As either of the above proposals, but remove the :WRITER and :ACCESSOR
    
+  slot options.
    
+
    
+Rational:
    
+  This provides the added functionality provided by :DEFAULT-INITARGS, and
    
+  the convenience of not having to explicitly write CONDITION as the only
    
+  super for some conditions.
    
+
    
+  INCOMPATIBLY-MORE-LIKE-DEFCLASS makes the basic syntax identical, but at
    
+  the cost of an incompatible change, since the list of slot specifications
    
+  will no longer be optional.
    
+
    
+  EMPHASIZE-READ-ONLY emphasizes the point that it is an error to attempt
    
+  to assign a condition's slots using SETF.  Condition objects are supposed
    
+  to be at least conceptually read-only.
    
+
    
+Current Practice:
    
+  IIM supports the :DEFAULT-INITARGS option.  They may support the behavior
    
+  specified for an empty supertype list (if they don't, then they still
    
+  require at least one supertype).
    
+
    
+Cost to Implementors:
    
+  Supporting an empty supertype list in the specified way is probably fairly
    
+  trivial.  For an implementation of conditions which is not based on an
    
+  implementation of CLOS, adding the support for :default-initargs might not
    
+  be trivial.
    
+
    
+Cost to Users:
    
+  MORE-LIKE-DEFCLASS is upwardly compatible for the status quo.
    
+
    
+  The other two proposals will probably require some programs to be modified.
    
+  As an interim solution implementations could support MORE-LIKE-DEFCLASS and
    
+  issue warnings for cases which were incompatible with the other two
    
+  proposals.
    
+
    
+Benefits:
    
+  Programmers would need to remember fewer idiosyncratic differences in the
    
+  syntax of two very similar and important macros.
    
+
    
+Discussion:
    
+  Barrett supports MORE-LIKE-DEFINE-CONDITION.  He thinks that 
    
+  EMPHASIZE-READ-ONLY would be a good idea if there isn't too much concern
    
+  about the incompatibility issues.
    
+
    
+  Pitman supports MORE-LIKE-DEFCLASS but mostly because the CLOS crew are
    
+  a stubborn bunch and it seems more likely that we can bend the rest of the
    
+  spec to be like their polished piece of prose than vice versa.  
    
+  (i.e., MORE-LIKE-DEFINE-CONDITION is technically just as good to him.)
    
+  Pitman also supports EMPHASIZE-READ-ONLY.
    
+
    
+-----
    
+Additional comments in response to write-up:
    
+
    
+Moon (11 Jan 90):
    
+
    
+  This issue raises good points that I think were overlooked in past
    
+  discussions of unifying Conditions and CLOS.
    
+  
    
+  I am neutral among MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS,
    
+  or MORE-LIKE-DEFINE-CONDITION.  The incompatibilities here (either making
    
+  the slot-specifier list optional where it's mandatory or mandatory where
    
+  it is optional) are of little concern since the adjustment is tiny.  Any
    
+  one of these would be a significant improvement over the status quo.
    
+  
    
+  I am definitely in favor of EMPHASIZE-READ-ONLY and not impressed by the
    
+  compatibility arguments.  An existing program that is incompatible with
    
+  this either actually modifies condition objects, in which case it can't
    
+  work, or it just accidentally says :ACCESSOR but only uses the reader,
    
+  in which case it is trivial to fix.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103.htm new file mode 100644 index 00000000..40980b17 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFINE-METHOD-COMBINATION-BEHAVIOR:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFINE-METHOD-COMBINATION-BEHAVIOR:CLARIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFINE-METHOD-COMBINATION-BEHAVIOR:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103_w.htm new file mode 100644 index 00000000..1f9fe1d7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss103_w.htm @@ -0,0 +1,100 @@ + + + +CLHS: Issue DEFINE-METHOD-COMBINATION-BEHAVIOR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFINE-METHOD-COMBINATION-BEHAVIOR Writeup

    + +
    Issue:        DEFINE-METHOD-COMBINATION-BEHAVIOR
    
+Forum:        X3J13 Letter Ballot
    
+References:   DEFINE-METHOD-COMBINATION (X3J13/92-102, p7-77)
    
+	      Public review comment Barrett-23
    
+	      Public review comment Loosemore-9
    
+Category:     CLARIFICATION
    
+Edit history: 21-Jun-93, Version 1 by Steele (based on text by Loosemore)
    
+Status:		Proposal CLARIFY passed 11-0 on letter ballot 93-304.
    
+
    
+Problem Description:
    
+
    
+  A portion of a previously approved technical issue
    
+  (CLOS-MACRO-COMPILATION) that specified when method combinations are
    
+  executed was not incorporated into the draft.
    
+
    
+Proposal (DEFINE-METHOD-COMBINATION:CLARIFY):
    
+
    
+  Add this statement to the description of DEFINE-METHOD-COMBINATION:
    
+
    
+    If a \macref{define-method-combination} \term{form} appears as a
    
+    \term{top level form}, the \term{compiler} must make the
    
+    \term{method combination} \term{name} be recognized as a valid
    
+    \term{method combination} \term{name} in subsequent \macref{defgeneric}
    
+    \term{forms}.  However, the \term{method combination} is executed
    
+    no earlier than when the \macref{define-method-combination} \term{form}
    
+    is executed, and possibly as late as the time that \term{generic functions}
    
+    that use the \term{method combination} are executed.
    
+  
    
+Test Case:
    
+
    
+  Not provided.
    
+
    
+Rationale:
    
+
    
+  Incorporate technical change already approved.
    
+
    
+Current Practice:
    
+
    
+  Not provided.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably relatively small.
    
+
    
+Cost to Users:
    
+
    
+  None.  This change doesn't affect anything already guaranteed to the user.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Vagueness in the language specification.
    
+
    
+Benefits:
    
+
    
+  Better program portability.
    
+
    
+Editorial Impact:
    
+
    
+  Small.  A few small, localized edits.
    
+
    
+Aesthetics:
    
+
    
+  Mostly neutral.
    
+
    
+Discussion:
    
+  
    
+  This addresses comment Barrett #23 and Loosemore #9.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104.htm new file mode 100644 index 00000000..f829e966 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104.htm @@ -0,0 +1,43 @@ + + + +CLHS: Issue DEFINING-MACROS-NON-TOP-LEVEL:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFINING-MACROS-NON-TOP-LEVEL:ALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104_w.htm new file mode 100644 index 00000000..d4480992 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss104_w.htm @@ -0,0 +1,172 @@ + + + +CLHS: Issue DEFINING-MACROS-NON-TOP-LEVEL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFINING-MACROS-NON-TOP-LEVEL Writeup

    + +
    Forum:		Compiler
    
+Issue:		DEFINING-MACROS-NON-TOP-LEVEL
    
+References:	CLtL p. 66-70, 114, 143
    
+		Issue EVAL-WHEN-NON-TOP-LEVEL
    
+		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    
+		Issue COMPILER-LET-CONFUSION
    
+Category:	CLARIFICATION, ENHANCEMENT, CHANGE
    
+Edit History:   6-May-88, V1 by Sandra Loosemore
    
+		9-Jun-88, V2 by Sandra Loosemore
    
+		12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
    
+                21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
    
+		16-Dec-88, V5 by Sandra Loosemore (major restructuring)
    
+		31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
    
+		07-Jan-89, V7 by Sandra Loosemore (add example)
    
+		09-Mar-89, V8 by Sandra Loosemore (more restructuring)
    
+		22-Mar-89, V9 by Sandra Loosemore (add MACROLET stuff)
    
+Status:		Ready for release
    
+
    
+
    
+Problem Description:
    
+
    
+CLtL leaves the interpretation of defining forms such as DEFMACRO and
    
+DEFVAR that appear in other than top-level locations unclear.
    
+
    
+On page 66, it is stated: "It is not illegal to use these forms at
    
+other than top level, but whether it is meaningful to do so depends on
    
+context.  Compilers, for example, may not recognize these forms
    
+properly in other than top-level contexts".  At least one implementation 
    
+has interpreted this to mean that it is permissible to simply refuse
    
+to compile defining macros that do not appear at top-level.
    
+
    
+A further problem is that CLtL p. 145 states that macro functions are
    
+always defined in the null lexical environment.  These semantics would
    
+require it to be a special form, not a macro, since there is no
    
+possible macro expansion that has equivalent semantics under the
    
+processing model presented in issue EVAL-WHEN-NON-TOP-LEVEL.  Under
    
+that model, it ought to be possible for DEFMACRO to be implemented as
    
+expanding into an EVAL-WHEN.  Furthermore, the macro function should
    
+appear in a for-evaluation position in the expansion, such as
    
+(function (lambda ...)).
    
+
    
+
    
+Proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:
    
+
    
+(1) Remove the language from p. 66 of CLtL quoted above.  Clarify that
    
+while defining macros normally appear at top level, it is meaningful
    
+to place them in non-top-level contexts and that the compiler must
    
+handle them properly in all situations.  However, the compile-time side
    
+effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
    
+only take place when the defining macros appear at top-level.
    
+
    
+(2) Remove the language from p. 145 of CLtL referenced above.  Clarify
    
+that all defining macros which create functional objects (including
    
+DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
    
+DEFSETF, as well as DEFUN) must ensure that those functions are
    
+defined in the lexical environment in which the defining form appears.
    
+
    
+(3) Change the description of MACROLET to indicate that the macro
    
+functions it creates are defined in the lexical environment in which
    
+the MACROLET form appears, and not the null lexical environment.
    
+State that declarations and MACROLET and SYMBOL-MACROLET definitions
    
+affect the local macro definitions in a MACROLET, but that the
    
+consequences are undefined if the local macro definitions reference
    
+any local variable or function bindings that are visible in that
    
+lexical environment.
    
+
    
+
    
+Rationale:
    
+
    
+Items (1) and (2) make the rules for when defining macros cause
    
+compile-time side effects to be exactly the same as the rules for when
    
+(EVAL-WHEN (COMPILE) ...) causes compile-time evaluation.  This
    
+provides a simple implementation technique.
    
+
    
+Item (3) makes the handling of MACROLET macro definitions consistent
    
+with DEFMACRO macro definitions.
    
+
    
+
    
+Current Practice:
    
+
    
+Most implementations do allow defining macros in non-top-level places.
    
+However, the rules for when they cause compile-time side-effects are
    
+not always the same as those for EVAL-WHEN.  This is the case in
    
+Lucid Common Lisp, for example.
    
+
    
+Lucid evaluates DEFMACRO macro functions in the lexical environment
    
+in which the DEFMACRO appears, but always evaluates MACROLET macro
    
+functions in the null lexical environment.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Implementations that currently don't compile defining macros correctly
    
+when they appear at non-top-level will have to be changed.
    
+
    
+There will also be changes required to support compile-time definition
    
+of functions in a non-null lexical environment.  These changes
    
+are required to support defining macros such as DEFINE-SETF-METHOD
    
+that require functional objects to be created at compile-time, as well
    
+as to support the changes to DEFMACRO and MACROLET.  (Note that even
    
+though defining macros cause compile-time evaluation only at
    
+top-level, top-levelness does not necessarily imply a null lexical
    
+environment under proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.)
    
+
    
+
    
+Cost to users:
    
+
    
+The changes to DEFMACRO and the other defining macros probably will
    
+cause few problems for users.  Since CLtL didn't require non-top-level
    
+defining macros to be meaningful, assigning them a meaning is a
    
+compatible extension.
    
+
    
+The changes to MACROLET may cause problems for users who have assumed
    
+that, within local macro definitions, global function and variable
    
+definitions are not shadowed by local function and variable bindings.
    
+Code-walking programs will also have to be changed to reflect the new
    
+semantics (see issue SYNTACTIC-ENVIRONMENT-ACCESS).
    
+
    
+
    
+Benefits:
    
+
    
+The notion of defining macros as being somehow special when they
    
+appear at top-level is removed, since their behavior can be explained
    
+using EVAL-WHEN as a primitive.  Allowing defining macros to appear
    
+anywhere instead of restricting them to certain positions results in a
    
+cleaner language design.
    
+
    
+
    
+Discussion:
    
+
    
+This proposal is consistent with the behavior specified in proposal
    
+EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.  In particular, if the compile
    
+time side-effects for defining macros specified in proposal
    
+COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
    
+EVAL-WHEN, the "right" compiler behavior for defining macros at
    
+non-top-level will happen automatically.
    
+
    
+The problems with compile-time definition of functions in a non-null
    
+environment could be avoided by modifying proposal
    
+DEFINING-MACROS-NON-TOP-LEVEL to remove the special treatment for
    
+MACROLET, SYMBOL-MACROLET, and LOCALLY.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105.htm new file mode 100644 index 00000000..735f92cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105_w.htm new file mode 100644 index 00000000..a8afa5e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss105_w.htm @@ -0,0 +1,123 @@ + + + +CLHS: Issue DEFMACRO-BLOCK-SCOPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFMACRO-BLOCK-SCOPE Writeup

    + +
    Forum:		Cleanup
    
+Issue:		DEFMACRO-BLOCK-SCOPE
    
+References:	Issue FLET-IMPLICIT-BLOCK
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 24 Oct 1989, Sandra Loosemore
    
+                V2, 10 Jul 1990, David Moon (reflect vote at November meeting)
    
+Status: This reflects a friendly amendment and the 15-0-1 vote at the November meeting.
    
+
    
+Problem Description:
    
+
    
+Does the scope of the implicit BLOCK that surrounds the body of
    
+DEFMACRO, MACROLET, DEFINE-SETF-METHOD, DEFTYPE, and
    
+DEFINE-COMPILER-MACRO (the forms that define functional objects that
    
+also support destructuring) include the bindings of the variables in
    
+the destructuring pattern?  In other words, is the BLOCK visible
    
+during the evaluation of initialization forms included in the lambda
    
+list?
    
+
    
+It seems clear that in forms such as DEFUN and FLET which do not support
    
+destructuring, the BLOCK surrounds only the body and includes none of
    
+the lambda-variable binding forms.
    
+
    
+There are two proposals, INCLUDES-BINDINGS and EXCLUDES-BINDINGS.
    
+The EXCLUDES BINDING proposal passed unanimously with 1 abstention.
    
+
    
+
    
+Proposal (DEFMACRO-BLOCK-SCOPE:INCLUDES-BINDINGS):
    
+
    
+Clarify that the scope of the implicit BLOCK in the functions defined
    
+by the forms listed above does include the initialization forms within
    
+the lambda list as well as the body forms.
    
+
    
+  Rationale:
    
+
    
+  One can view the destructuring code which binds the variables in the
    
+  lambda list as part of the body of the function (for example, as 
    
+  equivalent to a LET* or DESTRUCTURING-BIND construct), which would
    
+  be inside the scope of the BLOCK in an ordinary function-defining form.
    
+  Some users might find this behavior marginally more useful than the
    
+  other alternative.
    
+
    
+
    
+Proposal (DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS):
    
+
    
+Clarify that the scope of the implicit BLOCK in the functions defined
    
+by the forms listed above includes only the body forms and not the
    
+initialization forms within the lambda list.
    
+
    
+  Rationale:
    
+
    
+  One can view the destructuring code which binds the variables in the
    
+  lambda list as part of the ordinary lambda-list processing (for example,
    
+  as equivalent to binding &AUX variables), which would be outside the
    
+  scope of the BLOCK in an ordinary function-defining form.  Some people
    
+  might find this to be more consistent with the scoping of the BLOCK 
    
+  in the non-destructuring cases.
    
+
    
+
    
+Current Practice:
    
+
    
+Lucid CL, Utah CL, and CMU Common Lisp currently implement proposal
    
+INCLUDES-BINDINGS.  Kyoto CL implements proposal EXCLUDES-BINDINGS.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Probably not too much effort involved to fix it.
    
+
    
+
    
+Cost to users:
    
+
    
+Currently nonportable user programs that depend on this being done the
    
+other way will break, but this is a rather obscure point and it is
    
+unlikely that there would be many programs affected.
    
+
    
+
    
+Benefits:
    
+
    
+The specification of the language is made more precise.
    
+
    
+
    
+Discussion:
    
+
    
+Sandra Loosemore says:
    
+  I don't think this issue is worth spending a lot of time arguing over,
    
+  since both alternatives seem equally plausible to me.  I suggest we
    
+  just adopt whichever alternative that is closest to current practice.
    
+  I'm missing information on several implementations.
    
+
    
+  A sense of the meeting is that DEFUN and other functions were already
    
+  specified in CLTL.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106.htm new file mode 100644 index 00000000..395ff536 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106_w.htm new file mode 100644 index 00000000..056d2d8d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss106_w.htm @@ -0,0 +1,188 @@ + + + +CLHS: Issue DEFMACRO-LAMBDA-LIST Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFMACRO-LAMBDA-LIST Writeup

    + +
    Status: Passed, as amended, Mar 89 X3J13
    
+Issue:        DEFMACRO-LAMBDA-LIST
    
+Forum:	      Cleanup
    
+References:   8.1 Macro Definition (CLtL pp144-151),
    
+	      Issue DESTRUCTURING-BIND
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 30-Jan-89, Version 1 by Pitman
    
+			17-Mar-89, Version 2 by Masinter
    
+			 9-Apr-89, Version 3 by Masinter 
    
+				Incorporate amendments as per Mar 89 X3J13
    
+			10-Apr-89, V.4 Masinter (forgot an amendment)
    
+
    
+Problem Description:
    
+
    
+  The description of the DEFMACRO lambda list currently contains some 
    
+  mis-statements and leaves some ambiguities:
    
+
    
+  1. Can &BODY, &WHOLE, and &ENVIRONMENT appear at recursive levels of the
    
+     DEFMACRO lambda list?
    
+
    
+     The description of &WHOLE (p145) specifies that &WHOLE must occur ``first
    
+     in the lambda list,'' but the description of a lambda list says that 
    
+     ``a lambda may [recursively] appear in place of the parameter name.''
    
+     Consequently, the question arises whether &WHOLE should be permitted to
    
+     be a synonym for &REST at inner levels of a DEFMACRO lambda list.
    
+
    
+     The descriptions of &BODY and &ENVIRONMENT do not contain syntactic
    
+     restrictions on where they may appear.
    
+
    
+  2. Does using &WHOLE affect the pattern of arguments permitted by DEFMACRO.
    
+
    
+Proposal (DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION):
    
+
    
+  1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
    
+
    
+     b. Specify that &WHOLE may appear at any level of a DEFMACRO
    
+        lambda list. At inner levels, the &WHOLE variable is bound to
    
+		the corresponding part of the argument, as with &REST, but
    
+		unlike &REST, other arguments are also allowed.
    
+
    
+     c. Specify that &ENVIRONMENT may only appear at the top level of a
    
+	DEFMACRO lambda list.
    
+
    
+  2. Clarify that using &WHOLE does not affect the pattern of arguments
    
+     specified by DEFMACRO.
    
+
    
+  3. Clarify that  &ENVIRONMENT may appear anywhere in the top level
    
+     of a DEFMACRO lambda list, as in the following examples:
    
+
    
+        (&whole W &environment E A B)   ``After &Whole''
    
+        (&environment E &whole W A B)   ``Before &Whole''
    
+        (&whole W A B &environment E)   ``Last''
    
+        (&whole W A &environment E B)   ``Middle''
    
+
    
+   4. &ENVIRONMENT can only appear once in a DEFMACRO lambda list.
    
+
    
+Examples:
    
+
    
+  1. (DEFMACRO DM1A (&WHOLE FORM A B)  ...) is defined.
    
+     (DEFMACRO DM1B (A (&WHOLE B C &OPTIONAL D) E) ...) is defined.
    
+		It allows simultaneousaccess to the THIRD of the whole
    
+		form as B and to the destructuring of that list into
    
+		C and D.
    
+
    
+     (DEFMACRO DM1C (A B &ENVIRONMENT ENV) ...)     is defined.
    
+     (DEFMACRO DM1D (A (B &ENVIRONMENT ENV) C) ...) is undefined.
    
+
    
+     (DEFMACRO DM1E (A B &BODY X) ...)     is defined.
    
+     (DEFMACRO DM1F (A (B &BODY X) C) ...) is defined.
    
+
    
+  2. (DEFMACRO DM2A (&WHOLE X) `',X)
    
+
    
+     (MACROEXPAND '(DM2A))   => (QUOTE (DM2A))
    
+     (MACROEXPAND '(DM2A A)) is an error.
    
+
    
+     (DEFMACRO DM2B (&WHOLE X A &OPTIONAL B) `'(,X ,A ,B))
    
+     
    
+     (MACROEXPAND '(DM2B))       is an error.
    
+     (MACROEXPAND '(DM2B Q))     => (QUOTE ((DM2B Q) Q NIL))
    
+     (MACROEXPAND '(DM2B Q R))   => (QUOTE ((DM2B Q R) Q R))
    
+     (MACROEXPAND '(DM2B Q R S)) is an error.
    
+
    
+Rationale:
    
+
    
+  1. a. An example on p151 makes it clear that this was the intent.
    
+
    
+	b. There's no cogent reason to forbid &WHOLE at inner levels.
    
+     The example on p.150 uses &WHOLE in a non-top-level position.
    
+
    
+	This simplifies the implementation of DEFMACRO if we introduce a
    
+        DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
    
+
    
+     c. The environment is never different at top level than embedded.
    
+	Permitting &ENVIRONMENT to occur embedded would only encourage
    
+	the misconception that there was a potential difference.
    
+
    
+	This simplifies the implementation of DEFMACRO if we introduce a
    
+        DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
    
+
    
+  2. This allows useful syntax checking.
    
+
    
+     One can always trivially write
    
+	(DEFMACRO ... (&WHOLE FORM &REST IGNORE) ...)
    
+     to get around the error checking this forces.
    
+
    
+  3. <vote at Mar 89 X3J13>
    
+
    
+Current Practice:
    
+
    
+  1. a. Symbolics Genera permits &BODY at any level. This is compatible.
    
+     b. Symbolics Genera seems to permit &WHOLE at any level. When embedded,
    
+	it is treated as a synonym for &REST. 
    
+     c. Symbolics Genera does not permit &ENVIRONMENT except at top level.
    
+	This is compatible.
    
+
    
+  2. Symbolics Genera has this behavior when &WHOLE appears at top level,
    
+     but not at recursive levels (where &WHOLE is treated as a synonym for
    
+     &REST).
    
+
    
+Cost to Implementors:
    
+
    
+  This seems to be what CLtL intended and what most implementations
    
+  perform.
    
+
    
+Cost to Users:
    
+
    
+  We think this is possibly (probably) upward compatible with most
    
+  current practice.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some fuzzy places in DEFMACRO continue to exist.
    
+
    
+  It's harder to introduce DESTRUCTURING-BIND because describing its relation
    
+  to DEFMACRO is difficult.
    
+
    
+Benefits:
    
+
    
+  The language is a little tighter.
    
+
    
+Aesthetics:
    
+
    
+  Negligible impact.
    
+
    
+Discussion:
    
+
    
+  Part 2 of this issue came up during the discussion of DOTTED-MACRO-FORMS
    
+  but was not pursued until now.
    
+
    
+  Pitman supports these clarifications.
    
+
    
+  A previous version disallowed &WHOLE at inner levels, because
    
+  of the mistaken impression that &WHOLE was equivalent to &REST.
    
+  However, additional arguments are not allowed after &REST,
    
+  while they are for &WHOLE.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107.htm new file mode 100644 index 00000000..bca12288 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107_w.htm new file mode 100644 index 00000000..05ca0740 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss107_w.htm @@ -0,0 +1,176 @@ + + + +CLHS: Issue DEFMETHOD-DECLARATION-SCOPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFMETHOD-DECLARATION-SCOPE Writeup

    + +
    Issue:             DEFMETHOD-DECLARATION-SCOPE
    
+References:        DEFMETHOD, GENERIC-FUNCTION, GENERIC-FLET, GENERIC-LABELS,
    
+                   CALL-NEXT-METHOD, NEXT-METHOD-P
    
+Related issues:    DECLARATION-SCOPE
    
+                   ARGUMENT-MISMATCH-ERROR
    
+                   LEXICAL-CONSTRUCT-GLOBAL-DEFINITION
    
+                   METHOD-INITFORM
    
+Category:          CLARIFICATION
    
+Edit history:      v1, 27 Feb 91, Sandra Loosemore
    
+                   v2, 28 Feb 91, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The body of method definition in a DEFMETHOD, GENERIC-FUNCTION,
    
+  GENERIC-FLET, or GENERIC-LABELS form includes an implicit FLET of 
    
+  CALL-NEXT-METHOD and NEXT-METHOD-P.  Can one put declarations at the 
    
+  head of the method body which apply to these bindings?  Do "free" 
    
+  declarations (or declarations that don't apply to bindings) at the 
    
+  head of the method body apply to the definitions of these local 
    
+  functions?  
    
+
    
+
    
+Proposal (DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS):
    
+
    
+  Clarify that:
    
+
    
+  (1) Declarations at the head of the method body that apply to the 
    
+      method's lambda variables are treated as "bound" declarations 
    
+      whose scope is the same as the corresponding bindings.
    
+
    
+  (2) Declarations at the head of the method body that apply to the 
    
+      functional bindings of CALL-NEXT-METHOD or NEXT-METHOD-P apply
    
+      to references to those functions within the method body forms.
    
+      Any outer bindings of these functions and declarations associated 
    
+      with those bindings are shadowed within the method body forms.
    
+
    
+  (3) The scope of "free" declarations at the head of the method body 
    
+      is the entire method body (including any implicit local function 
    
+      definitions), but excluding initialization forms for the lambda 
    
+      variables.
    
+
    
+Rationale:
    
+
    
+  Items (1) and (3) are consistent with the rules from issue 
    
+  DECLARATION-SCOPE.
    
+
    
+  For item (2), it would be counterintuitive if declarations for 
    
+  CALL-NEXT-METHOD or NEXT-METHOD-P that appeared at the head of 
    
+  a method body didn't actually apply to references within the body.
    
+
    
+Examples:
    
+
    
+  (1) Must the call to CALL-NEXT-METHOD be NOTINLINE?
    
+
    
+      (defmethod baz (...)
    
+        (declare (notinline call-next-method))
    
+        ... (call-next-method))
    
+
    
+      Under proposal CORRESPONDS-TO-BINDINGS, the answer is that the
    
+      declaration does apply.  The NOTINLINE declaration applies to
    
+      the local binding of CALL-NEXT-METHOD established within the 
    
+      method definition, not to some outer binding that is shadowed by 
    
+      the local binding.
    
+
    
+  (2) Is the definition of CALL-NEXT-METHOD "safe"?  (See issue 
    
+      ARGUMENT-MISMATCH-ERROR for why it might matter.)
    
+
    
+      (defmethod baz (...)
    
+        (declare (optimize safety))
    
+        ... (call-next-method))
    
+
    
+      Under proposal CORRESPONDS-TO-BINDINGS, the answer is yes.  The
    
+      definition of CALL-NEXT-METHOD is in the scope of the declaration.
    
+
    
+  (3) Must the call to CALL-NEXT-METHOD be NOTINLINE?
    
+
    
+      (defmethod foo (...)
    
+        (declare (notinline call-next-method))
    
+        (generic-flet ((bar (...)
    
+    		         (:method (...)
    
+		            ...
    
+		            (call-next-method)
    
+		            ...)))
    
+          ...))
    
+      
    
+      Under proposal CORRESPONDS-TO-BINDINGS, the answer is no.  The
    
+      NOTINLINE declaration is shadowed by the rebinding of 
    
+      CALL-NEXT-METHOD within the nested method definition.
    
+
    
+
    
+Current Practice:
    
+
    
+  Chestnut's Lisp-to-C translator conforms to this proposal.
    
+
    
+  It appears that PCL puts all the declarations at the head of the
    
+  method body at the head of the resulting lambda-expression, where
    
+  they can be shadowed by the FLET.
    
+
    
+  Lucid 4.0 appears to scope "bound" declarations in accordance with
    
+  this proposal, but not "free" declarations.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably small.  Note, however, that it is necessary for DEFMETHOD
    
+  and GENERIC-FUNCTION to (internally) use something like PARSE-DECLARATIONS
    
+  to compute their macro expansions, in order to sort out which declarations 
    
+  apply to which binding form.  Presumably many implementations have 
    
+  something like that anyway, but the other cases where it's needed (LET*, 
    
+  (LAMBDA ...), LABELS, GENERIC-LABELS) are all special forms and not
    
+  macros.
    
+
    
+Cost to Users:
    
+
    
+  Probably small.
    
+
    
+Cost of non-adoption:
    
+
    
+  Continuing vagueness in the language specification.
    
+
    
+Performance impact:
    
+
    
+  Probably small.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  See the "rationale".
    
+
    
+Discussion:
    
+
    
+  The specification of DEFMETHOD and the other method-defining forms
    
+  doesn't really state explicitly that CALL-NEXT-METHOD and NEXT-METHOD-P
    
+  are required to be locally rebound within method definitions that
    
+  reference them.  (Document 88-002R says they have "lexical scope and 
    
+  indefinite extent".)  However, it's necessary to make this point
    
+  explicit so that the behavior of test case (3) is well-defined.
    
+
    
+  It is assumed to be unambiguous that "bound" declarations that apply 
    
+  to the method's lambda variables can appear at the head of the method 
    
+  body, and that the scope of the declarations is the same as the scope 
    
+  of the variable bindings, although 88-002R doesn't say that explicitly
    
+  either.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108.htm new file mode 100644 index 00000000..b049aa56 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFPACKAGE:ADDITION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFPACKAGE:ADDITION Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFPACKAGE:ADDITION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108_w.htm new file mode 100644 index 00000000..565f0492 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss108_w.htm @@ -0,0 +1,308 @@ + + + +CLHS: Issue DEFPACKAGE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFPACKAGE Writeup

    + +
    Issue:         DEFPACKAGE
    
+
    
+References:    CLtL section 11.7.
    
+               Issue: IN-PACKAGE-FUNCTIONALITY
    
+               Issue: MAKE-PACKAGE-USE-DEFAULT
    
+               Issue: PACKAGE-DELETION
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, 12-Mar-88, Moon
    
+               Version 2, 23-Mar-88, Moon, changes based on discussion
    
+               Version 3, 27-Sep-88, JonL 
    
+                (remove :import, :shadowing-import; allow :export to work on
    
+                 imported and inherited; update references to in-package, etc.)
    
+               Version 4,  1-Oct-88, Masinter
    
+               Version 5, 6-Oct-88, Moon
    
+               Version 6, 6-Oct-88, JonL (little nits)
    
+               Version 7, 2-Nov-88, JonL 
    
+		 (incorporate further discussion; simplify handling of
    
+		  syntactic errors; specify ordering constraints).
    
+
    
+Problem description:
    
+
    
+Many users incorrectly think that package operations can be performed
    
+in any order.  CLtL (p.192) contributes to this misconception.
    
+Programmers need direction on the ordering constraint, especially for
    
+creating packages, since doing things out of order can lead to
    
+confusing or even intractable problems.
    
+
    
+If the definition of a package is scattered throughout a program as a 
    
+number of individual forms, it is very easy to read a symbol before the 
    
+package setup needed to read that symbol correctly has been accomplished. 
    
+Three examples: an inherited symbol that should have been shadowed might 
    
+be accessed; a single-colon prefix might be used for a symbol that hasn't
    
+yet been exported; an internal symbol might be created afresh where a 
    
+symbol that will later be imported or inherited was intended.  These 
    
+problems can be difficult to understand or even to recognize; in some 
    
+cases it is difficult or impossible to correct the situation in the
    
+same Lisp image.
    
+
    
+
    
+Proposal (DEFPACKAGE:ADDITION):
    
+      
    
+Add a DEFPACKAGE macro to the language.  In the description below,
    
+'package-name' and 'symbol-name' can be a symbol or a string; if a 
    
+symbol, only its name matters, not what package it is in.
    
+
    
+The syntax of DEFPACKAGE is
    
+
    
+  (DEFPACKAGE package-name {option}*)
    
+
    
+where each option is a list of a keyword and arguments.  Nothing in a
    
+DEFPACKAGE form is evaluated.
    
+
    
+Standard options for DEFPACKAGE are listed below.   Except for :SIZE, 
    
+options may appear more than once (this is useful primarily for 
    
+:IMPORT-FROM and :SHADOWING-IMPORT-FROM).
    
+
    
+(:NICKNAMES {package-name}*)
    
+        Set the package's nicknames to the specified names.
    
+
    
+(:USE {package-name}*)
    
+        The package is to "use" the other designated packages; that is,
    
+        it will inherit from them.  The default value for this option 
    
+        should be the same as it is for MAKE-PACKAGE (also see the issue
    
+        MAKE-PACKAGE-USE-DEFAULT).
    
+
    
+(:SHADOW {symbol-name}*)
    
+        Create the specified symbols in the package being defined, 
    
+        making them shadows, just as the function SHADOW would do.
    
+
    
+(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
    
+        Find the specified symbols in the specified package, import
    
+        them into the package being defined, and place them on the 
    
+        shadowing symbols list.  In no case will symbols be created in 
    
+        any package other than the one being defined; a continuable error 
    
+        is signaled if no symbol is accessible in the package named 
    
+        package-name for one of the symbol-names.
    
+
    
+(:IMPORT-FROM package-name {symbol-name}*)
    
+        Find the specified symbols in the specified package and import
    
+        them into the package being defined.  In no case will symbols be 
    
+        created in a package other than the one being defined; a continuable
    
+        error is signaled if no symbol is accessible in the package named 
    
+        package-name for one of the symbol-names.
    
+
    
+(:EXPORT {symbol-name}*)
    
+        Find or create symbols with the specified names and export them.
    
+        Note an interaction with the :USE option, since inherited symbols 
    
+        can be used rather than new ones created;  note also an interaction 
    
+        with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since 
    
+	imported symbols can be used rather than new ones created.
    
+
    
+(:INTERN {symbol-name}*)
    
+        Find or create symbols with the specified names.  Note an 
    
+        interaction with the :USE option, since inherited symbols 
    
+        can be used rather than new ones created.  This option is useful if 
    
+        an :IMPORT-FROM or a :SHADOWING-IMPORT-FROM option in a subsequent 
    
+        call to DEFPACKAGE (for some other package) expects to find these 
    
+        symbols accessible but not necessarily external.
    
+
    
+(:SIZE integer)
    
+        Declare the approximate number of symbols expected in the package.
    
+        This is an efficiency hint only, so that the package's table will
    
+        not have to be frequently re-expanded when new symbols are added
    
+        to it (e.g., by reading in a large file "in" that package).
    
+
    
+The order in which the options occur in a DEFPACKAGE form is irrelevant;
    
+but since the effects of the entry-making options are context-sensitive, 
    
+the order in which they will be executed is as follows:
    
+  (1) :SHADOW and :SHADOWING-IMPORT-FROM 
    
+  (2) :USE 
    
+  (3) :IMPORT-FROM and :INTERN
    
+  (4) :EXPORT
    
+Shadows are established first, since they may be necessary to block 
    
+spurious name conflicts when the use link is established.  Use links are 
    
+established next so that :intern and :export may refer to normally 
    
+inherited symbols.  The :export is done last so that it may refer to 
    
+symbols created by any of the other options; in particular, shadows and 
    
+imported symbols can be made external.  Note also the prescription on CLtL 
    
+p.178 to cover the case of calling EXPORT on an inherited symbol.
    
+
    
+DEFPACKAGE creates the package as specified and returns it as its value.
    
+It has no other side effects; e.g., it does not alter the value of *PACKAGE*.
    
+The function COMPILE-FILE should treat top-level DEFPACKAGE forms the
    
+same way it treats the other package-effecting functions (see CLtL p.182).
    
+
    
+If the specified name already refers to an existing package, then the 
    
+name-to-package mapping for that name is not changed.   At most, the 
    
+existing package will be modified to reflect the new definition;  it is 
    
+undefined what happens if the new definition is at variance with the 
    
+current state of that package.  If one of the specified nicknames already
    
+refers to an existing package, then an error is signaled just the same
    
+as MAKE-PACKAGE would.  See the issue PACKAGE-DELETION for undoing the
    
+name-to-package mapping.
    
+
    
+Some DEFPACKAGE errors are, however,  purely syntactic.
    
+  (1) An error should be signaled if :SIZE appears than once.
    
+  (2) Since extended options might be allowed by other implementations, 
    
+      an error should be signaled if an option is present that is not 
    
+      actually supported in this implementation.
    
+  (3) The collection of symbol-name arguments given to the options 
    
+      :SHADOW, :INTERN, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must 
    
+      all be disjoint; additionally, the symbol-name arguments given to 
    
+      :EXPORT and :INTERN must be disjoint. If either condition is 
    
+      violated, an error should be signaled.
    
+Name conflict errors will, of course, be handled by the underlying calls to 
    
+USE-PACKAGE, IMPORT, and EXPORT.
    
+
    
+
    
+Examples:
    
+
    
+;;; An example that "plays it super-safe" by using only strings as names; 
    
+;;;  does not even assume that the package it is read in to "uses" LISP; 
    
+;;   *never* creates any symbols whatsoever in the package that it is read 
    
+;;     in to.
    
+
    
+(LISP:DEFPACKAGE "MY-PACKAGE"
    
+  (:NICKNAMES "MYPKG" "MY-PKG")
    
+  (:USE "LISP")
    
+  (:SHADOW "CAR" "CDR")
    
+  (:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP"  "CONS")
    
+  (:IMPORT-FROM           "VENDOR-COMMON-LISP"  "GC")
    
+  (:EXPORT "EQ" "CONS" "FROBOLA")
    
+  )
    
+
    
+;;; A similar call, mostly using symbols rather than strings as names.
    
+;;; Expects to be read in to a package that "uses" LISP and *may* create
    
+;;;  random internal symbols in that package (such as MY-PACKAGE etc).
    
+
    
+(defpackage my-package
    
+  (:nicknames mypkg :MY-PKG)		;remember CL conventions for case
    
+  (:use lisp)				; conversion on symbols
    
+  (:shadow CAR :cdr #:cons)
    
+  (:export "CONS")			;yes, this is the shadowed one.
    
+  )
    
+
    
+Rationale:
    
+
    
+The availability of DEFPACKAGE encourages putting the entire package 
    
+definition in a single place.  It also encourages putting all the package 
    
+definitions of a program in a single file, which can be loaded before 
    
+loading or compiling anything else that depends on those packages; such a
    
+file can be read in the USER package, avoiding any initial state issues.
    
+
    
+In addition, DEFPACKAGE allows a programming environment to process
    
+the whole package setup as a unit, providing better error-checking and
    
+more assistance with package problems, by dint of global knowledge of
    
+the package setup.
    
+
    
+Current practice:
    
+
    
+Symbolics Common Lisp (SCL) has always had a DEFPACKAGE, and users
    
+prefer it to individual calls to EXPORT, IMPORT, SHADOW, etc.  The SCL
    
+version of DEFPACKAGE has quite a few additional options, but none of
    
+them appears to be necessary to propose for Common Lisp at this time.
    
+This proposal is incompatible with Symbolics DEFPACKAGE in some ways
    
+that will probably not cause major problems.
    
+
    
+Cost to Implementors:
    
+
    
+Small--DEFPACKAGE can be implemented simply as a bunch of
    
+calls to existing functions.
    
+
    
+Cost to Users:
    
+
    
+Small, this is upward compatible.
    
+
    
+Cost of non-adoption:
    
+
    
+Packages continue to be difficult to use correctly.
    
+
    
+Benefits:
    
+
    
+Guide users away from using packages in ways that get them into trouble.
    
+
    
+Esthetics:
    
+
    
+Neutral.
    
+
    
+Discussion:
    
+
    
+It has been suggested that the "Put IN Seven EXtremely Random USEr
    
+Interface COmmands" mnemonic described in CLtL p.191 could be removed;
    
+and with possibly a few exceptions, the special handling of them by
    
+COMPILE-FILE could be removed.  As this would be an incompatible change, 
    
+it is not part of this proposal.  However, a new mnemonic can be offered, 
    
+to help remember the ordering constraints mentioned above:
    
+          I REmember Six USEr Interface Expressions
    
+Each word in the sentence corresponds to one operation listed below:
    
+   I				IN-PACKAGE	;"foot" to stand on
    
+   REmember			REQUIRE		;ensure pre-requisite packages
    
+   Six				SHADOW		;block multiple-inheritances
    
+   USEr				USE-PACKAGE	;go for it!
    
+   Interface			IMPORT		;bring in "foreign" symbols
    
+   EXpressions			EXPORT		;a "face" to show to others.
    
+
    
+It is noted that DEFPACKAGE cannot be used to create two "mutually
    
+recursive" packages, such as:
    
+    (defpackage my-package
    
+      (:use lisp your-package)	      ;requires 'your-package' to exist first
    
+      (:export "MY-FUN"))
    
+    (defpackage your-package
    
+      (:use lisp)
    
+      (:import-from my-package "MY-FUN") ;requires 'my-package' to exist first
    
+      (:export "MY-FUN"))
    
+However, nothing prevents one from using the package-effecting functions 
    
+such as USE-PACKAGE, IMPORT, and EXPORT to establish such links (which
    
+ought to be very rare) after a more standard use of DEFPACKAGE.
    
+
    
+The macroexpansion of DEFPACKAGE could usefully canonicalize the names
    
+into strings, so that even if a source file has random symbols in the
    
+DEFPACKAGE form, the compiled file would only contain strings.
    
+
    
+Frequently additional implementation-dependent options take the
    
+form of a keyword standing by itself as an abbreviation for a list
    
+(keyword T); this syntax should be properly reported as an unrecognized
    
+option in implementations that do not support it.
    
+
    
+Definition forms in Common Lisp usually just establish a name-to-object
    
+mapping; there is little precedent for them to modify other global-context
    
+state.  For this reason, we didn't want DEFPACKAGE also to "go" into the 
    
+new package.  If it did so, like IN-PACKAGE, then the following reasonable 
    
+file would become confused, because it wouldn't all be in one package:
    
+   (in-package "USER")
    
+   (defpackage "WATER"      (:use "LISP")             (:export "FISH"))
    
+   (defpackage "ALCHEMY"    (:use "LISP" "PHLOGISTON) (:export gold))
    
+Should the token 'gold' be read while in the USER package, or in the
    
+the WATER package?
    
+
    
+The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE  be 
    
+incompatibly changed to recognize only existing packages, not to create 
    
+them.  IN-PACKAGE would then not accept any keyword arguments.
    
+
    
+The function MAKE-PACKAGE might also be extended to take all the keywords
    
+that DEFPACKAGE does. This could be the subject of a separate cleanup.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109.htm new file mode 100644 index 00000000..ac33dade --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109_w.htm new file mode 100644 index 00000000..fc97332d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss109_w.htm @@ -0,0 +1,138 @@ + + + +CLHS: Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE Writeup

    + +
    Forum:         Cleanup
    
+Issue:         DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
    
+References:    CLtL page 316
    
+Category:      CHANGE
    
+Edit history:  20-Sep-88, Version 1, Peck
    
+               21-Sep-88, Version 2, Masinter, minor revisions
    
+                8-Jan-89, Version 3, Masinter
    
+
    
+
    
+Problem description:
    
+
    
+Currently, DEFSTRUCT constructor functions can be either the default
    
+constructor function, with *only* keyword arguments, or it can be a 
    
+so-called "By Order of Arguments" constructor function with explicitly
    
+*no* keyword arguments.  Other functions in Common Lisp allow a free
    
+mix of required, optional, and keyword arguments. 
    
+
    
+With the current restriction, it is necessary to hand code a function that
    
+will accept optional and keyword arguments and parse the supplied-p
    
+variables explicitly.  Even so, it is not obvious to the casual programmer
    
+how to provide the same semantics as defstruct does with respect to default
    
+values and the defstruct init-forms.
    
+
    
+Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
    
+
    
+Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs
    
+and the &ALLOW-OTHER-KEYS token in addition to the &OPTIONAL,
    
+&REST and &AUX arguments already allowed. Keyword arguments default
    
+in a manner similar to that of &OPTIONAL arguments: if no default
    
+is supplied in the lambda-list then the slot initform is used;
    
+otherwise the slot is not initialized -- its initial value is
    
+undefined.
    
+
    
+If keyword arguments of the form ((key var) [default [svar]])
    
+are specified, the "slot name" is matched with VAR (and not KEY).
    
+
    
+Additional arguments that do not correspond to slot names but
    
+are merely present to supply values used in subsequent initialization 
    
+computations are allowed.
    
+
    
+
    
+Examples:
    
+
    
+It should be possible to write forms like this:
    
+
    
+(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
    
+					    &key (d 2)
    
+					    &aux e (f 'eff))))
    
+  (a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
    
+
    
+(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
    
+(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
    
+
    
+In the definition:
    
+(defstruct (frob (:constructor create-frob
    
+		(a &key (b 3 have-b) (c-token 'c) 
    
+		        (c (list c-token (if have-b 7 2))))))
    
+	a b c)
    
+
    
+the c-token argument is used merely to supply a value used in the 
    
+initialization of the c slot. The "supplied-p" arguments of
    
+keyword arguments might be of this form.
    
+
    
+Rationale:
    
+
    
+This is a logical extension of the specification which makes some
    
+programming easier.
    
+
    
+Current practice:
    
+
    
+Many implementations signal an error if given &KEY arguments or
    
+arguments that are not slot names. The latest version of IIM Common 
    
+Lisp allows &KEY arguments in this manner. Envos Medley
    
+(Xerox Common Lisp) implements the proposal. 
    
+
    
+Cost to Implementors:
    
+
    
+The modifications to allow intermixed keywords and optionals in implementations
    
+that don't already are likely simple. 
    
+
    
+Cost to Users:
    
+
    
+No cost, this is upward compatible.
    
+
    
+Cost of non-adoption:
    
+
    
+The current situation is non-intuitive and needless restrictive.
    
+
    
+Benefits:
    
+
    
+Much easier for users to write the constructor function they want.
    
+Probably implementation code would be reduced, since this would no 
    
+longer be an error.
    
+
    
+Esthetics:
    
+
    
+Minor improvement since it removes a needless restriction.
    
+
    
+Discussion:
    
+
    
+Possibly  references to "By-position", "positional", and "By Order of
    
+Arguments" constructor function might need to be changed to something else in
    
+the standard.  (They can still be called BOA-constructors, though, right?  :-)
    
+
    
+Version 2 of this proposal was on the January 1989 ballot.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110.htm new file mode 100644 index 00000000..8bfd857a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110_w.htm new file mode 100644 index 00000000..0a6ccfe0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss110_w.htm @@ -0,0 +1,119 @@ + + + +CLHS: Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS Writeup

    + +
    Forum:		Cleanup
    
+Issue:		DEFSTRUCT-CONSTRUCTOR-OPTIONS
    
+References:	DEFSTRUCT; CLtL p. 309, 311, 315-316
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 11 Oct 1989, Sandra Loosemore
    
+
    
+
    
+Problem Description:
    
+
    
+It is permitted to specify multiple :constructor options to DEFSTRUCT,
    
+but the interactions between them are unclear.
    
+
    
+Is it legitimate to specify multiple (:constructor <name>) options to
    
+DEFSTRUCT to get multiple copies of the default keyword constructor
    
+function?
    
+
    
+Does specifying an explicit :constructor option inhibit DEFSTRUCT from
    
+creating the default keyword constructor or does one have to
    
+explicitly say (:constructor nil)?
    
+
    
+
    
+Proposal (DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT):
    
+
    
+Clarify that DEFSTRUCT creates the default keyword constructor only if
    
+no explicit :constructor options are specified, or if the :constructor
    
+option is specified without an argument.
    
+
    
+(:constructor nil) is meaningful only when there are no other
    
+:constructor options specified.  It prevents DEFSTRUCT from generating
    
+any constructors at all.
    
+
    
+Otherwise, DEFSTRUCT builds a constructor function corresponding to
    
+each supplied :constructor option.  It is permissible to specify both
    
+multiple BOA constructors and multiple keyword constructors.
    
+
    
+
    
+Rationale:
    
+
    
+This proposal treats all of the :constructor options uniformly as a
    
+group.  Instead of viewing each individual option as something that
    
+adds to or modifies the behavior, the entire set of specified
    
+:constructor options taken as a whole tell DEFSTRUCT to do something
    
+*instead of* its default behavior.  Treating all :constructor options
    
+uniformly in this respect should make the behavior easier to
    
+understand.
    
+
    
+
    
+Current Practice:
    
+
    
+Varies widely.
    
+
    
+Lucid Common Lisp and Kyoto Common Lisp appear to implement this
    
+proposal.
    
+
    
+Utah Common Lisp currently allows only one keyword constructor.  If a
    
+(:constructor name) option appears more than once, it ignores all but
    
+one.  It always makes a keyword constructor unless (:constructor nil)
    
+is explicitly specified, even if BOA constructors are explicitly
    
+requested.  CMU Common Lisp appears to behave in the same way.
    
+
    
+HPCL-I signals an error if multiple (:constructor name) options appear.
    
+It also always makes a keyword constructor unless (:constructor nil) is
    
+explicitly specified.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Probably wouldn't take more than a few hours to fix.
    
+
    
+
    
+Cost to users:
    
+
    
+Code (that is currently nonportable anyway) that assumes the default
    
+keyword constructor will be created unless it is explictly disabled
    
+with (:constructor nil) would have to be changed.
    
+
    
+
    
+Benefits:
    
+
    
+Increased portability of application code using DEFSTRUCT.
    
+
    
+
    
+Discussion:
    
+
    
+Loosemore supports this proposal even though she would have to fix UCL
    
+to conform to it.
    
+-------
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111.htm new file mode 100644 index 00000000..b796ef73 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111_w.htm new file mode 100644 index 00000000..372559f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss111_w.htm @@ -0,0 +1,253 @@ + + + +CLHS: Issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES Writeup

    + +
    Forum:		Cleanup
    
+Issue:		DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
    
+References:	DEFSTRUCT; CLtL p. 309
    
+                Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (passed)
    
+Category:	CLARIFICATION, CHANGE
    
+Edit History:   V1, 11 Oct 1989, Sandra Loosemore
    
+		V2, 02 Nov 1989, Sandra Loosemore (update discussion)
    
+
    
+
    
+Problem Description:
    
+
    
+Must the symbols which name DEFSTRUCT slots be bound as lambda
    
+variables by the default keyword constructor function?  Normally it
    
+would not matter, but if any of these symbols have been proclaimed
    
+SPECIAL it will affect the dynamic environment in which the slot init
    
+forms are evaluated.
    
+
    
+There are three proposals, BOUND, NOT-BOUND, and VISIBLY-BOUND.
    
+
    
+
    
+Background:
    
+
    
+CLtL requires each default slot init form to be evaluated "in the
    
+lexical environment of the DEFSTRUCT form in which it appeared".  This
    
+means that the obvious technique of supplying the init forms as the
    
+defaults for the keyword arguments in the lambda list of the
    
+constructor function is incorrect, unless care is taken to avoid
    
+shadowing any variable bindings of the symbols which correspond to
    
+those arguments.
    
+
    
+For example, given
    
+    (defstruct foo
    
+        (a <a-init>)
    
+        (b <b-init>)
    
+        (c <c-init>))
    
+
    
+Generating the constructor as
    
+    (defun make-foo (&key (a <a-init>) (b <b-init>) (c <c-init>)) ...)
    
+may not evaluate <b-init> and <c-init> in the correct lexical environment
    
+as specified in CLtL.  Proposal VISIBLY-BOUND would change the specification
    
+to make this the correct behavior.
    
+
    
+One alternative is to wrap the init forms in closures named with gensyms:
    
+    (flet ((#:g1 () <a-init>)
    
+           (#:g2 () <b-init>)
    
+           (#:g3 () <c-init>))
    
+        (defun make-foo (&key (a (#:g1)) (b (#:g2)) (c (#:g3))) ...))
    
+Under proposal BOUND, this would be the correct way to implement the
    
+constructor function.
    
+
    
+Another alternative is to make the lambda variables themselves gensyms:
    
+    (defun make-foo (&key ((:a #:g4) <a-init>)
    
+                          ((:b #:g5) <b-init>)
    
+                          ((:c #:g6) <c-init>)) ...)
    
+Under proposal NOT-BOUND, this would be the correct way to implement the
    
+constructor function.
    
+
    
+(Of course, it's possible that DEFSTRUCT could produce a simplified
    
+expansion in many cases by examining the init forms and/or lexical
    
+environment.)
    
+
    
+Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE implies that BOA constructors
    
+do bind the symbols which name slots as lambda variables, since these
    
+variables can be referenced in the init forms for subsequent
    
+arguments.
    
+
    
+
    
+Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:BOUND):
    
+
    
+Clarify that the symbols which name slots must be bound as lambda
    
+variables by the keyword constructor function, in the order in which
    
+the slots are specified in the DEFSTRUCT form.  Variables for
    
+inherited slots are bound before variables for explitly specified
    
+slots, in the order in which they were specified in the definition of
    
+the inherited structure.  Special bindings of these variables will be
    
+visible during the evaluation of the default init forms for subsequent
    
+slots.  The slot default init forms are still evaluated in the 
    
+lexical environment in which the DEFSTRUCT form itself appears.
    
+
    
+  Rationale:
    
+
    
+  This appears to be closest to the intent of CLtL.
    
+
    
+
    
+Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND):
    
+
    
+Clarify that the symbols which name slots must *not* be bound as
    
+lambda variables by the keyword constructor function.  The slot
    
+default init forms are evaluated in the lexical environment
    
+in which the DEFSTRUCT form itself appears and the dynamic environment
    
+in which the call to the constructor function appears.
    
+
    
+  Rationale:
    
+
    
+  This avoids the overhead of creating and invoking closures to compute
    
+  the default values of the slots for the default keyword constructor.
    
+
    
+
    
+Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:VISIBLY-BOUND):
    
+
    
+Clarify that the symbols which name slots must be bound as lambda
    
+variables by the keyword constructor function, in the order in which
    
+the slots are specified in the DEFSTRUCT form.  Variables for
    
+inherited slots are bound before variables for explitly specified
    
+slots, in the order in which they were specified in the definition of
    
+the inherited structure.  Special bindings of these variables will be
    
+visible during the evaluation of the default init forms for subsequent
    
+slots.  
    
+
    
+Remove the requirement that the slot default init forms be evaluated
    
+in the lexical environment in which the DEFSTRUCT form itself appears.
    
+Instead, require that they be evaluated in a lexical environment that
    
+contains bindings for the previous lambda variables of the constructor
    
+function.  This applies to both the default keyword constructor function
    
+and BOA constructors.
    
+
    
+  Rationale:
    
+
    
+  This alternative corresponds most closely to current practice.  It
    
+  avoids the overhead of creating and invoking closures to compute the
    
+  default values of the slots for both the default keyword constructor
    
+  and BOA constructors.
    
+
    
+
    
+Example/Test Cases:
    
+
    
+(defvar x 'global-x)
    
+(let ((y  'local-y))
    
+    (defstruct baz (x 'x-init) (y x) (z y)))
    
+(make-baz)
    
+
    
+Under proposal BOUND,
    
+    slot X is initialized to X-INIT
    
+    slot Y is initialized to X-INIT
    
+        (since the init form X is evaluated in the dynamic environment
    
+        containing the binding to X-INIT)
    
+    slot Z is initialized to LOCAL-Y
    
+        (since the init form Y is evaluated in the lexical environment in
    
+        which the DEFSTRUCT appears)
    
+
    
+Under proposal NOT-BOUND,
    
+    slot X is initialized to X-INIT
    
+    slot Y is initialized to GLOBAL-X
    
+        (since the constructor does not rebind the special variable X)
    
+    slot Z is initialized to LOCAL-Y
    
+
    
+Under proposal VISIBLY-BOUND,
    
+    slot X is initialized to X-INIT
    
+    slot Y is initialized to X-INIT
    
+        (since the special binding of X made by the constructor is visible)
    
+    slot Z is initialized to X-INIT
    
+        (since the lexical binding of Y made by the constructor is visible)
    
+       
    
+
    
+Current Practice:
    
+
    
+Most implementations (including Lucid CL, HPCL-I, KCL, CMU Common Lisp)
    
+appear to implement proposal VISIBLY-BOUND even though it is in conflict
    
+with what is required by CLtL.
    
+
    
+Utah Common Lisp currently implements proposal NOT-BOUND.
    
+
    
+
    
+Cost to implementors:
    
+
    
+For proposal BOUND, the cost of implementing the proposal correctly is
    
+fairly small.  The cost of implementing it both correctly and efficiently
    
+is potentially much larger.
    
+
    
+For proposal NOT-BOUND, the implementation cost is again fairly small, 
    
+but it still requires essentially the same work as in proposal BOUND to
    
+handle BOA constructors correctly.
    
+
    
+Proposal VISIBLY-BOUND has the least implementation cost, since this
    
+is what most implementations already do and is the least complicated
    
+of the alternatives.
    
+
    
+
    
+Cost to users:
    
+
    
+Adopting any of these proposals would improve the situation faced by
    
+users now.
    
+
    
+Users may find proposal VISIBLY-BOUND to be marginally more useful
    
+than the other alternatives since it allows the values of slots to be
    
+referenced in the subsequent default init forms.
    
+
    
+
    
+Benefits:
    
+
    
+An area of confusion in the language is removed.
    
+
    
+
    
+Discussion:
    
+
    
+Loosemore doesn't care much about which of these alternatives we
    
+adopt, but thinks that leaving this unspecified would be a mistake.
    
+
    
+Margolin says:
    
+  By the way, I prefer this proposal [NOT-BOUND].  I think lexical
    
+  environments should be captured (I think we've fixed everything so
    
+  that init-forms are always evaluated in the appropriate lexical
    
+  environment), but I don't like making the order of slots significant
    
+  by allowing init forms to reference other slots.  Order of slots is
    
+  often constrained by other requirements (such as the :INCLUDE
    
+  hierarchy, or using :TYPE to match a pre-existing structure), so they
    
+  shouldn't have an effect on the semantics of the structure.
    
+
    
+Moon says:
    
+  Surely the default constructor function and "BOA constructors" must work
    
+  compatibly.  Unspecified initforms for optional and keyword arguments in
    
+  a "BOA constructor" default from the slot initform rather than NIL, so
    
+  "BOA constructors" face the same issue as default constructors.
    
+
    
+  VISIBLY-BOUND seems semantically wrong.
    
+
    
+  I would go with BOUND, assuming we can't just get rid of DEFSTRUCT
    
+  entirely.  I don't care about the supposed efficiency issue, which is
    
+  easily gotten around or ignored.
    
+
    
+-------
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112.htm new file mode 100644 index 00000000..f4daf40e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112_w.htm new file mode 100644 index 00000000..e0889900 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss112_w.htm @@ -0,0 +1,115 @@ + + + +CLHS: Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE Writeup

    + +
    Issue:        DEFSTRUCT-COPIER-ARGUMENT-TYPE
    
+Forum:	      X3J13
    
+References:   DEFSTRUCT (X3J13/92-102, pp8-5..6)
    
+Category:     CLARIFICATION
    
+Edit history: 07-Jul-93, Version 1 by Pitman
    
+Status:		Proposal RESTRICT passed 11-1 on letter ballot 93-306.
    
+
    
+
    
+Problem Description:
    
+
    
+ The description of the :COPIER defstruct option doesn't say that the
    
+ consequences of applying the defined copier to an object not of the
    
+ structure type are undefined.
    
+
    
+Proposal (DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT):
    
+
    
+ Change the first sentence of the second paragraph of the description
    
+ of the :COPIER to:
    
+
    
+   The automatically defined copier function is a function of one
    
+   \term{argument}, which must be of the structure type being defined.
    
+
    
+ In addition, the last sentence can be changed to the following:
    
+
    
+   If the DEFSTRUCT :TYPE option was not used, the following
    
+   equivalence applies:
    
+
    
+    (<copier> x) = (copy-structure (the \param{structure-name} x))
    
+
    
+Test Case:
    
+
    
+ (DEFSTRUCT S1 A B C)
    
+ (DEFSTRUCT S2 A B C)
    
+
    
+ (COPY-S2 (MAKE-S1 :A 3)) => ??
    
+
    
+ Before this proposal, it is possible to interpret the definition to say
    
+ that #S(S1 :A 3) might be returned here.  This proposal makes it clear
    
+ that the consequences are in fact undefined.
    
+
    
+Rationale:
    
+
    
+ This gives implementational freedom in a situation where no reasonable
    
+ programmer would say that the behavior should be well-defined.  
    
+
    
+Current Practice:
    
+
    
+ LispWorks 3.1.0 signals an error in the test case (even in low safety code).
    
+
    
+ Symbolics Genera 8.3 returns #S(S1 :A 3) in the test case.
    
+
    
+Cost to Implementors:
    
+
    
+ None.  This change is upward compatible.
    
+
    
+Cost to Users:
    
+
    
+ HOPEFULLY none.   It would be really ugly to imagine anyone taking advantage
    
+ of the room that there is now.
    
+
    
+Cost of Non-Adoption:
    
+
    
+ The spec is less tight.
    
+
    
+Benefits:
    
+
    
+ Aesthetics.
    
+
    
+Editorial Impact:
    
+
    
+ Very small.
    
+
    
+Aesthetics:
    
+
    
+ Mostly the spec (and any resulting code) will be slightly cleaner this way.
    
+
    
+Discussion:
    
+
    
+ This change is in response to comment Margolin #8.
    
+
    
+ Pitman doubts that anyone will actually abuse the loophole that 
    
+ this comment is about, but think's it's reasonable to tighten things
    
+ up just in case.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113.htm new file mode 100644 index 00000000..e57c441c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue DEFSTRUCT-COPIER:ARGUMENT-TYPE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-COPIER:ARGUMENT-TYPE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-COPIER:ARGUMENT-TYPE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113_w.htm new file mode 100644 index 00000000..5eb725e7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss113_w.htm @@ -0,0 +1,183 @@ + + + +CLHS: Issue DEFSTRUCT-COPIER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-COPIER Writeup

    + +
    Issue:               DEFSTRUCT-COPIER
    
+References:          DEFSTRUCT
    
+Related issues:
    
+Category:            CLARIFICATION, CHANGE
    
+Edit history:        V1, 10 May 90, Sandra Loosemore
    
+                     V2, 13 May 90, Sandra Loosemore (update discussion)
    
+		     V3, 29 May 90, Sandra Loosemore (more comments)
    
+
    
+Problem description:
    
+
    
+The description of the :COPIER option to DEFSTRUCT in CLtL
    
+states:
    
+
    
+   The automatically defined copier function simply makes a new
    
+   structure and transfers all components verbatim from the argument
    
+   into the newly created structure.
    
+
    
+This description doesn't make it clear whether the type of the
    
+newly created structure is copied from the argument, or is
    
+determined by the copier function.  This can make a difference
    
+in the case where a copier function defined for one structure
    
+type is passed an argument that belongs to a subtype of the
    
+original type.  Does the result have the "name" of the subtype
    
+and any additional slots present in the subtype but not the
    
+parent type, or does it have the same "name" as the parent 
    
+type and only the slots inherited from that type?
    
+
    
+There are four proposals:  ARGUMENT-TYPE, COPIER-TYPE,
    
+UNSPECIFIED, and REMOVE.
    
+
    
+
    
+Proposal (DEFSTRUCT-COPIER:ARGUMENT-TYPE):
    
+
    
+  Clarify that the type of the result returned by copier functions 
    
+  created by DEFSTRUCT is always exactly the same type as the 
    
+  argument to the copier.  That is, if the argument is of a
    
+  subtype of the structure type for which the copier was defined,
    
+  then the result will also be of that subtype and include all
    
+  the slots of the subtype.
    
+
    
+  Rationale for proposal ARGUMENT-TYPE:
    
+    Some people expect this behavior.
    
+
    
+
    
+Proposal (DEFSTRUCT-COPIER:COPIER-TYPE):
    
+
    
+  Clarify that the type of the result returned by copier functions 
    
+  created by DEFSTRUCT is always exactly the structure type for 
    
+  which the copier was defined.  That is, if the argument is of a
    
+  subtype of the structure type for which the copier was defined,
    
+  the result will be of the supertype only and include only those
    
+  slots that are present in the supertype.
    
+
    
+  Rationale for proposal COPIER-TYPE:
    
+    Some people expect this behavior.
    
+
    
+
    
+Proposal (DEFSTRUCT-COPIER:UNSPECIFIED):
    
+
    
+  Clarify that it is unspecified whether the type of the result 
    
+  returned by copier functions created by DEFSTRUCT is the type
    
+  of the argument to the copier, or the structure type for which the
    
+  copier function was defined.  (In other words, the behavior of
    
+  copier functions is well-defined only when they are passed
    
+  arguments of the exact same type for which the copier was
    
+  defined.)
    
+
    
+  Rationale for proposal UNSPECIFIED:
    
+    Some people don't know what behavior to expect.
    
+
    
+
    
+Proposal (DEFSTRUCT-COPIER:REMOVE):
    
+
    
+  Remove the :COPIER option to DEFSTRUCT.
    
+
    
+  Rationale for proposal REMOVE:
    
+    The feature is so poorly specified it's already useless.
    
+  
    
+
    
+Examples:
    
+
    
+    (defstruct foo a b)
    
+    (defstruct (bar (:include foo)) c d)
    
+    (setq result (copy-foo (make-bar)))
    
+
    
+  Under proposal ARGUMENT-TYPE,
    
+    (type-of result) => BAR
    
+
    
+  Under proposal COPIER-TYPE,
    
+    (type-of result) => FOO
    
+
    
+  Under proposal UNSPECIFIED,
    
+    (type-of result) => either FOO or BAR
    
+
    
+  Under proposal REMOVE, users would have to define their own
    
+  copier functions to have whatever behavior they wanted.
    
+
    
+    
    
+Current Practice:
    
+
    
+  Some Lisps now implement proposal ARGUMENT-TYPE and others implement 
    
+  proposal COPIER-TYPE.  Some Lisps also provide a COPY-STRUCTURE
    
+  function that can be used to make an exact duplicate of any
    
+  structure object.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  Code that relies on any particular behavior is probably not now
    
+  portable anyway.  It doesn't seem like copiers are used very
    
+  much.
    
+
    
+Cost of non-adoption:
    
+
    
+  This part of the language specification remains vague.
    
+
    
+Performance impact:
    
+
    
+  Proposal REMOVE would save space since there would be no
    
+  normally useless copier functions generated by DEFSTRUCT.
    
+  It may be that copier functions defined by hand would be
    
+  considerably less efficient than a copier provided by the
    
+  implementation (which might make use of knowledge about the
    
+  internal layout of structures to do a block memory copy or the
    
+  like).
    
+
    
+Benefits:
    
+
    
+  This part of the language specification becomes more precise.
    
+
    
+Esthetics:
    
+
    
+  Leaving the behavior explicitly vague seems unnecessarily ugly.
    
+
    
+Discussion:
    
+
    
+  Loosemore's ranking of the proposals from most to least
    
+  acceptable is:  ARGUMENT-TYPE, REMOVE, COPIER-TYPE,
    
+  UNSPECIFIED.
    
+
    
+  BarMar has said he thinks the behavior should be left
    
+  unspecified.
    
+
    
+  Moon has said he favors flushing the :copier feature.  Barrett
    
+  also prefers flushing :copier.
    
+
    
+  Perhaps we should consider adding COPY-STRUCTURE to the
    
+  standard?
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114.htm new file mode 100644 index 00000000..4b65aeb0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114_w.htm new file mode 100644 index 00000000..ffe0eed9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss114_w.htm @@ -0,0 +1,157 @@ + + + +CLHS: Issue DEFSTRUCT-DEFAULT-VALUE-EVALUATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-DEFAULT-VALUE-EVALUATION Writeup

    + +
    Issue:          DEFSTRUCT-DEFAULT-VALUE-EVALUATION
    
+References:     CLtL p.308-10 & 86-003 p.4
    
+Category:       CLARIFICATION
    
+Edit history:   Revision 1 by Skona Brittain 05/13/88
    
+
    
+
    
+Problem Description:
    
+
    
+There is some confusion over whether default initialization
    
+forms for defstruct slots get evaluated, when they are not needed
    
+because a keyword argument was supplied to the constructor function.
    
+As a consequence of this confusion, there is confusion over whether
    
+there can be a type-mismatch error between the specified type of the slot
    
+and the type of the default value.
    
+
    
+On page 308, it says "The default-init is a form that is evaluated 
    
+each time a structure is to be constructed; the value is used as the 
    
+initial value of the slot.  If no default-init is specified, then the
    
+initial contents of the slot are undefined and implementation-dependent."
    
+
    
+On the next page, however, it says that the default-init is evaluated if
    
+the keyword argument is not supplied and the converse, although not stated,
    
+is intended and informally implied.
    
+
    
+
    
+Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):
    
+
    
+Clarify that the converse is true. i.e that the default-init is not evaluated 
    
+if the keyword argument is supplied.
    
+
    
+In the quote from page 308, delete the second sentence and replace 
    
+"a structure is to be constructed; the value is" by "its value is to be".
    
+
    
+To section 19.3, add a clarification,
    
+such as the following from Guy's issues file:
    
+       "The default value in a defstruct slot is not evaluated 
    
+        unless it is needed in the creation of a particular structure
    
+        instance.  If it is never needed, there can be no type-mismatch
    
+        error, even if the type of the slot is specified, and no warning
    
+        should be issued."
    
+
    
+
    
+Test Case:
    
+
    
+In the following sequence, only the last call is an error.
    
+
    
+        (defstruct person (name 007 :type string)) 
    
+        (make-person :name "James")
    
+        (make-person)
    
+
    
+
    
+Rationale:
    
+
    
+It is inefficient, and inconsistent with the rest of the language, for the 
    
+default initialization form to be evaluated when it is not needed.
    
+Consequently, when it's not needed, such type-mismatch errors should not be 
    
+detectable in general.
    
+
    
+Any existing confusion should be clarified by this proposal.
    
+
    
+
    
+Current Practice:
    
+
    
+KCL does not evaluate the default initialization form unless it is needed;
    
+even when it is needed, the type checking is not done at all.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+If there are any implementations that currently behave differently from
    
+the proposed way, then they need some slight modification.  
    
+
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+
    
+Benefits:
    
+
    
+Clarity and portability.  In particular, clarifying that the unaesthetic 
    
+situation mentioned in the next section is allowed should be reassuring.
    
+
    
+
    
+Aesthetics:
    
+
    
+It appears slightly unaesthetic to have a default value that violates a 
    
+type specification.  
    
+
    
+
    
+Discussion: 
    
+
    
+Although this issue was mentioned in Guy's original issues file, it has
    
+not been officially discussed since.
    
+
    
+!
    
+Additional notes:
    
+
    
+Several members of the cleanup committee endorsed this proposal.
    
+
    
+JonL added:
    
+
    
+You can add to the "Current Practice:" section:
    
+
    
+    LUCID does not evaluate the default initialization form unless it is 
    
+    needed; even when it is needed, the type checking is not done at all.
    
+    However, at structure definition time, if an initial value form is
    
+    constanp and doesn't satisfy the :type specification, a warning message
    
+    is printed.
    
+
    
+Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
    
+:type specifier, even though init-forms aren't checked.  Furthermore, in 
    
+safety levels 2 or higher, the compiled code will do minimal "memory-
    
+integrity" type checking for SETF's (which is what I suspect the various 
    
+special-purpose microcoded machines do); however except for low-level numeric
    
+types, this is rarely equivalent to what a full type check would do.
    
+
    
+I have long suggested that there should be at least one mode of operation 
    
+such that all :type information is checked when setting values into structure
    
+slots (setf as well as initialization).  Some have suggested that this mode 
    
+could be "when running interpretively, or when when compiled with the highest
    
+degree of SAFETY and lower degrees of SPEED."  However, since the wording of 
    
+CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
    
+some vendors effectively ignore any and all declarations [except for SPECIAL],
    
+then this suggestion hasn't reached proposal stage yet.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115.htm new file mode 100644 index 00000000..8c7a2d5e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115_w.htm new file mode 100644 index 00000000..ccd05fad --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss115_w.htm @@ -0,0 +1,104 @@ + + + +CLHS: Issue DEFSTRUCT-INCLUDE-DEFTYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-INCLUDE-DEFTYPE Writeup

    + +
    Issue:        DEFSTRUCT-INCLUDE-DEFTYPE
    
+Forum:	      Editorial
    
+References:   DEFSTRUCT's :INCLUDE option (pp312-314)
    
+Category:     CLARIFICATION
    
+Edit history: 01-Mar-91, Version 1 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  From time to time, people ask whether they can specify in a :INCLUDE
    
+  to DEFSTRUCT the name of a type which is defined by DEFTYPE to expand
    
+  into a type that was defined by DEFSTRUCT.
    
+
    
+Proposal (DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED):
    
+
    
+  Clarify that the only names which are permissible as type names to
    
+  the :INCLUDE option of DEFSTRUCT are actual names previously defined
    
+  by DEFSTRUCT.
    
+
    
+  Clarify that one implication of this is that the consequences are 
    
+  undefined if a type given to DEFSTRUCT's :INCLUDE option is a type
    
+  defined by DEFTYPE, even if it expands into a type defined by DEFSTRUCT.
    
+
    
+Test Case:
    
+
    
+  (DEFSTRUCT FOO A B)
    
+
    
+  (DEFTYPE FU () 'FOO)
    
+
    
+  (DEFSTRUCT (BAR (:INCLUDE FU)) C)
    
+
    
+Rationale:
    
+
    
+  Permitting DEFTYPE-defined types here might open the door to other
    
+  inconsistencies with DEFTYPE-defined types not being accepted in other
    
+  `reasonable' places.
    
+
    
+  Most implementations probably don't allow this and a change would
    
+  be extra work for implementors.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera signals an error if the :INCLUDE'd type was not
    
+  specifically defined by DEFSTRUCT.
    
+
    
+Cost to Implementors:
    
+
    
+  None. "The consequences are undefined" leaves implementations free to
    
+  do whatever they want.
    
+
    
+Cost to Users:
    
+
    
+  None.  Users de facto can't really rely on this now so portable
    
+  programs shouldn't be effected.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some users will continue to be puzzled about whether the perceived-to-be 
    
+  fascist behavior of some implementations is what was intended.
    
+
    
+Benefits:
    
+
    
+  Users will know what to expect.
    
+
    
+Aesthetics:
    
+
    
+  Doing the full job of making DEFTYPE-defined types acceptable in any
    
+  place might be aesthetic, but that's not what is proposed here, and making
    
+  a lot of little special case exceptions probably isn't so aesthetic.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116.htm new file mode 100644 index 00000000..3e5f3ec6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116.htm @@ -0,0 +1,42 @@ + + + +CLHS: Issue DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116_w.htm new file mode 100644 index 00000000..c6cc527c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss116_w.htm @@ -0,0 +1,164 @@ + + + +CLHS: Issue DEFSTRUCT-PRINT-FUNCTION-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-PRINT-FUNCTION-AGAIN Writeup

    + +
    Forum:		Public Review
    
+Issue:		DEFSTRUCT-PRINT-FUNCTION-AGAIN
    
+References:	Loosemore's public review comment #25 (X3J13/92-1325)
    
+		Norvig's public review comment #8.1 (X3J13/92-2208)
    
+		Pitman's public review comment #7 (X3J13/92-2707)
    
+		Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
    
+		DEFSTRUCT :PRINT-FUNCTION option  (p 8-10 and 8-11)
    
+		PRINT-OBJECT (p 22-55)
    
+Category:	CHANGE
    
+Edit history:	24 Dec 1992, Version 1 by Loosemore
    
+                01 Jan 1993, Version 2 by Loosemore (fix references,
    
+		  add method signature for print-object)
    
+Status:         Parts (2),(3),(4) only passed 6-1, March 1993
    
+
    
+
    
+Problem description:
    
+
    
+  Supplying the :PRINT-FUNCTION option to DEFSTRUCT is supposed to
    
+  be equivalent to defining a PRINT-OBJECT method, but the two can't
    
+  be entirely equivalent since the :PRINT-FUNCTION takes a third
    
+  argument (the current recursive printing depth) that the PRINT-OBJECT
    
+  method does not.
    
+
    
+  It is also not clear whether the inheritance of structure 
    
+  :PRINT-FUNCTIONs by the :INCLUDE option works in such a way that
    
+  one may use CALL-NEXT-METHOD and the like.
    
+
    
+
    
+Proposal (DEFSTRUCT-PRINT-FUNCTION-AGAIN:REPLACE-OPTION):
    
+
    
+  (1) Remove the :PRINT-FUNCTION option to DEFSTRUCT.
    
+
    
+  (2) Add a new DEFSTRUCT option, :PRINT-OBJECT, and document it
    
+      as follows:
    
+
    
+      This option can be used only if :TYPE is not supplied.  The
    
+      argument to :PRINT-OBJECT should be in a form acceptable to
    
+      FUNCTION, and is used when printing structures of this type.
    
+      The function is called with two arguments: the structure to 
    
+      be printed and the stream to print to.
    
+
    
+      Supplying (:PRINT-OBJECT fn) in a DEFSTRUCT definition for
    
+      a structure named s is equivalent to executing
    
+
    
+      (defmethod print-object ((object s) stream)
    
+        (funcall (function fn) object stream))
    
+
    
+      The :PRINT-OBJECT option can also be supplied without an
    
+      argument.  This is equivalent to defining a PRINT-OBJECT
    
+      method which calls a function that prints the structure in
    
+      the default #S notation.  [Kent Pitman's comment #7 proposes
    
+      to name this function PRINT-OBJECT-USING-SLOTS.]
    
+
    
+      If no :PRINT-OBJECT option is provided, then DEFSTRUCT does
    
+      not generate a PRINT-OBJECT method specialized on the named
    
+      structure class.
    
+
    
+  (3) Change places in chapter 22 that refer to "print functions"
    
+      to refer to "PRINT-OBJECT methods" instead.
    
+
    
+  (4) Add to the "Method Signatures" section for PRINT-OBJECT:
    
+
    
+      print-object (object structure-object) stream
    
+
    
+      In the "Description" section for PRINT-OBJECT, state that the
    
+      method on the class structure-object prints the object in the
    
+      default #S notation as described in section 22.1.3.15.
    
+
    
+
    
+Rationale:
    
+
    
+  The addition of PRINT-OBJECT and the pretty-printing protocol makes
    
+  it clear that *PRINT-LEVEL* truncation is handled automatically by
    
+  the printer, so the third argument to :PRINT-FUNCTION functions is
    
+  useless.
    
+
    
+  Simply redefining :PRINT-FUNCTION to take functions of two arguments
    
+  rather than of three would break existing programs.  Replacing it
    
+  with a new option with a different name permits implementations to 
    
+  continue to support the old :PRINT-FUNCTION as an extension, and/or 
    
+  issue diagnostics about obsolete usages.
    
+
    
+  Specifying the behavior of :PRINT-OBJECT entirely in terms of
    
+  PRINT-OBJECT and normal method definition means that the standard
    
+  doesn't have to discuss :PRINT-OBJECT functions as a special case.
    
+  This makes the standard conceptually simpler.
    
+
    
+
    
+Current practice:
    
+
    
+  Nobody ever does anything useful with the third argument to
    
+  :PRINT-FUNCTION functions anyway.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Some implementations will doubtless have to change, but the addition
    
+  of the PRINT-OBJECT and pretty-printer protocols already means that
    
+  many implementations will have to rework their printers anyway.
    
+
    
+
    
+Cost to users:
    
+
    
+  This is an incompatible change, but one that can be detected 
    
+  easily.  Implementations may continue to support :PRINT-FUNCTION
    
+  as an extension for backward compatibility.
    
+
    
+
    
+Aesthetics:
    
+
    
+  I like it.
    
+
    
+
    
+Editorial impact:
    
+
    
+  The references to :PRINT-FUNCTION in the structures and printers
    
+  chapters will have to be changed.
    
+
    
+
    
+Discussion:
    
+
    
+  Barrett notes that the description for the PRINT-OBJECT method on
    
+  standard-object doesn't say anything about how it actually prints
    
+  the objects.  Presumably this is covered by section 22.1.3.16, which
    
+  says that "other objects are printed in an implementation-dependent
    
+  manner".
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117.htm new file mode 100644 index 00000000..99b98c37 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117_w.htm new file mode 100644 index 00000000..1518f2f4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss117_w.htm @@ -0,0 +1,106 @@ + + + +CLHS: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE Writeup

    + +
    Issue:          DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
    
+References:     CLtL p. 312-314
    
+Category:       CLARIFICATION
    
+Edit History:   V1, 5 Aug 1988, Sandra Loosemore
    
+                V2, 15 Sep 1988, Sandra Loosemore
    
+                V3, 7 Dec 1988, Masinter
    
+
    
+Problem Description:
    
+
    
+CLtL doesn't make clear whether defstructs that :INCLUDE another
    
+structure type and do not specify a :PRINT-FUNCTION inherit the
    
+:PRINT-FUNCTION of the parent structure type.  While it is stated on
    
+page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
    
+the language on page 313 indicates that all operations on the parent
    
+type will also work on objects of the child type.  Because of the
    
+ambiguity, existing implementations have gone both ways, and users
    
+cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
    
+being used.
    
+
    
+Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
    
+
    
+Clarify that defstruct types which :INCLUDE another type but do not
    
+specify an explicit :PRINT-FUNCTION inherit the structure print
    
+function from the :INCLUDE'd type.  A print function that uses the
    
+default #S syntax (overriding any print function for the parent type)
    
+can be specified by providing the :PRINT-FUNCTION option without an 
    
+argument.
    
+
    
+Supplying a :PRINT-FUNCTION in a DEFSTRUCT is equivalent
    
+to defining an appropriate method on the PRINT-OBJECT generic
    
+function.
    
+
    
+Rationale:
    
+
    
+Users typically specify a print function for a structure type because
    
+its slots will contain circular objects or large internal data
    
+structures which are confusing when printed.  Any structure type that
    
+:INCLUDEs this type will also contain the same slots; it seems more
    
+reasonable to inherit the parent's print function than to use the
    
+default #S syntax.
    
+
    
+Current Practice:
    
+
    
+Lucid Common Lisp makes structures inherit print functions.
    
+VaxLisp uses #S syntax unless an explicit :PRINT-FUNCTION
    
+is specified.
    
+
    
+Cost to implementors:
    
+
    
+The changes to non-conforming implementations should be fairly minor
    
+and localized.
    
+
    
+
    
+Cost to users:
    
+
    
+It can't be any worse than the status quo.
    
+
    
+
    
+Benefits:
    
+
    
+An area of ambiguity in the language will be removed.
    
+
    
+
    
+Discussion:
    
+
    
+Pitman and VanRoggen support this proposal.
    
+
    
+The original version of the proposal did not provide for a way to
    
+force #S syntax to be used.  This functionality was added to the
    
+current version because there seemed to be general agreement that it
    
+would be useful.  Other alternatives would be to name the function
    
+that does what the #S printer does, or to provide a function that
    
+returns the #S information as a list (as suggested by Waters) so users
    
+can write their own.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118.htm new file mode 100644 index 00000000..6af7dce9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-REDEFINITION:ERROR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-REDEFINITION:ERROR Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-REDEFINITION:ERROR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118_w.htm new file mode 100644 index 00000000..9f424978 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss118_w.htm @@ -0,0 +1,159 @@ + + + +CLHS: Issue DEFSTRUCT-REDEFINITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-REDEFINITION Writeup

    + +
    Status:	Passed (as amended) Jan 89 X3J13
    
+Issue:          DEFSTRUCT-REDEFINITION
    
+References:     DEFSTRUCT (CLtL pp 305-320)
    
+Related-issues: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
    
+Category:       CLARIFICATION
    
+Edit history:   Version 1 by Skona Brittain 07/26/88
    
+		Version 2 by Larry Masinter  7-Jan-89
    
+		Version 3 by Masinter 6-Feb-89 as per Jan 89 X3J13 amendment
    
+
    
+Problem Description:
    
+
    
+The case of a structure type being redefined is not discussed in CLtL. Is
    
+it legal to redefine a DEFSTRUCT? What happens to DEFSTRUCTS that :INCLUDE
    
+the one defined. What things might be "wired in" in compiled code that
    
+refered to the previous DEFSTRUCT?
    
+
    
+Proposal: (DEFSTRUCT-REDEFINITION:ERROR):
    
+
    
+The results of redefining a DEFSTRUCT structure are undefined.
    
+
    
+Rationale:
    
+
    
+DEFSTRUCT is intended as "the most efficient" structure class. DEFCLASS
    
+allows much more flexible structures to be defined. Thus, implementations
    
+should be free to "wire in" much of the behavior of a DEFSTRUCT into
    
+compiled code.
    
+
    
+The issue of redefinition should be addressed since there are always
    
+consequences that affect use of the structures.
    
+
    
+Current Practice:
    
+
    
+None of KCL, Lucid, & Symbolics detect a redefinition.
    
+
    
+Envos Medley goes to some effort to detect if a new structure is
    
+"compatible" with the old -- e.g., slots might change names, initial
    
+values, but, since the space allocated in an instance is determined by the
    
+:TYPE, an incompatible set of :TYPE forms would cause old instances to be
    
+marked "obsolete". (The TYPE-OF an old instance changes to **OBSOLETE**,
    
+for example.)
    
+
    
+Cost to Implementors:
    
+
    
+This proposal attempts to be consistent with current practice.
    
+
    
+Cost to Users:
    
+
    
+It is doubtful that any current programs actually define structures more
    
+than once. Thus, constraints on DEFSTRUCT redefinition primarily affect the
    
+debugging environment.
    
+
    
+Cost of Non-Adoption:
    
+
    
+Confusion.
    
+
    
+Benefits:
    
+
    
+Clarity.
    
+
    
+Aethetics:
    
+
    
+Something that is not well-defined and leads to erratic behavior should be
    
+explicitly considered an error.
    
+
    
+Discussion: 
    
+
    
+Common implementation techniques may cause the following behavior if a
    
+DEFSTRUCT is redefined:
    
+
    
+If the new DEFSTRUCT is identical to the old DEFSTRUCT except for the
    
+initialization forms for slots,  previous structure objects probably can
    
+continue to be accessed with previously compiled slot accessors. DEFSTRUCT
    
+constructor, test functions are proclaimed INLINE, and if these have
    
+changed, previously compiled occurrences of them may behave unpredictably.
    
+
    
+If any change is made to the definiton of the slots (either in number,
    
+name, or :TYPE), attempting to execute a slot accessor of the old
    
+definition may behave unpredictably: if a slot name of the old definition
    
+also names a slot of the new definition, any "compiled" code might use the
    
+old definition instead. 
    
+ 
    
+DEFSTRUCT constructor, test functions may also be proclaimed INLINE, and
    
+may behave unpredictably if previously compiled. In particular, a compiled
    
+occurance of a constructor might have the previously slot initial values
    
+"wired in".
    
+
    
+If the new DEFSTRUCT differs from the old in any aspect other than the
    
+initialization forms for slots, the results of attempting to access any old
    
+instance might result in unspecified behavior. For example, if the size of
    
+the structure became considerably shorter, an old accessor might "access
    
+off the end" of an instance of a new object; it might signal an error or
    
+have other unpredictable results.
    
+
    
+Masinter supports this proposal.  If users want more flexibility than
    
+DEFSTRUCT allows, they should use DEFCLASS.
    
+
    
+Some felt strongly that  just saying it's an error to redefine a structure
    
+but not requiring the error to be signalled will cause users to be confused
    
+by the differing seemingly erratic behavior and code. 
    
+
    
+Programming environments are allowed, encouraged, etc. to allow such
    
+redefinition, perhaps with warning messages. It is beyond the scope of the
    
+language standard to define those interactions, except to note that they
    
+are not portable. 
    
+
    
+Here's an example where reexecuting an EQUAL DEFSTRUCT might result in
    
+different behavior:
    
+
    
+(defvar *token-counter* 0)
    
+(defstruct token (cookie '("unique-string")) (counter (incf
    
+*token-counter*)))
    
+
    
+(defvar *first-token* (make-token))
    
+
    
+(eql (token-cookie *first-token*) (token-cookie (make-token))) => true
    
+
    
+(defstruct token (cookie '("unique-string")) (counter (incf
    
+*token-counter*)))
    
+ 
    
+(eql (token-cookie *first-token*) (token-cookie (make-token))) => false
    
+
    
+I.e., even though the second DEFSTRUCT is EQUAL to the first, the
    
+structures are not EQL.
    
+
    
+This is related to the compiler issue QUOTE-MAY-COPY, but is not the same
    
+issue, since that proposal isn't proposing that QUOTE might copy its value
    
+*every time* it is executed.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119.htm new file mode 100644 index 00000000..c8d8831b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119_w.htm new file mode 100644 index 00000000..7deb743e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss119_w.htm @@ -0,0 +1,126 @@ + + + +CLHS: Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME Writeup

    + +
    Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
    
+References:     CLtL p.308 & 86-003 p.4
    
+Category:       CLARIFICATION
    
+
    
+Edit history:   Version 1 by Skona Brittain 05/13/88
    
+                Version 2, Masinter, 14-Sep-88
    
+                Version 3, Masinter, 23-Sep-88
    
+                Version 4, Masinter, 31-Oct-88
    
+                Version 5, Masinter, 12-Jan-89
    
+
    
+Problem Description:
    
+
    
+The case of two slots of a structure having the same name is not 
    
+discussed in CLtL. Is it allowed?  The problem is that the
    
+name of slot accessors and the keyword arguments of the 
    
+constructor function is determined only by the SYMBOL-NAME
    
+of the slot designator; the meaning of slot accessors and
    
+the constructor function is unspecified.
    
+
    
+Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
    
+
    
+It is an error for two slots in a structure type to have the same symbol-name;
    
+that is, the SYMBOL-NAME of the slot names should not be STRING=.
    
+This holds when they were both named directly by the same call to defstruct
    
+or when one is present by virtue of being in an included structure.
    
+
    
+The situation of expanding a DEFSTRUCT macro with a duplicate name "should
    
+signal an error." (While not yet formally defined, the intent is that 
    
+the error signalling may occur when compiling a file that contains
    
+duplicate names or when evaluating a DEFSTRUCT form with duplicate names
    
+in an interpreter.)
    
+
    
+This proposal only affects the operation of the DEFSTRUCT
    
+macro, and not the STRUCTURE-CLASS or structures defined
    
+with DEFCLASS>
    
+
    
+Examples:
    
+
    
+(defstruct struc slot slot) would be an error.  So would
    
+(defstruct (struc2 (:include struc1)) slot) if preceded by
    
+(defstruct struc1 slot).
    
+
    
+(defstruct struct package-1:slot package-2:slot) is also an
    
+error. Slot accessors are interned in the current *PACKAGE*
    
+at the time of the evalution of the DEFSTRUCT. 
    
+
    
+Rationale:
    
+
    
+Since it would be difficult to prescribe reasonable behavior for
    
+DEFSTRUCT, it should be considered an error.
    
+
    
+Current Practice:
    
+
    
+In KCL, if two slots have the same name, no warning message is 
    
+given but mysterious behavior ensues.  (Their default values are 
    
+both whatever is given for the second one, neither can be given a
    
+different value via a call to the constructor function, only the 
    
+second one's value can be changed by setf...)
    
+
    
+Cost to Implementors:
    
+
    
+None.
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+Possible confusion.
    
+
    
+Benefits:
    
+
    
+Clarity.
    
+
    
+Aethetics:
    
+
    
+Something that is not well-defined and leads to erratic behavior 
    
+should be explicitly considered an error.
    
+
    
+Discussion: 
    
+
    
+Although this issue was mentioned in Guy's original issues file, it has
    
+not been officially discussed since.  
    
+
    
+This issue was first circulated to X3J13 June 1988.
    
+
    
+This proposal does not address the issue of whether NIL is a legitimate
    
+slot name. There seems to be no current reason why it might be prohibitied.
    
+
    
+The compiler committee is proposing to address generally the issue 
    
+of how macro-expansion errors during compile-file might be caught and
    
+turned into compiler warnings.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120.htm new file mode 100644 index 00000000..f7df6e57 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120_w.htm new file mode 100644 index 00000000..2bd1a675 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss120_w.htm @@ -0,0 +1,87 @@ + + + +CLHS: Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER Writeup

    + +
    Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
    
+References:     CLtL p.307 & 86-003 p.4
    
+Category:       CHANGE
    
+Edit history:   Revision 1 by Skona Brittain 05/13/88
    
+
    
+Problem Description:
    
+
    
+Structures defined by defstruct currently are required to have at least
    
+one slot.  This seems to have been a mistake in the design of the language.
    
+
    
+Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):
    
+
    
+Allow a call to defstruct to have zero slot-descriptions.
    
+i.e. change the + to a * in the syntax of calls to defstruct 
    
+given at the bottom of page 307 of CLtL.
    
+
    
+Test Case:
    
+
    
+(defstruct s), which is not allowed according to CLtL, would be allowed.
    
+
    
+Rationale:
    
+
    
+The current restriction is in marked contrast to the generality allowed 
    
+elsewhere in the language.  And removing it slightly increases the 
    
+usefulness of defstruct - by allowing the zero slot case when it may be 
    
+deemed useful and by not requiring a check for it when it doesn't matter.
    
+
    
+Current Practice:
    
+
    
+KCL allows zero slots.  
    
+
    
+Cost to Implementors:
    
+
    
+None for implementations that currently allow zero slots.
    
+Very slight for others.
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+Benefits:
    
+
    
+Slightly increases the usefulness of defstruct and is aesthetic.
    
+
    
+Aesthetics:
    
+
    
+In general, it is more aesthetic to allow for generality rather than to
    
+specifically prohibit a particular case.  And the generality in this case 
    
+is consistent with that of many other features of the language, such as 
    
+that arrays can be empty, functions like + and list can take zero arguments, 
    
+etc.
    
+
    
+Discussion: 
    
+
    
+Although this issue was mentioned in Guy's original issues file, it has
    
+not been officially discussed since.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121.htm new file mode 100644 index 00000000..4a83dcb8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DEFTYPE-DESTRUCTURING:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFTYPE-DESTRUCTURING:YES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFTYPE-DESTRUCTURING:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121_w.htm new file mode 100644 index 00000000..54421a06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss121_w.htm @@ -0,0 +1,110 @@ + + + +CLHS: Issue DEFTYPE-DESTRUCTURING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFTYPE-DESTRUCTURING Writeup

    + +
    Issue:            DEFTYPE-DESTRUCTURING
    
+References:       DEFTYPE
    
+Related issues:   DEFTYPE-KEY
    
+Category:         CLARIFICATION, CHANGE
    
+Edit history:     V1, 23 May 90, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The specification of DEFTYPE is not clear on the issue of whether
    
+  it is supposed to support destructuring.  The description in CLtL
    
+  twice compares its syntax to that of DEFMACRO, leading some
    
+  people to think that it does support destructuring.  However,
    
+  since destructuring is not explicitly mentioned, other people
    
+  think it does not.
    
+
    
+  There are two proposals, YES and NO.
    
+
    
+Proposal (DEFTYPE-DESTRUCTURING:YES):
    
+  
    
+  Clarify that DEFTYPE does support destructuring of the lambda list.
    
+  The lambda-list syntax for DEFTYPE is identical to that of
    
+  DEFMACRO.
    
+
    
+  Rationale for proposal YES:
    
+    Some people think this is the way it was really supposed to
    
+    work, and that supporting destructuring makes the syntax of 
    
+    DEFTYPE more consistent with other defining macros.
    
+
    
+Proposal (DEFTYPE-DESTRUCTURING:NO):
    
+
    
+  Clarify that DEFTYPE does not support destructuring of the lambda
    
+  list.  
    
+
    
+  Rationale for proposal NO:
    
+    This requires minimal changes for implementors.  The use of
    
+    destructuring with DEFTYPE is rare and since some
    
+    implementations do not support it now, code that relies on
    
+    it working is already nonportable.
    
+
    
+Current Practice:
    
+
    
+  Spice Lisp implemented a destructuring DEFTYPE, and a number
    
+  of implementations have copied this behavior.  Other
    
+  implementations do not support destructuring in DEFTYPE.
    
+
    
+Cost to Implementors:
    
+
    
+  For proposal YES, fairly small, since every implementation
    
+  already has support for destructuring for other parts of
    
+  the language.
    
+
    
+  For proposal NO, none.  Implementations that now support 
    
+  destructuring can continue to do so as an extension.
    
+
    
+Cost to Users:
    
+
    
+  None for either proposal.  Code that relies on destructuring 
    
+  with DEFTYPE is already not portable, but on the other hand
    
+  adding destructing support shouldn't break code that doesn't
    
+  use it.
    
+
    
+Cost of non-adoption:
    
+
    
+  Continuing vagueness in this part of the language specification.
    
+
    
+Performance impact:
    
+
    
+  Probably insignificant.
    
+
    
+Benefits:
    
+
    
+  This part of the language specification is made more clear.
    
+
    
+Esthetics:
    
+
    
+  Seems to be a matter of personal taste.
    
+
    
+Discussion:
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122.htm new file mode 100644 index 00000000..51e67328 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DEFTYPE-KEY:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFTYPE-KEY:ALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFTYPE-KEY:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122_w.htm new file mode 100644 index 00000000..24c0234c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss122_w.htm @@ -0,0 +1,130 @@ + + + +CLHS: Issue DEFTYPE-KEY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFTYPE-KEY Writeup

    + +
    Issue:         DEFTYPE-KEY
    
+
    
+References:    CLtL p.50
    
+
    
+Related issues: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
    
+
    
+Category:      CLARIFICATION/ADDITION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+               30-Apr-90, Version 2 by Moon (update current practice)
    
+               4-May-90, Version 3 by Moon (update from comment received)
    
+               9-May-90, Version 4 by Moon (revise according to comments
    
+                        received.  Specifically, remove references to
    
+                        &ENVIRONMENT, take no stand on destructuring, and
    
+                        correct the current practice.)
    
+
    
+Problem description:
    
+
    
+  CLtL p.50 only mentions &OPTIONAL and &REST as allowed lambda-list
    
+  keywords in DEFTYPE.  It doesn't say whether &KEY is allowed too.
    
+
    
+  This is Symbolics issue #18.
    
+
    
+Proposal (DEFTYPE-KEY:ALLOW):
    
+
    
+  Allow &OPTIONAL, &REST, &KEY, &ALLOW-OTHER-KEYS, and &AUX in the
    
+  lambda-list of DEFTYPE.
    
+
    
+  Clarify that unsupplied keyword arguments default to *, not NIL, the same
    
+  as unsupplied optional arguments, if no initform is specified in the
    
+  lambda-list.  &AUX parameters are initialized to NIL if no initform is
    
+  specified.
    
+
    
+Examples:
    
+
    
+  (deftype xarray (&key dimensions (rank '* rank-p) element-type)
    
+    (check-type rank (or (member *) (integer 0 *)))
    
+    (check-type dimensions (or (member *) list))
    
+    `(array ,element-type
    
+            ,(if rank-p rank dimensions)))
    
+
    
+  (check-type z (xarray :rank 2 :element-type double-float))
    
+
    
+  (define-presentation-type command (&key (command-table *command-table*))
    
+     ....)
    
+
    
+  define-presentation-type is similar to deftype but defines some
    
+  additional information about use of the type in user interfaces.
    
+
    
+Rationale:
    
+
    
+  Type specifiers with keyword arguments are used extensively in CLIM
    
+  and CLIM-based applications.
    
+
    
+  &AUX is allowed just for completeness.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0 supports the proposal.
    
+  Lucid 3.0.1 signals an error (&KEY not allowed) for this example.
    
+  Franz Allegro CL 3.1.beta.22 supports the proposal.
    
+  Other implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+  Should be small since this simply makes DEFTYPE support the same
    
+  lambda-list keywords as DEFUN and LAMBDA (which suggests an
    
+  implementation technique of inserting '* where an initform is not
    
+  specified for an &optional or &keyword argument and then making a
    
+  function that is applied to the cdr of the type specifier).
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  CLIM will not fit into Common Lisp as well.  DEFTYPE will be less
    
+  consistent with the rest of the language.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Cost of non-adoption will not be incurred.
    
+
    
+Esthetics:
    
+
    
+  DEFTYPE will be consistent with DEFUN, eliminating an arbitrary
    
+  restriction.
    
+
    
+Discussion:
    
+
    
+  There has been some discussion about whether DEFTYPE supports
    
+  destructuring.  It seems that CLtL pages 50 and 146 may contradict
    
+  each other on this point.  This issue explicitly does not address
    
+  the question of destructuring.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123.htm new file mode 100644 index 00000000..8fba9264 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DEFVAR-DOCUMENTATION:UNEVALUATED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFVAR-DOCUMENTATION:UNEVALUATED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DEFVAR-DOCUMENTATION:UNEVALUATED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123_w.htm new file mode 100644 index 00000000..7ef30b4f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss123_w.htm @@ -0,0 +1,93 @@ + + + +CLHS: Issue DEFVAR-DOCUMENTATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFVAR-DOCUMENTATION Writeup

    + +
    Issue:        DEFVAR-DOCUMENTATION
    
+References:   DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
    
+Category:     CLARIFICATION
    
+Edit history: 30-Jun-87, Version 1 by Pitman
    
+              23-Nov-87, Version 2 by Masinter
    
+
    
+Problem Description:
    
+
    
+CLtL is not explicit about whether the documentation part of DEFVAR,
    
+DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
    
+
    
+Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
    
+
    
+Clarify that the documentation part of DEFVAR, DEFPARAMETER, and DEFCONSTANT
    
+special forms is not evaluated. That is, it must be a literal string, not a form
    
+which evaluates to a string.
    
+
    
+Examples:
    
+
    
+(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) "A documentation string")  ; OK
    
+(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) GENERIC-DOCUMENTATION-STRING)  ;
    
+would be an error
    
+
    
+Rationale:
    
+
    
+To ensure portability, implementations must agree on whether or not this
    
+position is evaluated. Specifying that the position is unevaluated is the
    
+conservative thing to suggest, and consistent with the (unevaluated)
    
+documentation strings in DEFUN, DEFSTRUCT.
    
+
    
+Current Practice:
    
+
    
+Some implementations evaluate this position. Others do not. 
    
+
    
+Cost to implementors:
    
+
    
+Implementations that did not already check might usefully add a check in the
    
+macro expansion for DEFVAR, DEFPARAMETER and DEFCONSTANT to assert that the
    
+DOCUMENTATION, if supplied, was a string. The change is likely trivial.
    
+
    
+Cost to users:
    
+
    
+Code which uses other than a literal string is not portable, so no portable
    
+programs will be broken. Some non-portable programs which rely on a particular
    
+vendor's interpretation would have to be rewritten. Automatic tools to detect
    
+most offending cases could trivially be constructed. (We know of no current
    
+uses.)
    
+
    
+Benefits:
    
+
    
+Code portability would be improved. Some programming environment tools might
    
+assume that documentation strings were determinable without evaluation.
    
+
    
+Aesthetics:
    
+
    
+Slight improvement; this implies consistent treatment for documentation strings
    
+in all defining forms.
    
+
    
+Discussion:
    
+
    
+We think this is a good idea.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124.htm new file mode 100644 index 00000000..5756733b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFVAR-INIT-TIME:NOT-DELAYED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFVAR-INIT-TIME:NOT-DELAYED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFVAR-INIT-TIME:NOT-DELAYED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124_w.htm new file mode 100644 index 00000000..162cd191 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss124_w.htm @@ -0,0 +1,99 @@ + + + +CLHS: Issue DEFVAR-INIT-TIME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFVAR-INIT-TIME Writeup

    + +
    Issue:        DEFVAR-INIT-TIME
    
+References:   DEFVAR (p68)
    
+Category:     CLARIFICATION
    
+Edit history: 23-Apr-87, Version 1 by Pitman
    
+              29-Mar-87, Version 2 by Masinter
    
+
    
+
    
+Problem Description:
    
+
    
+The description of DEFVAR is not completely clear about the time at
    
+which the initialization occurs.
    
+
    
+On p68 it says ``VARIABLE is initialized to the result of evaluating the
    
+form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
    
+is not evaluated unless it is used; this fact is useful if evaluation of
    
+the INITIAL-VALUE form does something expensive like create a large data
    
+structure.''
    
+
    
+At least one implementation interpreted the "unless it is used" to mean
    
+"unless the variable is used" rather than "unless the initial-value is
    
+to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
    
+interpreted as a kind of lazy initialization that happened upon the
    
+variable's first unbound reference. (This interpretation appears to have
    
+been further supported by the additional wording in CLtL about not
    
+creating expensive structures that are not needed.)
    
+
    
+Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
    
+
    
+Clarify that the evaluation of the initial value and the initialization
    
+happen at DEFVAR execution time (if at all). The cause of the confusion
    
+is the statement that the initial value form is not evaluated unless "it
    
+is used".  Better to say that INITIAL-VALUE is evaluated if and only if
    
+the variable does not already have a value.  Then there would be no
    
+confusion about the time of evaluation.
    
+
    
+Rationale:
    
+
    
+This clarification follows the intent of the original Common Lisp
    
+designers.
    
+
    
+Current Practice:
    
+
    
+Nearly all implementations implement the proposed interpretation.
    
+
    
+Adoption Cost:
    
+
    
+None, for most implementations; very small for any the implementation
    
+that adopted delayed evaluation.
    
+
    
+Benefits:
    
+
    
+This clarification makes the semantics of an important primitive more
    
+well-defined.
    
+
    
+Conversion Cost:
    
+
    
+Most users presumably expect the behavior currently in practice in most
    
+dialects. There's not a lot of code where the difference comes into play
    
+anyway. Presumably the conversion cost is fairly trivial.
    
+
    
+Aesthetics:
    
+
    
+Being a clarification, this really doesn't have much aesthetic effect.
    
+
    
+Discussion:
    
+
    
+The cleanup committee supports this clarification.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125.htm new file mode 100644 index 00000000..ee427986 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEFVAR-INITIALIZATION:CONSERVATIVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEFVAR-INITIALIZATION:CONSERVATIVE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEFVAR-INITIALIZATION:CONSERVATIVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125_w.htm new file mode 100644 index 00000000..9775bf9c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss125_w.htm @@ -0,0 +1,96 @@ + + + +CLHS: Issue DEFVAR-INITIALIZATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEFVAR-INITIALIZATION Writeup

    + +
    Issue:        DEFVAR-INITIALIZATION
    
+References:   DEFVAR (p68)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: Version 1 by Pitman 02/26/87
    
+              Version 2 by cleanup committee 15-Mar-87 14:45:18
    
+              Version 3 by Masinter (format) 15-Mar-87 18:34:28
    
+              Version 4 by Masinter  5-Jun-87
    
+
    
+Problem description:
    
+
    
+The description of DEFVAR on p.68 is not adequately clear on what
    
+happens if an initialization value is not provided, as in (DEFVAR FOO).
    
+Does this initialize the variable?
    
+
    
+Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
    
+
    
+If the one-argument form of DEFVAR is used, the value (or lack of value)
    
+of the variable is not changed.
    
+
    
+Rationale:
    
+
    
+In parent languages to CL, such behavior was documented. The omission of
    
+clear documentation in CL is presumably an accident.
    
+
    
+Current Practice:
    
+
    
+Most implementations already do not initialize the variable. Some
    
+implementations, however, assume that the missing initial value defaults
    
+to NIL and assume that the variable is always to be initialized if
    
+unbound.
    
+
    
+Adoption Cost:
    
+
    
+Some implementations suffer a minor incompatible change.  The
    
+modification to systems is presumably trivial.
    
+
    
+Benefits:
    
+
    
+It's sometimes useful to have the ability to declare a variable without
    
+initializing it. More importantly, though, DEFVAR is used by lots of
    
+users in every implementation and it deserves uniform treatment.
    
+
    
+Conversion Cost:
    
+
    
+It's stylistically poor to be relying on the variable to be initialized
    
+without writing the initial value explicitly anyway. Except for very
    
+rare situations where a conditional action is taken based on a BOUNDP
    
+test of the variable, user programs are unlikely to be affected in
    
+practice.
    
+
    
+Very few user programs are likely to be affected. The incidence rate is
    
+probably sufficiently low that the issue of automatic tools for
    
+conversion is irrelevant.
    
+
    
+Aesthetics:
    
+
    
+No significant issues are obvious.
    
+
    
+Discussion:
    
+
    
+The cleanup committee generally supports this clarification.
    
+
    
+[Version 3 was distributed at the last X3J13 meeting. This version has
    
+changed only to bring it in line with the current proposal format.]
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126.htm new file mode 100644 index 00000000..cadd4ad9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DEPRECATION-POSITION:LIMITED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DEPRECATION-POSITION:LIMITED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DEPRECATION-POSITION:LIMITED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126_w.htm new file mode 100644 index 00000000..a901fd65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss126_w.htm @@ -0,0 +1,142 @@ + + + +CLHS: Issue DEPRECATION-POSITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DEPRECATION-POSITION Writeup

    + +
    Issue:        DEPRECATION-POSITION
    
+References:   X3J13 committee and sub-committee meetings
    
+Category:     Policy
    
+Edit history: 12-DEC-88, Version 1 by Chapman
    
+              20-DEC-88, Version 2 by Chapman
    
+              9-JAN-89, Version 3 by Chapman
    
+ 
    
+Problem Description:
    
+ 
    
+When features of a language become outdated due to technology advances,
    
+or unnecessary due to the addition of better features, should the old
    
+features be deprecated from the language, or deleted outright?
    
+ 
    
+Since there has never been a Common Lisp standard before, deprecation
    
+is against a de-facto standard, which may or may not be appropriate.
    
+Deletion, on the other hand, is cleaner, but may generate never-ending
    
+discussion when the standard goes for public review (and even in the
    
+X3J13 meeting).
    
+
    
+In summary, there are two levels:
    
+1) features in CLtL that are not present in ANSI Common Lisp 1989,
    
+2) features in ANSI Common Lisp 1989 that will likely not be present in
    
+future standards;
    
+ 
    
+and the issues are:
    
+a) what features fit into which category
    
+b) how should implementations deal with such features? how can programs be
    
+written to avoid problems with such features?
    
+ 
    
+Proposal (DEPRECATION-POSITION:LIMITED)
    
+ 
    
+Since Common Lisp has been used industrially, it is reasonable to 
    
+assume that any level 1 feature will be a cause for
    
+at least some controversy. Therefore, this proposal suggests that
    
+X3J13 put features categorized as level 1 in a separate package,
    
+and retain features categorized as level 2 in the Lisp package, but
    
+declare them deprecated in the standard.
    
+The members of each level will be determined on a case-by-case basis by 
    
+the X3J13 committee.
    
+ 
    
+Rationale:
    
+ 
    
+The standard should contain information about deprecation since
    
+the topic has been mentioned more than once in X3J13, and since
    
+Common Lisp is such a large language.
    
+
    
+It's not
    
+unreasonable for a language the size of Lisp to get rid of the
    
+never-used tools, but we don't want to generate years of discussion
    
+over a relatively minor issue when the standard goes for public review.
    
+ 
    
+Current Practice:
    
+ 
    
+Fortran successfully deprecated one constant. However, a proposal 
    
+submitted during its latest standardization effort that 
    
+suggested deleting old features in favor of new ones was
    
+opposed vehemently. The Pascal committee is currently opposed
    
+to deprecation, and the SPARC proposal suggests that 
    
+deprecation should be dictated by the marketplace.
    
+ 
    
+ 
    
+Adoption Cost:
    
+ 
    
+None.
    
+ 
    
+Benefits:
    
+ 
    
+This policy will provide a basis for future X3J13 decisions.
    
+ 
    
+Conversion Cost:
    
+ 
    
+None.
    
+ 
    
+Aesthetics:
    
+ 
    
+None.
    
+ 
    
+Discussion:
    
+ 
    
+Comment:
    
+"I personally would argue for not including "deprecated" features in
    
+the standard at all, because including them now will make it harder to
    
+remove them later.  My perception is that ANSI Common Lisp is turning
    
+out to be a much different language than what is described in CLtL,
    
+particularly if CLOS becomes a required part of the language.  If,
    
+with the benefit of hindsight and experience, we now realize that some
    
+"features" described in CLtL were really "bugs", the time to remove
    
+them is *before* they become cast in stone as part of ANSI Common
    
+Lisp.  I suspect that most implementors will continue to provide these
    
+features as extensions anyway, as long as a substantial number of
    
+their customers are still using them."
    
+
    
+Response:
    
+Perhaps most implementors will continue to provide the deleted features,
    
+but they will do that also if they are deprecated. Since the only real
    
+difference between the two is the amount of discussion one will generate
    
+over the other (I think that worrying about future difficulty of getting
    
+rid of the features is not a "real" difference yet), it seems that choosing
    
+the route of least resistance in this case is the wisest course.
    
+ 
    
+Comment: 
    
+"For the most part, X3J13 hasn't been able to deal with 
    
+which features fit into which category until how the categories will
    
+be divided has been resolved. In particular, there are a number of 
    
+features that we didn't want to remove from ANSI Common Lisp 1989 if 
    
+it would be awkward for implementations to continue to support them or 
    
+programs to continue to use them, but wanted to at least declare them 
    
+"obsolete". There's been some debate on whether CHAR-FONT, for 
    
+example , should be deleted before the standard is written, or declared
    
+deprecated within the standard."
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127.htm new file mode 100644 index 00000000..513249e5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DESCRIBE-INTERACTIVE:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DESCRIBE-INTERACTIVE:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DESCRIBE-INTERACTIVE:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127_w.htm new file mode 100644 index 00000000..d438503e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss127_w.htm @@ -0,0 +1,205 @@ + + + +CLHS: Issue DESCRIBE-INTERACTIVE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DESCRIBE-INTERACTIVE Writeup

    + +
    Status:		Proposal NO passed Jan 89 X3J13
    
+Issue:        DESCRIBE-INTERACTIVE
    
+References:   DESCRIBE (p441)
    
+Category:     CLARIFICATION (EXPLICITLY-VAGUE) / CHANGE (NO)
    
+Edit history: 12-Sep-88, Version 1 by Pitman
    
+              23-Sep-88, Version 2 by Masinter
    
+              19-Oct-88, Version 3 by Pierson, invert
    
+              15-Nov-88, Version 4 by Pierson, two-proposal version
    
+
    
+Problem Description:
    
+
    
+  CLtL is not clear about whether DESCRIBE may be interactive.
    
+  While CLtL describes INSPECT as an interactive as an
    
+  interactive version of DESCRIBE, it doesn't make explicit
    
+  that DESCRIBE is non-interactive. In some implementations it is, 
    
+  and in other implementations it is not.
    
+
    
+  Users of systems in which DESCRIBE is not interactive may presume
    
+  that it is safe to call DESCRIBE in a batch applications without
    
+  hanging the application, which can lead to problems.
    
+
    
+Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
    
+
    
+    Specify that DESCRIBE is permitted (though not required) to
    
+    require user input, and that such input should be negotiated
    
+    through *QUERY-IO*.
    
+
    
+    Descriptive information would continue to go to *STANDARD-OUTPUT*.
    
+
    
+  Test Case:
    
+
    
+    The following kind of interaction would be permissible in
    
+    implementations which chose to do it:
    
+
    
+     (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
    
+     (SETF (GETHASH 'FOO *MY-TABLE*) 1)
    
+     (SETF (GETHASH 'BAR *MY-TABLE*) 2)
    
+     (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
    
+     (DESCRIBE *MY-TABLE*)
    
+     #<EQ-HASH-TABLE 259> has 3 entries.
    
+     Do you want to see its contents? (Yes or No) Yes
    
+
    
+  Rationale:
    
+
    
+    This validates current implementations.
    
+
    
+  Current Practice:
    
+
    
+    Symbolics Genera asks some questions interactively when describing
    
+    some kinds of structured data structures, such as hash tables.
    
+    Since users can define their own DESCRIBE methods and took their cue
    
+    from the system, describing some user structures also require such
    
+    interactions.
    
+
    
+  Cost to Implementors:
    
+
    
+    None.
    
+
    
+  Cost to Users:
    
+
    
+    User code which depended on DESCRIBE running without user interaction
    
+    would have to be modified. Such code is not currently fully portable,
    
+    however.
    
+
    
+  Cost of Non-Adoption:
    
+
    
+    Users would not know the straight story about whether they should
    
+    expect interaction from DESCRIBE.
    
+
    
+  Benefits:
    
+
    
+    Implementations which don't do interactive querying in DESCRIBE only
    
+    because they're not 100% sure it's kosher would be free to do it.
    
+
    
+  Aesthetics:
    
+
    
+    Some people might think it's not aesthetic for DESCRIBE to require user
    
+    intervention. Not saying whether it's permissible is probably less
    
+    aesthetic, though.
    
+
    
+Proposal (DESCRIBE-INTERACTIVE:NO):
    
+
    
+    Specify that DESCRIBE is forbidden to prompt for or require
    
+    user input.  Permit implementations to extend describe via keyword
    
+    arguments to prompt for or require user input as long as the default
    
+    action if no keyword arguments are supplied does not prompt for or
    
+    require user input.
    
+
    
+    This is an incompatible change for some implementations.
    
+
    
+  Test Case:
    
+
    
+    The following kind of interaction would be permissible in
    
+    implementations which chose to do it:
    
+
    
+     (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
    
+     (SETF (GETHASH 'FOO *MY-TABLE*) 1)
    
+     (SETF (GETHASH 'BAR *MY-TABLE*) 2)
    
+     (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
    
+     (DESCRIBE *MY-TABLE* :INTERACTIVE T)
    
+     #<EQ-HASH-TABLE 259> has 3 entries.
    
+     Do you want to see its contents? (Yes or No) Yes
    
+
    
+  Rationale:
    
+
    
+    DESCRIBE is the only hook a portable program has for providing
    
+    information about objects to the user.  The potential interactive
    
+    functions of DESCRIBE are also likely to be available via INSPECT.
    
+
    
+  Current Practice:
    
+
    
+    Symbolics Genera asks some questions interactively when describing
    
+    some kinds of structured data structures, such as hash tables.
    
+    Since users can define their own DESCRIBE methods and took their cue
    
+    from the system, describing some user structures also require such
    
+    interactions.
    
+
    
+  Cost to Implementors:
    
+
    
+    Symbolics Genera and other non-conforming implementations will have
    
+    to change.
    
+
    
+  Cost to Users:
    
+
    
+    User code which depends on DESCRIBE running with user interaction
    
+    will have to be modified. Such code is not currently portable,
    
+    however.
    
+
    
+  Cost of Non-Adoption:
    
+
    
+    Users would not have any portable way to have progams inform the
    
+    user about object they are dealing with.  This might be important in
    
+    traces and logs of portable progams or in portable debugging tools.
    
+
    
+  Benefits:
    
+
    
+    It will be easier to provide some types of portable functionality.
    
+
    
+  Aesthetics:
    
+
    
+    This simplifies the language slightly.
    
+
    
+Discussion:
    
+
    
+  Pitman thinks it's important to clarify this issue, but he isn't fussy
    
+  about the particulars.
    
+
    
+  EXPLICITY-VAGUE proposal is the minimal proposal for compatibility
    
+  with current behavior.
    
+
    
+  Some members of the cleanup committee think that EXPLICITLY-VAGUE is
    
+  really a change from the intent of CLtL. However, the current
    
+  sentiment is to be less rather than more specific about the behavior
    
+  of debugging tools (25.3 of CLtL).
    
+
    
+  It might be possible to extend DESCRIBE to have additional 
    
+  keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover 
    
+  additional behavior. 
    
+
    
+  Pierson supports NO because he thinks it's important for there to be
    
+  some way for portable programs to present this sort of information
    
+  to the user.  While the exact data and format presented is
    
+  implementation dependent and thus outside of the bounds of
    
+  standardization, the existance of such data is neither.
    
+
    
+  Moon opposes NO because "it creates extra work for implementors and
    
+  users of at least one implementation, for no compelling reason."
    
+
    
+  Moon suggested as a compromise only allowing DESCRIBE to require
    
+  user input from "interactive streams".  Several other members of the
    
+  committee like this in principle but question whether it's feasible
    
+  since we have neither defined "interactive streams" nor provided any
    
+  portable way to tell if a stream is interactive.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128.htm new file mode 100644 index 00000000..5f969ef9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128_w.htm new file mode 100644 index 00000000..42de8643 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss128_w.htm @@ -0,0 +1,176 @@ + + + +CLHS: Issue DESCRIBE-UNDERSPECIFIED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DESCRIBE-UNDERSPECIFIED Writeup

    + +
    Status:		Passed, as amended, Mar 89 X3J13
    
+Forum:		Cleanup
    
+Issue:		DESCRIBE-UNDERSPECIFIED
    
+References:	CLtL p441-2
    
+		88-002R, DESCRIBE function
    
+Category:	CHANGE, ADDITION
    
+Edit history:	Version 1, 10-Mar-89, Kim A. Barrett
    
+              Version 2,  9-Apr-89, Masinter (as per Mar 89 X3J13)
    
+
    
+Problem description:
    
+
    
+ The CLOS Specification (X3J13 Document 88-002R) changes the definition of the
    
+ function DESCRIBE, making it a generic function.  However, it does not specify
    
+ any of the protocol needed to make user-defined methods interact properly to
    
+ produce some of the effects mentioned in CLtL.  For example, CLtL says that
    
+ sometimes the method for describing an object will involve describing
    
+ something that it finds inside the object, and that such recursive
    
+ descriptions are indented appropriately.  How do user-written methods achieve
    
+ this indentation?  Must they arrange for the indentation explicitly, or is
    
+ there some automatic mechanism that handles it?
    
+
    
+ The new specification does not easily lend itself to certain kinds of features
    
+ which some implementations have included in their versions of DESCRIBE, such
    
+ as analogues to the printer's depth limits (*PRINT-DEPTH*) and circular
    
+ structure detection during recursion (*PRINT-CIRCLE*).
    
+
    
+ In addition, DESCRIBE does not take a stream argument, instead always doing
    
+ output to *STANDARD-OUTPUT*.  This means that a program which wants to use
    
+ DESCRIBE to output some information to a particular stream must rebind
    
+ *STANDARD-OUTPUT* around the call to DESCRIBE.  This is a nuisance, and is
    
+ also potentially a bad idea in implementations which have interrupts and such.
    
+
    
+Proposal DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT:
    
+
    
+ Remove the section of 88-002R which specifies that DESCRIBE is a generic
    
+ function.  Modify DESCRIBE to accept an optional second stream argument, which
    
+ defaults to *STANDARD-OUTPUT*, and which is handled in the same way as the
    
+ stream argument to PRINT (that is, permitting arguments of NIL and T).
    
+ The value of this argument is the stream which output will be directed to. 
    
+ Specify that DESCRIBE is implemented in terms of the generic function
    
+ DESCRIBE-OBJECT, described below.
    
+
    
+ DESCRIBE-OBJECT object stream				[Generic Function]
    
+
    
+  The generic function DESCRIBE-OBJECT writes a description of an object to a
    
+  stream.  The function DESCRIBE-OBJECT is called by the DESCRIBE function; it
    
+  should not be called by the user.
    
+
    
+  Each implementation is required to provide a method on the class
    
+  STANDARD-OBJECT and methods on enough other classes so as to ensure that
    
+  there is always an applicable method.  Implementations are free to add
    
+  methods for other classes.  Users can write methods for DESCRIBE-OBJECT for
    
+  their own classes if they do not wish to inherit an implementation-supplied
    
+  method.
    
+
    
+  ARGUMENTS:
    
+
    
+   The first argument is any Lisp object.  The second argument is a stream; it
    
+   cannot be T or NIL.
    
+
    
+  VALUES:
    
+
    
+   The values returned by DESCRIBE-OBJECT are unspecified.
    
+
    
+  REMARKS:
    
+
    
+   Methods on DESCRIBE-OBJECT may recursively call DESCRIBE.  Indentation,
    
+   depth limits, and circularity detection are all taken care of automatically,
    
+   provided that each method handles exactly one level of structure and calls
    
+   DESCRIBE recursively if there are more structural levels.
    
+
    
+   If this rule is not obeyed, the results are undefined.
    
+
    
+   In some implementations the stream argument passed to a DESCRIBE-OBJECT
    
+   method is not the original stream, but is an intermediate stream that
    
+   implements parts of DESCRIBE.  Methods should therefore not depend on the
    
+   identity of this stream.
    
+
    
+Rationale:
    
+
    
+ This proposal was closely modeled on the CLOS description of PRINT-OBJECT,
    
+ which was well thought out and provides a great deal of functionality and
    
+ implementation freedom.  The same implementation techniques applicable to
    
+ PRINT-OBJECT will be applicable to DESCRIBE-OBJECT.
    
+
    
+ The reason for making the return values for DESCRIBE-OBJECT unspecified is to
    
+ avoid forcing users to include explicit (VALUES) in all their methods.
    
+ DESCRIBE will take care of that.
    
+
    
+Current practice:
    
+
    
+ Probably nobody does precisely what this proposal suggests.
    
+
    
+Cost to Implementors:
    
+
    
+ A fair amount of work may be required, since every method/subfunction of
    
+ DESCRIBE in an implementation may need at least some fixing to be in line with
    
+ this proposal.  On the other hand, that work may already be needed in order to
    
+ conform to 88-002R, and this proposal may make the conversion easier by
    
+ simplifying the translation of an existing implementation of DESCRIBE.
    
+
    
+Cost to Users:
    
+
    
+ Any users who are using an implementation which supports the current CLOS
    
+ specification of DESCRIBE and have defined their own methods will have to
    
+ change them.  CLOS is sufficiently recent that this probably isn't a big
    
+ problem.
    
+
    
+ Those users who have made use of implementation-specific hooks into DESCRIBE
    
+ to define their own methods will likely have to change, but that was already
    
+ the case.
    
+
    
+ Users who are currently binding *STANDARD-OUTPUT* around calls to DESCRIBE may
    
+ wish to change their code.
    
+
    
+Cost of non-adoption:
    
+
    
+ Portable DESCRIBE methods may be difficult to write because the protocol they
    
+ must follow is insufficiently specified.
    
+
    
+Benefits:
    
+
    
+ The constraints on DESCRIBE methods are better specified, making it easier to
    
+ write such methods properly.
    
+
    
+Aesthetics:
    
+
    
+ Minimal.
    
+
    
+Discussion:
    
+
    
+ An additional change which is not included in the present proposal would be to
    
+ make the syntax of DESCRIBE and DESCRIBE-OBJECT be
    
+
    
+  DESCRIBE object &optional stream &key
    
+  DESCRIBE-OBJECT object stream &key
    
+
    
+ allowing implementation-specific extensions to the arguments.  A possible
    
+ standard keyword argument is :VERBOSE, which might be used to specify how much
    
+ output to produce.
    
+
    
+ It might be desirable to define some new describe control variables analogous
    
+ to the printer control variables, ie. *DESCRIBE-LEVEL* and *DESCRIBE-CIRCLE*,
    
+ and possibly *DESCRIBE-LENGTH*.
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129.htm new file mode 100644 index 00000000..e83b6d2f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DESTRUCTIVE-OPERATIONS:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DESTRUCTIVE-OPERATIONS:SPECIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DESTRUCTIVE-OPERATIONS:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129_w.htm new file mode 100644 index 00000000..fa4d36b1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss129_w.htm @@ -0,0 +1,150 @@ + + + +CLHS: Issue DESTRUCTIVE-OPERATIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DESTRUCTIVE-OPERATIONS Writeup

    + +
    Forum:		Public Review
    
+Issue:		DESTRUCTIVE-OPERATIONS
    
+References:	Dalton's public review comment #5 (X3J13/92-2005)
    
+		Section 3.1.2.1.3 (Self-Evaluating Objects), p 3-9
    
+		QUOTE, p 3-65
    
+Category:	CLARIFICATION
    
+Edit history:	30 Dec 1992, Version 1 by Loosemore
    
+Status:		Proposal SPECIFY passed (7+4)-1 on letter ballot 93-306
    
+
    
+
    
+Problem description:
    
+
    
+  Section 3.1.2.1.3 (Self-evaluating objects) states that the
    
+  "consequences are undefined if literal objects, including
    
+  self-evaluating objects, are destructively modified.  A
    
+  similar rule appears on p. 3-65 in the description of QUOTE.
    
+
    
+  What counts as part of such an object for the purposes of this
    
+  rule and consequently cannot be modified?
    
+
    
+  It is important to resolve this, because users do such things
    
+  as put hash table literals in code and then add new key-value
    
+  associations.  It is not clear whether or not this is permitted.
    
+  It is not even clear whether a symbol's property list counts as
    
+  part of the symbol for the purposes of this rule.
    
+
    
+  Other places in the standard that refer to limitations on destructive 
    
+  operations (such as sections 3.6 and 3.7, or the discussion of
    
+  compiler-macros), are similarly vague about exactly which operations
    
+  are considered "destructive".
    
+
    
+
    
+Proposal (DESTRUCTIVE-OPERATIONS:SPECIFY):
    
+
    
+  Specify that the following operations are considered destructive:
    
+
    
+  random-state
    
+    Using it as an argument to the function RANDOM.
    
+
    
+  cons
    
+    Altering or destructively modifying the CAR or CDR of the cons.
    
+
    
+  array
    
+    Altering or destructively modifying any array element;
    
+    changing the fill pointer, dimensions, or displacement of
    
+    the array (regardless of whether the array is actually adjustable);
    
+    or altering the contents of any array that is displaced to this array
    
+    or that otherwise shares its contents with this array.
    
+
    
+  hash-table
    
+    Altering or destructively modifying any key or its corresponding
    
+    value, or adding or removing entries from the hash table.
    
+
    
+  structure-object
    
+    Altering or destructively modifying the contents of any slot.
    
+
    
+  standard-object
    
+    Altering or destructively modifying the contents of any slot, or
    
+    changing the class of the object.
    
+
    
+  readtable
    
+    Altering the readtable-case; altering the syntax type of any
    
+    character in this readtable; altering the reader macro function
    
+    associated with any character in this readtable; or altering the
    
+    reader macro functions associated with characters defined as 
    
+    dispatching macro characters in this readtable.
    
+
    
+  stream
    
+    Performing I/O operations on the stream, or closing the stream.
    
+
    
+  all other types
    
+  (including number, character, symbol, package, pathname, function,
    
+  method, method-combination, condition, restart)
    
+    There are no destructive operations defined on these data types.
    
+    
    
+
    
+Rationale:
    
+
    
+  It solves the problem in a way that is generally consistent with 
    
+  what is considered to be a component of an object for the purposes
    
+  of determining similarity of constants.
    
+
    
+
    
+Current practice:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to users:
    
+
    
+  Unknown.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Specifying this behavior is more aesthetic than leaving it vague.
    
+
    
+
    
+Editorial impact:
    
+
    
+  Probably the easiest way to handle this is to add a new subsection
    
+  to section 3.7 containing the list above, and add appropriate references
    
+  (e.g., in the glossary entry for "destructive").
    
+
    
+
    
+Discussion:
    
+
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130.htm new file mode 100644 index 00000000..84cdb3f2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DESTRUCTURING-BIND:NEW-MACRO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DESTRUCTURING-BIND:NEW-MACRO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DESTRUCTURING-BIND:NEW-MACRO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130_w.htm new file mode 100644 index 00000000..65aa2c0a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss130_w.htm @@ -0,0 +1,207 @@ + + + +CLHS: Issue DESTRUCTURING-BIND Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DESTRUCTURING-BIND Writeup

    + +
    Issue:        DESTRUCTURING-BIND
    
+Forum:	      Cleanup
    
+References:   DEFMACRO (CLtL pp145-151),
    
+	      The LOOP Facility (X3J13/89-004)
    
+Category:     ADDITION
    
+Edit history: 24-Jan-89, Version 1 by Pitman
    
+	      25-Jan-89, Version 2 by Pitman
    
+	      29-Mar-89, Version 3, by Moon, amended based on poll
    
+
    
+Problem Description:
    
+
    
+  Common Lisp programmers have frequently complained that the
    
+  destructuring facility used by DEFMACRO is not made available
    
+  for use in ordinary programming situations involving list data.
    
+
    
+  The presence of a destructuring facility in the recently adopted
    
+  LOOP facility will be likely to make the absence of a separable
    
+  destructuring facility all the more apparent.
    
+
    
+  Prior to the introduction of LET into Maclisp, many people wrote
    
+  their own LET macros. A popular expansion was in terms of a DO
    
+  which did not iterate. eg,
    
+    (LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
    
+  While this practice `worked,' it was not perspicuous and contributed 
    
+  substantially to non-readability: not only were the macros hard to
    
+  understand, but the surface interface itself was not standardized
    
+  and varied in subtle ways. For example, some LET macros allowed GO
    
+  statements while others did not.
    
+
    
+  There is now considerable danger that a lot of people will write
    
+  DESTRUCTURING-BIND variants in terms of a LOOP expression that
    
+  immediately returns.
    
+    (DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
    
+    ==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
    
+  Since the destructuring offered by LOOP is different in subtle ways
    
+  from the destructuring offered by DESTRUCTURING-BIND in implementations
    
+  offering that primitive natively, gratuitous headaches could result.
    
+
    
+Proposal (DESTRUCTURING-BIND:NEW-MACRO):
    
+
    
+  Provide a macro called DESTRUCTURING-BIND which behaves like the
    
+  destructuring bind in DEFMACRO. Specifically...
    
+
    
+  DESTRUCTURING-BIND lambda-list expression {decl}* {form}*   [Macro]
    
+
    
+   Binds the variables specified in LAMBDA-LIST to the corresponding
    
+   values in the tree structure resulting from evaluating EXPRESSION,
    
+   then evaluates the FORMS in the body.
    
+
    
+   Anywhere in the LAMBDA-LIST where a parameter name may appear, and
    
+   where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
    
+   does not otherwise allow a list, a lambda-list may appear in place of
    
+   the parameter name. When this is done, then the argument form that
    
+   would match the parameter is treated as a (possibly dotted) list, to
    
+   be used as an argument forms list for satisfying the parameters in
    
+   the embedded lambda-list.
    
+
    
+   If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
    
+   &ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
    
+   as with any other lambda-list.
    
+
    
+   If the lambda list keyword &BODY appears, it is treated as a synonym
    
+   for &REST.
    
+
    
+   The lambda list keyword &ENVIRONMENT is not allowed.
    
+
    
+   If the lambda list keyword &WHOLE appears, it must be followed by a
    
+   single variable that is bound to the entire expression at the current
    
+   level. &WHOLE and its following variable should appear first in the
    
+   list, before any other parameter or lambda-list keyword.
    
+
    
+   It is also permissible for any level of the LAMBDA-LIST to be dotted,
    
+   ending in a parameter name. This situation is treaed exactly as if
    
+   the aprameter name that ends the list had appeared preceded by &REST
    
+   in a proper list. For example, the notation (X Y . Z) is equivalent
    
+   to (X Y &REST Z).
    
+
    
+   If the result of evaluating the expression does not match the 
    
+   destructuring pattern, an error should be signaled. 
    
+
    
+Test Case:
    
+
    
+  (DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
    
+
    
+  (DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
    
+		      `((ALPHA) ,@(IOTA 3))
    
+    (LIST A B THREE TWO ONE))
    
+  => (ALPHA BEE 3 2 1)
    
+
    
+Rationale:
    
+
    
+  The proposal directly addresses the stated problem, and is current practice
    
+  in numerous implementations. Our charter effectively dictates that where
    
+  feasible we should try to head off the widespread development of uselessly
    
+  different variants of commonplace tools.
    
+
    
+   The intent of the specification is to make DESTRUCTURING-BIND lambda-lists
    
+   compatible with inner-list elements of a macro lambda-list.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
    
+  DESTRUCTURING-BIND, though the details vary slightly.
    
+
    
+  The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
    
+  the pattern is not matched. The TI Explorer version does not.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small. In most cases, it's a matter of renaming and/or exporting an
    
+  already existing symbol. In a few cases, a very small amount of 
    
+  `program interface' code would have to be written.
    
+
    
+Cost to Users:
    
+
    
+  None. This is an upward compatible change.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Loss of the Benefits and Aesthetics cited below.
    
+
    
+Benefits:
    
+
    
+  Users will get a powerful feature they have asked for on many occassions.
    
+
    
+  In implementations which `autoload' code, it would be better for this
    
+  support to be separable so that people could do DESTRUCTURING-BIND
    
+  without demand loading all other LOOP support.
    
+
    
+Aesthetics:
    
+
    
+  Defining this macro centrally for the Common Lisp community will reduce
    
+  subtle deviations, which will in turn have positive aesthetic impact.
    
+
    
+Discussion:
    
+
    
+  JonL observes that although LOOP does destructuring, it can't directly
    
+  make use of the DESTRUCTURING-BIND interface suggested here.
    
+
    
+  Pitman and Gray think a facility of this sort is a good idea, though
    
+  obviously the details may still need a little fleshing out before the
    
+  proposal is ready for vote.
    
+
    
+  To date, the excuse for not satisfying this request has been a
    
+  religious war between factions who want to destructure lists by
    
+  writing
    
+    (DESTRUCTURING-BIND (var1 var2 var3) exp . body)
    
+  and those who want to destructure lists by writing
    
+    (DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
    
+
    
+  The advantage of the former approach is that it is notationally
    
+  concise for the common case of destructuring a list. The disadvantage
    
+  is that it is not extensible to accomodate abstract kinds of
    
+  destructuring.
    
+
    
+  The advantage of the latter approach is that it allows interesting
    
+  extensions that accomodate data-hiding, such as:
    
+    (DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
    
+    (DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
    
+  and later the ability to change the representation of a FOO without
    
+  updating the associated binding forms. The disadvantage is that it
    
+  is more verbose in the common case of destructuring a list, and still
    
+  even more verbose for nested lists.
    
+
    
+  Although destructuring has always existed in DEFMACRO, this has not
    
+  been adequate precedence for deciding the outcome of the religious war
    
+  because DEFMACRO only needs to destructure programs, and programs are
    
+  generally made up only of lists -- not arbitrary user-defined abstract
    
+  data types.
    
+
    
+  The lambda-list form of DESTRUCTURING-BIND in this version is
    
+  not completely compatible with the destructuring done by LOOP
    
+  in three areas: LOOP allows NIL elements of a list to be ignored,
    
+  LOOP does not allow &-keywords, and LOOP destructuring ignores
    
+  extra elements in the list being matched.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131.htm new file mode 100644 index 00000000..1b60c7e2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131_w.htm new file mode 100644 index 00000000..91e1e240 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss131_w.htm @@ -0,0 +1,104 @@ + + + +CLHS: Issue DISASSEMBLE-SIDE-EFFECT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DISASSEMBLE-SIDE-EFFECT Writeup

    + +
    Issue:         DISASSEMBLE-SIDE-EFFECT
    
+References:    DISASSEMBLE (p. 439), COMPILE (p. 439)
    
+Category:      CLARIFICATION
    
+Edit history:  Version 2 by Pierson 12/30/87
    
+               Version 3 by Pierson  1/21/88
    
+	       Version 4 by Pierson  6/10/88 correct VAX Lisp practice
    
+Status:        Ready For Release?
    
+
    
+Problem description:
    
+
    
+The definition of DISASSEMBLE says that "if the relevant function is
    
+not a compiled function, it is first compiled.".  The definition of
    
+COMPILE says that "If name is a non-nil symbol, then the
    
+compiled-function is installed as the global function definition of
    
+the symbol...".  Several implementations have taken this to mean that
    
+if DISASSEMBLE is passed a symbol which has an uncompiled function
    
+definition, then it has the side-effect of (COMPILE 'symbol).
    
+
    
+Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
    
+
    
+Clarify that when DISASSEMBLE compiles a function, it will never
    
+install the newly compiled function.
    
+
    
+Test Cases/Examples:
    
+
    
+    (DEFUN F (A) (1+ A))
    
+    (EQ (SYMBOL-FUNCTION 'F)
    
+	(PROGN (DISASSEMBLE 'F)
    
+	       (SYMBOL-FUNCTION 'F)))
    
+
    
+This code will return T if this proposal is adopted.  Some current
    
+implementations will return T, some will return NIL.
    
+
    
+Rationale:
    
+
    
+Several current implementations of DISASSEMBLE have surprising side
    
+effects, especially for new users.
    
+
    
+Current practice:
    
+
    
+Allegro CL installs the compiled definition.  Lucid, Symbolics, Xerox,
    
+VAX Lisp, and KCL don't install it.
    
+
    
+Cost to Implementors:
    
+
    
+Some implementations will have to make a simple change.
    
+
    
+Cost to Users:
    
+
    
+Very little.  DISASSEMBLE is really part of the environment and is
    
+probably not called by much, if any user code.
    
+
    
+Cost of non-Adoption:
    
+
    
+DISASSEMBLE will continue to surprise less experienced users.
    
+
    
+Benefits:
    
+
    
+DISASSEMBLE will become the predictable debugging function it was
    
+meant to be.
    
+
    
+Aesthetics:
    
+
    
+Some who worried that DISASSEMBLE was supposed to install the compiled
    
+function may find that the language has become a little cleaner.
    
+
    
+Discussion:
    
+
    
+DISASSEMBLE is an environment feature; some question has been raised
    
+as to the place and force of environment features in the standard.
    
+However, this proposal stands if DISASSEMBLE is part of the standard
    
+language.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132.htm new file mode 100644 index 00000000..a1d16f6a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DISPLACED-ARRAY-PREDICATE:ADD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DISPLACED-ARRAY-PREDICATE:ADD Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DISPLACED-ARRAY-PREDICATE:ADD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132_w.htm new file mode 100644 index 00000000..205c046f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss132_w.htm @@ -0,0 +1,139 @@ + + + +CLHS: Issue DISPLACED-ARRAY-PREDICATE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DISPLACED-ARRAY-PREDICATE Writeup

    + +
    Issue:             DISPLACED-ARRAY-PREDICATE
    
+References:        MAKE-ARRAY
    
+Related issues:    ADJUST-ARRAY-DISPLACEMENT
    
+Category:          ADDITION
    
+Edit history:      v1, 13 Feb 1991, Sandra Loosemore
    
+                   v2, 11 Mar 1991, Sandra Loosemore
    
+                   v3, 26 Mar 1991, Sandra Loosemore (amendment from meeting)
    
+Status:            v3 (proposal ADD) accepted by X3J13, Mar 91
    
+
    
+
    
+Problem description:
    
+
    
+  There is no way to determine whether an array is displaced to another
    
+  array.  Having this information available would be helpful to some
    
+  applications that want to dump and restore array contents, either to 
    
+  allow them to detect when sharing of displaced arrays is lost or to
    
+  reconstruct the arrays in such a way that sharing is preserved.
    
+
    
+Proposal (DISPLACED-ARRAY-PREDICATE:ADD):
    
+
    
+  Add a function:
    
+
    
+    ARRAY-DISPLACEMENT <array>                                 [Function]
    
+
    
+    The <array> argument must be an array.  If the array is a displaced
    
+    array, two values are returned:  the array to which it is displaced
    
+    corresponding to the :DISPLACED-TO argument to MAKE-ARRAY, and an
    
+    integer corresponding to the :DISPLACED-INDEX-OFFSET argument to
    
+    MAKE-ARRAY.  If the array is not a displaced array, this function
    
+    returns two values NIL and 0.
    
+
    
+    If ARRAY-DISPLACEMENT is called on an array for which a non-NIL
    
+    object was provided as the :DISPLACED-TO argument to MAKE-ARRAY 
    
+    or ADJUST-ARRAY, it must return that object as its first value.  
    
+    It is implementation-dependent whether ARRAY-DISPLACEMENT returns
    
+    a non-NIL first value for any other array.
    
+
    
+    
    
+Examples:
    
+
    
+  (array-displacement '#(1 2 3))
    
+    => the values are not specified, but are probably NIL and 0 in many
    
+       implementations.
    
+  (array-displacement (make-array 2 :displaced-to '#1=#(1 2 3)))
    
+    => (values #1# 0)
    
+
    
+Rationale:
    
+
    
+  Providing the function solves the problem.
    
+
    
+  Some implementations implicitly displace some arrays.  (For example,
    
+  adjustable arrays might be represented as displaced arrays.)  Permitting
    
+  ARRAY-DISPLACEMENT to return non-NIL for those arrays allows those
    
+  implementations not to have to record some additional information 
    
+  in the array about whether an explicit :DISPLACED-TO was provided.
    
+
    
+Current Practice:
    
+
    
+  Lucid version 4.0 and Apple's Macintosh Common Lisp implement such
    
+  a function, but call it DISPLACED-ARRAY-P.
    
+
    
+  Symbolics has an ARRAY-DISPLACED-P predicate but it returns neither 
    
+  the array nor an index, just a boolean.
    
+
    
+Cost to Implementors:
    
+
    
+  It's probably easy to add.
    
+
    
+Cost to Users:
    
+
    
+  None, this is a new feature.
    
+
    
+Cost of non-adoption:
    
+
    
+  Users can't do some kind of manipulations on displaced arrays in a 
    
+  portable way.
    
+
    
+Performance impact:
    
+
    
+  Probably none.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Looks OK to me.
    
+
    
+Discussion:
    
+
    
+  The addition of such a function was mentioned in the writeup for
    
+  proposal ADJUST-ARRAY-DISPLACEMENT as something that had been
    
+  considered at that time.  I don't recall what the arguments were 
    
+  against it.
    
+
    
+  A more extreme proposal would also define ARRAY-DISPLACEMENT as
    
+  a SETF place, to allow these parameters of displaced arrays to 
    
+  be changed.
    
+
    
+  The original name suggested for this function was DISPLACED-ARRAY-P.
    
+
    
+  JonL notes:
    
+
    
+    The reason Lucid has DISPLACED-ARRAY-P is that is the name Guy Steele
    
+    gave it back it 6-Dec-85 -- the "Clarifications" and
    
+    "non-controversial ..." lists.  Quite possibly, it had been suggested
    
+    already in the common-lisp@su-ai forum.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133.htm new file mode 100644 index 00000000..bf6a471b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133_w.htm new file mode 100644 index 00000000..56b1004d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss133_w.htm @@ -0,0 +1,99 @@ + + + +CLHS: Issue DO-SYMBOLS-BLOCK-SCOPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DO-SYMBOLS-BLOCK-SCOPE Writeup

    + +
    Issue:             DO-SYMBOLS-BLOCK-SCOPE
    
+References:        DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
    
+Related issues:
    
+Category:          CLARIFICATION
    
+Edit history:      v1, 13 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  It's not clear what the scope of the implicit NIL block surrounding
    
+  a DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, or DO-ALL-SYMBOLS form is.  Does
    
+  it include only the body forms or the entire form?
    
+
    
+
    
+Proposal (DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM):
    
+
    
+  Clarify that the implicit NIL block effectively surrounds the entire
    
+  DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, or DO-ALL-SYMBOLS form.
    
+
    
+Rationale:
    
+
    
+  This is consistent with DO, DO*, DOLIST, and DOTIMES.
    
+
    
+Examples:
    
+
    
+  (block nil
    
+      (do-symbols (s (or (find-package "FROB") (return nil)))
    
+          (print s))
    
+      t)
    
+
    
+  => always returns T since BLOCK referred to by the RETURN is the
    
+     implicit BLOCK established by DO-SYMBOLS, not the explicit outer
    
+     BLOCK.
    
+
    
+
    
+Current Practice:
    
+
    
+  Lucid version 4.0 implements this proposal.
    
+  Allegro version 3.1 implements DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS
    
+  according to this proposal, but not DO-SYMBOLS.
    
+  Chestnut's Lisp-to-C translator implements this proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Implementations will differ and the language specification will be vague,
    
+  without any good reason.
    
+
    
+Performance impact:
    
+
    
+  Probably none.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Making the language consistent is a good thing.
    
+
    
+Discussion:
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134.htm new file mode 100644 index 00000000..d637c47e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DO-SYMBOLS-DUPLICATES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DO-SYMBOLS-DUPLICATES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DO-SYMBOLS-DUPLICATES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134_w.htm new file mode 100644 index 00000000..974fc8f6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss134_w.htm @@ -0,0 +1,115 @@ + + + +CLHS: Issue DO-SYMBOLS-DUPLICATES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DO-SYMBOLS-DUPLICATES Writeup

    + +
    Issue:        DO-SYMBOLS-DUPLICATES
    
+References:   DO-SYMBOLS, CLtL p.187
    
+Category:     Clarification
    
+Edit history: Version 1 by Fahlman 17-Apr-87
    
+              Version 2 by Masinter 29-May-87
    
+              Version 3 by Masinter 23-Nov-87
    
+
    
+Problem Description:
    
+
    
+CLtL specifies that DO-SYMBOLS executes the body once for each symbol
    
+accessible in the package.  It does not say whether it is permissible
    
+for the body to be executed more than once for some accessible symbols.
    
+The term "accessible" is defined on page 172 to include symbols
    
+inherited from other packages (not including any symbols that may be
    
+shadowed).  It is very expensive in some implementations to eliminate
    
+duplications that occur because the same symbol is inherited from
    
+multiple packages.
    
+
    
+Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
    
+
    
+Add to the specification of DO-SYMBOLS a note that it may execute the
    
+body more than once for some symbols.
    
+
    
+Example:
    
+
    
+(SETQ A (MAKE-PACKAGE 'A))
    
+(SETQ B (MAKE-PACKAGE 'B))
    
+(EXPORT (INTERN "ASYM" A) A)
    
+(USE-PACKAGE A B)
    
+(EXPORT 'B::ASYM B)
    
+(USE-PACKAGE B A)
    
+(DO-SYMBOLS (X B) (PRINT X)) 
    
+;; this may print ASYM once or twice.
    
+
    
+Rationale:
    
+
    
+Most uses of DO-PACKAGE would not be harmed by the presence of
    
+duplicates.  For these applications it is unreasonable to force users to
    
+pay the high cost of filtering out the duplications.  Users who really
    
+want the duplicates to be removed can add additional code to do this job.
    
+
    
+Current Practice:
    
+
    
+Many implementations have always produced duplicate values.
    
+
    
+Cost to implementors:
    
+
    
+None.  Implemenations would still be free to eliminate the duplications,
    
+though code will not be assuming that this has been done.
    
+
    
+Cost to users:
    
+
    
+Code written assuming that DO-SYMBOLS eliminates duplications
    
+will have to be modified. (Such code was not truly portable.)
    
+
    
+Benefits:
    
+
    
+Clarification of a situation that is currently ambiguous.
    
+
    
+Aesthetics:
    
+
    
+It would be cleaner to present each symbol exactly once.  This is a
    
+clear case of choosing efficiency over elegance.
    
+
    
+Discussion:
    
+
    
+This issue was discussed on the Common Lisp mailing list in 1985, and
    
+the solution proposed here seems to have been informally agreed to at
    
+the time -- there was no formal decision-making process in place then.
    
+
    
+The need for do-symbols to be efficient is questionable, however; for 
    
+many applications (e.g., global package manipulation), duplicate values
    
+would create havoc. 
    
+
    
+For some implementations, the performance penalty would be well over 
    
+a factor of two.
    
+
    
+Several proposals were considered for adding keyword arguments
    
+to DO-SYMBOLS which might specify :ALLOW-DUPLICATES, adding keywords
    
+and eliminating DO-EXTERNAL-SYMBOLS, etc., but no clear consensus
    
+was reached for making additions.
    
+
    
+This version is the closest to the status quo.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135.htm new file mode 100644 index 00000000..527a7874 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135.htm @@ -0,0 +1,46 @@ + + + +CLHS: Issue DOCUMENTATION-FUNCTION-BUGS:FIX Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DOCUMENTATION-FUNCTION-BUGS:FIX Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DOCUMENTATION-FUNCTION-BUGS:FIX:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135_w.htm new file mode 100644 index 00000000..36911a1c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss135_w.htm @@ -0,0 +1,217 @@ + + + +CLHS: Issue DOCUMENTATION-FUNCTION-BUGS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DOCUMENTATION-FUNCTION-BUGS Writeup

    + +
    Issue:               DOCUMENTATION-FUNCTION-BUGS
    
+References:          DOCUMENTATION function 
    
+Related issues:      DEFINE-COMPILER-MACRO
    
+                     DEFINE-DECLARATION-BODY
    
+                     SYNTACTIC-ENVIRONMENT-ACCESS
    
+                     DEFPACKAGE
    
+Category:            CHANGE, ADDITION
    
+Edit history:        V1, 12 Feb 1991, Sandra Loosemore
    
+                     V2, 11 Mar 1991, Sandra Loosemore
    
+                     V3, 26 Mar 1991, Sandra Loosemore (incorporate amendments)
    
+Status:              V3 (proposal FIX) accepted by X3J13, Mar 1991
    
+
    
+Problem description:
    
+
    
+  There are a number of problems with the specification of the 
    
+  DOCUMENTATION function.  In particular, there are accessors missing
    
+  for accessing the documentation strings from some defining macros
    
+  (notably, DEFINE-COMPILER-MACRO).  Also, there is a method defined
    
+  that specializes on class STANDARD-SLOT-DESCRIPTION, which is not
    
+  defined anywhere in the standard.
    
+
    
+  The numbered items in the proposal are more or less independent of
    
+  each other and could be voted on individually.  Some items are
    
+  probably more controversial than others.
    
+
    
+
    
+Proposal (DOCUMENTATION-FUNCTION-BUGS:FIX)
    
+
    
+  (1) Add doc-type COMPILER-MACRO for accessing documentation strings
    
+      from DEFINE-COMPILER-MACRO forms.
    
+
    
+      Clarify that documentation strings from DEFINE-MODIFY-MACRO
    
+      forms can be accessed using doc-type FUNCTION.
    
+
    
+      Clarify that documentation strings from DEFINE-SETF-METHOD
    
+      forms can be accessed using doc-type SETF.
    
+
    
+    Rationale:
    
+
    
+      Presumably these were all oversights.
    
+
    
+  (2) Clarify that documentation strings from DEFSTRUCT forms that
    
+      do not specify the :TYPE option (that is, those that define 
    
+      classes) can also be accessed by
    
+        (DOCUMENTATION <structure-class-object>)
    
+      and
    
+        (DOCUMENTATION <class-name> 'type)
    
+      If :TYPE -is- specified, then the documentation string is not
    
+      accessible in these ways.
    
+
    
+    Rationale:
    
+
    
+      This treats classes defined by DEFSTRUCT in a way that is 
    
+      compatible with classes defined by DEFCLASS or DEFINE-CONDITION.
    
+
    
+      It violates data abstraction to have to know whether a type 
    
+      specifier was defined with DEFSTRUCT or not in order to access
    
+      its documentation string.
    
+
    
+  (3) Remove the methods to DOCUMENTATION and (SETF DOCUMENTATION) which 
    
+      specialize on STANDARD-SLOT-DESCRIPTION.
    
+
    
+      Clarify that Common Lisp prescribes no means to retrieve the 
    
+      documentation strings for individual slots specified in a 
    
+      DEFCLASS form, but that implementations might still provide
    
+      debugging tools and/or programming language extensions which 
    
+      manipulate this information.
    
+
    
+    Rationale:
    
+
    
+      This gets rid of a dangling pointer into hyperspace.  Not only
    
+      is the class STANDARD-SLOT-DESCRIPTION not defined in the standard,
    
+      but there are no accessors defined in the standard that might
    
+      return objects of this class.
    
+
    
+  (4) Add new methods which specialize on FUNCTION:
    
+
    
+        DOCUMENTATION (<object> function) &optional doc-type
    
+                                                        [Primary method]
    
+        (SETF DOCUMENTATION) (<object> function) &optional doc-type
    
+                                                        [Primary method]
    
+
    
+        These methods access the documentation strings associated with
    
+        the definition of the function <object>.  An error is signalled 
    
+        if the second argument is provided.
    
+
    
+      Remove the methods to DOCUMENTATION and (SETF DOCUMENTATION) which
    
+      specialize on STANDARD-GENERIC-FUNCTION.
    
+
    
+    Rationale:
    
+
    
+      This provides an accessor for documentation strings for 
    
+      anonymous and other non-globally-defined function objects.
    
+
    
+      Since STANDARD-GENERIC-FUNCTION is a subclass of FUNCTION, the
    
+      standard doesn't have to specify an additional method on it.
    
+
    
+  (5) Add a new option to the DEFPACKAGE macro:
    
+
    
+        (:DOCUMENTATION string)
    
+
    
+        This specifies a documentation string for the package.  At most
    
+        one :DOCUMENTATION option can appear in a single DEFPACKAGE form.
    
+
    
+      Add new methods which specialize on PACKAGE:
    
+
    
+        DOCUMENTATION (<object> package) &optional doc-type
    
+                                                        [Primary method]
    
+        (SETF DOCUMENTATION) (<object> package) &optional doc-type
    
+                                                        [Primary method]
    
+
    
+        These methods access the documentation strings associated with
    
+        the definition of the package <object>.  An error is signalled 
    
+        if the second argument is provided.
    
+
    
+    Rationale:
    
+
    
+      DEFPACKAGE is currently the only defining macro whose syntax 
    
+      does not permit a documentation string.
    
+
    
+
    
+  (6) Clarify that it is permissible for implementations to discard
    
+      documentation strings at any time.
    
+
    
+
    
+Current Practice:
    
+
    
+  Probably nobody implements any of this yet.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably small.  Since DOCUMENTATION has been changed to a generic 
    
+  function it probably needs to be overhauled in most implementations
    
+  anyway.
    
+
    
+Cost to Users:
    
+
    
+  Probably small.  DOCUMENTATION is primarily used as a debugging and
    
+  program development tool.
    
+
    
+Cost of non-adoption:
    
+
    
+  Some documentation strings can't be retrieved.
    
+  There's a dangling pointer to an undefined class left in the standard.
    
+
    
+Performance impact:
    
+
    
+  Probably not a major concern.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Does anybody care?
    
+
    
+Discussion:
    
+
    
+  Item (3) leaves no accessor defined for the documentation strings
    
+  specified for slots in a DEFCLASS form.  If that's a problem, the
    
+  easiest way to deal with it would be to remove the :documentation
    
+  slot option syntax.
    
+
    
+  I think the standard ought to have some kind of table showing all the 
    
+  forms that permit documentation strings, and the corresponding accessors.
    
+  The original description of CLtL had such a table (unfortunately not
    
+  quite complete) but the new description of DOCUMENTATION as a generic 
    
+  function does not.
    
+
    
+  Kent Pitman says:
    
+
    
+    Personally, I think it's a bug that the second argument to 
    
+    DOCUMENTATION is not required for other object types.
    
+    I'd rather it was
    
+      (DOCUMENTATION <structure-class-object> 'TYPE)
    
+    It doesn't provide an option to view a non-symbol in more than 
    
+    one way, which seems bogus.  (e.g., I could imagine a string
    
+    having more than one view.)  But what you say -is- consistent 
    
+    with the spec, so I won't criticize your proposal.  But if you
    
+    wanted to make the type optional, and say that for classes it
    
+    defaults to IDENTITY (i.e., document the thing itself), I 
    
+    wouldn't much complain.
    
+
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136.htm new file mode 100644 index 00000000..9937e7e4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136_w.htm new file mode 100644 index 00000000..4991da10 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss136_w.htm @@ -0,0 +1,164 @@ + + + +CLHS: Issue DOCUMENTATION-FUNCTION-TANGLED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DOCUMENTATION-FUNCTION-TANGLED Writeup

    + +
    Forum:		Public Review
    
+Issue:		DOCUMENTATION-FUNCTION-TANGLED
    
+References:     Barrett's public review coment #20 (X3J13/92-3120)
    
+                DOCUMENTATION function, X3J13/92-102 p 25-17..20
    
+Category:       CHANGE
    
+Edit history:   2 Sept 1991, Version 1 by Pitman (partial writeup)
    
+                22 May 1993, Version 2 by Loosemore 
    
+                  (only proposal REQUIRE-ARGUMENT, minor changes to
    
+                   content, add comments from Barrett)
    
+Status:         Proposal REQUIRE-ARGUMENT passed (7+2)-2 on letter ballot
    
+                  93/302.
    
+
    
+
    
+Problem Description:
    
+
    
+  The DOCUMENTATION function is hopelessly confused.  Its dispatching is
    
+  not a shining example of the way generic function dispatching should
    
+  work, and since it is one of the only generic functions actually
    
+  specified by CL, more care should be given to demonstrating that our
    
+  dispatch paradigm can work usefully in such situations.
    
+
    
+Proposal (DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT):
    
+
    
+ (a) Make the second argument to DOCUMENTATION be required.
    
+
    
+ (b) Specify the method signatures for DOCUMENTATION are:
    
+
    
+       ;; Variables
    
+       documentation (object symbol) (doc-type (eql 'variable))
    
+
    
+       ;; Functions, Macros, Special forms
    
+       documentation (object function) (doc-type (eql 't))
    
+       documentation (object function) (doc-type (eql 'function))
    
+       documentation (object list)     (doc-type (eql 'function))
    
+       documentation (object symbol)   (doc-type (eql 'function))
    
+
    
+       documentation (object list)     (doc-type (eql 'compiler-macro))
    
+       documentation (object symbol)   (doc-type (eql 'compiler-macro))
    
+
    
+       ;; Setf Expanders
    
+       documentation (object symbol) (doc-type (eql 'setf))
    
+
    
+       ;; Classes, Types, Structure Names
    
+       documentation (object standard-class)  (doc-type (eql 't))
    
+       documentation (object standard-class)  (doc-type (eql 'type))
    
+       documentation (object structure-class)  (doc-type (eql 't))
    
+       documentation (object structure-class)  (doc-type (eql 'type))
    
+
    
+       documentation (object symbol) (doc-type (eql 'type))
    
+       documentation (object symbol) (doc-type (eql 'structure))
    
+
    
+       ;; Method combinations
    
+       documentation (object method-combination) (doc-type (eql 't))
    
+       documentation (object method-combination) 
    
+                     (doc-type (eql 'method-combination))
    
+       documentation (object symbol)
    
+      	             (doc-type (eql 'method-combination))
    
+
    
+       ;; Methods
    
+       documentation (object standard-method) (doc-type (eql 't))
    
+
    
+       ;; Packages
    
+       documentation (object package) (doc-type (eql 't))
    
+
    
+
    
+ (c) Specify that the argument precedence order for documentation
    
+     is (DOC-TYPE OBJECT).
    
+
    
+ (d) Make the corresponding changes for (SETF DOCUMENTATION).
    
+
    
+
    
+Rationale:
    
+
    
+ Making the second argument required permits method dispatching on
    
+ that argument, and that in turn permits the messy description of
    
+ the function to be cleaned up.
    
+
    
+ For those methods in the current description that currently do
    
+ not permit a doc-type argument, the new description has a method
    
+ that requires a second argument of T.  If the current description
    
+ already has a doc-type symbol that corresponds to this kind of
    
+ documentation, a second method has been added that recognizes
    
+ that symbol.
    
+
    
+
    
+Current practice:
    
+
    
+ In the old (CLtL-I) definition of DOCUMENTATION, the second argument
    
+ was required.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+ This can't be any harder to implement than the current description.
    
+
    
+
    
+Cost to Users:
    
+
    
+ The DOCUMENTATION function is probably used mostly as a program
    
+ development tool, with relatively few calls actually embedded inside
    
+ of programs.  Also, all calls that would work under the CLtL-I
    
+ definition would continue to work under this proposal.
    
+
    
+ Any calls or method definitions that lack the second argument are
    
+ statically detectable and easily fixed.
    
+
    
+
    
+Editorial Impact:
    
+
    
+ Cleaning up the dictionary page for the DOCUMENTATION function.
    
+
    
+
    
+Discussion:
    
+
    
+ Kim Barrett says:
    
+   I'm not so sure the (eql 't) cases are a good idea.  They sort of
    
+   presume that the objects involved can't have more than one applicable
    
+   doc type.  They do let you say (documentation <object> T) to get the
    
+   canonical documentation for the object though.
    
+
    
+ Barrett also suggests replacing these method signatures:
    
+
    
+       documentation (object standard-class)  (doc-type (eql 't))
    
+       documentation (object standard-class)  (doc-type (eql 'type))
    
+       documentation (object structure-class)  (doc-type (eql 't))
    
+       documentation (object structure-class)  (doc-type (eql 'type))
    
+       documentation (object standard-method) (doc-type (eql 't))
    
+
    
+ with these:
    
+
    
+       documentation (object class)  (doc-type (eql 't))
    
+       documentation (object class)  (doc-type (eql 'type))
    
+       documentation (object method) (doc-type (eql 't))
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137.htm new file mode 100644 index 00000000..3d7c6980 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue DOTIMES-IGNORE:X3J13-MAR91 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DOTIMES-IGNORE:X3J13-MAR91 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DOTIMES-IGNORE:X3J13-MAR91:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137_w.htm new file mode 100644 index 00000000..4db4dfa3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss137_w.htm @@ -0,0 +1,650 @@ + + + +CLHS: Issue DOTIMES-IGNORE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DOTIMES-IGNORE Writeup

    + +
    Issue:        DOTIMES-IGNORE
    
+Forum:	      Cleanup
    
+References:   DOLIST (p126), DOTIMES (p126-128), IGNORE (p160), 
    
+	      LOOP (X3J13/89-004), DO-SYMBOLS (p187), DO-ALL-SYMBOLS (p188),
    
+	      DO-EXTERNAL-SYMBOLS (p187), DO (pp122-126), DO* (pp122-126)
    
+Category:     CLARIFICATION
    
+Edit history: 20-Jul-90, Version 1 by Pitman
    
+	      06-Mar-91, Version 2 by Pitman
    
+	      15-Mar-91, Version 3 by Pitman
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+  The IGNORE declaration is described in terms of whether a variable is
    
+  `used'.  But what constitutes a use?  Several iteration primitives are
    
+  described as macros, and the nature of the expansion is not well
    
+  enough specified for the answer to this question to be easily
    
+  determined.
    
+
    
+  Consider:
    
+    (DOTIMES (A 3) (PRINT 'FOO))
    
+  Is A used?  Would it be appropriate to write:
    
+    (DOTIMES (A 3) (DECLARE (IGNORE A)) (PRINT 'FOO))
    
+  In some implementations, this would seem to be desirable, while in
    
+  other implementations it would seem undesirable.
    
+
    
+  In some implementations, such as an older Genera release, when the 
    
+  compiler sees an IGNORE declaration, it `commits' the fact that the
    
+  variable will not be used and sometimes cannot later back out and
    
+  produce a successful compilation when this assumption is later realized
    
+  to be wrong in the process of code-walking.  Because such a program
    
+  is technically in error, this is a conforming situation.  But it
    
+  means that the choice of whether to use IGNORE or not has potential
    
+  semantic impact.
    
+
    
+  This issue started out as being just about DOTIMES (hence the name)
    
+  but has been generalized to include all CL iteration forms.
    
+
    
+Terminology:
    
+
    
+  For the purposes of this issue, the following terminology applies:
    
+
    
+  An "explicit use of a variable in a form" is a use that would be
    
+  apparent in the normal semantics of the form.  That is, if all
    
+  subforms of that form were macroexpanded, but the form itself were
    
+  not.  [This isn't how an implementation has to detect an explicit 
    
+  form; it's just a definition of what explicit use means.  The intent
    
+  is that an explicit use be one which does not expose any undocumented
    
+  details of the form's macro expansion (if the form is in fact a macro).]
    
+
    
+  An "iteration form" means a DOLIST, DOTIMES, LOOP, DO-SYMBOLS, 
    
+  DO-ALL-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO, or DO* form.
    
+
    
+  An "iteration variable" is a variable which is "explicitly used"
    
+  as a variable to be bound by by an "iteration form".
    
+
    
+Voting Instructions:
    
+
    
+  Proposals which have a "+" in their name are compatible with any
    
+  other proposals, and may be voted in addition to the other proposals.
    
+
    
+Proposal (DOTIMES-IGNORE:NEVER):
    
+
    
+  Clarify that iteration variables are, by definition, always `used'.  
    
+  That is, clarify that using
    
+   (DECLARE (IGNORE ...))
    
+  for such an iteration variable has undefined consequences.
    
+
    
+  Rationale:
    
+
    
+  This is analagous to the situation in DEFMETHOD where a specialized 
    
+  required argument is considered a use of the argument.
    
+
    
+  Example:
    
+
    
+   ;; The following would be correct and should not be warned about.
    
+   (DOTIMES (I 5)
    
+     (PRINT 'FOO))
    
+
    
+   ;; The following would not be correct and might be warned about.
    
+   (DOTIMES (I 5)
    
+     (DECLARE (IGNORE I))
    
+     (PRINT 'FOO))
    
+
    
+Proposal (DOTIMES-IGNORE:UNLESS-EXPLICIT):
    
+
    
+  Clarify that unless an variable in an iteration form is explicitly 
    
+  used in the form which binds it, it might be considered "unused" by
    
+  the implementation, and that it is always permissible to use
    
+   (DECLARE (IGNORE ...))
    
+  for such a unused variable.
    
+
    
+  Rationale:
    
+
    
+  This doesn't force users to think about the macro expansion and tends
    
+  to treat iteration variables more like variables bound by LET, LET*,
    
+  and LAMBDA.
    
+
    
+  Example:
    
+
    
+   ;; The following would be correct and should not be warned about.
    
+   (DOTIMES (I 5)
    
+     (DECLARE (IGNORE I))
    
+     (PRINT 'FOO))
    
+
    
+   ;; The following would not be correct and might be warned about.
    
+   (DOTIMES (I 5)
    
+     (PRINT 'FOO))
    
+
    
+Proposal (DOTIMES-IGNORE:INVISIBLE-REFERENCES):
    
+
    
+  Introduce a macro
    
+
    
+    WITH-INVISIBLE-REFERENCES ({vars}*) {forms}*		[Macro]
    
+
    
+    Within the context of this macro, any uses of the <vars> are not
    
+    regarded as `uses' of the <vars> for the purposes of compiler warnings.
    
+
    
+  Clarify that macros like DOTIMES which expand into code which do
    
+  invisible computations on user-supplied variables must do the equivalent
    
+  of wrapping WITH-INVISIBLE-REFERNCES around those invisible uses, so that
    
+  those uses will not be counted as uses.
    
+
    
+  Rationale:
    
+
    
+  This makes the mechanism for invisible uses available to users so that they
    
+  can write forms like DOTIMES which manipulate user-supplied variables 
    
+  and yet warn about lack of explicit use of those variables.
    
+
    
+  Example:
    
+
    
+   ;; The following would be correct and should not be warned about.
    
+   (DOTIMES (I 5)
    
+     (DECLARE (IGNORE I))
    
+     (PRINT 'FOO))
    
+
    
+   ;; The following would not be correct and might be warned about.
    
+   (DOTIMES (I 5)
    
+     (PRINT 'FOO))
    
+
    
+   ;; The following would be correct.  User might be warned that X 
    
+   ;; is not used. (This is a pathological case which wouldn't be a
    
+   ;; normal use.  For a `real' use see the expansion of DOTIMES in
    
+   ;; the Symbolics Genera current practice.)
    
+   (LET ((X 3))
    
+     (WITH-INVISIBLE-REFERENCES (X) (INCF X) (PRINT X))
    
+     0)
    
+   4
    
+   => 0
    
+
    
+Proposal (DOTIMES-IGNORE:+IGNORE-FUNCTION):
    
+
    
+  Introduce a function 
    
+
    
+    IGNORE &REST IGNORE 			[Function]
    
+
    
+     Accepts any number of arguments and returns NIL.
    
+
    
+  Function calls to IGNORE can effectively be optimized away by a compiler,
    
+  except where side-effects might occur.  That is, (IGNORE X #'Y (Z)) is
    
+  equivalent to (PROGN X #'Y (Z) NIL), but is more perspicuous about the
    
+  user's intent to identify ignored items.
    
+
    
+  Rationale:
    
+
    
+  This leaves the original problem in place but provides a compromise 
    
+  that people can learn to use.   It also has the side benefit of providing
    
+  an obvious syntax for `ignorable' variables introduced by some macros.
    
+  It also provides an obvious syntax for ignoring FLET'd items. 
    
+
    
+  Example:
    
+
    
+   ;; The following might or might not be correct and might be warned about.
    
+   (DOTIMES (I 5)
    
+     (DECLARE (IGNORE I))
    
+     (PRINT 'FOO))
    
+
    
+   (DOTIMES (I 5)
    
+     (PRINT 'FOO))
    
+
    
+   ;; The following would not be warned about.
    
+   (DOTIMES (I 5)
    
+     (IGNORE I)
    
+     (PRINT 'FOO))
    
+
    
+Proposal (DOTIMES-IGNORE:+STYLE-WARNING):
    
+
    
+  Clarify that any `unused variable' warning must be a STYLE-WARNING, and
    
+  may not affect program semantics.
    
+
    
+  Rationale:
    
+
    
+  This is similar to STATUS-QUO, but at least insures that the issue has
    
+  no semantic impact on code.
    
+
    
+  Example:
    
+
    
+   ;; The following might or might not be correct and might be warned about
    
+   ;; but could be suppressed in a context where style warnings were 
    
+   ;; suppressable.  In either case, correct code would be generated.
    
+
    
+   (DOTIMES (I 5)
    
+     (DECLARE (IGNORE I))
    
+     (PRINT 'FOO))
    
+
    
+   (DOTIMES (I 5)
    
+     (PRINT 'FOO))
    
+
    
+Proposal (DOTIMES-IGNORE:+NEW-DECLARATION):
    
+
    
+  Introduce a new declaration, IGNORABLE, similar to IGNORE, except that
    
+  it means that the variable might or might not be used, but that in 
    
+  neither case should a warning be issued.
    
+
    
+  Rationale:
    
+
    
+  A lot of people have asked for this.  e.g., it would be useful for 
    
+  places where variables pop out of nowhere due to the presence of some
    
+  macro. e.g., in New Flavors (think of it as a user program from the
    
+  point of view of this proposal) the variable SELF magically appears in a
    
+  DEFMETHOD.  The definition of FLAVOR:DEFMETHOD might, therefore, want
    
+  to declare SELF to be IGNORABLE since not all Flavors' DEFMETHOD forms
    
+  actually use this.
    
+
    
+  Example:
    
+
    
+   Given...
    
+
    
+   (DEFMACRO WITH-FOO (X &BODY STUFF)
    
+     `(LET ((FOO (FROB ,X)))
    
+	(DECLARE (IGNORABLE FOO))
    
+	,@STUFF))
    
+
    
+   Neither of the following two uses would be warned about:
    
+
    
+       (WITH-FOO (F) (G))
    
+   or  (WITH-FOO (F) (H FOO))
    
+
    
+Proposal (DOTIMES-IGNORE:+FUNCTION-DECLARATIONS):
    
+
    
+  Permit the IGNORE (and IGNORABLE, if it passes--see proposal
    
+  +NEW-DECLARATION) declarations to contain references to #'name 
    
+  in order to refer to a function name instead of a variable name.
    
+
    
+  Rationale:
    
+
    
+  This would be useful, for example, in the expansion of DEFMETHOD
    
+  in order to declare that CALL-NEXT-METHOD and NEXT-METHOD-P might
    
+  or might not be used, but that no warning should be produced in
    
+  either case.  Some user programs presumably have similar needs.
    
+
    
+  Example:
    
+
    
+   (DEFMACRO DEFMETHOD ...
    
+     `(... (FLET ((CALL-NEXT-METHOD ...)
    
+		  (NEXT-METHOD-P ...))
    
+	     (DECLARE (IGNORABLE #'CALL-NEXT-METHOD
    
+			         #'NEXT-METHOD-P))
    
+	     ...)))
    
+
    
+Proposal (DOTIMES-IGNORE:STATUS-QUO):
    
+
    
+  Accept the fact that the use of (DECLARE (IGNORE ...)) for an iteration
    
+  variable will always cause a warning in some implementations and that
    
+  the failure to use it will always cause a warning in some other 
    
+  implementations.  The net effect of this will be that no code which uses 
    
+  any iteration primitive, DO, LOOP, or otherwise without using all iteration
    
+  variables explicitly will be free from gratuitous whining of at least
    
+  some compilers.  Since the presence of 
    
+   (DECLARE (IGNORE ...))
    
+  is sometimes fatal to some compilers, people will learn to live without it,
    
+  or will introduce creative other ways to `use' the variable to muffle the
    
+  warnings, sometimes at a performance penalty.
    
+
    
+  Rationale:
    
+ 
    
+  Implements the status quo.
    
+
    
+  Example:
    
+
    
+   ;; The following might or might not be correct and might be warned about.
    
+   (DOTIMES (I 5)
    
+     (DECLARE (IGNORE I))
    
+     (PRINT 'FOO))
    
+
    
+   (DOTIMES (I 5)
    
+     (PRINT 'FOO))
    
+
    
+Test Case:
    
+
    
+  (DEFUN COMPILER-WARNINGS-P (BODIES &OPTIONAL (FLAG NIL))
    
+    (MAPCAR #'(LAMBDA (BODY)
    
+		(FLET ((TRY (BODY)
    
+			 (LET ((WARNING 
    
+				 (WITH-OUTPUT-TO-STRING (*ERROR-OUTPUT*)
    
+				   (COMPILE NIL `(LAMBDA ,@BODY)))))
    
+			   (IF FLAG WARNING (> (LENGTH WARNING) 0)))))
    
+		  (LIST (TRY BODY)
    
+			(TRY (LIST (CAR BODY)
    
+				   (REMOVE-IF
    
+				     #'(LAMBDA (X)
    
+					 (AND (NOT (ATOM X))
    
+					      (EQ (CAR X) 'DECLARE)))
    
+				     (CADR BODY)))))))
    
+	    BODIES))
    
+
    
+  (DEFUN TEST-CASE ()
    
+    (COMPILER-WARNINGS-P
    
+      '(((X) (DOTIMES (A X) (DECLARE (IGNORE A)) (PRINT 'FOO)))
    
+	((X) (DOLIST (A X) (DECLARE (IGNORE A)) (PRINT 'FOO)))
    
+	((X) (DO-SYMBOLS (S X) (DECLARE (IGNORE S)) (PRINT 'FOO)))
    
+	((X) (DO-EXTERNAL-SYMBOLS (S X) (DECLARE (IGNORE S)) (PRINT 'FOO)))
    
+	(()  (DO-ALL-SYMBOLS (S) (DECLARE (IGNORE S)) (PRINT 'FOO)))
    
+	((X) (LOOP FOR I IN X DO (DECLARE (IGNORE I)) (PRINT 'FOO)))
    
+	((X) (LOOP FOR L ON X DO (DECLARE (IGNORE L)) (PRINT 'FOO)))
    
+	((X) (DO ((L X X)) (NIL) (DECLARE (IGNORE L)) (PRINT 'FOO)))
    
+	((X) (DO* ((L X X)) (NIL) (DECLARE (IGNORE L)) (PRINT 'FOO))))))
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera implements INVISIBLE-REFERENCES (except that the
    
+   macro is called COMPILER:INVISIBLE-REFERENCES) and by implication
    
+   it implements UNLESS-EXPLICIT and STATUS-QUO.  It also implements 
    
+   +IGNORE-FUNCTION, and probably implements +STYLE-WARNING.
    
+
    
+  Test case results...
    
+   Symbolics Genera 8.0.1: ((NIL T) (T T  ) (T   NIL) (T NIL) (T NIL)
    
+		            (T   T) (T T  ) (T   T  ) (T T  ))
    
+
    
+   Symbolics Genera 8.1:   ((NIL T) (NIL T) (T   NIL) (T NIL) (T NIL)
    
+			    (T   T) (T   T) (T   T  ) (T T  ))
    
+
    
+   Symbolics Cloe:         ((NIL T) (T T  ) (NIL NIL) (T NIL) (T T  )
    
+		            (T   T) (T NIL) (T   T  ) (T T  ))
    
+
    
+  In Symbolics Genera, the macroexpansion of (DOTIMES (A 3) (PRINT 'FOO)) is:
    
+    (PROG    ((A 0))
    
+     #:G1689 (PRINT 'FOO)
    
+	     (COMPILER:INVISIBLE-REFERENCES (A)
    
+	       (IF (PROGN (SETQ A (1+ A))
    
+		          (< A 3))
    
+		   (PROGN (GO #:G1689))))
    
+	     (RETURN NIL))
    
+
    
+Cost to Implementors:
    
+
    
+  NEVER: Relatively small.  It's straightforward for macros to add a few
    
+   spurious additional references in order to assure that no unused warnings
    
+   occur.
    
+
    
+  UNLESS-EXPLICIT: Medium.  This is similar to INVISIBLE-REFERENCES, but
    
+   it allows for alternate implementations with equivalent effect because
    
+   it doesn't publish the interface.
    
+
    
+  +IGNORE-FUNCTION: Relatively small.
    
+
    
+  +NEW-DECLARATION: None to medium.  This involves some compiler work,
    
+   the amount of which may vary, for implementations that do enough
    
+   bookkeeping for it to matter.  Implementations which don't ever warn
    
+   can just ignore this, of course.
    
+
    
+  +FUNCTION-DECLARATIONS: Probably relatively small.
    
+
    
+  INVISIBLE-REFERENCES:  None to Medium.  This probably involves some
    
+    compiler hacking for implementations who care to do this kind of 
    
+    warning.  Strictly, an implementation could simply never warn, and then
    
+    this would be free, but some implementations have already established
    
+    a precedent of warning, so their customers would probably insist that
    
+    they did the work to make warnings continue to work in places where
    
+    they were called for.
    
+
    
+  STATUS-QUO: None.
    
+
    
+Cost to Users:
    
+
    
+  NEVER: Relatively small.
    
+
    
+  UNLESS-EXPLICIT: Relatively small.
    
+
    
+  +IGNORE-FUNCTION: Relatively small.
    
+
    
+  +NEW-DECLARATION: None.
    
+
    
+  +FUNCTION-DECLARATIONS: None.
    
+
    
+  INVISIBLE-REFERENCES: Relatively small.
    
+
    
+  STATUS-QUO: Potentially large nuisance value and medium amount of work
    
+    for some users.
    
+    When porting to a new platform, you get a lot of warnings.  Sometimes
    
+    the warnings are useful, sometimes they are not.  The worst part is
    
+    if they are not useful and you just want to ignore them but you can't
    
+    because there are other warnings you want to see and you don't have the
    
+    ability to turn off just these warnings.  So over and over you have to
    
+    wade through these warnings just to get to the others.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  See cost of option STATUS-QUO.
    
+
    
+Benefits:
    
+
    
+  Users don't have to guess about important aspects of language semantics.
    
+
    
+Aesthetics:
    
+
    
+  Proposals NEVER, UNLESS-EXPLICIT, +IGNORE-FUNCTION, +NEW-DECLARATION,
    
+  +FUNCTION-DECLARATIONS, and INVISIBLE-REFERENCES definitely improve the
    
+  aesthetics in the sense that they give the user the power to make the
    
+  code mean a particular thing, rather than leaving it to the discretion
    
+  of the implementation what the user meant.
    
+
    
+  Proposal STATUS-QUO is not aesthetic.
    
+
    
+Discussion:
    
+
    
+  Pitman thinks that anything but STATUS-QUO is livable, but has a
    
+  preference for either INVISIBLE-REFERENCES or NEVER.  He thinks 
    
+  any of +IGNORE-FUNCTION, +NEW-DECLARATION, and +FUNCTION-DECLARATIONS
    
+  would be nice additions, too.
    
+
    
+  Dalton is on record as opposing a WITH-INVISIBLE-REFERENCES macro
    
+  and an IGNORABLE declaration (see below), but he hasn't seen this
    
+  specific proposal (which admittedly isn't likely to change his mind).
    
+
    
+  Several Symbolics customers have complained about portability
    
+  problems due to this lack of specificity.
    
+
    
+  Gregor Kiczales says: ``in writing PCL, this IGNORE issue was a 
    
+  major pain in the ass.  I never really was able to get it right,
    
+  and it ended up showing through to the users.''
    
+
    
+  JonL White said of mail from Dalton in a much longer discussion:
    
+    ``he claims that DECLARE-IGNORE is *not* just friendly, 
    
+      optional advice to the compiler, but assertions about
    
+      the program.  I may disagree with him, but I can certainly
    
+      sympathesize with his viewpoint.  This issue in general
    
+      -- what *must* declarations do -- is a serious one.''
    
+
    
+  Margolin said ``We're past the deadline for making significant changes
    
+  in the language. We're trying to get the standard edited now.  At this
    
+  time we shouldn't be making changes unless they fix real language
    
+  bugs.  I personally don't feel that a style warning is sufficient
    
+  justification for a change to the semantics of DOTIMES.''  RWK
    
+  responded ``I feel that the style warnings *ARE* an important enough
    
+  issue, because these style warnings are by default dictating the
    
+  variable semantics, but in a manner inconsistent from implementation
    
+  to implementation.''
    
+
    
+  Some people reviewing version 1 made suggestions which are not
    
+  pursued in this version, but which are worthy of note:
    
+
    
+   - GLS suggested we might need a REPEAT macro, such that 
    
+     (REPEAT n . body) meant the same as (DOTIMES (I n) . body).
    
+     This would paper over the DOTIMES problem, but would still 
    
+     leave other similar problems unattended to.  This angle was
    
+     therefore not pursued.
    
+
    
+   - Barrett and others raised the issue of what counts as a use.
    
+     Both reading and writing it, or just reading?  Technically,
    
+     that's an orthogonal issue, although it has obvious interplay 
    
+     with anything decided here.
    
+
    
+   - There was discussion by Dalton, Margolin, and others of changing
    
+     the semantics of IGNORE to mean `ignorable'.  Some felt this 
    
+     would be visually confusing. Some felt we should rename IGNORE
    
+     to IGNORABLE.  Some felt we should introduce IGNORABLE in 
    
+     addition to IGNORE.   [An IGNORABLE declaration was added as an
    
+     option in v3 of this proposal. -kmp]
    
+
    
+   - Jeff Barnett (at Northrop) suggested that we should reconsider
    
+     the idea of dignifying a certain variable, IGNORE, as implicitly
    
+     ignored and then permit (DOTIMES (IGNORE 5) ...).  He observed
    
+     that this also works for (MULTIPLE-VALUE-BIND (X IGNORE Z) ...).
    
+     This was already brought up as issue IGNORE-VARIABLE (tabled by
    
+     Masinter at Mar-89 meeting due to deadline constraints).
    
+     Fred White (at BBN) suggested that it should be possible to do
    
+     (PROCLAIM '(IGNORE IGNORE)). Pitman pointed out that 
    
+     (PROCLAIM '(SPECIAL IGNORE)) almost works.
    
+     Neil Goldman (at ISI) raised the issue of 
    
+      (mapcar #'(lambda (V) t) l)
    
+     which again calls for the IGNORE variable.
    
+
    
+   - Eliot@CS.UMASS.EDU pointed out that he just tries to avoid 
    
+     (DECLARE (IGNORE X)) in favor of just X at toplevel of a body.
    
+     Don Cohen (at ISI) disagreed that this was adequate, saying that
    
+     he felt that an implementor would be justified in finding such
    
+     a `use' to be gratuitous and still warning.  (Pitman disagrees
    
+     with this disagreement, because sometimes macros expand into 
    
+     such things and getting a use that is `more significant' might be
    
+     a data abstraction violation.)  In any case, the use Eliot was
    
+     talking about really implements IGNORABLE, not IGNORE.
    
+
    
+   - There was some exploration into the area of whether DOTIMES should
    
+     create a new binding every time.  RPG cited that the current 
    
+     definition of DOTIMES is unintuitive to users of parallel lisps.
    
+     Dalton pointed out that if a new binding were made every time, then
    
+     the internal variable which DOTIMES stepped could be a different 
    
+     one, and hence the user's variable would be unused as a matter of
    
+     course (i.e., without WITH-INVISIBLE-REFERENCES) since no hidden
    
+     operations on it would be needed.  Bob Kerns (RWK at ILA) said that
    
+     if people were intending to close over an iteration variable, their
    
+     intent would still be clearer if they wrote
    
+      (DOTIMES (I N) (LET ((I I)) (SPAWN #'(LAMBDA () ...I...))))
    
+     rather than just 
    
+      (DOTIMES (I N) (SPAWN #'(LAMBDA () ...I...)))
    
+
    
+   - Dalton raised the question of whether all this trouble was really
    
+     worth it and whether we shouldn't just specify the expansion of
    
+     DOTIMES precisely so users could just know what it would have going
    
+     on inside it.  RPG said ``Using possible macro expansions to reason
    
+     about language design is poor methodology. DOTIMES should be
    
+     specified and its implementation choices outlined.''  Barmar
    
+     defended (as an example) the Symbolics implementation which
    
+     expands differently depending on the situation and worried that
    
+     optimizations would be harder if the expansion was dictated.  The
    
+     idea of showing a space of possible expansions was also discussed
    
+     by RWK and others.    Barmar said ``By specifying each
    
+     operator as independently as possible we have less trouble with
    
+     strange interactions.''  Dalton responded ``Except where we don't,
    
+     as with DOTIMES and IGNORE. Moreover, it is at least arguable that
    
+     when too much is separate the language is more complex and harder
    
+     to learn.''
    
+
    
+   - Neil Goldman cited three examples of problem situations--
    
+      - 1) in lambda lists, because a function is used in a role
    
+            where it may be passed arguments it does not need.
    
+        2) multiple-value-setq, where the values that need to be
    
+           consumed are not just an initial sequence of those returned.
    
+        3) macros (like DOTIMES), that require the provision of a
    
+           variable name that will be lexically bound in the expansion 
    
+           and permit IGNORE declarations about it.
    
+     He suggested that the form of destructuring used by LOOP would
    
+     solve these problems. e.g.,
    
+      (defun arg1-is-integer (arg1 nil) ...) ;;second arg is not consumed
    
+      (defun CAR-is-integer ((car . nil)) ...)
    
+        ;; first arg must be a CONS.  Its CDR is not consumed
    
+      (multiple-value-setq ((onea oneb) nil three) ...)
    
+      (dotimes (nil n) (push 0 l))
    
+     Peter Norvig (at Berkeley) worried about ambiguities in this notation.
    
+      (defun optional-CAR-is-integer (&optional (car nil)) ...)
    
+      (defmethod CAR-is-integer ((car cons)) ...)
    
+
    
+  RWK wrote one particular message which Moon identified in mail as the
    
+  most important message in the long conversation and which Moon said he
    
+  hoped wouldn't get lost.  GLS sent mail saying he agreed. The 
    
+  message was long, but it was a good message, so KMP has picked some choice 
    
+  paragraphs from it and reproduced them here. These are from the 
    
+  message of 26 Jul 90 21:26 EDT from RWK@FUJI.ILA.Dialnet.Symbolics.COM:
    
+
    
+   ``Variable semantics is a very fundamental aspect of the language, 
    
+     and we have failed to specify an important part of it.  Traditionally,
    
+     we have dismissed "style warnings" as being an "environment" issue.
    
+     However, in this case, I do not think it should be so dismissed.
    
+     Currently, we have implementations of CL which vocally complain about
    
+     opposite usages.  Having bogus style warnings go off in this way is
    
+     a serious problem for people porting code, because it obscures 
    
+     legitimate problems.  Bogus warnings are a serious waste of time for
    
+     porters of code, and they also make venders of portable code look as
    
+     if they are careless programmers.
    
+
    
+   ``I strongly feel that a well-written portable Common Lisp program 
    
+     should compile with no warnings in any well-done Common Lisp 
    
+     implementation.  Otherwise, how is the user of a portable program 
    
+     supposed to know if the warnings warn of actual problems, or are 
    
+     just noise.
    
+
    
+   ``I strongly feel that X3J13 should firmly nail down under what 
    
+     circumstances "unused variable" and "unused local function"
    
+     warnings may be issued.  It is our failure to do so which is
    
+     at the heart of the current issue, and as a porter of code, it
    
+     has been a recurrent problem.''
    
+
    
+   ``There are also two capabilities which are missing, which have
    
+     been refered to as an IGNORABLE declaration and a 
    
+     COMPILER:INVISIBLE-REFERENCES form, in BARMAR's message.  I 
    
+     actually think that both are needed.  IGNORABLE states that it
    
+     doesn't matter if the user doesn't reference a variable.  
    
+     COMPILER:INVISIBLE-REFERENCES (WITHOUT-REFERENCES ?) states that 
    
+     the user is *expected* to reference a particular variable, and 
    
+     that style warnings are appropriate if he does not.
    
+
    
+    ``I think both situations are common in macros, and that because
    
+      these issues are so close to the core of the language semantics,
    
+      this should be regarded as something more than mere "style
    
+      warnings".  I wouldn't require compilers and interpreters to 
    
+      issue the warnings in any particular situation, but I do think
    
+      we can and should define the semantics of our variables sufficiently 
    
+      to state when these warnings are and are not appropriate.
    
+
    
+    ``I'd also like to see all of these extended to local functions
    
+      in the same manner as the DYNAMIC-EXTENT declaration.''
    
+
    
+  Pitman notes the following bug report, received by Symbolics.  One very
    
+  important effect of solving this issue is that vendors will know what
    
+  to implement and users will know what to expect.  Right now, vendors
    
+  are forced to implement their conscience, and they have no defense if
    
+  a user thinks they did the wrong thing.  
    
+ 
    
+     Date: Fri, 14 Sep 90 17:45 EDT
    
+     From: J.P. Massar <massar@Think.COM>
    
+     Subject: Stupid warnings
    
+     To: bug-lispm@Think.COM
    
+     
    
+     Look at all this crap.  I don't care what anyone says about 
    
+     how iteration variables REALLY aren't been used...
    
+     
    
+     I JUST DON'T WANT TO SEE THESE STUPID MESSAGES AND I DON'T
    
+     PARTICULARLY FEEL LIKE GOING AND PUTTING STUPID #+ WHATEVER's
    
+     OVER THIS CODE.
    
+     
    
+     SYMBOLICS SHOULD BE SHOT FOR ISSUING THIS WARNING.
    
+     ...
    
+ 
    
+  The only little problem is--all Symbolics did was implement what it
    
+  felt CLtL said to implement.  What the user is really complaining
    
+  about is that the implementation didn't do the same thing as he 
    
+  expected, and the only way it ever will is if we resolve this issue
    
+  once and for all.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138.htm new file mode 100644 index 00000000..ff28619f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138.htm @@ -0,0 +1,55 @@ + + + +CLHS: Issue DOTTED-LIST-ARGUMENTS:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DOTTED-LIST-ARGUMENTS:CLARIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DOTTED-LIST-ARGUMENTS:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138_w.htm new file mode 100644 index 00000000..8ec0da19 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss138_w.htm @@ -0,0 +1,286 @@ + + + +CLHS: Issue DOTTED-LIST-ARGUMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DOTTED-LIST-ARGUMENTS Writeup

    + +
    Forum:		Public Review
    
+Issue:		DOTTED-LIST-ARGUMENTS
    
+References:	Loosemore's public review comment #10 (X3J13/92-1310)
    
+                Pitman's public review comments #37, #38, #39
    
+		  (X3J13/92-2737, -2738, -2739)
    
+		Issue APPEND-DOTTED (retracted)
    
+		Issue APPEND-FIASCO (withdrawn)
    
+		Issue APPEND-ATOM (withdrawn)
    
+		Issue REMF-DESTRUCTION-UNSPECIFIED (passed)
    
+		Issue LAST-N (passed)
    
+Category:	CLARIFICATION, CHANGE
    
+Edit history:	23 Dec 1992, Version 1 by Loosemore
    
+		04 Feb 1993, Version 2 by Loosemore (comments from Barmar)
    
+Status:		Proposal CLARIFY passed (6+3)-2 on letter ballot 93-302.
    
+
    
+
    
+Problem description:
    
+
    
+  The next-to-last paragraph on page 14-2 (in draft 12.24) says that
    
+  functions that take list arguments should be prepared to signal an
    
+  error if they receive dotted list arguments, except as explicitly
    
+  stated otherwise.  But many of the descriptions of the functions in
    
+  chapter 14 do not explicitly state otherwise, where they clearly ought
    
+  to.  (In some cases, the "correct" behavior is implied by notes or
    
+  examples, which are not binding parts of the standard.)  For example,
    
+  surely the committee did not intend to make primitive accessors such
    
+  as CAR and CDR fail on dotted lists!
    
+
    
+  Similarly, there are exceptions missing for the rule stated in the
    
+  last paragraph on page 14-2 (the consequences are undefined if
    
+  a circular list is passed).  
    
+  
    
+  For the functions which operate on trees, there is a further problem.
    
+  Some of the arguments are described as "objects", and others are
    
+  described as "lists", which I think is incorrect -- an atomic tree
    
+  argument should also be OK for functions such as SUBST and SUBLIS.
    
+  The dotted-list prohibition should clearly not apply to the tree
    
+  functions.  But since tree functions recursively descend both the 
    
+  car and cdr chains of a cons, there should be a prohibition against
    
+  circular tree structure in the arguments to these functions, not
    
+  just circular list structure.
    
+
    
+  Finally, there is confusion about whether atoms may be considered
    
+  degenerate dotted lists in some contexts.
    
+
    
+
    
+Proposal (DOTTED-LIST-ARGUMENTS:CLARIFY):
    
+
    
+  (1) Add to page 14-2 a third paragraph:
    
+
    
+      Except as explicitly stated otherwise, for any standardized
    
+      function that is required to be a tree, the consequences are
    
+      undefined if that tree is circular.
    
+
    
+  (2) Clarify that association lists, property lists, and lists
    
+      that are treated as sequences must be proper lists.
    
+
    
+  (3) Change the glossary definitions of "dotted list" and "list" to
    
+      clarify that atoms are not considered dotted lists.
    
+
    
+  (4) Clarify the nature of list arguments to the functions in chapter
    
+      14, as follows:
    
+
    
+
    
+      CAR, CDR and friends:  the argument "x" is permitted to be dotted
    
+        or circular.
    
+
    
+        Rationale:  These are primitive accessors.
    
+
    
+
    
+      COPY-TREE:  the argument "object" is a tree (not an object).
    
+      SUBLIS, NSUBLIS: the "tree" argument is a tree (not a list).
    
+      SUBST and friends: the "tree" argument is a tree (not a list).
    
+      TREE-EQUAL:  the arguments "object1" and "object2" are trees
    
+        (not objects).
    
+
    
+        Rationale:  This makes all the tree functions consistent.
    
+
    
+
    
+      COPY-LIST: the argument "list" may be dotted but not circular.
    
+
    
+        Rationale:  This is what CLtL said.
    
+
    
+
    
+      LIST-LENGTH: the argument "list" may be circular but not dotted.
    
+
    
+        Rationale:  It's supposed to detect and return NIL for 
    
+        circular lists.
    
+
    
+
    
+      POP:  the "place" argument is permitted to evaluate to a dotted or
    
+        circular list.
    
+      PUSH:  the "place" argument may evaluate to any object (not just 
    
+        a list).
    
+
    
+        Rationale:  This follows from the equivalences given in the notes.
    
+
    
+
    
+      FIRST and friends: the argument "list" may be dotted or circular.
    
+
    
+        Rationale:  These functions are commonly implemented as chains
    
+        of CAR and CDR operations.
    
+
    
+
    
+      NTH: the argument "list" may be dotted or circular.  Note that
    
+        the references to the length of the argument list in the
    
+        description are incorrect, since this concept doesn't make
    
+        sense for dotted lists.  The right thing to do is simply to 
    
+        define (NTH n list) = (CAR (NTHCDR n list)).
    
+
    
+        Rationale:  The notes for FIRST and friends say that
    
+        (FIFTH x) == (NTH 4 x).  This also makes NTH and NTHCDR
    
+        consistent.
    
+
    
+
    
+      ENDP: the argument "list" may be dotted or circular.
    
+
    
+        Rationale:  This function only cares whether the argument is
    
+        NIL/a cons/something else.
    
+
    
+
    
+      NCONC: the last "list" argument may be any object.  The remaining 
    
+        "lists" may be dotted but not circular.
    
+
    
+        Rationale:  This follows from the equivalence in the description
    
+        (from issue REMF-DESTRUCTION-UNSPECIFIED).
    
+
    
+
    
+      NRECONC: the argument "list1" must be a proper list.
    
+        The argument "list2" can be any object (not just a list).
    
+        (The example showing "list1" as a dotted list is incorrect.)
    
+
    
+        Rationale:  This follows from the equivalence in the side effects
    
+        section, which was added by issue REMF-DESTRUCTION-UNSPECIFIED.  
    
+        (NREVERSE is a sequence function.)
    
+
    
+
    
+      APPEND: the last "list" argument may be any object.
    
+        The remaining "lists" must be proper lists.
    
+
    
+        Rationale:  Allowing any object as the last argument came from
    
+        CLtL.  The inconsistency of the remaining arguments compared to 
    
+        NCONC was a deliberate decision by X3J13 (issues APPEND-DOTTED, etc).
    
+        
    
+
    
+      REVAPPEND: the argument "list1" must be a proper list.
    
+        The argument "list2" can be any object (not just a list).
    
+        (The example showing "list1" as a dotted list is incorrect.)
    
+
    
+        Rationale:  This follows from the equivalence in the notes section.
    
+        (REVERSE is a sequence function.)
    
+
    
+
    
+      BUTLAST, NBUTLAST:  the argument "list" may be dotted but not 
    
+        circular.   (The functions should complement LAST by counting 
    
+        conses, not elements.)
    
+
    
+        Rationale:  An obvious identity is
    
+        (BUTLAST list n) == (LDIFF list (LAST list n))
    
+        The intent of issue LAST-N was clearly to make LAST and BUTLAST
    
+        complementary.
    
+
    
+
    
+      LAST:  the argument "list" may be dotted but not circular.
    
+
    
+        Rationale:  This follows from the definition in the notes section.
    
+
    
+
    
+      LDIFF, TAILP: the "list" argument may be dotted.  The "sublist"
    
+        argument may be any object (not just a list).  Both arguments may
    
+        be circular lists only if (TAILP sub-list list) is true.
    
+
    
+        Rationale:  This is already stated for TAILP and the two functions
    
+        are clearly related.
    
+
    
+
    
+      NTHCDR: the "list" argument may be dotted or circular.
    
+
    
+        Rationale:  The examples show use on a dotted list, and the 
    
+        function will clearly still terminate if passed a circular list.
    
+
    
+
    
+      REST:  the "list" argument is permitted to be dotted or circular.
    
+
    
+        Rationale:  compatibility with CDR and FIRST.
    
+
    
+
    
+      MEMBER and friends:  the "list" argument must be a proper list.
    
+      INTERSECTION, NINTERSECTION: the "list-1" and "list-2" arguments
    
+        must be proper lists.
    
+      ADJOIN:  the "list" argument must be a proper list.
    
+      PUSHNEW:  the "place" argument must evaluate to a proper list.
    
+      SET-DIFFERENCE, NSET-DIFFERENCE:  the "list-1" and "list-2" 
    
+        arguments must be proper lists.
    
+      SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR:  the "list-1" and "list-2" 
    
+        arguments must be proper lists.
    
+      SUBSETP:  the "list1" and "list2" arguments must be proper lists.
    
+      UNION, NUNION:  the "list1" and "list2" arguments must be proper lists.
    
+
    
+        Rationale:  This makes all the functions that operate on lists as
    
+        sets consistent.  
    
+
    
+
    
+      MAPC and friends:  the "list" arguments must be proper lists.
    
+
    
+        Rationale:  The description makes clear that the lists are treated
    
+        as sequences.
    
+      
    
+
    
+Current practice:
    
+
    
+  Loosemore thinks the only item that is likely to cause compatibility
    
+  problems is explicitly requiring BUTLAST to work on dotted lists:
    
+  currently at least CMU CL and AKCL signal an error, but it works
    
+  in Lucid.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  This proposal should probably make it easier for implementors to do
    
+  the right thing.  Given the previous addition of the requirement that
    
+  implementations "should be prepared to signal" errors about dotted lists
    
+  and tighter restrictions about signalling TYPE-ERRORs for incorrect
    
+  arguments, all implementors probably need to reexamine the definitions
    
+  of these functions for conformance anyway.
    
+
    
+
    
+Cost to users:
    
+
    
+  There may be a few currently working programs that will stop working.
    
+
    
+
    
+Aesthetics:
    
+
    
+  This whole problem is messy to deal with.
    
+
    
+
    
+Editorial impact:
    
+
    
+  Substantial, but it needs to be done to correct obvious errors.
    
+
    
+
    
+Discussion:
    
+
    
+  Loosemore notes that there are a few more functions which could 
    
+  reasonably be defined to work on atoms as degenerate dotted lists
    
+  (notably, TAILP and LDIFF) but that current practice is to signal
    
+  an error, so the proposal does not include these.
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139.htm new file mode 100644 index 00000000..38c1e22f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DOTTED-MACRO-FORMS:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DOTTED-MACRO-FORMS:ALLOW Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DOTTED-MACRO-FORMS:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139_w.htm new file mode 100644 index 00000000..e30760c1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss139_w.htm @@ -0,0 +1,153 @@ + + + +CLHS: Issue DOTTED-MACRO-FORMS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DOTTED-MACRO-FORMS Writeup

    + +
    Issue:        DOTTED-MACRO-FORMS
    
+References:   forms (p54), lists and dotted lists (pp26-27),
    
+	      DEFMACRO (p145), destructuring macro arguments (p146)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 28-Jun-88, Version 1 by Pitman   (explicitly-vague vs allow)
    
+	      01-Oct-88, Version 2 by Masinter (disallow)
    
+	      15-Nov-88, Version 3 by Pitman   (revive allow, flush disallow)
    
+
    
+Problem Description:
    
+
    
+  CLtL is not explicit about whether macro forms may be dotted
    
+  lists.
    
+
    
+  p54 says that only certain forms are "meaningful": self-evaluating
    
+   forms, symbols, and "lists".
    
+
    
+  pp26-27 defines "list" and "dotted list". It goes on to say
    
+   ``Throughout this manual, unless otherwise specified, it is an
    
+   error to pass a dotted list to a function that is specified
    
+   to require a list as an argument.''
    
+
    
+  p146 states that in DEFMACRO destructuring, ``the argument
    
+   form that would match the parameter is treated as a
    
+   (possibly dotted) list, to be used as an argument forms list
    
+   for satisfying the parameters in the embedded lambda list.''
    
+   It goes on to say that ". var" is treated like "&rest var"
    
+   at any level of the defmacro lambda-list.
    
+
    
+Proposal (DOTTED-MACRO-FORMS:ALLOW):
    
+
    
+ Define that it is permissible for a macro form (or subform)
    
+ to be a dotted list when "&REST var" or ". var" is used to match
    
+ it. It is the responsibility of the macro to recognize and deal
    
+ with such situations.
    
+
    
+Rationale:
    
+  
    
+ Some implementations permit dotted lists in macro forms at toplevel.
    
+ Most or all implementations permit dotted lists in macro forms at
    
+ embedded levels. This proposal makes the language internally
    
+ consistent without requiring changes to existing code.
    
+
    
+ Also, there's no reason to unnecessarily restrict &REST since there
    
+ is no computational overhead and since there's no dispute about how
    
+ to interpret programmer intent in this gray area.
    
+
    
+Test Case:
    
+
    
+  #1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
    
+      (MACW . 1) => ??
    
+
    
+  #2: (DEFMACRO MACR (&REST R) `(- ,R))
    
+      (MACR . 1) => ??
    
+
    
+  #3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
    
+      (MACX . 1)
    
+
    
+    (MACW . 1) => -1 under this proposal.
    
+    (MACR . 1) => -1 under this proposal.
    
+
    
+    (MACX . 1) is an error under CLtL semantics and is not
    
+	       changed by this proposal. The reason it is an
    
+	       error is that the argument pattern does not
    
+	       match. The pattern is dictated by the arguments
    
+	       -other than- the &WHOLE argument, so the pattern
    
+	       is () and MACX cannot be called with any arguments.
    
+
    
+Current Practice:
    
+
    
+  A. Some implementations bind W to (MACW . 1) in #1 and #3
    
+   		      and bind R to 1 in #1 and #2.
    
+
    
+  B. Some implementations bind W to (MACW . 1) in #3
    
+		      and signal a syntax error in #1 and #2.
    
+
    
+  C. Some implementations signal a syntax error in #1, #2, and #3.
    
+     Symbolics Genera is such an implementation.
    
+
    
+Cost to Implementors:
    
+  
    
+ Some implementations would have to eliminate an error check.
    
+
    
+ Some implementations which try to use APPLY of a normal lambda
    
+ to accomplish part of the destructuring (in the non-recursive case)
    
+ would have to be slightly more careful.
    
+  
    
+Cost to Users:
    
+  
    
+ None. This change is upward compatible.
    
+  
    
+Benefits:
    
+
    
+ People would know what to expect.
    
+
    
+Aesthetics:
    
+
    
+ Mixed opinion: certainly it is better to specify whether they are
    
+ allowed or an error than to be vague.
    
+
    
+ Some feel that disallowing dotted macro forms helps catch syntax errors.
    
+ Some feel that allowing dotted macro forms makes the language more regular.
    
+
    
+Discussion:
    
+
    
+ Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
    
+ This issue came up primarily in the context of program-written programs;
    
+ a macro used in the program generated code might occasionally use
    
+ a dotted tail to a list to explicitly represent special conditions.
    
+ 
    
+ Allowing dotted macro forms may blur the data/code distinction too much, 
    
+ particularly for people who are new to Lisp. On the other hand, some people
    
+ argue that the point of macros is to help blur that distinction. Macro
    
+ forms are data which must be translated to program, and only once the
    
+ program claims to be macroexpanded ought syntax restrictions be imposed.
    
+
    
+ This proposal was rewritten from `DISALLOW' to `ALLOW' after Steele pointed
    
+ out in a recent meeting that dotted lists are allowed in subforms and 
    
+ that permitting them at toplevel would be the most internally consistent
    
+ interpretation.
    
+
    
+ Pitman supports DOTTED-MACRO-FORMS:ALLOW.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140.htm new file mode 100644 index 00000000..da3c4ee8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DRIBBLE-TECHNIQUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DRIBBLE-TECHNIQUE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DRIBBLE-TECHNIQUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140_w.htm new file mode 100644 index 00000000..a687e431 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss140_w.htm @@ -0,0 +1,108 @@ + + + +CLHS: Issue DRIBBLE-TECHNIQUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DRIBBLE-TECHNIQUE Writeup

    + +
    Issue:        DRIBBLE-TECHNIQUE
    
+References:   DRIBBLE (p443)
    
+Category:     CLARIFICATION
    
+Edit history: 06-Dec-87, Version 1 by Pitman
    
+              14-Feb-88, Version 2 by Masinter
    
+
    
+Problem Description:
    
+
    
+The intent and effect of DRIBBLE is not very clearly specified. Users have
    
+complained that DRIBBLE behaves quite differently in different implementations.
    
+
    
+Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
    
+
    
+Clarify that DRIBBLE is intended primarily for interactive debugging and that
    
+its effect cannot be relied upon from programs.
    
+
    
+Test Case:
    
+
    
+ #1: (PROGN (DRIBBLE "temp")
    
+	    (PRINT 'FOO)
    
+            (DRIBBLE))
    
+
    
+ #2: (DRIBBLE "temp")
    
+     (PROGN (PRINT 'FOO)
    
+            (DRIBBLE)
    
+	    (PRINC 'BAR))	 
    
+
    
+Rationale:
    
+
    
+Users of DRIBBLE have been surprised about how differently DRIBBLE behaves in
    
+different implementations. This makes the status quo much more explicit and will
    
+lead to less surprise.
    
+
    
+Current Practice:
    
+
    
+Some implementations implement DRIBBLE as a function which simply assigns
    
+streams such as *STANDARD-OUTPUT* to broadcast streams (or the approximate
    
+equivalent thereof).  Even within this camp, there is not widespread agreement
    
+about which streams are affected. However, typically test case #1 will capture
    
+the output of (PRINT 'FOO) in the file "temp" and will execute (PRINT 'BAR) but
    
+not capture its output.
    
+
    
+Some implementations (eg, Symbolics) push to a recursive command loop when
    
+DRIBBLE is called with an argument, and return from that command loop when
    
+DRIBBLE is called with no argument. In these implementations, test case #1 will
    
+enter a recursive command loop upon the first call to DRIBBLE and will not
    
+execute the (PRINT 'FOO) until (DRIBBLE) is done interactively. When the second
    
+(DRIBBLE) in test case #1 is executed, DRIBBLE will complain that output is not
    
+currently being recorded. In test case #2, the output of (PRINT 'FOO) will be
    
+captured, but the form (PRINT 'BAR) will never be executed because (DRIBBLE)
    
+does not return normally (it throws).
    
+
    
+Cost to implementors:
    
+
    
+None. This is just a clarification.
    
+
    
+Cost to users:
    
+
    
+Anyone who currently uses DRIBBLE in code that is believed to be portable is
    
+kidding himself. If such code works in some implementations, it can continue to
    
+work.
    
+
    
+Benefits:
    
+
    
+Users will be aware that they cannot rely on DRIBBLE in portable code.
    
+
    
+Aesthetics:
    
+
    
+No apparent effect.
    
+
    
+Discussion:
    
+
    
+DRIBBLE, like other environment features, is a standard interface to a
    
+non-standard feature. As such, there is some question as to its place in the
    
+ANSI standard. However, if DRIBBLE remains in the standard, its behavior is made
    
+explicitly vague by this proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141.htm new file mode 100644 index 00000000..450415a3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue DYNAMIC-EXTENT-FUNCTION:EXTEND Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DYNAMIC-EXTENT-FUNCTION:EXTEND Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue DYNAMIC-EXTENT-FUNCTION:EXTEND:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141_w.htm new file mode 100644 index 00000000..d3142a26 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss141_w.htm @@ -0,0 +1,148 @@ + + + +CLHS: Issue DYNAMIC-EXTENT-FUNCTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DYNAMIC-EXTENT-FUNCTION Writeup

    + +
    Forum:		CLEANUP
    
+Issue:          DYNAMIC-EXTENT-FUNCTION
    
+References:     Scope and Extent
    
+		Issue DYNAMIC-EXTENT
    
+Category:       ADDITION
    
+Edit history:   04-Apr-89, Version 1 by Loosemore
    
+		11-Jun-89, Version 2 by Loosemore
    
+
    
+
    
+Problem Description:
    
+
    
+  Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89 
    
+  meeting, provides a mechanism for declaring that the values of
    
+  variables have only dynamic (rather than indefinite) extent.  It
    
+  would be useful to have similar functionality to indicate that
    
+  functional bindings may have only dynamic extent.  (For example,
    
+  this would permit compilers to stack-allocate closures.)
    
+
    
+Proposal (DYNAMIC-EXTENT-FUNCTION:EXTEND):
    
+
    
+  Extend the DYNAMIC-EXTENT declaration to accept arguments that are
    
+  lists of the form (FUNCTION <name>) where <name> is a function name,
    
+  as well as symbols.
    
+
    
+  A (FUNCTION <name>) list appearing in a DYNAMIC-EXTENT declaration is
    
+  used to declare that the lexically visible functional binding of <name>
    
+  has dynamic extent.  Except for the interpretation of <name> as the
    
+  name of a function instead of the name of a variable, such a declaration
    
+  otherwise has semantics that are identical to those already described
    
+  in proposal DYNAMIC-EXTENT:NEW-DECLARATION.
    
+
    
+Rationale:
    
+
    
+  This permits a programmer to offer advice to an implementation about
    
+  what functions may be stack-allocated for efficiency.
    
+
    
+  It may be difficult or impossible for a compiler to infer this
    
+  same information statically.
    
+
    
+Current Practice:
    
+
    
+  JonL says that Lucid's compiler can stack-allocate closures, but they
    
+  have no mechanism for programmers to give the compiler permission to
    
+  do so.
    
+
    
+  HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
    
+  all closures created within the scope of the declaration.
    
+
    
+  The Symbolics Genera compiler can often infer when functions can be 
    
+  implemented to have dynamic extent.  Also, if a function has a
    
+  SYS:DOWNWARD-FUNCTION declaration in front of its body, then the
    
+  function is implemented with dynamic extent regardless of whether
    
+  the compiler thinks all uses are "downward".  (This declaration is
    
+  rather peculiar because its scope is actually larger than the lambda
    
+  expression containing the declaration; implementationally, it's the
    
+  surrounding function definition.)
    
+
    
+Cost to Implementors:
    
+
    
+  No cost is forced since implementations are permitted to simply
    
+  ignore the DYNAMIC-EXTENT declaration.  
    
+
    
+Cost to Users:
    
+
    
+  None. This change is upward compatible.
    
+
    
+  There may be some hidden costs to debugging using this declaration (or any
    
+  feature which permits the user to access dynamic extent objects without
    
+  the compiler proving that they are appropriate). If the user misdeclares
    
+  something and returns a pointer into the stack (or stores it in the heap),
    
+  an undefined situation may result and the integrity of the Lisp storage
    
+  mechanism may be compromised. Debugging these situations may be tricky,
    
+  but users who have asked for this feature have indicated a willingness
    
+  to deal with such costs. Nevertheless, the perils should be clearly
    
+  documented and casual users should not be encouraged to use this
    
+  declaration.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some portable code would be forced to run more slowly (due to
    
+  GC overhead), or to use non-portable language features.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  This declaration allows a fairly low level optimization to work
    
+  by asking the user to provide only very high level information.
    
+  The alternatives (sharpsign conditionals, some of which may
    
+  lead to more bit-picky abstractions) are far less aesthetic.
    
+
    
+Discussion:
    
+
    
+  Loosemore supports DYNAMIC-EXTENT-FUNCTION:EXTEND.
    
+
    
+  This proposal does not attempt to address the issue of specifying
    
+  dynamic extent for anonymous closures (which is really a special case
    
+  of the more general problem of specifying dynamic extent for unnamed
    
+  objects of any type).  It's possible, although often awkward, to
    
+  restructure the program to give the object a name and explicitly
    
+  identify its extent.
    
+
    
+  One possible solution to the problem of dynamic extent for anonymous
    
+  lambdas would be to clarify that a reference to a closed-over variable
    
+  or function appearing lexically within a FUNCTION form is enough to
    
+  cause its value to be "saved" when the FUNCTION form is executed,
    
+  regardless of whether or not that reference is actually executed when
    
+  the resulting function is called.  Then, if all of the closed-over
    
+  functions and variables referenced within a closure are declared to
    
+  have dynamic extent, the closure could be assumed to have dynamic
    
+  extent as well.  (More precisely, its maximum extent would be the
    
+  intersection of the extents of the closed-over functions and
    
+  variables.)
    
+-------
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142.htm new file mode 100644 index 00000000..60ba6816 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue DYNAMIC-EXTENT:NEW-DECLARATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue DYNAMIC-EXTENT:NEW-DECLARATION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue DYNAMIC-EXTENT:NEW-DECLARATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142_w.htm new file mode 100644 index 00000000..8bcef7d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss142_w.htm @@ -0,0 +1,308 @@ + + + +CLHS: Issue DYNAMIC-EXTENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue DYNAMIC-EXTENT Writeup

    + +
    Status:	      passed, as amended, Mar 89 X3J13.
    
+Forum:	      Cleanup
    
+Issue:        DYNAMIC-EXTENT
    
+References:   Scope and Extent
    
+Category:     ADDITION
    
+Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
    
+  	      15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
    
+	      11-Jan-89, Version 3 by Masinter (Moon's proposal)
    
+	      05-Apr-89, Version 4 by Pitman and Steele (changes per X3J13)
    
+Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
    
+
    
+Problem Description:
    
+
    
+  Sometimes a programmer knows that a particular data structure
    
+  will have only dynamic extent. In some implementations, it is
    
+  possible to allocate such structures in a way that will make them
    
+  easier to reclaim than by general purpose garbage collection
    
+  (eg, on the stack or in some temporary area). Currently, however,
    
+  there is no way to request the use of such an allocation mechanism.
    
+
    
+Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
    
+
    
+  Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
    
+  this declaration are names of variables.
    
+
    
+  It is permissible for an implementation to simply ignore this declaration.
    
+  In implementations which do not ignore it, the compiler (or interpreter)
    
+  is free to make whatever optimizations are appropriate given this
    
+  information; the most common optimization is to stack-allocate the
    
+  initial value of the object. What data types (if any) can have dynamic
    
+  extent will can vary from implementation to implementation.
    
+
    
+  Definition: Object <x> is an ``otherwise inaccessible part'' (OIP)
    
+    of <y> iff making <y> inaccessible would make <x> inaccessible.
    
+    (Note that every object is an OIP of itself.)
    
+
    
+  Suppose that construct <c> contains a DYNAMIC-EXTENT declaration for
    
+  variable <v> (which need not be bound by <c>).  Consider the values
    
+  <w1>, ..., <wN> taken on by <v> during the course of some execution of
    
+  <c>.  The declaration asserts that if object <x> is an OIP of <wI>
    
+  when <wI> ever becomes the value of <v>, then just after execution of
    
+  <c> terminates <x> will be either inaccessible or still an OIP of <v>.
    
+
    
+  If the assertion is ever violated, the conseqeuences are undefined.
    
+
    
+Examples:
    
+
    
+  Since stack allocation of the initial value entails knowing at the
    
+  object's creation time that the object can be stack-allocated, it is
    
+  not generally useful to declare DYNAMIC-EXTENT for variables for
    
+  which have no lexically apparent initial value. For example,
    
+
    
+	(DEFUN F ()
    
+	  (LET ((X (LIST 1 2 3)))
    
+	    (DECLARE (DYNAMIC-EXTENT X))
    
+	    ...))
    
+
    
+  would permit those compilers which wish to do so to stack-allocate the
    
+  list in X. However,
    
+
    
+	(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
    
+	(DEFUN F () (G (LIST 1 2 3)))
    
+
    
+  could not typically permit a similar optimization in G because it would
    
+  be a modularity violation for the compiler to assume facts about G from
    
+  within F. Only an implementation which was willing to be responsible for
    
+  recompiling F if G's definition changed incompatibly could stack-allocate
    
+  the list argument to G in F.
    
+
    
+  Other interesting cases are:
    
+
    
+	(PROCLAIM '(INLINE G))
    
+	(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
    
+	(DEFUN F () (G (LIST 1 2 3)))
    
+
    
+    and	(DEFUN F ()
    
+	  (FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
    
+	    (G (LIST 1 2 3))))
    
+
    
+  where some compilers might realize the optimization was possible and others
    
+  might not.
    
+
    
+  An interesting variant of this is the so-called `stack allocated rest list'
    
+  which can be achieved (in implementations supporting the optimization) by:
    
+
    
+	(DEFUN F (&REST X)
    
+	  (DECLARE (DYNAMIC-EXTENT X))
    
+	  ...)
    
+
    
+  Note here that although the initial value of X is not explicit, the F
    
+  function is responsible for assembling the list X from the passed arguments,
    
+  so the F function can be optimized by the compiler to construct a 
    
+  stack-allocated list instead of a heap-allocated list in implementations
    
+  which support such.
    
+
    
+
    
+In
    
+            (LET ((X (LIST 'A1 'B1 'C1))
    
+                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
    
+              (DECLARE (DYNAMIC-EXTENT X Y))
    
+              ...)
    
+The OIP's of X are three conses, and the OIP's of Y are three other
    
+conses.  None of the symbols A1, B1, C1, A2, B2, C2, or NIL is an
    
+OIP of X or Y.  However, if a freshly allocated uninterned symbol had
    
+been used, it would have been an OIP.
    
+
    
+- - - - - - - -
    
+          (DOTIMES (I N) 
    
+            (DECLARE (DYNAMIC-EXTENT I))
    
+
    
+This is particularly instructive.  Since I is an integer by the
    
+definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
    
+integers, what are the OIP's of I, which this declaration
    
+requires the body of the DOTIMES not to "save"?  If the value of I is 3,
    
+and the body does (SETQ FOO 3), is that an error?  The answer is no, but
    
+the interesting thing is that it depends on the implementation-dependent
    
+behavior of EQ on numbers.  In an implementation where EQ and EQL are
    
+equivalent for 3, then 3 is not an OIP because (EQ I (+ 2 1)) is true,
    
+and therefore there is another way to access the object besides
    
+going through I.  On the other hand, in an implementation where EQ and
    
+EQL are not equivalent for 3, then the particular 3 that is the value of
    
+I is an OIP, but any other 3 is not.  Thus (SETQ FOO 3) is valid
    
+but (SETQ FOO I) is erroneous.  Since (SETQ FOO I) is erroneous in some
    
+implementations, it is erroneous in all portable programs, but some other
    
+implementations may not be able to detect the error.
    
+
    
+- - - - - - - -
    
+
    
+  (LET ((X (LIST 1 2 3)))
    
+    (DECLARE (DYNAMIC-EXTENT X))
    
+    (PRINT X)
    
+    NIL)
    
+  PRINT does not "save" any part of its input.
    
+  This prints (1 2 3)
    
+
    
+- - - - - - - -
    
+
    
+  (DO ((L (LIST-ALL-PACKAGES) (CDR L)))
    
+      ((NULL L))
    
+    (DECLARE (DYNAMIC-EXTENT L))
    
+    (PRINT (CAR L)))
    
+  prints all packages; none of the newly-allocated list structures are saved.
    
+- - - - - - - -
    
+  (DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
    
+  (ADD 1 2 3) => 6
    
+
    
+I.e., useful way to declare that &REST lists have dynamic extent
    
+- - - - - - - -
    
+  (DEFUN ZAP (X Y Z)
    
+    (DO ((L (LIST X Y Z) (CDR L)))
    
+	((NULL L))
    
+      (DECLARE (DYNAMIC-EXTENT L))
    
+      (PRIN1 (CAR L))))
    
+  (ZAP 1 2 3)
    
+  prints 123
    
+
    
+- - - - - - - -
    
+  (DEFUN ZAP (N M)
    
+    ;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
    
+    ;; It may be slow, but with a good compiler at least it
    
+    ;; doesn't waste much heap storage.  :-)
    
+    (LET ((A (MAKE-ARRAY N)))
    
+      (DECLARE (DYNAMIC-EXTENT A))
    
+      (DOTIMES (I N) 
    
+	(DECLARE (DYNAMIC-EXTENT I))
    
+	(SETF (AREF A I) (RANDOM (+ I 1))))
    
+      (AREF A M)))
    
+  (< (ZAP 5 3) 3) => T
    
+
    
+- - - - - - - -
    
+The following are in error, since the value of X is used outside of its
    
+extent:
    
+
    
+       (LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
    
+
    
+  (PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
    
+         NIL)
    
+
    
+- - - - - - - -
    
+
    
+Rationale:
    
+
    
+  This permits a programmer to offer advice to an implementation about
    
+  what may be stack-allocated for efficiency.
    
+
    
+  It may be difficult or impossible for a compiler to infer this
    
+  same information statically.
    
+
    
+  Since a number of implementations offer this capability and there
    
+  is demand from users for access to the capability, this ``codifies
    
+  existing practice.''
    
+
    
+  Because this approach is purely lexical, it does not interact badly with
    
+  other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
    
+  by same name) would.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera and Symbolics Cloe offer stack allocation, though not
    
+  in this strategy.
    
+
    
+  [KMP thinks that] Lucid supports the proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  No cost is forced since implementations are permitted to simply
    
+  ignore the DYNAMIC-EXTENT declaration.
    
+
    
+Cost to Users:
    
+
    
+  None. This change is upward compatible.
    
+
    
+  There may be some hidden costs to debugging using this declaration (or any
    
+  feature which permits the user to access dynamic extent objects without
    
+  the compiler proving that they are appropriate). If the user misdeclares
    
+  something and returns a pointer into the stack (or stores it in the heap),
    
+  an undefined situation may result and the integrity of the Lisp storage
    
+  mechanism may be compromised. Debugging these situations may be tricky,
    
+  but users who have asked for this feature have indicated a willingness
    
+  to deal with such costs. Nevertheless, the perils should be clearly
    
+  documented and casual users should not be encouraged to use this
    
+  declaration.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some portable code would be forced to run more slowly (due to
    
+  GC overhead), or to use non-portable language features.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  This declaration allows a fairly low level optimization to work
    
+  by asking the user to provide only very high level information.
    
+  The alternatives (sharpsign conditionals, some of which may
    
+  lead to more bit-picky abstractions) are far less aesthetic.
    
+
    
+Discussion:
    
+
    
+  A previous version of this proposal suggested primitives STACK-LET
    
+  and STACK-LET*. Consensus was that the more general declaration facility
    
+  would be more popular.
    
+
    
+  Moon came up with a description of something called a "proper part" which
    
+  Steele formalized into the idea of an "otherwise inaccessible part". The
    
+  two are essentially interchangeable, but Steele's description was more
    
+  rigorous.
    
+
    
+  KMP: ... it still raises the question of whether we should define 
    
+       per-function for every CL function whether any of the arguments is
    
+       permitted to be "saved" so that CL programs don't get any funny
    
+       surprises. If we don't, it ends up being implementor's discretion how
    
+       to resolve cases ... and everyone might not agree that all cases are
    
+       ... obvious ...
    
+
    
+  JonL: PDP10 MacLisp had a similar problem w.r.t pdlnums.  That is why
    
+	"identity" functions were so troublsome for it -- in order to
    
+        return a guaranteed safe value, it typically had to copy it's
    
+	pdlnum argument, thereby making some cases of "fast arithmetic" 
    
+	code much worse than interpreted code!  [Remember PRINT in MacLisp?
    
+	it returns T rather than it's argument for just this reason.]
    
+
    
+	It is necessary for an optimizing compiler to know something about
    
+	what happens to the data it passes along to "system" functions; for
    
+	example, it could assume that GET doesn't clobber the list given
    
+	to it, nor does it retain pointers to any part of it [what was the
    
+	terminology in the revised proposal?  "saved"? and "proper part"?]
    
+	The issue LISP-SYMBOL-REDEFINITION might help here, in that an
    
+	implementation's compilers could depend upon it's own internal
    
+	database.  But it wouldn't hurt at all to have some of these
    
+	requirements "up front" in the standard.
    
+
    
+  It was generally agreed that we would also like to consider a proposal
    
+  on dynamic extent functions at the next meeting. (Sandra said she would
    
+  prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143.htm new file mode 100644 index 00000000..3b6c54ea --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue EQUAL-STRUCTURE:MAYBE-STATUS-QUO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EQUAL-STRUCTURE:MAYBE-STATUS-QUO Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue EQUAL-STRUCTURE:MAYBE-STATUS-QUO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143_w.htm new file mode 100644 index 00000000..b6a1f4e0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss143_w.htm @@ -0,0 +1,198 @@ + + + +CLHS: Issue EQUAL-STRUCTURE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EQUAL-STRUCTURE Writeup

    + +
    Status:	Passed as amended, Jun 89 X3J13
    
+Issue:        EQUAL-STRUCTURE
    
+References:   EQUAL (p80), EQUALP (p81)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 18-Mar-88, Version 1 by Pitman
    
+	      08-Jun-88, Version 2 by Masinter (add Benson's proposal)
    
+	      23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
    
+	      01-Oct-88, Version 4 by Masinter (fix description)
    
+	      01-Oct-88, Version 5 by Pitman   (correct wording, add discussion)
    
+	      11-Jan-89, Version 6 by Pitman   (attempt EQUALP correction)
    
+		15-Mar-89, Version 7 by Masinter (amended as per vote at Jan 89 X3J13)
    
+		3-Jul-89, Version 8, by Masinter (amended as per Jun89 X3J13)
    
+
    
+Problem Description:
    
+
    
+  The behavior of EQUAL and EQUALP on structures is a subject of controversy.
    
+  At issue are whether these functions should descend the slots of structures
    
+  or use simply the structure's primitive identity (i.e., EQ) to test for
    
+  equivalence.
    
+
    
+Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):
    
+
    
+  Clarify that EQUAL and EQUALP do not descend any structures or data types
    
+  other than the ones explicitly specified here:
    
+
    
+   Type                     EQUAL Behavior        EQUALP Behavior
    
+ 
    
+   Number                     uses EQL               uses =
    
+   Character                  uses EQL               uses CHAR-EQUAL
    
+   Cons                       descends               descends
    
+   Bit-Vector                 descends               descends
    
+   String                     descends               descends
    
+   Pathname                   magic per CLtL         same as EQUAL
    
+   Structure                  uses EQ                (see below)
    
+   other Array                uses EQ                descends
    
+   Hash-Table                 uses EQ                (see below)
    
+   Instance (Standard-Object) uses EQ                uses EQ
    
+   Other                      uses EQ                uses EQ
    
+
    
+  Note that the order of this table is in some cases important, with upper
    
+  entries taking priority over lower ones.
    
+
    
+  EQUALP descends hash tables by first comparing the count of entries
    
+  and the :TEST function; if those are the same, it compares the
    
+  keys of the tables using the :TEST function and then the values
    
+  of the matching keys using EQUALP recursively.
    
+
    
+  EQUALP on two DEFSTRUCT objects 's1' and 's2', where one is a
    
+  non-:TYPEed DEFSTRUCT and the other is typed, is false.
    
+
    
+  EQUALP on two DEFSTRUCT objects 's1' and 's2', where both are
    
+  non-:TYPEed DEFSTRUCTS is true iff:
    
+
    
+  (1) The type of 's1' is the same as the type of 's2' (this is
    
+   the same as saying that the defstruct name for 's1' is the same
    
+   as that for 's2').
    
+
    
+  (2) The value of each slot of 's1' is EQUALP to the value of the
    
+  same slot of 's2' (where "same" means same name) (this is not the
    
+  same as 'slots' for standard-objects in CLOS).
    
+ 
    
+Rationale:
    
+
    
+  There seem to be as many different equality primitives as there
    
+  are applications for them. None of the possible ways of changing
    
+  EQUAL or EQUALP are flawless. Given the inability to "fix" them,
    
+  it is better to leave them alone.
    
+
    
+Current Practice:
    
+
    
+  We are unaware of any extensions to CLtL's set of operations,
    
+  although frequently users request them.
    
+
    
+Cost to Implementors:
    
+
    
+  Since this seems to be compatible with the status quo, none.
    
+
    
+Cost to Users:
    
+
    
+  Same
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
    
+
    
+Benefits:
    
+
    
+  A feeling that EQUAL and EQUALP exist and/or do what they do because serious
    
+  consideration was given and we consciously decided on a particular resolution
    
+  to the numerous questions that have come up about them.
    
+
    
+Aesthetics:
    
+
    
+  There seems to be wide debate about what the proper aesthetics for
    
+  how equality should work in Common Lisp. While the status quo is not
    
+  aesthetically more pleasing than the various alternatives, aesthetic
    
+  considerations vary widely. Different people model structures
    
+  differently. Sometimes the same person models structures differently in
    
+  different situations. The question of which should be descended and which
    
+  should not is a very personal one, and the aesthetic attractiveness of any
    
+  of these options will vary from person to person or application to
    
+  application.
    
+
    
+Discussion:
    
+
    
+  An earlier version of this issue with various alternatives was distributed
    
+  at the June 1988 X3J13 meeting. Since
    
+  this is a frequently raised issue, we thought we should submit it
    
+  as a clarification although there is no change to CLtL.
    
+
    
+  Options for which we considered proposals were:
    
+    - removing EQUAL and EQUALP from the standard.
    
+    - changing EQUALP to descend structures.
    
+    - changing EQUALP to be case sensitive.
    
+    - adding a :TEST keyword to EQUAL.
    
+    - making EQUAL a generic function
    
+  All of these had some serious problems.
    
+
    
+  The cleanup committee supports option STATUS-QUO.
    
+
    
+  It would be useful if descriptions of EQUAL and EQUALP contained some sort
    
+  of additional commentary alluding to the complex issues discussed here.
    
+  The following is offered to the Editorial staff as a starting point:
    
+
    
+    Object equality is not a concept for which there is a uniquely
    
+    determined correct algorithm. The appropriateness of an equality
    
+    predicate can be judged only in the context of the needs of some
    
+    particular program. Although these functions take any type of
    
+    argument and their names sound very generic, EQUAL and EQUALP are
    
+    not appropriate for every application. Any decision to use or not
    
+    use them should be determined by what they are documented to do
    
+    rather than any abstract characterization of their function. If
    
+    neither EQUAL nor EQUALP is found to be appropriate in a particular
    
+    situation, programmers are encouraged to create another operator
    
+    that is appropriate rather than blame EQUAL or EQUALP for ``doing
    
+    the wrong thing.''
    
+
    
+ 
    
+Additional Comments to Version 6:
    
+
    
+Version 6 attempts to fix some of the problems noted in Version 5.
    
+There are still some open questions. Only the "Proposal"
    
+part has been changed since Version 5; some of the costs,
    
+benefits & other discussion is now incorrect.
    
+
    
+Kent says:
    
+
    
+Please read this very carefully before voting in favor of it.
    
+There were a lot of Yes votes for the last version, which I think
    
+had some serious bugs in it. This would be a very bad issue for
    
+us to screw up.
    
+
    
+Things that might need special attention:
    
+
    
+ - Moon contends that standard practice in Symbolics Lisp is
    
+   for instances to be compared using EQ under EQUALP, not by
    
+   descending. There may be performance issues involved here.
    
+   Some agreement needs to be reached.
    
+
    
+ - Neither the previous version of the proposal nor CLtL was
    
+   clear on what happens to pathnames under EQUALP. This showed
    
+   up when I converted the presentation below. That issue should
    
+   be addressed as well.
    
+
    
+Hopefully if this version of the proposal isn't something you want to
    
+vote yes for, at least it's in a suitable form for easy line-item
    
+changes interactively in the meeting.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144.htm new file mode 100644 index 00000000..23e078b3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ERROR-TERMINOLOGY-WARNING:MIGHT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ERROR-TERMINOLOGY-WARNING:MIGHT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ERROR-TERMINOLOGY-WARNING:MIGHT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144_w.htm new file mode 100644 index 00000000..6a75b7da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss144_w.htm @@ -0,0 +1,92 @@ + + + +CLHS: Issue ERROR-TERMINOLOGY-WARNING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ERROR-TERMINOLOGY-WARNING Writeup

    + +
    Issue:         ERROR-TERMINOLOGY-WARNING
    
+
    
+References:    ANSI CL spec (Jul 20, 1989 draft) p.1-12
    
+
    
+Category:      CHANGE (to terminology only)
    
+
    
+Edit history:  1-Feb-90, Version 1 by Moon
    
+               4-May-90, Version 2 by Moon (fix critical typo)
    
+
    
+Problem description:
    
+
    
+  Page 1-12 of the draft defines the phrase "a warning should be issued"
    
+  in a way that is not consistent with "an error should be signalled."
    
+  The latter "should" refers to the safety level, but the former
    
+  "should" just means "might" (depending on the implementation).
    
+
    
+  To use this term is to muddy the otherwise clear conceptual relation
    
+  between "should" and "high safety".
    
+
    
+  This is Symbolics issue #1.
    
+
    
+Proposal (ERROR-TERMINOLOGY-WARNING:MIGHT):
    
+
    
+  Change the term to "a warning might be issued" and update all uses of
    
+  the term throughout the document.
    
+
    
+Rationale:
    
+  
    
+  It's important for the document to be consistent in its terminology.
    
+  
    
+Current practice:
    
+
    
+  People are sloppy in their terminology.
    
+
    
+Cost to Implementors:
    
+
    
+  None.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  The specification document will be more difficult to understand.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  The specification document will be less difficult to understand.
    
+
    
+Esthetics:
    
+
    
+  The specification document will be less difficult to understand.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145.htm new file mode 100644 index 00000000..6330fd71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EVAL-OTHER:SELF-EVALUATE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EVAL-OTHER:SELF-EVALUATE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EVAL-OTHER:SELF-EVALUATE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145_w.htm new file mode 100644 index 00000000..c8986888 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss145_w.htm @@ -0,0 +1,126 @@ + + + +CLHS: Issue EVAL-OTHER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EVAL-OTHER Writeup

    + +
    Issue:        EVAL-OTHER
    
+References:   5.1.1 Self-Evaluating Forms (p55)
    
+Category:     ADDITION/CLARIFICATION
    
+Edit history: 07-Mar-88, Version 1 by Pitman
    
+		   8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)
    
+
    
+Problem Description:
    
+
    
+  CLtL does not specify what the evaluation behavior of some data types.
    
+
    
+Proposal (EVAL-OTHER:SELF-EVALUATE):
    
+
    
+  Standard data types (those mentioned by CLtL) other than those for which
    
+  a more explicit evaluation rule exists would be defined to self-evaluate.
    
+  Such data types include, for example, structures, arrays, vectors, and
    
+  pathnames.
    
+
    
+  Structure types defined by users using DEFSTRUCT should also self-evaluate
    
+  unless an explicit implementation type for the structure is given in the
    
+  DEFSTRUCT, in which case the rule for evaluation of that type should be
    
+  used. (This is important in the case of type LIST.)
    
+
    
+Test Case:
    
+
    
+  (LET ((TEMP (MAKE-PATHNAME)))  (EQ TEMP (EVAL TEMP))) => T
    
+  (LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T
    
+
    
+Rationale:
    
+
    
+  There are numerous possible positions that could be taken, from
    
+  requiring that an error be signalled for all of these cases to
    
+  requiring that these all have some useful behavior.
    
+
    
+  By making implementations agree, code portability is enhanced.
    
+  By biasing the decision away from the "signal
    
+  an error" end of the choice spectrum, the least interruption is
    
+  caused to implementations which already have working code.
    
+
    
+  There is still some chance that implementations will have some other
    
+  behavior than either signalling an error or self-evaluating, but there
    
+  are probably few if any.
    
+
    
+Current Practice:
    
+
    
+  In many implementations, the other data types besides those mentioned in
    
+  CLtL will self-evaluate.
    
+
    
+Cost to Implementors:
    
+
    
+  The cost is probably small. This is probably an "upward compatible"
    
+  change for most or all implementations -- a few lines of change in the
    
+  interpreter and/or compiler. Some code walkers may be affected as well.
    
+
    
+Cost to Users:
    
+
    
+  None, if they are not exploiting implementation-dependent features of
    
+  some implementation that is being forced to make an incompatible change.
    
+
    
+  There should be no performance impact since the evaluator's test for these
    
+  new data types can simply be made to follow other tests already in place,
    
+  so existing code will not be slowed.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Implementations will continue to differ in this relatively
    
+  user-visible way.
    
+
    
+Benefits:
    
+
    
+  Portability will be enhanced because implementations will tend to agree
    
+  in places where they have traditionally not always agreed.
    
+
    
+Aesthetics:
    
+
    
+  Some fans of 3LISP may find this invasive to their sense of distinction
    
+  between objects and the notation used to describe objects. In general,
    
+  however, this is a fairly picky detail that is not likely to trouble the
    
+  average programmer.
    
+
    
+Discussion:
    
+
    
+This idea for this proposal was suggested by the Japanese community.
    
+Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE.
    
+
    
+Fahlman: "... I do remember the original design discussions.  It was
    
+proposed that everything but lists and symbols evaluate to themselves,
    
+but at the time (this was quite early in the process) some people felt
    
+that this might close out interesting parts of the design space that
    
+might turn out to be useful for something.  This hasn't happened, and
    
+I think it would be reasonable to close this door now.  Some users do
    
+find it confusing that you have to quote vectors but not strings."
    
+
    
+There has been some additional discussion of this proposal (for example,
    
+an explaination of why a similar proposal in Scheme might be a bad design.)
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146.htm new file mode 100644 index 00000000..307bee01 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146_w.htm new file mode 100644 index 00000000..18acb085 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss146_w.htm @@ -0,0 +1,166 @@ + + + +CLHS: Issue EVAL-TOP-LEVEL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EVAL-TOP-LEVEL Writeup

    + +
    Forum:		Public Review
    
+Issue:		EVAL-TOP-LEVEL
    
+References:	Loosemore's public review comment #29 (X3J13/92-1329)
    
+		Section 3.2.3.1, "Processing of Top Level Forms"
    
+		EVAL, LOAD, COMPILE-FILE
    
+		Issue EVAL-WHEN-NON-TOP-LEVEL
    
+Category:	CLARIFICATION, CHANGE
    
+Edit history:	12 Dec 90, Version 1 by Tim Moore
    
+		14 Dec 90, Version 2 by Moore w/ comments from Loosemore
    
+		08 Mar 91, Version 3 by Moore, discussion from rwk and JonL
    
+		06 Feb 93, Version 4 by Loosemore
    
+		  (new proposal, update writeup)
    
+Status:		Proposal LIKE-COMPILER (version 3) failed 4-9 at
    
+		  the March 1991 meeting.
    
+		Proposal LOAD-LIKE-COMPILE-FILE passed 5-2 at the
    
+		  October 1993 meeting.
    
+
    
+
    
+Problem description:
    
+
    
+  Section 3.2.3.1, "Processing of Top Level Forms" specifies the 
    
+  processing of top-level forms in the file compiler in great detail.
    
+  Unfortunately, there is no such specification of the evaluator or
    
+  loader's top level behavior.  If the evaluator or loader does not 
    
+  process top-level forms in the same way that the compiler does, there 
    
+  can be a surprising semantic gap between the compiler and interpreter.
    
+  It may be impossible to evaluate forms that macroexpand into more than 
    
+  one top-level form.  For example:
    
+
    
+    (progn
    
+      (defsetf foo setf-foo)
    
+      (defun bar (u v)
    
+        (setf (foo u) v)))
    
+
    
+  If the DEFSETF form is not evaluated before the function definition is
    
+  processed, the SETF form will expand incorrectly into:
    
+
    
+    (funcall (function (setf foo)) v u)
    
+
    
+  instead of:
    
+
    
+    (setf-foo u v)
    
+
    
+  The net result is that code which has been carefully structured to
    
+  compile correctly under the order-of-processing constraints given in
    
+  section 3.2.3.1 may fail to work when loaded interpretively.
    
+
    
+  At least two implementations -- UCL and WCL -- have unwittingly 
    
+  stumbled into this trap by implementing evaluators that perform
    
+  implicit compilation before executing any code.
    
+
    
+
    
+Proposal (EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE):
    
+
    
+  Replace the fourth paragraph of the description section of the
    
+  dictionary entry for LOAD with:
    
+
    
+    \funref{load} sequentially executes each \term{form} it encounters
    
+    in the file named by \param{filespec}.  If the file is a source
    
+    file and the implementation chooses to perform 
    
+    \term{implicit compilation}, \funref{load} must recognize
    
+    \term{top level forms} as described in {\secref\TopLevelForms} and
    
+    arrange for each \term{top level form} to be executed before
    
+    beginning \term{implicit compilation} of the next.  (Note, however, 
    
+    that processing of \specref{eval-when} forms by \funref{load} is 
    
+    controlled by the \kwd{execute} situation.)
    
+
    
+
    
+Rationale:
    
+
    
+  Everybody seems to agree that it's a bug for implementations *not*
    
+  to be able to load files containing top-level forms such as that
    
+  given in the problem description section.  Having the standard say
    
+  something explicit about it will hopefully prevent implementors
    
+  from overlooking this source of bugs in the future.
    
+
    
+
    
+Current practice:
    
+
    
+  UCL and WCL have had problems with this in the past.  It's not known
    
+  whether or how they have been fixed.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  In those implementations that do implicit compilation, minor hacks
    
+  to make LOAD or EVAL to do stuff similar to the top-level COMPILE-FILE
    
+  processing.  None in other implementations.
    
+
    
+
    
+Cost to users:
    
+
    
+  None.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Neutral.
    
+
    
+
    
+Editorial impact:
    
+
    
+  Inserting the text included above.
    
+
    
+  (It would probably be better to reorganize this material into a separate
    
+  section describing program structure rather than talking about the
    
+  behavior of LOAD and COMPILE-FILE, but that's too much work!)
    
+
    
+
    
+Discussion:
    
+
    
+  Sandra Loosemore says:
    
+
    
+    I submitted this as a public review comment after I discovered that
    
+    WCL was "broken" while trying to port some code last fall.  I had 
    
+    completely forgotten that the exact same problem had previously 
    
+    been presented as a cleanup issue to the committee until Kim Barrett 
    
+    mentioned it while we were sorting through the comments after the 
    
+    end of the public review period.
    
+
    
+  Version 3 of this issue contained a different proposal, LIKE-COMPILER,
    
+  which would have constrained EVAL rather than LOAD.  That proposal was
    
+  defeated at the March 1991 meeting, with people who voted against the
    
+  proposal arguing that
    
+
    
+    (eval x) 
    
+
    
+  should have completely equivalent semantics to
    
+
    
+    (funcall (compile nil `(lambda () ,x)))
    
+
    
+  The LOAD-LIKE-COMPILE-FILE proposal in version 4 avoids this problem
    
+  by constraining LOAD only.  However, it may be implemented either by
    
+  tweaking LOAD specifically or EVAL in general to process forms in 
    
+  the required order.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147.htm new file mode 100644 index 00000000..05194f51 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147_w.htm new file mode 100644 index 00000000..75250306 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss147_w.htm @@ -0,0 +1,522 @@ + + + +CLHS: Issue EVAL-WHEN-NON-TOP-LEVEL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EVAL-WHEN-NON-TOP-LEVEL Writeup

    + +
    Issue:        EVAL-WHEN-NON-TOP-LEVEL
    
+Forum:        Compiler
    
+References:   EVAL-WHEN (CLtL pp69-70),
    
+              Issue DEFINING-MACROS-NON-TOP-LEVEL
    
+	      Issue COMPILED-FUNCTION-REQUIREMENTS
    
+	      Issue IN-PACKAGE-FUNCTIONALITY
    
+	      Issue LOCALLY-TOP-LEVEL
    
+Category:     CLARIFICATION/CHANGE
    
+Edit History: 06-May-88, Version 1 by Sandra Loosemore
    
+              16-Dec-88, Version 2 by Loosemore (alternate direction)
    
+              30-Dec-88, Version 3 by Loosemore (minor wording changes)
    
+              07-Jan-89, Version 4 by Loosemore (update discussion)
    
+              09-Feb-89, Version 5 by Pitman and Moon (some major changes)
    
+	      09-Mar-89, Version 6 by Loosemore (clean up wording)
    
+	      22-Mar-89, Version 7 by Loosemore (order of processing)
    
+Status:       Ready for release
    
+
    
+Problem Description:
    
+
    
+  The current description of how the compiler should handle EVAL-WHEN
    
+  only makes sense when it appears as a top-level form in the file being
    
+  compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
    
+  locations? Even if it is legitimate, what does it mean?
    
+ 
    
+  Another issue, referred to here as ``the EVAL-WHEN shadowing problem,''
    
+  is that some people have complained that shadowing the symbols EVAL,
    
+  COMPILE, or LOAD means that you have to also either shadow EVAL-WHEN
    
+  and define it to recognize the new symbol, or else you must resign
    
+  yourself to writing (EVAL-WHEN (... LISP:EVAL ...) ...),etc. all over.
    
+  While the goal here is not to solve this problem, it might be possible
    
+  to solve both problems at once.
    
+
    
+  There are two proposals presented here, GENERALIZE-EVAL and
    
+  GENERALIZE-EVAL-NEW-KEYWORDS.
    
+
    
+
    
+Background/Analysis:
    
+
    
+  The proposal which follows was constructed with the following goals
    
+  in mind:
    
+
    
+    1. The lexical and dynamic environment for the EVAL-WHEN body should
    
+       be the same for each situation.  That is, the body should ``mean
    
+       the same thing'' regardless of which situation is being processed.
    
+
    
+    2. The evaluation context for EVAL-WHEN should be the current
    
+       lexical environment.
    
+
    
+    3. At execution time, EVAL-WHEN should always return the result of
    
+       its last form if execution of the body occurred, or NIL if the
    
+       body was not executed.
    
+
    
+    4. If a top-level EVAL-WHEN has a LOAD keyword, its body should 
    
+       inherit top-level-ness during normal processing. This permits the
    
+       use of (EVAL-WHEN (EVAL COMPILE LOAD) ...) at top-level to mean
    
+       simply "Do whatever would normally be done for this body, but
    
+       also do something at compile time." This, in turn, will later be
    
+       the key to allowing defining forms to be usefully described in
    
+       terms of EVAL-WHEN.
    
+
    
+    5. Non-top-level expressions should have no effect until they are
    
+       executed. This is the key to making sure that any necessary
    
+       environment is present. Since the COMPILE keyword forces effects
    
+       to occur earlier than execution time, it follows from this that
    
+       any correct solution must not allow the COMPILE keyword to have
    
+       an effect at other than top-level.
    
+
    
+  To accomplish these goals, we formulated the following model:
    
+
    
+    The purpose of EVAL-WHEN is to accomodate the fact that some of the
    
+    semantic processing of an expression may usefully be partitioned
    
+    between compile time and run time in some circumstances.
    
+
    
+    (EVAL-WHEN (EVAL) <code>)
    
+    describes a general technique for accomplishing some particular goal
    
+    at normal program execution time. However, the pair of expressions
    
+    (EVAL-WHEN (COMPILE) <code-A>)
    
+    (EVAL-WHEN (LOAD) <code-B>)
    
+    can be used to describe an alternate technique for implementing part
    
+    of the effect (A) at compile-time, and part of the effect (B) at
    
+    load-time.
    
+
    
+
    
+Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL):
    
+
    
+  Replace the description of EVAL-WHEN with the following:
    
+
    
+  EVAL-WHEN ({situation}*) {form}*                      [Special Form]
    
+
    
+  The body of an EVAL-WHEN form is processed as an implicit PROGN, but
    
+  only in the situations listed.  Each SITUATION must be a symbol,
    
+  either COMPILE, LOAD, or EVAL.
    
+
    
+  The use of COMPILE and LOAD controls whether and when processing
    
+  occurs for top-level forms. The use of EVAL controls whether
    
+  processing occurs for non-top-level forms.
    
+
    
+  The EVAL-WHEN construct may be more precisely understood in terms of
    
+  a model of how the file compiler, COMPILE-FILE, processes forms in a
    
+  file to be compiled.
    
+
    
+  Successive forms are read from the file by the file compiler using 
    
+  READ. These top-level forms are normally processed in what we call
    
+  `not-compile-time' mode. There is one other mode, called 
    
+  `compile-time-too' mode, which can come into play for top-level
    
+  forms. The EVAL-WHEN special form is used to annotate a program
    
+  in a way that allows the program doing the processing to select
    
+  the appropriate mode.
    
+
    
+  Processing of top-level forms in the file compiler works as follows:
    
+
    
+   * If the form is a macro call, it is expanded and the result is
    
+     processed as a top-level form in the same processing mode
    
+     (compile-time-too or not-compile-time).
    
+
    
+   * If the form is a PROGN form, each of its body forms is
    
+     sequentially processed as top-level forms in the same processing
    
+     mode.
    
+
    
+   * If the form is a COMPILER-LET, MACROLET, or SYMBOL-MACROLET,
    
+     the file compiler makes the appropriate bindings and recursively
    
+     processes the body forms as an implicit top-level PROGN with those 
    
+     bindings in effect, in the same processing mode.
    
+
    
+   * If the form is an EVAL-WHEN form, it is handled according to
    
+     the following table:
    
+
    
+     COMPILE LOAD EVAL compile-time-too Action
    
+     
    
+       Yes   Yes  --     --             Process body in compile-time-too mode
    
+       No    Yes  Yes    Yes            Process body in compile-time-too mode
    
+       No    Yes  Yes    No             Process body in not-compile-time mode
    
+       No    Yes  No     --             Process body in not-compile-time mode
    
+       Yes   No   --     --             Evaluate body
    
+       No    No   Yes    Yes            Evaluate body
    
+       No    No   Yes    No             do nothing
    
+       No    No   No     --             do nothing
    
+
    
+     "Process body" means to process the body as an implicit top-level
    
+     PROGN.  "Evaluate body" means to evaluate the body forms as in
    
+     implicit PROGN in the dynamic execution context of the compiler and
    
+     in the lexical environment in which the EVAL-WHEN appears.
    
+
    
+   * Otherwise, the form is a top-level form that is not one of the
    
+     special cases.  If in compile-time-too mode, the compiler first
    
+     evaluates the form and then performs normal compiler processing
    
+     on it.  If in not-compile-time mode, only normal compiler
    
+     processing is performed.  [The nature of this processing is
    
+     defined more precisely in issue COMPILED-FUNCTION-REQUIREMENTS.]
    
+     Any subforms are treated as non-top-level forms.
    
+
    
+  Note that top-level forms are guaranteed to be processed in the order
    
+  in which they textually appear in the file, and that each top-level
    
+  form read by the compiler is processed before the next is read.
    
+  However, the order of processing (including, in particular, macro
    
+  expansion) of subforms that are not top-level forms is unspecified.
    
+
    
+  For an EVAL-WHEN form that is not a top-level form in the file compiler
    
+  (that is, one of: in the interpreter; in COMPILE; or in the file
    
+  compiler but not at top-level), if the EVAL situation is specified,
    
+  its body is treated as an implicit PROGN.  Otherwise, the EVAL-WHEN
    
+  form returns NIL.
    
+
    
+
    
+ Clarifications/Consequences:
    
+
    
+  The following effects are logical consequences of the above proposal:
    
+
    
+   * It is never the case that the execution of a single EVAL-WHEN
    
+     expression will execute the body code more than once.
    
+
    
+   * The keyword `EVAL' is a misnomer because execution of
    
+     the body need not be done by EVAL. In compiled code, such as
    
+     (DEFUN FOO () (EVAL-WHEN (EVAL) (PRINT 'FOO)))
    
+     the call to PRINT should be compiled.
    
+
    
+   * Macros intended for use in top-level forms should arrange for all
    
+     side-effects to be done by the forms in the macro expansion.
    
+     The macro-expander itself should not do the side-effects.
    
+
    
+       Wrong:  (defmacro foo ()
    
+                 (really-foo)
    
+                 `(really-foo))
    
+    
    
+       Right:  (defmacro foo ()
    
+                 `(eval-when (compile eval load) (really-foo)))
    
+
    
+     Adherence to this convention will mean that such macros will behave
    
+     intuitively when placed in non-top-level positions.
    
+
    
+   * Placing a variable binding around an EVAL-WHEN reliably captures the
    
+     binding because the `compile-time-too' mode cannot occur (because 
    
+     introducing a variable binding would mean we were not at top level).
    
+     For example,
    
+
    
+        (LET ((X 3))
    
+          (EVAL-WHEN (EVAL LOAD COMPILE) (PRINT X)))
    
+
    
+     will print 3 at execution [load] time, and will not print anything at
    
+     compile time.  This is important so that expansions of DEFUN and 
    
+     DEFMACRO can be done in terms of EVAL-WHEN and can correctly capture
    
+     the lexical environment.
    
+
    
+        (DEFUN BAR (X) (DEFUN FOO () (+ X 3)))
    
+
    
+     might expand into
    
+
    
+        (DEFUN BAR (X) 
    
+          (PROGN (EVAL-WHEN (COMPILE) 
    
+                   (COMPILER::NOTICE-FUNCTION-DEFINITION 'FOO '(X)))
    
+                 (EVAL-WHEN (EVAL LOAD)
    
+                   (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))))
    
+
    
+     which would be treated the same as
    
+
    
+        (DEFUN BAR (X) 
    
+          (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))
    
+
    
+     by the above rules.
    
+
    
+
    
+ Test Cases:
    
+
    
+  ;; #1: The EVAL-WHEN in this case is not at top-level, so only the EVAL
    
+  ;;     keyword is considered. At compile time, this has no effect.
    
+  ;;     At load time (if the LET is at top level), or at execution time
    
+  ;;     (if the LET is embedded in some other form which does not execute
    
+  ;;     until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
    
+  ;;     returns 1.
    
+ 
    
+  (LET ((X 1))
    
+    (EVAL-WHEN (EVAL LOAD COMPILE)
    
+      (SETF (SYMBOL-FUNCTION 'FOO1) #'(LAMBDA () X))))
    
+ 
    
+  ;; #2: If this expression occurs at the top-level of a file to be compiled,
    
+  ;;     it has BOTH a compile time AND a load-time effect of setting
    
+  ;;     (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
    
+ 
    
+  (EVAL-WHEN (EVAL LOAD COMPILE)
    
+    (LET ((X 2))
    
+      (EVAL-WHEN (EVAL LOAD COMPILE)
    
+        (SETF (SYMBOL-FUNCTION 'FOO2) #'(LAMBDA () X)))))
    
+ 
    
+  ;; #3: If this expression occurs at the top-level of a file to be compiled,
    
+  ;;     it has BOTH a compile time AND a load-time effect of setting the
    
+  ;;     function cell of FOO3 to a function which returns 3.
    
+ 
    
+  (EVAL-WHEN (EVAL LOAD COMPILE)
    
+    (SETF (SYMBOL-FUNCTION 'FOO3) #'(LAMBDA () 3)))
    
+ 
    
+  ;; #4: This always does nothing. It simply returns NIL.
    
+ 
    
+  (EVAL-WHEN (COMPILE)
    
+    (EVAL-WHEN (COMPILE) 
    
+      (PRINT 'FOO4)))
    
+ 
    
+  ;; #5: If this form occurs at top-level of a file to be compiled, FOO5 is
    
+  ;;     printed at compile time. If this form occurs in a non-top-level
    
+  ;;     position, nothing is printed at compile time. Regardless of context,
    
+  ;;     nothing is ever printed at load time or execution time.
    
+ 
    
+  (EVAL-WHEN (COMPILE) 
    
+    (EVAL-WHEN (EVAL)
    
+      (PRINT 'FOO5)))
    
+
    
+  ;; #6: If this form occurs at top-level of a file to be compiled, FOO6 is
    
+  ;;     printed at compile time.  If this form occurs in a non-top-level
    
+  ;;     position, nothing is printed at compile time. Regardless of context,
    
+  ;;     nothing is ever printed at load time or execution time.
    
+
    
+  (EVAL-WHEN (EVAL LOAD)
    
+    (EVAL-WHEN (COMPILE)
    
+      (PRINT 'FOO6)))
    
+ 
    
+ Rationale:
    
+  
    
+  This is compatible with any guarantees made by CLtL, and extends the
    
+  behavior usefully to non-top-level situations.
    
+
    
+  This gives a useful meaning to EVAL-WHEN that supports useful and
    
+  predictable behavior if defining macros are used in a non-top-level
    
+  situation.
    
+
    
+  The constraints on the order in which top-level forms are processed
    
+  ensure that the compile-time effects of defining macros and EVAL-WHENs
    
+  at the beginning of the file are visible during the processing of
    
+  forms that appear later in the file, which is what most users expect.
    
+  Leaving the order of processing of non-top-level forms unspecified
    
+  allows the compiler to perform certain kinds of transformations that
    
+  change the textual order of subforms.  Users should not depend on 
    
+  side-effects from macros that require them to be expanded in any
    
+  particular order.
    
+
    
+
    
+Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS):
    
+
    
+  As in GENERALIZE-EVAL, but rename the EVAL keyword to :EXECUTE,
    
+  the COMPILE keyword to :COMPILE-TOPLEVEL, and LOAD keyword to 
    
+  :LOAD-TOPLEVEL.
    
+
    
+  Deprecate the use of keywords EVAL, COMPILE, and LOAD to EVAL-WHEN.
    
+  For compatibility, they are supported in EVAL-WHEN
    
+  at top-level, but their meaning is not defined elsewhere.
    
+
    
+ Rationale:
    
+
    
+  The fact that the situation keywords chosen are not the same as
    
+  those now used means that the change can be added in a way that
    
+  is truly upward compatible (not only with CLtL but with existing
    
+  practice in implementations which have chosen to extend or `clarify'
    
+  the definition given in CLtL) since the meaning of EVAL, COMPILE,
    
+  and LOAD in non-top-level situations (which was never spelled
    
+  out in CLtL) can legitimately differ from the meaning of these
    
+  new keywords.
    
+
    
+  Using other names and/or the keyword package for the names of
    
+  situations solves the EVAL-WHEN shadowing problem.
    
+
    
+  The name `execute' does not promote the confusion that the body of an
    
+  EVAL-WHEN must be executed only in the evaluator. It also does not
    
+  promote the confusion that the body of an EVAL-WHEN, regardless of when
    
+  executed, must run interpreted.
    
+
    
+  The names `compile-toplevel' and `load-toplevel' emphasize the fact
    
+  that these cases are not interesting in non-top-level positions.
    
+
    
+
    
+Current Practice:
    
+
    
+  In Symbolics Genera, the interpreter permits EVAL-WHEN in non-top-level 
    
+  positions in a way that is compatible with this proposal but both the
    
+  COMPILE and COMPILE-FILE functions complain about EVAL-WHEN in a
    
+  non-top-level position.
    
+
    
+  Both Lucid Common Lisp and Kyoto Common Lisp already interpret the
    
+  EVAL keyword to mean "execute" in non-top-level situations.  Both of
    
+  these implementations also make (EVAL-WHEN (LOAD) ...) suppress
    
+  compile-time "magic" from defining macros such as DEFMACRO.
    
+
    
+  IIM describes its EVAL-WHEN as:
    
+   (defmacro eval-when (situations &body body &environment env)
    
+     (if (not (compiler-environment-p env))
    
+         (when (member 'eval situations) `(progn ,@body))
    
+         (progn
    
+           (when (member 'compile situations)
    
+             (if (compiler-at-top-level-p env)
    
+                 (mapc #'eval body)
    
+                 (warn "Top-level form encountered at non-top-level.")))
    
+           (when (member 'load situations) `(progn ,@body)))))
    
+  Note that the interpretation of the EVAL situation and the nesting
    
+  behavior is different.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+  The actual change to EVAL-WHEN in both cases is probably fairly
    
+  localized and straightforward to make in most or all implementations.
    
+
    
+  The second-order costs of proposal GENERALIZE-EVAL will vary depending
    
+  on whether existing implementations have extended the definition of
    
+  EVAL-WHEN in incompatible ways. If an implementation has made such
    
+  extensions, there may be user and system code which depends on them
    
+  and the cost of converting that code may be non-trivial. There is
    
+  presumably also documentation impact.
    
+
    
+  Proposal GENERALIZE-EVAL-NEW-KEYWORDS avoids most or all of the 
    
+  second-order costs of proposal GENERALIZE-EVAL.
    
+
    
+  The compiler processing for top-level forms might be implemented 
    
+  something like:
    
+
    
+  ;;; Forms read by the file compiler are passed to PROCESS-TOP-LEVEL-FORM
    
+  ;;;    with a env compile-time-too both NIL.
    
+  
    
+  (defun process-top-level-form (form env compile-time-too)
    
+      (setq form (macroexpand form env))
    
+      (cond ((not (consp form))
    
+             nil)
    
+            ((eq (car form) 'progn)
    
+             (dolist (f (cdr form))
    
+                 (process-top-level-form f env compile-time-too)))
    
+            ((eq (car form) 'compiler-let)
    
+             (process-compiler-let form env compile-time-too))
    
+            ((eq (car form) 'macrolet)
    
+             (process-macrolet form env compile-time-too))
    
+            ((eq (car form) 'symbol-macrolet)
    
+             (process-symbol-macrolet form env compile-time-too))
    
+            ((eq (car form) 'eval-when)
    
+             (process-eval-when form env compile-time-too))
    
+            (t
    
+             (if compile-time-too
    
+                 (internal-eval form env))
    
+             (compile-form form env))
    
+            ))
    
+  
    
+  (defun process-eval-when (form env compile-time-too)
    
+      (let* ((situations  (cadr form))
    
+             (body        (cddr form))
    
+             (compile-p   (member 'compile situations))
    
+             (load-p      (member 'load situations))
    
+             (eval-p      (member 'eval situations)))
    
+          (cond ((or (and compile-p load-p)
    
+                     (and eval-p load-p compile-time-too))
    
+                 (process-top-level-form `(progn ,@body) env t))
    
+                (load-p
    
+                 (process-top-level-form `(progn ,@body) env nil))
    
+                ((or compile-p
    
+                     (and eval-p compile-time-too))
    
+                 (dolist (f body)
    
+                     (internal-eval f env)))
    
+                (t
    
+                 nil))))
    
+  
    
+  ;;; PROCESS-COMPILER-LET, PROCESS-MACROLET, and PROCESS-SYMBOL-MACROLET
    
+  ;;;    do the obvious things.
    
+  ;;; INTERNAL-EVAL evaluates "form" in lexical environment "env".
    
+
    
+
    
+Cost to Users:
    
+
    
+  Technically, none. Either proposal is technically upward compatible
    
+  with CLtL.
    
+
    
+  Proposal GENERALIZE-EVAL might force some extended implementations to
    
+  change incompatibly. As such, some users who depend on 
    
+  implementation-dependent extensions might have to adjust their code
    
+  somewhat to deal with those changes.
    
+
    
+  Proposal GENERALIZE-EVAL-NEW-KEYWORDS does not force implementations
    
+  to change incompatibly, so has no forced impact on users.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  EVAL-WHEN is a mess. Using it as the low-level substrate into which
    
+  defining macros should expand, and guaranteeing any predictable effects
    
+  of those macros in non-top-level situations is currently difficult and
    
+  would continue to be so in the absence of some resolution on this issue.
    
+
    
+Benefits:
    
+
    
+  The costs of non-adoption would be avoided:  it would be possible to
    
+  use EVAL-WHEN in many situations where it cannot currently be used
    
+  reliably.
    
+
    
+  The portability of many existing tools which use EVAL-WHEN internally
    
+  in macros will be enhanced.
    
+
    
+Aesthetics:
    
+
    
+  This generalization of the meaning makes the purpose and uses of 
    
+  EVAL-WHEN less mysterious. In that sense, aesthetics are simplified
    
+  somewhat.
    
+
    
+
    
+Discussion:
    
+
    
+  The cleanup issue LOCALLY-TOP-LEVEL would make LOCALLY also "pass
    
+  through" top-level-ness to its body.  The reason why that is not 
    
+  addressed in this issue is that it involves making LOCALLY a special
    
+  form.
    
+
    
+  Pitman and Moon don't care whether we say `top level,' `top-level,' or
    
+  `toplevel.' The spelling choices in this writeup are arbitrary. If
    
+  necessary, the proposal GENERALIZE-EVAL-NEW-KEYWORDS could be amended
    
+  to propose :COMPILE-TOP-LEVEL, etc.
    
+
    
+  Pitman, Moon, and Bob Laddaga (a Symbolics Cloe implementor) support
    
+  both of these proposals.  Pitman and Laddaga have a preference for
    
+  GENERALIZE-EVAL-NEW-KEYWORDS.  Moon is neutral about which should be
    
+  preferred.
    
+
    
+  Sandra Loosemore says:
    
+    I still feel somewhat uncomfortable with the definition of EVAL-WHEN
    
+    presented here, mostly because its nesting behavior is so unintuitive
    
+    (as in test case number 6).  We have also had a hard time in deciding
    
+    what the term "top-level" really means; the definition presented here
    
+    is rather arbitrary.  However, since we have run out of time in which
    
+    to come up with acceptable alternatives, I'm willing to go along with
    
+    proposal GENERALIZE-EVAL.  It is compatible with the description in
    
+    CLtL but presented in a more coherent way, and I think it is an
    
+    improvement.  On the other hand, I don't really like the idea of
    
+    changing the names of the keywords; if we are going to make an
    
+    incompatible change, the right thing to do would be to throw out
    
+    EVAL-WHEN entirely and start from scratch.
    
+
    
+  Treating MACROLET and SYMBOL-MACROLET (and possibly LOCALLY) 
    
+  complicates the treatment of top-level DEFMACROs and other
    
+  defining macros that cause functions to be created at compile-time
    
+  (because the lexical environment the functions are defined in may
    
+  not be null).  See issue DEFINING-MACROS-NON-TOP-LEVEL for details.-------
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148.htm new file mode 100644 index 00000000..cc5a50ed --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148_w.htm new file mode 100644 index 00000000..a852084a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss148_w.htm @@ -0,0 +1,121 @@ + + + +CLHS: Issue EVAL-WHEN-OBSOLETE-KEYWORDS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EVAL-WHEN-OBSOLETE-KEYWORDS Writeup

    + +
    Forum:		Public Review
    
+Issue:		EVAL-WHEN-OBSOLETE-KEYWORDS
    
+References:	Moon's public review comment #2 (X3J13/92-3202)
    
+		EVAL-WHEN
    
+		Issue EVAL-WHEN-NON-TOP-LEVEL
    
+Category:	CHANGE
    
+Edit history:	20 Dec 1992, Version 1 by Loosemore
    
+		08 Jan 1993, Version 2 by Loosemore (comments from Moon)
    
+		12 Sept 1993, Version 3 by Loosemore (add second proposal)
    
+Status:         Proposal REMOVE-OLD-KEYWORDS failed 3-6-0, March 1993
    
+		Proposal X3J13-MARCH-1993 passed 6-1, March 1993
    
+
    
+
    
+Problem description:
    
+
    
+  The language in draft 12.24 about the relationship between
    
+  the new EVAL-WHEN keywords :EXECUTE, :COMPILE-TOPLEVEL, and
    
+  :LOAD-TOPLEVEL and the old, deprecated keywords EVAL, COMPILE, and 
    
+  LOAD is confusing.  (For example, it's inconsistent about what
    
+  EVAL means when not at top level.)  The compatibility argument
    
+  for retaining two sets of keywords with slightly different
    
+  meanings is outweighed by the resulting confusion.
    
+
    
+
    
+Proposal (EVAL-WHEN-OBSOLETE-KEYWORDS:REMOVE-OLD-KEYWORDS):
    
+
    
+  Eliminate all mention of the old keywords EVAL, COMPILE, and LOAD
    
+  in connection with EVAL-WHEN.
    
+
    
+Proposal (EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MARCH-1993):
    
+
    
+  Generalize the use of the old keywords; define that eval-when always 
    
+  treats eval the same as :execute, compile the same as :compile-toplevel,
    
+  and load the same as :load-toplevel.
    
+
    
+
    
+Rationale:
    
+
    
+  Adopting this suggestion would shorten the specification and remove
    
+  an inconsistency.  There are so many incompatibilities between
    
+  CLtL1, CLtL2, and the draft standard that it's pointless to try to
    
+  allow for a modeless implementation that is simultaneously compatible
    
+  with all of them.
    
+
    
+
    
+Current practice:
    
+
    
+  Moon says he's not aware of any implementations whose current releases
    
+  don't support the new keywords.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Probably small; implementations could continue to support the old
    
+  keywords as an extension.
    
+
    
+
    
+Cost to users:
    
+
    
+  This is an incompatible change, but one that is easy to detect.  A
    
+  good implementation should complain about unrecognized EVAL-WHEN
    
+  keywords, anyway.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Making the standard simpler is a good thing.
    
+
    
+
    
+Editorial impact:
    
+
    
+  The dictionary entry for EVAL-WHEN is the only place affected.
    
+  (The discussion of EVAL-WHEN in the concept section relating to
    
+  file compilation uses the new keywords exclusively.)
    
+
    
+
    
+Discussion:
    
+
    
+  Moon says: 
    
+    I like EVAL-WHEN-NON-TOP-LEVEL:REMOVE-OLD-KEYWORDS (version 1).
    
+
    
+  Moon suggested (in his public review comment) that another way to 
    
+  resolve this problem would be to define the behavior of the old 
    
+  keywords to be exactly the same as that of the new keywords.
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149.htm new file mode 100644 index 00000000..62d3e67a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EVALHOOK-STEP-CONFUSION:FIX Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EVALHOOK-STEP-CONFUSION:FIX Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EVALHOOK-STEP-CONFUSION:FIX:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_m.htm new file mode 100644 index 00000000..ab139881 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue EVALHOOK-STEP-CONFUSION Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue EVALHOOK-STEP-CONFUSION Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_w.htm new file mode 100644 index 00000000..9c6626b3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss149_w.htm @@ -0,0 +1,178 @@ + + + +CLHS: Issue EVALHOOK-STEP-CONFUSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EVALHOOK-STEP-CONFUSION Writeup

    + +
    Forum:		Cleanup
    
+Issue:		EVALHOOK-STEP-CONFUSION
    
+References:	CLtL p 321, 323, 441
    
+		Issue STEP-ENVIRONMENT (passed)
    
+                Issue APPLYHOOK-ENVIRONMENT (passed)
    
+Category:	CHANGE/CLARIFICATION
    
+Edit History:   V1, 9 Oct 1989, Sandra Loosemore
    
+		V2, 2 Nov 1989, Sandra Loosemore (update discussion)
    
+	        V3, 4 Dec 1990, Pitman (amendment per X3J13)
    
+
    
+Problem Description:
    
+
    
+Common Lisp permits the evaluator to be implemented by compiling the
    
+form before executing it, but notes that this techniques "renders the
    
+EVALHOOK mechanism relatively useless" (CLtL p. 321).
    
+
    
+CLtL also requires the STEP utility to be implemented in terms of
    
+EVALHOOK (p. 323).  The restriction against implementing STEP using
    
+some other technique (such as annotations on code lexically within the
    
+body of the STEP) that make more sense in a compiled-only
    
+implementation is pointless.  It is probably not even desirable for
    
+STEP to be implemented with *EVALHOOK*, since this effectively causes
    
+the stepper to break on user programs that also use *EVALHOOK*.
    
+
    
+
    
+Proposal (EVALHOOK-STEP-CONFUSION:X3J13-NOV-89):
    
+
    
+(a) Remove the requirement that STEP be implemented using *EVALHOOK*.
    
+Make it explicitly vague whether the scope of the code that is affected
    
+by STEP is lexical or dynamic.
    
+
    
+(b) Delete *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.
    
+
    
+Proposal (EVALHOOK-STEP-CONFUSION:FIX):
    
+
    
+(1) Clarify that there is no guarantee that the functions that are the
    
+values of *EVALHOOK* and *APPLYHOOK* will ever be invoked during
    
+evaluation.
    
+
    
+(2) Remove the requirement that STEP be implemented using *EVALHOOK*.
    
+Make it explicitly vague whether the scope of the code that is affected
    
+by STEP is lexical or dynamic.
    
+
    
+(3) Deprecate *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.
    
+
    
+
    
+Rationale:
    
+
    
+Point by point:
    
+
    
+(1) This is merely an explicit statement of the status quo.
    
+
    
+(2) This permits compiled-only implementations to support a STEP
    
+utility that does something useful.
    
+
    
+(3) The eval hook mechanism is a relic of a particular interpreter
    
+implementation technique and really has no place in a language
    
+standard, especially since one of the stated goals of the language is
    
+consistency between compiled and interpreted code.  Since there is no
    
+guarantee that these functions will ever be invoked, portable programs
    
+should not rely on them.
    
+
    
+
    
+
    
+Current Practice:
    
+
    
+According to Kent Pitman:
    
+  I'm told by the guys who did the Cloe implementation that indeed
    
+  neither evalhook nor step do much of anything useful.  If I understood
    
+  them correctly, *evalhook* just never gets called, and step works by a
    
+  different mechanism that may work at a granularity different than what
    
+  people expect.
    
+
    
+Loosemore has been implementing an evaluator for Utah Common Lisp that
    
+uses a preprocessor to partially compile programs.  The interpreter
    
+for the processed code does support the use of an *evalhook*-like
    
+special variable, but the information it is passed is in a different
    
+format than that which *evalhook* requires.  In particular, the object
    
+representing the lexical environment contains only bindings and not
    
+syntactic information such as macro definitions.  It also supports a
    
+variety of annotation-based program debugging hooks that are specified
    
+by declarations.  We are in the process of integrating the
    
+preprocessor into the UCL compiler so that most of these debugging
    
+hooks will also work in compiled code.
    
+
    
+
    
+Cost to implementors:
    
+
    
+None.
    
+
    
+
    
+Cost to users:
    
+
    
+None.
    
+
    
+
    
+Benefits:
    
+
    
+Users will not be misled into thinking *evalhook* is more portable
    
+than it actually is.
    
+
    
+Compiled-only implementations can make STEP do something reasonable.
    
+
    
+
    
+Discussion:
    
+
    
+There is an article by Parker in Lisp Pointers, Vol 1 #4 which
    
+describes one approach for annotation-based debugging.  Loosemore's
    
+PhD dissertation (soon to be available as a UofU Tech Report) also
    
+discusses alternate approaches for implementing program steppers.
    
+
    
+Scott Fahlman says:
    
+  I am staying out of most of these discussions, but thought I'd throw in my
    
+  two cents' worth on this one: I would very much like to see evalhook and
    
+  applyhook removed from the standard.  They have been a constant source of
    
+  confusion, and there are so many different interpretations of what these
    
+  hooks do that facilities built on top of them are not really very portable
    
+  in practice.  I'm now convinced that a really good stepping package cannot
    
+  easily be written using these hooks, but must be integrated into the
    
+  interpreter of a given implementation.
    
+
    
+David Moon says:
    
+  Seems okay, except that if we are going to deprecate these things,
    
+  I would much rather just remove them.  You would surely argue that
    
+  no significant program could possibly be depending on EVALHOOK,
    
+  since it has no semantics, so there can't be a compatibility issue.
    
+  If we agree that something is a bad idea, I would rather remove it
    
+  entirely unless there is a compelling compatibility reason to only
    
+  deprecate it.  In fact even if some programs used EVALHOOK, I would
    
+  still want to remove it, as I long ago ceased to believe in any
    
+  fantasy of seamless compatibility between CLtL and ANSI CL.  But
    
+  others might not agree with me there.
    
+
    
+  Plus if we remove them, Symbolics doesn't have to fix the bug that
    
+  EVALHOOK and APPLYHOOK accidentally got declared SPECIAL.  I mention
    
+  this only as an example of the costs of deprecating things instead
    
+  of removing them.  They have to be maintained.  Not only do they have
    
+  to be documented, but in addition to documenting them we have to tell
    
+  people not to use them.
    
+
    
+Loosemore says:
    
+  I'd rather get rid of these things entirely too, but I have previously
    
+  noted some resistance to the idea from others.  Maybe they've changed
    
+  their minds by now.  Anyway, if we can't agree to delete them now, 
    
+  deprecation is better than the current situation.
    
+-------
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss150.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss150.htm new file mode 100644 index 00000000..4ef13484 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss150.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue EVALHOOK-STEP-CONFUSION:X3J13-NOV-89 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EVALHOOK-STEP-CONFUSION:X3J13-NOV-89 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue EVALHOOK-STEP-CONFUSION:X3J13-NOV-89:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151.htm new file mode 100644 index 00000000..3e640bdb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151_w.htm new file mode 100644 index 00000000..abf02918 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss151_w.htm @@ -0,0 +1,138 @@ + + + +CLHS: Issue EXIT-EXTENT-AND-CONDITION-SYSTEM Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EXIT-EXTENT-AND-CONDITION-SYSTEM Writeup

    + +
    Issue:              EXIT-EXTENT-AND-CONDITION-SYSTEM
    
+References:         CATCH, THROW, UNWIND-PROTECT,
    
+                    HANDLER-BIND, RESTART-BIND
    
+Related issues:     EXIT-EXTENT
    
+Category:           CLARIFICATION
    
+Edit history:       v1, 22 Feb 1991, Sandra Loosemore
    
+                    v2, 11 Mar 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The EXIT-EXTENT issue doesn't specify how exit points interact with
    
+  the dynamic bindings of condition handlers and restarts.  At what
    
+  point in the execution of non-local transfers of control do the
    
+  extents of handlers and restarts established by HANDLER-BIND and
    
+  RESTART-BIND end?
    
+
    
+Proposal (EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS):
    
+
    
+  Clarify that undoing of handler and restart bindings during an exit
    
+  happens in parallel with the undoing of the bindings of special variables
    
+  and CATCH tags, in the reverse order in which they were established.
    
+  The effect of this is that the cleanup clauses of an UNWIND-PROTECT
    
+  will see the same handler and restart bindings, as well as dynamic bindings
    
+  and CATCH tags, as were visible with the UNWIND-PROTECT was entered.
    
+
    
+Examples:
    
+
    
+  ???
    
+
    
+Rationale:
    
+
    
+  Presumably many implementations use dynamic bindings and CATCH to 
    
+  implement handler and restart bindings.
    
+
    
+Current Practice:
    
+
    
+  The sample condition system implementation uses dynamic bindings and
    
+  CATCH to implement handler and restart bindings.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably none.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.
    
+
    
+Cost of non-adoption:
    
+
    
+  Continuing vagueness in the language specification.
    
+
    
+Performance impact:
    
+
    
+  Probably none.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Being consistent with issue EXIT-EXTENT is a good thing.  Whether
    
+  issue EXIT-EXTENT was resolved in an esthetic manner is another 
    
+  question.
    
+
    
+Discussion:
    
+
    
+  This issue was raised by Barry Margolin on the X3J13 mailing list.
    
+
    
+  Kim Barrett notes:
    
+
    
+    A consequence of this proposal is that
    
+    
    
+      (catch 'foo
    
+        (handler-case
    
+            (unwind-protect
    
+                (throw 'foo nil)
    
+              (error "foo"))
    
+          (error () (print 'foo))))
    
+    
    
+    has undefined consequences.  This is why I voted against EXIT-EXTENT.  Of
    
+    course, few people listened then so why should they listen now.
    
+
    
+  Moon replies:
    
+
    
+    ....[this] is a consequence of EXIT-EXTENT and has
    
+    nothing to do with EXIT-EXTENT-AND-CONDITION-SYSTEM, which speaks
    
+    only of when bindings are disestablished, not when using those
    
+    bindings becomes undefined, which is the subject of EXIT-EXTENT.
    
+
    
+    EXIT-EXTENT-AND-CONDITION-SYSTEM tells us that the handler binding
    
+    extablished by the HANDLER-CASE becomes disestablished when control
    
+    passes outside the HANDLER-CASE and not before.  In particular this
    
+    binding is still established while the UNWIND-PROTECT cleanup form
    
+    is executing.  It is difficult to imagine what other semantics
    
+    for this part could be defensible.
    
+
    
+    EXIT-EXTENT tells us that the exit point used by the handler established
    
+    by the HANDLER-CASE cannot be used after the THROW commences.  Note that
    
+    this is not the same binding as the one discussed by 
    
+    EXIT-EXTENT-AND-CONDITION-SYSTEM.  It is certainly possible to imagine
    
+    other defensible semantics for this part, we spent years discussing it.
    
+
    
+  JonL says:
    
+
    
+    I can think of few things more horrible than re-opening the issue
    
+    of EXIT-EXTENT.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152.htm new file mode 100644 index 00000000..4913c7be --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue EXIT-EXTENT:MINIMAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EXIT-EXTENT:MINIMAL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue EXIT-EXTENT:MINIMAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152_w.htm new file mode 100644 index 00000000..6f81aedd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss152_w.htm @@ -0,0 +1,391 @@ + + + +CLHS: Issue EXIT-EXTENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EXIT-EXTENT Writeup

    + +
    Status: proposal MINIMAL, as amended, passed Mar 89 X3J13 by vote of 11-5.
    
+Issue:         EXIT-EXTENT
    
+References:    CATCH, THROW (p 142),
    
+               BLOCK, RETURN, RETURN-FROM,
    
+               TAGBODY, GO, UNWIND-PROTECT,
    
+               Dynamic extent (CLtL p.37),
    
+               Nested dynamic extents (CLtL p.38),
    
+               Blocks can only be exited once (CLtL p.120),
    
+               Catch is disestablished just before the values 
    
+               are returned (CLtL p.139).
    
+Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
    
+                by this one.
    
+Category:      CLARIFICATION
    
+Edit history:  ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
    
+               Version 1, 5-Sep-88, by Moon, for discussion
    
+               Version 2, 1-Oct-88, by Masinter, minor edits
    
+               Version 3, 7-Oct-88, by Moon, wording improvements
    
+               Version 4,  7-Dec-88, by Masinter, add MEDIUM from
    
+                                   UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
    
+               Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
    
+               Version 6,  8-Jan-89, Masinter, fix some bugs
    
+               Version 7,  4-Apr-89, Moon, amend per X3J13 Mar-89, and make
    
+                                rationale and examples consistent with that
    
+
    
+Problem description:
    
+
    
+CLtL does not specify precisely when the dynamic extent (lifetime)
    
+of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends. 
    
+For example, at what point is it no longer possible to RETURN-FROM
    
+a particular BLOCK?
    
+
    
+An "exit" refers to a point from which control can be transferred.
    
+For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
    
+or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
    
+which was being executed at the time the GO is performed.
    
+
    
+The extent of an exit is dynamic; it is not indefinite. The extent
    
+of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
    
+clause) is entered.  When the extent of an exit has ended, it is no
    
+longer legal to return from it.
    
+
    
+The extent of an exit is not the same thing as the scope of the
    
+designator by which the exit is identified. For example, a BLOCK
    
+name has lexical scope but the extent of its exit is dynamic; the
    
+scope of a CATCH tag could differ from the extent of the CATCH's
    
+return point. (That's part of what is at issue here.)
    
+
    
+The ambiguity at issue arises for the case where there are transfers
    
+of control from the cleanup clauses of an UNWIND-PROTECT.
    
+
    
+When a transfer of control is initiated by GO, RETURN-FROM or THROW,
    
+a variety of events occur before the transfer of control is complete.
    
+In particular, 
    
+
    
+(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
    
+    are evaluated,
    
+
    
+(b) intervening dynamic bindings of special variables and catch tags
    
+    are undone,
    
+
    
+(c) intervening exits are "abandoned", i.e., their extent ends and it
    
+    is no longer legal to attempt to transfer control through them,
    
+
    
+(d) the extent of the exit being invoked ends,
    
+
    
+(e) control is finally passed to the target.
    
+
    
+The order of these events is not explicit in CLtL, however. The 
    
+implementation note on p.142 gives a clue about the interweaving
    
+of (a) and (b), but there are differing opinions about the times
    
+at which (c) and (d) may occur. In particular,
    
+
    
+Is it legal for an implementation to end the extent of all 
    
+intervening exits before processing the cleanup clauses of intervening 
    
+UNWIND-PROTECTs?
    
+
    
+What is the dynamic context at the time UNWIND-PROTECT clauses are 
    
+evaluated: how is the unwinding of dynamic bindings intertwined with 
    
+evaluation of UNWIND-PROTECT cleanup clauses? 
    
+
    
+Proposal (EXIT-EXTENT:MINIMAL):
    
+
    
+The extent of an exit being "abandoned" because it is being passed over
    
+ends as soon as the transfer of control is initiated. That is, the
    
+event (c) occurs at the beginning of the initiation of the transfer of
    
+control. In the language of the implementation note on p.142, the
    
+extent ends at the beginning of the second pass.  It is an error to
    
+attempt a transfer of control to an exit whose dynamic extent has
    
+ended.
    
+
    
+The event (d) occurs at the end of the transfer of control.
    
+
    
+Otherwise, events (a) and (b)--the undoing of dynamic binding of special
    
+variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
    
+clauses--are performed in the order corresponding to the reverse order
    
+in which they were established, as implied by the implementation note
    
+on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
    
+will see the same dynamic bindings of variables and CATCH tags as were
    
+visible when the UNWIND-PROTECT was entered.
    
+
    
+This proposal is called "minimal" because it gives exits the smallest
    
+extent consistent with CLtL, except that event (d) occurs later than
    
+CLtL requires.  A program that presumed a longer extent would be in
    
+error. Implementations may support longer extents for exits than is
    
+required by this proposal; in particular, an implementation which
    
+allowed the larger extent of the MEDIUM proposal below would still
    
+conform.
    
+
    
+Proposal (EXIT-EXTENT:MEDIUM):
    
+
    
+The events of (a), (b), (c) and (d) are interwoven in the reverse 
    
+order in which they were established. In particular, the extent of 
    
+a passed-over exit ends when control reaches a frame that was 
    
+established before the exit was established.  
    
+
    
+In particular, it is legal, during the evaluation of an UNWIND-PROTECT 
    
+cleanup form executed because of a non-local transfer of control, to
    
+initiate a new transfer of control to an exit intervening between the 
    
+UNWIND-PROTECT and the original target; the original processing of 
    
+transfer of control is abandoned.  
    
+
    
+Examples:
    
+
    
+;; Error under either proposal: BLOCK exits normally before RETURN
    
+(funcall (block nil #'(lambda () (return))))
    
+
    
+;; Error under either proposal: normal exit before GO
    
+(let ((a nil)) 
    
+  (tagbody t (setq a #'(lambda () (go t))))
    
+  (funcall a))
    
+
    
+;; Error under either proposal: TAGBODY is passed over, before GO
    
+(funcall (block nil
    
+           (tagbody a (return #'(lambda () (go a))))))
    
+
    
+
    
+;;returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
    
+(block nil   
    
+  (unwind-protect (return 1)
    
+    (return 2)))
    
+
    
+;;returns 2 under MEDIUM, is error under MINIMAL
    
+(block a    
    
+  (block b
    
+    (unwind-protect (return-from a 1)
    
+      (return-from b 2))))
    
+
    
+;; returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
    
+(catch nil 
    
+  (unwind-protect (throw nil 1)
    
+    (throw nil 2)))
    
+
    
+;; returns 2 under MEDIUM, is error under MINIMAL
    
+;; because the catch of B is passed over by
    
+;; the first THROW, hence portable programs must assume its dynamic extent
    
+;; is terminated.  The binding of the catch tag is not yet disestablished
    
+;; and therefore it is the target of the second throw.
    
+(catch 'a
    
+  (catch 'b
    
+    (unwind-protect (throw 'a 1)
    
+      (throw 'b 2))))
    
+
    
+
    
+;; the following was an error under MINIMAL version 6; the extent of
    
+;; the inner catch terminates as soon as the THROW commences, even
    
+;; though it remains in scope. Thus, the THROW of :SECOND-THROW
    
+;; sees the inner CATCH, but its extent has ended.
    
+;; under MEDIUM and MINIMAL version 7,
    
+;; it prints "The inner catch returns :SECOND-THROW"
    
+;; and then returns :OUTER-CATCH.
    
+(catch 'foo
    
+        (format t "The inner catch returns ~s.~%"
    
+                (catch 'foo
    
+                    (unwind-protect (throw 'foo :first-throw)
    
+                        (throw 'foo :second-throw))))
    
+        :outer-catch))
    
+
    
+
    
+;; Following returns 10 under either proposal.  The inner
    
+;; CATCH of A is passed over, but because that CATCH
    
+;; is disestablished before the THROW to A is executed,
    
+;; it isn't seen.
    
+(catch 'a
    
+  (catch 'b
    
+    (unwind-protect (1+ (catch 'a (throw 'b 1)))
    
+      (throw 'a 10))))
    
+
    
+
    
+;; Following is an error under MINIMAL because the extent of
    
+;; the (CATCH 'BAR ...) exit ends when the (THROW 'FOO ...)
    
+;; commences.
    
+;; Under MEDIUM, the pending exit to tag FOO is discarded by the
    
+;; second THROW to BAR and the value 4 is transferred to
    
+;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
    
+;; then returns the 4 because its first argument has returned
    
+;; normally.  XXX is not printed.
    
+
    
+    (CATCH 'FOO
    
+      (CATCH 'BAR
    
+          (UNWIND-PROTECT (THROW 'FOO 3)
    
+            (THROW 'BAR 4)
    
+            (PRINT 'XXX))))
    
+
    
+ 
    
+;; Following returns 4 under either proposal; XXX is not printed.
    
+;; The (THROW 'FOO ...) has no effect on the scope of the BAR
    
+;; catch tag or the extent of the (CATCH 'BAR ...) exit.
    
+(CATCH 'BAR
    
+    (CATCH 'FOO
    
+        (UNWIND-PROTECT (THROW 'FOO 3)
    
+          (THROW 'BAR 4)
    
+          (PRINT 'XXX))))
    
+
    
+
    
+;;The following are legal and print 5 under either proposal:
    
+    (block nil
    
+      (let ((x 5))
    
+        (declare (special x))
    
+        (unwind-protect (return)
    
+          (print x))))          
    
+
    
+    (block nil
    
+      (let ((x 5))
    
+        (declare (special x))
    
+        (unwind-protect
    
+            (if (test) (return))
    
+          (print x))))  
    
+
    
+
    
+Rationale:
    
+
    
+For MINIMAL: Giving exits the smallest extent consistent with CLtL
    
+maximizes freedom for implementations; there are few applications,
    
+if any, that require a longer extent.  Delaying event (d) until
    
+the transfer of control is completed allows multiple attempts to
    
+exit from a single exit, if the first attempt is interrupted,
    
+possibly by an error.
    
+
    
+For MEDIUM: Giving exits a longer extent has cleaner semantics.
    
+
    
+Current practice:
    
+
    
+Both implementations of Symbolics Genera (3600 and Ivory) end the extent
    
+of a target BLOCK or CATCH at the moment the values are returned, and
    
+end the extent of a passed-over exit at the moment the THROW, RETURN, or
    
+GO commences.  This choice of extent maximizes efficiency within the
    
+particular stack structure used by these implementations, by avoiding
    
+the need to retain the control information needed to use a passed over
    
+exit through the transfer of control.  Genera signals an error if an
    
+attempt is made to use an exit that has been passed over.
    
+
    
+In some implementations, it is possible for a throw or non-local exit
    
+to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
    
+performs a non-local transfer of control to a passed-over exit.
    
+
    
+Some implementations crash or otherwise generate garbage code for
    
+non-local exits from cleanup clauses of UNWIND-PROTECT.
    
+
    
+Cost to Implementors:
    
+
    
+No currently valid implementation will be made invalid by the MINIMAL
    
+proposal. Some implementors may wish to add error checks if they
    
+do not already have them.
    
+
    
+MEDIUM would have a high cost for those implementations that currently
    
+have shorter extent.
    
+
    
+Cost to Users:
    
+
    
+Most user programs don't do this, so there is likely little cost
    
+of converting existing code in any case. In any case, current implementations
    
+differ enough that this issue ostensibly does not
    
+affect current portable programs. Some users might have code that
    
+relies on the "unstoppable loops" that can be created with the MEDIUM
    
+proposal.
    
+
    
+Benefits:
    
+
    
+Either proposal would make Common Lisp more precisely defined.
    
+
    
+Cost of non-adoption :
    
+
    
+The semantics of exits will remain ambiguous.
    
+
    
+Esthetics:
    
+
    
+Precisely specifying the meaning of dynamic extent improves the language.
    
+Leaving implementations free to implement a longer extent if they choose
    
+can be regarded as unesthetic, but consistent with Common Lisp philosophy.
    
+Having a CATCH that is in scope even though its extent has ended may
    
+seem unesthetic, but it is consistent with how BLOCK behaves.
    
+
    
+Discussion:
    
+
    
+This issue is controversial. It was first discussed under the issue 
    
+named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
    
+the more global one of "extent of exits" rather than the specific 
    
+one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
    
+local exit", but the problem cases for both topics are the same.
    
+
    
+The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
    
+minimizing changes to the current situation. The MEDIUM proposal
    
+defines the extent of an exit to end at the last moment possible
    
+within some particular reference implementation.  It has
    
+a cost to implementors whose implementation is not identical to the
    
+reference implementation.  Another alternative proposal, not considered
    
+here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
    
+cleanup forms. That alternative would have a substantial cost to some users.
    
+
    
+Scheme is cleaner: it avoids this issue by specifying that the extent
    
+of an exit never ends.
    
+
    
+An argument for the MEDIUM proposal was made based on the example:
    
+
    
+  (block foo
    
+    (block bar
    
+      (unwind-protect
    
+          (return-from foo 'foo)
    
+        (return-from bar 'bar))))
    
+
    
+Since there is no reason for FOO and BAR not to be treated interchangeably,
    
+calling this an error would be inappropriate. 
    
+
    
+It was argued that the MINIMAL proposal is equivalent to practically
    
+outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
    
+there is no general way to determine the target of the non-local exit
    
+that caused the cleanup clause to be invoked. 
    
+
    
+The following example was offered as an argument against MINIMAL. Given:
    
+
    
+    (block nil
    
+      (handler-case
    
+          (unwind-protect (return)
    
+            (error "foo"))             ;probably an error, under the proposal
    
+        (error ()
    
+          (print "foo"))))
    
+
    
+If the ERROR handler has the same scope and extent a CATCH in the same place
    
+would have (and that seems reasonable, though I'm not certain that the
    
+condition system specifically requires that interpretation), then the handler
    
+will be apparent to the call to ERROR, but will no longer be a valid target
    
+(its extent was exited by the RETURN in the UNWIND-PROTECT body).
    
+
    
+The extent of an object with dynamic extent is the extent of the form 
    
+which created it.  Code which is executed "within" that form is within
    
+the extent of the object(s).  This applies to all dynamic objects, such
    
+as special variable bindings, not just exits.  Actually, I think the intent
    
+of the implementation note on p.142 is fairly clear and supports this
    
+interpretation.  The supposedly ambiguous use of "frame" should be read
    
+as something like "form which establishes a dynamic extent".  It might be
    
+clearer if the last sentence were changed to read something like:
    
+
    
+"On the second pass the stack is actually unwound.  Each form which establishes
    
+a dynamic extent is undone in reverse order of creation until the matching
    
+CATCH is reached.  The meaning of undoing a form depends on the type of form.
    
+For UNWIND-PROTECT, it means executing the cleanup forms.  For CATCH it means
    
+removing the CATCH tag.  For dynamic bindings it means undoing the binding,
    
+restoring the previous saved value. {This is not an exhaustive listing of the
    
+possibilities.}"
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153.htm new file mode 100644 index 00000000..d8af92e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EXPT-RATIO:P.211 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EXPT-RATIO:P.211 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EXPT-RATIO:P.211:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153_w.htm new file mode 100644 index 00000000..b9363795 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss153_w.htm @@ -0,0 +1,118 @@ + + + +CLHS: Issue EXPT-RATIO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EXPT-RATIO Writeup

    + +
    Forum:         Cleanup
    
+Issue:         EXPT-RATIO
    
+
    
+References:    CLtL pages 204 and 211
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  Version 1, 4-Oct-88, by Aspinall and Moon
    
+               Version 2,  6-Oct-88, Masinter (very minor discussion)
    
+               Version 3, 31-Oct-88, Masinter (fix typo)
    
+
    
+Problem description:
    
+
    
+  The comment (page 204, 2nd para) that "... an implementation [of expt]
    
+  might choose to compute (expt x 3/2) as if it had been written
    
+  (sqrt (expt x 3))" disagrees with the principal value definition on
    
+  page 211.  See the example below for a case where the two disagree.  We
    
+  believe the principal value definitions are consistent and reasonable,
    
+  therefore the implementation comment is wrong.
    
+
    
+Proposal (EXPT-RATIO:P.211):
    
+
    
+  Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
    
+  and that page 211 rules.
    
+
    
+Examples:
    
+
    
+  (defvar x (exp (/ (* 2 pi #c(0 1)) 3)))         ;exp(2.pi.i/3)
    
+  (expt x 3) => 1 (except for round-off error)
    
+  (sqrt (expt x 3)) => 1 (except for round-off error)
    
+  (expt x 3/2) => -1 (except for round-off error)
    
+  
    
+  There can be no question that 
    
+          (expt x 3) ==> 1
    
+  because expt is single-valued with an integer second argument, and
    
+          (sqrt 1) ==> 1
    
+  definitely follows the principal branch of the square root function.
    
+  
    
+  But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
    
+          (log x) ==> 2.pi.i/3
    
+  according to the definition of the logarithm's branch cuts on page 211
    
+  (which really comes down to the branch cuts of phase - page 210), so
    
+          (* (log x) 3/2) ==> pi.i
    
+  and
    
+          exp(pi.i) is -1.
    
+
    
+Rationale:
    
+
    
+  We believe the principal value definitions are consistent and
    
+  reasonable, therefore the implementation comment is wrong.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 7.3 currently returns the wrong answer, following page
    
+  204 rather than page 211.  Lucid Common Lisp, and 
    
+  Envos Medley implement the proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  The obvious code changes in complex expt.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Self-contradictory language specification.
    
+
    
+Benefits:
    
+
    
+  Users can better predict the branch cuts in expt.
    
+
    
+Discussion:
    
+
    
+  Mathematical Explanation:  When the expt function returns a complex result
    
+  in CL (Cartesian) form, the phase of the complex number is effectively
    
+  canonicalized.  Information is lost, and that information is necessary to
    
+  specify upon which branch of the sqrt function the final result should lie.
    
+  
    
+  Another way to put it would be that although
    
+          sqrt(expt(x,3)) = expt(x,3/2)
    
+  where expt and sqrt are the mathematical multi-valued functions, it is not
    
+  true that:
    
+          pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
    
+  where pvexpt and pvsqrt denote the principal value versions of those functions.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154.htm new file mode 100644 index 00000000..2b788ed8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EXTENSIONS-POSITION:DOCUMENTATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EXTENSIONS-POSITION:DOCUMENTATION Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EXTENSIONS-POSITION:DOCUMENTATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154_w.htm new file mode 100644 index 00000000..023e7123 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss154_w.htm @@ -0,0 +1,144 @@ + + + +CLHS: Issue EXTENSIONS-POSITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EXTENSIONS-POSITION Writeup

    + +
    Issue:        EXTENSIONS-POSITION
    
+References:   Chapter 1, Working draft of standard
    
+Category:     Clarification
    
+Related Issues: CONFORMANCE-POSITION, IF-BODY, ERROR-TERMINOLOGY, EXTRA-SYNTAX,
    
+		EXTRA-OPTIONAL-KEYWORD-ARGUMENTS, UNSPECIFIED-DATATYPES,
    
+		MACRO-AS-FUNCTION, UNSOLCITED-MESSAGES, EXTRA-RETURN-VALUES
    
+Edit history: 12-DEC-88, Version 1 by Chapman
    
+              20-DEC-88, Version 2 by Chapman
    
+              9-JAN-89, Version 3 by Chapman
    
+              10-JAN-89, Version 4 by Chapman
    
+              2-FEB-89, Version 5 by Chapman
    
+              24-FEB-89, Version 6 by Chapman (added RPG's comment)
    
+              10-MAR-89, Version 7 by Chapman (added discussion)
    
+ 
    
+Problem Description:
    
+ 
    
+What is the definition of a language extension?
    
+What effect does a language extension have on a conforming program? 
    
+What obligation does an implementation have to warn the user that an 
    
+extension is being used?
    
+
    
+Presumably the only thing that defining it as an extension can mean from
    
+CL's point of view is `initially defining' it as an extension. Whether
    
+an implementation permits redefinition of an extension is between that
    
+implementation and its users and beyond the scope of Common Lisp. For
    
+example, it is common practice to redefine some kinds of system functions
    
+in Genera -- to extend the system in interesting ways, to fix bugs, etc.
    
+ 
    
+ 
    
+Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
    
+ 
    
+The standard document should define a language extension to be
    
+any implementation-supplied tool that isn't explicitly defined
    
+in the standard. This includes facilities added to tools defined
    
+in the standard.
    
+The standard document should levy the following requirement on a 
    
+conforming implementation's documentation:
    
+The documentation that accompanies a conforming implementation should clearly
    
+state which parts of the implementation are extensions.  
    
+
    
+
    
+If the standard says that "the results are unspecified", and an
    
+implementation specifies the results, this an extension in the
    
+sense that if the correct behavior of a program depends on the results,
    
+only implementations with the same extension will execute the program
    
+correctly.
    
+
    
+In places where the standard says that "an implementation may be extended",
    
+this implies that a conforming, but probably non-portable, program can
    
+be written using the implementation's extension.
    
+
    
+Proposal (EXTENSIONS-POSITION:DISABLE)
    
+
    
+Same as EXTENSIONS-POSITION:DOCUMENTATION except that
    
+an implementation is required to have a way to disable its extensions, so
    
+that a programmer can be told when he is using a feature that might
    
+affect his program's portability. 
    
+
    
+
    
+Rationale:
    
+ 
    
+The standard should contain information about language extensions
    
+since most implementations have extended the language.
    
+ 
    
+Current Practice:
    
+
    
+CLtL allows any extension, provided that it doesn't alter the behavior
    
+of a program that only uses what is specified in CLtL.  In particular,
    
+any situation that "is an error" (either explicitly or implicitly) is a
    
+potential area for extension.
    
+ 
    
+ 
    
+Adoption Cost:
    
+ 
    
+Vendors will have to improve their documentation
    
+to list all their extensions.  Vendors will have to go through their
    
+implementation and determine what is or isn't an extension.
    
+ 
    
+ 
    
+Benefits:
    
+ 
    
+This definition will provide a basis for proper understanding of 
    
+the error terminology used in the standard. The implementation
    
+documentation requirement will aid the user in producing portable code.
    
+ 
    
+Conversion Cost:
    
+ 
    
+None.
    
+ 
    
+Aesthetics:
    
+ 
    
+None.
    
+ 
    
+Discussion:
    
+Masinter says:
    
+It seems to be a constraint on "documentation" rather than "implementation"
    
+if you turn the accidental behavior of (CAR T) into a "feature" of your
    
+implementation. We might want to disallow such an extension as "conforming
    
+to the standard". An implementation which had such an extension might
    
+conform, even if the extension did not conform.
    
+
    
+RPG says:
    
+I favor remaining mute on this topic in the standard.
    
+
    
+Moon says:
    
+"I favor EXTENSIONS-POSITION:DOCUMENTATION.
    
+ 
    
+I oppose EXTENSIONS-POSITION:DISABLE because it mandates a
    
+particular development environment feature, but Common Lisp
    
+has avoided saying anything about development environments
    
+since that is an area of extreme controversy.
    
+ 
    
+Gabriel's position of standing mute would be okay with me."
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155.htm new file mode 100644 index 00000000..5cf5687c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155_w.htm new file mode 100644 index 00000000..8c89dd90 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss155_w.htm @@ -0,0 +1,201 @@ + + + +CLHS: Issue EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION Writeup

    + +
    Status:       MINUMUM proposal accepted 4/1/92
    
+Issue:        EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION
    
+Forum:        Cleanup
    
+References:   OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, STREAM-EXTERNAL-FORMAT
    
+Category:     EXTEND
    
+Edit history: 10-Jan-92, Version 1 by Masa Ida
    
+              14-Jan-92, Version 2 ibid. 
    
+                (correct a typo. add Editorial Impact field. Add Discussion.)
    
+              1-Apr-92, Version 3 by Barrett
    
+                (compile-file-pathname, similarity of constants constraint)
    
+              2-Apr-92, Version 4 by Barrett (amendments from meeting)
    
+
    
+Problem Description:
    
+
    
+        OPEN and WITH-OPEN-FILE have :EXTERNAL-FORMAT keyword
    
+        to specify the external format of files, but other file
    
+        connecting interfaces like LOAD have no such keyword.
    
+        As a result uniform handling of external formats are
    
+        impossible with the current draft.
    
+
    
+Proposal (EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM);
    
+
    
+        Add the :EXTERNAL-FORMAT keyword to LOAD and COMPILE-FILE.
    
+        The default value is :DEFAULT as in OPEN.  This argument specifies the
    
+        character representation scheme to be used by LOAD and COMPILE-FILE
    
+        when reading a source file, in the same manner as for OPEN.
    
+
    
+        This changes the syntax descriptions to
    
+                Compile-file input-pathname &key :output-file :verbose
    
+                        :print :external-format
    
+                Load filename &key :verbose :print :if-does-not-exist
    
+                        :external-format
    
+
    
+        Add to the descriptions of COMPILE-FILE and LOAD a cross reference to
    
+        (or copy of) the description of the :EXTERNAL-FORMAT argument for OPEN.
    
+
    
+        The :EXTERNAL-FORMAT argument is ignored by LOAD when opening a
    
+        compiled file.  Instead, COMPILE-FILE and LOAD must cooperate (using
    
+        some implementation-dependent mechanism) in such a way that similarity
    
+        of constants is maintained across the interface between these two
    
+        functions.
    
+
    
+Editorial Impact:
    
+        Trivial. If STREAM-EXTERNAL-FORMAT description will refer
    
+        the usage of :EXTERNAL-FORMAT in the future, editorial consideration
    
+        will be needed.
    
+
    
+Test Case:
    
+
    
+        (LOAD "MY-PROG.LISP" :EXTERNAL-FORMAT :NIHONGO-EUC)
    
+        will load the file MY-PROG.LISP which contains nihongo-euc
    
+        coded characters defined by UI-OSF joint japanization definition.
    
+
    
+        (COMPILE-FILE "YY.CL")
    
+        will compile the file YY.CL with the default understanding.
    
+
    
+Rationale:
    
+        Uniform handling of external formats are enabled by
    
+        adopting this proposal.
    
+
    
+Current Practice:
    
+        There is no way to specify the coding scheme for
    
+        loading/compiling files.
    
+        Several Japanese commercial CL implementations use
    
+        this scheme.
    
+
    
+Cost to Implementors:
    
+        If implementation supports :default only, the cost is negligible.
    
+
    
+Cost to Users:
    
+        The existing japanized software with their own tricks for
    
+        converting the codes must rewrite the interface to the
    
+        system supplied one to have a portability.
    
+
    
+Cost of Non-Adoption:
    
+        Incompatibility with the Jeida Guideline draft.
    
+
    
+Benefits:
    
+        Performance up.
    
+        Compatible definition.
    
+
    
+Aesthetics:
    
+        unified syntax.
    
+
    
+
    
+Proposal (EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:JEIDA-GUIDELINE);
    
+
    
+        Only :DEFAULT is defined for the value of :EXTERNAL-FORMAT now.
    
+        Other possible selections are not defined.
    
+        Add the following selections for :external-format value.
    
+                :nihongo-jis  file contains JIS X0202 encoding JIS characters.
    
+                :nihongo-euc  file contains nihongo-euc defined by
    
+                              the joint convention defined by UI-OSF.
    
+                :nihongo-ms   file contains Microsoft Kanji Code.
    
+
    
+Editorial Impact:
    
+        Trivial. If STREAM-EXTERNAL-FORMAT description will refer
    
+        the usage of :EXTERNAL-FORMAT in the future, editorial consideration
    
+        will be needed.
    
+
    
+Test Case:
    
+        See the Test Case for MINIMUM
    
+
    
+Rationale:
    
+        Every practical conversion scheme is provided with this definition.
    
+
    
+Current Practice:
    
+        Users write their own codes for conversion. Or
    
+        Several CL cannot handle japanese characters.
    
+
    
+Cost to Implementors:
    
+        Requiers the supporting mechanisms/libraries for japanese
    
+        character handling.
    
+
    
+Cost to Users:
    
+
    
+Cost of Non-Adoption:
    
+        Incompatibility with the Jeida Guideline draft.
    
+
    
+Benefits:
    
+        By adopting this proposal, implementations can have a portable
    
+        way for japanization.
    
+
    
+Aesthetics:
    
+        If there is consideration for other nations,
    
+        say, we can add :arabic-XXX, :chinese-XXX, ...
    
+
    
+Discussion:
    
+        Masa Ida recomended to have the MINIMUM proposal.
    
+        The proposal JEIDA-GUIDELINE seems to be too sudden for X3J13
    
+        and may require more detailed definition.
    
+        The proposal JEIDA-GUIDELINE seems to be not needed for USA domestic
    
+        Applications.
    
+
    
+        Date: Mon, 13 Jan 92 11:16:40 EST
    
+        From: kab@cambridge.apple.com (Kim Barrett)
    
+        I don't yet have an informed opinion on the proposal (after the above
    
+        bug is fixed), but my initial reaction is that this certainly seems
    
+        plausible.  I couldn't think of any operators besides the two mentioned
    
+        that implicitly call OPEN.
    
+
    
+        Date: Mon, 13 Jan 1992 16:37-0500
    
+        From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    
+        I do believe this is an important issue.  I think it's nice for us to
    
+        try to cater to the legitimate technical needs of the international
    
+        community in order to better position CL for acceptance in the
    
+        international arena, both in the standards arena and in the commercial
    
+        arena.  I hope that at the appropriate time we will give it due
    
+        consideration.
    
+        My personal opinion is that the proposal looks solid (modulo the
    
+        obvious typo--missing "not"--mentioned by Kim Barrett) and worth doing,
    
+        both for general consistency and because I can easily see where the
    
+        absence of this feature would lead to some serious problems.
    
+
    
+        From: Larry Masinter <masinter@parc.xerox.com>
    
+        Date:    Mon, 13 Jan 1992 15:49:14 PST
    
+        I like the :MINIMUM proposal, but I would be wary of including the
    
+        JEIDA guideline without also including other values for
    
+        :EXTERNAL-FORMAT.
    
+        There is apprently good progress in the ISO 10646 standard. (The DIS-2
    
+        ISO 10646 was supposed to be issued January 1992 for a 4-month
    
+        vote...)
    
+        Even if we listed interpretations for :external-format that included
    
+        JIS, EUC and Microsoft Kanji codes, it would seem to be important to
    
+        include a better reference for those coding schemes, since they tend
    
+        to get revised from time to time. 
    
+        It might be that the standard should not include these keywords any
    
+        more than a listing of features, but that some other informal or
    
+        formal consortium of implementors could keep a registry of keyword
    
+        assignments.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156.htm new file mode 100644 index 00000000..472175a3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue EXTRA-RETURN-VALUES:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue EXTRA-RETURN-VALUES:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue EXTRA-RETURN-VALUES:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156_w.htm new file mode 100644 index 00000000..50c5184c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss156_w.htm @@ -0,0 +1,128 @@ + + + +CLHS: Issue EXTRA-RETURN-VALUES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue EXTRA-RETURN-VALUES Writeup

    + +
    Version 6 (not shown here) is what passed.
    
+It was modified by amendment to strike everything in the 
    
+proposal section except for the first paragraph. 
    
+v6 is the one that passed.
    
+ -kmp (Aug 89)
    
+
    
+-----
    
+Issue:        EXTRA-RETURN-VALUES
    
+References:   Chapter 1, Section 1.5, Working draft of standard
    
+Category:     Clarification
    
+Edit history: 8-JAN-89, Version 1 by Masinter
    
+	      3-FEB-89, Version 2 by Chapman
    
+	      10-MAR-89, Version 3 by Chapman
    
+              30-MAY-89, Version 4 by Pierson
    
+              20-JUN-89, Version 5 by Chapman
    
+ 
    
+ 
    
+Problem: Is it OK to return extra values from Common Lisp functions?
    
+ 
    
+Proposal: EXTRA-RETURN-VALUES:NO
    
+ 
    
+A function that is specified by the standard must return EXACTLY the number 
    
+of return values specified by the standard.  
    
+ 
    
+The following functions are explicited permitted to have additional
    
+return values: 
    
+ 
    
+  gethash
    
+  remhash
    
+  get-macro-character  
    
+  get-dispatch-macro-character
    
+  read
    
+  read-preserving-whitespace
    
+  read-delimited-list
    
+  read-line
    
+  read-char
    
+  unread-char
    
+  peek-char
    
+  listen
    
+  read-char-no-hang
    
+  read-from-string
    
+  parse-integer
    
+  read-byte
    
+  write-to-string
    
+  prin1-to-string
    
+  princ-to-string
    
+  write-string
    
+  format
    
+  y-or-n-p
    
+  yes-or-no-p
    
+  open
    
+  rename-file
    
+  probe-file
    
+  directory
    
+  trace
    
+  untrace
    
+  apropos-list
    
+  describe 
    
+
    
+ 
    
+ 
    
+Rationale:
    
+ 
    
+The reason is that additional arguments are visible to otherwise
    
+portable programs. For instance, (multiple-value-call #'cons (floor x
    
+y)) looks portable, but it will try to pass the wrong number of
    
+arguments to CONS if FLOOR returns an extra value.
    
+
    
+The order of the above list is by page number in CLtL.
    
+ 
    
+Current Practice:
    
+ 
    
+At least one implementation returns extra values for certain functions
    
+not currently specified to return those values.
    
+ 
    
+Adoption Cost:
    
+ 
    
+Implementations and their associated documentation that now contain 
    
+functions that return extra values will have to change.
    
+ 
    
+Benefits:
    
+ 
    
+Programs will potentially become more portable.
    
+ 
    
+Conversion Cost:
    
+ 
    
+See Adoption Cost.
    
+ 
    
+Aesthetics:
    
+ 
    
+None.
    
+ 
    
+Discussion:
    
+Pierson created the original list, Moon revised the list.
    
+ 
    
+Moon says:
    
+"The ones that I care the most about are gethash and read-line."
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157.htm new file mode 100644 index 00000000..c5473bab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157.htm @@ -0,0 +1,63 @@ + + + +CLHS: Issue FILE-OPEN-ERROR:SIGNAL-FILE-ERROR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FILE-OPEN-ERROR:SIGNAL-FILE-ERROR Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FILE-OPEN-ERROR:SIGNAL-FILE-ERROR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157_w.htm new file mode 100644 index 00000000..ddb897d9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss157_w.htm @@ -0,0 +1,220 @@ + + + +CLHS: Issue FILE-OPEN-ERROR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FILE-OPEN-ERROR Writeup

    + +
    Forum:		Public Review
    
+Issue:		FILE-OPEN-ERROR
    
+References:	Rose & Yen public review comment #3
    
+		OPEN
    
+		PROBE-FILE
    
+		Section 19.1.2, "Pathnames as Filenames"
    
+		Issue PATHNAME-SYNTAX-ERROR-TIME
    
+                Issue PATHNAME-WILD
    
+Category:	CLARIFICATION, CHANGE
    
+Edit history:	26-Dec-1992, Version 1 by Loosemore
    
+Status:         Item (4) removed; remainder of proposal passed 7-0-2,
    
+                  March 1993
    
+
    
+
    
+Problem description:
    
+
    
+  The specification provides no reliable way for application programs
    
+  to detect and recover from file system errors.
    
+
    
+  The specific situation raised by the referenced public review comment
    
+  was failure of OPEN due to the file being read- or write-protected.
    
+  However, there are numerous other situations which may also cause OPEN
    
+  (as well as other file-related operations, such as PROBE-FILE,
    
+  DIRECTORY, and the like) to fail.  These include things like directory
    
+  components in the pathname that don't really name directories, or
    
+  invalid symbolic links.  The dictionary pages for most of these
    
+  functions say nothing about what happens in the event the file system
    
+  is unable to perform the request.
    
+
    
+  To complicate matters further, there is also a related class of purely
    
+  syntactic pathname errors that were the subject of proposal
    
+  PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE, which was incorporated
    
+  into draft 12.24 as the second paragraph on page 19-2.  Nothing is
    
+  said in that section either about whether an error must be
    
+  signaled, or the type of such an error.  The problem description of
    
+  that issue left open the possibility that an implementation might
    
+  attempt to make `friendly' corrections to syntactically invalid
    
+  pathnames -- e.g., truncating names that are too long -- instead of
    
+  signaling an error, but the discussion in the draft does not mention
    
+  this explicitly.  Since one of the provisions of the proposal was to
    
+  "warn users clearly about this known source of program portability
    
+  problems", it seems some further clarification of how pathname syntax
    
+  errors may be handled is in order.
    
+
    
+  If that weren't enough, some functions specify that the type of error
    
+  signalled when a wildcard pathname is provided is TYPE-ERROR, and
    
+  others specify that it is of type FILE-ERROR.
    
+
    
+
    
+Proposal (FILE-OPEN-ERROR:SIGNAL-FILE-ERROR):
    
+
    
+  (1) Add to the "Exceptional Situations" section of the dictionary
    
+  pages for DIRECTORY, PROBE-FILE, TRUENAME, FILE-AUTHOR, FILE-WRITE-DATE,
    
+  OPEN, WITH-OPEN-FILE, COMPILE-FILE, LOAD, ED, and DRIBBLE a statement
    
+  that an error of type FILE-ERROR is signaled if the file system cannot
    
+  perform the requested operation.  (The entries for RENAME-FILE and 
    
+  DELETE-FILE already include similar language.)
    
+
    
+  If the proposals to restore the pathname argument to REQUIRE and/or
    
+  to add the ENSURE-DIRECTORIES-EXIST function pass, add the same
    
+  statement to the dictionary entries for these functions.
    
+
    
+
    
+  (2) Rewrite and expand the second paragraph on page 19-2 to read:
    
+
    
+    The mapping of the pathname components into the concepts peculiar to
    
+    each file system is implementation-defined.  There exist conceivable
    
+    pathnames for which there is no mapping to a syntactically valid
    
+    filename in a particular implementation.  An implementation may use
    
+    various strategies in an attempt to find a mapping; for example, an
    
+    implementation may quietly truncate filenames that exceed length
    
+    limitations imposed by the underlying file system, or ignore certain
    
+    pathname components for which the file system provides no support.  If
    
+    such a mapping cannot be found, an error of type FILE-ERROR is
    
+    signaled.
    
+
    
+    The time at which this mapping and associated error signaling occurs
    
+    is implementation-dependent.  Specifically, it may occur at the time
    
+    the pathname is constructed; when coercing a pathname to a namestring;
    
+    or when an attempt is made to open or otherwise access the file 
    
+    designated by the pathname.
    
+
    
+  At the editor's discretion, also note this in the "Exceptional 
    
+  Situations" section of the dictionary pages for the affected 
    
+  functions.  These functions are:  PATHNAME, MAKE-PATHNAME,
    
+  PATHNAME-HOST and friends, LOGICAL-PATHNAME-TRANSLATIONS, 
    
+  NAMESTRING and friends, PARSE-NAMESTRING, WILD-PATHNAME-P,
    
+  PATHNAME-MATCH-P, TRANSLATE-LOGICAL-PATHNAME, TRANSLATE-PATHNAME,
    
+  MERGE-PATHNAMES, COMPILE-FILE-PATHNAME, and all of the functions
    
+  mentioned in item (1) of the proposal.
    
+
    
+  (3) Change the dictionary entries for PROBE-FILE, TRUENAME,
    
+  FILE-AUTHOR, and FILE-WRITE-DATE to say that the type of error
    
+  signalled when a wildcard pathname is provided is FILE-ERROR rather 
    
+  than TYPE-ERROR.  (The entries for RENAME-FILE, DELETE-FILE, OPEN,
    
+  WITH-OPEN-FILE, COMPILE-FILE, and LOAD already specify a type of
    
+  FILE-ERROR.)
    
+
    
+  Also, add a statement that an error of type FILE-ERROR might be
    
+  signalled if the pathname argument is wild to the dictionary entries 
    
+  for COMPILE-FILE-PATHNAME, ED, DRIBBLE, and (if the appropriate
    
+  proposals pass) REQUIRE and ENSURE-DIRECTORIES-EXIST.
    
+
    
+  (4) Deprecate the function PROBE-FILE.
    
+
    
+
    
+Rationale:
    
+
    
+  Providing detailed information about when and what type of errors
    
+  might be signalled allows users to include condition handlers at
    
+  relevant places in their programs which can take appropriate action
    
+  to report and/or recover from the error.
    
+
    
+  It's clear that FILE-ERROR is the correct condition type for the
    
+  kinds of errors covered by item (1) of the proposal.  It could be
    
+  argued that the errors covered by items (2) and (3) ought to be of
    
+  some other condition type, but since in some cases these errors might
    
+  be reported by the file system in the same way as the errors from 
    
+  item (1), it may be difficult to distinguish them in practice.
    
+
    
+  The rationale for deprecating PROBE-FILE is that the general approach
    
+  of trying to check whether a file operation is going to succeed ahead
    
+  of time is not the right way to handle file system access problems.
    
+  Also, its functionality can readily be duplicated by OPEN and/or
    
+  TRUENAME.
    
+  
    
+
    
+Current practice:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Probably small.
    
+
    
+
    
+Cost to users:
    
+
    
+  Probably small.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+  Continuing confusion about how to handle file system errors.
    
+
    
+
    
+Aesthetics:
    
+
    
+  I suppose having the standard made more explicit on this issue is an
    
+  improvement, even if it makes it longer.
    
+
    
+
    
+Editorial impact:
    
+
    
+  There are a large number of functions affected, but the changes are
    
+  fairly mechanical in nature.
    
+
    
+
    
+Discussion:
    
+
    
+  A completely different proposal, PROBE-FILE:ADD-DIRECTION-KEYWORD,
    
+  was originally suggested by Rose & Yen in their public review comment.
    
+  The gist of that proposal was to modify PROBE-FILE so it could be used
    
+  to check whether the user had privilege to subsequently OPEN a file.
    
+  The public review committee concluded this was an unsatisfactory
    
+  approach, not only because it didn't allow for detection of other
    
+  kinds of file access problems, but also because it could be defeated
    
+  by changes to the file system in between the check and the attempted
    
+  access.  In subsequent e-mail discussion, the commentors have agreed
    
+  to withdrawing that proposal in favor of the one presented here.
    
+
    
+  Loosemore admits to being skeptical about the rationale for deprecating
    
+  PROBE-FILE (in particular, because doing so would seem to indicate
    
+  that there are no valid uses of PROBE-FILE at all), but the original
    
+  commentors requested us to consider it.
    
+    
    
+
    
+
    
+  
    
+
    
+
    
+
    
+
    
+
    
+
    
+
    
+  
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158.htm new file mode 100644 index 00000000..ce7807bc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158_w.htm new file mode 100644 index 00000000..f910da18 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss158_w.htm @@ -0,0 +1,158 @@ + + + +CLHS: Issue FIXNUM-NON-PORTABLE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FIXNUM-NON-PORTABLE Writeup

    + +
    Status: Passed Jan 89 X3J13, as amended
    
+Issue: FIXNUM-NON-PORTABLE
    
+References:	CLtL p. 14, 34, 43, 231
    
+Category:	CHANGE, CLARIFICATION
    
+
    
+Edit History:   Version 1, 11-Jul-88, Sandra Loosemore
    
+		    Version 2, 15-Sep-88, Masinter
    
+		    Version 3, 23-Sep-88, Masinter
    
+		    Version 4,  7-Dec-88, Masinter (two proposals)
    
+		    Version 5, 16-Mar-89, Masinter (incorporate amendments)
    
+		    Version 6, 17-Mar-89, Masinter (incorporate amendments correctly)
    
+
    
+Problem Description: 
    
+
    
+Implementations of Common Lisp are required to support two disjoint
    
+subsets of integers, fixnums and bignums, with the promise that
    
+fixnums have a more efficient representation.  However, nothing is
    
+guaranteed about the range of integers which are fixnums: "Exactly
    
+which integers are fixnums is implementation-dependent; typically they
    
+will be those integers in the range -2**n to 2**n - 1, inclusive, for
    
+some n not less than 15."
    
+
    
+There are few uses of the fixnum type that are portable, given the
    
+current definition.  In particular, many programmers use FIXNUM type
    
+declarations where they really mean "small integer".
    
+
    
+While most Common Lisp implementations have a FIXNUM range
    
+which is a subset of integers represeted and operated on most
    
+efficiently, many also have several other subranges.  The
    
+partitioning of INTEGER into BIGNUM and FIXNUM is merely
    
+confusing in these implementations, and not useful.
    
+
    
+CLtL p14 and p34 disagree about BIGNUM. One says that
    
+ FIXNUM and BIGNUM are an exhaustive partition of the
    
+integer space, the other says they might not be!
    
+
    
+Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
    
+
    
+(1) Change the description of the type FIXNUM to reflect that it is
    
+ required to be a supertype of (SIGNED-BYTE 16).
    
+
    
+(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
    
+
    
+(3) require that (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM)
    
+
    
+Example:
    
+
    
+Consider an implementation with three numeric representations:
    
+
    
+	Fast                (INTEGER -1024 1023)
    
+	Immediate           29 bits
    
+	Extended            Multi-precision
    
+
    
+Such an implementation would have to define
    
+FIXNUM to be (OR Fast Immediate). BIGNUM
    
+would then refer to multi-precision integers. 
    
+
    
+Rationale:
    
+
    
+Many programmers already use FIXNUM to mean "small integer"; this
    
+proposal makes this usage portable. 
    
+
    
+However, there is little portable use for the type BIGNUM, and it
    
+is inconsistent with many current implementation techniques.
    
+Removing it is an incompatible change for a weak reason.
    
+
    
+Current Practice:
    
+
    
+Xerox Common Lisp has 17-bit fixnums.  Most other Common Lisp
    
+ implementations have  fixnum ranges of 24 bits or larger. We know
    
+of no implementation that currently violates the proposed minimum 
    
+size.
    
+
    
+Several existing Common Lisp implementations have more than two 
    
+representations for integers, such that the FIXNUM/BIGNUM distinction
    
+is confusing; they define BIGNUM to cover all of the larger number
    
+types.
    
+
    
+Cost to implementors:
    
+
    
+Slight.  All implementations we know of already define FIXNUMs to be at
    
+least 16 bits.
    
+
    
+Cost to users:
    
+
    
+Slight.  
    
+
    
+Benefits:
    
+
    
+The FIXNUM type specifier would have a portable interpretation.
    
+
    
+The language would be less confusing.
    
+
    
+Discussion:
    
+
    
+There was little consensus on whether to leave BIGNUM in the language.
    
+
    
+Earlier discussion of a related proposal contained several other more
    
+controversial components (adding a constant MAX-INTEGER-LENGTH, allowing 
    
+MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
    
+is an attempt to address the part that cleanup committee seemed to agree
    
+on.
    
+
    
+It is possible that an implementation have a single  representation for all
    
+integers, and no way to identify any efficient range of integers. Those
    
+implementations might need to set MOST-POSITIVE-FIXNUM
    
+ and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with 
    
+the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
    
+
    
+Other alternatives considered (and not necessarily mutually exclusive
    
+with this proposal):
    
+
    
+  remove the FIXNUM type specifier entirely, while leaving a way
    
+  to query what is the most efficient range of integers
    
+
    
+   leave the range of FIXNUMs unconstrained  and introduce a 
    
+   SMALL-INTEGER type with a fixed range (but no promises about
    
+   efficiency) . 
    
+
    
+It might be possible to specify the required performance behavior
    
+of FIXNUMs more concretely, e.g., specify that the basic integer operations
    
+use algorithms that are not proportional to the size of the data;  it 
    
+should be just about as fast to add numbers in the middle of the fixnum 
    
+range as it is to add, say, 10 and 11. This might be a useful way to
    
+describe
    
+the intent of the FIXNUM range, if not its specification.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159.htm new file mode 100644 index 00000000..4b19254e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FLET-DECLARATIONS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FLET-DECLARATIONS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FLET-DECLARATIONS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_m.htm new file mode 100644 index 00000000..fea18c71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue FLET-DECLARATIONS Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue FLET-DECLARATIONS Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_w.htm new file mode 100644 index 00000000..f8187c04 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss159_w.htm @@ -0,0 +1,129 @@ + + + +CLHS: Issue FLET-DECLARATIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FLET-DECLARATIONS Writeup

    + +
    Issue:         FLET-DECLARATIONS
    
+
    
+References:    FLET, LABELS, MACROLET (CLtL p.113)
    
+	       X3J13 document 86-003 item 113
    
+	       Cleanup issue DECLARATION-SCOPE.
    
+	       Cleanup issue DECLARE-MACROS.
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, Moon, 1 Jan 1988
    
+	       Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
    
+
    
+Problem description:
    
+
    
+Declarations are not allowed before the body of FLET, LABELS, and
    
+MACROLET, even though Common Lisp allows declarations in other seemingly
    
+analogous places, such as LET.
    
+
    
+Proposal (FLET-DECLARATIONS:ALLOW):
    
+
    
+Change the syntax of FLET, LABELS, and MACROLET to allow declarations
    
+between the list of local function/macro definitions and the body forms.
    
+
    
+The scope of such declarations in FLET and LABELS includes the bodies
    
+of the locally defined functions, when the declarations are pervasive.
    
+Non-pervasive declarations have no effect on those bodies, except when
    
+LABELS includes the body in the scope of a function non-pervasively
    
+declared.  This paragraph follows directly from CLtL p.155 if the
    
+locally defined function bodies are treated like initialization forms.
    
+(This paragraph will be superseded by cleanup issue DECLARATION-SCOPE
    
+if it passes.)
    
+
    
+The scope of such declarations does not include the bodies of the
    
+macro expander functions defined by MACROLET.  This is consistent with
    
+the existing rule that the bodies of those functions are in the global
    
+environment, not the local lexical environment.
    
+
    
+If cleanup issue DECLARE-MACROS is not passed, in MACROLET an
    
+invocation of one of the macros locally defined by that MACROLET is
    
+permitted to expand into a DECLARE.
    
+
    
+Test Cases/Examples:
    
+
    
+(defun example (y l)
    
+  (flet ((attach (x)
    
+	   (setq l (append l (list x)))))
    
+    (declare (inline attach))
    
+    (dolist (x y)
    
+      (unless (null (cdr x))
    
+	(attach x)))
    
+    l))
    
+
    
+(example '((a apple apricot) (b banana) (c cherry) (d) (e))
    
+	 '((1) (2) (3) (4 2) (5) (6 3 2)))
    
+ => ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
    
+
    
+The above function is erroneous in current Common Lisp.  With this
    
+proposal, it would have an intuitively obvious meaning.
    
+
    
+Rationale:
    
+
    
+This will make the syntax of FLET and LET consistent.  This will make
    
+it possible to attach declarations to function bindings; currently only
    
+variable bindings can have attached declarations.
    
+
    
+Current practice:
    
+
    
+Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW.
    
+Symbolics Common Lisp does not allow declarations in this position.
    
+
    
+Cost to Implementors:
    
+
    
+The compilation and interpretation of three special forms will have to
    
+be changed, however the same techniques already developed for
    
+declarations in LET should be applicable.
    
+
    
+Cost to Users:
    
+
    
+No cost since this is an upward-compatible addition.
    
+
    
+Cost of non-adoption:
    
+
    
+Unnecessary inconsistency in the syntax of Common Lisp.
    
+
    
+Benefits:
    
+
    
+There is no major benefit but the language will be more consistent.
    
+
    
+Esthetics:
    
+
    
+Makes the language more consistent.
    
+
    
+Discussion:
    
+
    
+We need to resolve this for CLOS, because CLOS introduces two new
    
+special forms similar to FLET and LABELS and we need to make their
    
+syntax consistent with FLET and LABELS.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss160.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss160.htm new file mode 100644 index 00000000..3b0a3970 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss160.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FLET-DECLARATIONS:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FLET-DECLARATIONS:ALLOW Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FLET-DECLARATIONS:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161.htm new file mode 100644 index 00000000..a0cee2cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue FLET-IMPLICIT-BLOCK:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FLET-IMPLICIT-BLOCK:YES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FLET-IMPLICIT-BLOCK:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161_w.htm new file mode 100644 index 00000000..26ad1fb0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss161_w.htm @@ -0,0 +1,135 @@ + + + +CLHS: Issue FLET-IMPLICIT-BLOCK Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FLET-IMPLICIT-BLOCK Writeup

    + +
    Issue:        FLET-IMPLICIT-BLOCK
    
+Reference:    CLtL p. 113, 67
    
+Category:     OMISSION 
    
+Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
    
+              Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12 
    
+              Versions 4,5 by Fahlman 11-Apr-87
    
+              Version 6 by Masinter  5-Jun-87
    
+
    
+
    
+Problem Description:
    
+
    
+Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
    
+DEFTYPE have an implicit block around their bodies like the body of a
    
+DEFUN?  CLtL is silent on this point.  Many users and some implementors
    
+assume that such blocks should be established, since they view these
    
+forms as analogous with DEFUN.
    
+
    
+Test case:
    
+
    
+(defun test ()
    
+  (flet ((test (x) (if x (return-from test 4) 3)))
    
+	(list (test nil) (test t))))
    
+
    
+(test)
    
+
    
+will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
    
+return 4 in an implementation that did not add an implicit block around
    
+FLET.
    
+
    
+Proposal: FLET-IMPLICIT-BLOCK:YES
    
+
    
+Each function created by FLET and LABELS and each macro created by
    
+DEFMACRO and MACROLET has an implicit block around the body.  The name
    
+of this block is that same as the (lexical) name of the function or
    
+macro.  Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
    
+DEFTYPE is surrounded by a block with the same name as the accessor or
    
+type.
    
+
    
+Current Practice:
    
+
    
+Current practice is mixed.  Several implementations do not add the
    
+implicit block, others do, some add some of these blocks and not others.
    
+
    
+Cost of adopting this change:
    
+
    
+Some implementations will have to be modified.  This should be a
    
+relatively easy modification.
    
+
    
+Cost of not adopting the change:
    
+
    
+If the issue is not clarified one way or another, continuing confusion
    
+will result in portability problems.  Clarifying the issue in any other
    
+way would also require modifications in some implementations.
    
+
    
+Cost of converting existing code:
    
+
    
+It is possible that some user code would break because it does a return
    
+from within a code body to an outer block that has the same as the
    
+newly-required block.  Such problems will be rare, and the code in
    
+question would not run on all current Common Lisp systems because of the
    
+diverse interpretations currently in effect.  It would be possible to
    
+detect all such instances automatically, though it seems unlikely that
    
+anyone will need to use this technique.
    
+
    
+Discussion:
    
+
    
+The goal is first to clean up an ambiguous situation and, second, to do
    
+this in a way that provides consistent behavior between local and global
    
+definitions.  The proposed change would allow a simple rule of thumb:
    
+any named entity that takes a code body establishes an implicit block
    
+with the obvious name.
    
+
    
+Two alternatives to the proposal were considered and rejected:
    
+
    
+The first would be to keep the implicit block in DEFUN, and to clearly
    
+state that the other forms do not create implicit blocks.  This violates
    
+the goal of consistency between lexical and global definitions, and it
    
+seems to conflict with users' expectations.
    
+
    
+The second alternative was to eliminate the implicit block from DEFUN
    
+rather than adding such blocks to other forms.  There was some feeling
    
+that specifying the implicit block in DEFUN was a poor design decision
    
+in the first place, since it hides a reference to the name of a function
    
+within the code of the function itself.  If a user decides to rename
    
+some function, he must be careful to rename any return-from forms within
    
+the body of the function as well.
    
+
    
+However, eliminating the implicit block in DEFUN would be a significant
    
+incompatible change.  Some users find this implicit block to be a great
    
+convenience for popping out of convoluted code, and some existing code
    
+makes heavy use of this feature.  While such code could be repaired
    
+automatically by searching for situations in which the user returns from
    
+a function by name and by adding an appropriate explicit block to any
    
+function containing such a forms, it would still require more more work
    
+on existing user code than this proposal made above.
    
+
    
+There was considerable discussion in the cleanup committee about whether
    
+these implicit blocks would interfere with tail-recursion optimization,
    
+which we hope will become more common in future Common Lisp
    
+implementations.  The outcome of these discussions was general agreement
    
+that a compiler could easily eliminate the implicit block in any case
    
+where it is not actually used, and that the impact on tail-recursion
    
+optimization in compiled code is therefore minimal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162.htm new file mode 100644 index 00000000..01b3981a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FLOAT-UNDERFLOW:ADD-VARIABLES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FLOAT-UNDERFLOW:ADD-VARIABLES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FLOAT-UNDERFLOW:ADD-VARIABLES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162_w.htm new file mode 100644 index 00000000..effc1aae --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss162_w.htm @@ -0,0 +1,150 @@ + + + +CLHS: Issue FLOAT-UNDERFLOW Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FLOAT-UNDERFLOW Writeup

    + +
    Issue:         FLOAT-UNDERFLOW
    
+References:    CLtL p.231
    
+Related issues:LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION (not written up),
    
+               ERROR-CHECKING-IN-NUMBERS-CHAPTER
    
+Category:      ADDITION and CLARIFICATION
    
+Edit history:  Version 1, 9-May-89, by Moon (suggested in January, but
    
+                        the writeup was late)
    
+               Version 2, 23-May-89, by Moon (final cleanup for post-CLtL
    
+                        changes to Common Lisp)
    
+               Version 3, 18-Jun-89, by Moon (update based on discussion
    
+                        within the cleanup subcommittee)
    
+	       Version 4, 28-Jul-89, by Pitman (modify per X3J13 vote)
    
+Status: Passed FLOAT-UNDERFLOW:ADD-CONTROLS-1-2, June 1989
    
+
    
+Problem description:
    
+  
    
+  In implementations with denormalized floating point numbers (as in IEEE
    
+  floating point), which are closer to zero than any non-zero normalized
    
+  floating point numbers, should the LEAST-POSITIVE- and
    
+  MOST-POSITIVE-XXX-FLOAT constants be the normalized or denormalized
    
+  values?  Which is preferred depends on the application.  Note that in
    
+  IEEE floating point, denormalized results are normally only produced
    
+  as a result of underflow.
    
+  
    
+  Also, there is no portable way to control what happens when a floating
    
+  point number underflows.  Sometimes this is an error, sometimes not.
    
+  Indeed there is no mention at all of underflow or overflow in CLtL.
    
+  Pending issue ERROR-CHECKING-IN-NUMBERS-CHAPTER does not mention floating
    
+  point overflow or underflow.  Draft ANSI Common Lisp specifies error
    
+  conditions named FLOATING-POINT-OVERFLOW and FLOATING-POINT-UNDERFLOW
    
+  but does not specify the circumstances in which they are signalled and
    
+  does not provide any way to suppress underflow checking.
    
+
    
+Proposal (FLOAT-UNDERFLOW:ADD-VARIABLES):
    
+  
    
+  1. Clarify that the existing LEAST-POSITIVE-XXX-FLOAT and
    
+  LEAST-NEGATIVE-XXX-FLOAT constants are literally as defined, and
    
+  therefore can be denormalized numbers in implementations that have
    
+  denormalized numbers.
    
+  
    
+  2. Add the following constants, whose values are the normalized floating
    
+  point numbers closest in value to (but not equal to) zero.  In
    
+  implementations that don't have denormalized numbers, the values of these
    
+  constants are the same as the values of the other constants.
    
+  
    
+    LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
    
+    LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT [Constant]
    
+    LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT [Constant]
    
+    LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT [Constant]
    
+    LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
    
+    LEAST-POSITIVE-NORMALIZED-LONG-FLOAT [Constant]
    
+    LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT [Constant]
    
+    LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT [Constant]
    
+
    
+Rationale:
    
+
    
+  Regularize current practice.
    
+
    
+  The ANSI Common Lisp standard should be compatible with the widely used
    
+  IEEE Floating Point standard.
    
+
    
+  WITHOUT-FLOATING-UNDERFLOW-TRAPS is provided as a macro to allow
    
+  implementation flexibility.  It could expand into HANDLER-BIND for
    
+  FLOATING-POINT-UNDERFLOW, but in most implementations it will probably
    
+  expand into implementation-dependent code that sets a hardware mode bit.
    
+
    
+  Specifying "should signal" rather than "signals" or "might signal" for
    
+  floating-point overflows and underflows seems the best balance between
    
+  safety and implementation freedom.  It wouldn't harm the proposal to
    
+  change it to one of the other two phrases.
    
+
    
+Current practice:
    
+
    
+  Lucid and Symbolics implement this proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+  If there are implementations that currently consider storing only
    
+  normalized quantities in the CLtL-specified variables, code that
    
+  references those variables might need to be changed to refer to the
    
+  new variable so that the existing variables can be changed to store
    
+  unnormalized values.
    
+
    
+Cost to Users:
    
+
    
+  Technically none.  Portable code cannot rely on this feature because
    
+  it is currently inadequately specified.  Code which relies on a 
    
+  particular implementation's interpretation might have to be modified
    
+  very slightly and recompiled.
    
+
    
+Cost of non-adoption:
    
+
    
+  Continued confusion over the question of what is held by the
    
+  existing LEAST-xxx variables.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Increased portability and correctness of floating point code.
    
+
    
+Esthetics:
    
+
    
+  Neutral.
    
+
    
+Discussion:
    
+
    
+  Earlier revisions of this proposal addressed other features which 
    
+  addressed the issues raised in the Problem Description in a more 
    
+  thorough way.  Included in version 3 was a proposal for a 
    
+  WITHOUT-FLOATING-UNDERFLOW-TRAPS form.  Discussion of those 
    
+  additional features was tabled for lack of time during the meeting
    
+  where the vote was taken on this issue--and a proposal equivalent
    
+  to this more limited proposal was approved since it was less
    
+  controversial.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163.htm new file mode 100644 index 00000000..e0a09218 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163_w.htm new file mode 100644 index 00000000..f018bafb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss163_w.htm @@ -0,0 +1,167 @@ + + + +CLHS: Issue FLOATING-POINT-CONDITION-NAMES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FLOATING-POINT-CONDITION-NAMES Writeup

    + +
    Forum:		Cleanup
    
+Issue:		FLOATING-POINT-CONDITION-NAMES
    
+References:	CLtL, Section 12.10 "Implementation Parameters" (for floats)
    
+		CLtL, P.448 "*features*"
    
+		IEEE Standard for Binary Floating-Point Arithmetic
    
+Related Issues:	FLOAT-UNDERFLOW
    
+		ERROR-CHECKING-IN-NUMBERS-CHAPTER
    
+Category:	ADDITION
    
+Edit History:   V1, 30 Oct 1989, JonL White
    
+	        V2, 4 Dec 1990, Kent M. Pitman (amendments per X3J13)
    
+
    
+Problem Description:
    
+
    
+The currently proposed error system contains names for three conditions
    
+related to floating-point operations: floating-point-underflow,
    
+floating-point-overflow, and division-by-zero.  Probably a majority
    
+of implementation will be running on machines that support the IEEE
    
+floating point standard; but there is no name for the remaining two out 
    
+of the five mandated trapping conditions, namely floating-point-inexact
    
+and floating-point-invalid-operation.
    
+
    
+Furthermore, even though the condition names may appear in an image,
    
+it is not clear that such traps are enabled at every point in time.
    
+The IEEE standard specifies that user-level programs ought to have
    
+the capability of selectively enabling or disabling its five traps;
    
+and other implementations may run on a variety of hardware configurations
    
+for which the traps possible vary from host to host.  However, there is
    
+no current way for user-code to ask (1) what conditions are in fact
    
+supporting floating-point traps, nor to ask (2) just what traps are 
    
+currently active
    
+
    
+Note that some very simple implementations might not be able to cause
    
+trapping even for floating-point-underflow;  and in other implementations,
    
+the relevant traps may vary on a host-to-host basic, depending on what
    
+particular optional hardware is available on that host.  For example,
    
+Sun3 workstations come  in three configurations: one with only software 
    
+floating-point support, one with a Motorola MC68881 attached co-processor, 
    
+and one with both an MC68881 and a Weitek Floating Point "Accelerator"; 
    
+the increasing hardware complement gives rise to an increasing number of 
    
+implementation-specific traps.  Even within the IEEE standard, it is 
    
+possible for a conforming implementation to make a refinement of the five 
    
+suggested traps [the MC68881 partitions one of the traps into three, 
    
+giving a total of eight]; so even though one knows that an implementation 
    
+is IEEE compatible, it still makes sense to ask what conditions are 
    
+supportable as floating-point traps.
    
+
    
+Proposal (FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89)
    
+
    
+  1. Add FLOATING-POINT-INVALID-OPERATION and FLOATING-POINT-INEXACT
    
+     as conditions which are sub-conditions of ARITHMETIC-ERROR.
    
+
    
+The intent is that if condition FOO is a currently enabled floating
    
+point trap, then whenever that particular situation arises the
    
+system will arrange to signal the Lisp condition FOO.  The means for
    
+enabling and disabling traps is not addressed in this proposal.
    
+
    
+Proposal (FLOATING-POINT-CONDITION-NAMES:ADD-MINIMAL-IEEE)
    
+
    
+  1. Add FLOATING-POINT-INVALID-OPERATION and FLOATING-POINT-INEXACT
    
+     as conditions which are sub-conditions of ARITHMETIC-ERROR.
    
+  2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS which
    
+     is to contain a list of all the condition names that can, in that
    
+     implementation, be enabled as floating-point traps; this is to
    
+     be an "implementation revealing" parameter.
    
+  3. Add a function of no arguments ENABLED-FLOATING-POINT-TRAPS which
    
+     returns a list of condition names for all currently enabled
    
+     floating point trapping conditions.
    
+
    
+The intent is that if condition FOO is a currently enabled floating
    
+point trap, then whenever that particular situation arises the
    
+system will arrange to signal the Lisp condition FOO.  The means for
    
+enabling and disabling traps is not addressed in this proposal.
    
+
    
+
    
+Rationale:
    
+
    
+Many Common Lisp implementations do in fact run on hardware that
    
+supports the IEEE floating-point standard;  a minimal requirement
    
+for porting between these implementations is that they all use the
    
+same name for the five IEEE-mandated floating-point conditions.
    
+Since at least some implementations will provide means for selective
    
+enabling and disabling of various floating-point traps, then the 
    
+user must be able to query the system to find out what the current
    
+state is, and what states are supportable.
    
+
    
+
    
+Current Practice:
    
+
    
+Lucid Common Lisp supports this much; moreover, it uses SETF on
    
+(ENABLED-FLOATING-POINT-TRAPS) as the primary means to alter the
    
+currently-enabled traps.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Trivial.
    
+
    
+
    
+Cost to users:
    
+
    
+None; this is an upward-compatible addition.
    
+
    
+
    
+Benefits:
    
+
    
+Portability of a greater amount of user code; portability of "skills",
    
+since IEEE support is so common.
    
+
    
+
    
+Aesthetics:
    
+
    
+It is better for all IEEE implementations to use the same names for
    
+these conditions, rather than have them vary from one to another.
    
+It is also probably better for non-IEEE implementations to use the
    
+IEEE condition names where appropriate, just to minimize the 
    
+conceptual overload.
    
+
    
+
    
+Discussion:
    
+
    
+If an implementation is to claim full IEEE support, then it ought to 
    
+provide some means of enabling and catching these five IEEE-mandated
    
+traps.  Then it would be appropriate to put :IEEE-FLOATING-POINT on
    
+the list *FEATURES* (see CLtL, P.448).
    
+
    
+Moon and JonL privately discussed some means for enabling and
    
+disabling various floating-point traps, back in June 1989 when the 
    
+float-underflow proposal was under discussion; they came to the 
    
+conclusion that "getting the design right and efficient" was more 
    
+than a few minutes worth of work, and so postponed further work on it.
    
+
    
+
    
+[The IEEE standard apparently goes by the name of ANSI-IEEE Std 754-1985; 
    
+my working copy is Draft 10.0 from 1982.  I don't think there are great 
    
+variances between them. -- JonL --]
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164.htm new file mode 100644 index 00000000..9c85757e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FORMAT-ATSIGN-COLON Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-ATSIGN-COLON Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FORMAT-ATSIGN-COLON:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164_w.htm new file mode 100644 index 00000000..2a941412 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss164_w.htm @@ -0,0 +1,84 @@ + + + +CLHS: Issue FORMAT-ATSIGN-COLON Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-ATSIGN-COLON Writeup

    + +
    Issue:        FORMAT-ATSIGN-COLON
    
+References:   FORMAT description (p386)
    
+Category:     CLARIFICATION
    
+Edit history: Version 1 by Pitman 02/27/87
    
+              Version 2 by cleanup committee 15-Mar-87
    
+              Version 3 by Masinter 15-Mar-87
    
+	      Version 4 by Masinter  5-Jun-87
    
+
    
+Problem Description:
    
+
    
+CLtL describes the format op syntax as:
    
+
    
+"a format directive consists of a tilde (~), optional prefix parameters
    
+separated by commas, optional colon (:) and atsign (@) modifiers, and a
    
+single character indicating what kind of directive this is."
    
+
    
+CLtL uses :@ fairly consistently throughout without saying whether @: is
    
+legal. Is @: allowed?
    
+
    
+Proposal (FORMAT-ATSIGN-COLON:OK):
    
+
    
+There is no required ordering between the @ and : modifier.
    
+
    
+Rationale:
    
+
    
+This is currently underspecified, and this way of specifying it will
    
+cause the least disruption to user code.
    
+
    
+Current practice:
    
+
    
+Most implementations accept these in either order. Some implementations
    
+have been known to expect only :@.
    
+
    
+Adoption Cost:
    
+
    
+The change to accept either syntax is probably quite trivial.
    
+
    
+Benefits:
    
+
    
+Having @: and :@ mean different things would be awkward. 
    
+
    
+Conversion Cost:
    
+
    
+Existing user code would be unaffected.
    
+
    
+Aesthetics:
    
+
    
+Leaving these unordered is slightly simpler conceptually.
    
+
    
+Discussion:
    
+
    
+The cleanup committee supports this clarification.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165.htm new file mode 100644 index 00000000..2c4b2eba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FORMAT-COLON-UPARROW-SCOPE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-COLON-UPARROW-SCOPE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FORMAT-COLON-UPARROW-SCOPE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165_w.htm new file mode 100644 index 00000000..948cc8ee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss165_w.htm @@ -0,0 +1,141 @@ + + + +CLHS: Issue FORMAT-COLON-UPARROW-SCOPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-COLON-UPARROW-SCOPE Writeup

    + +
    Issue: FORMAT-COLON-UPARROW-SCOPE
    
+
    
+References:    CLtL p. 406 and also p. 403
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  version 1: Guy Steele, 30 November 1987
    
+	       version 2: Guy Steele, 18 January 1988
    
+	       version 3: Masinter,  5 February 1988
    
+
    
+Problem description:
    
+
    
+Implementations currently differ on the question of what is tested by the FORMAT
    
+command "~:^".  Some implementations test to see whether any arguments remain in
    
+the sublist for the current iteration step; others test to see whether any
    
+sublists remain.  The text on page 406 is not clear on this point.
    
+
    
+Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
    
+
    
+~:^ may be used only if the command it would terminate is ~:{ or ~:@{. The
    
+entire iteration process is terminated if and only if the sublist that is
    
+supplying the arguments for the current iteration step is the last sublist (in
    
+the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:^ is *not*
    
+equivalent to ~:#^; the latter terminates the entire iteration if and only if no
    
+arguments remain for the current iteration step.
    
+
    
+Example:
    
+
    
+(format nil "~:{~@?~:^...~}" '(("a") ("b")))
    
+
    
+Under this proposal, this yields "a...b", rather than "a".
    
+
    
+Rationale:
    
+
    
+This proposal is desirable because otherwise there is no way to test whether any
    
+sublists remain. The text on page 406 may be construed to hint at this proposal
    
+indirectly.  To quote Nick Gall:
    
+
    
+"If one thinks about the intent of the parenthetical `(because in the standard
    
+case it tests for remaining arguments of the current step only)', one should
    
+agree that "a...b" will be returned.  In referring to ~^ as the `standard case',
    
+which tests the arguments remaining in the current argument sublist, this
    
+parenthetical implies that there is an `other case', which tests `something
    
+else.'  The only `other case' discussed is ~:^, which therefore must test
    
+`something else.'  I claim that the parentheical makes no sense if we interpret
    
+~:^ as testing the same condition as ~^.  If they both test the same condition,
    
+why have the parenthetical explanation?
    
+
    
+"If ~:^ doesn't test the same condition as ~^, then what does it test? I claim
    
+that the only test that makes sense is for ~:^ to test the only thing that
    
+affects the `entire iteration process:' the number of sublists.  When there are
    
+no more sublists, `the entire iteration process' is terminated."
    
+
    
+Current practice:
    
+
    
+Some implementations already have the proposed behavior, including Symbolics
    
+Common Lisp and TI Lisp.
    
+
    
+Many other implementations currently have a different interpretation: the test
    
+case returns "a", since ~:^ in those implementations test for the remaining
    
+arguments rather than remaining sublists. These currently include  Kyoto Common
    
+Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP.
    
+
    
+Cost to Implementors:
    
+
    
+Many implementations will have to make a small change, probably a one-liner.
    
+
    
+Cost to Users:
    
+
    
+It is unlikely that much user code depends on the behavior of testing for
    
+remaining arguments, but it is possible.  The author of this writeup (Steele)
    
+judges it somewhat more likely that user code might depend on the behavior of
    
+testing for remaining sublists.
    
+
    
+Cost of non-adoption:
    
+
    
+Users would have to be warned not to use ~:^ in code that is meant to be
    
+portable.
    
+
    
+Benefits:
    
+
    
+Elimination of yet one more ambiguity. The proposed semantics allows greater
    
+semantic power (there are more things one can test).
    
+
    
+Esthetics:
    
+
    
+``Absolutely none.  We're talking about FORMAT here.'' -- Guy L. Steele Jr.
    
+
    
+Discussion:
    
+
    
+Guy Steele very strongly prefers the interpretation
    
+FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
    
+
    
+David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and
    
+Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
    
+
    
+Kevin Layer and Rich Robbins have spoken in favor of an alternative proposal, to
    
+test for the remaining arguments.
    
+
    
+Historical note: Steele first implemented this "feature", in Zetalisp, and so
    
+the code in Symbolics Common Lisp is likely a direct descendant of the original
    
+code.  This might cause some to give weight to Steele's opinion. There are two
    
+arguments against such credence.  First, there is no reason why the original
    
+code should be regarded as part of the specification of Common Lisp any more
    
+than any other implementation; plainly, Steele botched the specification when he
    
+wrote the book.  Second, a professor of literature (I believe) once told Isaac
    
+Asimov concerning a short story of his (I quote from memory): "Tell me, Dr.
    
+Asimov, just because you wrote the story, what makes you think you know what it
    
+means?"
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166.htm new file mode 100644 index 00000000..a6a6e06e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue FORMAT-COMMA-INTERVAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-COMMA-INTERVAL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FORMAT-COMMA-INTERVAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166_w.htm new file mode 100644 index 00000000..3bf8428f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss166_w.htm @@ -0,0 +1,113 @@ + + + +CLHS: Issue FORMAT-COMMA-INTERVAL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-COMMA-INTERVAL Writeup

    + +
    Issue:        FORMAT-COMMA-INTERVAL
    
+References:   FORMAT integer printing (p. 388-9)
    
+Category:     ADDITION
    
+Edit history: Version 1, Pavel, 10-Jun-87
    
+              Version 2, Masinter, 15-Jun-87
    
+
    
+Problem description:  
    
+
    
+There are times when users would like to print out numbers with some punctuation
    
+between groups of digits.  The "commachar" argument to the ~D, ~B, ~O, ~X, and
    
+~R FORMAT directives was introduced to fill that need.  Unfortunately, the
    
+interval at which the commachar should be printed is always every three digits.
    
+This constraint is annoying when a different interval would be more appropriate.
    
+
    
+Proposal (FORMAT-COMMA-INTERVAL:YES):
    
+
    
+Add a fourth argument to the ~D, ~B, ~X, and ~O FORMAT directives, and a fifth
    
+argument to the ~R directive, to be called the "comma-interval".  This value
    
+must be an integer and defaults to 3.  When the : modifier is given to any of
    
+these directives, the "commachar" is printed between groups of "comma-interval"
    
+digits.
    
+
    
+Test Cases:
    
+
    
+Under the proposal, the following forms return the indicated values:
    
+	(format nil "~,,' ,4:B" 13) => "1101"
    
+	(format nil "~,,' ,4:B" 17) => "1 0001"
    
+	(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
    
+	(format nil "~3,,,' ,2:R" 17) => "1 22"
    
+	(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
    
+
    
+Rationale: 
    
+
    
+The current specification of FORMAT gives the user control over almost all of
    
+the facets of printing integers.  Only the wired-in constant for the
    
+comma-interval remains, even though there are uses for varying that number.  For
    
+example, in many contexts, it would be convenient to be able to print out
    
+numbers in binary with a space between each group of four bits.  FORMAT does not
    
+currently allow specification of the commachar printing interval so users
    
+needing this functionality must write it themselves, duplicating much of the
    
+logic in every implementation's integer printing code.  Other uses, requiring
    
+other intervals, can be imagined.  For example, using a "commachar" of #\Newline
    
+and a "comma-interval" of, say, 72, very large bignums could be printed in such
    
+a way as to ensure line-breaks at appropriate places.
    
+
    
+Current practice:
    
+
    
+No released implementations currently support this feature.
    
+
    
+Cost to implementors: 
    
+
    
+The change in the implementation of FORMAT is reasonably minor and, in most
    
+cases, highly localized.  Usually, the change is as simple as taking an extra
    
+parameter and using it instead of a wired-in value of 3.
    
+
    
+Cost to users:
    
+
    
+Since the proposal involves the addition of an argument to certain directives,
    
+the change would be entirely upward-compatible. No user code would need to be
    
+converted.
    
+
    
+Cost of non-adoption: 
    
+
    
+Users desiring this functionality will have to write it themselves, duplicating
    
+much of the logic involved in printing integers at all.
    
+
    
+Benefits: 
    
+
    
+One of the few remaining inflexibilities in integer printing is eliminated with
    
+a net increase in user-visible functionality.
    
+
    
+Esthetics: 
    
+
    
+By parameterizing one of the final pieces of wired-in behavior from integer
    
+printing, this small part of the workings of FORMAT would be perceived as having
    
+been cleaned up.
    
+
    
+Discussion: 
    
+
    
+Several members of the cleanup committee endorsed this proposal. No objections
    
+were raised.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167.htm new file mode 100644 index 00000000..5b025b3a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FORMAT-E-EXPONENT-SIGN:FORCE-SIGN Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-E-EXPONENT-SIGN:FORCE-SIGN Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FORMAT-E-EXPONENT-SIGN:FORCE-SIGN:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167_w.htm new file mode 100644 index 00000000..ed5b3e16 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss167_w.htm @@ -0,0 +1,128 @@ + + + +CLHS: Issue FORMAT-E-EXPONENT-SIGN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-E-EXPONENT-SIGN Writeup

    + +
    Status:	Passed, Jan 89 X3J13
    
+Forum:         Cleanup
    
+Issue:         FORMAT-E-EXPONENT-SIGN
    
+
    
+References:    CLtL pp. 366, 393
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  Bob Cassels, 13 Sep 88
    
+			Masinter,  2-Oct-88 (change issue name)
    
+
    
+Problem description:
    
+
    
+    The result of (format nil "~E" 1.0) is specified in a contradictory way.
    
+    The ambiguity is whether a plus sign should be printed in front of
    
+    the exponent.
    
+    
    
+    The top of page 393 says, "Next, either a plus or a minus sign is
    
+    printed, followed by e digits ... [decimal exponent]"
    
+    
    
+    Later on page 393 we see, "If all of w, d, and e are omitted, then the
    
+    effect is ... [like prin1].
    
+    
    
+    Page 366 [presumably where prin1 is defined] doesn't explicitly say that
    
+    the plus sign is omitted from the exponent, but all the examples (and
    
+    usual practice) indicate that.
    
+    
    
+    So the posssibilities are:
    
+
    
+	A. "1.0e+0"
    
+	B. "1.0e0"
    
+    
    
+    The first reference implies that A is correct, the third reference
    
+    implies that B is correct.  The second reference implies that A and B
    
+    are the same.
    
+
    
+Proposal (FORMAT-E-EXPONENT-SIGN:FORCE-SIGN):
    
+
    
+    Specify that ~E always prints a plus or minus sign in front of the
    
+    exponent.
    
+
    
+ This would cause the language on page 393 of CLtL to to change:
    
+
    
+    "If all of w, d, and e are omitted, then the effect is to print the
    
+    value using ordinary free-format exponential-notation output; PRIN1 uses
    
+    a similar format for any non-zero number whose magnitude is less than
    
+    10**-3 or greater than or equal to 10**7.  The only difference is that
    
+    the ~E directive always prints a plus or minus sign in front of the
    
+    exponent, while PRIN1 omits the plus sign if the exponent is
    
+    non-negative."
    
+
    
+Test Case:
    
+
    
+    (format nil "~E" 1.0) => "1.0e+0"
    
+
    
+Rationale:
    
+
    
+    This proposal makes ~E self-consistent.  That is more important than
    
+    making ~E consistent with PRIN1.
    
+
    
+Current practice:
    
+
    
+    Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
    
+    sign as in the test case above.  Apollo DOMAIN Common Lisp (version
    
+    2.10) and Xerox Common Lisp produce "1.0", which is wrong because  
    
+   it includes no exponent at all.
    
+
    
+Adoption Cost:
    
+
    
+    Minimal changes to one printing routine for non-conforming
    
+    implementations.  (No change to the three implementations mentioned
    
+    above.)
    
+
    
+Cost of non-adoption:
    
+
    
+    Minor confusion and possible incompatibility among implementations.
    
+
    
+Benefits:
    
+
    
+    Less confusion, more compatibility.
    
+
    
+Conversion Cost:
    
+
    
+    Minimal.  It is doubtful that any user programs depend on this
    
+    obscure distinction.
    
+
    
+Esthetics:
    
+
    
+    A matter of opinion.
    
+
    
+Discussion:
    
+
    
+    Fortran ~E format requires a sign before the exponent, since the exponent
    
+    mark character may be dropped.  Since Common Lisp ~E always prints
    
+    the exponent marker, the exponent sign may be dropped in the case
    
+    that it would be a plus sign.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168.htm new file mode 100644 index 00000000..c3dc848c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FORMAT-OP-C Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-OP-C Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FORMAT-OP-C:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168_w.htm new file mode 100644 index 00000000..b4cf938f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss168_w.htm @@ -0,0 +1,130 @@ + + + +CLHS: Issue FORMAT-OP-C Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-OP-C Writeup

    + +
    Issue:        FORMAT-OP-C
    
+References:   WRITE-CHAR (p384), ~C (p389)
    
+Category:     CHANGE/CLARIFICATION
    
+Edit History: 23-Feb-87, Version 1 by Pitman
    
+              29-Apr-87, Versions 2,3 by Pitman
    
+               5-Jun-87, Version 4 by Masinter (copy-editing)
    
+              11-Jun-87, Version 5 release to X3J13
    
+					(remove confusing paragraph)
    
+
    
+Problem Description:
    
+
    
+CLtL is not adequately specific about the function of the format
    
+operation ~C. The description on p389 says that "~C prints the character
    
+in an implementation-dependent abbreviated format. This format should be
    
+culturally compatible with the host environment." This description is
    
+not very useful in practice.
    
+
    
+Presumably the authors intended the `cultural compatibility' part to
    
+gloss issues like how the SAIL character set printed, but unfortunately
    
+another completely reasonable (albeit unplanned) interpretation arose:
    
+some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
    
+than " ".
    
+
    
+Since the behavior of ~A is also vague on characters (a separate
    
+proposal will address this), the only way to safely output a literal
    
+character is to WRITE-CHAR; currently, FORMAT does not suffice.
    
+
    
+Proposal (FORMAT-OP-C:WRITE-CHAR):
    
+
    
+Change the behavior of ~C to say that, when given a character with zero
    
+bits, it will perform the same action as WRITE-CHAR. (This proposal
    
+leaves the behavior of ~C with non-zero bits incompletely specified.)
    
+For example, the description of the ~C format directive on p389 of CLTL
    
+might read:
    
+
    
+  ~C prints the character using WRITE-CHAR if it has zero bits.
    
+  Characters with bits are not necessarily printed as WRITE-CHAR
    
+  would do, but are displayed in an implementation-dependent
    
+  abbreviated format that is culturally compatible with the host
    
+  environment.
    
+
    
+Test Case:
    
+
    
+(EQUAL (FORMAT NIL "~C" #\Space) " ")
    
+
    
+Rationale:
    
+
    
+This was probably the intent of the Common Lisp designers. 
    
+
    
+It makes things clear enough that programmers can know what to expect in
    
+the normal case (standard characters with zero bits).
    
+
    
+Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
    
+It seems as if the implementations which return "Space" treat ~C and ~:C
    
+equivalently or very similarly.
    
+
    
+Current Practice:
    
+
    
+Implementations are divided. Some implementations have
    
+     (FORMAT NIL "~C" #\Space) => "Space".
    
+Others have the same form return " ".
    
+
    
+Adoption Cost:
    
+
    
+Those implementations which did not already implement ~C as WRITE-CHAR
    
+would require an incompatible change.
    
+
    
+Benefits:
    
+
    
+User code that uses ~C would have a chance of being portable. As things
    
+stand, users who use ~C can't reliably port their code.
    
+
    
+~C and ~:C would perform usefully distinct operations.
    
+
    
+Conversion Cost:
    
+
    
+Standard ``Query Replace'' technology for finding occurrences of "~C"
    
+and changing them to "~:C" semi-automatically should suffice.
    
+
    
+Aesthetics:
    
+
    
+Making ~C do something well-defined will probably be perceived as a
    
+simplification.
    
+
    
+Discussion:
    
+
    
+The cleanup committee generally supports this clarification.
    
+
    
+The original version of this proposal (which tried to make WRITE-CHAR
    
+and ~C identical in all cases) prompted the following comment:
    
+
    
+"I believe the error in CLtL is that it was not stated explicitly that
    
+the `implementation-dependent abbreviated format' applies only to
    
+characters with non-zero char-bits. Thus instead of removing the
    
+mumbling about cultural compatibility, I suggest simply adding a
    
+sentence saying that ~C is the same as WRITE-CHAR for characters with
    
+zero char-bits.  I don't think we want to require ~C and write-char to
    
+do the same thing for characters with bits."
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169.htm new file mode 100644 index 00000000..09d5105e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169.htm @@ -0,0 +1,49 @@ + + + +CLHS: Issue FORMAT-PRETTY-PRINT:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-PRETTY-PRINT:YES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FORMAT-PRETTY-PRINT:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169_w.htm new file mode 100644 index 00000000..09fd2fa4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss169_w.htm @@ -0,0 +1,220 @@ + + + +CLHS: Issue FORMAT-PRETTY-PRINT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-PRETTY-PRINT Writeup

    + +
    See "Additional Discussion" at end.
    
+-----
    
+Issue:         FORMAT-PRETTY-PRINT
    
+References:    FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
    
+               WRITE (p. 382), *PRINT-PRETTY* (p. 371)
    
+Category:      CLARIFICATION
    
+Edit history:  Version 1 by Pierson 3/4/88
    
+    	       Version 2 by Pierson 5/24/88 (fix name typo)
    
+	       Version 3 by Pierson 6/10/88 incorporate comments
    
+	       Version 4 by Pierson 6/10/88 comments from Van Roggen
    
+	       Version 5 by Masinter  2-Oct-88
    
+               Version 6 by Pierson 11/10/88 final nits
    
+               Version 7 by Pierson 11/15/88 "does" => "does not"
    
+
    
+Problem description:
    
+
    
+The FORMAT operators, ~A and ~S are defined to print their argument as
    
+PRINC and PRIN1 respectively.  The text does not say whether or not
    
+these FORMAT operators must obey the *PRINT-PRETTY* flag.
    
+
    
+Proposal (FORMAT-PRETTY-PRINT:YES):
    
+
    
+Specify that FORMAT does not rebind any of the printer control
    
+variables (*PRINT-...) except as follows:
    
+
    
+~A
    
+    Binds *PRINT-ESCAPE* to NIL.
    
+
    
+~S
    
+    Binds *PRINT-ESCAPE* to T.
    
+
    
+~D
    
+    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    
+    *PRINT-BASE* to 10.
    
+
    
+~B
    
+    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    
+    *PRINT-BASE* to 2.
    
+
    
+~O
    
+    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    
+    *PRINT-BASE* to 8.
    
+
    
+~X
    
+    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    
+    *PRINT-BASE* to 16.
    
+
    
+~R
    
+    Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
    
+    *PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
    
+    argument.
    
+
    
+    Iff no aruments are specified, binds *PRINT-BASE* to 10.
    
+
    
+~@C
    
+    Binds *PRINT-ESCAPE* to T.
    
+
    
+~F,~G,~E,~$
    
+    Binds *PRINT-ESCAPE* to NIL.
    
+
    
+Test Cases/Examples:
    
+
    
+(LET ((TEST '#'(LAMBDA (X)
    
+		 (LET ((*PRINT-PRETTY* T))
    
+		   (PRINT X)
    
+		   (FORMAT T "~%~S " X)
    
+		   (TERPRI) (PRINC X) (PRINC " ")
    
+		   (FORMAT T "~%~A " X)))))
    
+  (FUNCALL (EVAL TEST) TEST))
    
+
    
+This should print four copies of the above lambda expression.  The
    
+first pair should appear identical and the second pair should appear
    
+identical.  The only difference between the two pairs should be the
    
+absence of string quotes in the second pair.
    
+
    
+Rationale:
    
+
    
+FORMAT should interact with the printer control variables in a
    
+predictable way.  This proposal is one of the two simplest possible
    
+definitions and provides the most flexibility to the user.
    
+
    
+A major advantage of this proposal is that the following two
    
+expressions are guaranteed to have exactly the same effect:
    
+
    
+    (FORMAT stream "~S" object)
    
+    (PRIN1 object stream)
    
+
    
+Thus use or non-use of FORMAT becomes a purely stylistic matter.
    
+
    
+Current practice:
    
+
    
+Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
    
+Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
    
+to NIL.
    
+
    
+Cost to Implementors:
    
+
    
+While changing FORMAT to not bind *PRINT-foo* variables is trivial,
    
+there are some painful implications.  How does a pretty-printing ~A
    
+interact with MINCOL, etc?  How much of the user interface depends on
    
+FORMAT in ways that might be uglified by pretty printing?
    
+
    
+Cost to Users:
    
+
    
+Truely portable code shouldn't be affected because existing
    
+implementations are inconsistent.  Despite this, there are probably a
    
+number of user programs in non-complying implementations which will
    
+have to change whichever way this is decided.
    
+
    
+Cost of non-Adoption:
    
+
    
+The interaction of FORMAT and the printer control variables (especially
    
+*PRINT-PRETTY*) will remain undefined.  This will continue to make
    
+portable Common Lisp programming harder than it need be.
    
+
    
+Benefits:
    
+
    
+Life will be easier for users in two ways: (1) one more portability
    
+problem will be removed, and (2) users will be more likely to be able
    
+to persuade environmental features like debuggers to print in their
    
+preferred way.
    
+
    
+Aesthetics:
    
+
    
+The interaction between two related parts of output will be clarified
    
+in a simple way.
    
+
    
+Discussion:
    
+
    
+It is important to specify exactly what of Common Lisp's special
    
+variables get rebound by other functions and macros in Common Lisp.
    
+This cleanup issue addresses the interaction of FORMAT and the
    
+*PRINT-  variables. There may be other similar interactions in 
    
+Common Lisp that need clarification.
    
+
    
+Otherwise, code that depends on FORMATs action in one implementation
    
+will not port to others that do not have the same behavior.
    
+
    
+CLtL might change as follows:
    
+
    
+Add a header "Printer Control Variables" before the description of
    
+*PRINT-ESCAPE* on page 370.
    
+
    
+Add the following paragraph to page 386 just before the paragraph
    
+starting with "It is an error":
    
+
    
+    "The FORMAT function by itself never binds any of the printer
    
+    control variables.  Specific FORMAT directives bind exactly the
    
+    printer control variables specified in their description.  While
    
+    implementations may specify the binding of new, implementation
    
+    specific printer control variables for each FORMAT directive, they
    
+    may neither bind any standard printer control variables not
    
+    specified in description of a FORMAT directive nor fail to bind
    
+    any standard printer control variables as specified in the
    
+    description."
    
+
    
+There was some discussion on whether *PRINT-BASE* should be bound for
    
+~F, ~G, ~E, and ~$.  This is not necessary because page 341 of CLtL
    
+states that floating point numbers are always printed in base 10.
    
+
    
+-----
    
+Additional Discussion:
    
+
    
+Date: Tue, 23 Jul 91 11:24:56 EDT
    
+From: Guy Steele <gls@Think.COM>
    
+To: KMP@STONY-BROOK.SCRC.Symbolics.COM
    
+Cc: Quinquevirate@MCC.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
    
+In-Reply-To: <19910712224013.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
    
+Subject: Hopefully just a typo in FORMAT-PRETTY-PRINT
    
+
    
+   Date: Fri, 12 Jul 1991 18:40-0400
    
+   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    
+
    
+   >From the proposal part of issue FORMAT-PRETTY-PRINT:YES ...
    
+
    
+   ==========
    
+     ~R
    
+	 Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
    
+	 *PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
    
+	 argument.
    
+
    
+	 Iff no arguments are specified, binds *PRINT-BASE* to 10.
    
+   ==========
    
+
    
+   I'm just going to assume that "parameter" was intended instead of
    
+   "argument" in all three cases.  If someone disagrees, they should say so.
    
+
    
+I believe your assumption is correct.
    
+--Guy
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170.htm new file mode 100644 index 00000000..653cc3fe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170.htm @@ -0,0 +1,56 @@ + + + +CLHS: Issue FORMAT-STRING-ARGUMENTS:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FORMAT-STRING-ARGUMENTS:SPECIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FORMAT-STRING-ARGUMENTS:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170_w.htm new file mode 100644 index 00000000..38ee0e83 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss170_w.htm @@ -0,0 +1,177 @@ + + + +CLHS: Issue FORMAT-STRING-ARGUMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FORMAT-STRING-ARGUMENTS Writeup

    + +
    Issue:               FORMAT-STRING-ARGUMENTS
    
+References:          
    
+Related issues:      Issue PRETTY-PRINT-INTERFACE
    
+Category:            CLARIFICATION, CHANGE
    
+Edit history:        V1, 10 May 90, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+Issue PRETTY-PRINT-INTERFACE says that
    
+    The function FORMAT is extended so that it can accept a
    
+    function instead of a FORMAT string.  (This change is also made
    
+    in the other functions that accept FORMAT strings such as ERROR
    
+    and WARN.)
    
+
    
+The pretty printer proposal did not explicitly address whether
    
+this also affects the :FORMAT-STRING slot of simple-condition 
    
+objects, and whether any macros (as well as functions) specified 
    
+in the standard were affected by the change.
    
+
    
+Also, there is potential for confusion in using the terminology
    
+"format strings" to refer to objects that are now permitted to
    
+be either strings or functions.
    
+
    
+There are two proposals, SPECIFY and RETRACT.
    
+
    
+This is issue #1 from Loosemore's list.
    
+
    
+Proposal (FORMAT-STRING-ARGUMENTS:SPECIFY):
    
+
    
+  (1) Clarify that the following functions and macros which formerly were
    
+  specified to take format strings as arguments now accept either
    
+  a format string or a format function:
    
+
    
+  ASSERT (datum; treated like a string argument is now)
    
+  BREAK (format-string)
    
+  CERROR (both continue-format-string and datum arguments)
    
+  DEFINE-METHOD-COMBINATION (:DESCRIPTION argument)
    
+  ERROR (datum; treated like a string argument is now)
    
+  FORMAT (control-string)
    
+  INVALID-METHOD-ERROR  (format-string)
    
+  METHOD-COMBINATION-ERROR (format-string)
    
+  SIGNAL (datum; treated like a string argument is now)
    
+  WARN (datum; treated like a string argument is now)
    
+  WITH-SIMPLE-RESTART (format-string)
    
+  Y-OR-N-P (format-string)
    
+  YES-OR-NO-P (format-string)
    
+
    
+  (2) Clarify that the :FORMAT-STRING argument passed to MAKE-CONDITION
    
+  to construct a condition which is a subtype of SIMPLE-CONDITION
    
+  may be either a string or a function, and the accessor 
    
+  SIMPLE-CONDITION-FORMAT-STRING can return either a string or a function.
    
+
    
+  (3) Change the name of the :FORMAT-STRING argument to MAKE-CONDITION 
    
+  associated with SIMPLE-CONDITION types to :FORMAT-CONTROL, and
    
+  rename the accessor function to SIMPLE-CONDITION-FORMAT-CONTROL.  As
    
+  an editorial matter, change all references to arguments now
    
+  named "format-string" to "format-control".
    
+
    
+  Rationale for proposal SPECIFY:
    
+
    
+  Items (1) and (2) were probably what was intended by the
    
+  PRETTY-PRINT-INTERFACE proposal.  Item (3) is a logical
    
+  extension; since the arguments need not be strings, calling
    
+  them "format-strings" is a misnomer.
    
+
    
+
    
+Proposal (FORMAT-STRING-ARGUMENTS:RETRACT):
    
+
    
+  (1) Retract the part of issue PRETTY-PRINT-INTERFACE that required
    
+  FORMAT, related functions such as ERROR and WARN, and the ~?
    
+  and ~{~} directives to accept format control functions as well
    
+  as strings.
    
+
    
+  (2) Remove the FORMATTER macro from the language.
    
+
    
+  Rationale for proposal RETRACT:
    
+
    
+  It is easier to remove this feature than to try to fix the rest
    
+  of the language to be consistent with it.  Having a macro to
    
+  "compile" format strings into functions is probably not useful
    
+  in the absence of the extensions to FORMAT.
    
+  
    
+
    
+Current Practice:
    
+
    
+  Unknown.  The pretty printer specification is a fairly recent
    
+  addition to the language and it probably hasn't been fully
    
+  integrated into any implementation yet.
    
+
    
+Cost to Implementors:
    
+
    
+  The actual implementation cost of extending the listed functions 
    
+  and macros to accept function arguments is probably small, since
    
+  in most cases they just pass the argument to FORMAT anyway.
    
+  Both proposals probably involve changes to documentation.
    
+  
    
+Cost to Users:
    
+
    
+  For proposal SPECIFY, the incompatible change to the name of the 
    
+  :FORMAT-STRING slot of SIMPLE-CONDITION objects may cause some 
    
+  problems for users who have started using the condition system
    
+  in their code, but these ought to be fairly straightforward to 
    
+  track down and fix.
    
+
    
+  Proposal RETRACT may cause some problems for users who have
    
+  started writing code which uses the FORMATTER macro and the
    
+  extension to FORMAT to accept functions, but again the
    
+  problems should generally be easy to find and fix.
    
+  
    
+Cost of non-adoption:
    
+
    
+  Parts of the language are poorly specified.
    
+
    
+Performance impact:
    
+
    
+  The ability to "compile" format strings into functions in advance can
    
+  potentially lead to greater runtime efficiency.  On the other
    
+  hand, some implementations might implement FORMATTER in such a
    
+  way that it is less efficient than passing a format string
    
+  directly.  Furthermore, even without FORMATTER in the language,
    
+  it is still possible for implementations to do a compile-time
    
+  transformation to "compile" constant string arguments to FORMAT
    
+  and related functions.
    
+
    
+Benefits:
    
+
    
+  The language is better specified.
    
+
    
+Esthetics:
    
+
    
+  Either proposal would be an improvement over the current
    
+  situation.
    
+
    
+Discussion:
    
+
    
+  Conceivably, the FORMATTER macro could be left in the language
    
+  even while removing the extensions to FORMAT and friends, but it's 
    
+  not clear how useful this would be to users.
    
+
    
+  Loosemore opposes other partial solutions (like requiring FORMAT 
    
+  to accept both strings and functions but specifying everything else 
    
+  to accept only strings) on the grounds that they would
    
+  introduce additional, unnecessary complexity and inconsistency
    
+  into the language.  If the feeling is that this feature belongs
    
+  in the language, we ought to bite the bullet and do it
    
+  properly.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171.htm new file mode 100644 index 00000000..86da6750 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171_w.htm new file mode 100644 index 00000000..4d40107d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss171_w.htm @@ -0,0 +1,124 @@ + + + +CLHS: Issue FUNCTION-CALL-EVALUATION-ORDER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-CALL-EVALUATION-ORDER Writeup

    + +
    Status:       passed v2 on 15-0 vote, Jun-90
    
+Issue:        FUNCTION-CALL-EVALUATION-ORDER
    
+
    
+References:   CLtL p 194 ("...that order is always left to right")
    
+              ANSI CL spec (Aug 29, 1989 draft) p.4-10 3rd paragraph
    
+
    
+Category:     CLARIFICATION
    
+
    
+Edit history: Version 1 by Clinger (22 March 1988)
    
+              Version 2 by Moon (1 Feb 90), add MORE-UNSPECIFIED
    
+
    
+Problem Description:
    
+
    
+  CLtL does not say whether the function expression of a call is evaluated
    
+  before or after the argument expressions.
    
+
    
+  This is Symbolics issue #4.
    
+
    
+Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):
    
+
    
+  Common Lisp does not specify whether the function expression of a call is
    
+  evaluated before or after the argument expressions.  Programs that rely
    
+  on a particular order of evaluation are in error.
    
+
    
+  The above proposal was accepted in October 1988.  The following proposal
    
+  is new in version 2.
    
+
    
+Proposal (FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED):
    
+
    
+  Common Lisp does not specify whether the function expression of a call is
    
+  evaluated before the argument expressions, after the argument
    
+  expressions, or between any two argument expressions if there is more
    
+  than one argument.  Programs that rely on a particular order of
    
+  evaluation are in error.
    
+
    
+Example:
    
+
    
+  (defun foo (x) (+ x 3))
    
+  (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
    
+  (foo (progn (bar) 20))
    
+  ; may return 23 or 24
    
+
    
+  (defun foo2 (x y) (+ x y))
    
+  (defun bar2 () (setf (symbol-function 'foo2) #'(lambda (x y) (* x y))))
    
+  (defun bar3 () (setf (symbol-function 'foo2) #'(lambda (x y) (- x y))))
    
+  (foo2 (progn (bar2) 6) (progn (bar3) 7))
    
+  ; under UNSPECIFIED, may return 13 or -1
    
+  ; under MORE-UNSPECIFIED, may return 13, -1, or 42
    
+
    
+Rationale:
    
+
    
+  UNSPECIFIED makes the status quo explicit.
    
+
    
+  MORE-UNSPECIFIED allows complete freedom to the implementation; as long
    
+  as we are not going to require all implementations to be consistent, it
    
+  seems useless to impose half a restriction on the implementation.  Some
    
+  RISC machines with delayed branches would prefer to evaluate the function
    
+  between evaluating the penultimate argument and the last argument in
    
+  some situations.
    
+
    
+Current Practice:
    
+  
    
+  TI and Symbolics used to evaluate the function expression last.
    
+  Symbolics currently evaluates the function expression either first or
    
+  last depending on the hardware and whether the code is compiled or
    
+  interpreted.  I'm not sure if TI has changed in the past two years.
    
+  Lucid and Coral sometimes evaluate the function expression first and at
    
+  other times evaluate the function expression last.
    
+
    
+Cost to implementors:
    
+
    
+  None.
    
+
    
+Cost to users:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Codifies an ambiguity.
    
+
    
+Aesthetics:
    
+  
    
+  Since Common Lisp evaluates argument expressions from left to right, it
    
+  would be more consistent for the function expression to be evaluated
    
+  before the argument expressions.  On the other hand, the evaluation rules
    
+  for function expressions are already quite different from the rules for
    
+  argument expressions, and nobody in their right mind would write code
    
+  that depends on the order of evaluation, so aesthetics should not count
    
+  for much in this case.  Requiring left to right evaluation would force
    
+  some implementations to consume an extra register for many function
    
+  calls.  The efficiency argument seems more important than the aesthetic
    
+  argument.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172.htm new file mode 100644 index 00000000..c9674985 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue FUNCTION-COMPOSITION:JAN89-X3J13 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-COMPOSITION:JAN89-X3J13 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FUNCTION-COMPOSITION:JAN89-X3J13:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172_w.htm new file mode 100644 index 00000000..d96a2fc0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss172_w.htm @@ -0,0 +1,129 @@ + + + +CLHS: Issue FUNCTION-COMPOSITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-COMPOSITION Writeup

    + +
    Status: Passed (as amended) Jan 89 X3J13
    
+(And reaffirmed Jun 89 X3J13 that this was the version wanted)
    
+
    
+Forum:          Cleanup
    
+Issue:          FUNCTION-COMPOSITION
    
+References:     None
    
+Category:       ADDITION
    
+Edit history:   21-Jun-88, Version 1 by Pitman
    
+                05-Oct-88, Version 2 by Pitman
    
+                 7-Dec-88, Version 3 by Masinter
    
+                12-Dec-88, Version 4 by Masinter (additional comments)
    
+		10-Feb-89, Version 5 (as amended by X3J13 Jan 89)
    
+Related-Issues: TEST-NOT-IF-NOT
    
+
    
+Problem Description:
    
+
    
+  A number of useful functions on functions are conspicuously
    
+  absent from Common Lisp's basic set. Among them are functions
    
+  which return constant T, constant NIL, and functions which
    
+  combine functions in common, interesting ways.
    
+
    
+Proposal (FUNCTION-COMPOSITION:JAN89-X3J13):
    
+
    
+  Add the following functions:
    
+
    
+   COMPLEMENT function					[Function]
    
+
    
+    Returns a function whose value is the same as the NOT of the
    
+    given function applied to the same arguments.
    
+
    
+   CONSTANTLY value						[Function]
    
+
    
+    Returns a function whose value is always VALUE.
    
+
    
+Examples:
    
+
    
+  (MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
    
+  ==
    
+  (MAPCAR (CONSTANTLY T) '(3 A 4.3))
    
+  => (T T T)
    
+
    
+  (FIND-IF-NOT #'ZEROP '(0 0 3))
    
+  ==
    
+  (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
    
+  => 3
    
+
    
+Rationale:
    
+
    
+  The presence of these functions will contribute to syntactic
    
+  conciseness in some cases. 
    
+
    
+Current Practice:
    
+
    
+  No Common Lisp implementations provide these functions,
    
+  but they do exist in the T language.
    
+
    
+Cost to Implementors:
    
+
    
+  A straightforward implementation is simple to cook up. The definitions
    
+  given here would suffice. Typically some additional work might be
    
+  desirable to make these open code in interesting ways.
    
+
    
+  (DEFUN COMPLEMENT (FUNCTION)
    
+    #'(LAMBDA (&REST ARGUMENTS)
    
+        (NOT (APPLY FUNCTION ARGUMENTS))))
    
+
    
+  (DEFUN CONSTANTLY (VALUE)
    
+    #'(LAMBDA (&REST ARGUMENTS) 
    
+        (DECLARE (IGNORE ARGUMENTS))
    
+        VALUE))
    
+
    
+Cost to Users:
    
+
    
+  None. This change is upward compatible.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  (COMPLEMENT BENEFITS)
    
+
    
+Benefits:
    
+
    
+  Some code would be more clear. 
    
+  Some compilers might be able to produce better code.
    
+
    
+  Takes a step toward being able to flush the -IF-NOT functions
    
+  and the :TEST-NOT keywords, both of which are high on the list
    
+  of what people are referring to when they say Common Lisp is
    
+  bloated by too much garbage.
    
+
    
+Aesthetics:
    
+
    
+  In situations where these could be used straightforwardly, the
    
+  alternatives are far less perspicuous.
    
+
    
+Discussion:
    
+
    
+  Several additional functions (COMPOSE, CONJOIN) were
    
+ considered and rejected at the Jan 89 X3J13 meeting.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173.htm new file mode 100644 index 00000000..a9effcfb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FUNCTION-DEFINITION:JAN89-X3J13 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-DEFINITION:JAN89-X3J13 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FUNCTION-DEFINITION:JAN89-X3J13:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173_w.htm new file mode 100644 index 00000000..4b1b6656 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss173_w.htm @@ -0,0 +1,162 @@ + + + +CLHS: Issue FUNCTION-DEFINITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-DEFINITION Writeup

    + +
    Issue:        FUNCTION-DEFINITION
    
+References:   Issue FUNCTION-TYPE
    
+Category:     ADDITION
    
+Edit history: 23-Jun-88, Version 1 by Pitman
    
+              09-Dec-88, Version 2 by GZ (change name, remove REQUIRED
    
+                     option, specify first value to be a lambda, add to
    
+	             discussion and current practice)
    
+		10-Feb-89, Version 3, as amended Jan 89 X3J13
    
+
    
+Problem Description:
    
+
    
+  There are portable ways to turn symbols and lists into functions,
    
+  but there are no portable ways to get back the original symbols and
    
+  lists given the functions.
    
+
    
+  In many cases, it used to be possible to recover the lambda expression
    
+  after a DEFUN by using FUNCTION or SYMBOL-FUNCTION, but the passage of
    
+  FUNCTION-TYPE will make this no longer be the case.
    
+
    
+Proposal (FUNCTION-DEFINITION:JAN89-X3J13):
    
+
    
+  Introduce a new function called FUNCTION-LAMBDA-EXPRESSION
    
+  which takes as its argument a function and returns three values:
    
+   #1: The function's defining lambda expression, or NIL if the information
    
+       is not available.  The lambda expression may have been pre-processed
    
+       in some ways, but it should remain a suitable argument to COMPILE
    
+       or FUNCTION.
    
+   #2: NIL if the definition was enclosed in the null lexical
    
+       environment or something non-NIL if the definition might
    
+       have been enclosed in some non-null lexical environment.
    
+   #3: the `name' of this function. The name is intended for debugging
    
+       only and may be any lisp object -- not necessarily one that would
    
+       be valid for use as a name in DEFUN or FUNCTION, for example.
    
+       By convention, NIL is used to mean that the function had no name.
    
+
    
+  Implementations are free to always return NIL T NIL, but are encouraged
    
+  to return the lambda expression in the case where the argument was created
    
+  by an in-core call to COMPILE or EVAL (as opposed to being created by
    
+  loading a compiled file).
    
+
    
+Examples:
    
+  
    
+    The following examples illustrate some possible return values, but
    
+    are not intended to be exhaustive:
    
+  
    
+    #1:    (FUNCTION-LAMBDA-EXPRESSION #'(LAMBDA (X) X))
    
+	or (FUNCTION-LAMBDA-EXPRESSION
    
+		(FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
    
+	might return NIL, NIL, NIL
    
+		  or (LAMBDA (X) X), T, NIL
    
+		  or (LAMBDA (X) X), NIL, NIL
    
+
    
+    #2: (FUNCTION-LAMBDA-EXPRESSION 
    
+		(FUNCALL #'(LAMBDA (X) #'(LAMBDA () X)) NIL))
    
+	might return NIL, T, NIL
    
+		  or (LAMBDA () X), T, NIL
    
+	   but -not- (LAMBDA () X), NIL, NIL
    
+  
    
+    #3: (DEFUN FOO (X) X)
    
+	(SETF (SYMBOL-FUNCTION 'BAR) #'FOO)
    
+	(FUNCTION-LAMBDA-EXPRESSION #'BAR)
    
+	might return NIL, NIL, NIL
    
+		  or (LAMBDA (X) (BLOCK FOO X)), T, NIL
    
+		  or (LAMBDA (X) (BLOCK FOO X)), NIL, FOO
    
+		  or (SI::BLOCK-LAMBDA FOO (X) X), NIL, FOO
    
+
    
+    #4: (DEFUN FOO ()
    
+	  (FLET ((BAR (X) X))
    
+	    #'BAR))
    
+	(FUNCTION-LAMBDA-EXPRESSION (FOO))
    
+	might return NIL, T, NIL
    
+		  or (LAMBDA (X) (BLOCK BAR X)), T, NIL
    
+		  or (LAMBDA (X) (BLOCK BAR X)), T, (:INTERNAL FOO 0 BAR)
    
+		  or (LAMBDA (X) (BLOCK BAR X)), NIL, "BAR in FOO"
    
+  
    
+Rationale:
    
+  
    
+    This functionality would be useful to a pretty printer, debugger,
    
+    inspector, and other tools.
    
+  
    
+Cost to Implementors:
    
+  
    
+    The following implementation is technically legitimate, although many
    
+    implementations would want to provide something more useful:
    
+  
    
+     (DEFUN FUNCTION-LAMBDA-EXPRESSION (FUNCTION)
    
+       (CHECK-TYPE FUNCTION FUNCTION)
    
+       (VALUES NIL T NIL))
    
+
    
+Current Practice:
    
+
    
+  Many implementations record this information, but not all that do
    
+  publish an interface to extracting the information.  VAXLISP and
    
+  Lucid call it SOURCE-CODE.  Coral calls it UNCOMPILE-FUNCTION.
    
+  The language T has this operation and calls it DISCLOSE. It is the
    
+  conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
    
+  and is implemented as what CLOS would call a "generic function".
    
+
    
+Cost to Users:
    
+
    
+  None. The change is upward compatible.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Certain kinds of portable debugging tools would be harder to write.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  The phrase ``program is data; data is program'' comes up a lot in discussions
    
+  about Lisp. This makes the case for ``program is data'' more interesting.
    
+
    
+Discussion:
    
+
    
+  The initial name proposed for this function was FUNCTION-DEFINITION.  This
    
+  was changed because of technical uses of the term ``definition'' to refer
    
+  to the entire defining form (e.g. a DEFUN form) rather than the lambda
    
+  expression that might be recovered from it.
    
+
    
+  The possibility of _requiring_ the lambda expression to be available for
    
+  all functions created by in-core calls to COMPILE or FUNCTION was considered
    
+  but didn't receive much support.  Pitman would prefer that option because
    
+  it is considerably more useful in practice, but would like to see at least
    
+  the current proposal.
    
+
    
+  Jan 89 X3J13 amended the proposal of Version 2 to change the name
    
+  from FUNCTION-SOURCE to FUNCTION-LAMBDA-EXPRESSION.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174.htm new file mode 100644 index 00000000..bacc4f76 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174.htm @@ -0,0 +1,53 @@ + + + +CLHS: Issue FUNCTION-NAME:LARGE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-NAME:LARGE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FUNCTION-NAME:LARGE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174_w.htm new file mode 100644 index 00000000..03fa6006 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss174_w.htm @@ -0,0 +1,559 @@ + + + +CLHS: Issue FUNCTION-NAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-NAME Writeup

    + +
    Status: Proposal LARGE, with sections 7, 8, 9 removed, passed Mar 89 X3J13
    
+
    
+Issue:         FUNCTION-NAME
    
+
    
+References:    SETF rules for what -place- can be (pp.94-7)
    
+               FBOUNDP function (p.90)
    
+               FMAKUNBOUND function (p.92)
    
+               FUNCTION special form (p.87)
    
+               SYMBOL-FUNCTION and setf of symbol-function (p.90)
    
+               88-002R pages 1-21, 2-21, 2-26, 2-39, 2-44, 2-46, 2-51, and 2-55
    
+               (There are additional references for the MEDIUM and LARGE
    
+                proposals, but they are not listed here.  They're obvious.)
    
+
    
+Related issues: SETF-FUNCTION-VS-MACRO, SETF-PLACES (both subsumed by this)
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, 23-Jan-89, by Moon 
    
+                              (based on discussion at Jan X3J13 meeting)
    
+
    
+
    
+Problem description:
    
+
    
+The Common Lisp Object System needs a well-defined way to relate the name
    
+and arguments of a writer function to those of a reader function, because
    
+both functions can be generic and can have user-defined methods.  The way
    
+that was adopted into Common Lisp when X3J13 voted to accept document
    
+88-002R was to use a list (SETF reader) as the name of the writer function.
    
+
    
+Some changes to the non-object-oriented portion of Common Lisp are required
    
+in order to support this.
    
+
    
+This issue has three proposals.
    
+
    
+
    
+Proposal (FUNCTION-NAME:SMALL):
    
+          
    
+  Add a new concept "function-name" (called "function-specifier" in
    
+  88-002R).  A function-name is either a symbol or a 2-element list whose
    
+  first element is the symbol SETF and whose second element is a symbol.
    
+  Implementations are free to extend the syntax of function-names to
    
+  include lists beginning with additional symbols other than SETF.
    
+
    
+  Add a new function (FDEFINITION function-name), which returns the
    
+  current global function definition named by function-name, or signals
    
+  an error if there is no global function definition.  This follows all
    
+  the same rules listed for SYMBOL-FUNCTION in CLtL p.90.
    
+
    
+  Add SETF of FDEFINITION to change the current global function definition
    
+  named by a function-name.  This follows all the same rules listed for
    
+  SETF of SYMBOL-FUNCTION in CLtL p.90.
    
+
    
+  Change the FBOUNDP and FMAKUNBOUND functions, and the FUNCTION special
    
+  form, to accept function-names in place of symbols.  Implementation
    
+  defined extensions to the syntax of function-names cannot use the
    
+  symbol LAMBDA, since FUNCTION already uses that symbol.
    
+
    
+  Change the rules for SETF places (CLtL pp.94-7) by adding the following
    
+  clause after all the existing clauses:
    
+
    
+   - Any other list whose first element is a symbol, call it reader.
    
+     In this case, SETF expands into a call to the function named by the
    
+     list (SETF reader).  The first argument is the new value and the
    
+     remaining arguments are the values of the remaining elements of
    
+     -place-.  This expansion occurs regardless of whether reader or
    
+     (SETF reader) is defined as a function locally, globally, or not at
    
+     all.  For example,
    
+         (SETF (reader arg1 arg2...) new-value)
    
+     expands into a form with the same effect and value as
    
+         (LET ((#:temp-1 arg1)          ;force correct order of evaluation
    
+               (#:temp-2 arg2)
    
+               ...
    
+               (#:temp-0 new-value))
    
+           (FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)).
    
+
    
+  Change the functions GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE
    
+  to implement the above change to the rules.
    
+         
    
+  Document that a function named (SETF reader) should return its first
    
+  argument as its only value, in order to preserve the semantics of SETF.
    
+
    
+  Change the macro DEFGENERIC and the function ENSURE-GENERIC-FUNCTION to
    
+  refer to the function FDEFINITION where they now refer to the function
    
+  SYMBOL-FUNCTION.
    
+
    
+  Change the macros DEFCLASS, DEFGENERIC, and DEFMETHOD, the special forms
    
+  GENERIC-FLET and GENERIC-LABELS, and the functions DOCUMENTATION and
    
+  ENSURE-GENERIC-FUNCTION to use the term "function-name" where they now
    
+  use the term "function-specifier" or "function specifier".
    
+
    
+
    
+Rationale for FUNCTION-NAME:SMALL:
    
+
    
+  This is the minimum change to Common Lisp needed to do what 88-002R says
    
+  about (SETF reader).  Giving implementations freedom to extend the syntax
    
+  of function-names allows for current practice.  Changing the name from
    
+  "function-specifier" to "function-name" avoids confusion and improves
    
+  consistency with the rest of the language, at the cost of a few small
    
+  changes to 88-002R.
    
+
    
+
    
+Proposal (FUNCTION-NAME:MEDIUM):
    
+
    
+  Everything in FUNCTION-NAME:SMALL, and in addition:
    
+
    
+  Change the DEFUN macro to accept a function-name for its name argument,
    
+  instead of only accepting a symbol.  If function-name is (SETF sym),
    
+  the body is surrounded by an implicit block named sym.
    
+
    
+
    
+Rationale for FUNCTION-NAME:MEDIUM:
    
+
    
+  Keeping DEFUN consistent with DEFMETHOD is a good idea.  Also 88-002R
    
+  says "The name of a generic function, like the name of an ordinary
    
+  function, can be either a symbol or a two-element list whose...", which
    
+  implies this change to DEFUN.
    
+
    
+
    
+Proposal (FUNCTION-NAME:LARGE):
    
+
    
+  Everything in FUNCTION-NAME:MEDIUM, and in addition the following
    
+  numbered points, each of which could be adopted independently,
    
+  except where explicitly noted:
    
+
    
+  1. Change the function COMPILE to accept a function-name as its name
    
+  argument.
    
+
    
+  2. Change the function DISASSEMBLE to accept a function-name as its name
    
+  argument.
    
+
    
+  3. Change the FTYPE, INLINE, and NOTINLINE declarations and proclamations
    
+  to accept function-names, not just symbols, as function names.
    
+
    
+  4. Change the FLET and LABELS special forms to accept a function-name in
    
+  the name position, not just a symbol.
    
+
    
+  5. Change the TRACE and UNTRACE macros to accept function-names, not just
    
+  symbols, in the function name positions.
    
+
    
+  6. Change the ED function to accept (ED function-name) in place of
    
+  (ED symbol).
    
+
    
+  7. Change the syntax of a function call to allow a function-name as the
    
+  first element of the list, rather than allowing only a symbol.
    
+
    
+  8. Change the DEFMACRO macro and the MACROLET special form to accept a
    
+  function-name in the name position, not just a symbol.  Change the
    
+  MACRO-FUNCTION function to accept function-names, not just symbols.
    
+  Change the last rule for SETF places to use
    
+    ((SETF reader) #:temp-0 #:temp-1 #:temp-2...)
    
+  in place of
    
+    (FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)
    
+  so that (SETF reader) can be defined as a macro.  This depends on item
    
+  7.  If item 4 is rejected, MACROLET should be stricken from this item.
    
+
    
+  9. Add an optional environment argument to FDEFINITION, SETF of
    
+  FDEFINITION, FBOUNDP, and FMAKUNBOUND.  This is the same as the
    
+  &environment argument to a macroexpander.  This argument can be used to
    
+  access local function definitions, to access function definitions in the
    
+  compile-time remote environment, and to modify function definitions in
    
+  the compile-time remote environment.
    
+
    
+  10. Change the second, third, fourth, fifth, seventh, and ninth rules for
    
+  SETF places so that they only apply when the function-name refers to the
    
+  global function definition, rather than a locally defined function or
    
+  macro.  (The ninth rule is the one that refers to DEFSETF and
    
+  DEFINE-SETF-METHOD; the other rules listed are the ones that list
    
+  specific built-in functions).  The effect of this change is that SETF
    
+  methods defined for global functions are ignored when there is a local
    
+  function binding; instead, the function named (SETF reader), which may
    
+  have a local function binding, is called.  This change is most useful
    
+  in connection with item 4, but does not actually depend on it.
    
+
    
+  11. Clarify that the eighth rule for SETF places (the one for macros)
    
+  uses MACROEXPAND-1, not MACROEXPAND.
    
+
    
+Rationale for FUNCTION-NAME:LARGE:
    
+
    
+  This extends the new feature throughout the language, in order to make
    
+  things generally more consistent and powerful.  Point by point:
    
+
    
+  1,2,3 - one should be able to compile, examine, and make declarations
    
+  about functions regardless of whether they are named with symbols or
    
+  with lists.
    
+
    
+  4 - locally defined non-generic SETF functions are a logical companion
    
+  to locally defined generic SETF functions, which can be defined with
    
+  GENERIC-FLET or GENERIC-LABELS.  They make sense on their own, since one
    
+  might define a local reader function and want a local writer function
    
+  to go with it.
    
+
    
+  5,6 - one should be able to apply development tools to functions
    
+  regardless of how they are named.  The function DOCUMENTATION was already
    
+  updated to work for function-names by 88-002R.  There might be some
    
+  difficulty with implementation-dependent syntax extensions to TRACE and
    
+  UNTRACE conflicting with this new syntax.
    
+
    
+  7 - this restores consistency between the FUNCTION special form and the
    
+  first element of a function call form.
    
+
    
+  8 - it seems more consistent to allow macros to be named the same way
    
+  that ordinary functions are named.  However, this might be considered
    
+  redundant with DEFSETF.
    
+
    
+  9 - this is not needed by the "chapter 1 and 2" level of CLOS, but might
    
+  be used by the metaobject based implementation of ENSURE-GENERIC-FUNCTION.
    
+
    
+  10 - this change was in SETF-FUNCTION-VS-MACRO and makes item 4 more useful.
    
+
    
+  11 - this change was in SETF-FUNCTION-VS-MACRO and is a good idea, but
    
+  actually is independent of everything else being proposed here.
    
+
    
+
    
+Examples:
    
+
    
+;This is an example of the sort of syntax 88-002R allows
    
+(defmethod (setf child) (new-value (parent some-class))
    
+  (setf (slot-value 'child parent) new-value)
    
+  (update-dependencies parent)
    
+  new-value)
    
+(setf (child foo) bar)
    
+
    
+;If SETF of SUBSEQ was not already built into Common Lisp,
    
+;it could have been defined like this, if the MEDIUM or LARGE
    
+;proposal is adopted.
    
+(defun (setf subseq) (new-value sequence start &optional end)
    
+  (unless end (setq end (length sequence)))
    
+  (setq end (min end (+ start (length new-value))))
    
+  (do ((i start (1+ i))
    
+       (j 0 (1+ j)))
    
+      ((= i end) new-value)
    
+    (setf (elt sequence i) (elt new-value j))))
    
+
    
+;The preceding example would have to be defined like this
    
+;if only the SMALL proposal is adopted.  This is a method
    
+;all of whose parameter specializer names are T.
    
+(defmethod (setf subseq) (new-value sequence start &optional end)
    
+  (unless end (setq end (length sequence)))
    
+  (setq end (min end (+ start (length new-value))))
    
+  (do ((i start (1+ i))
    
+       (j 0 (1+ j)))
    
+      ((= i end) new-value)
    
+    (setf (elt sequence i) (elt new-value j))))
    
+
    
+;Another example, showing a locally defined setf function
    
+(defun frobulate (mumble)
    
+  (let ((table (mumble-table mumble)))
    
+    (flet ((foo (x)
    
+             (gethash x table))
    
+           ((setf foo) (new x)
    
+             (setf (gethash x table) new)))
    
+      ..
    
+      (foo a)
    
+      ..
    
+      (setf (foo a) b))))
    
+
    
+;get-setf-method could implement setf functions by calling
    
+;this function when the earlier rules do not apply
    
+(defun get-setf-method-for-setf-function (form)
    
+  (let ((new-value (gensym))
    
+	(temp-vars (do ((a (cdr form) (cdr a))
    
+			(v nil (cons (gensym) v)))
    
+		       ((null a) v))))
    
+    (values temp-vars
    
+	    (cdr form)
    
+	    (list new-value)
    
+	    `(funcall #'(setf ,(car form)) ,new-value ,@temp-vars)
    
+	    `(,(car form) ,@temp-vars))))
    
+
    
+
    
+Current practice:
    
+
    
+  No implementation supports exactly what is proposed.  Symbolics Genera
    
+  and the TI Explorer support something close to the MEDIUM proposal, but
    
+  differing in a number of details.  Symbolics Genera supports items 1, 2,
    
+  3, 6, and 11, and modified forms of items 5 and 8, of the LARGE proposal.
    
+  Moon considers this proposal's variations from Symbolics current practice
    
+  to be an improvement, although incompatible in some cases.
    
+  
    
+  Many implementations currently support only symbols as function names.
    
+
    
+  Symbolics Genera and the TI Explorer have some additional function-name
    
+  syntaxes.
    
+
    
+Cost to Implementors:
    
+
    
+  The SMALL and MEDIUM proposals are estimated to be no more than 50 lines
    
+  of code and require no changes to the "guts" of the interpreter and
    
+  compiler.  Most of the code for this can be written portably and was
    
+  shown on two slides at the X3J13 meeting.
    
+
    
+  Some of the changes in the LARGE proposal are trivial, some require
    
+  the compiler to use EQUAL instead of EQ to compare function names, and
    
+  items 4, 7, and 8 might require a more substantial implementation
    
+  effort.  Even that effort is estimated to be negligible compared to
    
+  the effort required to implement CLOS.
    
+
    
+Cost to Users:
    
+
    
+  No cost to users, other than program-understanding programs, since this
    
+  is an upward compatible addition.
    
+
    
+  As with any language extension, some program-understanding programs may
    
+  need to be enhanced.  A particular issue here is programs that assume
    
+  that all function names are symbols.  They may use GET to access
    
+  properties of a function name or use EQ or EQL (perhaps via MEMBER or
    
+  ASSOC) to compare function names for equality.  Such programs will need
    
+  improvement before they can understand programs that use the new feature,
    
+  but otherwise they will still work.
    
+
    
+Cost of non-adoption:
    
+
    
+  We would have to make some other language change since the language
    
+  became inconsistent when 88-002R was adopted.
    
+
    
+Performance impact:
    
+
    
+  This has no effect on performance of compiled code.  It might slow
    
+  down the compiler and interpreter but not by very much.
    
+
    
+Benefits:
    
+
    
+  CLOS will work as designed.
    
+
    
+Esthetics:
    
+
    
+  Some people dislike using anything but symbols to name functions.
    
+  Other people would prefer that if the change is to be made at all,
    
+  the LARGE proposal be adopted so that the language is uniform in its
    
+  treatment of the new extended function names.  Other proposals for
    
+  how to deal with SETF in CLOS were considerably less esthetic,
    
+  especially when package problems are taken into account.
    
+  
    
+  SETF would be more esthetic, but less powerful, if it had only the
    
+  proposed setf functions and did not have setf macros.  Such a major
    
+  incompatible change is of course out of the question; however, if setf
    
+  functions are stressed over setf macros, SETF will be much easier to
    
+  teach.
    
+
    
+Discussion:
    
+
    
+  Moon supports at least FUNCTION-NAME:MEDIUM.  He does not necessarily
    
+  approve of all parts of FUNCTION-NAME:LARGE.
    
+
    
+
    
+!
    
+Additional Comments:
    
+
    
+On the whole, I like this presentation much better than either of the
    
+other two writeups that were circulated previously.  I suspect that it
    
+might be necessary to vote on each of the items in the LARGE proposal
    
+individually, though.  I think I would support items 1, 2, and 11, and
    
+don't have any particular objections to 3, 5, and 6.  For item 4, if
    
+consistency with GENERIC-FLET and GENERIC-LABELS is an object, another
    
+alternative is to change those two special forms to be like ordinary
    
+FLET and LABELS, instead of vice versa.
    
+
    
+- - - - - - -
    
+I support FUNCTION-NAME:MEDIUM and may support LARGE once I think about
    
+it some more.
    
+
    
+As I explained in Hawaii, support for either of these is based on the
    
+:conc-name bugs being removed from the condition system.  Of course, I
    
+believe the best way to do that is to CLOSify it.
    
+- - - - - - - - 
    
+I'm still thinking about this, but while I am I wanted point out that
    
+MEDIUM is unacceptable to me because I don't think FLET and DEFUN should
    
+disagree on what they permit as defined names. If FLET were added to
    
+MEDIUM, I suspect I'd think it was an internally consistent position.
    
+
    
+LARGE has an appeal to me in general, but I'm still mulling over 
    
+the specifics.
    
+- - - - - - - - - -
    
+I favor the FUNCTION-NAME:LARGE proposal, because it defines a single,
    
+useful notion of what a function name is.  The other proposals have
    
+the flaw that there are two kinds of function names:  symbols, and
    
+extended names, with only some of the Lisp primitives accepting the
    
+latter.  This may be convenient for some implementations, for the
    
+short term, but it fragments the language.
    
+
    
+I have two other comments on the proposal.
    
+
    
+
    
+A. Reducing the Cost to Implementors
    
+
    
+One observation you could put in the Cost To Implementors section is
    
+that none of the SMALL, MEDIUM, or LARGE proposals require changes to
    
+the "guts" of the interpreter and compiler.  This is because an
    
+implementation is free to use plain symbols internally to name
    
+functions, and use a hack like JonL's SETF:|3.FOO.BAR| mapping to
    
+convert non-symbol names to symbols.  This conversion would be done as a
    
+part of parsing the handful of forms which accept function names, and
    
+then all other passes of the interpreter and compiler (the "guts") would
    
+just see symbols.  (By "parsing" I mean ensuring the right number and
    
+type of syntactic subforms.  You can see that this is a very early and
    
+simple stage of processing.)  Or, Lisp compilers with an "alphatization"
    
+phase could perform function name symbolization at that phase.
    
+
    
+
    
+B. Finishing the Job of Regularization
    
+
    
+I'd like to suggest two additions to your smorgasbord of options in the
    
+FUNCTION-NAME:LARGE section of the proposal.  One addition would
    
+regularize a major special case of functions--lambda expressions.  The
    
+other addition would reaffirm an unstated regularity in the language,
    
+that function names can stand in for functions under FUNCALL and APPLY.
    
+Not only can the treatment of symbolic and setf-list function names be
    
+regularized, but lambda too can be treated in a consistent manner.
    
+
    
+If these two points are added to your proposal, the language as a whole
    
+would have a completely uniform treatment of functions and function
    
+names.  Here they are:
    
+
    
+13. Declare that any function name is a suitable argument to FUNCALL and
    
+    APPLY.  In such a case, the function name is passed to FDEFINITION,
    
+    and the result (which may in turn be a function name) is called.
    
+    That is, the following two expressions are equivalent, when fname
    
+    is a function name:
    
+	(FUNCALL fname x y)
    
+	  <==>
    
+	(FUNCALL (FDEFINITION fname) x y)
    
+    Note that the definition is sought in the global environment.
    
+    Compare with the rule which applies to a function name occurs,
    
+    syntactically, as the car of a list in code:
    
+	(fname x y)
    
+	  <==>
    
+	(FUNCALL (FUNCTION fname) x y)
    
+	  <==> (under proposal item 9)
    
+	(FUNCALL (FDEFINITION fname <local-environment>) x y)
    
+
    
+12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
    
+    whose cdr is a well-formed lambda argument list and body) is a function
    
+    name.  The effects of the function name accessors on lambda expressions
    
+    are as follows.  FDEFINITION returns an implementation-defined value which
    
+    is the function specified the lambda expression, closed in the global
    
+    environment.  This FDEFINITION value cannot be changed by SETF.
    
+    FBOUNDP always returns T, and MAKUNBOUND is an error.
    
+
    
+Esthetics:
    
+
    
+The effect of items 11 and 12 is to complete the regularization of
    
+Common Lisp's treatment of functions and function names.  The total
    
+effect of proposal items 1 through 12 is that Lisp has just two notions
    
+for referencing function objects: FUNCTIONS, which are Lisp objects that
    
+directly represent executable code, and FUNCTION NAMES, which can denote
    
+functions.  Symbols, SETF function names, and lambda expressions are all
    
+examples of the latter notion.  The former notion is highly
    
+implementation dependent.  Function names can occur as syntactic
    
+entities in code.  FUNCALL and APPLY work uniformly on both functions
    
+and function names, with a consistent semantics.
    
+
    
+Lambda expressions are often thought to denote "anonymous" functions, so
    
+it may seem paradoxical to treat them as names.  The paradox is only
    
+apparent, since the expression itself has the properties of a Lisp
    
+function name: It is (typically) a cons tree which can be read, printed,
    
+and stored in source files, and it denotes a well-defined Lisp function.
    
+
    
+Benefit to Users:
    
+
    
+Function names are useful for representing objects in remote
    
+environments, because they need not be bound at all times to the same
    
+function, or to any function, and because they are typically stable in
    
+meaning across reads and prints, where plain functions are not.
    
+Programs which deal simultaneously with remote and local environments,
    
+such as CLOS, can probably be simplified, since function names
    
+can be used uniformly, rather than an ad-hoc mixture of functions
    
+and function names.
    
+
    
+The language as a whole become more uniform from these additions and
    
+clarifications, making it easier to learn and use.  (See Esthetics.)
    
+
    
+Cost to Implementors:
    
+
    
+Interpreters which currently have a special case check for application
    
+of lambda expressions would need to modify this check to call
    
+FDEFINITION when a list of any sort is encountered.  Note that all
    
+Common Lisps already must perform some such check, since lambda
    
+expressions can be funcalled (and this is currently a very special case,
    
+the only standard case of a list being funcalled).  This means that
    
+every Lisp already has a place to insert the required call to
    
+FDEFINITION.
    
+
    
+In some implementations, FDEFINITION of a lambda expression could be that
    
+lambda-expression itself.  In others featuring a pre-eval codewalk, the
    
+walk would be done by FDEFINITION, which would return an appropriate
    
+closure.
    
+
    
+Cost of Non-adoption:
    
+
    
+Rather than two notions for function references (functions and function
    
+names), there would be several notions, each corresponding to the valid
    
+inputs for particular group of primitives.  APPLY and FUNCALL would
    
+accept functions, symbolic names, and lambda expressions, but not setf
    
+function names.  FDEFINITION and its kind would accept symbols and setf
    
+function names but not lambda expressions.  If the :LARGE proposal is
    
+not adopted, this fragmentation would also apply to the various syntaxes
    
+involving function names; some names would be acceptable to DEFUN
    
+but not to FLET, etc.
    
+
    
+- - - - - - - - - - - - -
    
+> 13. Declare that any function name is a suitable argument to FUNCALL and
    
+>     APPLY.  In such a case, the function name is passed to FDEFINITION,
    
+>     and the result (which may in turn be a function name) is called.
    
+
    
+I don't think this is such a good idea.  The case of automatically coercing
    
+a symbol to a function is needed because it provides a portable mechanism
    
+for indirect addressing of a function; I haven't seen a reason to need this
    
+for non-symbol function specs.  But more important is that coercing a
    
+symbol to a function is a trivial operation that is reasonable to do at
    
+run time on each call without adding a significant amount of overhead.
    
+FDEFINITION, on the other hand, is a much more expensive operation -- at
    
+best it might use GET to do a property list lookup, or it could be using
    
+string-append and INTERN to convert the name to a symbol.  In either case,
    
+I think this is more work than you want to do on each call.
    
+
    
+> 12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
    
+>     whose cdr is a well-formed lambda argument list and body) is a function
    
+>     name.  The effects of the function name accessors on lambda expressions
    
+>     are as follows.  FDEFINITION returns an implementation-defined value which
    
+>     is the function specified the lambda expression, closed in the global
    
+>     environment.  This FDEFINITION value cannot be changed by SETF.
    
+>     FBOUNDP always returns T, and MAKUNBOUND is an error.
    
+
    
+The exceptions for SETF and MAKUNBOUND show that this is not really as
    
+consistent as you might like.  Furthermore, the FUNCTION special form would
    
+have to treat a LAMBDA expression as a function, not a function name, in
    
+order for it to be lexically scoped.  It seems like this might just cause
    
+confusion rather than consistency.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175.htm new file mode 100644 index 00000000..3679685e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FUNCTION-TYPE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-TYPE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FUNCTION-TYPE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_m.htm new file mode 100644 index 00000000..04774d09 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue FUNCTION-TYPE Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue FUNCTION-TYPE Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_w.htm new file mode 100644 index 00000000..af38c214 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss175_w.htm @@ -0,0 +1,302 @@ + + + +CLHS: Issue FUNCTION-TYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-TYPE Writeup

    + +
    Issue:        FUNCTION-TYPE
    
+References:   functions (p32), types (p33), FUNCTIONP (p76),
    
+              SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
    
+Category:     CHANGE
    
+Edit History: 26-Feb-87, Version 1 by Gabriel
    
+              15-Mar-87, Version 2 by Cleanup Committee
    
+              10-May-87, Version 3 by Fahlman
    
+              29-May-87, Version 4 by Masinter (incorporate comments)
    
+              15-Jun-87, Version 5 by Fahlman (include two options)
    
+              23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
    
+              09-Nov-87, Version 7 by Masinter (minor cleanup)
    
+              14-Nov-87, Version 8 by Pitman (major restructuring)
    
+              13-Feb-88, Version 9 by Masinter, (add back 2nd option)
    
+              19-May-88, Version 10 by Masinter, (modify as per X3J13)
    
+              24-May-88, Version 11 by van Roggen
    
+                            (don't coerce lists, relax SYMBOL-FUNCTION reqs)
    
+		   4-Sep-88, Version 12 by Masinter
    
+		 	(incorporate amendments adopted at June 88 X3J13)
    
+
    
+Problem Description:
    
+
    
+ The definition of the term ``function'' in CLtL includes all symbols and
    
+ many lists in addition to `true' functions.
    
+
    
+ Also, page 47 of CLtL states that the FUNCTION type specifier can only
    
+ be used for declaration and not for discrimination. Some of the original
    
+ Common Lisp designers maintain that this restriction on the use of the
    
+ FUNCTION specifier was meant to apply only to long-form FUNCTION
    
+ specifiers, but since this intent was not explicitly stated, the status
    
+ of FUNCTION as a type is blurred. 
    
+
    
+ A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
    
+ be relied upon to be equivalent to (TYPEP x 'FUNCTION).
    
+
    
+Proposal FUNCTION-TYPE:X3J13-MARCH-88
    
+
    
+This proposal is basically the STRICT-REDEFINITION proposal of version 9
    
+of this issue, correcting a few typos, changing section 2E as
    
+agreed upon at X3J13 March 1988, allowing symbols but not lists to
    
+be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
    
+requirements.
    
+
    
+ 1.  Redefine the type FUNCTION so that it can be used for discrimination
    
+     as well as declaration.
    
+
    
+    1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
    
+        are pairwise disjoint.  In particular, a list may not be used
    
+        to implement any FUNCTION subtype.
    
+
    
+    1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
    
+        Implementations are free to define other subtypes of FUNCTION.
    
+
    
+ 2. Define that a ``function'' as used throughout the CLtL is restricted
    
+    to be exactly those objects of type FUNCTION.
    
+
    
+    2a. This type no longer includes objects of type SYMBOL or lists
    
+        whose CAR is LAMBDA.
    
+
    
+    2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
    
+        #'(LAMBDA (X) (TYPEP X 'FUNCTION)).  This is an incompatible
    
+        change.
    
+
    
+    2c. Clarify that the list form of the FUNCTION type specifier may
    
+        still only be used for declaration.
    
+
    
+    2d. Clarify that the symbol form of the FUNCTION type specifier may
    
+        be used for type discrimination.
    
+
    
+    2e. FUNCALL and APPLY and all Common Lisp functions that
    
+	take function arguments to also take a symbol, which will
    
+	be coerced to a function as if by SYMBOL-FUNCTION.
    
+
    
+    2f. This is an incompatible change in that it is an error to pass
    
+	  anything other than a function or symbol as the functional
    
+	  argument.
    
+
    
+ 3. Clarify that the result of a FUNCTION special form must be a function.
    
+
    
+    3a. This implies that some (FUNCTION name) may be implicitly interpreted
    
+	as (THE FUNCTION (FUNCTION name)). 
    
+
    
+ 4. Clarify that it is an error to use the special form FUNCTION on a
    
+    symbol that does not denote a function in the lexical environment in
    
+    which the special form appears. Specifically, it is an error to use the
    
+    FUNCTION special form on a symbol that denotes a macro or special form.
    
+    
    
+    4a. Some implementations may choose not to signal this error for
    
+        performance reasons, but implementations are forbidden from
    
+        defining the failure to signal an error as a `useful' behavior.
    
+
    
+ 5. Clarify that FBOUNDP must return true for a symbol naming a macro or
    
+    a special form, and that it is permissible to call SYMBOL-FUNCTION
    
+    on any symbol for which FBOUNDP returns true.
    
+
    
+    5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
    
+        but the symbol denotes a macro or special form is not well-defined,
    
+        but SYMBOL-FUNCTION will not signal an error. 
    
+
    
+    5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
    
+	It is an error to set the SYMBOL-FUNCTION of a symbol to a
    
+	symbol or a list or the value returned by SYMBOL-FUNCTION on
    
+	the name of a macro or a special form.
    
+
    
+    5c. The motivation for this distinction between FUNCTION and 
    
+	SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
    
+	use within programs while SYMBOL-FUNCTION is a data structure
    
+	accessor used primarily for meta-level applications and not
    
+	recommended for general use. It is provided primarily to
    
+	complete the set of accessors on symbols.
    
+
    
+ 6. COERCE is extended to allow objects to be coerced to type FUNCTION.
    
+
    
+    6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
    
+        given symbol, signalling an error if the symbol is not FBOUNDP or
    
+	if the symbol names a macro or a special-form.
    
+
    
+    6b. (COERCE x 'FUNCTION), where the value of x is a list that
    
+		 begins with LAMBDA, will return a FUNCTION similar to
    
+		 (EVAL '(FUNCTION ,x)).
    
+
    
+ 7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
    
+    function before being called as the expansion interface hook by
    
+    MACROEXPAND-1.
    
+
    
+Rationale:
    
+
    
+ The fuzzy definition of ``function'' has descended from older dialects of
    
+ Lisp, such as Maclisp. Many places in existing code make assumptions about
    
+ the current meaning, making any change painful.
    
+
    
+ It is very important both for documentation clarity and for program type
    
+ discrimination (such as CLOS) to have a clear term which denotes a 
    
+ ``true function.''
    
+
    
+ This proposal is a compromise between a CONSERVATIVE proposal (which left
    
+ FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
    
+ which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
    
+ but also the behavior of FUNCALL, APPLY and functions with functional
    
+ arguments.
    
+
    
+ For compatibility reasons symbols are still acceptable to FUNCALL et al.,
    
+ but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
    
+ and whose CADR is a list) are no longer acceptable.
    
+
    
+Current Practice:
    
+
    
+ In some implementations, (TYPEP x 'FUNCTION) signals an error.
    
+ In some implementations, (TYPEP x 'FUNCTION) is true for values
    
+   returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions. 
    
+ In some implementations, (TYPEP x 'FUNCTION) is true only for values
    
+   returned by FUNCTION.
    
+
    
+ Implementations vary on what my go into the function cell, depending on
    
+ how much error checking they want to have to do at function call time, and
    
+ depending on whether they store other kinds of information (such as special
    
+ form information) in the function cell.
    
+
    
+ Few current Common Lisp implementations have exactly the
    
+ semantics described in this proposal.
    
+
    
+Cost to Implementors:
    
+
    
+ Bringing type predicates (FUNCTIONP, etc.) and higher order functions
    
+ (APPLY, etc.) into compliance should require little effort in most
    
+ implementations.
    
+
    
+ Compiled functions are true functions in almost all current
    
+ implementations, but in many implementations, interpreted functions and
    
+ closures stored in the function cell of a symbol are represented as lists.
    
+ Under this proposal, this representation would have to be different
    
+ (implemented either as structures or as some special internal data type).
    
+ The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be 
    
+ modified to deal with functions that are not lists (but from which the
    
+ list form can be reconstructed if necessary).
    
+
    
+Cost to Users:
    
+
    
+ The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
    
+ to deal with. 
    
+
    
+ Because CLtL's language was somewhat fuzzy about what might go into the
    
+ function cell of a symbol, some code that explicitly deposited symbols
    
+ or lists in a symbol's function cell, or expected lists back, will
    
+ have to change. Such code was already not portable, however, since some
    
+ implementations signal an error when this is done.
    
+
    
+ The original STRICT-REDEFINITION proposal required users to deal with
    
+ the use of symbols and lambda-expressions as functional arguments.  However
    
+ this proposal is compatible with current CLtL definition in the use of
    
+ symbols, which would be the hardest change to make.  There are probably
    
+ relatively few uses of lambda-expressions as ``functions'', which can
    
+ be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
    
+
    
+Benefits:
    
+
    
+ The term ``function'' would be given a useful and precise meaning.
    
+ The FUNCTION datatype would be useful for type discrimination in CLOS.
    
+
    
+ The type hierarchy would be simplified.
    
+
    
+ This proposal brings Common Lisp slightly closer to Scheme and the
    
+ work of the EuLisp committee. Scheme, for example, also has the concept
    
+ of a ``procedure'' which is compatible with the FUNCTION type.
    
+
    
+
    
+Aesthetics:
    
+
    
+ This proposal improves the aesthetics of the language.
    
+
    
+ Lambda-expressions do not obey the normal, apparent scoping rules because
    
+ free variables cannot refer to lexical bindings.  This is because
    
+ coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
    
+
    
+ The following code does -not- count the number of nodes in a graph:
    
+
    
+  (LET ((COUNTER 0))
    
+    (TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
    
+                    (THING-ROOT)))
    
+
    
+ since it is not the same as
    
+
    
+  (LET ((COUNTER 0))
    
+    (TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
    
+                    (THING-ROOT)))
    
+
    
+ which does pass around a closure incrementing the LET variable.
    
+ (These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
    
+
    
+ Making the coercion of lambda-expressions to functions explicit with
    
+ the use of EVAL will encourage less confusing code and also highlight
    
+ that use of EVAL.
    
+
    
+
    
+Discussion:
    
+
    
+This issue has been discussed at great length; this section attempts
    
+only to summarize the important points.
    
+
    
+There is general agreement that the definition of the FUNCTION data type
    
+must be clarified or revised. The cleanup of the type hierarchy is important
    
+to the CLOS group.
    
+
    
+The description of COMPILE must be changed, since it is no longer
    
+meaningful to speak of a symbol with a definition that "is a
    
+lambda-expression".  We believe this is a subject for a separate
    
+proposal, as the behavior of COMPILE needs additional clarification.
    
+
    
+Many different alternatives have been discussed both in the cleanup committee
    
+and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
    
+this version is the result of discussions at that meeting. It is a compromise
    
+between the conflicting goals of backward compatibility, flexibility in the
    
+language, and simple semantics.
    
+ 
    
+This proposal does not address the issue of when coercion to functions occur.
    
+For example, it is allowed to write
    
+
    
+(MAPCAR 'FROB my-list)
    
+
    
+It is not specified when the coercion of FROB to its SYMBOL-FUNCTION 
    
+occurs. For example, 
    
+
    
+(DEFUN FROB (X) 
    
+   (WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
    
+   T)
    
+
    
+(MAPCAR 'FROB '(-1 -1 1 1))
    
+
    
+may return different results if MAPCAR coerces its functional argument
    
+once rather than for each element. This may require a separate
    
+cleanup issue.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176.htm new file mode 100644 index 00000000..55f4e2aa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176_w.htm new file mode 100644 index 00000000..9575c582 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss176_w.htm @@ -0,0 +1,192 @@ + + + +CLHS: Issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS Writeup

    + +
    Forum:        Cleanup
    
+Issue:        FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
    
+References:   CLtL pp 47-48, 158-159
    
+Category:     CHANGE
    
+Related-issues: DECLARE-TYPE-FREE
    
+Edit history: #1, 7 Sept 1988, Walter van Roggen
    
+              #2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
    
+              #3,  7-Dec-88, Masinter
    
+
    
+
    
+Problem description:
    
+
    
+The current description of the specialized FUNCTION type specifier is not very
    
+useful to program analysis tools and is not very intuitive to programmers
    
+because the meaning of the argument type specifiers is not restrictive.
    
+
    
+Programmers find it useful to add information about the types of the arguments
    
+a function expects and about the type(s) that a function may return. This
    
+information is useful both to human readers of the code as well as to type
    
+checking programs such as compilers and cross referencers. The only apparent
    
+way of providing this information is with the FTYPE declaration
    
+or the FUNCTION type specifier.
    
+
    
+Furthermore, implementations may wish to provide additional optimizations based
    
+on avoiding type checking or different methods of argument passing. These
    
+optimizations require the same sort of information about the argument types.
    
+
    
+However, the current definition of FUNCTION type specifiers on pages 47-48 of
    
+CLtL states that a function such as CONS that is of type
    
+  (FUNCTION (T T) CONS)
    
+is also of type
    
+  (FUNCTION (FLOAT STRING) LIST).
    
+
    
+The problem is that the argument types aren't restrictive, so no interesting
    
+matching of types is possible.
    
+
    
+Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
    
+
    
+This proposal is written as if DECLARE-TYPE-FREE (Version 6, 06-Oct-88)
    
+is in effect.
    
+
    
+Specify that a declaration of the form
    
+   
    
+    (ftype (function (arg0-type arg1-type ...) val-type) f))
    
+
    
+implies that any call of the form (f arg0 arg1 ...) within the scope of
    
+the declaration can be treated as if it were
    
+
    
+  (the val-type (f (the arg0-type arg0) (the arg1-type arg1) ...))
    
+
    
+That is, it is an error for any of the arguments not to be of the specified
    
+types or the result not to be of the specified type. (In particular,
    
+If any argument is not of the correct type,  the result is not guaranteed 
    
+to be of the specified type.)
    
+
    
+Thus, an FTYPE declaration for a function describes calls to the function,
    
+not the actual definition of the function. 
    
+
    
+Similarly, specify that a declaration of the form
    
+    (type (function (arg0-type arg1-type ...) val-type) fn-valued-variable)
    
+
    
+has the interpretation that, within the scope of the declaration, it
    
+is an error to call the value of fn-valued-variable with arguments
    
+not of the specified type; assert that the value resulting from a valid
    
+call will be of type val-type.
    
+
    
+As with variable type declarations (cf DECLARE-TYPE-FREE), nested declarations
    
+imply intersections of types, as follows:
    
+
    
+If two (or more) declarations of the form "ftype" are in effect,
    
+(ftype (function (arg0-type1 arg1-type1 ...) val-type1) f))
    
+and
    
+(ftype (function (arg0-type2 arg1-type2 ...) val-type2) f))
    
+
    
+then within the shared scope of the declarations, calls to f can be
    
+treated as if it were declared
    
+(ftype (function ((and arg0-type1 arg0-type2) (and arg1-type1 arg1-type2 ...) ...)
    
+                 (and val-type1 val-type2)) 
    
+       f))
    
+
    
+(It is legitimate to ignore one or all of the declarations in force.)
    
+
    
+
    
+If two (or more) type declarations are in effect for a variable, and
    
+they are both FUNCTION declarations, the declarations combine similarly.
    
+
    
+This proposal does not alter the status (or lack thereof) of other issues
    
+related to FUNCTION type specifiers: what lambda-list keywords mean, what the
    
+VALUES type means, what implications there are w.r.t. argument counts, doing
    
+multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
    
+proclamations, describing generic functions incrementally, the result of TYPEP
    
+with a specialized FUNCTION type, or the nesting and scoping rules for 
    
+FTYPE declarations.
    
+
    
+Example:
    
+
    
+  (DEFUN FFF (F)
    
+    (DECLARE (TYPE (FUNCTION (FLOAT STRING) LIST) F))
    
+    ... (FUNCALL F (FOO ...) ...) ... )
    
+
    
+then #'CONS is a valid argument to be passed to FFF because the declared
    
+type of the argument is consistent with type (FUNCTION (T T) CONS).
    
+Within FFF, the declaration permits us, for example, to assume that FOO
    
+returns a FLOAT. 
    
+
    
+Rationale:
    
+
    
+The proposal seems most like what users expect.
    
+
    
+Current Practice:
    
+
    
+VAX LISP assumes and makes use of the semantics different than CLtL
    
+but not exactly what is specified here. Lucid
    
+has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
    
+standard FTYPE declaration. Gold Hill intends to use these declarations in this
    
+manner.  Many implementations don't make use of these declarations.  At least
    
+several users make use of declarations assuming the new semantics.
    
+
    
+Cost to Implementors:
    
+
    
+Since most implementations don't make use of function declarations, and since
    
+those known to do so can be changed easily, the cost should be minimal.
    
+
    
+Cost to Users:
    
+
    
+There may be some existing "imprecise" function declarations.  However, the
    
+natural tendency when providing these declarations is to be as "descriptive"
    
+(i.e., restrictive but complete) as possible, both for documentation purposes
    
+as well as for potential compiler benefits. There cannot have been any uses of
    
+the specialized FUNCTION type for discrimination. Thus most existing uses are
    
+probably compatible with this new definition.
    
+
    
+Cost of Non-Adoption:
    
+
    
+There already exists user code on many implementations that assume the
    
+proposed semantics.  Not adopting this proposal would continue to render
    
+such code incorrect or at least non-portable.
    
+
    
+Benefits:
    
+
    
+Better type checking and more compiler optimizations should be possible.
    
+
    
+Esthetics:
    
+
    
+This is the what most programmers expect the specialized FUNCTION type to
    
+mean, particularly those coming from other languages.
    
+
    
+Discussion:
    
+
    
+A declaration of
    
+ (FUNCTION (FIXNUM FIXNUM) CONS)
    
+is a not proper global declaration for CONS if any program might
    
+call CONS with arguments that are not FIXNUM.
    
+
    
+The list form of the FUNCTION type specifier is different from most
    
+type specifiers because it cannot be used for discrimination.
    
+Thus, the notion of "subtype" does not make sense, since assertions
    
+about the functional value of a variable are only partially
    
+about the actual value of the variable and mainly about the
    
+values that might be passed to the variables (function) value.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177.htm new file mode 100644 index 00000000..502356fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177_w.htm new file mode 100644 index 00000000..7acf2eb9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss177_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue FUNCTION-TYPE-KEY-NAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-TYPE-KEY-NAME Writeup

    + +
    Issue:         FUNCTION-TYPE-KEY-NAME
    
+References:    CLtL p.47-48, 61
    
+Category:      CLARIFICATION, CHANGE
    
+Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
    
+               Version 2, 15-Jan-1988 Sandra Loosemore 
    
+	           (from comments by Kent Pitman)
    
+               Version 3, 13-Feb-88 Masinter
    
+Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT, 
    
+                KEYWORD-ARGUMENT-NAME-PACKAGE
    
+                FUNCTION-ARGUMENT-TYPE-SEMANTICS
    
+
    
+
    
+Problem description:
    
+
    
+The FUNCTION type specifier list is provided to allow declaration of function
    
+argument types and return value types.  This type specifier uses a syntax
    
+similar to the usual lambda list syntax to specify which types go with which
    
+lambda list variables.  However, there is a problem with &KEY lambda variables
    
+because CLtL does not specify how the types specified in the FUNCTION
    
+declaration are matched up to either the actual arguments passed to the
    
+function, or the lambda variables in the function definition (since the ordering
    
+of keyword arguments is arbitrary).
    
+
    
+Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
    
+
    
+(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list
    
+should be supplied as lists of the form (<keyword> <type>).  The <keyword> must
    
+be a valid keyword-name symbol as must be supplied in the actual arguments of a
    
+call. (This is usually a symbol in the keyword package, but, as per
    
+KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.) 
    
+
    
+(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list. 
    
+
    
+The interpretation of such declarations is that, when &KEY is given in a
    
+FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
    
+are exhaustive unless &ALLOW-OTHER-KEYS is present. 
    
+
    
+&ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
    
+supplied and, if supplied, may be used. 
    
+
    
+Example:
    
+
    
+The type of the function MAKE-LIST could be declared as:
    
+
    
+   (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
    
+
    
+Rationale:
    
+
    
+(1) This specifies a direct correspondence between the argument type and its
    
+matching keyword.  All of the information is in one place, and the user does not
    
+have to remember (or even know) the order in which &KEY arguments appear in the
    
+actual function definition.
    
+
    
+(2) This is probably an oversight in the original specification.
    
+
    
+Current practice:
    
+
    
+Many Common Lisp implementations currently ignore FUNCTION type declarations.
    
+The situation regarding type specifications for keyword arguments is so
    
+ambiguous that few users attempt to use them.
    
+
    
+Cost to Implementors:
    
+
    
+Implementations that ignore the FUNCTION type specifier or keyword arguments in
    
+a FUNCTION type specifier may continue to do so.  This proposal should not
    
+involve massive amounts of code to be rewritten.
    
+
    
+Cost to users:
    
+
    
+Because the current situation is so ambiguous, FUNCTION type specifiers and
    
+particularly the specification of keyword argument types are not widely used.
    
+However, since this is an incompatible change, it would be nice if
    
+implementations check for, and warn about, old-style usage.
    
+
    
+Cost of non-adoption:
    
+
    
+If nothing is done, the FUNCTION type specifier will continue to be of limited
    
+use for its intended purpose.
    
+
    
+Benefits:
    
+
    
+Adopting the proposal will clear up an area of confusion in the language design.
    
+
    
+Esthetics:
    
+
    
+The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
    
+lambda list syntax.
    
+
    
+Discussion:
    
+
    
+The exact semantics of function declarations and the types of arguments  is
    
+still under discussion, as are several other issues dealing with declarations.
    
+However, this issue seemed separable.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178.htm new file mode 100644 index 00000000..60e40fe8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178_w.htm new file mode 100644 index 00000000..faa8bc65 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss178_w.htm @@ -0,0 +1,148 @@ + + + +CLHS: Issue FUNCTION-TYPE-REST-LIST-ELEMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue FUNCTION-TYPE-REST-LIST-ELEMENT Writeup

    + +
    Forum:         Cleanup
    
+Issue:         FUNCTION-TYPE-REST-LIST-ELEMENT
    
+References:    CLtL p. 27, 47-48, 61
    
+               "Artifical Intelligence Programming", Charniak et. al.
    
+               X3J13/86-003 (A:>GLS>clarifications.text.4)
    
+Category:      CLARIFICATION, ADDITION
    
+Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
    
+               Version 2, 15-Jan-1988 Sandra Loosemore
    
+	           (incorporate comments from Scott Fahlman & others)
    
+               Version 3, 13-Feb-88 Masinter
    
+               Version 4,  2-Oct-88 Masinter (update references,
    
+								discussion)
    
+               Version 5, 14-Nov-88 Masinter (add to discussion)
    
+Related issues: FUNCTION-TYPE-KEY-NAME, 
    
+                FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
    
+                REST-LIST-ALLOCATION
    
+
    
+Problem description:
    
+
    
+The FUNCTION type specifier list is provided to allow declaration of
    
+function argument types and return value types.  This type specifier uses a
    
+syntax similar to the usual lambda list syntax to specify which types go
    
+with which lambda list variables.  However, this is actually of limited
    
+usefulness in the context of a declaration, where one normally wants type
    
+information about the actual arguments which can be passed to the function
    
+rather than the lambda variables to which they are bound.
    
+
    
+There is a particular problem with &REST lambda variables, which are always
    
+bound to a value of type LIST.  For the sake of consistency, it would seem
    
+that the corresponding type given in the FUNCTION declaration must also be
    
+LIST, but since this provides no information about the actual arguments,
    
+some users/implementors have instead adopted the convention of supplying
    
+the type of the actual arguments which are gathered into the list.  
    
+
    
+CLtL is vague on the issue, mentioning only that &REST may appear in the
    
+type specifier without touching upon its interpretation.
    
+
    
+Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
    
+
    
+Clarify that, in the FUNCTION type specifier, the type specifier provided
    
+with &REST is the type of each actual argument, not the type of the
    
+corresponding lambda variable.
    
+
    
+Example:
    
+
    
+The type of the function + would be specified as:
    
+
    
+(FUNCTION (&REST NUMBER) NUMBER)
    
+
    
+Rationale:
    
+
    
+This is more useful than specifying that the type of a &REST parameter must
    
+be LIST, since it provides information about the actual arguments.
    
+
    
+Current practice:
    
+
    
+There does not appear to be any concensus on this issue.  Most Common Lisp
    
+implementations currently ignore FUNCTION type declarations. The only
    
+examples found so far are in a text book on Common Lisp, which follows the
    
+proposed syntax.
    
+
    
+Cost to Implementors:
    
+
    
+Implementations that ignore the FUNCTION type specifier may continue to do
    
+so.  Probably only a small amount of code would have to be written/changed
    
+in implementations that currently think that the  &REST argument should be
    
+LIST.
    
+
    
+Cost to Users:
    
+
    
+Users who have been using the convention that the &REST type parameter must
    
+be LIST will have to change their code.  However, because this issue is so
    
+unclear, the FUNCTION type specifier is probably not used very much.
    
+
    
+Cost of non-adoption:
    
+
    
+If nothing is done, the FUNCTION type specifier will continue to be of
    
+limited use for its intended purpose.
    
+
    
+Benefits:
    
+
    
+Adopting the proposal will clear up an area of confusion in the language
    
+design.
    
+
    
+Esthetics:
    
+
    
+Debatable.  One the one hand, since the argument type syntax used by the
    
+FUNCTION type specifier mirrors normal lambda-list syntax, it would be
    
+cleaner and less confusing to provide the type of the lambda variable
    
+rather than the type of the actual arguments. However, considering the
    
+types specified in the FUNCTION specifier to be the types of the actual
    
+arguments rather than the types of the parameters as seen on the receiving
    
+end makes the proposed semantics more palatable.
    
+
    
+Discussion:
    
+
    
+This issue provoked considerable debate in the cleanup committee and at
    
+X3J13. 
    
+
    
+Many people objected to this proposal, and would prefer the alternative
    
+that the type given after a &REST in a function declaration apply to the
    
+value of the formal parameter rather than the actual arguments. This would
    
+be even more useful if complex LIST type specifiers were part of Common
    
+Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were
    
+possible to declare, for example, &REST {keyword integer}*.
    
+
    
+Some additional arguments against this proposal are the apparent mismatch
    
+between the external declarations of type and the internal ones. It might
    
+be that this proposals presumes that rest lists are always lists, and the
    
+following is illegal:
    
+
    
+ (DEFUN FOO (&REST X) X)
    
+ (APPLY #'FOO T)
    
+
    
+which is not otherwise explicitly forbidden, but for which there is no
    
+legitimate declaration.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss179.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss179.htm new file mode 100644 index 00000000..68b654fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss179.htm @@ -0,0 +1,49 @@ + + + +CLHS: Issue FUNCTION-TYPE:X3J13-MARCH-88 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue FUNCTION-TYPE:X3J13-MARCH-88 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue FUNCTION-TYPE:X3J13-MARCH-88:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180.htm new file mode 100644 index 00000000..f3024af7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180.htm @@ -0,0 +1,44 @@ + + + +CLHS: Issue GENERALIZE-PRETTY-PRINTER:UNIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue GENERALIZE-PRETTY-PRINTER:UNIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue GENERALIZE-PRETTY-PRINTER:UNIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180_w.htm new file mode 100644 index 00000000..58e69d17 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss180_w.htm @@ -0,0 +1,245 @@ + + + +CLHS: Issue GENERALIZE-PRETTY-PRINTER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue GENERALIZE-PRETTY-PRINTER Writeup

    + +
    Forum:		Public Review
    
+Issue:		GENERALIZE-PRETTY-PRINTER
    
+References:	Loosemore's public review comment #18 (X3J13/92-1318)
    
+		Section 22.2.1 (Pretty Printer Concepts), p 22-13
    
+		~/name/ FORMAT directive, p 22-39..22-40
    
+		PPRINT-DISPATCH, p 22-45..22-46
    
+		PPRINT-EXIT-IF-LIST-EXHAUSTED, p 22-46
    
+		PPRINT-FILL (etc), p 22-47
    
+		PPRINT-INDENT, p 22-48
    
+		PPRINT-LOGICAL-BLOCK, p 22-49..22-51
    
+		PPRINT-NEWLINE, p 22-51..22-52
    
+		PPRINT-POP, p 22-52..22-54
    
+		PPRINT-TAB, p 22-54
    
+		PRINT-OBJECT, p 22-55..22-56
    
+		SET-PPRINT-DISPATCH, p 22-57..22-58
    
+Category:	CHANGE
    
+Edit history:	V1, 18 Sept 1992, Sandra Loosemore
    
+		V2, 18 Sept 1992, Sandra Loosemore
    
+		  (comments from Dick Waters)
    
+		V3, 04 Feb 1993, Sandra Loosemore
    
+		  (fix references)
    
+Status:		Proposal UNIFY passed 8-3 on letter ballot 93-302.
    
+
    
+
    
+Problem description:
    
+
    
+  The pretty-printing mechanisms are poorly integrated with the rest
    
+  of the printer.
    
+
    
+  Specifically,
    
+
    
+  (1) The requirement that objects for which there is no pretty-print
    
+  function defined in *PRINT-PPRINT-DISPATCH* print using the standard
    
+  mechanisms but with *PRINT-PRETTY* bound to NIL (p. 22-15 and 22-45)
    
+  makes it impossible for PRINT-OBJECT methods or DEFSTRUCT 
    
+  :PRINT-FUNCTIONS to handle *PRINT-PRETTY* themselves.  This can lead 
    
+  to unnecessary duplication of code, as it requires programmers to write 
    
+  two different functions to print the same kind of object.
    
+
    
+  (2) The behavior of PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR,
    
+  PPRINT-INDENT, PPRINT-LOGICAL-BLOCK, PPRINT-NEWLINE, and PPRINT-TAB when
    
+  *PRINT-PRETTY* is not true is unspecified, although the names imply
    
+  that they are only useful when pretty-printing or that they may bind
    
+  *PRINT-PRETTY*.  Again, to avoid pointless duplication of code, these
    
+  mechanisms should do something reasonable regardless of whether
    
+  *PRINT-PRETTY* is true.
    
+
    
+  (3) The order of the "stream" and "object" arguments to 
    
+  PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR, functions in pprint
    
+  dispatch tables, and functions used with the ~/name/ format directive
    
+  is backwards with respect to that of other printing functions.
    
+
    
+  There are three non-mutually-exclusive proposals here.  Proposal
    
+  UNIFY addresses problems (1) and (2).  Proposal REORDER addresses
    
+  problem (3).  Proposal RENAME changes the names of most of the
    
+  affected functions to reflect the more general utility under proposal
    
+  UNIFY.
    
+
    
+
    
+Proposal (GENERALIZE-PRETTY-PRINTER:UNIFY):
    
+
    
+  (1) Change the behavior stated in section 22.2.1.4 and in the
    
+  description of PPRINT-DISPATCH to say that if there is no specific
    
+  found in the pprint dispatch table, a function which invokes the
    
+  appropriate PRINT-OBJECT method is used.  Remove the requirement that
    
+  *PRINT-PRETTY* be rebound to NIL.
    
+
    
+  (2) Clarify that PPRINT-LOGICAL-BLOCK may be used even when
    
+  *PRINT-PRETTY* is not true.  Remove the requirement that the stream
    
+  cease to behave as a pretty-printing stream if *PRINT-PRETTY* becomes
    
+  bound to NIL.  Clarify that PPRINT-LOGICAL-BLOCK does not locally
    
+  rebind *PRINT-PRETTY*.
    
+
    
+  (3) Specify that if *PRINT-PRETTY* is false, the functions PPRINT-FILL,
    
+  PPRINT-LINEAR, and PPRINT-TABULAR print list arguments with a minimum
    
+  of whitespace (i.e., as described in section 22.1.3.8).  Clarify that
    
+  these functions do not locally rebind *PRINT-PRETTY*.
    
+
    
+  (4) The draft currently says that PPRINT-NEWLINE, PPRINT-TAB, and
    
+  PPRINT-INDENT do nothing if the stream is not a pretty-printing stream.  
    
+  Change this to say they also do nothing if *PRINT-PRETTY* is false.
    
+
    
+  (5) Change the description of PRINT-OBJECT to mention the use of
    
+  functions such as PPRINT-FILL to handle *PRINT-PRETTY*, and
    
+  PPRINT-LOGICAL-BLOCK to handle *PRINT-LENGTH* truncation, instead
    
+  of discouraging people from handling these variables properly.
    
+
    
+
    
+  Rationale:
    
+
    
+    This allows you to write a single function that handles both pretty
    
+    and non-pretty printing that can use a single block of code inside
    
+    PPRINT-LOGICAL-BLOCK to print structured objects regardless of whether
    
+    *PRINT-PRETTY* is true.  It also allows you to call the other
    
+    functions without having to make an explicit check to be sure that 
    
+    *PRINT-PRETTY* is true, and do something else if it isn't.
    
+
    
+
    
+
    
+Proposal (GENERALIZE-PRETTY-PRINTER:REORDER):
    
+
    
+  (1) Reverse the order of the "object" and "stream" arguments to
    
+  functions in pprint dispatch tables.
    
+
    
+  (2) Explicitly state that PPRINT-DISPATCH returns the generic function
    
+  PRINT-OBJECT if there is no matching type specifier in the pprint
    
+  dispatch table.
    
+
    
+  (3) Reverse the order of the "object" and "stream" arguments to
    
+  PPRINT-FILL, PPRINT-LINEAR, and PPRINT-TABULAR.  Make the "stream"
    
+  argument optional and default in the usual way for an output stream
    
+  designator, so that the argument list is 
    
+    (object &optional stream colon-p at-sign-p).
    
+
    
+  (4) Reverse the order of the "object" and "stream" arguments passed
    
+  to functions invoked with the ~/name/ format directive.
    
+
    
+
    
+  Rationale:
    
+
    
+    This removes a pointless inconsistency in the language design and
    
+    makes it a little simpler.
    
+
    
+
    
+
    
+Proposal (GENERALIZE-PRETTY-PRINTER:RENAME):
    
+
    
+  Rename PPRINT-EXIT-IF-LIST-EXHAUSTED, PPRINT-FILL, PPRINT-LINEAR,
    
+  PPRINT-TABULAR, PPRINT-INDENT, PPRINT-LOGICAL-BLOCK, PPRINT-NEWLINE,
    
+  PPRINT-POP, and PPRINT-TAB to PRINT-*.
    
+
    
+  Rationale: 
    
+
    
+    Changing the names makes it more apparent that these functions are
    
+    useful even when *PRINT-PRETTY* is false and that they do not
    
+    rebind *PRINT-PRETTY* to true as PPRINT does.  (Note that this list 
    
+    does not include *PRINT-PPRINT-DISPATCH*, PPRINT-DISPATCH, and
    
+    SET-PPRINT-DISPATCH, since these are only relevant when *PRINT-PRETTY*
    
+    is true.)
    
+
    
+    Since proposals UNIFY and REORDER make incompatible changes in the
    
+    behavior of these functions, changing their names may be helpful in
    
+    detecting obsolete calls.
    
+
    
+
    
+Current practice:
    
+
    
+  XP doesn't implement any of these changes.
    
+
    
+  Loosemore made most of these changes when rewriting XP into a
    
+  Scheme-like dialect; the Yale Haskell system uses it extensively.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Medium.  Making the changes to the printer implementation is
    
+  straightforward, but there are the usual support costs associated
    
+  with making an incompatible change.
    
+
    
+
    
+Cost to users:
    
+
    
+  This is an incompatible change for people who now use XP, but it's
    
+  easy to fix.  Adoption of proposal RENAME may make it easier to detect
    
+  obsolete uses.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+  More work for people writing new code.  Confusion about why
    
+  PRINT-OBJECT methods can't detect when *PRINT-PRETTY* is true.  Risk
    
+  of function for printing when *PRINT-PRETTY* is true getting out of
    
+  sync with function for printing the same object when *PRINT-PRETTY* is
    
+  false.  Risk of people making stupid programming mistakes because they
    
+  can't remember which functions accept arguments in which order.
    
+
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Making the language simpler and more uniform is generally a good
    
+  thing.
    
+
    
+
    
+Editorial impact:
    
+
    
+  It would probably take two or three days to make the necessary changes,
    
+  including updating examples.  Loosemore is willing to undertake the
    
+  editorial work.
    
+
    
+
    
+Discussion:
    
+
    
+  This issue was first raised on the X3J13 mailing list in January 1992
    
+  with the subject "apparent shortcomings with PPRINT interface".
    
+
    
+  Loosemore says: I discovered these problems when trying to implement
    
+  the new pretty-printer functionality for the first time for use by the
    
+  Yale Haskell system.  We have several dozen different kinds of structures
    
+  representing AST nodes and wanted to be able to print them reasonably
    
+  for debugging and error messages.  Pushing the detection for
    
+  *PRINT-PRETTY* into the support functions resulted in *major*
    
+  consolidations and simplifications of this code.
    
+
    
+  Waters says: I support your proposal strongly.  Please feel free to
    
+  add me to the proposal as a formal supporter.
    
+
    
+  John Burger also says he was bitten by the inability to handle
    
+  *PRINT-PRETTY* in PRINT-OBJECT methods, and that he supports this 
    
+  proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181.htm new file mode 100644 index 00000000..48e4f1b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181.htm @@ -0,0 +1,49 @@ + + + +CLHS: Issue GENERIC-FLET-POORLY-DESIGNED:DELETE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue GENERIC-FLET-POORLY-DESIGNED:DELETE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue GENERIC-FLET-POORLY-DESIGNED:DELETE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181_w.htm new file mode 100644 index 00000000..ad168c62 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss181_w.htm @@ -0,0 +1,163 @@ + + + +CLHS: Issue GENERIC-FLET-POORLY-DESIGNED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue GENERIC-FLET-POORLY-DESIGNED Writeup

    + +
    Status:         Proposal DELETE accepted 12/91
    
+Issue:          GENERIC-FLET-POORLY-DESIGNED
    
+References:     CLtL2 p.844-846
    
+Related issues: WITH-ADDED-METHODS
    
+Category:       CHANGE
    
+Edit history:   22-Aug-91, Version 1 by Barmar
    
+                10-Sep-91, Version 2 by Barmar - minor RPG-suggested
    
+                           changes
    
+                10-Jan-92, Version 3 by Barrett - remove GENERIC-FUNCTION,
    
+                           per X3J13 ammendment
    
+                10-Feb-92, Version 4 by Barrett - put back GENERIC-FUNCTION
    
+                           symbol mistakenly removed; fix Current practice
    
+
    
+Problem description:
    
+
    
+  Very few, if any, CLOS implemementations implement GENERIC-FLET and
    
+  GENERIC-LABELS.
    
+
    
+Proposal (GENERIC-FLET-POORLY-DESIGNED:DELETE):
    
+
    
+  Remove the operators GENERIC-FLET, GENERIC-LABELS, and GENERIC-FUNCTION from
    
+  the language.  Delete the symbols GENERIC-FLET and GENERIC-LABELS from the
    
+  COMMON-LISP package.
    
+
    
+Rationale:
    
+
    
+  The current form of lexical generic functiona is inadequate for
    
+  general use, and therefore there is no existing compelling reason to
    
+  retain them. Because they are poorly designed, it would be better to
    
+  remove them from the language hoping for research and better designs
    
+  than to prejudice the case for them by retaining a bad design.
    
+
    
+  The symbol GENERIC-FUNCTION is retained because it also names a class.
    
+
    
+Current practice:
    
+
    
+  Apple Macintosh Common Lisp 2.0 provides the listed operators.
    
+
    
+  Lucid CL 4.0 and Symbolics Genera 8.1 both export GENERIC-FLET and
    
+  GENERIC-LABELS from their CLOS packages, and Lucid imports it into
    
+  the implementation-dependent package that USER inherits from.  Neither
    
+  of them defines them, though.
    
+
    
+  Preliminary Symbolics Genera 8.2 and Chesnut Lisp-to-C Translator 2.0
    
+  provided the listed operators at the time of the December meeting.  Since
    
+  then they have deleted from both implementations, in deference to the
    
+  committee's decision.
    
+
    
+  Symbolics CLOE does not provide them.
    
+
    
+Cost to Implementors:
    
+
    
+  Very little.  For many implementors, no work at all is involved.
    
+  Any implementors that export these symbols from COMMON-LISP will have
    
+  to change their package specification, but that's it.
    
+
    
+Cost to Users:
    
+
    
+  Since this is a new feature that not everyone implements, programs
    
+  that use them are not currently portable, so there should be little
    
+  effect on users.
    
+
    
+Cost of non-adoption:
    
+
    
+  It will probably take longer for complete CLOS implementations to
    
+  appear.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  See Esthetics and Cost of non-adoption.
    
+
    
+Esthetics:
    
+
    
+  Since no one really understands what these special forms are for, this
    
+  clearly simplifies the language.
    
+
    
+Discussion:
    
+
    
+  From RPG:
    
+
    
+    The reason that lexical generic functions are relatively less useful
    
+    than lexical functions is that with a generic function you are
    
+    expecting that someone will extend it when they extend the ontology of
    
+    the world, and you want to get a hold of those extensions for free.
    
+    The mechanism for the for-freeness is the global namespace for generic
    
+    function names. When you make those names lexical you lose this
    
+    feature. Presumably this is the primary nice feature of OOP.
    
+    
    
+    The use of lexical generic functions is to create private operations
    
+    within a scope, which can be larger than the scope of a function. The
    
+    purpose of generic-flet/labels is to allow folks to write these
    
+    private functions. The point of with-added-methods was to allow these
    
+    local functions to be extended within the larger lexical scope. 
    
+    
    
+    With-added-methods had the flaw that it did not allow one to extend a
    
+    global generic function within its dynamic extent, which I believe was
    
+    the intent of its proposer. That is, it couldn't be used to add a
    
+    method to a generic version of print such that that extended version
    
+    would be used by all free references to it dynamically within the
    
+    extent of the with-added-methods.
    
+    
    
+    Still, it had a use within the scenario I outlined above.
    
+    
    
+    The real flaw with the whole design is that one would like to have
    
+    lexical class definitions, which would render lexical generic
    
+    functions more useful, because then the lexical environments provide a
    
+    possible worlds mechanism. So, one would like to create an environment
    
+    with a locally extended hierarchy within which the lexical generic
    
+    functions are used.
    
+    
    
+    A minor flaw with lexical generic functions are specified is their
    
+    stupid syntax. If I were in a catty mood, I would ascribe the bad
    
+    syntax.
    
+    
    
+    I believe there are a number of other operations one would like to
    
+    perform with generic functions that are now not possible, such as
    
+    explicitly combining separately defined generic functions. This along
    
+    with lexical generic functions would allow people to do
    
+    encapsulation.  But that's another story.
    
+    
    
+    Right now I would advocate removing lexical generic functions so that
    
+    someone can do a proper design.
    
+
    
+  Barmar:
    
+
    
+    What about GENERIC-FUNCTION?  If lexical generic functions are
    
+    useless, maybe anonymous ones are as well.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182.htm new file mode 100644 index 00000000..85765f30 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue GENSYM-NAME-STICKINESS:LIKE-TEFLON Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue GENSYM-NAME-STICKINESS:LIKE-TEFLON Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue GENSYM-NAME-STICKINESS:LIKE-TEFLON:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182_w.htm new file mode 100644 index 00000000..c4621c0b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss182_w.htm @@ -0,0 +1,149 @@ + + + +CLHS: Issue GENSYM-NAME-STICKINESS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue GENSYM-NAME-STICKINESS Writeup

    + +
    Issue:        GENSYM-NAME-STICKINESS
    
+Forum:	      Cleanup
    
+References:   GENSYM (p169)
    
+Category:     CHANGE
    
+Edit history: 14-Feb-89, Version 1 by Pitman
    
+	      15-Mar-89, Version 2 by Steele (add GENSYM-COUNTER function)
    
+	      20-Mar-89, Version 3 by Pitman (make it a variable)
    
+
    
+Problem Description:
    
+
    
+  Many people avoid use of the argument to GENSYM because the argument
    
+  is `sticky' and such stickiness can lead to confusion. The problem is
    
+  that if any application (usually a macro) uses the gensym argument at
    
+  all, then all applications are forced to. If they do not, they risk
    
+  finding that the `helpful' argument supplied in some previous call will
    
+  be harmful to them.
    
+
    
+Proposal (GENSYM-NAME-STICKINESS:LIKE-TEFLON)
    
+
    
+  Define that if an optional argument [either a string or a number] is
    
+  given to GENSYM, it does NOT have a side-effect on GENSYM's internal state.
    
+
    
+  Introduce a new variable, *GENSYM-COUNTER*, which holds the state of
    
+  the gensym counter. That is, the next symbol generated by GENSYM will
    
+  be number n.  The initial value of this variable is not defined, but
    
+  must always be a non-negative integer. This variable may be either 
    
+  assigned or bound by users at any time, but always to a non-negative
    
+  integer.
    
+
    
+  Deprecate the use of a numeric argument to GENSYM.
    
+
    
+Rationale:
    
+
    
+  Conscientious programmers are forced now to write their own GENSYM
    
+  lookalikes because they know the system's GENSYM has an invasive
    
+  effect. This defeats the primary intended function of GENSYM, which
    
+  is to satisfy the most common idiomatic use of MAKE-SYMBOL.
    
+
    
+  The stickiness of the GENSYM prefix was an attempt to be gratuitously
    
+  compatible with Maclisp, at the expense of good programming pratice.
    
+
    
+  Users who need the old behavior of GENSYM can trivially implement
    
+  that behavior using MAKE-SYMBOL.
    
+
    
+  Occasionally you want to reset the GENSYM counter so that, for example,
    
+  you can get the compiler to generate the same symbol names again
    
+  (good for comparing results to see what really changed).
    
+
    
+Test Case:
    
+
    
+  ;; #1: Test stickiness of name part.
    
+  (CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
    
+	      #\G)
    
+  => NIL ;under CLtL
    
+  => T   ;under this proposal
    
+
    
+  ;; #2: Test stickiness of number part.
    
+  (= (PARSE-INTEGER (PROGN (GENSYM 6789) (STRING (GENSYM "G"))) :START 1)
    
+     6790)
    
+  => T   ;under CLtL
    
+  => NIL ;under this proposal (except when *gensym-counter* happens to align)
    
+
    
+  ;; #3: Illustrate use of new variable.
    
+  (STRING= (SYMBOL-NAME (LET ((*GENSYM-COUNTER* 43)) (GENSYM "FOO")))
    
+           "FOO43")
    
+  => T   ;under this proposal (not meaningful previously)
    
+
    
+Current Practice:
    
+
    
+  Symbolics Cloe and Genera are compatible with CLtL, so this would be an
    
+  incompatible change.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+  If any implementations currently use a more compact representation for
    
+  the internal state of GENSYM than a variable holding a string and a
    
+  separate variable holding an integer, they might be forced to change.
    
+  Even then, the change would proabably still be quite small.
    
+
    
+Cost to Users:
    
+
    
+  Most uses of GENSYM do not depend on the stickiness of the name, so the
    
+  change would be compatible. In some cases, the change would be an
    
+  improvement. Even in the worst case where someone depends on stickiness,
    
+  it's extremely straightforward to write the couple of lines of code to
    
+  produce an application based on MAKE-SYMBOL that is at least as flexible
    
+  as GENSYM, and often moreso.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Good programmers would avoid using the argument to GENSYM (or using 
    
+  GENSYM altogether) in many situations where they ought not have to.
    
+
    
+Benefits:
    
+
    
+  Gensyms which appear to convey information through their name would not
    
+  accidentally pop out and cause confusion in places where they oughtn't.
    
+
    
+  Making the gensym counter visible as a variable means that people will
    
+  be able to bind the gensym counter locally when they don't want to affect
    
+  the global counter.
    
+
    
+Aesthetics:
    
+
    
+  Unnecessary global state changes are hard to reason about. This would 
    
+  be a small simplification.
    
+
    
+Discussion:
    
+
    
+  Pitman claims to have written a non-sticky GENSYM function for nearly
    
+  every one of the dozen or so large systems that he's written or worked
    
+  on in the last decade in order to get around the stated problem.
    
+  Others have suggested similar experience.
    
+
    
+  Pitman and Steele support LIKE-TEFLON.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183.htm new file mode 100644 index 00000000..95fb0e1f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue GENTEMP-BAD-IDEA:DEPRECATE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue GENTEMP-BAD-IDEA:DEPRECATE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue GENTEMP-BAD-IDEA:DEPRECATE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183_w.htm new file mode 100644 index 00000000..022d88f4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss183_w.htm @@ -0,0 +1,105 @@ + + + +CLHS: Issue GENTEMP-BAD-IDEA Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue GENTEMP-BAD-IDEA Writeup

    + +
    Issue:        GENTEMP-BAD-IDEA
    
+Forum:	      X3J13 Letter Ballot
    
+References:   GENTEMP (X3J13/92-102 pp10-10..11)
    
+Category:     CHANGE
    
+Edit history: 04-Jun-93, Version 1 by Pitman
    
+Status:	      Proposal DEPRECATE passed 9-2 on letter ballot 93-302.
    
+
    
+Problem Description:
    
+
    
+  GENTEMP is an `attractive nuisance.'  Pitman and many others believe that
    
+  GENTEMP should NEVER be used.
    
+ 
    
+  Its effects are hard to depend on because they differ from session to
    
+  session.
    
+ 
    
+  Its description gives the impression that the symbol it creates is
    
+  unique, but it is easy to establish innocent-looking patterns of data
    
+  flow (when multiple sessions are involved) where the same supposedly
    
+  unique symbol is created for conflicting uses.
    
+
    
+Proposal (GENTEMP-BAD-IDEA:DEPRECATE):
    
+
    
+  Deprecate the function GENTEMP.
    
+
    
+Proposal (GENTEMP-BAD-IDEA:REMOVE):
    
+
    
+  Remove the function GENTEMP from the language.
    
+
    
+Test Case:
    
+
    
+  None.
    
+
    
+Rationale:
    
+
    
+  The potential bad effects of GENTEMP are large, and there is no real
    
+  benfit.  Anyone who really needs this could write it trivially given
    
+  the primitives already in the language.
    
+
    
+Current Practice:
    
+
    
+  Presumably all implementations provide it.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+Cost to Users:
    
+
    
+  Small.  (In the worst case, users will have to write a one-liner
    
+  to patch over it if they really need it.)
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Users might think this function was more useful than it was, and might
    
+  fall into some of its traps.
    
+
    
+Benefits:
    
+
    
+  Language is one page shorter.
    
+
    
+Editorial Impact:
    
+
    
+  A small, well-isolated change, plus a quick sweep of the sources
    
+  to make sure there are no stray references.
    
+
    
+Aesthetics:
    
+
    
+  GENTEMP is not aesthetic.
    
+
    
+Discussion:
    
+
    
+  This is in response to Pitman's comment #19, first Public Review.
    
+  Pitman supports the proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184.htm new file mode 100644 index 00000000..2af9fc70 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184_w.htm new file mode 100644 index 00000000..19eaa52d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss184_w.htm @@ -0,0 +1,137 @@ + + + +CLHS: Issue GET-MACRO-CHARACTER-READTABLE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue GET-MACRO-CHARACTER-READTABLE Writeup

    + +
    Status: Passed, Jan 89 X3J13
    
+Forum: Cleanup
    
+Issue: 	GET-MACRO-CHARACTER-READTABLE
    
+
    
+References:  CLtL p.361: COPY-READTABLE, SET-SYNTAX-FROM-CHAR, and
    
+                         GET-MACRO-CHARACTER
    
+             CLtL p.364: GET-DISPATCH-MACRO-CHARACTER, 
    
+             CLtL p.378: Example in middle of page
    
+
    
+Category:    CLARIFICATION/CHANGE
    
+
    
+Edit history:  Version 1, 16-Nov-88, by JonL
    
+               Version 2,  8-Dec-88, by Masinter (fix typo)
    
+		Version 3, 11-Feb-89, as amended Jan 89 X3J13
    
+
    
+
    
+Problem description:
    
+
    
+The 'readtable' argument to GET-DISPATCH-MACRO-CHARACTER and to
    
+GET-MACRO-CHARACTER must be of type READTABLE, without mention of
    
+what happens when NIL is supplied. This may have been simply
    
+an oversight, since it makes more sense for it to refer to values from
    
+the standard readtable.  Both COPY-READTABLE and SET-SYNTAX-FROM-CHAR
    
+explicitly say that a NIL in the 'from-readtable' argument refers to the
    
+standard readtable.  Also, an example in the middle of the page, CLtL
    
+p.378, supplies a NIL to GET-MACRO-CHARACTER, and is clearly intending
    
+to access the standard readtable values.
    
+
    
+
    
+Proposal (GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD)
    
+
    
+Specify that a NIL readtable argument to GET-DISPATCH-MACRO-CHARACTER
    
+and to GET-MACRO-CHARACTER mean the same thing it does for COPY-READTABLE,
    
+and SET-SYNTAX-FROM-CHAR; namely a reference to the standard readtable.  
    
+Thus (GET-MACRO-CHARACTER <char> NIL) would be equivalent to 
    
+(GET-MACRO-CHARACTER <char> (COPY-READTABLE)), but without consing.
    
+
    
+Rationale:
    
+
    
+Probably was the original intent; somebody wants it; also see "Esthetics".
    
+
    
+Current practice:
    
+
    
+Symbolics and Xerox have already implemented the proposal; Lucid, VAXLISP,
    
+and KCL stuck to the more rigid interpretation.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Trivial.
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+Cost of non-adoption:
    
+
    
+Minor worry about porting between implementations that support the
    
+generalization and those that don't; minor worry about consing when
    
+calling (COPY-READTABLE) to get at standard readtable semantics.
    
+
    
+Performance impact:
    
+
    
+See "Cost of non-adoption".
    
+
    
+Benefits:
    
+
    
+See "Cost of non-adoption".
    
+
    
+Esthetics:
    
+
    
+Increases parallel design among similar readtable functions.
    
+
    
+Discussion:
    
+
    
+This question was raised in the Common Lisp mailing last summer:
    
+    Date: 19 Jul 88 13:35
    
+    Subject: Question about readtable null arguments
    
+    From: quiroz%cs.rochester:EDU:Xerox
    
+    To: common-lisp%sail.stanford:EDU:Xerox
    
+ 
    
+This issue passed at the Jan 89 X3J13 meeting. The only
    
+difference between version 2 and 3 was to remove the
    
+test case because of problems of "function equivalence":
    
+
    
+If "same-function-p" compared functions:
    
+
    
+(let ((standard-rt (copy-readtable))
    
+      (chars '(#\* #\= #\| #\A #\  #\( #\# #\1)))
    
+  ;; Test Case 1
    
+  (dolist (char chars)
    
+    (assert (same-function-p (get-macro-character char nil)
    
+                (get-macro-character char standard-rt))
    
+            () "Lose on character ~C" char))
    
+  ;; Test Case 2
    
+  (dolist (char chars)
    
+    (assert (same-function-p (get-dispatch-macro-character #\# char nil)
    
+                (get-dispatch-macro-character #\# char standard-rt))
    
+            () "Lose on #\# dispatch character ~C" char))
    
+  ;; Test Case 3
    
+  (assert (same-function-p (get-dispatch-macro-character #\# #\A nil)
    
+              (get-dispatch-macro-character #\# #\a nil))
    
+          () "Lose on #\# dispatch character ~C" char)
    
+ )
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185.htm new file mode 100644 index 00000000..7820bb75 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue GET-SETF-METHOD-ENVIRONMENT:ADD-ARG Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue GET-SETF-METHOD-ENVIRONMENT:ADD-ARG Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185_w.htm new file mode 100644 index 00000000..764db506 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss185_w.htm @@ -0,0 +1,147 @@ + + + +CLHS: Issue GET-SETF-METHOD-ENVIRONMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue GET-SETF-METHOD-ENVIRONMENT Writeup

    + +
    Issue:          GET-SETF-METHOD-ENVIRONMENT
    
+References:     GET-SETF-METHOD (CLtL p 187)
    
+Category:       Change
    
+Edit History:   Version 1 9-Jan-87, Version 1 by Masinter 
    
+                (no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
    
+                Version 2 29-May-87, extracted again 
    
+                Version 3  5-Jun-87, by Masinter
    
+                Version 4  11-Jun-87, for release
    
+                Version 5  13-Jul-87, by Masinter
    
+                
    
+Problem Description:
    
+
    
+If a macro that performs similar processing to SETF uses GET-SETF-METHOD,
    
+and that macro occurs within a MACROLET, the expansion will not see the
    
+MACROLET definition, e.g.,
    
+
    
+ (defmacro special-incf ... (get-setf-method ...) ...)
    
+
    
+then  
    
+
    
+ (macrolet ((test (x) `(car ,x)))
    
+         (special-incf (test z)))
    
+
    
+would not "see" the test definition.
    
+
    
+Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
    
+
    
+Add an optional environment argument to GET-SETF-METHOD and
    
+GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
    
+defaults to the null lexical environment. NIL can also be passed explicitly
    
+to denote the null lexical environment.
    
+
    
+Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
    
+DEFINE-SETF-METHOD form, as with a DEFMACRO.
    
+
    
+Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
    
+environment to GET-SETF-METHOD.
    
+
    
+Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
    
+definitions of the name defined by the MACROLET, FLET or LABELS do not
    
+apply.  A SETF method applies only when the global function binding of the
    
+name is lexically visible.  All of the built in macros of Common Lisp
    
+(SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location specifications
    
+obey this convention.
    
+
    
+Test Case:
    
+
    
+;;; This macro is like POP 
    
+
    
+(defmacro xpop (place &environment env)
    
+  (multiple-value-bind (dummies vals new setter getter)
    
+                       (get-setf-method place env)
    
+     `(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
    
+        (prog1 (car ,(car new))
    
+               (setq ,(car new) (cdr ,(car new)))
    
+               ,setter)))))
    
+
    
+(defsetf frob (x) (value) 
    
+    `(setf (car ,x) ,value))
    
+
    
+;;; The following will modify (cdr z) and not (car z)
    
+(macrolet ((frob (x) `(cdr ,x)))
    
+     (xpop (frob z)))
    
+
    
+;;; The following is an error; an error may be signaled at macro expansion
    
+time
    
+
    
+(flet ((frob (x) (cdr x))
    
+     (xpop (frob z)))
    
+
    
+
    
+Rationale:
    
+
    
+This was an omission in the original definition of CLtL.
    
+
    
+Current Practice:
    
+
    
+Many Common Lisp implementations already have this extension, although some
    
+do not. One implementation has extended GET-SETF-METHOD to take an optional
    
+argument which is incompatible with this use.
    
+
    
+Cost to implementors:
    
+
    
+Some implementations will have to add this feature, although it is not a
    
+major change.
    
+
    
+Cost to users:
    
+
    
+This is generally an upward compatible change. In implementations which did
    
+not already take into account the lexical environment for SETF'd forms
    
+might start working differently if the internal implementation of SETF is
    
+changed. The likelihood of this affecting a user's program is very small.
    
+
    
+Benefits:
    
+
    
+This change improves portability and the ability to use MACROLET, FLET and
    
+LABELS in portable code which might also have SETF forms.
    
+
    
+Aesthetics:
    
+
    
+SETF methods cannot work correctly within lexically defined function
    
+symbols without this change. This change makes the language more consistent
    
+and correct. 
    
+
    
+Discussion:
    
+
    
+The cleanup committee generally supports this change.
    
+
    
+A number of additional changes for rationally dealing with lexical
    
+environments as first class objects, including a more general set of
    
+accessors and constructors for lexical environments is required for many
    
+language extensions (e.g., a portable version of the proposed Common Lisp
    
+Object System) and should be addressed by a future proposal. For a while,
    
+the cleanup committee attempted to deal with these issues together, but
    
+decided to separate them out into their component parts. This issue is the
    
+simplest.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186.htm new file mode 100644 index 00000000..990acc91 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue HASH-TABLE-ACCESS:X3J13-MAR-89 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue HASH-TABLE-ACCESS:X3J13-MAR-89 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue HASH-TABLE-ACCESS:X3J13-MAR-89:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186_w.htm new file mode 100644 index 00000000..da63b9f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss186_w.htm @@ -0,0 +1,109 @@ + + + +CLHS: Issue HASH-TABLE-ACCESS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue HASH-TABLE-ACCESS Writeup

    + +
    Status:       Passed, as amended, Mar 89 X3J13 (by vote of 17-0)
    
+
    
+
    
+Issue:        HASH-TABLE-ACCESS
    
+References:   Hash-tables (Chapter 21 of CLtL)
    
+Category:     ADDITION
    
+Edit History: 13-Sept-88, version 1 by Walter van Roggen
    
+              13-Oct-88, version 2 by Walter van Roggen
    
+	      05-Apr-89, version 3 by Pitman (changes per x3J13)
    
+ 
    
+Problem Description:
    
+ 
    
+  There are many characteristics of hash-tables which are specified upon
    
+  creation but are not accessible afterwards.
    
+ 
    
+Proposal: (HASH-TABLE-ACCESS:X3J13-MAR-89)
    
+ 
    
+  Add the following functions to the language:
    
+ 
    
+  HASH-TABLE-REHASH-SIZE hash-table
    
+ 
    
+    Returns the current rehash size of a hash table.
    
+ 
    
+  HASH-TABLE-REHASH-THRESHOLD hash-table
    
+ 
    
+    Returns the current rehash threshold of a hash table.
    
+ 
    
+  HASH-TABLE-SIZE hash-table
    
+ 
    
+    Returns the current size of a hash table.
    
+ 
    
+  HASH-TABLE-TEST hash-table
    
+ 
    
+    Returns the test used for comparing keys in the hash table.
    
+    By default the value will be EQL.
    
+ 
    
+  Define that the results of HASH-TABLE-REHASH-SIZE, 
    
+  HASH-TABLE-REHASH-THRESHOLD, and HASH-TABLE-SIZE are suitable
    
+  for use in a call to MAKE-HASH-TABLE in order to produce a hash
    
+  table with state corresponding to the current state of the hash
    
+  table.
    
+
    
+  Clarify that the result of HASH-TABLE-TEST is always a symbol
    
+  naming a function rather than the function itself if the test
    
+  is one of those defined by this standard. (Implementations which
    
+  provide additional tests for hash tables may determine how this
    
+  function relates to such extended tests.)
    
+ 
    
+Current Practice:
    
+ 
    
+  VAX LISP and Lucid 3.0 implement the proposal.
    
+ 
    
+Cost to Implementors:
    
+ 
    
+  Most of these should be trivial to implement, since the information
    
+  must be present for nearly all types.
    
+ 
    
+Cost to Users:
    
+ 
    
+  None.  This is an upward-compatible extension.
    
+ 
    
+Cost of Non-Adoption:
    
+ 
    
+  The benefits would not be available in a portable fashion.
    
+ 
    
+Benefits:
    
+ 
    
+  Programs would be able to access useful information otherwise hidden.
    
+  For example, it would allow programs to gain statistics about hash
    
+  table usage that might enable better tuning.
    
+ 
    
+Discussion:
    
+ 
    
+  None of these are required to be SETF'able, though some might be
    
+  reasonable implementation-dependent extensions.  Including such
    
+  modification abilities might constrain some implementations unduly.
    
+ 
    
+  This first appeared in ">GLS>clarifications.text" of 12/06/85.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187.htm new file mode 100644 index 00000000..d5fbceb4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue HASH-TABLE-KEY-MODIFICATION:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue HASH-TABLE-KEY-MODIFICATION:SPECIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue HASH-TABLE-KEY-MODIFICATION:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187_w.htm new file mode 100644 index 00000000..b476de78 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss187_w.htm @@ -0,0 +1,265 @@ + + + +CLHS: Issue HASH-TABLE-KEY-MODIFICATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue HASH-TABLE-KEY-MODIFICATION Writeup

    + +
    Issue:		HASH-TABLE-KEY-MODIFICATION
    
+References:	CLtL page 282, page 168 (last paragraph in 10.2)
    
+		X3J13 Proposal EQUAL-STRUCTURE:MAYBE-STATUS-QUO (passed 6/89)
    
+Category:	CLARIFICATION
    
+Edit history:	Version 1, 12-Sep-88, Moon, for discussion
    
+		Version 2, 05-Feb-90, by Kim A. Barrett,
    
+					rewrite with more explicit constraints
    
+	        Version 3, 16-Feb-90, by Kim Barrett, KMP (respond to comments from Moon)
    
+
    
+Problem description:
    
+
    
+ CLtL is silent about what happens if you modify a component of an object that
    
+ is used as a hash-table key.
    
+
    
+Proposal (HASH-TABLE-KEY-MODIFICATION:SPECIFY):
    
+
    
+ Define that the function supplied as the :TEST argument to MAKE-HASH-TABLE
    
+ specifies the `equivalence test' for the new hash table.
    
+
    
+ Define that an object is `visibly modified' with regard to an equivalence test
    
+ if there exists some set of objects (or potential objects) which are equivalent
    
+ to the object before the modification but are no longer equivalent afterwards.
    
+
    
+ If an object is used as a key in a hash table and is then visibly modified
    
+ with regard to the equivalence test of the hash table, then using the object
    
+ as a key in further operations on the hash table has unspecified consequences.
    
+ Moreover, this applies for other objects which either are or were equivalent
    
+ to the key object.  Further, undoing the modification does not remove this
    
+ effect.
    
+
    
+ Following are specifications of the modifications which are visible to the
    
+ equivalence tests which must be supported by hash tables.  The modifications
    
+ are described in terms of modification of components, and are defined
    
+ recursively.  Visible modifications of components of the object are visible
    
+ modifications of the object.
    
+
    
+ 1. EQ and EQL
    
+   Common Lisp does not specify any method for visibly modifying any data type
    
+   with regard to either of these equivalence tests.
    
+
    
+ 2. EQUAL
    
+   As a consequence of the behavior for EQUAL specified by Issue
    
+   EQUAL-STRUCTURE, the specification for this case reverts to the previous
    
+   description for EQ and EQL for many data types.  The exceptions are
    
+
    
+   a. CONS
    
+     The car and cdr.
    
+
    
+   b. BIT-VECTOR
    
+     Elements of the vector, limited by the fill-pointer if present.
    
+     The length of the vector, if adjustable or a fill-pointer is present.
    
+
    
+   c. STRING
    
+     Same as for BIT-VECTOR.
    
+
    
+   d. PATHNAME
    
+     Common Lisp does not specify any method for visibly modifying a PATHNAME
    
+     with regard to EQUAL.
    
+
    
+ 3. EQUALP
    
+   As a consequence of the behavior for EQUALP specified by Issue
    
+   EQUAL-STRUCTURE, the specification for this case reverts to the previous
    
+   description for EQUAL for many data types.  The exceptions are
    
+
    
+   a. NUMBER
    
+     Common Lisp does not specify any method for visibly modifying a NUMBER
    
+     with regard to EQUALP.
    
+
    
+   b. CHARACTER
    
+     Common Lisp does not specify any method for visibly modifying a CHARACTER
    
+     with regard to EQUALP.
    
+
    
+   c. STRUCTURE
    
+     The values of the slots.
    
+
    
+   d. VECTOR
    
+     Elements of the vector, limited by the fill-pointer if present.
    
+     The length of the vector, if adjustable or a fill-pointer is present.
    
+
    
+   e. ARRAY
    
+     Elements of the array, limited by the fill-pointer if present.
    
+     The value of the fill-pointer, if present.
    
+     The dimensions, if adjustable.
    
+
    
+   f. HASH-TABLE
    
+     The count of entries in the table.
    
+     The keys.  Note that the visibility of modifications to the keys depends
    
+       on the equivalence test of the hash table, not on the specification of
    
+       EQUALP. 
    
+     The values associated with the keys.
    
+
    
+ Implementations which extend the language by providing additional mutator
    
+ functions (or additional behavior for existing mutator functions) must
    
+ document how the use of these extensions interacts with equivalence tests and
    
+ hash table searches.
    
+
    
+ Implementations which extend the language by defining additional acceptable
    
+ equivalence tests for hash tables (allowing additional values for the :TEST
    
+ argument to MAKE-HASH-TABLE) must document the visible components of these
    
+ tests.
    
+
    
+Test Cases/Examples:
    
+
    
+ (setf ht (make-hash-table :test #'eq))
    
+ (setf a (cons 1 2))
    
+ (setf (gethash a ht) 'win)
    
+ (setf (cdr a) 3)
    
+ (gethash a ht 'lose) => win t
    
+
    
+ The same example with :test #'equal in the first line would be an error.
    
+
    
+ The following example is not an error, because EQUAL does not examine the
    
+ components of general vectors:
    
+
    
+ (setf ht (make-hash-table :test #'equal))
    
+ (setf a (vector 1 2))
    
+ (setf (gethash a ht) 'win)
    
+ (setf (aref a 1) 3)
    
+ (gethash a ht 'lose) => win t
    
+
    
+ The following example is not an error, because EQUALP is limited by the
    
+ fill-pointer when examining the elements of a vector:
    
+
    
+ (setf ht (make-hash-table :test #'equalp))
    
+ (setf a (make-array 3 :fill-pointer 2 :initial-contents '(1 2 3)))
    
+ (setf (gethash a ht) 'win)
    
+ (setf (aref a 2) 4)
    
+ (gethash a ht 'lose) => win t
    
+
    
+ The following example is an error, because EQUALP may examine the dimensions
    
+ of arrays:
    
+
    
+ (setf ht (make-hash-table :test #'equalp))
    
+ (setf a (make-array '(2 3) :adjustable t))
    
+ (setf (gethash a ht) 'win)
    
+ (setf a (adjust-array a '(3 2)))
    
+ (gethash a ht 'lose) => `unspecified'
    
+
    
+ The following example is not an error, because EQUALP is case insensitive:
    
+
    
+ (setf ht (make-hash-table :test #'equalp))
    
+ (setf a "ABC")
    
+ (setf (gethash a ht) 'win)
    
+ (setf (char a 0) #\a)
    
+ (gethash a ht 'lose) => win t
    
+
    
+ The same example with :test #'equal in the first line would be an error.
    
+
    
+Rationale:
    
+
    
+ EQ and EQL hash tables use the identity of the object as the key, while EQUAL
    
+ and EQUALP hash tables use the structure of the object as the key.  Component
    
+ modification changes the structure of an object, while the identity of an
    
+ object cannot be changed in Common Lisp.
    
+
    
+ Specifying `unspecified consequences' provides implementation freedom, while
    
+ still providing guidance to users.
    
+
    
+ This is a generalization of the warning on p.168 of CLtL.
    
+
    
+ Note that this proposal implies that it is invalid to use an overly general
    
+ hash function, such as SXHASH, as the hash function for EQ or EQL hash tables.
    
+ The value of SXHASH can be affected by component modifications, and this is
    
+ likely to cause hash table entries to become inaccessible.  The general rule
    
+ for this is that a hash function must not depend on the value of some
    
+ property of an object if modification of that property is not visible to the
    
+ associated equivalence function.
    
+
    
+ The documentation requirements for extensions seems like the minimal necessary
    
+ thing, assuming we want to talk about extensions at all.
    
+
    
+Current practice:
    
+
    
+ I am not aware of any implementations that do not conform to the proposal.
    
+
    
+ Some implementations which provide any of the described extensions may not
    
+ conform to the documentation requirement.
    
+
    
+Cost to Implementors:
    
+
    
+ Most implementations probably already conform.  It is possible that some
    
+ implementations might have to use a different hash function in their
    
+ implementation of some hash tables in order to conform.
    
+
    
+Cost to Users:
    
+
    
+ None.
    
+
    
+Cost of non-adoption:
    
+
    
+ Users would not be sure whether they were allowed to perform side effects on
    
+ objects that might have been used as keys of hash tables.
    
+
    
+Benefits:
    
+
    
+ More specific language semantics.
    
+
    
+Esthetics:
    
+ 
    
+ More specific language semantics.
    
+
    
+Discussion:
    
+
    
+ Version 1
    
+  Discussion on the Common-Lisp mailing list was in favor of this.
    
+ 
    
+ Version 2
    
+  Barrett:
    
+   The two paragraphs about language extensions could be stricken without really
    
+   affecting the proposal.
    
+  
    
+   This proposal does not deal with any of the performance issues addressed by
    
+   Issue HASH-TABLE-STABILITY.  Rather, it provides guidance to users and
    
+   implementors as to the requirements for conforming programs.
    
+  
    
+   `Unspecified consequences' could be changed to 'undefined consequences',
    
+   though it seems unlikely that this is actually a 'crash and burn' situation.
    
+   (The program which was depending on the result of the operation may exhibit
    
+   undefined consequences as a result of the hash-table operation's having
    
+   unspecified consequences, but that's not the same thing.)
    
+
    
+  Moon:
    
+    Re: Define that an object is 'visibly modified' with regard to an
    
+        equivalence test if there exists some class of objects which were 
    
+	equivalent to the object before the modification but are no longer 
    
+	equivalent afterwards.
    
+    Except for ... the use of "class" to mean "set" rather than the
    
+    usual CLOS meaning, it looks okay.  Actually where it says "some
    
+    class of objects", a single object would be sufficient.  X is
    
+    visibly modified if there exists any Y such that (funcall test X Y)
    
+    produces a different result, provided (this is missing from Kim's
    
+    writeup) Y has not been modified [whatever that means exactly].
    
+
    
+  Pitman and Barrett support this proposal (v3).
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188.htm new file mode 100644 index 00000000..4426648b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188_w.htm new file mode 100644 index 00000000..042f1282 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss188_w.htm @@ -0,0 +1,354 @@ + + + +CLHS: Issue HASH-TABLE-PACKAGE-GENERATORS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue HASH-TABLE-PACKAGE-GENERATORS Writeup

    + +
    Forum:         Cleanup
    
+Issue:         HASH-TABLE-PACKAGE-GENERATORS
    
+
    
+References:    Issue: DO-SYMBOLS-DUPLICATES 
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, 23-May-88 JonL
    
+               Version 2,  6-Oct-88 JonL (convert to "with" scoping).
    
+               Version 3,  7-Oct-88 JonL (mly's syntax for package iterator)
    
+               Version 4,  8-Nov-88 JonL (fix example; clarify some nits)
    
+               Version 5, 22-Nov-88 Moon (improve syntax for package iterator,
    
+                                          add examples, fix typos)
    
+               Version 6,  6-Oct-88 JonL (final nits)
    
+               Version 7,  8-Dec-88, Masinter (add comment to discussion)
    
+
    
+Problem description:
    
+
    
+The Iteration subcommittee would like the several iteration proposals to be
    
+writable in portable Common Lisp code.  Unfortunately, the only complete
    
+access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
    
+DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives 
    
+is satisfactory for building complex iteration clauses.  In particular,
    
+these primitives are fully packaged and do not allow control over the
    
+individual operations of starting the iteration, stopping the iteration,
    
+and advancing to the next step of the iteration.
    
+
    
+
    
+Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
    
+
    
+Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR 
    
+to the language as follows:
    
+
    
+
    
+    WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body)      [Macro]
    
+
    
+    Within the lexical scope of 'body', the name <next-fn> is defined
    
+    via MACROLET such that successive invocations of (<next-fn>) will 
    
+    return the items, one by one, from the hash-table which is obtained 
    
+    by evaluating <hash-table> only once.
    
+
    
+    An invocation (<next-fn>) returns three values as follows:
    
+        1. a boolean indicating whether an entry is returned (T says yes)
    
+        2. the key item (of a <key, value> pair)
    
+        3. the value item (of a <key, value> pair)
    
+    After all entries have been returned [by successive invocations of
    
+    (<next-fn>)], then only one value is returned, namely NIL.
    
+
    
+
    
+
    
+    WITH-PACKAGE-ITERATOR ((<next-fn> <package-list>                    [Macro]
    
+                            &rest <symbol-types>)
    
+                           &body body)
    
+
    
+    Within the lexical scope of 'body', the name <next-fn> is defined
    
+    via MACROLET such that successive invocations of (<next-fn>) will 
    
+    return symbols, one by one, from the packages that are elements
    
+    of the list which is obtained by evaluating <package-list> only once.  
    
+    Each element of <package-list> can be a package or the name of a
    
+    package.
    
+
    
+    The order of symbols returned does not necessarily reflect the order
    
+    of packages in <package-list>.  When <package-list> has more than
    
+    one element, it is unspecified whether duplicate symbols are
    
+    returned once or more than once.  Even when <package-list> has only
    
+    one element, it is unspecified whether symbols inherited from
    
+    multiple packages are returned more than once.  See the proposal
    
+    DO-SYMBOLS-DUPLICATES:ALLOWED.
    
+
    
+    As a convenience, the value of <package-list> can be a package or
    
+    the name of a package; this is equivalent to a list of one element.
    
+    An argument of NIL is treated as an empty list of packages.
    
+
    
+    The <symbol-types> subform consists of one or more symbols from the
    
+    set {:INTERNAL, :EXTERNAL, :INHERITED}.  Their order does not
    
+    matter.  The <symbol-types> subform is not evaluated.  This controls
    
+    which symbols accessible in a package are returned:
    
+        :INTERNAL  means the symbols that are present in the package,
    
+                   but which are not exported;
    
+        :EXTERNAL  means the symbols that are present and exported;
    
+        :INHERITED means the symbols that are exported by used packages
    
+                   and that are not shadowed.
    
+    When more than one argument is supplied for <symbol-types>, then a 
    
+    symbol is returned if its accessibility matches any one of the 
    
+    <symbol-types> specified.  WITH-PACKAGE-ITERATOR signals an error if 
    
+    no <symbol-types> are specified or if a <symbol-type> not recognized 
    
+    by the implementation is specified.  Implementations are permitted to 
    
+    extend this syntax by recognizing additional symbol accessibility types.
    
+
    
+    An invocation (<next-fn>) returns four values as follows:
    
+        1. a boolean indicating whether a symbol is returned (T says yes)
    
+	2. a symbol (accessible in one the indicated packages)
    
+	3. the accessibility type for that symbol; i.e. one of
    
+	   :INTERNAL, :EXTERNAL, or :INHERITED
    
+	4. the package from which the symbol has been accessed.
    
+    After all symbols have been returned [by successive invocations of
    
+    (<next-fn>)], then only one value is returned, namely NIL.
    
+
    
+   The fourth return value is one of the packages present or named in the
    
+   <package-list> argument.  The meaning of the second, third, and fourth
    
+   values is that the returned symbol is accessible in the returned package
    
+   in the way indicated by the second return value:
    
+        :INTERNAL   ==>  present, and not exported,
    
+        :EXTERNAL   ==>  present, and exported, 
    
+        :INHERITED  ==>  not present (thus not shadowed) but inherited
    
+                         from some used package.
    
+
    
+It is unspecified what happens if any of the implicit interior state 
    
+of an iteration is returned outside the dynamic extent of the WITH-...
    
+form (such as by returning some closure over the invocation form).
    
+
    
+Any number of invocations of with-hash-table-iterator and
    
+with-package-iterator can be nested, and the body of the innermost one
    
+can invoke all of the MACROLET'ed macros, provided all those macros
    
+have distinct names.
    
+
    
+
    
+Examples:
    
+
    
+The following function should return T on any hash-table, and signal
    
+an error if the usage of 'with-hash-table-iterator' doesn't agree
    
+with the corresponding usage of 'maphash'.
    
+
    
+(defun test-hash-table-iterator (hash-table)
    
+  (let ((all-entries '())
    
+        (generated-entries '())
    
+        (unique (list nil)))
    
+    (maphash #'(lambda (key value) (push (list key value) all-entries))
    
+             hash-table)
    
+    (with-hash-table-iterator (generator-fn hash-table)
    
+      (loop     
    
+        ;;Note -- this is the "trivial" LOOP of CLtL p121
    
+        (multiple-value-bind (more? key value) (generator-fn)
    
+          (unless more? (return))
    
+          (unless (eql value (gethash key hash-table unique))
    
+            (error "Key ~S not found for value ~S" key value))
    
+          (push (list key value) generated-entries))))
    
+    (unless (= (length all-entries)
    
+               (length generated-entries)
    
+               (length (union all-entries generated-entries :test #'equal)))
    
+      (error "Generated entries and Maphash entries don't correspond"))
    
+    t))
    
+
    
+
    
+The following function should return T on any package, and signal
    
+an error if the usage of 'with-package-iterator' doesn't agree
    
+with the corresponding usage of 'do-symbols'.
    
+
    
+(defun test-package-iterator (package)
    
+  (unless (packagep package)
    
+    (setq package (find-package package)))
    
+  (let ((all-entries '())
    
+        (generated-entries '()))
    
+    (do-symbols (x package) 
    
+      (multiple-value-bind (symbol accessibility) 
    
+          (find-symbol (symbol-name x) package)
    
+        (push (list symbol accessibility) all-entries)))
    
+    (with-package-iterator (generator-fn package 
    
+                            :internal :external :inherited)
    
+      (loop     
    
+        ;;Note -- this is the "trivial" LOOP of CLtL p121
    
+        (multiple-value-bind (more? symbol pkg accessibility)
    
+            (generator-fn)
    
+          (unless more? (return))
    
+          (let ((l (multiple-value-list (find-symbol (symbol-name symbol) 
    
+                                                     package))))
    
+            (unless (equal l (list symbol accessibility))
    
+              (error "Symbol ~S not found as ~S in package ~A [~S]"
    
+                     symbol accessibility (package-name package) l))
    
+            (push l generated-entries)))))
    
+    (unless (and (subsetp all-entries generated-entries :test #'equal)
    
+                 (subsetp generated-entries all-entries :test #'equal))
    
+     (error "Generated entries and Do-Symbols entries don't correspond"))
    
+    t))
    
+
    
+
    
+The following function prints out every interned symbol (possibly
    
+more than once):
    
+
    
+(defun print-all-symbols () 
    
+  (with-package-iterator (next-symbol (list-all-packages)
    
+                          :internal :external)
    
+    (loop
    
+      ;;Note -- this is the "trivial" LOOP of CLtL p121
    
+      (multiple-value-bind (more? symbol) (next-symbol)
    
+        (if more? 
    
+           (print symbol)
    
+           (return))))))
    
+
    
+
    
+The following could be an acceptable definition of the function
    
+MAPHASH, implemented by WITH-HASH-TABLE-ITERATOR"
    
+
    
+(defun maphash (function hash-table)
    
+  (with-hash-table-iterator (next-entry hash-table)
    
+    (loop (multiple-value-bind (more key value) (next-entry)
    
+            (unless more (return nil))
    
+            (funcall function key value)))))
    
+
    
+
    
+Rationale:
    
+
    
+The particular way in which hash-tables and packages are represented
    
+need not be standardized, or even exposed to the user.  Yet a simpler 
    
+handle on them is needed for the various iteration paradigms to be written 
    
+in portable code.  In fact, after these iterator macros are put into an 
    
+implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages 
    
+of them; but no _efficient_ use of the current primitives will provide 
    
+the effect of the new macros, namely a form that _returns_ the elements
    
+of a table "one by one".
    
+
    
+
    
+Current Practice:
    
+
    
+Nobody does it this way, but both Symbolics and Lucid are not far off.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Moderate.  Possibly a couple day's to a week's work for an implementation 
    
+that has to start completely afresh.  Something like this is already being
    
+done by the standard package macros [CLtL, p187].
    
+
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+
    
+Benefits:
    
+
    
+Will provide a more basic primitive for iterating over hash-tables and 
    
+packages; will permit new iteration paradigms to be written in portable code.
    
+
    
+
    
+Aesthetics:
    
+
    
+All other things being equal, it is better to have more general primitives
    
+than less general ones.  
    
+
    
+
    
+Discussion:
    
+
    
+The Iteration Subcommittee supports this proposal (or, "used to" -- 
    
+JonL 6-Oct-88).
    
+
    
+One must be careful not to assume that the invocation (<next-fn>) is a 
    
+"generator" function call -- since <next-fn> is MACROLET'd in an 
    
+implementation dependent way, it could even turn into a special form like
    
+    (if something
    
+        (values nil)
    
+        (yet-another-function-call))
    
+
    
+The scoping called for herein may not be quite so useful to the "generators"
    
+style proposals; in particular they offer an interface wherein one may 
    
+create a "generator" function of indefinite extent that returns, one-by-one,
    
+the elements of the table.  The constrained scoping implicit in these
    
+WITH-... macros is not so much for any kind of optimization, but rather
    
+for coordination of such hash-table "locking" as may occur in multi-
    
+processing implementations like Symbolics.  Nevertheless, Dick Waters 
    
+thinks these macros should be put in anyway, since it clearly is a 
    
+requirement for a portable LOOP, and can be use in a limited context 
    
+(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
    
+
    
+Of course, if an implementation _can_ support an indefinite extent for
    
+a "generator" object returned out of the iterator forms, it is allowed 
    
+to do so by this proposal.
    
+
    
+The following macro definitions show how Common Lisp's DO-mumble-SYMBOLS 
    
+macros could have been defined in terms of WITH-PACKAGE-ITERATOR.  They 
    
+are intended as illustrative examples, not as new specifications of those 
    
+built-in Common Lisp facilities. [PARSE-BODY is as defined in Guy Steele's 
    
+"Clarifications" of 6-Dec-85.]
    
+
    
+(defmacro do-symbols ((var &optional (package `*package*) result-form)
    
+                      &body body 
    
+                      &environment env) 
    
+  (multiple-value-bind (body decls docstring) (parse-body body env)
    
+    `(with-package-iterator (next-symbol (list ,package)
    
+                             :internal :external :inherited)
    
+       (let (more? ,var)
    
+         ,@decls
    
+         (loop
    
+           (unless (multiple-value-setq (more? ,var) (next-symbol))
    
+             (setq ,var nil)
    
+             (return ,result-form))
    
+           ,@body)))))
    
+
    
+(defmacro do-external-symbols ((var &optional (package `*package*) result-form)
    
+                               &body body 
    
+                               &environment env) 
    
+  (multiple-value-bind (body decls docstring) (parse-body body env)
    
+    `(with-package-iterator (next-symbol (list ,package)
    
+                             :external)
    
+       (let (more? ,var)
    
+         ,@decls
    
+         (loop
    
+           (unless (multiple-value-setq (more? ,var) (next-symbol))
    
+             (setq ,var nil)
    
+             (return ,result-form))
    
+           ,@body)))))
    
+
    
+(defmacro do-all-symbols ((var &optional result-form) 
    
+                          &body body 
    
+                          &environment env) 
    
+  (multiple-value-bind (body decls docstring) (parse-body body env)
    
+    `(with-package-iterator (next-symbol (list-all-packages)
    
+                             :internal :external)
    
+       (let (more? ,var)
    
+         ,@decls
    
+         (loop
    
+           (unless (multiple-value-setq (more? ,var) (next-symbol))
    
+             (setq ,var nil)
    
+             (return ,result-form))
    
+           ,@body)))))
    
+
    
+-------
    
+"Why not define <next-fn> as a local function as if defined by
    
+    FLET rather than a macro as if defined by MACROLET? "
    
+
    
+"A macro gave more scope to the implememtation to optimize
    
+without losing anything essential in these circumstances."
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189.htm new file mode 100644 index 00000000..d95e3934 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue HASH-TABLE-REHASH-SIZE-INTEGER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue HASH-TABLE-REHASH-SIZE-INTEGER Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue HASH-TABLE-REHASH-SIZE-INTEGER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189_w.htm new file mode 100644 index 00000000..b845a577 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss189_w.htm @@ -0,0 +1,112 @@ + + + +CLHS: Issue HASH-TABLE-REHASH-SIZE-INTEGER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue HASH-TABLE-REHASH-SIZE-INTEGER Writeup

    + +
    Issue:		HASH-TABLE-REHASH-SIZE-INTEGER
    
+Reference:	Draft 8.81, p.19-3
    
+Category:	CLARIFICATION/CHANGE
    
+Edit History:	Version 1, 06/16/91, Kim Barrett
    
+		Version 2, 09/26/91, Steve Haflich, add Franz current practice
    
+		Version 3, 01/10/91, Steve Haflich, Lucid & Chestnut
    
+			 current practice
    
+
    
+Problem Description:
    
+
    
+ The semantics for the :REHASH-SIZE argument to MAKE-HASH-TABLE are unclear.
    
+ The description in the draft says it can be 
    
+
    
+   "an integer greater than zero, which is the number of entries to add, or it
    
+    can be a floating-point number greater than 1, which is the ratio of the
    
+    new size to the old size."
    
+
    
+ When the :REHASH-SIZE argument is an integer, it is unclear whether it is
    
+ expected to be scaled as the size is increased or if it is supposed to
    
+ indicate an expected additional number of entries to add.
    
+
    
+ At issue is whether a programmer can use the type of value provided for the
    
+ :REHASH-SIZE argument to give the implementation a hint as to the expected
    
+ growth rate for the table, with an integer indicating an additive growth rate
    
+ and a float indicating a multiplicative growth rate.
    
+
    
+Proposal:
    
+
    
+ Specify that if the :REHASH-SIZE argument is an integer then the
    
+ implementation may assume that the expected growth rate for the table is
    
+ additive, and that if the argument is a float then it may assume that the
    
+ expected growth rate is multiplicative.
    
+
    
+ Clarify that the value of the :REHASH-SIZE argument does not constrain the
    
+ implementation to use any particular method for computing the new size when
    
+ the hash table is enlarged.  The actual method for computing the new size is
    
+ implementation dependent and the :REHASH-SIZE argument only provides hints
    
+ from the programmer to the implementation.
    
+
    
+Editorial Impact:
    
+
    
+ An isolated change to MAKE-HASH-TABLE and HASH-TABLE-REHASH-SIZE.
    
+
    
+Rationale:
    
+
    
+ Provides a means for the programmer to reliably provide to the implementor a
    
+ particular piece of information about the programmer's intent, without
    
+ constraining the implementor to any particular implementation technique.
    
+
    
+Current Practice:
    
+
    
+ Symbolics Genera and IIM appear to use the :SIZE and integral :REHASH-SIZE
    
+ arguments to produce a ratio which is then used as the effective rehash size
    
+ in the same way as if a float with the same value had been specified for the
    
+ :REHASH-SIZE.
    
+
    
+ Lucid, Franz, and Chestnut conform to the interpretation of
    
+ :REHASH-SIZE here suggested.
    
+
    
+Discussion:
    
+
    
+ Pitman:
    
+  Only the application programmer knows whether new elements are expected to
    
+  arrive in an additive or multiplicative way.  All the implementation knows at
    
+  the time growth needs to occur is that there isn't room.  It can't tell how
    
+  many extra elements are coming.  And just because the computation on the size
    
+  is allowed to be slightly fuzzy, that doesn't mean it doesn't matter whether
    
+  the input to that computation should be allowed to be fuzzy.
    
+
    
+  Control of memory growth is a frequently cited reason for preferring C over
    
+  Lisp.  In some places, fixing the problems that underlie this is virtually a
    
+  research topic because no one can even figure out what they'd want to write
    
+  down in order to advise the program about what to do.  Controlled growth as
    
+  in vector-push-extend or hash-table-rehash-size is not in that camp.  To the
    
+  extent that we have a linguistic facilities begging for the opportunity to be
    
+  properly expressive, I see no reason to be vague--even if we're going to let
    
+  implementations do something a little different than what was asked for, we
    
+  should still define the language in such a way that the implementation at
    
+  least knows what was asked for.  Both of the possible values (integers and
    
+  floats) are potentially meaningful in distinct ways, and trivial to
    
+  implement, so why blur their intent?
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190.htm new file mode 100644 index 00000000..4078408a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue HASH-TABLE-SIZE:INTENDED-ENTRIES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue HASH-TABLE-SIZE:INTENDED-ENTRIES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue HASH-TABLE-SIZE:INTENDED-ENTRIES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190_w.htm new file mode 100644 index 00000000..010cd511 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss190_w.htm @@ -0,0 +1,105 @@ + + + +CLHS: Issue HASH-TABLE-SIZE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue HASH-TABLE-SIZE Writeup

    + +
    Status: Passed, as amended here, Jun 89 X3J13
    
+Issue:         HASH-TABLE-SIZE
    
+References:    CLtL p.283
    
+Category:      CLARIFICATION
    
+Edit history:  Version 1, 20-Mar-89, by Moon
    
+		Version 2, 1-Jul-89, by Masinter (per Jun89 X3J13 amendments)
    
+ 
    
+Problem description:
    
+  
    
+  CLtL contradicts itself on the meaning of the :SIZE argument to
    
+  MAKE-HASH-TABLE.  At the top of p.283, it says that the size is "the
    
+  maximum number of entries it can hold.  Usually the actual capacity of
    
+  the table is somewhat less."  At the bottom of the page it says "this
    
+  argument serves as a hint to the implementation of approximately how
    
+  many entries you intend to store."  So does the :SIZE intended to be the
    
+  actual capacity of the table, or the amount of storage allocated to hold
    
+  the table.  For example, if the implementation of hash tables is
    
+  designed for a loading of 65%, and the user specifies :SIZE 100, does
    
+  the table returned have space allocated for 100 entries, so that it
    
+  overflows and becomes bigger when 65 entries are inserted, or does the
    
+  table have space allocated for 154 entries, so that it overflows and
    
+  becomes bigger when 100 entries are inserted?
    
+
    
+Proposal (HASH-TABLE-SIZE:INTENDED-ENTRIES):
    
+
    
+  Believe the bottom of p.283 rather than the top.  The :SIZE argument
    
+  is approximately the number of entries that can be inserted without
    
+  the table having to grow.
    
+
    
+  Keep the first and last sentences of the definition of :REHASH-THRESHOLD
    
+  (CLtL p. 284.) Replace the rest with:
    
+  "This can be a REAL between 0 and 1, inclusive, which is a hint to the
    
+  implementation of the maximum desired hash table occupancy level. An
    
+  implementation is permitted to ignore this argument."
    
+
    
+Editorial consequences:
    
+  Remove the second complete paragraph of CLtL p. 283. It's too implementa-
    
+  tion-dependent. Clarify the implementation is not necessarily an actual
    
+  hash table of any particular hashing technique.
    
+
    
+Rationale:
    
+  
    
+  The bottom of p.283 is user-oriented, the top is implementation-oriented.
    
+  User-oriented seems more appropriate.
    
+
    
+Current practice:
    
+  
    
+  Symbolics Genera 7.4 adheres to HASH-TABLE-SIZE:INTENDED-ENTRIES.
    
+  Other implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+  At worst adding a multiplication to MAKE-HASH-TABLE.
    
+
    
+Cost to Users:
    
+
    
+  Probably none, but it is hard to predict.
    
+
    
+Cost of non-adoption:
    
+  
    
+  Implementations will probably vary in which of the two interpretations
    
+  they believe.  The language standard will not be self-consistent.
    
+
    
+Performance impact:
    
+
    
+  None of any significance.
    
+
    
+Benefits/Esthetics:
    
+
    
+  More self-consistent language.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191.htm new file mode 100644 index 00000000..ebe57f02 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue HASH-TABLE-TESTS:ADD-EQUALP Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue HASH-TABLE-TESTS:ADD-EQUALP Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue HASH-TABLE-TESTS:ADD-EQUALP:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191_w.htm new file mode 100644 index 00000000..21a1c9a4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss191_w.htm @@ -0,0 +1,164 @@ + + + +CLHS: Issue HASH-TABLE-TESTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue HASH-TABLE-TESTS Writeup

    + +
    Status:	Passed, Jan 89 X3J13
    
+Issue: 		HASH-TABLE-TESTS
    
+
    
+References: 	CLtL, p382 (third paragraph), and p383
    
+            	Issue EQUAL-STRUCTURE
    
+Requires Issue:   CONTAGION-ON-NUMERICAL-COMPARISONS
    
+
    
+Category:         Addition
    
+
    
+Edit history:  	26-Sep-88 Version 1 by JonL
    
+               	 8-Dec-88 Version 2 by Masinter
    
+
    
+Problem Description:
    
+
    
+A great many users try to coalesce two equivalent DEFSTRUCT instances,
    
+or two equivalent pointer arrays, using hash tables; but they are rudely
    
+awakened when they find out that EQUAL is not an appropriate test for
    
+this case, and that there is no :test argument to MAKE-HASH-TABLE which 
    
+will "hash on non-tree structures".
    
+
    
+Proposal: HASH-TABLE-TESTS:ADD-EQUALP
    
+
    
+With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
    
+can expect EQUALP to be a true equivalence function, and thus a suitable
    
+candidate for the :test function to MAKE-HASH-TABLE.   Hash-tables will 
    
+come in four kinds, the difference being whether the keys are compared 
    
+with EQ, EQL, EQUAL, or EQUALP.
    
+
    
+
    
+Examples:
    
+
    
+> (defstruct foo a b c)
    
+FOO
    
+> (setq x      (make-foo :a 1 :b 'b :c '(1 . 2))
    
+        x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
    
+#S(FOO A 1 B B C (1 . 2))
    
+> (setq y      #(1 B (1 . 2))
    
+        y-copy (copy-seq y))
    
+#(1 B (1 . 2))
    
+> (setq ht-equal  (make-hash-table :test 'equal) 
    
+        ht-equalp (make-hash-table :test 'equalp))
    
+
    
+#<Hash-Table BB1F7B>
    
+> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t) 
    
+         (setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
    
+T
    
+> (gethash x-copy ht-equal)
    
+NIL
    
+NIL
    
+> (gethash x-copy ht-equalp)
    
+T
    
+T
    
+> (gethash y-copy ht-equal)
    
+NIL
    
+NIL
    
+> (gethash (copy-seq y) ht-equalp)
    
+T
    
+T
    
+> 
    
+
    
+
    
+Rationale:	
    
+
    
+Implementing hash-tables efficiently is not an easy task; it makes more
    
+sense for this to be standardly available than for individual programmers 
    
+to keep trying to re-invent this obscure part of technology.
    
+
    
+
    
+Current Practice:
    
+
    
+Lucid's release 3.0 implements this proposal [some 2.1-level release
    
+supported it "provisionally"].  Symbolics implementation is reputed
    
+to be robust enough to implement this proposal trivially.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Moderate.  Implementors have already dealt with EQUAL; the only tricky 
    
+part will be ensuring the implication:
    
+    "If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
    
+     same collision chain in any given EQUALP hash table"
    
+It has been suggested that merely linear searching a table is an acceptable
    
+implementation technique for CL's hash-tables  [although no serious 
    
+implementation limits itself thus] and that such tables have no "collision 
    
+chains"; but in fact, this is the degenerate case wherein all entries are 
    
+in the same collision chain, so the implication is trivially satisfied.
    
+
    
+Some persons prefer to say that the "reprobe sequence will be the same for
    
+the two items", rather than using the term "collision chain"; the meaning 
    
+is the same. 
    
+
    
+
    
+
    
+Cost to Users:
    
+
    
+None.  This is an entirely upwards-compatible addition.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+Continuing bug reports from users  about why "hashing 
    
+doesn't work" when said user tries entering pointer-containing objects
    
+other than cons cells into hash tables.  Continuing delay in same
    
+user's work until they figure out a new strategy for identifying
    
+equivalent structures.  More difficulty in debugging their alternatives.
    
+
    
+
    
+Benefits:
    
+
    
+Addresses one aspect of the difficult equivalence problem.  Makes
    
+hash tables more useful.  Permits case-insensitive hashing
    
+on strings [tables of type EQUAL are case-sensitive on strings]; 
    
+another use is to allow = comparison for numbers
    
+ [tables of type EQUAL use EQL on numbers].
    
+
    
+
    
+Aesthetics:
    
+
    
+Reduces the discontinuity between basic equivalence functions and those
    
+usable as equivalence relations in hash-tables.
    
+
    
+
    
+Discussion:
    
+
    
+With the rejection of all the issues related to EQUAL-STRUCTURE, there is 
    
+little or no hope that EQUAL will be "beefed up" to meet the expectations
    
+of so many of the user community on compound structures.   If one wants
    
+a hash-table with a :test function that has fewer equivalence classes 
    
+(i.e.,  does more "coalescing"), then there is no alternative now except 
    
+to use the function EQUALP.
    
+
    
+It would also be possible to extend hash tables to allow = or
    
+STRING=, but those are not being proposed at this time.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192.htm new file mode 100644 index 00000000..f111d7dc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue IEEE-ATAN-BRANCH-CUT:SPLIT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue IEEE-ATAN-BRANCH-CUT:SPLIT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue IEEE-ATAN-BRANCH-CUT:SPLIT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192_w.htm new file mode 100644 index 00000000..7b18547b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss192_w.htm @@ -0,0 +1,158 @@ + + + +CLHS: Issue IEEE-ATAN-BRANCH-CUT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue IEEE-ATAN-BRANCH-CUT Writeup

    + +
    Status:	Passed, Jan 89 X3J13
    
+Forum:         Cleanup
    
+Issue:         IEEE-ATAN-BRANCH-CUT
    
+References:    CLtL p.203-214
    
+Related issues: COMPLEX-ATAN-BRANCH-CUT
    
+Category:      CHANGE
    
+
    
+Edit history:  Version 1, 13-Dec-88, Steele
    
+               Version 2, 11-Jan-89, Masinter 
    
+
    
+Problem description:
    
+
    
+If an implementation provides a floating-point minus zero as well as a
    
+floating-point plus zero, most notably as in IEEE 754 floating-point
    
+arithmetic, then slight adjustments in the branch cuts of transcendental
    
+functions are appropriate.
    
+
    
+If there is a minus zero and a plus zero, then *no* complex number
    
+is actually "on the axis" whether real or imaginary.  Instead,
    
+numbers of the form x+0i and x-0i straddle the real axis, and those
    
+of the form 0+xi and -0+xi straddle the imginary axis.  Branch cuts
    
+that lie on the axes therefore run between such numbers, and directions
    
+of continuity are not an issue.
    
+
    
+Proposal (IEEE-ATAN-BRANCH-CUT:SPLIT):
    
+
    
+Redefine the branch cut for two-argument ATAN, covering
    
+the cases where there is or is not a minus zero, and then redefine *all*
    
+other functions that have branch cuts in terms of two-argument ATAN.
    
+Specifically, we first define PHASE in terms of two-argument ATAN,
    
+and complex ABS in terms of real SQRT (which has no branch cut problems);
    
+then define complex LOG in terms of PHASE, ABS, and real LOG; then define
    
+complex SQRT in terms of LOG; and then define all others in terms of these.
    
+
    
+In this propoal Lisp expressions should be taken as mathematical
    
+formulas that actually are implemented in other ways for improved accuracy.
    
+
    
+(1) If there is no minus zero, two-argument ATAN behaves as in CLtL.
    
+    If there is a minus zero, then some cases are modified:
    
+	Condition			result
    
+	y=+0  x>0			   +0
    
+	y=-0  x>0			   -0
    
+	y=+0  x<0			   +pi
    
+	y=-0  x<0			   -pi
    
+	y=+0  x=+0			   +0
    
+	y=-0  x=+0			   -0
    
+	y=+0  x=-0			   +pi
    
+	y=-0  x=-0			   -pi
    
+    The range of two-argument atan therefore includes -pi in this case.
    
+
    
+    Note that the case y=0 x=0 is an error in the absence of minus zero,
    
+    but is defined in the presence of minus zero.
    
+
    
+(2) (PHASE X) = (ATAN (IMAGPART X) (REALPART X)), as before, but now
    
+    the range of PHASE may include -PI if there is a minus zero.
    
+
    
+(3) (ABS X) = (SQRT (+ (* (REALPART X) (REALPART X))
    
+		       (* (IMAGPART X) (IMAGPART X)))), as before
    
+
    
+(4) (LOG X) = (COMPLEX (LOG (ABS X)) (PHASE X))
    
+
    
+(5) (SQRT X) = (EXP (/ (LOG X) 2))
    
+
    
+(6) For EXPT, ASIN, ACOS, ATAN, ASINH, ACOSH, ATANH use the formulas
    
+    in CLtL pp. 211-213, but use the formulas (1-5) above as the
    
+    definitions of LOG and SQRT in order to determine the branch cuts
    
+    properly.
    
+
    
+Examples:
    
+
    
+(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...)	;Current
    
+(LOG #c(-1.0 -0.0)) => #c(0.0 3.14159...)	;Current
    
+
    
+(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...)	;Proposed (= current)
    
+(LOG #c(-1.0 -0.0)) => #c(0.0 -3.14159...)	;Proposed (conjugate)
    
+
    
+Rationale:
    
+
    
+The current specification ignores some natural consequences of IEEE
    
+floating-point arithmetic.  The proposed specification produces results
    
+more natural to that arithmetic.
    
+
    
+  
    
+Current practice:
    
+
    
+Of implementations that support a minus zero that I have checked,
    
+such as Sun-4 CL 2.1.3 of 10-Nov-88 and Symbolics CL, all follow
    
+the current CLtL specification.
    
+
    
+The IEEE trig library atan2 routine written by K.C. Ng (with the advice
    
+or supervision of W. Kahan, I believe), and distributed with BSD UNIX
    
+(it is file /usr/src/usr.lib/libm/IEEE/atan2.c on my machine) follows
    
+this proposal for treatment of minus zero.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Some of the trig routines will require some rewriting.  Probably certain
    
+tests that are now written using ZEROP need to be rewritten to use
    
+FLOAT-SIGN instead.
    
+
    
+
    
+Cost to Users:
    
+
    
+It is barely conceivable that some user code could depend on this.
    
+Probably there is no cost.
    
+
    
+The compatibility note on p. 210 of CLtL gave users fair warning that
    
+a change of this kind might be adopted.
    
+
    
+Cost of non-adoption:
    
+
    
+Unnatural treatment of some functions on machines supporting IEEE
    
+floating-point arithmetic.
    
+
    
+Benefits:
    
+
    
+Natural treatment, etc.
    
+
    
+Esthetics:
    
+
    
+A toss-up, except to those who care.
    
+
    
+Discussion:
    
+
    
+Steele has sent a letter to W. Kahan at Berkeley to get any last
    
+comments he may have on the matter.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193.htm new file mode 100644 index 00000000..28de16a3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue IGNORE-USE-TERMINOLOGY:VALUE-ONLY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue IGNORE-USE-TERMINOLOGY:VALUE-ONLY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue IGNORE-USE-TERMINOLOGY:VALUE-ONLY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193_w.htm new file mode 100644 index 00000000..6a04c1fb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss193_w.htm @@ -0,0 +1,121 @@ + + + +CLHS: Issue IGNORE-USE-TERMINOLOGY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue IGNORE-USE-TERMINOLOGY Writeup

    + +
    Forum:		Public Review
    
+Issue:		IGNORE-USE-TERMINOLOGY
    
+References:	Barrett's public review comment #30
    
+		IGNORE, IGNORABLE
    
+Category:	CLARIFICATION
    
+Edit history:	21 Dec 1992, Version 1 by Loosemore
    
+Status:		Proposal VALUE-ONLY passed (7+1)-2 on letter ballot 93-302
    
+
    
+
    
+Problem description:
    
+
    
+  In the description of the IGNORE declaration, there are several
    
+  occurances of "use", "used", "referred to", and "referenced", which
    
+  are not well specified.  The question is, what constitutes a use of a
    
+  binding.  Are only references for value considered to be "uses~, or
    
+  should references as a place to modify also be considered "uses"?
    
+  Implementations differ on this question, making it very difficult to
    
+  use the IGNORE declaration in portable code.
    
+
    
+  There are two proposals, VALUE-ONLY and VALUE-AND-ASSIGNMENT.
    
+
    
+
    
+Proposal (IGNORE-USE-TERMINOLOGY:VALUE-ONLY):
    
+
    
+  Change the description of the IGNORE and IGNORABLE declarations to
    
+  use the glossary term "reference" throughout.
    
+
    
+  Clarify that, for the purposes of IGNORE and IGNORABLE, a "reference"
    
+  includes only references for value.  
    
+
    
+
    
+Proposal (IGNORE-USE-TERMINOLOGY:VALUE-AND-ASSIGNMENT):
    
+ 
    
+  Change the description of the IGNORE and IGNORABLE declarations to
    
+  use the glossary term "reference" throughout.
    
+
    
+  Clarify that, for the purposes of IGNORE and IGNORABLE, a "reference"
    
+  includes both references for value and variable assignments.
    
+
    
+
    
+Rationale:
    
+
    
+  Either one of these proposals would address the problem.
    
+
    
+
    
+Current practice:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Probably small.
    
+
    
+
    
+Cost to users:
    
+
    
+  Probably small.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Specifying this behavior is more aesthetic than leaving it unspecified.
    
+
    
+
    
+Editorial impact:
    
+
    
+  The changes are confined to the dictionary entry for IGNORE and
    
+  IGNORABLE.
    
+
    
+
    
+Discussion:
    
+
    
+  Barrett has indicated he prefers proposal VALUE-ONLY, but Loosemore
    
+  thinks that having variables that can be assigned to but not
    
+  referenced are of questionable utility.
    
+
    
+  While researching this issue, Loosemore noted that the provision
    
+  about the behavior of IGNORE (and presumably IGNORABLE) from issue
    
+  MACRO-DECLARATIONS had not been incorporated into draft 12.24.  Can
    
+  we give the editor authority to remedy this?  
    
+
    
+
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194.htm new file mode 100644 index 00000000..95fbbbaa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue IMPORT-SETF-SYMBOL-PACKAGE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue IMPORT-SETF-SYMBOL-PACKAGE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue IMPORT-SETF-SYMBOL-PACKAGE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194_w.htm new file mode 100644 index 00000000..ea5feac8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss194_w.htm @@ -0,0 +1,74 @@ + + + +CLHS: Issue IMPORT-SETF-SYMBOL-PACKAGE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue IMPORT-SETF-SYMBOL-PACKAGE Writeup

    + +
    Issue:        IMPORT-SETF-SYMBOL-PACKAGE
    
+References:   IMPORT (CLtL p. 186)
    
+Category:     CLARIFICATION.
    
+Edit History: Version 2 at committee meeting 15-Mar-87 15:19:23
    
+              Version 3 by Masinter 15-Mar-87 18:42:13
    
+              Version 4 29-May-87 by Masinter, remove confusing
    
+                "to further clarify".
    
+              Version 5 to X3J13
    
+
    
+Problem Description:
    
+
    
+The action of IMPORT on the home package of a symbol is not described
    
+well; does it affects the "home package" of a symbol.
    
+
    
+Proposal (IMPORT-SETF-SYMBOL-PACKAGE:YES):
    
+
    
+IMPORT behaves as follows: if any symbol to be imported has no home
    
+package (SYMBOL-PACKAGE returns NIL), then IMPORT sets the home package
    
+of the symbol to the specified package being imported to.
    
+
    
+Rationale:
    
+
    
+Current practice:
    
+
    
+Most Common Lisp implementations work this way. 
    
+
    
+Adoption Cost:
    
+
    
+small -- it requires a simple rewrite if not done this way.
    
+
    
+Benefits:
    
+
    
+Without this proposal, there is confusion about how Common Lisp works,
    
+and the risks that some new implementations will not work this way.
    
+
    
+Conversion Cost:
    
+
    
+None, as this describes current practice.   
    
+
    
+Discussion: 
    
+
    
+The cleanup committee supports this clarification.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195.htm new file mode 100644 index 00000000..1b755e43 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195_w.htm new file mode 100644 index 00000000..cb3884fa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss195_w.htm @@ -0,0 +1,182 @@ + + + +CLHS: Issue IN-PACKAGE-FUNCTIONALITY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue IN-PACKAGE-FUNCTIONALITY Writeup

    + +
    Status: 	proposal MAR89-X3J13 passed, as amended, Mar 89 X3J13
    
+Issue:          IN-PACKAGE-FUNCTIONALITY
    
+References:     IN-PACKAGE (p182-183)
    
+Category:       CHANGE
    
+Edit history:   07-Jul-88, Version 1 by Pitman
    
+                 7-Oct-88, Version 2 by Masinter (discussion)
    
+                 8-Dec-88, Version 3 by Masinter
    
+                12-Dec-88, Version 4 by Masinter
    
+                20-Jan-89, Version 5 by Loosemore
    
+                30-Jan-89, Version 6 by Loosemore
    
+                10-Mar-89, Version 7 by Loosemore
    
+                15-Mar-89, Version 8 by Masinter (add back SELECT-ONLY)
    
+                 9-Apr-89, Verison 9 by Masinter, as amended Mar 89 X3J13,
    
+				and discussion updated.
    
+
    
+Related-Issues: DEFPACKAGE (passed)
    
+		COMPILE-FILE-SYMBOL-HANDLING
    
+
    
+Problem Description:
    
+
    
+  There are two typical uses for IN-PACKAGE -- to define/create a package
    
+  and to select a package. The fact that these two purposes have been
    
+  given to the same function has led to reduced error checking.
    
+
    
+  A more general problem is that the "Put In Seven Extremely Randoms" 
    
+  convention described in CLtL is now recognized by many people as being
    
+  unsatisfactory for both package definition and package selection.
    
+  The DEFPACKAGE macro provides a much cleaner mechanism for package
    
+  definition, but there is still a need for a convenient way to select
    
+  a package that has well-defined compilation semantics.
    
+
    
+
    
+Proposal (IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13):
    
+
    
+  Change IN-PACKAGE from a function to a macro:
    
+
    
+    IN-PACKAGE name						[macro]
    
+
    
+    This macro causes *PACKAGE* to be set to the package named NAME,
    
+    which must be a symbol or string.  An error is signalled if the
    
+    package does not already exist.  Everything this macro does is also
    
+    performed at compile time if the call appears at top-level.
    
+
    
+  Remove the second paragraph of section 11.7 in CLtL.  (This includes
    
+  the requirement for special compile-time treatment of the various
    
+  package functions.)
    
+
    
+  Rationale:
    
+
    
+    This could allow improved error checking and modularity, with only
    
+    minimal loss of functionality.
    
+
    
+    Making IN-PACKAGE a macro rather than a function means that there
    
+    is no need to require COMPILE-FILE to handle it specially.  Since
    
+    DEFPACKAGE is also defined to side-effect the compilation environment,
    
+    there is no need to require any of the package functions to be treated
    
+    specially by the compiler.
    
+
    
+    The language in section 11.7 of CLtL puts the burden on
    
+    implementations of ensuring that all symbols in a file which is
    
+    compiled and loaded end up in the same package that they would if the
    
+    source file were loaded interpretively.  No implementation can
    
+    possibly meet this requirement because, in general, the runtime
    
+    behavior of the program cannot be predicted by the compiler.
    
+
    
+  Current Practice:
    
+
    
+    Probably no one implements this behavior exactly since it's an 
    
+    incompatible change to CLtL.
    
+
    
+  Cost to Implementors:
    
+
    
+    The SELECT-PACKAGE macro can be implemented trivially by using 
    
+    EVAL-WHEN in its expansion:
    
+
    
+    (defmacro select-package (name)
    
+        `(eval-when (eval compile load)
    
+	     (setq *package*
    
+	           (or (find-package ',name)
    
+		       (error "Package ~s does not exist." ',name)))))
    
+
    
+    The changes required to COMPILE-FILE to remove the magic treatment
    
+    of the package functions are also likely to be small.
    
+
    
+  Cost to Users:
    
+
    
+    In most cases, minor syntactic changes to some files would be
    
+    necessary.  Programmers that are now using the "Put In Seven
    
+    Extremely Randoms" convention will probably find it straightforward
    
+    to convert their code to do a DEFPACKAGE followed by a 
    
+    SELECT-PACKAGE.
    
+
    
+  Cost of Non-Adoption:
    
+
    
+    The specification of COMPILE-FILE will be much more difficult to
    
+    understand.
    
+
    
+    The standard will require compilers to solve the halting problem.
    
+
    
+  Benefits:
    
+
    
+    Modular package declarations would be encouraged and errors due
    
+    to demand-creation of packages would be easier to detect.
    
+
    
+    The specification of COMPILE-FILE will be simplified.
    
+
    
+    There will be a clear statement of the requirements for program
    
+    conformance, as relating to usage of packages.
    
+
    
+  Aesthetics:
    
+
    
+    The fact that IN-PACKAGE is currently ambiguous about intent (whether
    
+    the package should exist already or not) is clearly not aesthetic.
    
+    Removing it can't be any worse.
    
+
    
+    The fact that the currently stated requirements for handling of
    
+    the package functions by the compiler are not implementable is
    
+    clearly not aesthetic.
    
+Discussion:
    
+
    
+  The dual use of IN-PACKAGE has not been helpful and is confusing.
    
+
    
+  This is an incompatible change.
    
+
    
+KMP's notes of the Mar 89 X3J13:
    
+
    
+ On Tuesday, we took a straw poll.
    
+   0 opposed both proposals.
    
+  15 liked NEW-MACRO.
    
+   7 liked SELECT-ONLY.
    
+ ``Keeping IN-PACKAGE makes no difference to compatibility.'' --Moon
    
+ Pitman moved to amend this to say "deprecate" instead of remove.
    
+ The motion to amend failed 3-N.
    
+ The NEW-MACRO proposal passed unamended 12-4.
    
+
    
+ On Thursday, Aaron Larson and JonL asked that the issue be reconsidered.
    
+ The motion to reconsider passed N-1.
    
+ There was a motion to rename the SELECT-PACKAGE which we'd voted in to
    
+ IN-PACKAGE -- so that the compatible syntax (IN-PACKAGE "FOO") would work
    
+ in CLtL and ANSI CL.
    
+ Steele requested verbal clarification that we were not trying to solve
    
+ the ``dusty file'' problem but rather to make it possible to write new code
    
+ that worked in old and new situations -- it was agreed that this was a
    
+ correct characterization of the proposal.
    
+ JonL's amendment passed 13-1.
    
+ Then the amended proposal was voted in 14-0.
    
+
    
+The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
    
+changed to IN-PACKAGE.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196.htm new file mode 100644 index 00000000..f0b8efc2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue IN-SYNTAX:MINIMAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue IN-SYNTAX:MINIMAL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue IN-SYNTAX:MINIMAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196_w.htm new file mode 100644 index 00000000..8646c5e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss196_w.htm @@ -0,0 +1,105 @@ + + + +CLHS: Issue IN-SYNTAX Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue IN-SYNTAX Writeup

    + +
    Status: Passed, Mar 89 X3J13
    
+Issue: IN-SYNTAX
    
+Edit History: 21-Oct-88, Version 1 by Pitman
    
+		Version 2, KMP 3/30/89
    
+		Version 3,  9-Apr-89, Masinter
    
+			(Include discussion from Version 1)
    
+
    
+Problem Description:
    
+
    
+  There is no way to bind read syntax within a file.
    
+
    
+  As a result, applications which require extended syntax of some sort
    
+  tend to globally modify the lisp readtable at compile and load time,
    
+  sometimes interfering with other modules and/or user interaction.
    
+
    
+  Conscientious developers often avoid the creation of any stylized
    
+  syntax because of its likely effect on parts of the environment which
    
+  don't really belong to the application developer. This need for
    
+  paranoia is probably contrived and the result of what amounts to
    
+  an oversight in the design of Common Lisp.
    
+
    
+
    
+Proposal (IN-SYNTAX:MINIMAL):
    
+
    
+    Define that COMPILE-FILE and LOAD bind *READTABLE* to its current value.
    
+
    
+Rationale:
    
+
    
+   This allows portable programs to do
    
+
    
+     (IN-PACKAGE "FOO")
    
+     (EVAL-WHEN (EVAL LOAD COMPILE)
    
+       (SETQ *READTABLE* FOO:MY-READTABLE))
    
+
    
+   at the top of a file without globally side-effecting the
    
+   environment.
    
+
    
+   Currently, there is no portable way to change the syntax only for
    
+   the duration of a file, which in turn makes customized syntax
    
+   difficult to use safely.
    
+
    
+   Programs that want to side effect the environment can instead
    
+   continue to modify *READTABLE*.
    
+
    
+    This is enough of a foothold to implement a more elaborate facility
    
+    for using readtables in a localized way.
    
+
    
+
    
+Current Practice:
    
+
    
+   mixed
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+Cost to Users:
    
+
    
+small
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Readtables would continue to be hard to use in a clean way.
    
+
    
+Benefits:
    
+
    
+  If people could use readtables safely, we might see more interesting
    
+  experimentation with read syntax.
    
+
    
+Aesthetics:
    
+
    
+  A slight improvement to aesthetics by controlling what was formerly
    
+  an unbounded side-effect (modification to the global readtable).
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197.htm new file mode 100644 index 00000000..27629bdc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197.htm @@ -0,0 +1,44 @@ + + + +CLHS: Issue INITIALIZATION-FUNCTION-KEYWORD-CHECKING Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue INITIALIZATION-FUNCTION-KEYWORD-CHECKING Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue INITIALIZATION-FUNCTION-KEYWORD-CHECKING:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197_w.htm new file mode 100644 index 00000000..2e53e574 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss197_w.htm @@ -0,0 +1,224 @@ + + + +CLHS: Issue INITIALIZATION-FUNCTION-KEYWORD-CHECKING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue INITIALIZATION-FUNCTION-KEYWORD-CHECKING Writeup

    + +
    Status: Passed v4 (8-1), as amended, Dec-91; v5 reflects the amendment
    
+Issue:          INITIALIZATION-FUNCTION-KEYWORD-CHECKING
    
+Reference:      Draft 10.156
    
+		  7.2.1.1 Initialization Arguments (p.7-6)
    
+		    (which corresponds to CLtL-II 28.1.9.1, p.802)
    
+		  7.2.1.2 Declaring the Validity of Initialization Arguments
    
+		    (p.7-7) (which corresponds to CLtL-II 28.1.9.2, p.803)
    
+		  7.3.5 Keyword Arguments in Generic Functions and Methods
    
+		    (p.7-20) (which corresponds to CLtL-II 28.1.6.5, p.792)
    
+Category:       CHANGE
    
+Edit History:   Version 1, 10/2/91, Kim Barrett
    
+		Version 2, 10/8/91, Kim Barrett (Moon & JonL comments)
    
+		Version 3, 10/11/91, Kim Barrett (more Moon comments)
    
+		Version 4, 11/20/91, Kim Barrett
    
+		  (clarify :allow-other-keys, make references to 10.156 draft)
    
+		Version 5, 11-Feb-92, Kent Pitman
    
+		  ("has no effect on" => "suppresses" per X3J13 meeting amendment)
    
+
    
+Problem Description:
    
+
    
+ A careful reading of 88-002R indicates that users must specify
    
+ &ALLOW-OTHER-KEYS in the lambda-lists of methods for initialization functions
    
+ if the method also specifies &KEY, else risk having the generic function
    
+ keyword argument checking signal an error due to the presence of "slot
    
+ filling" initargs.  (An error might not occur due to the presence of other
    
+ methods which already specify &KEY + &ALLOW-OTHER-KEYS).
    
+
    
+ Several implementors (and presumably users too) have misread the specification
    
+ as saying that &ALLOW-OTHER-KEYS in an applicable initialization method means
    
+ that initarg validation is suppressed for those protocols in which the method
    
+ takes part.
    
+
    
+ The result is that the need for and meaning of &ALLOW-OTHER-KEYS in
    
+ initialization methods differs significantly from one implementation to
    
+ another. 
    
+
    
+Proposal:
    
+
    
+ 1. Change the syntax of the following generic functions to specify both &KEY
    
+ and &ALLOW-OTHER-KEYS:
    
+
    
+   ALLOCATE-INSTANCE class &key &allow-other-keys
    
+   INITIALIZE-INSTANCE object &key &allow-other-keys
    
+   MAKE-INSTANCE class &key &allow-other-keys
    
+   REINITIALIZE-INSTANCE object &key &allow-other-keys
    
+   SHARED-INITIALIZE object slot-names &key &allow-other-keys
    
+   UPDATE-INSTANCE-FOR-DIFFERENT-CLASS previous current
    
+				       &key &allow-other-keys
    
+   UPDATE-INSTANCE-FOR-REDEFINED-CLASS object
    
+				       added-slots discarded-slots
    
+				       property-list
    
+				       &key &allow-other-keys
    
+
    
+ It is of course possible to retain "&rest initargs" in the syntax description
    
+ when needed in the corresponding function description.
    
+
    
+ 2. Clarify that the presence of &ALLOW-OTHER-KEYS in the lambda-list of an
    
+ applicable method relevant to the specified initarg validity checking for an
    
+ initialization protocol suppresses the validity checking.
    
+
    
+ 3. Clarify that a true value for the initialization argument :ALLOW-OTHER-KEYS
    
+ disables initialization argument validation.  Make the following changes Draft
    
+ 10.156 in order make this clarification.
    
+
    
+  a. Remove the last sentence of the second paragraph of section 7.2.1.1
    
+  (p.7-6), which says
    
+
    
+   "Error checking of initialization argument names is disabled if the keyword
    
+    argument pair whose keyword is :ALLOW-OTHER-KEYS and whose value is non-NIL
    
+    appears in the initialization argument list."
    
+
    
+  b. Replace the last sentence of section 7.2.1.2 (p.7-7), which says
    
+
    
+   "The meaning of:ALLOW-OTHER-KEYS is the same here as when it is passed to an
    
+    ordinary function."
    
+
    
+  with
    
+
    
+   "Validity checking of initialization arguments is disabled if the value of
    
+    the initialization argument :ALLOW-OTHER-KEYS is true."
    
+
    
+Editorial impact:
    
+
    
+ The syntax entries for seven functions need to be modified.
    
+
    
+ A small change to "Declaring the Validity of Initialization Arguments" is
    
+ needed in order to clarify the handling of &ALLOW-OTHER-KEYS in initialization 
    
+methods.
    
+
    
+Rationale:
    
+
    
+ Since &ALLOW-OTHER-KEYS needs to be specified somewhere if &KEY is specified
    
+ by any of the applicable methods, it is better to have the generic function
    
+ specify it, rather than requiring programmers to remember to include it in
    
+ every initialization method that also specifies &KEY.
    
+
    
+Examples:
    
+
    
+ (defclass test ()
    
+     ((slot :initarg :slot-filler))
    
+   )
    
+
    
+ (defmethod initialize-instance :after ((x test) &key) nil)
    
+ (make-instance 'test :slot-filler 5)
    
+   -> currently might signal an error
    
+   -> returns instance of test under proposed change.
    
+
    
+Current Practice:
    
+
    
+ Both Lucid 4.0 and IIM 3.4 specify only &REST in the lambda-lists of the
    
+ listed generic functions and the specified methods for those functions, with
    
+ the implication that user defined methods which specify &KEY must also specify
    
+ &ALLOW-OTHER-KEYS in order to inhibit keyword argument checking by the generic
    
+ function from signaling an error due to the presence of "slot filling"
    
+ initargs.  However, because generic function keyword checking has not yet been
    
+ implemented in either Lucid 4.0 or IIM 3.4, users may not be aware of this
    
+ requirement.  In fact, in IIM 3.4 there are system-supplied initialization
    
+ methods that fail to meet this requirement, so there are some implementors who
    
+ aren't aware of this problem either.
    
+
    
+ Franz Allegro 4.0 appears to have the same behavior as described above for
    
+ Lucid 4.0 and IIM 3.4.  In particular, generic function keyword checking has
    
+ not yet been implemented.
    
+
    
+ Symbolics CLOS and Chestnut's Lisp-to-C translator both specify &KEY and
    
+ &ALLOW-OTHER-KEYS in the lambda-lists of the listed generic functions.  In
    
+ addition, if an applicable method for one of the protocols specifies
    
+ &ALLOW-OTHER-KEYS then the specified initarg checking for the protocol is not
    
+ performed.
    
+
    
+ Macintosh Common Lisp 2.0b3c4 has "&KEY &ALLOW-OTHER-KEYS" in the lambda list
    
+ for MAKE-INSTANCE, but all the others just use "&REST". This asymmetry is an
    
+ oversight due to the fact that the method combination code special cases them,
    
+ and elides normal generic function keyword checking for all of them (hence it
    
+ has never appeared as a "bug").  MCL (like Symbolics and Chestnut) also
    
+ provides the additional behavior that if one of the applicable methods
    
+ specifies &ALLOW-OTHER-KEYS then the initarg checking for the protocol is not
    
+ performed.
    
+
    
+Cost to Implementors:
    
+
    
+ Some possibly tricky code in the implementation may have to be reexamined.  In
    
+ some implementations it looks like this may involve simply ripping out some
    
+ special cases.
    
+
    
+Cost to Users:
    
+
    
+ Probably none in most cases.  Since none of the implementations surveyed ever
    
+ signal an error for the described problem case, it is unlikely that any user
    
+ code exists which depends on an error being signaled.
    
+
    
+ Users can eliminate unnecessary &ALLOW-OTHER-KEYS from initialization methods
    
+ at their leisure, since its presence or absence has no effect.
    
+
    
+ However, those users who have made use of the fairly common but non-portable
    
+ meaning of &ALLOW-OTHER-KEYS in applicable methods as a means of suppressing
    
+ initarg validation would have to find some other mechanism for this purpose.
    
+ One possibility would be to define appropriate :AROUND or primary methods on
    
+ MAKE-INSTANCE that add :ALLOW-OTHER-KEYS T to the initialization arguments.
    
+
    
+Performance Impact:
    
+
    
+ None.
    
+
    
+Benefits:
    
+
    
+ Users and implementors will know what &ALLOW-OTHER-KEYS in an initialization
    
+ method's lambda-list means.  Programmers writing initialization methods that
    
+ specify keywords won't have to remember to include &ALLOW-OTHER-KEYS
    
+ explicitly. 
    
+
    
+Aesthetics:
    
+
    
+ Requiring all initialization methods that specify &KEY to also specify
    
+ &ALLOW-OTHER-KEYS is clearly unaesthetic, so this change is an improvement.
    
+
    
+Discussion:
    
+
    
+ Interestingly, for one reason or another, none of the implementations surveyed
    
+ perform generic function keyword checking (as opposed to initarg checking) for
    
+ the functions affected by this proposal.
    
+
    
+ The possibility of having &ALLOW-OTHER-KEYS in the lambda-list of an
    
+ applicable initialization method mean that initarg validation should be
    
+ inhibited was discussed, especially in light of the fact that several of the
    
+ implementations surveyed already provide this behavior.  However, some people
    
+ questioned whether this was really such a good idea, being unmodular and
    
+ perhaps *too* convenient.  Also, making such a change would add a real cost to
    
+ users who weren't expecting this extension, since they would have to examine
    
+ occurances of &ALLOW-OTHER-KEYS in initialization methods to decide whether
    
+ they were left over from the time when it was (at least theoretically) needed
    
+ to inhibit generic function keyword checking or actually there to do the new
    
+ thing.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198.htm new file mode 100644 index 00000000..ca00eadf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue ISO-COMPATIBILITY:ADD-SUBSTRATE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ISO-COMPATIBILITY:ADD-SUBSTRATE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue ISO-COMPATIBILITY:ADD-SUBSTRATE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198_w.htm new file mode 100644 index 00000000..8f9c1cf5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss198_w.htm @@ -0,0 +1,224 @@ + + + +CLHS: Issue ISO-COMPATIBILITY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ISO-COMPATIBILITY Writeup

    + +
    Issue:        ISO-COMPATIBILITY
    
+Forum:	      X3J13 Letter Ballot
    
+References:   ISO SC22/WG16 Committee Draft
    
+Category:     CHANGE
    
+Edit history: 16-Jun-93, Version 1 by Pitman
    
+Status:       Proposal ADD-SUBSTRATE passed 8-3 on letter ballot 93-304.
    
+
    
+Problem Description:
    
+
    
+  The ISO specification for ISLISP contains features which cannot be 
    
+  straightforwardly implemented in ANSI Common Lisp, but that with
    
+  minor changes could be.
    
+
    
+Proposal (ISO-COMPATIBILITY:ADD-SUBSTRATE)
    
+
    
+  1. Add a new macro:
    
+
    
+     DEFINE-SYMBOL-MACRO name form		[Macro]
    
+
    
+     Globally defines a symbol macro named <name> which expands 
    
+     to <form>.
    
+
    
+  2. Add a new macro:
    
+
    
+     LAMBDA lambda-list &body declarations-and-forms    [Macro]
    
+
    
+     The form (lambda ...) is shorthand for #'(lambda ...).
    
+
    
+Test Case:
    
+
    
+  Sample code to better illustrate the issue goes here.
    
+
    
+Rationale:
    
+
    
+  This makes it possible to implement ISO's ISLISP dialect entirely
    
+  in portable code.
    
+
    
+  1. DEFINE-SYMBOL-MACRO can be used to define global lexicals, 
    
+     by having a global lexical be a symbol macro that expands 
    
+     into a reference to a globally allocated cell that is not
    
+     subject to dynamic binding.
    
+
    
+     DEFINE-SYMBOL-MACRO can also be used to define the ISLISP
    
+     notion of a compiler constant, which is a variable that
    
+     cannot be assigned but that CAN be bound.  The implementation
    
+     is the same as for global lexicals, except that the expansion
    
+     form is not SETF-able.
    
+
    
+  2. A LAMBDA, although conceptually trivial, cannot be defined by 
    
+     users because issue LISP-SYMBOL-REDEFINITION places restrictions
    
+     on users' ability to add definitions to symbols in the CL package.
    
+
    
+  Also, each of these features is independently useful in its own right.
    
+
    
+  1. DEFINE-SYMBOL-MACRO has been requested by some users.
    
+     For example, see Public Review comment Pitman #10.
    
+
    
+     Some users have also requested global lexicals, 
    
+     especially those from the Scheme community.
    
+     For example, see Public Review comment Loosemore #30.
    
+
    
+     Some users have also requested ISLISP-style constants,
    
+     especially those from the Eulisp community.
    
+     For example, see Public Review comment Dalton #4.
    
+
    
+   2. A LAMBDA macro has been requested by many users,
    
+      especially, but not at all exclusively, those from the
    
+      Scheme and Eulisp communities.
    
+      Issue LAMBDA-FORM previously failed before this committee,
    
+      however at a time when the compatibility issue with other 
    
+      Lisp standards was not as great a concern.  It's appropriate
    
+      that the concept be reconsidered again here in this new light.
    
+
    
+Current Practice:
    
+
    
+  1. Symbolics Genera provides DEFINE-SYMBOL-MACRO as an 
    
+     implementation-depednent extension.
    
+
    
+  2. Symbolics Genera has long provided a LAMBDA macro, which was
    
+     permitted as an extention under CLtL, but not the dpANS.  Users
    
+     were upset when this was not only taken away from them, but they
    
+     were forbidden from creating it anew.  (It's quite a complicated 
    
+     symbol to be shadowing.)
    
+
    
+     Most Lisp dialects don't provide a LAMBDA macro since doing so 
    
+     would be a violation of the spec.
    
+
    
+Cost to Implementors:
    
+
    
+  1. Relatively small.
    
+
    
+  2. Very small.  
    
+       (DEFMACRO LAMBDA (&WHOLE FORM &REST BVL-DECLS-AND-BODY)
    
+	  (DECLARE (IGNORE BVL-DECLS-AND-BODY))
    
+	  `#',FORM)
    
+
    
+Cost to Users:
    
+
    
+  1. None.  (This change is upward compatible.)
    
+
    
+  2. Very small.  (Mostly the need to remove any compatibility definition
    
+      they might already have, in spite of warnings that they should not
    
+      have such a thing.)
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The relation of ANSI CL to ISLISP would be difficult to explain.  Neither is
    
+  a subset of the other, so they would appear as competing dialects and it might
    
+  be a hassle for some vendors to explain off the lack of coordination. 
    
+
    
+Benefits:
    
+
    
+  If we can say that ANSI CL is capable of implementing ISLISP, 
    
+  then ISLISP becomes a substantially reduced threat in some situations.
    
+
    
+Editorial Impact:
    
+
    
+  Relatively small.
    
+
    
+  1. Changes to the description of how symbol macros are processed.
    
+     A new dictionary entry for the DEFINE-SYMBOL-MACRO macro.
    
+
    
+  2. A new dictionary entry for the LAMBDA macro.
    
+
    
+Aesthetics:
    
+
    
+  1. Having DEFINE-SYMBOL-MACRO as a companion to SYMBOL-MACROLET seems
    
+     to make things simpler to explain, since users often expect there
    
+     to be both definers and binders for things in the environment.
    
+
    
+  2. People are mixed on the aesthetics of this:
    
+
    
+     - Some people think a LAMBDA form is massively more aesthetic.
    
+
    
+     - Some people think LAMBDA is something primitive, not something
    
+	to be layered on as an afterthought with macro technology.
    
+
    
+     - Some people think having both (LAMBDA  ...) and #'(LAMBDA ...)
    
+	is extra baggage that look silly.
    
+
    
+     - Some people think having both (LAMBDA ...) and #'(LAMBDA ...)
    
+	provides expressional flexibility to two camps who won't be 
    
+	content to settle on a single solution.
    
+
    
+     - Some people think having (LAMBDA ...) brings them uncomfortably
    
+	close to having to fight the Lisp1/Lisp2 battle over again.
    
+
    
+     - Some people think having (LAMBDA ...) only makes sense in the
    
+	Lisp1 context.
    
+
    
+     - Some people think having (LAMBDA ...) ameliorates one of the 
    
+	aggravating problems seen by Lisp1-fans, which is the need to
    
+	write #' in front of things.  It doesn't get rid of all of them,
    
+	but it does get rid of many.
    
+
    
+     - Some people think that not having to write #'(LAMBDA ...) may
    
+	lead to further confusion down the road in understanding why the
    
+	car of a form is treated differently than other parts of the form.
    
+
    
+     There is not likely to be consensus from an absolute point of view 
    
+     on this.  It is clear that there is no way to optimize aesthetic
    
+     criteria related to LAMBDA in a way that satisfies everyone.
    
+
    
+     Pitman thinks this means that people should prefer to add the macro
    
+     since it permits maximal flexibility of style to users at extremely
    
+     low cost to implementors.
    
+
    
+Discussion:
    
+
    
+  This comment addresses the following Public Review comments:
    
+    Dalton #4
    
+    Pitman #10
    
+    Pitman #32
    
+    Loosemore #30
    
+  Pitman strongly supports this proposal.
    
+
    
+  The data for this proposal was generated from an experiment:
    
+  As a test, since the dialects were similar, Pitman implemented an 
    
+  approximate version of ISLISP in Common Lisp.  The exercise took 
    
+  only a few hours to code up.  In a few places, Pitman had to use
    
+  implementation-specific techniques to compensate for missing 
    
+  functionality. The items mentioned in this proposal are the things
    
+  he would have needed in Common Lisp in order not to have needed
    
+  implementation-specific substrate.
    
+
    
+  It's arguable that things like QUASIQUOTE, UNQUOTE, and
    
+  UNQUOTE-SPLICING should appear in this proposal as well.  However,
    
+  technically, those can be written straightforwardly in CL, so they
    
+  were omitted for reasons of minimalism in order to improve the
    
+  likelihood of this passing.  However, we might want to seriously
    
+  consider them separately since they did get mentioned in other Public
    
+  Review comments as a compatibility issue for Scheme users.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199.htm new file mode 100644 index 00000000..912e70c3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:11 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:11 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:11:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_m.htm new file mode 100644 index 00000000..16ad7ed4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue JUN90-TRIVIAL-ISSUES Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_w.htm new file mode 100644 index 00000000..ce78b4ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss199_w.htm @@ -0,0 +1,96 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue JUN90-TRIVIAL-ISSUES Writeup

    + +
    Date: Thu, 09 Jan 92 13:34:34 EST
    
+From: kab@cambridge.apple.com (Kim Barrett)
    
+To: kmp@symbolics.com
    
+Subject: jun90-trivial-issues
    
+
    
+Issue:  JUN90-TRIVIAL-ISSUES
    
+Status: Passed Jun 90
    
+
    
+
    
+Here is a list of (what I consider to be) fairly trivial issues
    
+from the list I circulated some time ago, along with a one-line
    
+fix for the problem.  I'm hoping they are noncontroversial enough
    
+so that we can just have one vote to approve the whole bunch.  If
    
+you *really* want to see a full cleanup issue and have a separate
    
+vote on any of these, let me know....
    
+
    
+The numbering follows my original list.
    
+
    
+(3) Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION specifies some
    
+behavior "when *PRINT-ESCAPE* is T".  Change "T" to "true" but
    
+don't change the behavior.
    
+
    
+(4) Rule (2) in issue PUSH-EVALUATION-ORDER specifies some
    
+behavior for the macro GETF, but GETF is actually a function.
    
+Since the order of evaluation of its arguments is already 
    
+well-specified, remove GETF from the list of affected macros
    
+in this issue.
    
+
    
+(5) Issue PATHNAME-COMPONENT-CASE specifies some behavior for
    
+a function named TRANSLATE-WILD-PATHNAME, which is not fully
    
+defined anywhere else.  Change the reference to 
    
+"TRANSLATE-WILD-PATHNAME" to "TRANSLATE-PATHNAME".
    
+
    
+(9) The symbols CLASS, GENERIC-FUNCTION, METHOD, and
    
+STRUCTURE-OBJECT were not formally defined as class names in
    
+CLOS chapters 1 and 2, although they were documented in the
    
+Aug 89 draft of the standard.  Formally add these classes to
    
+the language as documented in the draft.
    
+
    
+(11) Clarify that symbols that are defined as LOOP macro
    
+keywords are not exported from the COMMON-LISP package unless
    
+they have some other definition in the language.  The equality
    
+test used by LOOP to match keywords is a STRING= test on the 
    
+SYMBOL-NAMEs.
    
+
    
+(14) Issue CONDITION-RESTARTS states that restarts have dynamic
    
+extent, but doesn't say what the lifetime of that extent is.
    
+Clarify that it is the same as the lifetime of the binding of
    
+the restart.
    
+
    
+(24) The character committee proposals stated that BASE-STRING
    
+and SIMPLE-BASE-STRING are valid as type specifiers that
    
+abbreviate.  Clarify that the list forms of these type specifiers
    
+have the same syntax as the list form of the STRING type
    
+specifier.
    
+
    
+(25) Clarify that, when there is a dribble file already open,
    
+the behavior when DRIBBLE is called again to open another dribble
    
+file is unspecified.  (Some possible behaviors are: close
    
+the first file; dribble to both files; leave the first file open
    
+but dribble only to the second until it is closed; or to ignore
    
+the new dribble request entirely.)
    
+
    
+(27) Clarify that SETF places THE and APPLY support multiple
    
+store variables.  (See issue SETF-MULTIPLE-STORE-VARIABLES.)
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss200.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss200.htm new file mode 100644 index 00000000..b23248ff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss200.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:14 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:14 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:14:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss201.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss201.htm new file mode 100644 index 00000000..c438351e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss201.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:24 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:24 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:24:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss202.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss202.htm new file mode 100644 index 00000000..cc85bdb0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss202.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:25 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:25 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:25:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss203.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss203.htm new file mode 100644 index 00000000..5eb9c604 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss203.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:27 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:27 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:27:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss204.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss204.htm new file mode 100644 index 00000000..d3a964cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss204.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:3 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:3 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:3:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss205.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss205.htm new file mode 100644 index 00000000..121c8afc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss205.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:4 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:4 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:4:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss206.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss206.htm new file mode 100644 index 00000000..9b17e106 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss206.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:5 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:5 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:5:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss207.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss207.htm new file mode 100644 index 00000000..9d922807 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss207.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue JUN90-TRIVIAL-ISSUES:9 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue JUN90-TRIVIAL-ISSUES:9 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue JUN90-TRIVIAL-ISSUES:9:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208.htm new file mode 100644 index 00000000..a36745e1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue KEYWORD-ARGUMENT-NAME-PACKAGE:ANY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue KEYWORD-ARGUMENT-NAME-PACKAGE:ANY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue KEYWORD-ARGUMENT-NAME-PACKAGE:ANY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208_w.htm new file mode 100644 index 00000000..42611d50 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss208_w.htm @@ -0,0 +1,220 @@ + + + +CLHS: Issue KEYWORD-ARGUMENT-NAME-PACKAGE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue KEYWORD-ARGUMENT-NAME-PACKAGE Writeup

    + +
    Version 6 conditionally passed X3J13/Jun87. Version 8 distributed in hardcopy
    
+form X3J13/Nov87.
    
+
    
+!
    
+Issue:        KEYWORD-ARGUMENT-NAME-PACKAGE
    
+References:   Lambda Expressions (CLtL pp60-64)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 20-Apr-87, Version 1 by Moon
    
+              29-Apr-87, Version 2 by Pitman
    
+              11-May-87, Version 3 by Moon
    
+              29-May-87, Version 4 by Masinter 
    
+               5-Jun-87, Version 5 by Masinter
    
+              11-Jun-87, Version 6 by Masinter
    
+              23-Oct-87, Version 7 by Masinter
    
+               8-Nov-87, Version 8 by Moon
    
+
    
+Problem Description:
    
+
    
+CLtL says that only keyword symbols can be used as keyword-names in
    
+&key parameter specifiers (page 60, "each -keyword- must be a
    
+keyword symbol, such as :start.")
    
+
    
+As Common Lisp is currently defined, if someone wants to define a
    
+function that accepts keyword (rather than positional) arguments whose
    
+keyword-names are symbols in packages other than the KEYWORD package,
    
+they cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
    
+using &REST, GETF, and (if they want error checking of argument names)
    
+DO.
    
+
    
+Some applications (including the draft proposal for the Common Lisp
    
+Object System (CLOS)) require this capability. [See Rationale below.]
    
+
    
+Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
    
+
    
+Remove restrictions on the package of the keyword-names of keyword
    
+parameters; allow any symbol. That is:
    
+
    
+If, following an &KEY, a variable appears alone or in a (variable
    
+default-value) pair, the behavior specified in CLtL is unchanged: a
    
+keyword symbol with the same print name as the variable is created and
    
+is used as the keyword-name when matching arguments to parameter
    
+specifiers.  A keyword-name that is not a keyword symbol can be
    
+specified with the ((-keyword- -var-) ...) syntax of parameter
    
+specifier. The -keyword- can be any symbol, not just a keyword.
    
+
    
+A future specification of Common Lisp could be written with revised
    
+terminology that did not use the term "keyword" to refer to three
    
+different things: symbols in the KEYWORD package, symbols beginning
    
+with & that have special meaning in lambda-lists, and keyword-names
    
+used to match function arguments to keyword parameter specifiers.
    
+However, this proposal does not propose to change any terminology.
    
+
    
+Test case:
    
+
    
+(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
    
+    (FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
    
+
    
+(RESULT :AMOUNT 100) => "You lose $100"
    
+(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
    
+
    
+
    
+Rationale:
    
+
    
+The "rationale" box on p.62 of CLtL is an argument in favor of requiring
    
+keyword-names to be symbols, and disallowing numbers, but does not
    
+speak to the issue of whether or not those symbols should be further
    
+restricted to be in the KEYWORD package.
    
+
    
+The desire for keyword parameters whose keyword-names are not in the
    
+KEYWORD package arises when the set of keyword-names accepted by a
    
+function is the union of the sets of keyword-names accepted by several
    
+other functions, rather than being enumerated in a single place.  In
    
+this case, it becomes desirable to use packages to prevent accidental
    
+name clashes among keyword-names of different functions.
    
+
    
+One example of a Common Lisp application that requires this capability
    
+is the draft proposal for an object-oriented programming standard
    
+(CLOS).  It will have generic functions that accept arguments and pass
    
+them on to one or more applicable methods, with each method defining its
    
+own set of keyword-names that it is interested in.  If this proposal is
    
+not adopted, either the keyword-names will be required to be keywords,
    
+which will require the methods to have non-modular knowledge of each
    
+other in order to avoid name clashes, or the methods will have to be
    
+defined with an ad hoc mechanism that duplicates the essential
    
+functionality of &key but removes the restriction.
    
+
    
+A second example of a Common Lisp application that requires this
    
+capability is private communication channels between functions.  Suppose
    
+a public routine MAKE-FOO needs to accept arbitrary arguments from the
    
+caller and passes those arguments along to an internal routine with
    
+additional arguments of its own, and suppose that keyword parameters
    
+are used to receive these arguments.
    
+
    
+ (IN-PACKAGE 'FOOLAND)
    
+ (DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
    
+   (APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
    
+
    
+This could be done without fear that the use of EXPLICIT T would
    
+override some argument in NAME-VALUE-PAIRS, since the only way
    
+that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
    
+NIL), or if the user was programming explicitly in the FOOLAND package,
    
+either of which is an implicit admission of willingness to violate
    
+FOOLAND's modularity.
    
+
    
+Documentation Impact:
    
+
    
+Some careful rewording of the existing language in CLtL is necessary in
    
+the standard to avoid confusion between "keyword", indicating a symbol
    
+in the KEYWORD package, and "keyword name", indicating a syntactic part
    
+of a keyword parameter specifier.  It is likely that this is best served
    
+by changing those instances of "keyword" to "named argument" when the
    
+specification is discussing the indicator which introduces an actual
    
+parameter in a call to a function defined with &KEY.
    
+
    
+The wording which refers to named arguments as being introduced by
    
+keyword symbols would change to simply refer to those arguments being
    
+introduced by symbols. For example, in the middle of p.60, the sentence:
    
+   ... each -keyword- must be a keyword symbol, such as :start.
    
+ would become
    
+   ... each named argument name must be a symbol.
    
+
    
+The word "keyword" in the first complete sentence on p.62 would be
    
+changed to "symbol" for similar reasons.
    
+
    
+Extra wording would have to be added on p.60 to explain that by
    
+convention keyword symbols are normally used as the names for named
    
+arguments, and that all functions built into the Common Lisp language
    
+follow that convention.
    
+
    
+Examples would be useful. On p.64 the following examples might be added:
    
+
    
+    ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
    
+    => (1 2 6 NIL)
    
+
    
+    ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
    
+    => (1 2 6 NIL)
    
+
    
+Current Practice:
    
+
    
+We do not currently know of an implementation that enforces the
    
+restriction that this proposal seeks to remove.
    
+
    
+Some implementations have bugs that prevent NIL from working as a
    
+keyword argument name, but allow all non-NIL symbols. (One Symbolics
    
+version that was checked had this bug.)
    
+
    
+Cost to implementors:
    
+
    
+Some implementors might have to rearrange their error checking slightly,
    
+but it should be very easy.
    
+
    
+Cost to users:
    
+
    
+None--no existing programs will stop working.  
    
+
    
+Benefits:
    
+
    
+This will help with the object-oriented programming standard, among
    
+other things.
    
+
    
+Aesthetics:
    
+
    
+The restriction of &key to only keyword symbols is arbitrary and
    
+unnecessary.
    
+
    
+There will probably be an argument about whether the restriction is more
    
+aesthetic or less aesthetic than the freedom, but in either case the
    
+aesthetic effect is slight.
    
+
    
+In any case, users who do not want to use the extended functionality can
    
+generally avoid it.
    
+
    
+Discussion:
    
+
    
+The cleanup committee generally supports this extension. 
    
+
    
+Moon was under the impression that this proposal was actually adopted
    
+around December 1985 (although no formal mechanism for adopting
    
+proposals existed at that time), but may be mistaken.
    
+
    
+If Common Lisp truly has a restriction that only keyword symbols can be
    
+used as keyword names in calls to functions that take keyword arguments,
    
+it will be more difficult to come up with an object-oriented programming
    
+standard that fits within Common Lisp.
    
+
    
+The cleanup committee considered, but did not adopt, a proposal to
    
+exclude NIL as a legal indicator. It might catch some errors, but is
    
+otherwise an odd restriction.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209.htm new file mode 100644 index 00000000..06690d19 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LAST-N Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LAST-N Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LAST-N:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209_w.htm new file mode 100644 index 00000000..f2169040 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss209_w.htm @@ -0,0 +1,133 @@ + + + +CLHS: Issue LAST-N Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LAST-N Writeup

    + +
    Issue:        LAST-N
    
+References:   LAST (p267)
    
+Category:     ENHANCEMENT
    
+Edit history: 04-Dec-87, Version 1 by Pitman
    
+	      12-Mar-88, Version 2 by Pitman
    
+
    
+Problem Description:
    
+
    
+  People always ask why LAST returns a cons and not an element.
    
+
    
+  BUTLAST takes an argument N but LAST does not.
    
+
    
+Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
    
+
    
+  Allow LAST to take an optional argument N, saying how many cells to return.
    
+  The default for N would be 1.
    
+
    
+  It is an error if N is negative or L is circular.
    
+
    
+  If N is zero, then the atom that terminates the list L is returned.
    
+
    
+  If N is greater than or equal to the number of cons cells in the list
    
+  L, then the result is L.
    
+
    
+Test Cases:
    
+
    
+ (LAST    '(A B C) 0) => ()
    
+ (BUTLAST '(A B C) 0) => (A B C)
    
+
    
+ (LAST    '(A B C) 1) => (C)
    
+ (BUTLAST '(A B C) 1) => (A B)
    
+
    
+ (LAST    '(A B C) 2) => (B C)
    
+ (BUTLAST '(A B C) 2) => (A)
    
+
    
+ (LAST    '(A B C) 3) => (A B C)
    
+ (BUTLAST '(A B C) 3) => ()
    
+
    
+ (LAST    '(A B C) 4) => (A B C)
    
+ (BUTLAST '(A B C) 4) => ()
    
+
    
+ (LAST    '(A B C))   => (C)
    
+ (BUTLAST '(A B C))   => (A B)
    
+
    
+ (LAST '(A . B) 0)    => B
    
+ (LAST '(A . B) 1)    => (A . B)
    
+ (LAST '(A . B) 2)    => (A . B)
    
+
    
+Rationale:
    
+
    
+  BUTLAST and LAST would select complementary parts of a list in general.
    
+  That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
    
+  and L being a proper list.
    
+
    
+  This would make it more obvious why LAST should return a list and not
    
+  an element. ie, it would return the "last N elements" where N=1 by default.
    
+
    
+Current Practice:
    
+
    
+  Probably nobody does this.
    
+
    
+Adoption Cost:
    
+
    
+  Very slight. The following code would suffice:
    
+
    
+  (DEFUN LAST (LIST &OPTIONAL (N 1))
    
+    (CHECK-TYPE N (INTEGER 0))
    
+    (DO ((L LIST (CDR L))
    
+	 (R LIST)
    
+	 (I 0 (+ I 1)))
    
+	((ATOM L) R)
    
+      (IF (>= I N) (POP R))))
    
+
    
+  Some implementations might want to provide compiler optimizations for
    
+  the N=1 case.
    
+
    
+Benefits:
    
+
    
+  This utility is probably needed often enough to warrant its inclusion.
    
+  It's present (as a separate function called NLEFT) in Symbolics Common
    
+  Lisp and Interlisp.
    
+
    
+Conversion Cost:
    
+
    
+  None. This is an upward compatible extension.
    
+
    
+Aesthetics:
    
+
    
+  This would make things a little prettier.
    
+
    
+Discussion:
    
+
    
+  This suggestion came up recently on a Symbolics design discussion list.
    
+  Symbolics is contemplating offering it as an extension, but it seemed like
    
+  the rest of the CL community might want to adopt it, too.  Pitman thinks
    
+  it's a nice idea.
    
+
    
+  Masinter opposes this extension as gratuitous.
    
+
    
+  Moon and Daniels think this is very low priority but have expressed a
    
+  lack of major objection to this proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210.htm new file mode 100644 index 00000000..2e68ce97 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LCM-NO-ARGUMENTS:1 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LCM-NO-ARGUMENTS:1 Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LCM-NO-ARGUMENTS:1:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210_w.htm new file mode 100644 index 00000000..adb49807 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss210_w.htm @@ -0,0 +1,77 @@ + + + +CLHS: Issue LCM-NO-ARGUMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LCM-NO-ARGUMENTS Writeup

    + +
    Issue:         LCM-NO-ARGUMENTS
    
+
    
+References:    CLtL p. 202
    
+
    
+Related issues: none
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, Guy Steele 10/17/88
    
+
    
+Problem description:
    
+
    
+   CLtL incorrectly states that (lcm) should return infinity, and
    
+   therefore specifies that giving lcm no arguments is an error.
    
+
    
+   In point of mathematical fact, 1 is the identity for the lcm operation.
    
+
    
+Proposal (LCM-NO-ARGUMENTS:1):  Define (lcm) to return the integer 1.
    
+
    
+Examples:   (lcm) => 1
    
+
    
+Test Cases:  (lcm) => 1
    
+
    
+   Currently the behavior in this case is implementation-dependent.
    
+
    
+Rationale:  Doing what is mathematically right.
    
+
    
+Current practice:
    
+   KCL signals an error.
    
+   Lucid Lisp returns 1.
    
+   Symbolics Common Lisp returns 1.
    
+
    
+Cost to Implementors:  Pretty small (one-line fix).
    
+
    
+Cost to Users:  None.
    
+
    
+Cost of non-adoption:  Continued embarassment for Steele.
    
+
    
+Performance impact:  Negligible.
    
+
    
+Benefits:  Correct handling of a seldom-used boundary case.
    
+
    
+Esthetics:  Mild improvement.
    
+
    
+Discussion:  Mentioned in Steele's December 1985 "clarifications".
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211.htm new file mode 100644 index 00000000..f9addd68 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211.htm @@ -0,0 +1,41 @@ + + + +CLHS: Issue LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211_w.htm new file mode 100644 index 00000000..3e173e64 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss211_w.htm @@ -0,0 +1,134 @@ + + + +CLHS: Issue LEXICAL-CONSTRUCT-GLOBAL-DEFINITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LEXICAL-CONSTRUCT-GLOBAL-DEFINITION Writeup

    + +
    Issue:               LEXICAL-CONSTRUCT-GLOBAL-DEFINITION 
    
+References:          PPRINT-EXIT-IF-LIST-EXHAUSTED
    
+                     PPRINT-POP
    
+                     LOOP-FINISH
    
+		     CALL-METHOD
    
+                     CALL-NEXT-METHOD
    
+		     NEXT-METHOD-P
    
+Related issues:      Issue LISP-SYMBOL-REDEFINITION
    
+                     Issue PRETTY-PRINT-INTERFACE
    
+                     Issue LOOP-FINISH-NOT-FINISHED
    
+Category:            CLARIFICATION, CHANGE
    
+Edit history:        V1, 05 May 90, Sandra Loosemore
    
+                     V2, 29 May 90, Sandra Loosemore (forgot one)
    
+
    
+Problem description:
    
+
    
+The description of PPRINT-EXIT-IF-LIST-EXHAUSTED and PPRINT-POP
    
+in issue PRETTY-PRINT-INTERFACE specifies that "an error message
    
+is issued" if either of these constructs are used anywhere other
    
+than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.
    
+It is not clear whether this means "an error is signalled" or
    
+"a message is printed", or whether this situation must be
    
+detected at compile time or at run time.
    
+
    
+This is actually a more general problem, since there are other 
    
+constructs in the language that have similar scoping requirements:  
    
+notably LOOP-FINISH, CALL-METHOD, CALL-NEXT-METHOD, and NEXT-METHOD-P.  
    
+The error behavior of all of these constructs when they are referenced
    
+outside the lexical scope where their behavior is defined ought
    
+to be made consistent, as should the matter of whether they
    
+are permitted/required/not allowed to be globally FBOUNDP.  
    
+
    
+This issue incorporates items #2 and #23 from Loosemore's list.
    
+
    
+Proposal (LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED):
    
+
    
+  This proposal affects the constructs PPRINT-EXIT-IF-LIST-EXHAUSTED, 
    
+  PPRINT-POP, LOOP-FINISH, CALL-METHOD, CALL-NEXT-METHOD, and 
    
+  NEXT-METHOD-P, which are referred to as "lexically-scoped operators".
    
+
    
+  (1) Change the descriptions of lexically-scoped operators to
    
+  state that any attempt to invoke the operator outside of the
    
+  lexical scope where its behavior is defined has undefined
    
+  consequences.
    
+
    
+  (2) Clarify that it is unspecified whether function names that
    
+  are defined by the standard as lexically-scoped operators have
    
+  global function or macro definitions (i.e., are FBOUNDP).
    
+
    
+  (3) Clarify that the restrictions on redefinition or shadowing
    
+  of symbols in the COMMON-LISP package (originally stated in issue 
    
+  LISP-SYMBOL-REDEFINITION) are the same for symbols that define 
    
+  lexical operators as for symbols that are globally defined as
    
+  operators.
    
+
    
+Rationale:
    
+
    
+  This gives maximum freedom to implementors and avoids having to
    
+  deal with sticky issues about whether errors are detected at
    
+  compile or run time, etc.
    
+
    
+Current Practice:
    
+
    
+  I suspect it is fairly common practice to define these operators
    
+  using MACROLET (etc) and provide a global definition that
    
+  signals an error if it is invoked.
    
+
    
+Cost to Implementors:
    
+
    
+  None.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Part of the language specification remains imprecise,
    
+  inconsistent, and confusing.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  The language specification is made more precise, consistent,
    
+  and less confusing.
    
+
    
+Esthetics:
    
+
    
+  Treating all of these guys uniformly is better than having them
    
+  all specify something slightly different with regard to their
    
+  behavior.
    
+
    
+Discussion:
    
+
    
+The situation with the DECLARE special form is related but not
    
+entirely analogous, so it has been left out of this proposal.
    
+From a purely abstract point of view, DECLARE is not a special form 
    
+at all but simply a syntactic marker like LAMBDA, and the only
    
+reason for defining it as an operator is to facilitate diagnostics 
    
+about misplaced declarations.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212.htm new file mode 100644 index 00000000..b7e307ec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue LISP-PACKAGE-NAME:COMMON-LISP Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LISP-PACKAGE-NAME:COMMON-LISP Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LISP-PACKAGE-NAME:COMMON-LISP:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212_w.htm new file mode 100644 index 00000000..6a918342 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss212_w.htm @@ -0,0 +1,236 @@ + + + +CLHS: Issue LISP-PACKAGE-NAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LISP-PACKAGE-NAME Writeup

    + +
    Status: passed, as amended, Mar 89 X3J13
    
+
    
+Issue:        LISP-PACKAGE-NAME
    
+References:   11.6 Built-in Packages (pp181-182)
    
+Category:     CHANGE
    
+Edit history: 22-Dec-88, Version 1 by Pitman
    
+		9-Apr-89, version 2 by Masinter, incorporate
    
+		changes per Mar 89 amendments.
    
+
    
+Problem Description:
    
+
    
+  Since ANSI Common Lisp will differ from the Common Lisp described by CLtL,
    
+  it will not be possible to have support for both in the same Lisp image
    
+  if ANSI Common Lisp insists on placing its functionality in the package
    
+  named LISP.
    
+
    
+  Further, use of the name unqualified name LISP by the ANSI Common Lisp
    
+  community is inconsistent with ANSI's expressed position to ISO that 
    
+  the term "LISP" names a language family rather than a specific dialect
    
+  within that family.
    
+
    
+Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
    
+
    
+  Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
    
+  Define that the COMMON-LISP package has nickname CL.
    
+
    
+  Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
    
+  between COMMON-LISP and LISP in implementations simultaneously supporting
    
+  both, clarify that the initial symbols specified by ANSI Common Lisp as
    
+  belonging in the COMMON-LISP package need not have a home package of 
    
+  Common-Lisp.
    
+
    
+  Similarly, rename the package USER to be COMMON-LISP-USER with
    
+  nickname CL-USER.
    
+
    
+Test Case:
    
+
    
+  In an implementation supporting CLtL's LISP package and 
    
+  the ANSI Common Lisp CL package proposed here:
    
+
    
+  (EQ 'LISP:T 'CL:T)
    
+  => not specified, due to this proposal, but probably T
    
+
    
+  (EQ 'LISP:CAR 'CL:CAR)
    
+  => not specified, due to this proposal, but probably T
    
+
    
+  (EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
    
+  => not specified, due to this proposal, but since FUNCTIONP is
    
+     changed incompatibly between CLtL (LISP) and CL (ANSI), there
    
+     are good reasons why this might return NIL.
    
+
    
+  (SYMBOL-PACKAGE 'CL:T)
    
+  => not specified, due to this proposal. Perhaps #<Package CL>, 
    
+     perhaps #<Package LISP>, or perhaps something implementation-specific.
    
+
    
+  (SYMBOL-PACKAGE 'LISP:T)
    
+  => not specified, not due to this proposal, but because CLtL didn't
    
+     specify this explicitly.
    
+
    
+Rationale:
    
+
    
+  In practice, some implementations will have very legitimate reasons for 
    
+  wanting to Lisp dialects to be coresident. As it stands, they will have
    
+  little other choice than to make the two use different packages, and so
    
+  will be forced to be incompatible with one or the other dialect unless
    
+  we choose a different package name for the one dialect for which there
    
+  is currently no existing code.
    
+
    
+  Not only is this important the CLtL and ANSI Common Lisp communities, but
    
+  also, if we continue to use the name LISP, it sends a signal to the ISO
    
+  Lisp community that the "latest and greatest" Lisp should use the generic
    
+  name LISP, and they may try to use it as well. If ISO Lisp turns out to
    
+  be very different than ANSI Common Lisp, there may be motivation down the
    
+  line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts
    
+  will inevitably arise if both want to use the name LISP. This will almost
    
+  certainly lead to a confrontation where one Lisp dialect tries to force
    
+  the other out by the artificial means of asserting its right to this
    
+  generic name. Choosing a name which compatibly admits the option of
    
+  introducing other dialects into the environment at a later date without
    
+  conflict is a good way to avoid a class of potential problems.
    
+
    
+  Although there are a few problems which could come up due to the symbol
    
+  package of initial symbols being unspecified, experience with 
    
+  implementations that do this suggests that they are very few.
    
+  Problems occur only in the rare circumstance that all of the following
    
+  conditions are met:
    
+
    
+   - A symbol S on the LISP package but with home package H (that is not "LISP")
    
+     is shadowed in some package P of implementation A.
    
+
    
+   - A program F in package P uses the shadowed symbol H:S by an explicit
    
+     LISP: or H: package qualification. (Only the case of using "LISP:" is
    
+     interesting, of course, since if H were named explicitly, we would be
    
+     outside the bounds of portable code).
    
+
    
+   - The program F, referring to H:S, is printed out in implementation A 
    
+     while using package P (or some other package that shadows S, so that
    
+     the H package qualifier appears explicitly) and an attempt is made to
    
+     re-read it in implementation B.
    
+
    
+   - Implementation B has no package named H, has a package named H but no
    
+     external symbol named S, or has a package named H with external symbol
    
+     S but the symbol H:S has different semantics in implementation B than
    
+     it did in implementation A.
    
+
    
+  In practice, this hardly ever happens. It would happen even less if 
    
+  programmers were explicitly alerted that it was a potential problem they
    
+  needed to guard against.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera already has a package named COMMON-LISP with nicknames
    
+  CL and LISP. As such, this would be an incompatible change for Genera.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+  In some cases, this may even have `negative cost' because it will provide
    
+  implementors a way of avoiding incompatible changes to released operators.
    
+
    
+Cost to Users:
    
+
    
+  Small.
    
+
    
+  In some cases, this may even have `negative cost' because existing code
    
+  would be able to continue to run in implementations which chose to support
    
+  both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing
    
+  developers to put off a massover changeover, perhaps doing the transition
    
+  more incrementally.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Implementations trying to support multiple dialects in the same environment
    
+  would be forced to violate one or the other spec.
    
+
    
+  Worse, different implementations faced with the same set of hard choices
    
+  about which spec to violate in order to concurrently support two dialects
    
+  might not make the same choices, leading to even more gratuitous 
    
+  incompatibility.
    
+
    
+  ANSI's position in ISO that we are not trying to legislate the meaning of
    
+  -the- LISP dialect would be weakened.
    
+
    
+Benefits:
    
+
    
+  Needless incompatibility would be avoided in a variety of situations.
    
+
    
+Aesthetics:
    
+
    
+  Failing to specify the home package of symbols in the LISP and CL packages
    
+  seems unaesthetic because it appears to diminish print/read invertability,
    
+  but as observed above, that case is rare.
    
+
    
+  Failiing to specify a way in which lisp dialects can be co-resident is also
    
+  unaesthetic because in practice implementors with a need to do this will do
    
+  so whether the standard allows them or not, and it will be a source of 
    
+  severe divergence among implementations.
    
+
    
+Discussion:
    
+
    
+  Symbolics Genera offers two co-resident dialects of Lisp: Zetalisp and
    
+  Symbolics Common Lisp. The Symbolics Cloe development environment adds
    
+  a third co-resident dialect, making an environment in which two differing
    
+  Common Lisp dialects (Symbolics Common Lisp and Cloe) must cooperate.
    
+  Already in Cloe it is not possible for the home package to contain 
    
+  package "LISP" since Cloe's concept of what the "LISP" package is differs
    
+  from Genera's concept of what the "LISP" package is, yet they are forced
    
+  by efficiency constraints to share the same symbol. It is Pitman's belief,
    
+  based on extensive experience with Cloe, that failure to pass this proposal
    
+  (or something very like it) will lead to all sorts of trouble for Common
    
+  Lisp users and implementors down the road.
    
+
    
+  Pitman strongly supports this proposal.
    
+
    
+Additional comments:
    
+
    
+Is it permissible for implementations to define
    
+"LISP" as a nickname for this package, for the
    
+sake of backward compatibility?
    
+
    
+Anyone wanting to make LISP a nickname could just as well create a LISP
    
+package which simply imported the appropriate symbols from the CL package.
    
+
    
+With only modest additional effort, they could try to make new symbols where
    
+feasable (especially for most functions) and put borrowed functions plopped
    
+in their function cells. The amount of additional storage is small (compared
    
+to implementing a whole new lisp), but it would leave open the possibility for
    
+users upgrading the level of compatibility without hurting the core
    
+system. eg, if I wanted APPEND to signal an error on dotted lists, I
    
+would not consider redefining the system's APPEND for fear of breaking
    
+the world, but if they told me that nothing depended on LISP other than
    
+compatibility code, I might feel ok about redefining (or doing
    
+SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with
    
+appropriate sharp conditionals)) in order to up the level of
    
+compatibility.
    
+
    
+In fact, though, my guess is that implementations which are not going to
    
+do a serious compatibility effort are better off leaving the package
    
+missing. My experience has been that customers are often happier growing
    
+their own compatibility [or getting it from a public library] than being
    
+stuck with something which really doesn't do what they want but which
    
+seals off the place in the namespace which they needed in order to do
    
+their own thing.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213.htm new file mode 100644 index 00000000..96cccca2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213_w.htm new file mode 100644 index 00000000..b1f3b140 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss213_w.htm @@ -0,0 +1,119 @@ + + + +CLHS: Issue LISP-SYMBOL-REDEFINITION-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LISP-SYMBOL-REDEFINITION-AGAIN Writeup

    + +
    Issue:        LISP-SYMBOL-REDEFINITION-AGAIN
    
+Reference:    X3J13/92-102 (dpANS 12.24)
    
+                Section 11.1.2.1.1 Constraints on the COMMON-LISP Package
    
+                  for Conforming Implementations (p.11-5)
    
+                Section 11.1.2.1.2 Constraints on the COMMON-LISP Package
    
+                  for Conforming Programs (p.11-5..6)
    
+                Section 11.1.2.1.2.1 Some Exceptions to Constraints on the
    
+                  COMMON-LISP Package for Conforming Programs (p.11-6)
    
+              X3J13/90-419 LISP-SYMBOL-REDEFINITION (Version 8)
    
+              X3J13/92-1412 Barry Margolin comment #12
    
+              X3J13/92-2517 Kim Barrett comment #17
    
+              "The Art of the Metaobject Protocol", Section 5.3.1, p.142
    
+Category:     CHANGE/CLARIFICATION
    
+Edit History: Version 1, 12/31/92, Kim Barrett
    
+Status:       Proposal MORE-FIXES passed (10+1)-0 on letter ballot 93-302.
    
+
    
+
    
+Problem Description:
    
+
    
+ The set of restrictions on conforming programs specified in 11.1.2.1.2 is
    
+ incomplete.  Some constraints added by X3J13/90-419 were not included, and
    
+ there are some additional restrictions that were missed entirely.
    
+
    
+Proposal (LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES):
    
+
    
+ 1. Make the following changes to existing items in 11.1.2.1.2.
    
+
    
+   a. Add "undefining" to item 2, prohibiting the removal of function
    
+      definitions.
    
+   b. Add "undefining" to item 3, prohibiting the removal of macro and
    
+      compiler-macro definitions.
    
+
    
+ 2. Add the following items to 11.1.2.1.2.
    
+
    
+   a. Defining a \term{setf expander} for it (via \funref{defsetf} or
    
+      \funref{define-setf-method}).
    
+
    
+   b. Defining, undefining, or binding its \term{setf function name}.
    
+
    
+   c. Defining it as a \term{method combination} type (via
    
+      \funref{define-method-combination}).
    
+
    
+   d. Using it as the class-name argument to \funref{setf} of
    
+      \funref{find-class}.
    
+
    
+   e. Binding it as a \term{catch tag}.
    
+
    
+   f. Binding it as a \term{restart} \term{name}.
    
+
    
+   g. Defining a \term{method} for a \term{standardized} \term{generic
    
+      function} which is \term{applicable} when all of the \term{arguments}
    
+      are \term{direct instances} of \term{standardized} \term{classes}.
    
+
    
+ 3. Add the following as an additional paragraph for 11.1.2.1.2.1.
    
+
    
+   If an \term{external symbol} of \thepackage{common-lisp} is not defined as
    
+   a \term{standardized} \term{function}, \term{macro}, or \term{special
    
+   operator}, it is allowed to lexically \term{bind} its \term{setf function
    
+   name} as a \term{function}, and to declare the \declref{ftype} of that
    
+   \term{binding}.
    
+
    
+ 4. Add the following entry to the glossary.
    
+
    
+   \gentry{setf function name} \Noun\ (of a \term{symbol})
    
+     the \term{list} \f{(setf \term{symbol})}.
    
+
    
+Editorial Impact:
    
+
    
+ Several small additions described above.
    
+
    
+Rationale:
    
+
    
+ Items 1, 2a through 2d, and 3 were in LISP-SYMBOL-REDEFINITION (v8) but were
    
+ not included in the draft.  Items 2a, 2b, and 3 also respond to Margolin's
    
+ comment.
    
+
    
+ Item 4 defines terminology for the other items to use.
    
+
    
+ Items 2e and 2f are cases that were previously overlooked.
    
+
    
+ Item 2g was also previously overlooked.  It is a recasting of the first
    
+ bullet on p.143 of AMOP.  It responds to both Margolin's and Barrett's
    
+ comments.
    
+
    
+Discussion:
    
+
    
+ It's unfortunate that section 11.1.2.1 doesn't contain any rationale for the
    
+ specified restrictions, but changing that is beyond the scope of this proposal.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214.htm new file mode 100644 index 00000000..273e2787 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue LISP-SYMBOL-REDEFINITION:MAR89-X3J13 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LISP-SYMBOL-REDEFINITION:MAR89-X3J13 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LISP-SYMBOL-REDEFINITION:MAR89-X3J13:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214_w.htm new file mode 100644 index 00000000..1a990b7a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss214_w.htm @@ -0,0 +1,177 @@ + + + +CLHS: Issue LISP-SYMBOL-REDEFINITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LISP-SYMBOL-REDEFINITION Writeup

    + +
    Status:	       Version 8 passed (superseding version 6), 6/8/90
    
+
    
+Forum:         Cleanup
    
+Issue:         LISP-SYMBOL-REDEFINITION
    
+ 
    
+References:    Cleanup issue PACKAGE-CLUTTER
    
+               CLtL pp 67-69 Defining named functions
    
+	       CLtL pp 101-106 Generalized variables
    
+	       Cleanup issue FUNCTION-NAME
    
+	       Condition System, version 18
    
+	       CLOS specification, 88-002R
    
+ 
    
+Category:      CLARIFICATION
    
+ 
    
+Edit history:  Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
    
+               Masinter, Version 2, 7-Oct-88
    
+               Masinter, Version 3,  7-Oct-88, fix typos
    
+               van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
    
+               Masinter, Version 5, 22-Nov-88, add more cases
    
+	       Masinter, Version 6,  9-Apr-89, make Mar 89 X3j13 amendments
    
+	       Barrett, Version 7, 3-Jan-90, add more cases
    
+	       Barrett, Version 8, 9-Jan-90, make Jun 90 X3J13 ammendments
    
+ 
    
+Problem description:
    
+ 
    
+Is it legal to redefine Common Lisp functions? There is no explicit
    
+prohibition, and many implementations do allow redefinition of
    
+functions in the Lisp package.
    
+ 
    
+CLtL only says that special forms can not be redefined. But this doesn't 
    
+solve the general problem of redefining system functions.
    
+ 
    
+Proposal LISP-SYMBOL-REDEFINITION:MAR89-X3J13
    
+
    
+Except where explicitly allowed, the consequences are undefined if any of the
    
+following actions are performed on symbols exported from the COMMON-LISP
    
+package:
    
+
    
+1. Binding or altering its value (lexically or dynamically)
    
+2. Defining, undefining, or binding it as a function
    
+3. Defining, undefining, or binding it as a macro or compiler-macro
    
+4. Defining it as a type specifier (defstruct, defclass, define-condition,
    
+   deftype)
    
+5. Defining it as a structure (defstruct)
    
+6. Defining it as a declaration (declaration, define-declaration)
    
+7. Using it as a symbol macro
    
+8. Altering its print name (this may already be prohibited)
    
+9. Altering its package
    
+10. Tracing it
    
+11. Declaring or proclaiming it special
    
+12. Declaring or proclaiming its type or ftype
    
+13. Uninterning or unexporting it from the package COMMON-LISP
    
+14. Defining a setf method for it (defsetf, define-setf-method, defining,
    
+    undefining, or binding the function named (SETF symbol))
    
+15. Defining it as a method combination type
    
+16. Using it as the class-name argument to SETF of FIND-CLASS
    
+
    
+If such a symbol is not globally defined as a variable or a constant, it is
    
+allowed to lexically bind it as a variable or as a symbol-macro and declare the
    
+type of that binding.
    
+
    
+If such a symbol is not defined as a function, macro, or special form,
    
+it is allowed to (lexically) bind it as a function and to declare the
    
+ftype of that binding and to trace that binding.
    
+
    
+If such a symbol is not defined as a function, macro, or special form,
    
+it is allowed to (lexically) bind it as a macro.
    
+
    
+If such a symbol does not have a setf method defined for it, it is allowed to
    
+(lexically) bind the function named (SETF symbol).
    
+
    
+Examples:
    
+ 
    
+The behavior of the construct:
    
+ 
    
+(FLET ((OPEN (filename &key direction) (format t "Open called....") 
    
+			(OPEN filename :direction direction)))
    
+    (with-open-file (x "frob" :direction ':output) 
    
+		(format t "was Open called?")))
    
+ 
    
+is undefined; for example, the macro expansion of with-open-file might refer
    
+to the OPEN function and might not.
    
+ 
    
+(DEFUN CAR (X) (CDR X))
    
+ 
    
+might signal an error.
    
+ 
    
+Rationale:
    
+ 
    
+This proposal is the only simple resolution of the problem description that
    
+we can imagine that is consistent with current implementation techniques.
    
+ 
    
+Allowing arbitrary redefinition of symbols in the system would place
    
+severe restrictions on implementations not to actually use those symbols in
    
+macro expansions of other symbols, in function calls, etc. While some
    
+looser restrictions might do for any particular Common Lisp implementation,
    
+there seems to be no good way to distinguish between those symbols that are
    
+redefinable and those that are not.
    
+ 
    
+In general, programs can redefine functions safely by creating new symbols in
    
+their own package, possibly shadowing the name.
    
+ 
    
+Current practice:
    
+ 
    
+Many Lisp environments have some mechanism for warning about redefinition of
    
+Lisp symbols and preventing accidental redefinition while allowing it where
    
+necessary (e.g., to patch the Lisp system itself, fix a bug, add an
    
+optimization.)
    
+ 
    
+Fewer check for lexical redefinition, since such redefinition is not as
    
+dangerous. Certainly, there are some symbols that are never used in macro
    
+expansions of the standard Common Lisp macros. However, implementations do
    
+differ on the behavior of macro expansions.
    
+ 
    
+Cost to Implementors:
    
+ 
    
+This proposal clarifies the status quo -- that the consequences are undefined.
    
+It allows and encourages implementors to check for such redefinition, but does
    
+not require it.
    
+ 
    
+Cost to Users:
    
+ 
    
+This proposal clarifies that implementations are free to check for a condition
    
+that they might not have before, and may clarify that some current user code is
    
+non-portable.
    
+ 
    
+Benefits:
    
+ 
    
+This issue frequently arises. Adopting this proposal would clarify a frequent
    
+source of question about Common Lisp. 
    
+ 
    
+Cost of non-adoption:
    
+ 
    
+Continued questions.
    
+ 
    
+Esthetics:
    
+ 
    
+Disallowing all redefinition is the simplest way of disallowing the ones that
    
+really are trouble. 
    
+ 
    
+Discussion:
    
+ 
    
+At the March 89 X3j13 meeting, a proposed additional constraint 
    
+("Altering its property list") was removed. Presumably this means
    
+that conformal programs are allowed to alter the property list of
    
+ symbols in the COMMON-LISP package.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215.htm new file mode 100644 index 00000000..b97514f9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue LOAD-OBJECTS:MAKE-LOAD-FORM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOAD-OBJECTS:MAKE-LOAD-FORM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LOAD-OBJECTS:MAKE-LOAD-FORM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215_w.htm new file mode 100644 index 00000000..083e35fd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss215_w.htm @@ -0,0 +1,319 @@ + + + +CLHS: Issue LOAD-OBJECTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOAD-OBJECTS Writeup

    + +
    Issue:         LOAD-OBJECTS
    
+
    
+References:    none
    
+
    
+Related issues: LOAD-TIME-EVAL,
    
+                CONSTANT-COMPILABLE-TYPES,
    
+                CONSTANT-CIRCULAR-COMPILATION
    
+
    
+Category:      ADDITION
    
+
    
+Forum:         Cleanup
    
+
    
+Edit history:  Version 1, 2-Jan-89, by Moon (for discussion)
    
+               Version 2, 13-Jan-89, by Moon (draft updated from discussion)
    
+               Version 3,  9-Mar-89, by Moon (changes suggested by discussion)
    
+	       Version 4, 4-Apr-89, by Pitman (changes per X3J13 Mar 89; 
    
+		 MAKE-LOAD-FORM-USING-SLOTS => MAKE-LOAD-FORM-SAVING-SLOTS)
    
+
    
+Status:  Accepted by an 18-0 vote, March 1989.
    
+
    
+Problem description:
    
+
    
+  Common Lisp doesn't provide any way to use an object of a user-defined
    
+  type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
    
+  compiled with COMPILE-FILE.  The problem is that LOAD has to be able
    
+  to "reconstruct" an equivalent object when the compiled-code file is
    
+  loaded, but the programmer has no way to tell LOAD how to do that.
    
+
    
+
    
+Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
    
+          
    
+  Define a new generic function named MAKE-LOAD-FORM, which takes one
    
+  argument and returns two values.  The argument is an object that is
    
+  referenced as a constant or as a self-evaluating form in a file being
    
+  compiled by COMPILE-FILE.  The objective is to enable LOAD to
    
+  construct an equivalent object.
    
+
    
+  The first value, called the "creation form," is a form that, when
    
+  evaluated at load time, should return an object that is equivalent to
    
+  the argument.  The exact meaning of "equivalent" depends on the type
    
+  of object and is up to the programmer who defines a method for
    
+  MAKE-LOAD-FORM.  This is the same type of equivalence discussed
    
+  in issue CONSTANT-COMPILABLE-TYPES.
    
+
    
+  The second value, called the "initialization form," is a form that,
    
+  when evaluated at load time, should perform further initialization of
    
+  the object.  The value returned by the initialization form is ignored.
    
+  If the MAKE-LOAD-FORM method returns only one value, the
    
+  initialization form is NIL, which has no effect.  If the object used
    
+  as the argument to MAKE-LOAD-FORM appears as a constant in the
    
+  initialization form, at load time it will be replaced by the
    
+  equivalent object constructed by the creation form; this is how the
    
+  further initialization gains access to the object.
    
+
    
+  Both the creation form and the initialization form can contain
    
+  references to objects of user-defined types (defined precisely below).
    
+  However, there must not be any circular dependencies in creation forms.
    
+  An example of a circular dependency is when the creation form for the
    
+  object X contains a reference to the object Y, and the creation form
    
+  for the object Y contains a reference to the object X.  A simpler
    
+  example would be when the creation form for the object X contains
    
+  a reference to X itself.  Initialization forms are not subject to
    
+  any restriction against circular dependencies, which is the entire
    
+  reason that initialization forms exist.  See the example of circular
    
+  data structures below.
    
+
    
+  The creation form for an object is always evaluated before the
    
+  initialization form for that object.  When either the creation form or
    
+  the initialization form references other objects of user-defined types
    
+  that have not been referenced earlier in the COMPILE-FILE, the
    
+  compiler collects all of the creation and initialization forms.  Each
    
+  initialization form is evaluated as soon as possible after its
    
+  creation form, as determined by data flow.  If the initialization form
    
+  for an object does not reference any other objects of user-defined
    
+  types that have not been referenced earlier in the COMPILE-FILE, the
    
+  initialization form is evaluated immediately after the creation form.
    
+  If a creation or initialization form F references other objects of
    
+  user-defined types that have not been referenced earlier in the
    
+  COMPILE-FILE, the creation forms for those other objects are evaluated
    
+  before F, and the initialization forms for those other objects are
    
+  also evaluated before F whenever they do not depend on the object
    
+  created or initialized by F.  Where the above rules do not uniquely
    
+  determine an order of evaluation, which of the possible orders of
    
+  evaluation is chosen is unspecified.
    
+
    
+  While these creation and initialization forms are being evaluated, the
    
+  objects are possibly in an uninitialized state, analogous to the state
    
+  of an object between the time it has been created by ALLOCATE-INSTANCE
    
+  and it has been processed fully by INITIALIZE-INSTANCE.  Programmers
    
+  writing methods for MAKE-LOAD-FORM must take care in manipulating
    
+  objects not to depend on slots that have not yet been initialized.
    
+
    
+  It is unspecified whether LOAD calls EVAL on the forms or does some
    
+  other operation that has an equivalent effect.  For example, the
    
+  forms might be translated into different but equivalent forms and
    
+  then evaluated, they might be compiled and the resulting functions
    
+  called by LOAD, or they might be interpreted by a special-purpose
    
+  interpreter different from EVAL.  All that is required is that the
    
+  effect be equivalent to evaluating the forms.
    
+
    
+  COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
    
+  a constant or as a self-evaluating form, if the object's metaclass is
    
+  STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
    
+  subclass of BUILT-IN-CLASS), or any of a possibly-empty
    
+  implementation-defined list of other metaclasses.  COMPILE-FILE will
    
+  only call MAKE-LOAD-FORM once for any given object (compared with EQ)
    
+  within a single file.
    
+
    
+  It is valid for user programs to call MAKE-LOAD-FORM in other
    
+  circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
    
+  or a subclass of BUILT-IN-CLASS.
    
+
    
+  Define a new function named MAKE-LOAD-FORM-SAVING-SLOTS, which takes
    
+  one required argument and one optional argument and returns two
    
+  values.  This can be useful in user-written MAKE-LOAD-FORM methods.
    
+  The first argument is the object.  The optional second argument is a
    
+  list of the names of the slots to preserve; it defaults to all of the
    
+  local slots.  MAKE-LOAD-FORM-SAVING-SLOTS returns forms that construct
    
+  an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
    
+  slots with values, or SLOT-MAKUNBOUND for slots without values, or
    
+  using other functions of equivalent effect.
    
+  MAKE-LOAD-FORM-SAVING-SLOTS returns two values, thus it can deal with
    
+  circular structures.  MAKE-LOAD-FORM-SAVING-SLOTS works for any object
    
+  of metaclass STANDARD-CLASS or STRUCTURE-CLASS.  Whether the result is
    
+  useful in an application depends on whether the object's type and slot
    
+  contents fully capture the application's idea of the object's state.
    
+
    
+  MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
    
+  STRUCTURE-CLASS for which no user-defined method is applicable signals
    
+  an error.  It is valid to implement this either by defining default
    
+  methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
    
+  or by having no applicable method for those classes.
    
+
    
+
    
+Examples:
    
+
    
+  ;; Example 1
    
+  (defclass my-class ()
    
+     ((a :initarg :a :reader my-a)
    
+      (b :initarg :b :reader my-b)
    
+      (c :accessor my-c)))
    
+  (defmethod shared-initialize ((self my-class) ignore &rest ignore)
    
+    (unless (slot-boundp self 'c)
    
+      (setf (my-c self) (some-computation (my-a self) (my-b self)))))
    
+  (defmethod make-load-form ((self my-class))
    
+    `(make-instance ',(class-name (class-of self))
    
+                    :a ',(my-a self) :b ',(my-b self)))
    
+
    
+  In this example, an equivalent instance of my-class is reconstructed
    
+  by using the values of two of its slots.  The value of the third slot
    
+  is derived from those two values.
    
+
    
+  Another way to write the last form in the above example would have been
    
+
    
+  (defmethod make-load-form ((self my-class))
    
+     (make-load-form-saving-slots self '(a b)))
    
+
    
+  ;; Example 2
    
+  (defclass my-frob ()
    
+     ((name :initarg :name :reader my-name)))
    
+  (defmethod make-load-form ((self my-frob))
    
+    `(find-my-frob ',(my-name self) :if-does-not-exist :create))
    
+
    
+  In this example, instances of my-frob are "interned" in some way.
    
+  An equivalent instance is reconstructed by using the value of the
    
+  name slot as a key for searching existing objects.  In this case
    
+  the programmer has chosen to create a new object if no existing
    
+  object is found; alternatively she could have chosen to signal an
    
+  error in that case.
    
+
    
+  ;; Example 3
    
+  (defclass tree-with-parent () ((parent :accessor tree-parent)
    
+                                 (children :initarg :children)))
    
+  (defmethod make-load-form ((x tree-with-parent))
    
+    (values
    
+      ;; creation form
    
+      `(make-instance ',(class-of x) :children ',(slot-value x 'children))
    
+      ;; initialization form
    
+      `(setf (tree-parent ',x) ',(slot-value x 'parent))))
    
+
    
+  In this example, the data structure to be dumped is circular, because
    
+  each parent has a list of its children and each child has a reference
    
+  back to its parent.  Suppose make-load-form is called on one object in
    
+  such a structure.  The creation form creates an equivalent object and
    
+  fills in the children slot, which forces creation of equivalent
    
+  objects for all of its children, grandchildren, etc.  At this point
    
+  none of the parent slots have been filled in.  The initialization form
    
+  fills in the parent slot, which forces creation of an equivalent
    
+  object for the parent if it was not already created.  Thus the entire
    
+  tree is recreated at load time.  At compile time, MAKE-LOAD-FORM is
    
+  called once for each object in the true.  All of the creation forms
    
+  are evaluated, in unspecified order, and then all of the
    
+  initialization forms are evaluated, also in unspecified order.
    
+
    
+  ;; Example 4
    
+  (defstruct my-struct a b c)
    
+  (defmethod make-load-form ((s my-struct))
    
+     (make-load-form-saving-slots s))
    
+
    
+  In this example, the data structure to be dumped has no special
    
+  properties and an equivalent structure can be reconstructed
    
+  simply by reconstructing the slots' contents.
    
+
    
+
    
+Rationale:
    
+
    
+  Only the programmer who designed a class can know the correct
    
+  way to reconstruct objects of that class at load time, therefore
    
+  the reconstruction should be controlled by a generic function.
    
+  Using EVAL as the interface for telling LOAD what to do provides
    
+  full generality.
    
+
    
+  MAKE-LOAD-FORM returns two values so that circular structures can
    
+  be handled.  If CONSTANT-CIRCULAR-COMPILATION is rejected,
    
+  MAKE-LOAD-FORM will only return one value, although implementations
    
+  that make an extension to support circular constants will probably
    
+  also make the extension to accept two values from MAKE-LOAD-FORM.
    
+
    
+  The default for class objects and structures is to signal an error,
    
+  rather than picking some particular object reconstruction technique,
    
+  because no reconstruction technique is appropriate for all objects.
    
+  It only takes two lines of code, as in example 4, to instruct the
    
+  compiler to use the technique that most often has been suggested
    
+  as the default.
    
+
    
+  MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
    
+  for the programmer to control the system's actions.
    
+
    
+  The order of evaluation rules for creation and initialization forms
    
+  eliminate the possibility of partially initialized objects in the
    
+  absence of circular structures, and reduce it to the minimum possible
    
+  in the presence of circular structures.  This allows nodes in
    
+  non-circular structures to be built out of fully initialized subparts.
    
+
    
+
    
+Current practice:
    
+
    
+  Symbolics Flavors has something like this, but under a different name.
    
+  The name Symbolics uses is not suitable for standardization.
    
+
    
+  JonL reports that Lucid is getting more and more requests for this.
    
+
    
+Cost to Implementors:
    
+
    
+  This seems like only a few one-line changes in the compiled-code
    
+  file writer and reader.  MAKE-LOAD-FORM-SAVING-SLOTS is a couple
    
+  dozen lines of code, assuming the presence of the CLOS metaobject
    
+  protocol or an implementation-dependent equivalent.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Serious impairment of the ability to use extended-type objects.  Each
    
+  implementation will probably make up its own version of this as an
    
+  extension.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  See Cost of non-adoption.
    
+
    
+Esthetics:
    
+
    
+  No significant positive or negative impact.
    
+
    
+Discussion:
    
+
    
+  It would be possible to define an additional level of protocol that
    
+  allows multiple classes to contribute to the reconstruction of an
    
+  object, combining initialization arguments contributed by each class.
    
+  Since a user can easily define that in terms of MAKE-LOAD-FORM without
    
+  modifying the Lisp system, it is not being proposed now.
    
+
    
+  Any type that has a read syntax is likely to appear as a quoted
    
+  constant or inside a quoted constant.  Pathnames are one example, user
    
+  programs often define others.  Also many implementations provide a way
    
+  to create a compiled-code file full of data (rather than compiled Lisp
    
+  programs), and such data probably include extended-type objects.
    
+
    
+  Moon supports this.  David Gray and John Rose made major contributions
    
+  to the discussion that produced this improved version 2 proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216.htm new file mode 100644 index 00000000..7cf599f8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_m.htm new file mode 100644 index 00000000..e16c7310 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue LOAD-TIME-EVAL Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue LOAD-TIME-EVAL Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_w.htm new file mode 100644 index 00000000..e7e3e508 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss216_w.htm @@ -0,0 +1,351 @@ + + + +CLHS: Issue LOAD-TIME-EVAL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOAD-TIME-EVAL Writeup

    + +
    Forum:		Compiler
    
+Issue:          LOAD-TIME-EVAL
    
+References:     #, (p. 356),  (EVAL-WHEN (LOAD) ...) (p. 69-70)
    
+		issue SHARP-COMMA-CONFUSION
    
+Category:       ADDITION
    
+Edit history:   06-Jun-87, Version 1 by James Kempf
    
+                17-Jul-87, Version 2 by James Kempf
    
+                12-Nov-87, Version 3 by Pitman (alternate direction)
    
+                01-Feb-88, Version 4 by Moon
    
+                  (from version 2 w/ edits suggested by Masinter)
    
+                06-Jun-88, Version 5 by Pitman
    
+                  (fairly major overhaul, merging versions 3 and 4)
    
+                21-Sep-88, Version 6 by Moon (stripped down)
    
+		17-Oct-88, Version 7 by Loosemore (change direction again)
    
+		30-Dec-88, Version 8 by Loosemore (tweaks)
    
+		23-Jan-89, Version 9 by Loosemore (amendments)
    
+		02-Mar-89, Version 10 by Loosemore (new proposal)
    
+		11-Mar-89, Version 11 by Loosemore
    
+
    
+
    
+Problem description:
    
+
    
+ Common Lisp provides reader syntax (#,) which allows the programmer
    
+ to designate that a particular expression within a program is to be
    
+ evaluated early (at load time) but to later be treated as a constant.
    
+ Unfortunately, no access to this capability is available to programs
    
+ which construct other programs without going through the reader.
    
+    
    
+ Some computations can be deferred until load time by use of EVAL-WHEN,
    
+ but since EVAL-WHEN must occur only at toplevel, and since the nesting
    
+ behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
    
+ solution to the problem of load-time computation of program constants.
    
+
    
+ Proposal R**2-NEW-SPECIAL-FORM was approved at the January 1989
    
+ meeting.  After the meeting, some additional suggestions were made that
    
+ have been incorporated into proposal R**3-NEW-SPECIAL-FORM.  The sections
    
+ of the two proposals that differ are marked with change bars in the margin.
    
+ 
    
+Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
    
+    
    
+ Add a new special form, LOAD-TIME-VALUE, which has the following
    
+ contract:
    
+
    
+   LOAD-TIME-VALUE form &optional read-only-p	[Special Form]
    
+
    
+   LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
    
+   until the expression is in the "runtime" environment.  
    
+
    
+   If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
    
+|  performs normal semantic processing such as macro expansion but
    
+|  arranges for the evaluation of <form> to occur at load time in a null
    
+   lexical environment, with the result of this evaluation then being
    
+   treated as an immediate quantity at run time.  It is guaranteed that 
    
+   the evaluation of <form> will take place only once when the file is 
    
+   loaded, but the order of evaluation with respect to the "evaluation" 
    
+   of top-level forms in the file is unspecified.
    
+
    
+   If a LOAD-TIME-VALUE expression appears within a function compiled
    
+   with COMPILE, the <form> is evaluated at compile time in a null lexical
    
+   environment.  The result of this compile-time evaluation is treated as 
    
+   an immediate quantity in the compiled code.  
    
+
    
+   In interpreted code, <form> is evaluated (by EVAL) in a null
    
+   lexical environment, and one value is returned.  Implementations which
    
+   implicitly compile (or partially compile) expressions passed to
    
+   EVAL may evaluate the <form> only once, at the time this
    
+   compilation is performed.  This is intentionally similar to the
    
+   freedom which implementations are given for the time of expanding
    
+   macros in interpreted code.
    
+
    
+|  Note that, in interpreted code, there is no guarantee as to when
    
+|  evaluation of <form> will take place, or the number of times the
    
+|  evaluation will be performed.  Since successive evaluations of the
    
+|  same LOAD-TIME-VALUE expression may or may not result in an evaluation
    
+|  which returns a "fresh" object, destructive side-effects to the
    
+|  resulting object may or may not persist from one evaluation to the
    
+|  next.  It is safest to explicitly initialize the object returned by
    
+|  LOAD-TIME-VALUE, if it is later modified destructively.
    
+|   Implementations must guarantee that each reference to a
    
+|  LOAD-TIME-VALUE expression results in at least one evaluation of its
    
+|  nested <form>.  For example,
    
+|    (DEFMACRO CONS-SELF (X)
    
+|        `(CONS ,X ,X))
    
+|    (CONS-SELF (LOAD-TIME-VALUE (COMPUTE-IT)))
    
+|  must perform two calls to COMPUTE-IT; although there is only one
    
+|  unique LOAD-TIME-VALUE expression, there are two distinct references
    
+|  to it.
    
+|
    
+|  In the case of a LOAD-TIME-VALUE form appearing in a quoted expression 
    
+|  passed to EVAL, each call to EVAL must result in a new evaluation of 
    
+|  <form>.  For example,
    
+|    (DEFVAR X 0)
    
+|    (DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
    
+|  is guaranteed to increment X each time FOO is called, while
    
+|    (DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
    
+|  may cause X to be evaluated only once.
    
+
    
+   The READ-ONLY-P argument designates whether the result can be considered
    
+   read-only constant. If NIL (the default), the result must be considered 
    
+   ordinary, modifiable data. If T, the result is a read-only quantity
    
+   which may, as appropriate, be copied into read-only space and/or shared
    
+   with other programs. (Because this is a special form, this argument is
    
+   -not- evaluated and only the literal symbols T and NIL are permitted.)
    
+
    
+
    
+ Rationale:
    
+
    
+   LOAD-TIME-VALUE is a special form rather than a function or macro 
    
+   because it requires special handling by the compiler.
    
+
    
+   Requiring the compiler to perform semantic processing such as macro
    
+   expansion on the nested <form>, rather than delaying all such processing
    
+   until load time, has the advantages that fewer macro libraries may need
    
+   to be available at load time, and that loading may be faster and result
    
+   in less consing due to macroexpansion.  If users really want to delay
    
+   macroexpansion to load time, this can be done with an explicit call to
    
+   EVAL, e.g.
    
+  
    
+    (LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
    
+    
    
+   Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
    
+   evaluated more than once makes simplifies its implementation in
    
+   interpreters which do not perform a preprocessing code walk.  It also
    
+   makes the rules for the time of its processing analogous to those
    
+   for macro expansion.
    
+
    
+   This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
    
+   read macro.  Doing so would be an incompatible change to the definition
    
+   of #, (which is reliably useful only -inside- quoted structure,
    
+   while LOAD-TIME-VALUE must appear -outside- quoted structure in a
    
+   for-evaluation position).
    
+
    
+   The requirement that LOAD-TIME-VALUE expressions be evaluated once per
    
+   reference (rather than once per unique expression) prevents problems 
    
+   that could result by performing destructive side-effects on a value 
    
+   that is unexpectedly referenced in more than one place.
    
+
    
+
    
+Proposal (LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM):
    
+    
    
+ Add a new special form, LOAD-TIME-VALUE, which has the following
    
+ contract:
    
+
    
+   LOAD-TIME-VALUE form &optional read-only-p	[Special Form]
    
+
    
+   LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
    
+   until the expression is in the "runtime" environment.  
    
+
    
+   If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
    
+|  performs its normal semantic processing (such as macro expansion and
    
+|  translation into machine code) on the form, but arranges for the
    
+|  execution of <form> to occur at load time in a null
    
+   lexical environment, with the result of this evaluation then being
    
+   treated as an immediate quantity at run time.  It is guaranteed that 
    
+   the evaluation of <form> will take place only once when the file is 
    
+   loaded, but the order of evaluation with respect to the "evaluation" 
    
+   of top-level forms in the file is unspecified.
    
+
    
+   If a LOAD-TIME-VALUE expression appears within a function compiled
    
+   with COMPILE, the <form> is evaluated at compile time in a null lexical
    
+   environment.  The result of this compile-time evaluation is treated as 
    
+   an immediate quantity in the compiled code.  
    
+
    
+   In interpreted code, <form> is evaluated (by EVAL) in a null
    
+   lexical environment, and one value is returned.  Implementations which
    
+   implicitly compile (or partially compile) expressions passed to
    
+   EVAL may evaluate the <form> only once, at the time this
    
+   compilation is performed.  This is intentionally similar to the
    
+   freedom which implementations are given for the time of expanding
    
+   macros in interpreted code.
    
+
    
+|  If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
    
+|  evaluated or compiled more than once, it is unspecified whether <form>
    
+|  is evaluated only once or is evaluated more than once.  This can
    
+|  happen both when an expression being evaluated or compiled shares
    
+|  substructure, and when the same expression is passed to EVAL or to
    
+|  COMPILE multiple times.  Since a LOAD-TIME-VALUE expression may be
    
+|  referenced in more than one place and may be evaluated multiple times
    
+|  by the interpreter, it is unspecified whether each execution returns
    
+|  a "fresh" object or returns the same object as some other execution.
    
+|  Users must use caution when destructively modifying the resulting
    
+|  object.
    
+|
    
+|  If two lists (LOAD-TIME-VALUE <form>) are EQUAL but not EQ, their
    
+|  values always come from distinct evaluations of <form>.  Coalescing
    
+|  of these forms is not permitted.
    
+
    
+   The READ-ONLY-P argument designates whether the result can be considered
    
+   read-only constant. If NIL (the default), the result must be considered 
    
+   ordinary, modifiable data. If T, the result is a read-only quantity
    
+   which may, as appropriate, be copied into read-only space and/or shared
    
+   with other programs. (Because this is a special form, this argument is
    
+   -not- evaluated and only the literal symbols T and NIL are permitted.)
    
+
    
+
    
+ Rationale:
    
+
    
+   LOAD-TIME-VALUE is a special form rather than a function or macro 
    
+   because it requires special handling by the compiler.
    
+
    
+   Requiring the compiler to perform semantic processing such as macro
    
+   expansion on the nested <form>, rather than delaying all such processing
    
+   until load time, has the advantages that fewer macro libraries may need
    
+   to be available at load time, and that loading may be faster and result
    
+   in less consing due to macroexpansion.  If users really want to delay
    
+   macroexpansion to load time, this can be done with an explicit call to
    
+   EVAL, e.g.
    
+  
    
+    (LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
    
+    
    
+   Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
    
+   evaluated more than once makes simplifies its implementation in
    
+   interpreters which do not perform a preprocessing code walk.  It also
    
+   makes the rules for the time of its processing analogous to those
    
+   for macro expansion.
    
+
    
+   This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
    
+   read macro.  Doing so would be an incompatible change to the definition
    
+   of #, (which is reliably useful only -inside- quoted structure,
    
+   while LOAD-TIME-VALUE must appear -outside- quoted structure in a
    
+   for-evaluation position).
    
+
    
+   Allowing multiple references to the same LOAD-TIME-VALUE expression
    
+   to result in only one interpretation allows it to be specified more
    
+   cleanly.  It also allows interpreters that do not perform a prepass
    
+   to cache LOAD-TIME-VALUE expressions.
    
+
    
+
    
+Current Practice:
    
+
    
+   This is an addition to the language and has not yet been implemented.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+   In compiled code, (LOAD-TIME-VALUE <form>) is similar to 
    
+   '#,<form>.  Most implementations can probably make use of the same 
    
+   mechanism they use to handle #, to handle LOAD-TIME-VALUE.  Note that
    
+   #, does not currently provide a mechanism for dealing with 
    
+   non-read-only-ness.
    
+
    
+   Implementing LOAD-TIME-VALUE in the interpreter should be fairly
    
+   straightforward, since one simply needs to evaluate the <form> in the
    
+   null lexical environment.  Implementations that use a preprocessing
    
+   code walk in the interpreter to perform macro expansion could process
    
+   LOAD-TIME-VALUE forms at that time.
    
+
    
+   Some code-walkers would have to be taught about this new
    
+   special form. Such changes would likely be trivial.
    
+
    
+
    
+Cost to Users:
    
+
    
+   Some code-walkers would have to be taught about this new
    
+   special form. Such changes would likely be trivial.
    
+
    
+
    
+Benefits:
    
+
    
+   Users are given a mechanism that to force evaluation to be delayed 
    
+   until load time that does not rely on a feature of the reader.
    
+
    
+
    
+Discussion:
    
+
    
+   Earlier versions (up to version 7) of this proposal stated that
    
+   all semantic processing of the LOAD-TIME-VALUE form should be postponed
    
+   until load time.  
    
+
    
+   The semantics of LOAD-TIME-VALUE would be simplified considerably if
    
+   the READ-ONLY-P argument were removed and destructive operations on
    
+   the result of evaluating <form> prohibited.  However, some people feel
    
+   that the ability to destructively modify the value is an essential
    
+   feature to include.
    
+
    
+   "Collapsing" of multiple references to the same LOAD-TIME-VALUE 
    
+   expression could be allowed for read-only situations, but it seems 
    
+   like it would be more confusing to make it legal in some situations 
    
+   and not in others.
    
+
    
+   A number of other alternatives have been considered on this issue, 
    
+   including:
    
+
    
+   - A proposal for a new special form that would force evaluation of
    
+     the <form> to happen only once.  This was rejected because of
    
+     implementation difficulties.
    
+
    
+   - A proposal to add a function making the "magic cookie" used by #,
    
+     available to user code.  The current proposal does not prevent such
    
+     a function from being added, but this approach appeared to have
    
+     less support than making the hook available as a new special form.
    
+
    
+   - A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
    
+
    
+   - A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
    
+
    
+
    
+Kent Pitman says:
    
+   Although I'm willing to take multiple evaluation in the interpreter
    
+   as a compromise position, I would like it mentioned in the discussion
    
+   that this was only an expedient to getting this issue accepted at all,
    
+   and that I'm not really happy about it. I have said that I think a
    
+   number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
    
+   this -- for example) are due to the presence of interpreters which do
    
+   not do a semantic-prepass at a known time. If I had my way, we would
    
+   require a semantic pre-pass and we would then be able to forbid
    
+   multiple evaluations even in the interpreter.
    
+
    
+Moon and Gray support proposal R**3-NEW-SPECIAL-FORM.
    
+
    
+Pitman also expressed willingness to go along with
    
+R**3-NEW-SPECIAL-FORM, but was somewhat concerned that coalescing
    
+LOAD-TIME-VALUE results based on EQ-ness of the LOAD-TIME-VALUE form
    
+could conceivably lead to trouble down the line. However, since he
    
+could provide no actual examples to back up that worry, and since the
    
+majority opinion was that some implementations would find a
    
+restriction against such coalescing an undue burden, the decision was
    
+made to just `note the concern' and proceed on.  Sandra Loosemore and
    
+JonL White concur with this position.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss217.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss217.htm new file mode 100644 index 00000000..0bc7f93b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss217.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218.htm new file mode 100644 index 00000000..bf2bb5fb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue LOAD-TRUENAME:NEW-PATHNAME-VARIABLES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOAD-TRUENAME:NEW-PATHNAME-VARIABLES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LOAD-TRUENAME:NEW-PATHNAME-VARIABLES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218_w.htm new file mode 100644 index 00000000..7e801691 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss218_w.htm @@ -0,0 +1,214 @@ + + + +CLHS: Issue LOAD-TRUENAME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOAD-TRUENAME Writeup

    + +
    Status: Passed, Jun 89 X3J13
    
+
    
+Issue:        LOAD-TRUENAME
    
+Forum:	      Cleanup
    
+References:   LOAD (p426), PROVIDE (p188), REQUIRE (p188),
    
+	      Issue REQUIRE-PATHNAME-DEFAULTS
    
+Category:     ADDITION
    
+Edit history: 13-Mar-89, Version 1 by Pitman
    
+	      29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
    
+	      10-Apr-89, Version 3 by Pitman (clarify v2)
    
+	      11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
    
+
    
+Problem Description:
    
+
    
+ It is difficult to construct sets of software modules which work
    
+ together as a unit and which port between different implementations.
    
+
    
+ REQUIRE and PROVIDE were intended to provide this level of support
    
+ but have `failed' to be portable in practice.
    
+
    
+ Typical user configurations involve a `system definition' file which
    
+ loads the modules of a `system' (collection of software modules).
    
+
    
+ Among the specific problems which arise are:
    
+
    
+  - File system types may vary. Different file syntax must be used for
    
+    each site.
    
+
    
+  - Even with the same Lisp implementation and host file system type,
    
+    the directory in which a software system resides may differ from
    
+    delivery site to delivery site.
    
+
    
+  - Multiple `copies' of the same system may reside in different
    
+    directories on the same machine.
    
+
    
+Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
    
+
    
+ Introduce new variables:
    
+
    
+   *LOAD-TRUENAME*					[Variable]
    
+
    
+   This special variable is initially NIL, but is bound by LOAD to
    
+   hold the truename of the pathname of the file being loaded.
    
+
    
+   *COMPILE-FILE-TRUENAME*				[Variable]
    
+
    
+   This special variable is initially NIL, but is bound by 
    
+   COMPILE-FILE to hold the truename of the pathname of the file
    
+   being compiled.
    
+   
    
+   *LOAD-PATHNAME*					[Variable]
    
+  
    
+   This special variable is initially NIL but is bound by LOAD
    
+   to hold a pathname which represents the filename given as the
    
+   first argument to LOAD merged against the defaults.
    
+   That is, (PATHNAME (MERGE-PATHNAMES arg1)).
    
+  
    
+   *COMPILE-FILE-PATHNAME*				[Variable]
    
+  
    
+   This special variable is initially NIL but is bound by COMPILE-FILE
    
+   to hold a pathname which represents the filename given as the
    
+   first argument to COMPILE-FILE merged against the defaults.
    
+   That is, (PATHNAME (MERGE-PATHNAMES arg1)).
    
+
    
+Example:
    
+
    
+ ------ File SETUP ------
    
+ (IN-PACKAGE "MY-STUFF")
    
+ (DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
    
+ (DEFVAR *MY-COMPILE-TRUENAME* (COMPILE-TRUENAME) "Just for debugging.")
    
+ (DEFVAR *MY-LOAD-PATHNAME* *LOAD-PATHNAME*)
    
+ (DEFUN LOAD-MY-SYSTEM ()
    
+   (DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
    
+     (LOAD (MERGE-PATHNAMES MODULE-NAME *MY-LOAD-PATHNAME*))))
    
+ ------------------------
    
+
    
+ (LOAD "SETUP")
    
+ (LOAD-MY-SYSTEM)
    
+
    
+Rationale:
    
+
    
+ This satisfies the most common instances of the frequently reported
    
+ problem in the Problem Description.
    
+
    
+ The ...-TRUENAME* variables are useful to tell the real file being
    
+ loaded.
    
+
    
+ The ...-PATHNAME* variables are useful to find information about
    
+ the original link names or logical device names mentioned in the
    
+ pathname to be opened but no longer reflected in the truename.
    
+
    
+ Note that it is not adequate to just have the -PATHNAME* variables
    
+ since TRUENAME on these pathnames might not yield the value of the
    
+ -TRUENAME* variables if the file has been deleted or protected
    
+ since the open occurred (in some implementations).
    
+
    
+Current Practice:
    
+
    
+ Wide variation.
    
+
    
+ In some implementations, calling LOAD binds or sets 
    
+ *DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
    
+ LOADed will default to being `nearby.'
    
+
    
+ Some implementations provide special variables that are similar or
    
+ identical to one or both of those proposed.
    
+
    
+ Some implementations have a way to represent the pathname for the
    
+ current working directory, and make the default pathname default
    
+ to that, so that loading without specifying a default again tends to
    
+ get `nearby' files.
    
+
    
+ None of these techniques is portable, unfortunately, because there
    
+ is no agreement.
    
+
    
+Cost to Implementors:
    
+
    
+ Very small.
    
+
    
+Cost to Users:
    
+
    
+ None. This change is upward compatible.
    
+
    
+Cost of Non-Adoption:
    
+
    
+ Continued difficulty for anyone trying to put a system of modules
    
+ in a form where they can be conveniently delivered using portable code.
    
+
    
+Benefits:
    
+
    
+ The cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+ Negligible.
    
+
    
+Discussion:
    
+
    
+ Touretzky raised the issue most recently on Common-Lisp. A number
    
+ of people immediately jumped on the bandwagon, indicating it was
    
+ important to them, too.
    
+
    
+ Pitman made three suggestions in response, of which the above is
    
+ the first. The others included:
    
+  2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
    
+     lists of the truenames of all files being loaded or compiled,
    
+     respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
    
+ 
    
+  3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
    
+    ((LOAD truename) (COMPILE-FILE truename) ...)
    
+    during the dynamic invocation of LOAD and COMPILE-FILE.
    
+ 
    
+ Touretzky responded:
    
+ ``I like KMP's proposals.  I like the second one best: have separate
    
+   variables for files being loaded and files being compiled, and use
    
+   them to maintain a stack so we can see the nesting of loads within
    
+   files.''
    
+
    
+ Pitman ultimately chose to present the first rather than the second
    
+ because it seemed simpler, easier to explain, and more likely to
    
+ pass at this late date.
    
+
    
+ Other suggestions which were considered discarded were:
    
+  a. Provide just variables *LOAD-STREAM* and *COMPILE-FILE-STREAM*.
    
+     Then PATHNAME and TRUENAME could be used to yield the 
    
+     information contained in the -PATHNAME* and -TRUENAME* variables
    
+     of the proposal above.
    
+  b. Like (a), but call both variables *STANDARD-INPUT*. That is,
    
+     say that LOAD and COMPILE-FILE bind *STANDARD-INPUT* to the
    
+     stream being loaded.
    
+ There were a number of pitfalls with this approach which all center
    
+ around the way it invites the user to do other operations besides
    
+ PATHNAME and TRUENAME.  Not only would some people be confused by
    
+ the difference between the characteristics of *LOAD-STREAM* for
    
+ compiled and interpreted files, but also even with interpreted 
    
+ streams, the actual position of the stream pointer at the time of
    
+ execution of the forms contained in the file could vary between
    
+ implementations in a way that became a lurking portability barrier.
    
+ Since the observed user need which spawned this discussion was for
    
+ a way to tell what file was being loaded and not for a way to 
    
+ manipulate the stream, it seemed best to just go with the variables
    
+ that addressed that specific need--fewer pitfalls and more perspicuous
    
+ code are likely to result.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219.htm new file mode 100644 index 00000000..3efc7997 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOCALLY-TOP-LEVEL:SPECIAL-FORM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOCALLY-TOP-LEVEL:SPECIAL-FORM Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOCALLY-TOP-LEVEL:SPECIAL-FORM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219_w.htm new file mode 100644 index 00000000..b041cebb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss219_w.htm @@ -0,0 +1,145 @@ + + + +CLHS: Issue LOCALLY-TOP-LEVEL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOCALLY-TOP-LEVEL Writeup

    + +
    Issue:         LOCALLY-TOP-LEVEL
    
+
    
+References:    None
    
+
    
+Related issues: EVAL-WHEN-NON-TOP-LEVEL, DECLARATION-SCOPE
    
+
    
+Category:      CLARIFICATION / ADDITION
    
+
    
+Edit history:  Version 1,  9-Mar-89, by Moon
    
+               Version 2, 16-Mar-89, by Moon, fix referenced proposal name
    
+
    
+Problem description:
    
+
    
+  It is desirable to be able to wrap LOCALLY around one or more
    
+  top-level forms and have them continue to be treated as top-level
    
+  forms.  Three examples of how this is useful:
    
+
    
+   - to put an OPTIMIZE or INLINE declaration into force around
    
+     several related forms.
    
+
    
+   - to put declarations into force around DEFCLASS, or any other
    
+     top-level form that lacks a syntax for embedded declarations.
    
+
    
+   - DECLARATION-SCOPE:NO-HOISTING, which passed in January,
    
+     removed the ability to use a DECLARE at the head of the body of a
    
+     DEFUN or DEFMACRO to make a declaration that applies to the entire
    
+     form, including the lambda-list.  We are supposed to use LOCALLY
    
+     instead, but forms in the body of LOCALLY are not top-level,
    
+     and that changes the semantics of DEFMACRO.
    
+
    
+  Issue EVAL-WHEN-NON-TOP-LEVEL could not define LOCALLY to treat
    
+  its body as top-level forms, because only a special form can do
    
+  that and LOCALLY is a macro.
    
+
    
+Proposal (LOCALLY-TOP-LEVEL:SPECIAL-FORM):
    
+          
    
+  Change LOCALLY from a macro to a special form, and change the
    
+  definition of compiler processing (in EVAL-WHEN-NON-TOP-LEVEL)
    
+  so that when a LOCALLY form appears at top level the forms in
    
+  its body are processed at top level.
    
+
    
+Examples:
    
+
    
+  (locally (declare (optimize (safety 3) (space 3) (speed 0)))
    
+    (defmacro frob (&environment e x y &optional (z (foo x y)))
    
+      (mumble x y z e)))
    
+
    
+  Without this proposal, this would have to be written
    
+
    
+  (defmacro frob (&environment e x y &optional (z (locally
    
+                                                    (declare
    
+                                                      (optimize
    
+                                                        (safety 3)
    
+                                                        (space 3)
    
+                                                        (speed 0)))
    
+                                                    (foo x y))))
    
+    (locally (declare (optimize (safety 3) (space 3) (speed 0)))
    
+      (mumble x y z e)))
    
+
    
+Rationale:
    
+
    
+  Wrapping LOCALLY around a form should not change its semantics except
    
+  as specified by the declarations, hence the body of a top-level
    
+  LOCALLY should be top-level.
    
+
    
+  A macro cannot have a top-level body unless it expands into a special
    
+  form that has a top-level body; otherwise the macro invocation and
    
+  the macro expansion would not have identical semantics as top-level
    
+  forms.  There is no available special form for LOCALLY to macroexpand
    
+  into (CLtL doesn't say, but presumably the intent was to expand into
    
+  a LET with an empty binding list).
    
+
    
+Current practice:
    
+
    
+  The Zetalisp equivalent of LOCALLY worked to surround top-level forms,
    
+  because it was a macro that expanded into COMPILER-LET (stashing the
    
+  declarations in a special variable the compiler would look at).  This
    
+  is of course the wrong way to do declarations, but it shows that the
    
+  idea was that you could wrap declarations around a bunch of top-level
    
+  forms.
    
+
    
+  Symbolics Genera 7.4.0 does not implement the proposal (but it does
    
+  not implement DECLARATION-SCOPE:NO-HOISTING either).  I did
    
+  not survey any other implementations.
    
+
    
+Cost to Implementors:
    
+
    
+  A half dozen lines of code in the compiler and a smaller amount
    
+  in the interpreter and any program-analyzing programs.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  See the horrible example above.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  More consistent language.
    
+
    
+Esthetics:
    
+
    
+  Improved.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220.htm new file mode 100644 index 00000000..5530b74f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOOP-AND-DISCREPANCY:NO-REITERATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-AND-DISCREPANCY:NO-REITERATION Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOOP-AND-DISCREPANCY:NO-REITERATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220_w.htm new file mode 100644 index 00000000..f47555b5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss220_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue LOOP-AND-DISCREPANCY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-AND-DISCREPANCY Writeup

    + +
    Issue:		LOOP-AND-DISCREPANCY
    
+
    
+References:	Loop Facility document X3J13/89-004
    
+
    
+Related issues: 
    
+
    
+Category:	CHANGE CLARIFICATION
    
+
    
+Edit history:	Version 1, 15-Mar-88 by Steele
    
+
    
+Problem description:
    
+
    
+The treatment of the AND conjunction in FOR/AS and WITH clauses is not
    
+consistent.  Examples of the use of WITH are also not consistent in this
    
+respect.
    
+
    
+Page 2-5 implies by example that when AND is used to join two
    
+FOR/AS clauses, the word FOR or AS must occur after the word AND.
    
+
    
+Page 2-31 has formal syntax specifying that when AND is used to join two
    
+WITH clauses, the word WITH must *not* occur after the word AND.  Examples
    
+on that page are consistent with this specification.
    
+
    
+Page 2-41 has an example in which WITH is repeated after AND.
    
+
    
+
    
+Proposal (LOOP-AND-DISCREPANCY:NO-REITERATION):
    
+
    
+Let stand the formal syntax for WITH.
    
+
    
+Change the description of FOR/AS clauses to specify that when
    
+two or more such clauses are joined with AND, clauses after the
    
+first do not have FOR or AS before them.
    
+
    
+The complete formal syntax for FOR/AS may be described as follows:
    
+
    
+for-as ::= {FOR | AS} for-as-subclause {AND for-as-subclause}*
    
+
    
+for-as-subclause ::= for-as-arithmetic | for-as-in-list
    
+		   | for-as-on-list | for-as-equals-then
    
+		   | for-as-across | for-as-hash | for-as-package
    
+
    
+for-as-arithmetic ::= var [type-spec] ...
    
+
    
+and so on.
    
+
    
+Examples:
    
+
    
+> (loop for x from 1 to 10		;Corrected from X3J13/89-004, page 2-5
    
+        and y = nil then x
    
+        collect (list x y))
    
+((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
    
+
    
+> (loop with (a b) float = '(1.0 2.0)	;Corrected from X3J13/89-004, page 2-41
    
+        and (c d) integer = '(3 4)
    
+        and (e f)
    
+        return (list a b c d e f))
    
+(1.0 2.0 3 4 nil nil)
    
+
    
+
    
+Rationale:
    
+
    
+The treatment of AND should be internally consistent.  There is no reason
    
+to repeat the FOR/AS keyword.  Not repeating the keyword emphasizes that
    
+the subclauses are functionally linked under the heading of WITH or FOR.
    
+(Compare to the third use of AND in LOOP, to link clauses controlled
    
+by WHEN/IF/UNLESS.  One does not repeat the WHEN; rather, the clauses
    
+grouped by AND are controlled by a single WHEN.)
    
+
    
+
    
+Current practice:
    
+
    
+Symbolics LOOP allows FOR to be included or omitted after AND,
    
+with identical meanings.  WITH may not be repeated after AND.
    
+
    
+
    
+Cost to Implementors: Small?
    
+
    
+Cost to Users: Possible incompatibility with existing implementors' extensions.
    
+
    
+Cost of non-adoption:  Utter confusion.
    
+
    
+Performance impact:  None.
    
+
    
+Benefits:  Consistent treatment of AND within LOOP.
    
+
    
+Esthetics:
    
+
    
+Absolutely none.  We're talking about LOOP here.
    
+
    
+Discussion:
    
+
    
+Steele supports this proposal.  It is a reversal of his previous
    
+suggestion on the topic, thanks to feedback from Moon.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221.htm new file mode 100644 index 00000000..a6e60f27 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOOP-FOR-AS-ON-TYPO:FIX-TYPO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-FOR-AS-ON-TYPO:FIX-TYPO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOOP-FOR-AS-ON-TYPO:FIX-TYPO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221_w.htm new file mode 100644 index 00000000..060d8630 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss221_w.htm @@ -0,0 +1,128 @@ + + + +CLHS: Issue LOOP-FOR-AS-ON-TYPO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-FOR-AS-ON-TYPO Writeup

    + +
    Status:         Proposal FIX-TYPO passed 12/91
    
+Issue:  	       LOOP-FOR-AS-ON-TYPO
    
+Reference:      X3J13/89-004 page 2-10, CLtL/II page 721, and dict-flow.tex
    
+Category:       Clarify/fix-typo
    
+Edit History:   Version 1  20-Aug-91 by JonL 
    
+
    
+
    
+Problem Description:
    
+
    
+ From the draft proposal .tex file, under the subsection {\bf for-as-on-list},
    
+ the words:
    
+
    
+     In the {\it for-as-on-list\/} subclause,
    
+     the {\tt for\/} 
    
+     or {\tt as\/} construct iterates over the contents of a 
    
+     @type[list]. It checks for the
    
+     end of the @type[list] as if by using
    
+       @funref[endp].  
    
+
    
+ were erroneously copied verbatim from the subsection {\bf for-as-in-list},
    
+ rather than the intended wording from the Iteration Subcommittee.
    
+
    
+ At one level, this prescription doesn't make sense;  by saying that 
    
+ it is iterating over the "contents", rather than down the successive cdrs,
    
+ of the list, there is confusion about the values assumed by the variable
    
+ [which is subsequently said to take on the "tails" of the list.]
    
+
    
+ In the spring of 1988, the Iteration Subcommittee suggested a change from
    
+ the then existing practice of terminating both LOOP-FOR-AS-IN and 
    
+ LOOP-FOR-AS-ON by simply a NULL test.  [Indeed, in the MacLisp days before
    
+ CommonLisp, ENDP didn't exist; and the common use of NULL rather than ATOM
    
+ was based on a performance hack for the PDP10 Architecture.]  So ENDP was 
    
+ specified for LOOP-FOR-AS-IN because that style views the list as a sequence 
    
+ having "contents" or elements; but ATOM was specified for LOOP-FOR-AS-ON
    
+ since the only concern was the succession of list tails.  The LOOP-FOR-AS-ON
    
+ case is intended to be more general -- and hence have a less restrictive
    
+ termination test -- so that user-defined iteration over non-standard
    
+ lists can be supported.  But the current draft specification completely
    
+ and accidentally defeats this design.
    
+
    
+
    
+Proposal (LOOP-FOR-AS-ON-TYPO:FIX-TYPO)
    
+
    
+ Restore the original wording as intended by the Iteration Subcommittee
    
+ as follows:
    
+
    
+    In the {\it for-as-on-list\/} subclause,
    
+    the {\tt for\/} 
    
+    or {\tt as\/} construct iterates over a
    
+    @type[list]. It checks for the
    
+    end of the @type[list] as if by using
    
+      @funref[atom].  
    
+
    
+
    
+Editorial Impact:
    
+
    
+ Very small.
    
+
    
+Rationale:
    
+
    
+ The evidence that this is a typo is in the Lucid Product Documentation
    
+ of about the same time that 89-004 was abstracted from it; this product
    
+ documentation has the "correct" wording, and the person responsible for
    
+ doing the abstracting simply copied over the wrong, albeit very
    
+ similarly worded paragraph.  The two paragraphs are close together
    
+ in that text.
    
+
    
+ Without this fix, there will surely be gratuitous variations as to
    
+ how the termination testing is done for the LOOP-FOR-AS-ON case.
    
+
    
+
    
+Current Practice:
    
+
    
+ Some existing implementations still adhere to the MacLisp inspired
    
+ version that used to be distributed from MIT, which simply used NULL
    
+ for both the FOR-AS-IN and the FOR-AS-ON cases; some adhere to a
    
+ later Common Lisp version that uses ENDP, at least for the FOR-AS-IN 
    
+ case.  Harlequin has apparently implemented the broken semantics of 
    
+ "X3J13/89-004 page 2-10".
    
+
    
+
    
+Discussion:
    
+
    
+ This typo has gone undetected for over two years, between January 1989 
    
+ until about April 1991, when a fresh implementation of LOOP taken purely 
    
+ "from the spec" produced anomalous results on LOOP-FOR-AS-ON termination 
    
+ tests.  Lawrence G. Mayka <lgm@iexist.att.com> noticed the variation when 
    
+ comparing Harlequin's LOOP implementation with some of the others.
    
+
    
+
    
+ Jonl 11-Apr-91:  I know this (the use of ATOM for FOR-AS-ON termination) 
    
+    was discussed and agreed upon; and I hope that the forum of discussion 
    
+    was within X3J13, either the iteration subcommittee or the whole 
    
+    committee.  I even recall changing Lucid's implementation after this 
    
+    decision. [And an edit-history record of that change, along with the
    
+    rationale cited above, still exists in the Lucid source code for
    
+    Loop, dated 9-May-88.]
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222.htm new file mode 100644 index 00000000..4f75332a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222_w.htm new file mode 100644 index 00000000..4778dbeb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss222_w.htm @@ -0,0 +1,240 @@ + + + +CLHS: Issue LOOP-INITFORM-ENVIRONMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-INITFORM-ENVIRONMENT Writeup

    + +
    Issue:        LOOP-INITFORM-ENVIRONMENT
    
+Forum:	      Editorial
    
+References:   LOOP (pages 8-85, 
    
+	      Draft 8.81 
    
+Category:     CLARIFICATION
    
+Edit history: 05-Mar-91, Version 1 by Pitman
    
+	      15-Mar-91, Version 2 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  The Symbolics implementation of X3J13's LOOP spec surprised some users 
    
+  by being incompatible with the old Symbolics Genera LOOP on the 
    
+  following test case:
    
+
    
+    (let ((list '(1 2 3)))
    
+      (loop for list = list then (cdr list)
    
+	 until (null list)
    
+	 do (princ (car list))))
    
+
    
+  The Symbolics Genera implementation prints nothing, but old Symbolics 
    
+  Genera LOOP prints 123. In double-checking the implementation against the
    
+  working draft specification to determine if the implementation was in
    
+  error, more than one Symbolics implementors did not feel this behavior 
    
+  was clearly enough spelled out and worried that implementations might not
    
+  agree.
    
+
    
+  Further investigation showed that Lucid Common Lisp had the same behavior.
    
+  
    
+  The following are the only references which appeared relevant:
    
+
    
+   From page 8-85:
    
+ 
    
+    The LOOP macro translates the given <form> into code and returns the
    
+    expanded <form>.   The expanded <form> is one or more <lambda
    
+    expressions> for the local <binding> of loop variables and a block
    
+    and a tagbody that express a looping control structure. The variables
    
+    established in LOOP are bound as if by LET or LAMBDA.
    
+    Implementations can interleave the setting of initial values with
    
+    the bindings.  However, the assignment of the initial values is
    
+    always calculated in othe order specified by the user.  A variable is 
    
+    thus sometimes bound to a meaningless value of the correct type
    
+    and then later in the prologue is set to the true initial value by
    
+    using SETQ.
    
+   
    
+   Later, on page 8-86:
    
+   
    
+    The FOR and AS constructs provide iteration control clauses that
    
+    establish a variable to be initialized.  FOR and AS clauses can be
    
+    combined with the LOOP keyword AND to get parallel initialization and
    
+    stepping.  Otherwise, the initialization and stepping are sequential.
    
+   
    
+  The need for this information is so fundamental that it should be very
    
+  plainly stated.  These extremely vague phrases don't really say much
    
+  about the environment, and since they don't say what goes into the LET
    
+  or the LAMBDA, or even how many LET or LAMBDA forms are involved, they
    
+  don't really say much at all.
    
+
    
+  Further, the vague statement on p8-85 about how LET+SETQ might be used to
    
+  implement binding leaves an unusually large amount of latitude to 
    
+  implementations.
    
+
    
+Proposal (LOOP-INITFORM-ENVIRONMENT:INITFORM-BEFORE-BINDING)
    
+
    
+  Clarify that the initforms in a FOR-AS clause
    
+  (each being variously called the <form1>, the <hash-table>, or the
    
+  <package> in the `bnf' on pages 8-82..8-83)
    
+  are all evaluated (in left to right order) prior to establishing
    
+  the binding for any of the the <vars> in the same clause.
    
+
    
+  Clarify that the initforms in a WITH clause (each being
    
+  called a <form1> in the `bnf' on pages 8-82..8-83)
    
+  are all evaluated (in left to right order) prior to establishing
    
+  the binding for any <varN> in the same clause.
    
+
    
+Test Case:
    
+
    
+    (let ((list '(1 2 3)))
    
+      (loop for list = list then (cdr list)
    
+	 until (null list)
    
+	 collect (car list)))
    
+    => (1 2 3)
    
+
    
+Rationale:
    
+
    
+  This is what most users who make an analogy to LET or DO will expect.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera's FUTURE-COMMON-LISP:LOOP (which purports to conform
    
+  to the draft specification) returns NIL.
    
+
    
+  Symbolics Genera's LISP:LOOP (which purports to conform to CLtL)
    
+  returns (1 2 3) for the test case.
    
+
    
+Cost to Implementors:
    
+
    
+  Hopefully small.
    
+
    
+Cost to Users:
    
+
    
+  Hopefully most users will consider this the status quo.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The specification might be ambiguous on an important point.
    
+
    
+Benefits:
    
+
    
+  Cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  Clarity improves aesthetics.
    
+
    
+Discussion:
    
+
    
+  Pitman and Moon support this proposal.
    
+  JonL opposes this proposal.
    
+
    
+  A long-winded discussion ensued, excerpts of which follow.
    
+
    
+  Moon writes:
    
+   ``It's intentional that implementations should have latitude in 
    
+     the expansion of LOOP, but not to the extent that the meaning of
    
+     the program changes!  The problem is that the only thing this
    
+     version of the LOOP specification says about the scope of LOOP
    
+     variables is that they are lexical unless proclaimed special and
    
+     their scope is the loop.  This isn't specific enough.
    
+
    
+   ``Also in CLtL2 p.722 there is an example expansion which could be
    
+     taken as an argument against the INITFORM-BEFORE-BINDING proposal.
    
+     However I don't think that example was intended to talk about
    
+     variable scoping.  This example does not appear in the draft ANSI
    
+     CL spec, which is good in my opinion.''
    
+
    
+  JonL writes:
    
+   ``I don't see this as a clarification but as a change;  in particular,
    
+     it isn't consistent with the section of CLtL/II that you cite:
    
+     [... page 8-85 ...]
    
+     since it forbids the aforementioned "interleaving".  As Moon said, 
    
+     it is "intentional that implementations should have latitude in
    
+     the expansion of LOOP, ...".  So the question is just how
    
+     importantant is the case of loop variables "shadowing" local
    
+     lexical variables?  That is, I agree that the current spec is
    
+     ambiguous on just when the binding of 'list' occurs in
    
+	  (let ((list '(1 2 3)))
    
+	    (loop for list = list then (cdr list)
    
+	    . . . ))
    
+     but I'm more inclined to say SO WHAT?  Is the world going into
    
+     terminal meltdown just because this case isn't completely portable?
    
+     is LOOP completely unusable *** just because of this lexical
    
+     shadowing ambiguity?    
    
+
    
+   ``The point I'm trying to make is not that this case isn't a problem, 
    
+     but that it isn't a *big* problem; and even if it remained
    
+     ambiguous (as was the intention for the draft proposal -- reasons
    
+     cited below), it is nowhere near the magnitude of problem that we 
    
+     face in other areas.
    
+
    
+   ``... Lucid's LOOP (unchanged for many years now) was modeled after
    
+     GSB's MIT code, and it has the same behaviour as Genera.  Even if
    
+     the "original designers" intended something here, I think Glenn's
    
+     execution of it might have led people to think otherwise. ...''
    
+
    
+  Moon writes:
    
+
    
+   ``I don't see this particular issue as some technical issue of angels
    
+     dancing on the heads of pins that is only of real interest to
    
+     specialists.  It's not uncommon for user programs to use the same
    
+     variable name more than once.  I hear that users very often find it
    
+     frustrating to try to use LOOP because there are implementations around
    
+     that do unintuitive things and documentation around that they can't
    
+     decode.  Those problems are so unnecessary.
    
+
    
+   ``... I just now loaded up the MIT LOOP, unchanged for nearly five       
    
+     years (unless someone's been changing it without updating the edit
    
+     history at the front) from REAGAN.AI.MIT.EDU, and tried the test case
    
+     from the cleanup issue.  It prints 123, so it conforms to the cleanup.
    
+     This makes me suspect that the MIT LOOP has always had the intuitive
    
+     behavior, but programmers at Lucid and also at Symbolics broke it in the
    
+     process of improving it.  I don't think it's true that Glenn implemented
    
+     it differently from what the cleanup says.
    
+     
    
+   ``So then I tried the CMU implementation referenced in Scott Fahlman's
    
+     recent message.  It, too, conforms to the cleanup, although it seems to
    
+     have its share of bugs (several compiler warnings and errors while
    
+     loading that I fixed up and proceeded past).
    
+
    
+   ``... We can always specify a language feature as doing something
    
+     unpredictable, but is that really necessary?''
    
+
    
+  JonL writes:
    
+
    
+   ``I claim this ambiguity is purposeful -- the "interleaving" of binding
    
+     and initialization clauses, which in some implementations has 
    
+     performance consequences  -- and that the case that brought this 
    
+     ambiguity to public attention is not of great consequence to the
    
+     language.  
    
+
    
+   ``Of course, I agree that we must specify *exactly* the behaviour
    
+     of LET when local variables are being shadowed, such as in:
    
+       (let ((x (list x))) . . .)
    
+     because renaming of bound variables is an important concept (not just
    
+     "pinheads dancing on angels").  But LOOP bindings are not documented to
    
+     be *exactly* like LET, and they aren't the primariy means to achieve
    
+     lexical "shadows"; thus I strongly disagree that seeking out and "fixing"
    
+     documented ambiguities in the binding-order for LOOP "shadows" is of high
    
+     priority.''
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223.htm new file mode 100644 index 00000000..7617e500 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223.htm @@ -0,0 +1,48 @@ + + + +CLHS: Issue LOOP-MISCELLANEOUS-REPAIRS:FIX Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-MISCELLANEOUS-REPAIRS:FIX Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LOOP-MISCELLANEOUS-REPAIRS:FIX:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223_w.htm new file mode 100644 index 00000000..2ba68a22 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss223_w.htm @@ -0,0 +1,262 @@ + + + +CLHS: Issue LOOP-MISCELLANEOUS-REPAIRS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-MISCELLANEOUS-REPAIRS Writeup

    + +
    Issue:        LOOP-MISCELLANEOUS-REPAIRS
    
+Document:     (no document number yet)
    
+Forum:        Cleanup
    
+References:   refer to the referenced Public Review comments
    
+Category:     CLARIFICATION
    
+Edit history: 14-Feb-93, Version 1 by Moon
    
+              18-Feb-93, Version 2 by Moon (fix spelling error)
    
+Status:       Proposal FIX passed 7-1-0, March 1993
    
+
    
+Problem Description:
    
+
    
+  There were public review comments relating to chapter 6 of draft 12.24.
    
+  This cleanup does not address the complete set, just the easier ones
    
+  since it makes sense to lump them all into one omnibus issue.  I have
    
+  not included editorial comments in this cleanup.
    
+
    
+  A brief summary of the comments:
    
+
    
+  1. Flanagan #4, Loosemore #3, Moon #47 -- extension mechanism is
    
+  promised but not included
    
+
    
+  2. Moon #28 -- text says "Function Designator", examples work differently
    
+
    
+  3. Moon #30 -- LOOP "IT" Description doesn't make sense
    
+
    
+  4. Moon #32 -- LOOP DOING doesn't allow implicit progn, but DO does
    
+
    
+  5. Moon #35 -- LOOP-FINISH Inconsistency
    
+
    
+  6. Moon #37 -- Does LOOP RETURN clause return multiple values?
    
+
    
+  7. Moon #41 -- LOOP Conditional Execution Nonsense
    
+
    
+  8. Moon #43 -- LOOP Bad Type-Spec Example
    
+
    
+  9. Moon #21 -- LOOP Block Name Scope is not specified
    
+
    
+  10. Moon #34 -- LOOP Thereis Default is not specified
    
+
    
+  11. Moon #24 -- LOOP-AND-DISCREPANCY:NO-REITERATION not incorporated
    
+
    
+  12. Moon #25 -- LOOP by/to phrase Order should be unrestricted
    
+
    
+  13. Moon #36 -- LOOP Return/Named Interaction
    
+
    
+  14. Moon #26 -- Eliminate the ability to put a LOOP keyword after FINALLY
    
+
    
+Proposal (LOOP-MISCELLANEOUS-REPAIRS:FIX)
    
+
    
+  Make all of the following numbered changes:
    
+    
    
+  1. Remove reference to extension mechanism on page 6-32.
    
+
    
+  2. Change definition of step-fun on page 6-5 to:
    
+
    
+    \param{step-fun}---a \term{form} that evaluates to a \term{function}
    
+    of one \term{argument}.
    
+
    
+  3. Replace the entire paragraph beginning "clause, clause1" on page 6-5
    
+     with:
    
+
    
+      \param{Clause}, \param{clause1}, \param{clause2} -- 
    
+      \i{unconditional} | \i{accumulation} | \i{conditional}, as defined
    
+      in the section "Syntax of an Extended LOOP Form".
    
+
    
+     Replace the last paragraph on page 6-18 with: 
    
+
    
+      The \term{loop keyword} \loopref{it} can be used to refer to the result
    
+      of the test expression in a clause.
    
+      Use the \term{loop keyword} \loopref{it} in place of the form in a
    
+      {\tt return} clause or an \i{accumulation} clause that is
    
+      inside a conditional execution clause.
    
+      If multiple clauses are connected with \loopref{and}, the \loopref{it}
    
+      construct must be in the first clause in the block.
    
+
    
+    In a Notes section, note that:
    
+
    
+      Use caution when using a variable named {\tt it} (in any package) in
    
+      connection with LOOP, since \loopref{it} is a \term{loop keyword} that
    
+      can be used in place of a form in certain contexts.
    
+
    
+  4. Add DOING to the next-to-last paragraph on page 6-5.
    
+
    
+  5. Remove the following paragraph from p.6-7:
    
+
    
+      Note also that the \macref{loop-finish} macro terminates iteration and
    
+      returns any accumulated result. Any \loopref{finally} clauses that are
    
+      supplied are evaluated.
    
+
    
+  6. Change the next-to-last paragraph on p.6-7, the third paragraph on
    
+     p.6-19, and the last paragraph on p.6-19 all to state clearly that all
    
+     values returned by the form in a RETURN clause are returned by the LOOP.
    
+
    
+  7. Replace the first three paragraphs under the heading Conditional
    
+     Execution on p.6-18 with:
    
+
    
+       The \loopref{if}, \loopref{when}, and \loopref{unless} constructs
    
+       establish conditional control in a \macref{loop}. If the test
    
+       passes, the succeeding loop clause is executed. If the test does
    
+       not pass, the succeeding clause is skipped, and program control
    
+       moves to the clause that follows the \term{loop keyword}
    
+       \loopref{else}. If the test does not pass and no \loopref{else}
    
+       clause is supplied, control is transferred to the clause or
    
+       construct following the entire conditional clause.
    
+
    
+       If conditional clauses are nested, each \loopref{else} is paired
    
+       with the closest preceding conditional clause that has no
    
+       associated \loopref{else} or \loopref{end}. 
    
+
    
+       In the \loopref{if} and \loopref{when} clauses, which are
    
+       synonymous, the test passes if the value of \param{form} is
    
+       \term{true}. 
    
+
    
+       The \loopref{unless} \param{form} construct is equivalent to
    
+       \f{when (not \param{form})}; the test passes if the value of
    
+       \param{form} is \term{false}.
    
+
    
+  8. Add OF-TYPE to the example on page 6-24.
    
+
    
+  9. State explicitly in the next to last paragraph on page 6-19 that the
    
+     scope of the block name includes the entire LOOP. Move the "BLOCK NIL"
    
+     in the example on page 6-17 so it is outside the LET*.
    
+
    
+  10. Add the following sentence to the description of "thereis" in the
    
+      section "Termination Condition Clauses" on p.6-7:
    
+
    
+       Otherwise, it provides a default return value of \nil.
    
+
    
+  11. Make the syntax and the English agree with the X3J13 vote on
    
+      LOOP-AND-DISCREPANCY:NO-REITERATION (Version 1) by correcting
    
+      the syntax for each for-as subclause on page 6-3 by removing
    
+      the "\curly{\loopref{for} | \loopref{as}}"; by adding the
    
+      same text to the front of the definition of for-as-clause on
    
+      page 6-3; and by adding a sentence to the second paragraph on
    
+      page 6-9 clarifying that the word FOR or AS is not repeated
    
+      after the word AND.
    
+
    
+  12. The detailed description of for-as-arithmetic (p6-9) should say
    
+      in English that the "by" subclause can appear either before or after
    
+      the "to" subclause, and similarly for the other two pairs of
    
+      subclauses. The syntax of for-as-arithmetic on p.6-3 should be
    
+      changed as follows, to allow the three subclauses to appear in any
    
+      order, to require at least one subclause to be used, and to indicate
    
+      the restrictions on combinations of prepositions described in
    
+      English on pp.6-9..6-10:
    
+
    
+      for-as-arithmetic ::= { FOR | AS } var [ type-spec ]
    
+       { { FROM | UPFROM } form1 [ { TO | UPTO | BELOW } form2 ] [ BY form3 ] 
    
+|
    
+         { FROM | UPFROM } form1 BY form3 [ { TO | UPTO | BELOW } form2 ] |
    
+         { TO | UPTO | BELOW } form2 [ { FROM | UPFROM } form1 ] [ BY form3 ] 
    
+|
    
+         { TO | UPTO | BELOW } form2 BY form3 [ { FROM | UPFROM } form1 ] |
    
+         BY form3 [ { FROM | UPFROM } form1 ] [ { TO | UPTO | BELOW } form2 ] 
    
+|
    
+         BY form3 { TO | UPTO | BELOW } form2 [ { FROM | UPFROM } form1 ] |
    
+         FROM form1 { DOWNTO | ABOVE } form2 [ BY form3 ] |
    
+         FROM form1 BY form3 { DOWNTO | ABOVE } form2 |
    
+         { DOWNTO | ABOVE } form2 FROM form1 [ BY form3 ] |
    
+         { DOWNTO | ABOVE } form2 BY form3 FROM form1 |
    
+         BY form3 { DOWNTO | ABOVE } form2 FROM form1 |
    
+         BY form3 FROM form1 { DOWNTO | ABOVE } form2 |
    
+         DOWNFROM form1 [ { TO | DOWNTO | ABOVE } form2 ] [ BY form3 ] |
    
+         DOWNFROM form1 BY form3 [ { TO | DOWNTO | ABOVE } form2 ] |
    
+         { TO | DOWNTO | ABOVE } form2 DOWNFROM form1 [ BY form3 ] |
    
+         { TO | DOWNTO | ABOVE } form2 BY form3 DOWNFROM form1 |
    
+         BY form3 [ { TO | DOWNTO | ABOVE } form2 ] DOWNFROM form1 |
    
+         BY form3 DOWNFROM form1 [ { TO | DOWNTO | ABOVE } form2 ]
    
+       }
    
+
    
+      Yes, it looks complicated, that's the limitation of BNF to express
    
+      things where not all permutations are allowed.
    
+
    
+  13. Replace the second sentence of the next-to-last paragraph on page 6-7
    
+      with:
    
+
    
+        It is equivalent to the clause
    
+        \f{do (return-from \i{block-name} \i{value})},
    
+        where \i{block-name} is the name specified in a \loopref{named}
    
+        clause, or \nil if there is no \loopref{named} clause.
    
+
    
+      Replace the second sentence of the third paragraph on page 6-19
    
+      with the text quoted just above.
    
+
    
+  14. Remove the syntax "finally unconditional-clause" on page 6-4.  Remove
    
+      the sentence "An unconditional clause can also follow 
    
+      \theloopkeyword{finally}." from the sixth paragraph on page 6-8.
    
+
    
+Test Cases:
    
+
    
+  Refer to the referenced Public Review comments
    
+
    
+Rationale:
    
+
    
+  These are non-controversial corrections to mistakes or ambiguities in
    
+  the draft specification.
    
+
    
+Current Practice:
    
+
    
+  All of these changes bring the specification into conformity with current
    
+  practice as observed in Apple MCL 2.0p1, with the exception of the ability
    
+  to put the BY subclause before both of the other subclauses in #12.  I
    
+  believe it would be a one-line change to the implementation to allow that.
    
+
    
+Cost to Implementors:
    
+
    
+  Little or none for most implementations that already conform.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Ambiguous, inconsistent, or incomprehensible language specification.
    
+
    
+Benefits:
    
+
    
+  Better language specification.
    
+
    
+Aesthetics:
    
+
    
+  Better language specification.
    
+
    
+Performance Impact:
    
+
    
+  None.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224.htm new file mode 100644 index 00000000..771dfe2d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue LOOP-NAMED-BLOCK-NIL:OVERRIDE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-NAMED-BLOCK-NIL:OVERRIDE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LOOP-NAMED-BLOCK-NIL:OVERRIDE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224_w.htm new file mode 100644 index 00000000..02442a2e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss224_w.htm @@ -0,0 +1,145 @@ + + + +CLHS: Issue LOOP-NAMED-BLOCK-NIL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-NAMED-BLOCK-NIL Writeup

    + +
    Status:       Proposal OVERRIDE (version 2) accepted 12/91
    
+Issue:        LOOP-NAMED-BLOCK-NIL
    
+Reference:    Draft 9.126
    
+Category:     CLARIFICATION
    
+Edit History: Version 1, 22-Dec-91, Kim Barrett
    
+              Version 2, 26-Jan-92, Kim Barrett (clarification, per KMP)
    
+
    
+Problem Description:
    
+
    
+ (Note: All section numbers are from Draft 9.126)
    
+
    
+  Regarding:
    
+
    
+  section 8.1.2.2, page 8-2, last paragraph in section
    
+
    
+   Expansion of the \macref{loop} macro produces an implicit block named \nil\
    
+   unless \loop{named} is supplied.  Thus, \macref{return} and
    
+   \specref{return-from} can be used to return values from \macref{loop} or to
    
+   exit \macref{loop}.
    
+
    
+  section 8.1.2.6, End-Test Control, p8-15, first itemization
    
+
    
+   \itemitem{\bull} The \loop{until} construct executes any \loop{finally}
    
+   clause. Since \loop{thereis} uses the macro \macref{return} to terminate
    
+   iteration, any \loop{finally} clause that is supplied is not evaluated.  
    
+
    
+  section 8.1.2.6, End-Test Control, p8-15, second itemization
    
+
    
+   \itemitem{\bull} The \loop{until} construct executes any \loop{finally}
    
+   clause. Since \loop{never} uses the macro \macref{return} to terminate
    
+   iteration, any \loop{finally} clause that is supplied is not evaluated.  
    
+
    
+ In his review, Barmar noted "hmm..." in regard to this issue of not having a
    
+ NIL block get generated even when NAMED is used.  He and KMP discussed it and
    
+ decided (based on examining the Lucid and Symbolics implementations) that the
    
+ intent was clear and they would let it go.
    
+
    
+ In processing other review comments of Barmar's, KMP noticed that these two
    
+ items refer specifically to RETURN (rather than RETURN-FROM) being generated.
    
+ This suggests one of the following two things:
    
+
    
+ (a) RETURN was not intended in the second two cases, and RETURN-FROM was
    
+     meant.
    
+
    
+ (b) RETURN was intended intended in the second two, and this exposes the fact
    
+     that the part about having no NIL block in the first case was wrong.
    
+
    
+ How shall we proceed in fixing this?
    
+
    
+Proposal (LOOP-NAMED-BLOCK-NIL:OVERRIDE):
    
+
    
+ Clarify that if a NAMED clause appears in a LOOP form then no implicit NIL
    
+ block is established by the LOOP form.  That is, confirm interpretation (a)
    
+ and reject interpretation (b) from the Problem Description.
    
+
    
+Editorial Impact:
    
+
    
+ The two bulleted items mentioned in the problem description need to be changed
    
+ to refer to the special operator RETURN-FROM rather than the macro RETURN.
    
+
    
+Rationale:
    
+
    
+ Gives the user greater control over the expansion of a LOOP form, permitting
    
+ its use in places where it might not be desirable if a NIL block were always
    
+ established.
    
+
    
+Examples:
    
+
    
+ (block nil
    
+   (loop named foo
    
+     do (return 'success))
    
+   'failure)
    
+ -> SUCCESS
    
+
    
+Current Practice:
    
+
    
+ Apple MCL 2.0b3 and Lucid 4.0 do not introduce an implicit NIL block if a 
    
+ NAMED clause is present in the LOOP form.
    
+
    
+ Symbolics LOOP always introduces a NIL block, in addition to any block
    
+ established for a NAMED clause.
    
+
    
+Discussion:
    
+
    
+ Barrett:
    
+  I think (a) (RETURN-FROM was meant, rather than RETURN) is preferable.  The
    
+  main use I've found for explicitly named blocks is to avoid accidentally
    
+  shadowing the intended receiver of a return-from when writing a wrapper
    
+  macro.  If LOOP might always introduce a NIL block then you can't safely
    
+  write such macros in terms of LOOP forms.
    
+
    
+ GSB:
    
+  I'm not sure how much help this is; I'll try to explain the history behind
    
+  the current Symbolics implementation.
    
+
    
+  My personal preference is for NAMED to use the named block instead of
    
+  (rather than in addition to) a block named NIL.  Now, at the time I
    
+  implemented the ANSI loop (and extensions) at Symbolics, I was under the
    
+  impression that NAMED was not part of ANSI.  Maybe it had been dyked from
    
+  the standard, maybe it was in the process of being removed (there was this
    
+  minimalist pressure at the time).  JonL, you remember anything about this?
    
+  I was basically working from the first draft that differed greatly from the
    
+  prior Lucid documentation.
    
+
    
+  Now, a semantic divergence occurred several years ago between the "NIL" and
    
+  other "MIT" loop sources, and the Symbolics Zetalisp loop source, because
    
+  someone (Me) got confused about the semantics of Zetalisp's named PROG.  In
    
+  particular, I translated (prog name varlist ...) into roughly
    
+  (block name (let varlist (tagbody ...))).  This is not a correct
    
+  translation: Zetalisp named prog establishes that block name IN ADDITION TO
    
+  a block named NIL.  Therefore when I did NAMED (as an extension to ANSI), I
    
+  made it compatible with the existing (lisp machine) one, against my own
    
+  preferences, because it was only an extension and the incompatibility is
    
+  fairly subtle.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225.htm new file mode 100644 index 00000000..5c5489cb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225_w.htm new file mode 100644 index 00000000..845c7bc5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss225_w.htm @@ -0,0 +1,116 @@ + + + +CLHS: Issue LOOP-PRESENT-SYMBOLS-TYPO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-PRESENT-SYMBOLS-TYPO Writeup

    + +
    Status:         Accepted 3/31/92
    
+Issue:          LOOP-PRESENT-SYMBOLS-TYPO
    
+References:     X3J13/92-101, page 6-13, 6-25; X3J13/89-004, page 2-14
    
+Related issues: 
    
+Category:       CHANGE
    
+Edit history:   24-Feb-92 Version 1 by JonL
    
+
    
+Problem description:
    
+
    
+  Iteration over "present" symbols by the loop schema PRESENT-SYMBOLS
    
+  excludes all present but external symbols.
    
+
    
+
    
+Proposal (LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS):
    
+
    
+  Remove the words:
    
+    "... but not \term{external symbols} of that \term{package}."
    
+  from the first sentence of the draft description on page 6-13.
    
+
    
+  Add the line:
    
+        "\OUT THIS"
    
+  to the output of the draft example at the top of page 6-25.
    
+
    
+Rationale:
    
+
    
+  This is clearly a typo since the phrase "present symbols" has had
    
+  a precise technical meaning since the early 1980's;  furthermore,
    
+  it has a significant adverse impact on the intended semantics.
    
+
    
+Current practice:
    
+
    
+  All of Lucid's implementation use the meaning of "present" rather 
    
+  than "internal"; apparently one of Symbolics' implementations uses
    
+  "internal".
    
+
    
+Cost to Implementors:
    
+
    
+  Surely, very small (probably more to marketing types.)
    
+
    
+Cost to Users:
    
+
    
+  Again, small if any at all.  
    
+
    
+Cost of non-adoption:
    
+
    
+  Occurance of many obscure bugs (looping over present symbols misses
    
+  some of those present); egg on face for such a misnomered feature.
    
+
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Editorial impact:
    
+
    
+  KMP says, in an email msg of Thu, 13 Feb 1992 22:57-0500:
    
+
    
+    I estimate the editorial impact to be about 2 minutes of work ..."
    
+
    
+Benefits:
    
+
    
+  See Cost of non-adoption.
    
+
    
+Esthetics:
    
+
    
+  Say what you mean.
    
+
    
+Discussion:
    
+
    
+  Possibly some user might think that this odd wording is simply a means 
    
+  of resurrecting the non-proposed schema for INTERNAL-SYMBOLS; but this 
    
+  schema was considered and rejected on its own (non) merits.
    
+
    
+  Some "bibliographic archeology" of the actual LOOP proposal --
    
+  X3J13/89-004 -- shows that the wording in the original sources were 
    
+  very confusing, leading to the conculsion that the offensive phrase 
    
+  was inserted (by someone not knowing what they were doing?) into
    
+  X3J13/89-004 to lessen the "confusion"
    
+
    
+  Moon has questioned how the committee could have voted upon
    
+  X3J13/89-004 without reading it more carefully and noticing this 
    
+  glitch.  JonL compares the scrutiny of X3J13/89-004 with that given 
    
+  to X3J13/88-002R (i.e., probably no on re-read either before voting.)
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226.htm new file mode 100644 index 00000000..2d8615a0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue LOOP-SYNTAX-OVERHAUL:REPAIR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue LOOP-SYNTAX-OVERHAUL:REPAIR Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue LOOP-SYNTAX-OVERHAUL:REPAIR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226_w.htm new file mode 100644 index 00000000..a8dbbca4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss226_w.htm @@ -0,0 +1,330 @@ + + + +CLHS: Issue LOOP-SYNTAX-OVERHAUL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue LOOP-SYNTAX-OVERHAUL Writeup

    + +
    Issue:        LOOP-SYNTAX-OVERHAUL
    
+Forum:	      X3J13 Letter Ballot
    
+References:   LOOP syntax (X3J13/92-102 pp6-2..6-5)
    
+Category:     CLARIFICATION
    
+Edit history: 16-Jun-93, Version 1 by Pitman
    
+Status:	      Proposal REPAIR passed (7+3)-1 on letter ballot 93-304.
    
+
    
+
    
+Problem Description:
    
+
    
+  The LOOP syntax in the first dpANS all screwed up.
    
+
    
+Proposal (LOOP-SYNTAX-OVERHAUL:REPAIR):
    
+
    
+  Affirm that the following changes to the source relating to LOOP syntax
    
+  are in fact editorial and that nothing has been broken. Note that several
    
+  recently passed cleanups are implicitly included in this writeup.
    
+
    
+  A typeset version of this code should have been attached for the reader's
    
+  convenience, but the TeX source code is what is being voted upon and kept 
    
+  as a record.  This requires a new TeX macro library, not included.
    
+
    
+  Note that two new notations are used to make this work:
    
+       [[ { x }1 | { y }* ]]
    
+  means that x can occur anywhere, but exactly once (it is not optional).
    
+  And 
    
+       [[ x | y | ... ]]+
    
+  means that at least one of the enclosed options must be selected.
    
+  (Appropriate text has been added to Section 1.4 to explain this new
    
+  notational extension.)
    
+
    
+ \input setup		      % -*- Mode: TeX -*-
    
+ 
    
+ \beginchapter{X}{LOOP}{ChapX}{LOOP}
    
+ 
    
+ %%% ========== LOOP
    
+ \begincom{loop}\ftype{Macro}
    
+ 
    
+ \label Syntax::
    
+ 
    
+ The ``simple'' \macref{loop} \term{form}:
    
+ 
    
+ \DefmacWithValues loop {\starparam{compound-form}} {\starparam{result}}
    
+ 
    
+ The ``extended'' \macref{loop} \term{form}:
    
+ 
    
+ \DefmacWithValues loop {\brac{\down{name-clause}}
    
+			 \stardown{variable-clause}
    
+			 \stardown{main-clause}} {\starparam{result}}
    
+ 
    
+ \auxbnf{name-clause}{\loopref{named} \param{name}}
    
+ \auxbnf{variable-clause}{\down{with-clause} | \down{initial-final} | \down{for-as-clause}}
    
+ \auxbnf{with-clause}%
    
+ {\loopref{with} \param{var1} \brac{\param{type-spec}} \brac{$=$ \param{form1}}
    
+  \star{\curly{\loopref{and} \param{var2} \brac{\param{type-spec}} 
    
+			     \brac{$=$ \param{form2}}}}}
    
+ \auxbnf{main-clause}%
    
+ {\down{unconditional} |
    
+  \down{accumulation}  |
    
+  \down{conditional}   |
    
+  \down{end-test}      |
    
+  \down{initial-final}}
    
+ \auxbnf{initial-final}%
    
+ {\loopref{initially} \plusparam{form} |  \loopref{finally} \plusparam{form}}
    
+ \auxbnf{unconditional}%
    
+ {\curly{\loopref{do} | \loopref{doing}} \plusparam{form} |
    
+  \loopref{return} \param{form}}
    
+ \auxbnf{accumulation}{\down{list-accumulation} | \down{numeric-accumulation}}
    
+ \auxbnf{list-accumulation}%
    
+ {\curly{\loopref{collect} | \loopref{collecting} |
    
+	 \loopref{append}  | \loopref{appending}  |
    
+	 \loopref{nconc} | \loopref{nconcing}} \param{form} \CR
    
+  \brac{\loopref{into} \param{var}}}
    
+ \auxbnf{numeric-accumulation}%
    
+ {\curly{\loopref{count}    | \loopref{counting}   |
    
+	 \loopref{sum}      | \loopref{summing}    | \CR
    
+  \xcurly\loopref{maximize} | \loopref{maximizing} |
    
+	 \loopref{minimize} | \loopref{minimizing}} \param{form} \CR
    
+  \brac{\loopref{into} \param{var}} \brac{\param{type-spec}}}
    
+ \auxbnf{conditional}%
    
+ {\curly{\loopref{if} | \loopref{when} | \loopref{unless}} \param{form}
    
+	  \param{selectable-clause} \star{\curly{\loopref{and} \param{selectable-clause}}} \CR
    
+  \brac{\loopref{else}
    
+	  \param{selectable-clause} \star{\curly{\loopref{and} \param{selectable-clause}}}} \CR
    
+  \brac{\loopref{end}}}
    
+ %% I flushed the clause/clause1/clause2 distinction in the next thing, since it's not used
    
+ %% anywhere for reference, and it's not appropriate to the bnf style.
    
+ %% However, I'm concerned about the loss of IT here due to LOOP-MISCELLANEOUS-REPAIRS.
    
+ %%  -kmp 4-May-93
    
+ \auxbnf{selectable-clause}{\down{unconditional} | \down{accumulation} | \down{conditional}}
    
+ \auxbnf{end-test}%
    
+ {\loopref{while}   \param{form}  | 
    
+  \loopref{until}   \param{form}  |
    
+  \loopref{repeat}  \param{form}  |
    
+  \loopref{always}  \param{form}  |
    
+  \loopref{never}   \param{form}  |
    
+  \loopref{thereis} \param{form}}
    
+ \auxbnf{for-as-clause}%
    
+ {\curly{\loopref{for} | \loopref{as}} \down{for-as-subclause}
    
+  \star{\curly{\loopref{and} \down{for-as-subclause}}}}
    
+ \auxbnf{for-as-subclause}%
    
+ {\down{for-as-arithmetic}  |
    
+  \down{for-as-in-list}     |
    
+  \down{for-as-on-list}     |
    
+  \down{for-as-equals-then} |\CR
    
+  \down{for-as-across}      |
    
+  \down{for-as-hash}        |
    
+  \down{for-as-package}}
    
+ \auxbnf{for-as-arithmetic}{\param{var} \brac{\param{type-spec}}
    
+			    \down{for-as-arithmetic-subclause}}
    
+ \auxbnf{for-as-arithmetic-subclause}%
    
+ {\down{arithmetic-up} | \down{arithmetic-downto} | \down{arithmetic-downfrom}}
    
+ \auxbnf{arithmetic-up}%
    
+ {\begininterleave\curly{\loopref{from} | \loopref{upfrom}} \param{form1}               | 
    
+  \extrainterleave\curly{\loopref{to} | \loopref{upto} | \loopref{below}} \param{form2} | 
    
+  \extrainterleave\loopref{by} \param{form3}\endinterleave\prevplus}
    
+ \auxbnf{arithmetic-downto}%
    
+ {\begininterleave\one{\curly{\loopref{from} \param{form1}}} 				| 
    
+  \extrainterleave\one{\curly{\curly{\loopref{downto} | \loopref{above}} \param{form2}}} | 
    
+  \extrainterleave\loopref{by} \param{form3}\endinterleave}
    
+ \auxbnf{arithmetic-downfrom}%
    
+ {\begininterleave\one{\curly{\loopref{downfrom} \param{form1}}} 			 | 
    
+  \extrainterleave\curly{\loopref{to} | \loopref{downto} | \loopref{above}} \param{form2} | 
    
+  \extrainterleave\loopref{by} \param{form3}\endinterleave}
    
+ \auxbnf{for-as-in-list}%
    
+ {\param{var} \brac{\param{type-spec}}
    
+  \loopref{in} \param{form1} \brac{\loopref{by} \param{step-fun}}}
    
+ \auxbnf{for-as-on-list}%
    
+ {\param{var} \brac{\param{type-spec}}
    
+  \loopref{on} \param{form1} \brac{\loopref{by} \param{step-fun}}}
    
+ \auxbnf{for-as-equals-then}%
    
+ {\param{var} \brac{\param{type-spec}}
    
+  $=$ \param{form1} \brac{\loopref{then} \param{form2}}}
    
+ \auxbnf{for-as-across}%
    
+ {\param{var} \brac{\param{type-spec}}
    
+  \loopref{across} \param{vector}}
    
+ \auxbnf{for-as-hash}%
    
+ {\param{var} \brac{\param{type-spec}}
    
+  \loopref{being} \curly{\loopref{each} | \loopref{the}} \CR
    
+  \lcurly\curly{\loopref{hash-key} | \loopref{hash-keys}}
    
+	 \curly{\loopref{in} | \loopref{of}} \param{hash-table} \CR
    
+  \xcurly\brac{\loopref{using} \paren{\loopref{hash-value} \param{other-var}}} | \CR
    
+  \xcurly\curly{\loopref{hash-value} | \loopref{hash-values}}
    
+	 \curly{\loopref{in} | \loopref{of}} \param{hash-table} \CR
    
+  \xcurly\brac{\loopref{using} \paren{\loopref{hash-key} \param{other-var}}}\rcurly}
    
+ \auxbnf{for-as-package}%
    
+ {\param{var} \brac{\param{type-spec}}
    
+  \loopref{being} \curly{\loopref{each} | \loopref{the}} 	        \CR
    
+  \lcurly\loopref{symbol} | \loopref{symbols}		               |\CR
    
+  \xcurly\loopref{present-symbol} | \loopref{present-symbols}           |\CR
    
+  \xcurly\loopref{external-symbol} | \loopref{external-symbols}\rcurly   \CR
    
+  \brac{\curly{\loopref{in} | \loopref{of}} \param{package}}}
    
+ \auxbnf{type-spec}{\down{simple-type-spec} | \down{destructured-type-spec}}
    
+ \auxbnf{simple-type-spec}%
    
+ {\declref{fixnum} | \declref{float} | \declref{t} | \declref{nil}}
    
+ \auxbnf{destructured-type-spec}{\loopref{of-type} \param{d-type-spec}}
    
+ \auxbnf{d-type-spec}%
    
+ {\param{type-specifier} | \f{(\param{d-type-spec} . \param{d-type-spec})}}
    
+ 
    
+ \label Arguments and Values::
    
+ 
    
+ \param{compound-form}---a \term{compound form}.
    
+ 
    
+ \param{name}---a \term{symbol}.
    
+ 
    
+ \param{var}, \param{var1}, \param{var2}, \param{other-var}---a \term{symbol}
    
+   (a \term{variable} \term{name}).
    
+ 
    
+ \param{form}, \param{form1}, \param{form2}, \param{form3}---a \term{form}.
    
+ 
    
+ \issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
    
+ \param{step-fun}---a \term{form} that evaluates to a \term{function} of one \term{argument}.
    
+ \endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
    
+ 
    
+ \param{vector}---a \term{form} that evaluates to a \term{vector}.
    
+ 
    
+ \param{hash-table}---a \term{form} that evaluates to a \term{hash table}.
    
+ 
    
+ \param{package}---a \term{form} that evaluates to a \term{package designator}.
    
+ 
    
+ \param{type-specifier}---a \term{type specifier}.
    
+ 
    
+ \param{result}---an \term{object}.
    
+ 
    
+ \label Description::
    
+ 
    
+ %!!! This should be elaborated slightly here.
    
+ For details, \seesection\LoopFacility.
    
+ 
    
+ \label Examples::
    
+ 
    
+ \code
    
+ ;; An example of the simple form of LOOP.
    
+  (defun sqrt-advisor ()
    
+    (loop (format t "~&Number: ")
    
+	  (let ((n (parse-integer (read-line) :junk-allowed t)))
    
+	    (when (not n) (return))
    
+	    (format t "~&The square root of ~D is ~D.~%" n (sqrt n)))))
    
+ \EV SQRT-ADVISOR
    
+  (sqrt-advisor)
    
+ \OUT Number: \IN{5\CRLF}
    
+ \OUT The square root of 5 is 2.236068.
    
+ \OUT Number: \IN{4\CRLF}
    
+ \OUT The square root of 4 is 2.
    
+ \OUT Number: \IN{done\CRLF}
    
+ \EV NIL
    
+ 
    
+ ;; An example of the extended form of LOOP.
    
+  (defun square-advisor ()
    
+    (loop as n = (progn (format t "~&Number: ")
    
+			(parse-integer (read-line) :junk-allowed t))
    
+	  while n
    
+	  do (format t "~&The square of ~D is ~D.~%" n (* n n))))
    
+ \EV SQUARE-ADVISOR
    
+  (square-advisor)
    
+ \OUT Number: \IN{4\CRLF}
    
+ \OUT The square of 4 is 16.
    
+ \OUT Number: \IN{23\CRLF}
    
+ \OUT The square of 23 is 529.
    
+ \OUT Number: \IN{done\CRLF}
    
+ \EV NIL
    
+ 
    
+ ;; Another example of the extended form of LOOP.
    
+  (loop for n from 1 to 10
    
+	when (oddp n)
    
+	  collect n)
    
+ \EV (1 3 5 7 9)
    
+ \endcode
    
+  
    
+ \label Affected By:\None.
    
+ 
    
+ \label Exceptional Situations:\None.
    
+ 
    
+ %!!! Barmar: The description mentions several places where PROGRAM-ERROR is signaled.
    
+ 
    
+ \label See Also::
    
+ 
    
+ \macref{do}, \macref{dolist}, \macref{dotimes}, 
    
+ \macref{return}, \specref{go}, \specref{throw}
    
+  
    
+ \label Notes::
    
+ 
    
+ The simple form of \macref{loop} is related to the extended form
    
+ in the following way:
    
+ 
    
+ \code
    
+  (loop \starparam{compound-form}) \EQ (loop do \starparam{compound-form})
    
+ \endcode
    
+ 
    
+ \endcom%{loop}
    
+ 
    
+ \endchapter
    
+ 
    
+ \bye
    
+
    
+Test Case:
    
+
    
+  N/A
    
+
    
+Rationale:
    
+
    
+  What was there was utterly broken, so how could we do worse?
    
+
    
+Current Practice:
    
+
    
+  N/A
    
+
    
+Cost to Implementors:
    
+
    
+  Hopefully very small.  This is not really supposed to be a change, 
    
+  just a clarification for readability.
    
+
    
+Cost to Users:
    
+
    
+  Hopefully very small.  This is not really supposed to be a change, 
    
+  just a clarification for readability.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  A hopelessly messed up description of LOOP's syntax.
    
+
    
+Benefits:
    
+
    
+  Using LOOP just from the documentation will be possible.
    
+
    
+Editorial Impact:
    
+
    
+  This affirms work already done.
    
+
    
+Aesthetics:
    
+
    
+  What was there was so broken that this is unquestionably an improvement.
    
+
    
+Discussion:
    
+
    
+  Pitman thinks this is just a rubber stamp, and that only editorial changes
    
+  have been made here.  He just wanted the committee to have a chance to 
    
+  double-check this work specially.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227.htm new file mode 100644 index 00000000..09cd76a4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACRO-AS-FUNCTION:DISALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACRO-AS-FUNCTION:DISALLOW Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACRO-AS-FUNCTION:DISALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227_w.htm new file mode 100644 index 00000000..179d1ec6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss227_w.htm @@ -0,0 +1,100 @@ + + + +CLHS: Issue MACRO-AS-FUNCTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACRO-AS-FUNCTION Writeup

    + +
    Issue:        MACRO-AS-FUNCTION
    
+References:   Chapter 1, Section 1.5, Working draft of standard
    
+Category:     Clarification
    
+Edit history: 8-JAN-89, Version 1 by Masinter
    
+	      6-FEB-89, Version 2 by Chapman
    
+ 
    
+
    
+
    
+Problem: 
    
+
    
+May operators defined in the standard as "macros" and
    
+"special forms" be implemented as functions instead? PROG1 is the main
    
+example, but there might be others.
    
+ 
    
+Proposal: MACRO-AS-FUNCTION:YES
    
+ 
    
+Operators that are defined in CL as "macros" may be defined as functions
    
+instead if the semantics can be preserved. 
    
+
    
+This is rare, perhaps only
    
+restricted to
    
+ 
    
+(defun prog1 (value &rest ignore) value)
    
+(defun prog2 (value1 value2 &rest ignore) value2)
    
+
    
+
    
+Operators defined as "special forms" may also be defined as functions.
    
+
    
+
    
+Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
    
+
    
+The standard will remain silent on the issue of whether or not is
    
+is legal for an implementation to implemention "macros" and 
    
+"special forms" as functions.
    
+
    
+Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW
    
+
    
+A conforming implementation does not define "macros" and "special forms"
    
+as functions.
    
+
    
+Rationale: 
    
+
    
+There isn't a good reason to disallow "macro" and "special form" function
    
+definitions. It doesn't interfere with portability.
    
+ 
    
+ 
    
+Current Practice:
    
+
    
+One implementation defines PROG1 as a function.
    
+
    
+Adoption Cost:
    
+
    
+None for :YES; some for :DISALLOW.
    
+
    
+Benefits:
    
+
    
+Increased implementation flexibility.
    
+
    
+Conversion Cost:
    
+
    
+None.
    
+
    
+Aesthetics:
    
+
    
+None.
    
+
    
+Discussion:
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228.htm new file mode 100644 index 00000000..c8488236 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue MACRO-DECLARATIONS:MAKE-EXPLICIT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACRO-DECLARATIONS:MAKE-EXPLICIT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue MACRO-DECLARATIONS:MAKE-EXPLICIT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228_w.htm new file mode 100644 index 00000000..0d78f50e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss228_w.htm @@ -0,0 +1,184 @@ + + + +CLHS: Issue MACRO-DECLARATIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACRO-DECLARATIONS Writeup

    + +
    Forum:		Cleanup
    
+Issue:		MACRO-DECLARATIONS
    
+References:	Issue SYMBOL-MACROLET-DECLARE
    
+		Issue DECLARATION-SCOPE
    
+		Issue DECLARE-TYPE-FREE
    
+		Issue DEFINE-COMPILER-MACRO
    
+		Issue DYNAMIC-EXTENT
    
+                Issue DYNAMIC-EXTENT-FUNCTION
    
+	        Declarations (CLtL chapter 9)
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 26 Oct 1989, Sandra Loosemore
    
+		V2, 02 Nov 1989, Sandra Loosemore (suggestions from Moon)
    
+
    
+
    
+Problem Description:
    
+
    
+Issue SYMBOL-MACROLET-DECLARE defines a meaning for TYPE declarations
    
+when the lexically visible "binding" of the symbol names a
    
+symbol-macro.  It also requires SYMBOL-MACRO to signal an error if a
    
+SPECIAL declaration is provided in the body for a symbol which it
    
+defines as a symbol-macro.
    
+
    
+What is the meaning of a SPECIAL declaration appearing in some other
    
+context (such as in a LOCALLY construct), for a symbol for which the
    
+lexically apparent "binding" is a symbol-macro definition?  How about
    
+any other declaration which normally applies to a variable or function
    
+binding (IGNORE, DYNAMIC-EXTENT, FTYPE, INLINE, NOTINLINE) when the
    
+lexically apparent "binding" is a macro or symbol-macro definition? 
    
+
    
+
    
+Proposal (MACRO-DECLARATIONS:MAKE-EXPLICIT):
    
+
    
+Clarify that the standard declarations that apply to function or variable
    
+bindings have the following effects when the binding is a macro or
    
+symbol-macro:
    
+
    
+  SPECIAL
    
+    SYMBOL-MACROLET signals an error if it includes a SPECIAL declaration 
    
+    for any symbol that it binds as a symbol-macro.  [Issue
    
+    SYMBOL-MACROLET-DECLARE]  Presumably, this error is of type 
    
+    PROGRAM-ERROR and is signalled at compile-time rather than run-time.
    
+
    
+    A SPECIAL declaration for a symbol whose lexically visible binding
    
+    is a symbol-macro causes that binding to be shadowed, in the same way
    
+    that a SPECIAL declaration shadows lexical variable bindings.
    
+
    
+  TYPE
    
+    A TYPE declaration for a symbol that names a symbol-macro is equivalent
    
+    to wrapping a THE expression around the expansion of that symbol-macro.
    
+    [Issue SYMBOL-MACROLET-DECLARE]  This is meaningful regardless of whether 
    
+    the declaration appears in the form that bound the symbol-macro or as a 
    
+    free declaration within the scope of the symbol-macro binding.  Multiple
    
+    TYPE declarations applying to a single symbol-macro binding are handled
    
+    in the same way as multiple TYPE declarations that apply to a
    
+    single variable binding.
    
+
    
+  FTYPE
    
+    This declaration is not valid when the lexically apparent binding
    
+    is a macro binding rather than a function binding.  (This is because
    
+    FTYPE declares the functional binding of the name to be of a particular
    
+    subtype of FUNCTION, and macros are not FUNCTIONs.)
    
+
    
+  IGNORE
    
+    IGNORE declarations for symbol-macro bindings should be treated in 
    
+    exactly the same way as IGNORE declarations for variable bindings.
    
+    In other words, such a declaration specifies that the bindings of
    
+    of the specified symbol-macros are never used.
    
+
    
+  DYNAMIC-EXTENT
    
+    This declaration is not valid when the lexically apparent binding
    
+    is a symbol-macro or macro binding rather than a variable or
    
+    function binding.
    
+
    
+  NOTINLINE
    
+    In the presence of compiler-macro definitions, this declaration
    
+    affects references to macros in exactly the same way that it affects
    
+    references to functions.  When the lexically apparent binding is a 
    
+    macro that also has a compiler-macro definition, this declaration can 
    
+    be used to indicate to a language processor that the macro (and not the 
    
+    compiler-macro) definition should be used.  [Issue DEFINE-COMPILER-MACRO.]
    
+    A NOTINLINE declaration for a macro has otherwise has no effect on
    
+    its expansion.  Implementations are not free to ignore this declaration.
    
+
    
+  INLINE
    
+    To parallel treatment of NOTINLINE, in the presence of compiler-macro
    
+    definitions, this declaration affects references to macros in exactly
    
+    the same way that it affects references to functions.  When the lexically 
    
+    apparent binding is a macro that also has a compiler-macro definition, 
    
+    this declaration can be used to indicate to a language processor that 
    
+    the compiler-macro (and not the macro) definition should be used.  An
    
+    INLINE declaration for a macro otherwise has no effect on its expansion.
    
+    Implementations are free to ignore this declaration.
    
+
    
+In those situations where the use of the declaration is not valid, the
    
+consequences of evaluating or compiling the program are undefined.
    
+
    
+
    
+Rationale:
    
+
    
+This proposal is primarily an explicit restatement of things which have
    
+already been stated in other places, with some obvious interpolations
    
+added.
    
+
    
+Leaving the consequences undefined permits implementations to signal
    
+an error, to assign some implementation-specific interpretation to
    
+the declaration, or simply to ignore the declaration.
    
+
    
+
    
+Current Practice:
    
+
    
+Utah Common Lisp implements this proposal.  It currently ignores all
    
+declarations that apply to function or variable bindings when the
    
+lexically visible binding is a macro or symbol-macro.  The
    
+declarations are added to the environment in the normal way but are
    
+never examined by the interpreter or compiler.  The exception is that
    
+a SPECIAL declaration will shadow a symbol-macro definition in the
    
+same way that it will shadow a lexical variable binding. 
    
+
    
+Neither HPCL-I nor Lucid CL complain about FTYPE or INLINE/NOTINLINE
    
+declarations when the lexically visible function "binding" is a macro.
    
+They are apparently being ignored.  KCL ignores all declarations
    
+that apply to function bindings (and doesn't yet support symbol-macros).
    
+
    
+
    
+Cost to implementors:
    
+
    
+Presumably small.  
    
+
    
+
    
+Cost to users:
    
+
    
+It seems unlikely that this proposal would be an incompatible change
    
+that causes many user programs to break, particularly given the
    
+relative newness of symbol-macros and compiler-macros.
    
+
    
+
    
+Benefits:
    
+
    
+More complete specification of the language and less chance for confusion
    
+to arise later on.
    
+
    
+
    
+Aesthetics:
    
+
    
+Some people might be bothered by the asymmetry between the handling of
    
+TYPE and FTYPE declarations.  Strictly speaking, the special handling for
    
+TYPE declarations is unnecessary since one could explicitly include the
    
+THE form in the expansion of the symbol-macro.  Other people probably
    
+think that the notational convenience outweighs the asymmetry.
    
+
    
+Discussion:
    
+-------
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229.htm new file mode 100644 index 00000000..d3eb1d73 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue MACRO-ENVIRONMENT-EXTENT:DYNAMIC Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACRO-ENVIRONMENT-EXTENT:DYNAMIC Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue MACRO-ENVIRONMENT-EXTENT:DYNAMIC:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229_w.htm new file mode 100644 index 00000000..7d654933 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss229_w.htm @@ -0,0 +1,260 @@ + + + +CLHS: Issue MACRO-ENVIRONMENT-EXTENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACRO-ENVIRONMENT-EXTENT Writeup

    + +
    Forum:		Compiler
    
+Issue:		MACRO-ENVIRONMENT-EXTENT
    
+References:	CLtL p. 145-146
    
+		Issue COMPILER-LET-CONFUSION
    
+		Issue MACRO-CACHING
    
+		Issue EVAL-WHEN-NON-TOP-LEVEL
    
+		Issue SYNTACTIC-ENVIRONMENT-ACCESS
    
+		CLOS Chapter 3 (89-003)
    
+Category:	CLARIFICATION,CHANGE
    
+Edit History:   V1, 10 Jan 1989, Sandra Loosemore
    
+		V2, 09 Mar 1989, Sandra Loosemore
    
+		V3, 13 Mar 1989, Sandra Loosemore (last-minute discussion)
    
+Status:		**DRAFT**
    
+
    
+
    
+Problem Description:
    
+
    
+What is the extent of environment objects received as the &ENVIRONMENT
    
+argument of a macro function?
    
+
    
+CLtL says that &ENVIRONMENT is "useful primarily in the rare cases
    
+where a macro definition must explicitly expand any macros in a
    
+subform of the macro call before computing its own expansion".  While
    
+this suggests that macro environment objects are typically used within
    
+the dynamic scope of the macro function, the use of the word
    
+"primarily" (rather than "only" or "exclusively" or some similarly
    
+strong language) suggests that there may be other legitimate uses for
    
+environment objects.  But, because CLtL is silent about what those
    
+uses might be, many users and implementors are under the impression
    
+that environment objects have only dynamic extent.
    
+
    
+There are some situations where using environment objects as if they
    
+had indefinite extent provides a very useful viewpoint from which to
    
+solve a problem.  Consider the following example:
    
+
    
+  (defmacro typed-var (var) var)
    
+
    
+  (defmacro local-type-declare (declarations &body forms &environment env)
    
+      `(macrolet ((typed-var (&whole w var)
    
+		    (let ((type  (assoc var ',declarations)))
    
+		      (if type 
    
+		          `(the ,(cadr type) ,var)
    
+                          (macroexpand w ',env)))))
    
+	 ,@forms))
    
+
    
+  (defun f (x y)
    
+    (local-type-declare ((x fixnum) (y float))
    
+      (+ (typed-var x) (typed-var y))))
    
+
    
+Here, local macro TYPED-VAR is defined to look first in the innermost
    
+lexical environment for information about the variable, and if there
    
+isn't any then it recurses on the next outermost lexical environment.
    
+The global definition of TYPED-VAR provides a terminal case to stop
    
+the recursion.
    
+
    
+There are other situations where the extent of macro environment
    
+objects comes into play.  For example, if we allow caching of macro
    
+expansions (issue MACRO-CACHING), environments must have indefinite
    
+extent.  It is unclear whether CLOS would be affected by allowing
    
+macro environments to have only dynamic extent.  (The descriptions of
    
+the CLOS defining macros in document 89-003 seem to imply that the
    
+value of the &ENVIRONMENT argument appears in the expansion of the
    
+macro, but there now seems to be sentiment that the model of how the
    
+defining macros work that is presented there is broken.)
    
+
    
+
    
+Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE:
    
+
    
+State that macro environment objects received with the &ENVIRONMENT
    
+argument of a macro function or as the argument to a *MACROEXPAND-HOOK*
    
+function have indefinite extent.
    
+
    
+Note that implementations are not permitted to destructively modify
    
+lexical information in environment objects once they have been passed
    
+to a macro function.  It is, however, permissible to add or remove
    
+global definitions that are accessible through the environment.
    
+
    
+  Rationale:
    
+
    
+  This legitimizes the use of idioms which depend on macro environments
    
+  having indefinite extent.
    
+
    
+  Since data objects in Lisp otherwise have indefinite extent, it is
    
+  more consistent to give environment objects indefinite extent as
    
+  well.
    
+
    
+
    
+Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC:
    
+
    
+State that macro environment objects received with the &ENVIRONMENT
    
+argument of a macro function or with a *MACROEXPAND-HOOK* function
    
+have only dynamic extent; the consequences are undefined if they are
    
+referred to outside the dynamic extent of that macro function or hook
    
+function.
    
+
    
+  Rationale:
    
+
    
+  This allows implementations to use somewhat more efficient techniques
    
+  for representing environment objects.  For example, the storage could
    
+  be stack-allocated, or environments could be bashed destructively
    
+  instead of always being freshly heap-allocated.
    
+
    
+
    
+Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC-WITH-COPIER:
    
+
    
+State that macro environment objects received with the &ENVIRONMENT
    
+argument of a macro function or with a *MACROEXPAND-HOOK* function
    
+have only dynamic extent; the consequences are undefined if they are
    
+referred to outside the dynamic extent of that macro function or hook
    
+function.
    
+
    
+Add a new function:
    
+
    
+COPY-ENVIRONMENT environment				[function]
    
+
    
+This function returns an environment object that is semantically
    
+equivalent to "environment" (which must be an object of the type
    
+received with an &ENVIRONMENT argument to a macro or as an argument to
    
+a *MACROEXPAND-HOOK* function), but which may safely be referred to
    
+outside the dynamic extent of the macro function.  This function is
    
+permitted to return an object that is EQ to its argument if that 
    
+object may be safely used.
    
+
    
+  Rationale:
    
+
    
+  This allows implementations to use somewhat more efficient techniques
    
+  for representing environment objects.  For example, the storage could
    
+  be stack-allocated, or environments could be bashed destructively
    
+  instead of always being freshly heap-allocated.
    
+
    
+  It also allows programmers to use idioms that rely on environment
    
+  objects having indefinite extent.
    
+
    
+
    
+Current Practice:
    
+
    
+Macro environments appear to have indefinite extent in Lucid Common
    
+Lisp, Kyoto Common Lisp, CMU Common Lisp (at least in the
    
+interpreter), Utah Common Lisp, and A-Lisp.  A-Lisp internally uses
    
+the kind of idiom shown in the example above to implement FLET,
    
+LABELS, and FUNCTION as macros.
    
+
    
+Macro environments are stack-allocated in Symbolics Genera, and hence
    
+have dynamic extent.
    
+
    
+Macro environments also have dynamic extent on the TI Explorer,
    
+because the compiler uses special variables are used to keep track of
    
+lexical definitions.
    
+
    
+
    
+Cost to implementors:
    
+
    
+For proposal INDEFINITE, some implementations would need to change.  A
    
+simple implementation of macro environments that would fit the
    
+requirements of this proposal is to represent them as lists, pushing
    
+information for inner contours onto the front of the list as the
    
+contour is entered and popping the list when the contour is exited.
    
+
    
+For proposal DYNAMIC, there is no associated implementation cost.
    
+
    
+For proposal DYNAMIC-WITH-COPIER, the implementation cost is unknown
    
+but probably fairly small in most implementations.
    
+
    
+
    
+Cost to users:
    
+
    
+For proposal INDEFINITE, there is no associated cost to users.
    
+
    
+For proposal DYNAMIC, users would not be able to portably use a
    
+simple and elegant approach to solving certain kinds of problems.
    
+
    
+For proposal DYNAMIC-WITH-COPIER, users would have to remember to make
    
+a copy of an environment object in some situations.
    
+
    
+
    
+Benefits:
    
+
    
+It is made clear whether treating environment objects as if they had
    
+indefinite extent is portable usage.
    
+
    
+
    
+Discussion:
    
+
    
+Proposal SYNTACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE
    
+includes adding a function called AUGMENT-ENVIRONMENT which could also
    
+be used to create a copy of an environment.  However, it returns an
    
+object with the same extent as its argument, and therefore can not
    
+replace the function COPY-ENVIRONMENT under proposal
    
+DYNAMIC-WITH-COPIER.
    
+
    
+We have also considered a couple of other alternatives on this 
    
+issue.
    
+
    
+One alternative would be to give "remote" environments created by
    
+COMPILE-FILE the extent of that call to COMPILE-FILE, while "local"
    
+environments (the null lexical environment and environments created by
    
+COMPILE and EVAL) would have indefinite extent.
    
+
    
+Another alternative would be to say that environments created by
    
+COMPILE-FILE, COMPILE, or EVAL have a dynamic extent that includes the
    
+time when any other macro calls appearing lexically within the
    
+expansion returned by the macro function are expanded.  This is
    
+similar to the extent of the special bindings made by COMPILER-LET.
    
+
    
+Both of these proposals could be combined with adding a copier
    
+function to deal with those implementations where environments are
    
+stack-allocated.  They would both solve the extent problem for the
    
+example given in the problem description section, but not the general
    
+problem of macro caching.  In conjunction with the proposals for issue
    
+SYNTACTIC-ENVIRONMENT-ACCESS, they would both require some
    
+modifications to implementations that currently give macro
    
+environments dynamic extent.
    
+
    
+Loosemore supports proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE.
    
+
    
+Moon says:
    
+  My opinion is that anything in CLOS that seems to depend on indefinite
    
+  extent for macro environments is broken and needs to be fixed.  It's not
    
+  broken because of the environment extent, but for other reasons.
    
+  Thus I believe in dynamic extent for environments.
    
+
    
+Neil Goldman says:
    
+  In my code walker I have a pretty ugly way of dealing with MACROLET
    
+  that would have been trivial if I could have counted on the
    
+  ENVIRONMENT having indefinite extent.  There may be some cleaner way
    
+  than what I did, but I just looked at PCL's code walker, and it also
    
+  is much more complex than would be necessary if environments had
    
+  indefinite extent.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230.htm new file mode 100644 index 00000000..bd15ce42 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACRO-FUNCTION-ENVIRONMENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACRO-FUNCTION-ENVIRONMENT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACRO-FUNCTION-ENVIRONMENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_m.htm new file mode 100644 index 00000000..50a4ba87 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue MACRO-FUNCTION-ENVIRONMENT Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue MACRO-FUNCTION-ENVIRONMENT Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_w.htm new file mode 100644 index 00000000..a7e6da2c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss230_w.htm @@ -0,0 +1,133 @@ + + + +CLHS: Issue MACRO-FUNCTION-ENVIRONMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACRO-FUNCTION-ENVIRONMENT Writeup

    + +
    Issue:         MACRO-FUNCTION-ENVIRONMENT
    
+
    
+References:    MACRO-FUNCTION, p. 144
    
+               MACROLET, pp. 113-4
    
+               &ENVIRONMENT, pp. 145-6
    
+               MACROEXPAND and MACROEXPAND-1, pp. 151-2
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, Pavel, March 21, 1988
    
+		   Version 2, Masinter,  8-Jun-88, (as per cleanup discussion)
    
+
    
+Problem description:
    
+
    
+The &ENVIRONMENT argument to a macro-expansion function may only be used as
    
+the
    
+second argument to the functions MACROEXPAND and MACROEXPAND-1.  It is
    
+sometimes
    
+more convenient, however, to be able to work directly with the more
    
+primitive
    
+function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are
    
+presumably
    
+based.  However, since MACRO-FUNCTION does not take an environment
    
+argument, it
    
+cannot be used in situations in which that environment must be taken into
    
+account.
    
+
    
+Proposal (MACRO-FUNCTION-ENVIRONMENT:YES):
    
+
    
+Add an optional second argument to MACRO-FUNCTION, that argument being an
    
+environment that was passed as the &ENVIRONMENT argument to some macro
    
+expansion
    
+function.  If the argument is not given, or the argument is NIL, the null
    
+environment is used.  MACRO-FUNCTION will now consider macro definitions
    
+from
    
+that environment in preference to ones in the global environment.  It is an
    
+error
    
+to supply the environment argument in a use of MACRO-FUNCTION as a SETF
    
+location
    
+specifier.
    
+
    
+Examples:
    
+
    
+(macrolet ((foo (&environment env)
    
+              (if (macro-function 'bar env)
    
+                 ''yes
    
+                 ''no)))
    
+   (list (foo)
    
+         (macrolet ((bar () :beep))
    
+            (foo))))
    
+
    
+=> (no yes)
    
+
    
+(setf (macro-function 'bar env) ...) is an error.
    
+
    
+Rationale:
    
+
    
+Intuitively, the more primitive operation in macro expansion is
    
+MACRO-FUNCTION,
    
+not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
    
+supplied to the latter functions and not to the former one.  By changing
    
+this
    
+state of affairs, the model of macro expansion becomes somewhat simpler.
    
+Also,
    
+more flexible use of the facility is enabled.
    
+
    
+Current practice:
    
+
    
+Xerox Common Lisp already implements this proposal.  Symbolics Common Lisp,
    
+and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0
    
+does.
    
+
    
+Cost to Implementors:
    
+
    
+This is presumably a simple change to make, a small matter of moving the
    
+environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.
    
+
    
+Cost to Users:
    
+
    
+The change is upward-compatible and so poses no cost to users.
    
+
    
+Cost of non-adoption:
    
+
    
+One more (small) semantic wart on the language.
    
+
    
+Benefits:
    
+
    
+The function that users think of as being more primitive really is.
    
+
    
+Aesthetics:
    
+
    
+This slightly cleans up the language.
    
+
    
+Discussion:
    
+
    
+This issue was discussed starting in January 1987, but got tangled in
    
+a web of other related proposals. In its current form, the only objections
    
+have been that some other proposal or committee might otherwise change
    
+macro handling, or that this proposal doesn't fix enough of the problems.
    
+
    
+  
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss231.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss231.htm new file mode 100644 index 00000000..46b5e852 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss231.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACRO-FUNCTION-ENVIRONMENT:YES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACRO-FUNCTION-ENVIRONMENT:YES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACRO-FUNCTION-ENVIRONMENT:YES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232.htm new file mode 100644 index 00000000..a58d0950 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232_w.htm new file mode 100644 index 00000000..399bec4a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss232_w.htm @@ -0,0 +1,114 @@ + + + +CLHS: Issue MACRO-SUBFORMS-TOP-LEVEL-P Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACRO-SUBFORMS-TOP-LEVEL-P Writeup

    + +
    Issue:            MACRO-SUBFORMS-TOP-LEVEL-P
    
+References:       EVAL-WHEN, COMPILE-FILE,
    
+                  all macros defined in the standard
    
+Related issues:   EVAL-WHEN-NON-TOP-LEVEL
    
+Category:         CLARIFICATION
    
+Edit history:     v1, 13 Feb 1991, Sandra Loosemore
    
+                  v2, 11 Mar 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The compilation model defined by issue EVAL-WHEN-NON-TOP-LEVEL specifies
    
+  that expansions of macros inherit "top-level-ness" from the macro call.
    
+  This makes sense for user-defined macros, but users have no control
    
+  over what the expansions of macros defined in the standard are, since
    
+  they're provided by the Lisp implementation.  The semantics of a macro
    
+  call form can depend on whether or not its subforms appear at top-level
    
+  in the expansion, so the standard ought to place some constraints
    
+  on what the standard macros can expand into.
    
+
    
+Proposal (MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS):
    
+
    
+  Clarify that no subforms of calls to macros defined in the standard
    
+  inherit "top-level-ness" from the macro call unless explicitly stated
    
+  otherwise.  
    
+
    
+  Clarify that no macros now in the standard pass on "top-level-ness"
    
+  to their subforms.
    
+
    
+  Clarify that even if a macro is normally treated as a special form by 
    
+  the file compiler, both its handling as a special form and its normal
    
+  macro expansion must still satisfy these constraints.
    
+
    
+  Clarify that compiler-macro functions must ensure that expansions 
    
+  have the same semantics regarding inheritance of top-level-ness 
    
+  as the normal function or macro definition of the form.
    
+
    
+Rationale:
    
+
    
+  It fixes the problem.
    
+
    
+Current Practice:
    
+
    
+  Probably many implementations currently return macro expansions that
    
+  violate these rules.
    
+
    
+Cost to Implementors:
    
+
    
+  Implementors will have to examine the definitions of all macros they
    
+  provide to make sure that they conform to these rules.  Some 
    
+  "optimizations" currently performed may turn out to be invalid;
    
+  for example,          (and <form>)
    
+  could expand into     (let () <form>)
    
+  but not               (locally <form>)
    
+  or                    (progn <form>)
    
+  or                    <form>
    
+    
    
+Cost to Users:
    
+
    
+  Probably none.
    
+
    
+Cost of non-adoption:
    
+
    
+  User programs will behave differently in different implementations.
    
+
    
+Performance impact:
    
+
    
+  Probably small.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  The whole business of "top-level-ness" is kind of ugly.
    
+
    
+Discussion:
    
+
    
+  It doesn't appear that any of the ~90 macros defined in the standard
    
+  require special exceptions from the rule.  Certainly none of the
    
+  binding, conditional, or iteration macros ought to pass "top-level-ness"
    
+  through.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233.htm new file mode 100644 index 00000000..692d1c76 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233_w.htm new file mode 100644 index 00000000..b73b56ca --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss233_w.htm @@ -0,0 +1,88 @@ + + + +CLHS: Issue MACROEXPAND-HOOK-DEFAULT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACROEXPAND-HOOK-DEFAULT Writeup

    + +
    Issue:        MACROEXPAND-HOOK-DEFAULT
    
+Forum:	      Editorial
    
+References:   MACROEXPAND (pp151-152), *MACROEXPAND-HOOK* (p152)
    
+Category:     CLARIFICATION
    
+Edit history: 02-Mar-91, Version 1 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  In the description of the MACROEXPAND function on p152 of CLtL,
    
+  it says ``The initial value of *MACROEXPAND-HOOK* is FUNCALL.''
    
+
    
+  Does that mean the symbol FUNCALL, the function FUNCALL, or either?
    
+
    
+Proposal (MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE):
    
+
    
+  Specify that the initial value of *MACROEXPAND-HOOK* is either 
    
+  the symbol FUNCALL or the function which it names.
    
+
    
+Test Case:
    
+
    
+  None.
    
+
    
+Rationale:
    
+
    
+  This leaves flexibility to an implementation which needs it to be
    
+  #'FUNCALL for speed.  
    
+
    
+Current Practice:
    
+
    
+  In Symbolics Genera, the value is a function.
    
+
    
+Cost to Implementors:
    
+
    
+  None.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Lack of clear specification means mainly that implementors might worry
    
+  they were doing the wrong thing if they use #'FUNCALL, but might worry
    
+  about needless inefficiency if they use the symbol FUNCALL instead.
    
+
    
+Benefits:
    
+
    
+  Clearer specification.
    
+
    
+Aesthetics:
    
+
    
+  Negligible.
    
+
    
+Discussion:
    
+
    
+  Pitman doesn't care which way this is decided.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234.htm new file mode 100644 index 00000000..ecadae30 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234_w.htm new file mode 100644 index 00000000..5108b038 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss234_w.htm @@ -0,0 +1,100 @@ + + + +CLHS: Issue MACROEXPAND-HOOK-INITIAL-VALUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACROEXPAND-HOOK-INITIAL-VALUE Writeup

    + +
    Forum:		Public Review
    
+Issue:		MACROEXPAND-HOOK-INITIAL-VALUE
    
+References:	Moon's public review comment #15
    
+		*MACROEXPAND-HOOK* (p. 3-78)
    
+Category:	CHANGE
    
+Edit history:	21 Dec 1992, Version 1 by Loosemore
    
+Status:         Proposal IMPLEMENTATION-DEPENDENT passed 9-0-0, Mar 1993
    
+
    
+
    
+Problem description:
    
+
    
+  Page 3-78 says the initial value of *macroexpand-hook* is "a
    
+  designator for the function funcall". I think the initial value should
    
+  be implementation dependent, because some implementations use
    
+  *macroexpand-hook* to provide information to their program development
    
+  environment on which macros are in use.
    
+
    
+
    
+Proposal (MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT):
    
+
    
+  (1) Change the description of the initial value of *MACROEXPAND-HOOK*
    
+  to say that it is a designator for a function that is equivalent to
    
+  the function FUNCALL, but which can have additional 
    
+  implementation-dependent side-effects.
    
+
    
+  (2) Add to the notes section of the dictionary entry for
    
+  *MACROEXPAND-HOOK* a statement that users who put their own function
    
+  into *MACROEXPAND-HOOK* should consider saving the previous hook and
    
+  calling it from their function.
    
+
    
+
    
+Rationale:
    
+
    
+  Adopting this proposal would make *MACROEXPAND-HOOK* more useful.
    
+
    
+
    
+Current practice:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  None.
    
+
    
+
    
+Cost to users:
    
+
    
+  Probably little or none.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Neutral.
    
+
    
+
    
+Editorial impact:
    
+
    
+  The change is confined to the dictionary entry for *MACROEXPAND-HOOK*.
    
+
    
+
    
+Discussion:
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235.htm new file mode 100644 index 00000000..7c556e09 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MACROEXPAND-RETURN-VALUE:TRUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MACROEXPAND-RETURN-VALUE:TRUE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MACROEXPAND-RETURN-VALUE:TRUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235_w.htm new file mode 100644 index 00000000..3818a630 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss235_w.htm @@ -0,0 +1,96 @@ + + + +CLHS: Issue MACROEXPAND-RETURN-VALUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MACROEXPAND-RETURN-VALUE Writeup

    + +
    Forum:		Cleanup
    
+Issue:		MACROEXPAND-RETURN-VALUE
    
+References:	MACROEXPAND, MACROEXPAND-1
    
+			(CLtL p151)
    
+		COMPILER-MACROEXPAND, COMPILER-MACROEXPAND-1
    
+			(issue DEFINE-COMPILER-MACRO)
    
+Category:	CHANGE
    
+Edit History:   V1, 29 Oct 1989, Sandra Loosemore
    
+
    
+
    
+Problem Description:
    
+
    
+CLtL says that the second value returned by MACROEXPAND and
    
+MACROEXPAND-1 is T if the argument form is a macro call.  Presumably
    
+this is also the case for COMPILER-MACROEXPAND and
    
+COMPILER-MACROEXPAND-1, since these functions are intended to be "just
    
+like" their counterparts.  Specifying a return value of T is
    
+inconsistent with other predicates in the language, where a return
    
+value of "true" is normally specified instead.
    
+
    
+
    
+Proposal (MACROEXPAND-RETURN-VALUE:TRUE):
    
+
    
+Change the specification so that the second return value from
    
+MACROEXPAND, MACROEXPAND-1, COMPILER-MACROEXPAND, and
    
+COMPILER-MACROEXPAND-1 is a boolean instead of one of the symbols T or
    
+NIL.  In other words, if the form represents a macro call (or a
    
+compiler macro call, as appropriate), the second return value is true.
    
+
    
+
    
+Rationale:
    
+
    
+This is more consistent with other predicates in the language.
    
+
    
+
    
+Current Practice:
    
+
    
+Presumably all conforming implementations now return T.
    
+
    
+
    
+Cost to implementors:
    
+
    
+None, except possibly for the cost of changing documentation.
    
+
    
+
    
+Cost to users:
    
+
    
+It seems unlikely that user programs would explicitly test for the
    
+return value being T, or otherwise depend on this.
    
+
    
+
    
+Benefits:
    
+
    
+Increased consistency in the language design.
    
+
    
+
    
+Discussion:
    
+
    
+Loosemore notes:
    
+  In some implementations, there is a slight performance advantage in
    
+  allowing the return values from predicates to be any non-NIL value
    
+  instead of the symbol T.  Some functions such as MEMBER are required
    
+  to return a particular truth value that conveys extra information back
    
+  to the caller, but there doesn't appear to be similar motivation for
    
+  making an exception to the general rule in this situation.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236.htm new file mode 100644 index 00000000..58a1353b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue MAKE-LOAD-FORM-CONFUSION:REWRITE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MAKE-LOAD-FORM-CONFUSION:REWRITE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue MAKE-LOAD-FORM-CONFUSION:REWRITE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236_w.htm new file mode 100644 index 00000000..cd1850f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss236_w.htm @@ -0,0 +1,367 @@ + + + +CLHS: Issue MAKE-LOAD-FORM-CONFUSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MAKE-LOAD-FORM-CONFUSION Writeup

    + +
    Status:         Proposal REWRITE (version 8) accepted 12/91
    
+Issue:          MAKE-LOAD-FORM-CONFUSION
    
+Reference:      Draft 9.126, MAKE-LOAD-FORM (p.9-30)
    
+                Proposal LOAD-OBJECTS:MAKE-LOAD-FORM (Version 4)
    
+                Proposal CONSTANT-COMPILABLE-TYPES:SPECIFY (Version 10)
    
+                Proposal COMPILE-ENVIRONMENT-CONSISTANCE:CLARIFY (Version 6)
    
+                Issue CONFORMING-METHODS
    
+Category:       Change
    
+Edit History:   Version 1, 7/19/91, Kim Barrett
    
+                Version 2, 7/25/91, Kim Barrett
    
+                Version 3, 8/2/91, Kim Barrett
    
+                Version 4, 8/18/91, Kim Barrett
    
+                Version 5, 9/3/91, Kim Barrett (dangling "conforming method")
    
+                Version 6, 9/18/91, Kim Barrett (proposal REWRITE)
    
+                Version 7, 9/25/91, Kim Barrett
    
+                  (proposal REWRITE-WITH-POSITIONALS, update Discussion &etc,
    
+                   change "same (EQ)" to "\term{same}", add "Notes")
    
+                Version 8, 9/25/91, Kim Barrett (Moon's comments, change bars)
    
+
    
+Problem Description:
    
+
    
+ The last paragraph of the MAKE-LOAD-FORM proposal inadvertently forbids
    
+ implementations from providing methods for MAKE-LOAD-FORM which are applicable
    
+ to instances with metaclass STANDARD-CLASS or STRUCTURE-CLASS.
    
+
    
+ There was discussion about specifying that class metaobjects encountered as
    
+ compiled constants should be handled by looking up the class by name at load
    
+ time, but it appears that several mutually referencing issues may have all
    
+ assumed that this would be dealt with by one of the others, with the result
    
+ that nothing was actually specified for this situation.
    
+
    
+ MAKE-LOAD-FORM and MAKE-LOAD-FORM-SAVING-SLOTS are functions that deal with
    
+ forms, but violate the general principle that any function that manipulates
    
+ forms must have access to the environment in which those forms are to be
    
+ processed.
    
+
    
+Proposal (MAKE-LOAD-FORM-CONFUSION:REWRITE):
    
+
    
+ [Note: Lines beginning with "-n-" (where n is an integer) are not part of this
    
+ proposal.  These lines were taken verbatim from the passed LOAD-OBJECTS
    
+ proposal, and are present only as an aid to understanding some of the changes
    
+ being made by this proposal by presenting both the original text and the
    
+ corresponding rewritten description side by side.  Lines beginning with "+n+"
    
+ are part of the proposal, and are the proposed replacements for the
    
+ corresponding "-n-" text.  However, the absence of these change markers should
    
+ not be taken to imply that the unmarked text is the same as the LOAD-OBJECTS
    
+ proposal or Draft 9.126.]
    
+
    
+ 1. Replace the specification of MAKE-LOAD-FORM with the following:
    
+
    
+   MAKE-LOAD-FORM                               Standard Generic Function
    
+
    
+   Syntax:
    
+        MAKE-LOAD-FORM object &optional environment
    
+
    
+   Method Signatures:
    
+        make-load-form (object standard-object) &optional environment
    
+
    
+        make-load-form (object structure-object) &optional environment
    
+
    
+        make-load-form (object condition) &optional environment
    
+
    
+        make-load-form (object class) &optional environment
    
+
    
+   Arguments:
    
+        object -- an object.
    
+        environment -- an environment object.
    
+
    
+   Values:
    
+        Value 1: Creation form.
    
+        Value 2: Initialization form or not returned.
    
+
    
+   Description:
    
+        The generic function MAKE-LOAD-FORM creates and returns one or two
    
+        forms, a creation form and an initialization form, that enable LOAD to
    
+        construct an object equivalent to \arg{object}.  \arg{Environment} is
    
+        the environment in which the forms will be processed.
    
+
    
+-1-     COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
    
+-1-     a constant or as a self-evaluating form, if the object's metaclass is
    
+-1-     STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
    
+-1-     subclass of BUILT-IN-CLASS), or any of a possibly-empty
    
+-1-     implementation-defined list of other metaclasses.  COMPILE-FILE will
    
+-1-     only call MAKE-LOAD-FORM once for any given object (compared with EQ)
    
+-1-     within a single file.
    
++1+     COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as a
    
++1+     constant or as a self-evaluating form, if the object is a generalized
    
++1+     instance of STANDARD-OBJECT, STRUCTURE-OBJECT, CONDITION, or any of a
    
++1+     possibly empty implementation dependent list of other classes.
    
++1+     COMPILE-FILE will only call MAKE-LOAD-FORM once for the \term{same}
    
++1+     object within a single file.
    
+
    
+-2-     It is valid for user programs to call MAKE-LOAD-FORM in other
    
+-2-     circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
    
+-2-     or a subclass of BUILT-IN-CLASS.
    
++2+     Programmers may call MAKE-LOAD-FORM directly, providing \arg{object} is
    
++2+     a generalized instance of one of the explicitly named classes listed
    
++2+     previously.
    
+
    
+-3-     MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
    
+-3-     STRUCTURE-CLASS for which no user-defined method is applicable signals
    
+-3-     an error.  It is valid to implement this either by defining default
    
+-3-     methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
    
+-3-     or by having no applicable method for those classes.
    
++3+     The methods specialized on STANDARD-OBJECT, STRUCTURE-OBJECT, and
    
++3+     CONDITION all signal an error of type ERROR.
    
+
    
+        The method specialized on CLASS returns a creation form using the name
    
+        of the class if the class has a proper name in \arg{environment},
    
+        signaling an error of type ERROR if it does not have a proper name.
    
+        Evaluation of the creation form uses the name to find the class with
    
+        that name, as if by calling FIND-CLASS.  If a class with that name has
    
+        not been defined, then a class may be computed in an implementation
    
+        defined manner.  If a class cannot be returned as the result of
    
+        evaluating the creation form, then an error of type ERROR is signaled.
    
+
    
+        Implementations may provide additional methods specialized on system
    
+        classes.  It is implementation dependent whether calling MAKE-LOAD-FORM
    
+        on a generalized instance of a \term{system class} signals an error or
    
+        returns creation and initialization forms.
    
+
    
+        Both implementations and programs may define additional
    
+        \term{conforming methods} to extend the behavior of MAKE-LOAD-FORM.
    
+
    
+        The creation form is a form that, when evaluated at \term{load time},
    
+        should return an object that is equivalent to \arg{object}.  The exact
    
+        meaning of ``equivalent'' depends on the type of object and is up to
    
+        the programmer who defines a method for MAKE-LOAD-FORM.  See ``What can
    
+        appear as a constant'' and ``Similarity as constants''.
    
+
    
+        The initialization form is a form that, when evaluatated at \term{load
    
+        time}, should perform further initialization of the object.  The value
    
+        returned by the initialization form is ignored.  If MAKE-LOAD-FORM
    
+        returns only one value, the initialization form is NIL, which has no
    
+        effect.  If \arg{object} appears as a constant in the initialization
    
+        form, at \term{load time} it will be replaced by the equivalent object
    
+        constructed by the creation form; this is how the further
    
+        initialization gains access to the object.
    
+
    
+-4-     Both the creation form and the initialization form can contain
    
+-4-     references to objects of user-defined types (defined precisely below).
    
++4+     Both the creation and initialization forms may contain references to
    
++4+     objects of any type which can be processed as a constant by
    
++4+     COMPILE-FILE.  However, there must not be any circular dependencies in
    
+        creation forms.  An example of a circular dependency is when the
    
+        creation form for the object X contains a reference to the object Y,
    
+        and the creation form for the object Y contains a reference to the
    
+        object X.  Initialization forms are not subject to any restriction
    
+        against circular dependencies, which is the reason that initialization
    
+        forms exist.  See the example of circular data structures below.
    
+
    
+-5-     The creation form for an object is always evaluated before the
    
+-5-     initialization form for that object.  When either the creation form or
    
+-5-     the initialization form references other objects of user-defined types
    
+-5-     that have not been referenced earlier in the COMPILE-FILE, the
    
+-5-     compiler collects all of the creation and initialization forms.  Each
    
+-5-     initialization form is evaluated as soon as possible after its
    
+-5-     creation form, as determined by data flow.  If the initialization form
    
+-5-     for an object does not reference any other objects of user-defined
    
+-5-     types that have not been referenced earlier in the COMPILE-FILE, the
    
+-5-     initialization form is evaluated immediately after the creation form.
    
+-5-     If a creation or initialization form F references other objects of
    
+-5-     user-defined types that have not been referenced earlier in the
    
+-5-     COMPILE-FILE, the creation forms for those other objects are evaluated
    
+-5-     before F, and the initialization forms for those other objects are
    
+-5-     also evaluated before F whenever they do not depend on the object
    
+-5-     created or initialized by F.  Where the above rules do not uniquely
    
+-5-     determine an order of evaluation, which of the possible orders of
    
+-5-     evaluation is chosen is unspecified.
    
++5+     The creation form for an object is always evaluated before the
    
++5+     initialization form for that object.  When either the creation form or
    
++5+     the initialization form references other objects that have not been
    
++5+     referenced earlier in the file being compiled, the compiler ensures
    
++5+     that all of the referenced objects have been created before evaluating
    
++5+     the referencing form.  When the referenced object is of a type which
    
++5+     COMPILE-FILE processes using MAKE-LOAD-FORM, this involves evaluating
    
++5+     the creation form returned for it.  (This is the reason for the
    
++5+     prohibition against circular references among creation forms).
    
++5+
    
++5+     Each initialization form is evaluated as soon as possible after its
    
++5+     associated creation form, as determined by data flow.  If the
    
++5+     initialization form for an object does not reference any other objects
    
++5+     not referenced earlier in the file and processed by COMPILE-FILE using
    
++5+     MAKE-LOAD-FORM, the initialization form is evaluated immediately after
    
++5+     the creation form.  If a creation or initialization form F does contain
    
++5+     references to such objects, the creation forms for those other objects
    
++5+     are evaluated before F, and the initialization forms for those other
    
++5+     objects are also evaluated before F whenever they do not depend on the
    
++5+     object created or initialized by F.  Where these rules do not uniquely
    
++5+     determine an order of evaluation between two creation/initialization
    
++5+     forms, the order of evaluation is unspecified.
    
+
    
+        While these creation and initialization forms are being evaluated, the
    
+        objects are possibly in an uninitialized state, analogous to the state
    
+        of an object between the time it has been created by ALLOCATE-INSTANCE
    
+        and it has been processed fully by INITIALIZE-INSTANCE.  Programmers
    
+        writing methods for MAKE-LOAD-FORM must take care in manipulating
    
+        objects not to depend on components that have not yet been initialized.
    
+
    
+        It is implementation dependent whether LOAD calls EVAL on the forms or
    
+        does some other operation that has an equivalent effect.  For example,
    
+        the forms might be translated into different but equivalent forms and
    
+        then evaluated, they might be compiled and the resulting functions
    
+        called by LOAD, or they might be interpreted by a special-purpose
    
+        interpreter different from EVAL.  All that is required is that the
    
+        effect be equivalent to evaluating the forms.
    
+
    
+   Examples:
    
+        {use existing examples}
    
+
    
+   Affected By:
    
+        None.
    
+
    
+   Exceptional Situations:
    
+        Certain methods signal an error when called, indicating that
    
+        \arg{object} cannot be used as a constant in code being processed by
    
+        COMPILE-FILE.
    
+
    
+   See Also:
    
+        COMPILE-FILE, MAKE-LOAD-FORM-SAVING-SLOTS, ``Compilation'',
    
+        ``Evaluation''.
    
+
    
+   Notes:
    
+        Some implementations may provide facilities for defining new subclasses
    
+        of classes which are specified as \term{system classes} by this
    
+        standard (some likely candidates include GENERIC-FUNCTION, METHOD, and
    
+        STREAM).  Such implementations should document how COMPILE-FILE treats
    
+        instances of such classes when encountered as constants, and should
    
+        document any relevant methods for MAKE-LOAD-FORM.
    
+
    
+ 2. Change the syntax of MAKE-LOAD-FORM-SAVING-SLOTS to
    
+
    
+        MAKE-LOAD-FORM-SAVING-SLOTS object &key :slot-names :environment
    
+
    
+ \arg{Environment} is an environment object, and is the environment in which
    
+ the forms will be processed.
    
+
    
+Proposal (MAKE-LOAD-FORM-CONFUSION:REWRITE-WITH-POSITIONALS):
    
+
    
+ Same as MAKE-LOAD-FORM-CONFUSION:REWRITE, except that the syntax for
    
+ MAKE-LOAD-FORM-SAVING-SLOTS is changed to
    
+
    
+        MAKE-LOAD-FORM-SAVING-SLOTS object &optional slot-names environment
    
+
    
+Editorial Impact:
    
+
    
+ A new version of MAKE-LOAD-FORM must be integrated into the document.  It is
    
+ intended that this be a matter of making stylistic edits, formatting, and
    
+ getting fonts right for defined names, glossary terms, and such.
    
+
    
+ Small changes to MAKE-LOAD-FORM-SAVING-SLOTS.
    
+
    
+ Possibly some small changes to the description of constant processing by
    
+ COMPILE-FILE.
    
+
    
+Rationale:
    
+
    
+ Adding optional environment arguments to these functions provides them with
    
+ access to the environment in which the forms to be returned will be processed
    
+ by COMPILE-FILE.
    
+
    
+ The rewrite attempts to fix the problem that the original specification of
    
+ MAKE-LOAD-FORM said something much stronger than was perhaps actually
    
+ intended, while still providing programmers with some guarantees about the
    
+ behavior of MAKE-LOAD-FORM when applied to instances of portable classes.
    
+
    
+ The intent is that programmers may define portable classes with the knowledge
    
+ that these classes will not be unintentionally inheriting supposedly useful
    
+ but actually inadequate methods for MAKE-LOAD-FORM provided by the
    
+ implementation, while still permitting COMPILE-FILE to use MAKE-LOAD-FORM for
    
+ handling instances of classes which are specified as possibly being built in
    
+ classes and for instances of additional implementation specific classes.
    
+
    
+ Adding a method signature for CLASS fills the gap mentioned in the problem
    
+ description.  Some portions of the mechanism for performing the name to class
    
+ lookup are implementation defined in order to permit extensions (such as
    
+ forward referenced classes).  This method is needed because class metaobjects
    
+ are valid type specifiers and so may be expected to appear directly in code to
    
+ be compiled.
    
+
    
+Current Practice:
    
+
    
+ Lucid plans (in a future release which includes MAKE-LOAD-FORM) to provide the
    
+ method signature MAKE-LOAD-FORM (object CLASS), which will return a form that
    
+ looks up the class by name, returning a forward referenced class if necessary.
    
+
    
+ Symbolics removed the method MAKE-LOAD-FORM (object CLASS) from their current
    
+ development system, both because of technical issues related to extensions and
    
+ because of a belief that there were unresolved semantic issues.  This proposal
    
+ attempts to deal with those issues.
    
+
    
+ Presumably nobody has yet given MAKE-LOAD-FORM an optional second argument.
    
+
    
+Cost to Users and Implementors:
    
+
    
+ All existing methods for MAKE-LOAD-FORM will have to be modified to accept the
    
+ optional second argument.  Some methods might need to be modified to use the
    
+ argument, rather than simply ignoring it.  Probably the number of methods
    
+ involved is small, and both implementors and users will presumably be alerted
    
+ to unmodified definitions because of lambda-list congruency failures.
    
+
    
+ Calls to MAKE-LOAD-FORM-SAVING-SLOTS will need to be examined to determine
    
+ whether there is a missing environment argument that needs to be supplied, and
    
+ figure out where that environment is supposed to come from.  Since most calls
    
+ to this function are likely to be in MAKE-LOAD-FORM methods, this is probably
    
+ going to be easy in virtually every case.
    
+
    
+Discussion:
    
+
    
+ There was significant divergence of opinion regarding the treatment of class
    
+ metaobjects as compiled constants.  Some discussion revolved around the issue
    
+ of whether the name to class mapping was sufficiently dependable to make
    
+ dumping by loadtime name lookup a reasonable choice, and whether this facility
    
+ was needed at all.  The principal point of debate was the question of what to
    
+ do at loadtime when FIND-CLASS doesn't find a class.  The passage from
    
+ COMPILE-ENVIRONMENT-CONSISTANCY regarding classes defined with DEFCLASS bears
    
+ on both of these questions.  The current description is a compromise whose
    
+ intent is to permit but not require certain kinds of extensions, while
    
+ providing users with confidence that something well defined will happen if
    
+ this situation (which COMPILE-ENVIRONMENT-CONSISTANCY can be interpreted as
    
+ saying is an error) occurs.
    
+
    
+ Moon, regarding environment information
    
+  As I keep saying over and over (although I guess I must not have been
    
+  listening to myself when I first proposed make-load-form!), no form has any
    
+  meaning without an accompanying environment.
    
+
    
+ JonL, in response to the question
    
+   Will users complain if we don't add the ability to fasdump named class
    
+   objects to the language? 
    
+
    
+  Already have.  In droves.  Probably because class-objects are written into
    
+  the language as first-class type-specifiers, and are being incorporated into
    
+  programs (as constants) with impunity.
    
+
    
+ Moon and Barrett both prefer proposal REWRITE over REWRITE-WITH-POSITIONALS.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237.htm new file mode 100644 index 00000000..c2a37896 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237_w.htm new file mode 100644 index 00000000..2eae4881 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss237_w.htm @@ -0,0 +1,129 @@ + + + +CLHS: Issue MAKE-LOAD-FORM-SAVING-SLOTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MAKE-LOAD-FORM-SAVING-SLOTS Writeup

    + +
    Issue:        MAKE-LOAD-FORM-SAVING-SLOTS
    
+Reference:    X3J13/92-102, dpANS 12.24
    
+                MAKE-LOAD-FORM, p.7-51
    
+                MAKE-LOAD-FORM-SAVING-SLOTS, p.7-56
    
+              X3J13/92-2102, Kevin Gallagher comment #2
    
+              X3J13/92-3104, Kim Barrett comment #4
    
+              X3J13/89-526, Issue LOAD-OBJECTS (Version 4)
    
+              X3J13/91-485, Issue SLOT-VALUE-METACLASSES (Version 7)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit History: Version 1, 1/5/93, Kim Barrett
    
+              Version 2, 1/5/93, Kim Barrett (fix current practice)
    
+              Version 3, 1/6/93, Kim Barrett
    
+                (description is operational, move possible operators to notes)
    
+Status:       Proposal NO-INITFORMS accepted, March 1993
    
+
    
+Problem Description:
    
+
    
+ The description of the function MAKE-LOAD-FORM-SAVING-SLOTS is expressed in
    
+ terms of MAKE-INSTANCE, SETF of SLOT-VALUE, and SLOT-MAKUNBOUND, which is a
    
+ mistake on several counts.
    
+
    
+ 1. It could be interpreted as indicating that slot initialization forms are
    
+ to be executed, with the values of the slots then modified by SETF of
    
+ SLOT-VALUE or SLOT-MAKUNBOUND.  This is not in the spirit of the overall
    
+ proposal that introduced this operator, which talks about allocation via the
    
+ function ALLOCATE-INSTANCE.  MCL2.0 in fact used that interpretation, and then
    
+ received bug reports from users who expected initforms to not be executed.
    
+
    
+ 2. None of these operators are defined by this document as being applicable
    
+ when the metaclass STRUCTURE-CLASS is involved.  A sufficiently literal
    
+ reading could cause one to conclude that in fact this specification requires
    
+ such applicability, which the committee explicitly decided against.
    
+
    
+Proposal (MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS):
    
+
    
+ 1. Replace the first paragraph of the Description section of the dictionary
    
+ entry for MAKE-LOAD-FORM-SAVING-SLOTS with
    
+
    
+  Returns \term{forms} that, when \term{evaluated}, will construct an
    
+  \term{object} equivalent to \param{object}, without \term{executing}
    
+  \term{initialization forms}.  The \term{slots} in the new \term{object}
    
+  that correspond to initialized \term{slots} in \param{object} are
    
+  initialized using the values from \param{object}.  Uninitialized \term{slots}
    
+  in \param{object} are not initialized in the new \term{object}.
    
+  \funref{make-load-form-saving-slots} works for any \term{instance} of
    
+  \typeref{standard-object} or \typeref{structure-object}.
    
+
    
+ 2. Add the following to the Notes section for MAKE-LOAD-FORM-SAVING-SLOTS.
    
+
    
+  When the \term{object} is an \term{instance} of \typeref{standard-object},
    
+  \funref{make-load-form-saving-slots} could return a creation form that
    
+  \term{calls} \funref{allocate-instance} and an initialization form that
    
+  contains \term{calls} to \macref{setf} of \funref{slot-value} and
    
+  \funref{slot-makunbound}, though other \term{functions} of similar effect
    
+  might actually be used.
    
+
    
+Editorial Impact:
    
+
    
+ A small cut and paste job.
    
+
    
+Rationale:
    
+
    
+ Addresses the problem description.
    
+
    
+Examples:
    
+
    
+ (defvar *initform-executed-counter* 0)
    
+ (defstruct foo
    
+   (slot-1 (incf *initform-executed-counter*)))
    
+ (defvar *foo* (make-foo))
    
+ *initform-executed-counter* => 1
    
+ (mapc #'eval (multiple-value-list (make-load-form-saving-slots *foo*)))
    
+ *initform-executed-counter* => 1
    
+
    
+Current Practice:
    
+
    
+ Apple Macintosh Common Lisp 2.0p2 implements this.
    
+
    
+Cost to Implementors:
    
+
    
+ Probably small.
    
+
    
+Cost to Users:
    
+
    
+ Probably small.  Only programs that were depending on the execution of
    
+ initforms would be negatively affected by this, and such programs are
    
+ probably already not portable.
    
+
    
+Performance Impact:
    
+
    
+ None.
    
+
    
+Benefits:
    
+
    
+Aesthetics:
    
+
    
+Discussion:
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238.htm new file mode 100644 index 00000000..c4dc2559 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238_w.htm new file mode 100644 index 00000000..d8fbe530 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss238_w.htm @@ -0,0 +1,214 @@ + + + +CLHS: Issue MAKE-PACKAGE-USE-DEFAULT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MAKE-PACKAGE-USE-DEFAULT Writeup

    + +
    Status: Passed, as amended
    
+Issue:        MAKE-PACKAGE-USE-DEFAULT 
    
+
    
+References:    MAKE-PACKAGE, CLtL p183
    
+               "USER" package, CLtL p181
    
+
    
+Related issues: PACKAGE-CLUTTER
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  JonL White, 6-Oct-88 (version 1)
    
+               Masinter,  8-Oct-88  (version 2)
    
+               Masinter, 16-Mar-89, Version 3 (make amendments 
    
+			per Jan 89 X3J13)
    
+
    
+Problem description:
    
+
    
+The proposal in the issue PACKAGE-CLUTTER would specify that 
    
+implementation-specific extensions are not in the LISP package.
    
+
    
+With that restriction, access to implementation-specific features
    
+is awkward; it is necessary to always name the vendor-specific
    
+extensions in the :USE list of MAKE-PACKAGE or (if the proposal
    
+in DEFPACKAGE is adopted) in DEFPACKAGE.
    
+
    
+This forces users of a specific implementation to always have
    
+to type something to get the default set of features for that
    
+implementation, even if they have no intention of writing portable
    
+code.
    
+
    
+
    
+Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
    
+
    
+Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
    
+adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
    
+adopted) so that the default for the :USE keyword is 
    
+undefined. Normally, the default will include
    
+the packages containing the implementation-specific features.
    
+
    
+Portable programs should instead always specify :USE '("LISP")
    
+explicitly.  
    
+
    
+Examples:
    
+
    
+(package-use-list (make-package "SOME-USER"))
    
+(package-use-list "USER")
    
+
    
+
    
+Test Cases:
    
+
    
+(assert 
    
+    (subsetp `(,(find-package "LISP"))
    
+              (package-use-list (or (find-package "SOME-USER")
    
+				    (make-package "SOME-USER")))))
    
+
    
+
    
+Rationale:
    
+
    
+Every implementation either already does the equivalent of this, or
    
+else has a confusing assymetry about the USER package (i.e., their
    
+extensions are "available" in USER, but not in SOME-USER).
    
+
    
+Current practice:
    
+
    
+TI and Lucid's  3.0 versions "implement" this proposal in that they set 
    
+the default :USE argument to be a list of the LISP package and the 
    
+implementation-specific package. 
    
+
    
+In VAXLISP the LISP package is the implementation-specific
    
+package, which contains the 775 symbols supposed to be in the LISP packge
    
+along with all the extensions; the package named COMMON-LISP
    
+has only the 775.  Thus this implements the proposal in the sense that
    
+the inheritance of a package made with a default :USE list contains
    
+all the implementation-specific symbols -- not just the 775 "LISP" ones.
    
+
    
+Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
    
+default MAKE-PACKAGE use list, but have the aforementioned assymetry
    
+about the USER package.
    
+
    
+Cost to Implementors:
    
+
    
+None; this relaxes a constraint imposed by CLtL.
    
+
    
+Cost to Users:
    
+
    
+In theory, every user porting code from one vendor to another would
    
+have to ensure that every package definition, via IN-PACKAGE or
    
+MAKE-PACKAGE, had an explicit :USE list.  This is probably at most
    
+a 5-minute text editor search.  But in fact this imposition is moot,
    
+since virtually every such user has *already* supplied explicit
    
+:USE lists; given the current practice, he has had no alternative.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+There will continue to be a lack of clear standardization in this area,
    
+especially since vendors are more willing to violate this apparently
    
+unuseful mandate from CLtL than they are to give up a minor bias towards
    
+their customer base.
    
+
    
+Performance impact:
    
+
    
+None.
    
+
    
+Benefits:
    
+
    
+This new default behaviour for package creation will permit 
    
+documented extensions to appear on equal footing with the basic facilities
    
+in the LISP package.  It appears as though the _majority_ of any  
    
+users are developing and running their code totally within the 
    
+enviornment provided by that one vendor; hence it seems reasonable for
    
+implementations to bias their default use list towards those making 
    
+frequent use of their specific extensions to Common Lisp.
    
+
    
+
    
+Esthetics:
    
+
    
+Some feel that fewer implementation-dependent loopholes in the language
    
+is preferable, even when the practical import is virtually moot.
    
+
    
+Discussion:
    
+
    
+Lucid "exposes" the default :use list as the value of the special
    
+variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
    
+time, one could do
    
+	  (setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
    
+to return to the 1984 CLtL behaviour.  [This is not being proposed
    
+at this time.]
    
+
    
+
    
+
    
+     ----- Additional Comments -----
    
+
    
+
    
+" I don't like this proposal, but I made a note to myself about another
    
+ reason that just occurred to me:  There is no syntax for getting the default
    
+ (ie, system-dependent) package included if you want to -also- use some other
    
+ package."
    
+
    
+ - - - - - -
    
+
    
+"MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
    
+I think it might be better to strengthen it and say that the
    
+default for :USE is identical to the use list of the USER package.
    
+Does anyone agree?
    
+
    
+In response to Kent's remarks, the issue is whether the default should
    
+be a portable way to get the local extensions, or a portable way to
    
+get the portable language without the extensions.  I think either of
    
+those choices is portable and reasonable, it just depends on what you
    
+want to make easier, which probably depends on whether a package is
    
+being set up for use only by a predefined program or for use by user
    
+typein and/or user-written programs, either of which are likely to
    
+expect the local extensions.
    
+
    
+Hence I would also accept a proposal to make the default for :USE
    
+continue to be the LISP package, rather than incompatibly changing it,
    
+and add a portable name for the local extensions."
    
+ - - - - - -
    
+
    
+"re: I think it might be better to strengthen it and say that the
    
+    default for :USE is identical to the use list of the USER package.
    
+    Does anyone agree?
    
+
    
+I agree, sort of.  Especially since one of the motivating factors for 
    
+this proposal was that some Lucid 2.1 user's were complaining that 
    
+"things" look a lot different from the USER package than from a 
    
+user-created package.
    
+
    
+The only question is whether or not you really want the default to be
    
+sensitive to subsequent alterations of USER's :use list.  As mentioned
    
+in the Discussion section of the proposal, Lucid's implementation
    
+exposes the default as the value of a global variable, which happens
    
+to be a copy of the initial :use list of USER; but subsequent changes 
    
+to USER have no affect on this global variable."
    
+ - - - - - -
    
+
    
+"The point:  non-portable programs should declare that intent up-front.
    
+This is a virtue of the current situation:  if the program uses a
    
+non-portable package, they have to state that at the head of the file.  Us
    
+poor losers who try to load it into the wrong environment get a error
    
+before we've gotten on with the load."
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239.htm new file mode 100644 index 00000000..0262878d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MAP-INTO:ADD-FUNCTION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MAP-INTO:ADD-FUNCTION Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MAP-INTO:ADD-FUNCTION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239_w.htm new file mode 100644 index 00000000..c8bf404d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss239_w.htm @@ -0,0 +1,132 @@ + + + +CLHS: Issue MAP-INTO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MAP-INTO Writeup

    + +
    Status:	Passed, Jun 89 X3J13
    
+Issue:          MAP-INTO
    
+References:     none
    
+Related issues: BIT-ARRAY-FUNCTIONS
    
+Category:       ADDITION
    
+Edit history:   23-May-89, version 1 by Moon
    
+                19-Jun-89, version 2 by Moon (fix arglist)
    
+                23-Jun-89, version 3 by Moon (include BarMar's suggestions)
    
+
    
+Problem description:
    
+
    
+  The function MAP is very useful but can be a source of inefficiency
    
+  because it conses the result.  Sometimes the user has storage
    
+  already allocated in which the result could be stored.
    
+
    
+Proposal (MAP-INTO:ADD-FUNCTION):
    
+
    
+  Add the following function:
    
+
    
+    MAP-INTO result-sequence function &rest sequences            [Function]
    
+
    
+    Destructively modifies the result-sequence to contain the results of
    
+    applying function to each element in the argument sequences in turn.
    
+    Returns result-sequence.
    
+
    
+    The arguments result-sequence and each element of sequences can each be
    
+    either a list or a vector (one-dimensional array).  Note that NIL is
    
+    considered to be a sequence, of length zero.  If result-sequence and
    
+    each element of sequences are not all the same length, the iteration
    
+    terminates when the shortest sequence is exhausted.  If result-sequence
    
+    is a vector with a fill-pointer, the fill-pointer is ignored when
    
+    deciding how many iterations to perform, and afterwards the
    
+    fill-pointer is set to the number of times function was applied.
    
+
    
+    If result-sequence is longer than the shortest element of sequences,
    
+    extra elements at the end of result-sequence are left unchanged.
    
+
    
+    MAP-INTO differs from MAP in that it modifies an existing sequence
    
+    rather than creating a new one.  In addition, MAP-INTO can be called
    
+    with only two arguments, while MAP requires at least three arguments.
    
+    If result-sequence is NIL, MAP-INTO immediately returns NIL, since
    
+    NIL is a sequence of length zero.
    
+
    
+    If BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS passes, then MAP-INTO will
    
+    allow result-sequence and each element of sequences to be mappables
    
+    all of the same rank.
    
+
    
+    The function must take at least as many arguments as there are
    
+    sequences provided.
    
+
    
+    If function has side effects, it can count on being called first on all
    
+    of the elements with index 0, then on all of those numbered 1, and so
    
+    on.
    
+
    
+Examples:
    
+
    
+  (map-into x #'+ x y)
    
+  (map-into q #'cons keys vals)
    
+  (map-into syms #'gensym)
    
+
    
+Rationale:
    
+
    
+  MAP-INTO is a simple way to express reuse of storage that is
    
+  stylistically consistent with the rest of Common Lisp.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 7.2 implements the proposal.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Small.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  More expressive language.
    
+
    
+Esthetics:
    
+
    
+  User programs won't have to write the above examples as
    
+
    
+   (loop for xx on x and yy in y do
    
+      (setf (car xx) (+ (car xx) yy)))
    
+
    
+  or something else about equally horrible.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240.htm new file mode 100644 index 00000000..1e26d2b3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240.htm @@ -0,0 +1,70 @@ + + + +CLHS: Issue MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240_w.htm new file mode 100644 index 00000000..49c57cc1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss240_w.htm @@ -0,0 +1,138 @@ + + + +CLHS: Issue MAPPING-DESTRUCTIVE-INTERACTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MAPPING-DESTRUCTIVE-INTERACTION Writeup

    + +
    Issue:          MAPPING-DESTRUCTIVE-INTERACTION
    
+References:     MAPCAR, MAPLIST, ... (p128);
    
+	        DOLIST (p126); MAPHASH (p285); 
    
+	        DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
    
+	        All functions using :TEST	      
    
+Related-Issues: REMF-DESTRUCTION-UNSPECIFIED.
    
+Category:       CLARIFICATION
    
+Edit history:   07-Mar-88, Version 1 by Pitman
    
+	        09-Jun-88, Version 2 by Pitman
    
+		   (merge Moon's comments and update current practice)
    
+
    
+Problem Description:
    
+
    
+ The interaction of mapping functions and DOLIST with destructive
    
+ operations on the list being operated on is unclear. For example,
    
+ if you destructively modify some tail of a list being mapped down,
    
+ does that affect the mapping process?
    
+
    
+Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):
    
+
    
+ Clarify that it in general is an error (the effect is not defined
    
+ but in general no error will be signalled) for code executed during a
    
+ "structure traversing" operation to destructively modify the
    
+ structure in a way that might affect the ongoing traversal operation.
    
+
    
+ For list traversal operations, this means that the cdr chain of the
    
+ list may not be destructively modified.
    
+
    
+ For array traversal operations, the array may not be adjusted and
    
+ its fill-pointer, if any, may not be changed.
    
+
    
+ For hash tables, new elements may not be added or deleted EXCEPT
    
+ that the element corresponding to the current hash key may be
    
+ changed or removed.
    
+
    
+ For packages, new symbols may not be interned in or uninterned from
    
+ the package being traversed or any package that it uses EXCEPT that
    
+ the current symbol may be uninterned from the package being traversed
    
+ in a DO-SYMBOLS.
    
+
    
+ Note: This proposal is intended to clarify restrictions on user code
    
+  for use with structure manipulators which are not inherently
    
+  destructive. Other operators, such as DELETE-DUPLICATES or NREVERSE,
    
+  may have much more complicated restrictions and are intentionally not
    
+  treated by this proposal. See the issue REMF-DESTRUCTION-UNSPECIFIED
    
+  for more discussion of such issues.
    
+
    
+Test Case:
    
+
    
+ (LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
    
+   (DOLIST (FOO L)
    
+     (INCF I)
    
+     (IF (EQ FOO 'B)
    
+	 (SETF (CDR LL) NIL)
    
+	 (POP LL)))
    
+   (LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
    
+
    
+Rationale:
    
+
    
+ This clarifies the status quo.
    
+
    
+ Also, the likelihood that the user will want to destructively alter a
    
+ structure while it is being traversed is low. The likelihood that such
    
+ code would be readable and maintainable is also low. The likelihood 
    
+ that a compiler could do some interesting optimization if this point
    
+ were not pinned down is high enough to be the overriding consideration
    
+ in this case.
    
+
    
+Current Practice:
    
+
    
+ The implementation of DOLIST in Symbolics Genera, KCL, and PopLog Common Lisp
    
+ returns (3 (A B)) for the test case.
    
+
    
+Cost to Implementors:
    
+
    
+  None. This simply makes the status quo explicit.
    
+
    
+Cost to Users:
    
+
    
+  Technically none. People who were mistakenly assuming that CLtL guaranteed
    
+  things which it does not might be inclined to rewrite their code in a more
    
+  portable way.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Users would be less informed.
    
+
    
+Benefits:
    
+
    
+  users would be more informed.
    
+
    
+Aesthetics:
    
+
    
+  Some might say it would be clearer to define this one way or the other, but
    
+  advocates of both camps exist and their arguments are fairly symmetric.
    
+  In any case, since this is a proposal to preserve the status quo, it has no
    
+  major impact on aesthetics.
    
+
    
+Discussion:
    
+
    
+  This idea for this proposal was suggested by the Japanese community.
    
+
    
+  Pitman drafted the formal proposal and supports the EXPLICITLY-VAGUE proposal.
    
+
    
+  Moon generally supported version 1 of this proposal, but had some specific
    
+  criticisms about weakness of the wording which this version is an attempt to fix.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241.htm new file mode 100644 index 00000000..f3328806 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241_w.htm new file mode 100644 index 00000000..cc3c5ca9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss241_w.htm @@ -0,0 +1,118 @@ + + + +CLHS: Issue METACLASS-OF-SYSTEM-CLASS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue METACLASS-OF-SYSTEM-CLASS Writeup

    + +
    Issue:        METACLASS-OF-SYSTEM-CLASS
    
+Reference:    X3J13/92-102, dpANS 12.24
    
+                Section 4.3.7, "Integrating Types and Classes", p.4-16..418
    
+              X3J13/92-3105, Kim Barrett comment #5
    
+Category:     CHANGE
    
+Edit History: Version 1, 1/6/93, Kim Barrett
    
+Status:       Proposal UNSPECIFIED accepted, March 1993
    
+
    
+Problem Description:
    
+
    
+ The fifth and seventh paragraphs on p.4-17 say
    
+
    
+  Each \term{class} that corresponds to a predefined \term{type specifier}
    
+  can be implemented in one of three ways, at the discretion of each
    
+  implementation.  It can be a \term{standard class}, a
    
+  \term{structure class}, or a \term{built-in class}.
    
+
    
+  It is possible to determine whether a \term{class} is a
    
+  \term{built-in class} by checking the \term{metaclass}.  A
    
+  \term{standard class}  is an \term{instance} of \theclass{standard-class},
    
+  a \term{built-in class}  is an \term{instance} of
    
+  \theclass{built-in-class}, and a \term{structure class} is an
    
+  \term{instance} of \theclass{structure-class}.
    
+
    
+ This prohibits implementations from using implementation-specific metaclasses
    
+ which are not subclasses of one of the three defined metaclasses
    
+ (STANDARD-CLASS, STRUCTURE-CLASS, and BUILT-IN-CLASS).  This prohibition
    
+ gratuitously limits implemention freedom, since it serves no useful purpose
    
+ for users.
    
+
    
+ Depending on how the uses of the term \term{instance} are disambiguated in
    
+ the second paragraph, it may actually be making the stronger requirement that
    
+ \term{direct instances} of these metaclasses be used.
    
+
    
+Proposal (METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED):
    
+
    
+ Change the fifth paragraph on p.4-17 by replacing the occurance of the term
    
+ \term{built-in class} with the term \term{system class}, so that it says
    
+
    
+  Each \term{class} that corresponds to a predefined \term{type specifier}
    
+  can be implemented in one of three ways, at the discretion of each
    
+  implementation.  It can be a \term{standard class}, a
    
+  \term{structure class}, or a \term{system class}.
    
+
    
+Editorial Impact:
    
+
    
+ One tiny edit.
    
+
    
+Rationale:
    
+
    
+ Allows system classes to be implemented using implementation specific
    
+ metaclasses that are not themselves subclasses of any of the standardized
    
+ metaclasses, and therefore can be implemented in whatever manner is
    
+ deemed appropriate by the implementor without the need to override possibly
    
+ undesirable features of the inherited standardized metaclass.
    
+
    
+Examples:
    
+
    
+ (typep (find-class 'stream)
    
+        '(or standard-class structure-class built-in-class))
    
+ \EV \term{implementation-dependent}
    
+
    
+Current Practice:
    
+
    
+ Of the half dozen implementations I checked, none obeyed even the
    
+ weaker of requirements mentioned in the problem description.
    
+
    
+Cost to Implementors:
    
+
    
+ None.  This does not require any implementation to change.
    
+
    
+Cost to Users:
    
+
    
+ Small.  Any program that was specializing some generic function on
    
+ standard-class, structure-class, and built-in-class (with the idea that this
    
+ covered all the possibilities) would have to change.  Such a program is
    
+ already non-portable.  The obvious change is to instead specialize on class.
    
+
    
+Performance Impact:
    
+
    
+ None.
    
+
    
+Discussion:
    
+
    
+ This issue was discussed extensively in private mail during February 1992,
    
+ under the Subject line "implementation of a system class".
    
+ 
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242.htm new file mode 100644 index 00000000..116d9a14 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue METHOD-COMBINATION-ARGUMENTS:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue METHOD-COMBINATION-ARGUMENTS:CLARIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue METHOD-COMBINATION-ARGUMENTS:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242_w.htm new file mode 100644 index 00000000..a36f5215 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss242_w.htm @@ -0,0 +1,224 @@ + + + +CLHS: Issue METHOD-COMBINATION-ARGUMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue METHOD-COMBINATION-ARGUMENTS Writeup

    + +
    Issue:         METHOD-COMBINATION-ARGUMENTS
    
+
    
+References:    Draft ANSI CL specification p.6-71
    
+               88-002R p.2-34
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+               30-Apr-90, Version 2 by Moon (rewrite more clearly)
    
+               1-May-90, Version 3 by Moon (minor wording improvements)
    
+               4-May-90, Version 4 by Moon (update current practice)
    
+               6-Jun-90, Version 5 by Moon (add &WHOLE, update current practice)
    
+               8-Jun-90, Version 6 by Moon (include one-word amendment to &WHOLE
    
+                                            that was passed by X3J13 meeting)
    
+
    
+Problem description:
    
+
    
+  The :ARGUMENTS option to DEFINE-METHOD-COMBINATION is not specified very
    
+  clearly.  In particular, different generic functions using the type of
    
+  method combination being defined might accept different argument
    
+  patterns, so the lambda-list in the :ARGUMENTS option is unlikely to be
    
+  congruent to the generic function's lambda-list; the behavior when they
    
+  are not congruent should be clearly specified.  Such mismatches often
    
+  occur in practice, as in the example on p.6-74 where the generic function
    
+  would typically have more than one argument.
    
+
    
+  88-002R says:
    
+
    
+    If lambda-list is not congruent to the generic function's lambda-list,
    
+    additional ignored parameters are automatically inserted until it is
    
+    congruent.  Thus it is permissible for lambda-list to receive fewer
    
+    arguments than the number that the generic function expects.
    
+
    
+  The current ANSI CL draft says:
    
+  
    
+    If the arguments supplied to the generic function do not match
    
+    lambda-list, extra arguments are ignored and missing arguments are
    
+    defaulted to nil.  Thus it is permissible for lambda-list to receive
    
+    fewer arguments than the number of required arguments for the generic
    
+    function.
    
+
    
+  This is Symbolics issue #10.
    
+
    
+Proposal (METHOD-COMBINATION-ARGUMENTS:CLARIFY):
    
+
    
+  Replace the sentences quoted above with the following sentences.  Note
    
+  that these sentences immediately follow "When this form is evaluated
    
+  during execution of the effective method, its value is the corresponding
    
+  argument to the generic function."
    
+
    
+    This correspondence is computed by dividing the :ARGUMENTS lambda-list
    
+    and the generic function lambda-list into three sections: the required
    
+    parameters, the optional parameters, and the keyword/rest parameters.
    
+    The arguments supplied to the generic function for a particular call
    
+    are also divided into three sections; the required arguments section
    
+    contains as many arguments as the generic function has required
    
+    parameters, the optional arguments section contains as many arguments
    
+    as the generic function has optional parameters, and the keyword/rest
    
+    arguments section contains the remaining arguments.  Each parameter in
    
+    the required and optional sections of the :ARGUMENTS lambda-list
    
+    accesses the argument at the same position in the corresponding section
    
+    of the arguments.  If the section of the :ARGUMENTS lambda-list is
    
+    shorter, extra arguments are ignored.  If the section of the :ARGUMENTS
    
+    lambda-list is longer, excess required parameters are bound to forms
    
+    that evaluate to NIL and excess optional parameters are bound to their
    
+    initforms.  The keyword/rest parameters in the :ARGUMENTS lambda-list
    
+    access the keyword/rest section of the arguments.  If the :ARGUMENTS
    
+    lambda-list contains &KEY, it behaves as if it also contained
    
+    &ALLOW-OTHER-KEYS.
    
+
    
+    In addition, &WHOLE <var> can be placed first in the :ARGUMENTS
    
+    lambda-list.  It causes <var> to be bound to a form that evaluates to
    
+    a list of all of the arguments supplied to the generic function.  This
    
+    is different from &REST because it accesses all of the arguments, not
    
+    just the keyword/rest arguments.
    
+
    
+Examples:
    
+
    
+  The example in both documents is:
    
+  
    
+    ;;; Example of the use of :arguments
    
+    (define-method-combination progn-with-lock ()
    
+            ((methods ()))
    
+      (:arguments object)
    
+      `(unwind-protect
    
+           (progn (lock (object-lock ,object))
    
+                  ,@(mapcar #'(lambda (method)
    
+                                `(call-method ,method))
    
+                            methods))
    
+         (unlock (object-lock ,object))))
    
+
    
+  This would be used as follows:
    
+
    
+    (defgeneric send (channel buffer &optional (start 0) end)
    
+      (:method-combination progn-with-lock))
    
+
    
+    where each channel class has an object-lock method.
    
+
    
+  A variation that uses non-required arguments in :arguments is:
    
+  
    
+    (define-method-combination progn-with-lock-2 ()
    
+            ((methods ()))
    
+      (:arguments &key lock)
    
+      `(unwind-protect
    
+          (progn (lock ,lock)
    
+                 ,@(mapcar #'(lambda (method)
    
+                               `(call-method ,method))
    
+                           methods))
    
+         (unlock ,lock)))
    
+
    
+  This would be used as follows:
    
+
    
+    (defgeneric send (channel buffer
    
+                      &optional (start 0) end
    
+                      &key lock character-set-translation)
    
+      (:method-combination progn-with-lock-2))
    
+
    
+  The :lock keyword argument comes from the third section of the arguments,
    
+  which for this generic function starts at the fourth argument.
    
+
    
+  To show how lambda-list mismatch works:
    
+
    
+    If (:ARGUMENTS a b c) meets DEFGENERIC (x y &optional z), the value of
    
+    the value of C will be NIL, not the value of Z.
    
+
    
+  To show the use of &WHOLE:
    
+
    
+    (define-method-combination progn-with-gf-lock ()
    
+            ((methods ()))
    
+      (:arguments &whole args)
    
+      (:generic-function gf)
    
+      `(unwind-protect
    
+           (progn (lock-gf-args ,gf ,args) 
    
+                  ,@(mapcar #'(lambda (method)
    
+                                `(call-method ,method))
    
+                            methods))
    
+         (unlock (unlock-gf-args ,gf ,args))))
    
+
    
+Rationale:
    
+
    
+  This seems the only useful way to allow lambda-list-keywords in the
    
+  :ARGUMENTS lambda-list while solving the congruency problems.  It's likely
    
+  that this is not a change from what was originally intended, but just a
    
+  more precise way of describing it.  The examples show why both &WHOLE and
    
+  &REST are needed; using &REST in the progn-with-gf-lock example is not
    
+  consistent with using &KEY in the progn-with-lock-2 example.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0.1 (to be released in a few months) will implement the
    
+  proposal, possibly omitting &WHOLE.  In Symbolics Genera 8.0 the :ARGUMENTS
    
+  option to DEFINE-METHOD-COMBINATION does not work at all (it produces
    
+  incorrect code that does not compile).
    
+
    
+  TI Explorer release 6 has :ARGUMENTS in DEFINE-METHOD-COMBINATION, but
    
+  its status relative to the proposed clarification is unknown at present.
    
+
    
+  Recent versions of PCL support :ARGUMENTS in DEFINE-METHOD-COMBINATION
    
+  but do not seem to conform to the proposal -- I think PCL just
    
+  effectively appends "&rest ignore" to the :arguments lambda-list.
    
+
    
+  I did not discover any other CLOS implementations that support
    
+  :ARGUMENTS.
    
+
    
+Cost to Implementors:
    
+
    
+  This does not make supporting :ARGUMENTS more difficult.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  :ARGUMENTS will be specified in a way that can't be understood.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  :ARGUMENTS will be usable in the relatively rare circumstances where it
    
+  is needed.
    
+
    
+Esthetics:
    
+
    
+  A specification that can be understood is more esthetic than one that
    
+  cannot be.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243.htm new file mode 100644 index 00000000..92ba1aea --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue METHOD-INITFORM:FORBID-CALL-NEXT-METHOD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue METHOD-INITFORM:FORBID-CALL-NEXT-METHOD Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue METHOD-INITFORM:FORBID-CALL-NEXT-METHOD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243_w.htm new file mode 100644 index 00000000..f285bb3e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss243_w.htm @@ -0,0 +1,176 @@ + + + +CLHS: Issue METHOD-INITFORM Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue METHOD-INITFORM Writeup

    + +
    Date: Fri, 8 Jun 90 20:00 EDT
    
+From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
+Subject: Issue: METHOD-INITFORM (Version 5)
    
+To: X3J13@mcc.com
    
+Message-ID: <19900609000021.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
    
+
    
+This version contains the corrections to current practice noted at
    
+the X3J13 meeting today.
    
+
    
+METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD failed 0-11
    
+METHOD-INITFORM:FORBID-CALL-NEXT-METHOD passed 13-0
    
+
    
+Issue:         METHOD-INITFORM
    
+
    
+References:    88-002R p.2-12
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+               30-Apr-90, Version 2 by Moon (update current practice)
    
+               4-May-90, Version 3 by Moon (update discussion and current
    
+                                            practice)
    
+               5-Jun-90, Version 4 by Moon (update current practice)
    
+               8-Jun-90, Version 5 by Moon (update current practice)
    
+
    
+Problem description:
    
+
    
+  Should CALL-NEXT-METHOD and NEXT-METHOD-P be allowed in initforms for
    
+  optional and keyword parameters and &AUX variables of methods?  The
    
+  document currently allows them only in the body of a method, not in forms
    
+  embedded in the lambda-list, although it takes a close reading of the
    
+  document to discern this.
    
+
    
+  There are two proposals in this issue.
    
+
    
+  This is Symbolics issue #15.
    
+
    
+Proposal (METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD):
    
+
    
+  Expand the lexical scope of CALL-NEXT-METHOD and NEXT-METHOD-P to include
    
+  all forms in a method, including forms embedded in the lambda-list.
    
+
    
+Rationale:
    
+
    
+  This seems more natural and consistent.
    
+
    
+Proposal (METHOD-INITFORM:FORBID-CALL-NEXT-METHOD):
    
+          
    
+  The lexical scope of CALL-NEXT-METHOD and NEXT-METHOD-P includes only
    
+  forms in the body of a method.
    
+
    
+Rationale:
    
+
    
+  This is the status quo and is easier to implement.
    
+
    
+Examples:
    
+
    
+  (defmethod foo ((x myclass) &aux (y (call-next-method)))
    
+    (if (null y)
    
+        (zzz)
    
+        (list ':baz y)))
    
+  ;is briefer than
    
+  (defmethod foo ((x myclass))
    
+    (let ((y (call-next-method)))
    
+      (if (null y)
    
+          (zzz)
    
+          (list ':baz y))))
    
+
    
+  (defmethod countem ((x myclass) &optional (local (not (next-method-p))))
    
+    (let ((accum (if local 0 (call-next-method))))
    
+      (dolist (y (frobs x))
    
+        (incf accum y))
    
+      accum))
    
+  ;is briefer than
    
+  (defmethod countem ((x myclass) &optional (local nil local-p))
    
+    (let ((accum (if (if local-p local (not (next-method-p)))
    
+                     0 (call-next-method))))
    
+      (dolist (y (frobs x))
    
+        (incf accum y))
    
+      accum))
    
+
    
+  (defmethod jack-of-confusion ((x myclass))
    
+     (defmethod ace-of-confusion ((x myclass)
    
+                                  &optional (y (call-next-method)))
    
+       (borf x y))
    
+     (ace-of-confusion x))
    
+  ;In METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD, the default value for y
    
+  ;is the value returned by an ace-of-confusion method.
    
+  ;In METHOD-INITFORM:FORBID-CALL-NEXT-METHOD, the default value for y
    
+  ;is the value returned by a jack-of-confusion method.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0, Lucid 4.0.0 Beta-1, and recent versions of
    
+  PCL appear to implement METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD.
    
+  TI Explorer release 6 does not.
    
+  Apple and IIM implement METHOD-INITFORM:FORBID-CALL-NEXT-METHOD.
    
+
    
+  The first example does not actually work in Genera due to a bug.
    
+
    
+  Other CLOS implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+  In METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD, handling CALL-NEXT-METHOD and
    
+  NEXT-METHOD-P by simply wrapping a FLET or MACROLET around the body will
    
+  not work.  If they are called from forms in the lambda-list some
    
+  massaging of the lambda-list is necessary.  It's not very difficult,
    
+  though.
    
+
    
+  METHOD-INITFORM:FORBID-CALL-NEXT-METHOD has no cost to implementors.
    
+
    
+Cost to Users:
    
+
    
+  None for either proposal.
    
+
    
+Cost of non-adoption:
    
+
    
+  METHOD-INITFORM:FORBID-CALL-NEXT-METHOD forbids a programming technique
    
+  that users might find useful.  METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD
    
+  requires a little more work for implementors, who might have thought
    
+  they had finished their CLOS implementations by now.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  METHOD-INITFORM:FORBID-CALL-NEXT-METHOD avoids changing the status quo.
    
+  METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD provides a programming technique
    
+  that users might find useful.
    
+
    
+Esthetics:
    
+
    
+  METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD seems more uniform.
    
+
    
+Discussion:
    
+
    
+  Jeff Dalton suggests that the places where CALL-NEXT-METHOD is allowed
    
+  should be consistent with the places where RETURN from an implicit block
    
+  is allowed.  This probably supports FORBID-CALL-NEXT-METHOD.
    
+
    
+  Gregor Kiczales says he supports FORBID-CALL-NEXT-METHOD, but is not
    
+  adamant about it.  He thinks FORBID-CALL-NEXT-METHOD is more natural.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244.htm new file mode 100644 index 00000000..b552e225 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MUFFLE-WARNING-CONDITION-ARGUMENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MUFFLE-WARNING-CONDITION-ARGUMENT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MUFFLE-WARNING-CONDITION-ARGUMENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244_w.htm new file mode 100644 index 00000000..daf24fb6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss244_w.htm @@ -0,0 +1,72 @@ + + + +CLHS: Issue MUFFLE-WARNING-CONDITION-ARGUMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MUFFLE-WARNING-CONDITION-ARGUMENT Writeup

    + +
    Issue:		MUFFLE-WARNING-CONDITION-ARGUMENT
    
+Reference:	Draft 8.81
    
+		Issue: CONDITION-RESTARTS
    
+Category:	CHANGE/CLARIFICATION
    
+Edit History:	Version 1, 06/15/91, Kim Barrett
    
+		Version 2, 10/17/91, Steve Haflich, current practice
    
+
    
+Problem Description:
    
+
    
+ A user recently noted that MUFFLE-WARNING was left out of the list of restart
    
+ functions which take an optional condition argument.
    
+
    
+Proposal:
    
+
    
+ Add MUFFLE-WARNING to the list of restart functions which take an optional
    
+ condition argument.
    
+
    
+Editorial Impact:
    
+
    
+ None.  The editor included this change when merging the CONDITION-RESTARTS
    
+ proposal into the draft, with a comment stating that it was pending a formal
    
+ decision by the committee.
    
+
    
+Rationale:
    
+
    
+ Both authors of the CONDITION-RESTARTS proposal claim that leaving out
    
+ MUFFLE-WARNING was an oversight. 
    
+
    
+Current Practice:
    
+
    
+ IIM implements this proposal.
    
+
    
+ Lucid does not appear to have implemented CONDITION-RESTARTS yet.
    
+
    
+ Franz does not implement the optional argument to MUFFLE-WARNING.
    
+
    
+Discussion:
    
+
    
+ Note that Steele CLtL2 p.913 also conforms to this proposal without
    
+ comment, so users will indeed expect it. - smh 17oct91
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245.htm new file mode 100644 index 00000000..fc3c309d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245_w.htm new file mode 100644 index 00000000..57ee89b2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss245_w.htm @@ -0,0 +1,131 @@ + + + +CLHS: Issue MULTIPLE-VALUE-SETQ-ORDER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MULTIPLE-VALUE-SETQ-ORDER Writeup

    + +
    Issue:            MULTIPLE-VALUE-SETQ-ORDER
    
+References:       MULTIPLE-VALUE-SETQ, SYMBOL-MACROLET
    
+Related issues:   SYMBOL-MACROLET-SEMANTICS
    
+                  SETF-SUB-METHODS
    
+                  SETF-OF-VALUES
    
+Category:         CLARIFICATION
    
+Edit history:     V1,  1 Jun 1990, Sandra Loosemore
    
+                  V2,  6 Jun 1990, Sandra Loosemore
    
+                  V3, 12 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+Proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM extended
    
+MULTIPLE-VALUE-SETQ to allow symbols naming symbol-macros to appear in
    
+the "variables" argument to MULTIPLE-VALUE-SETQ.  The intent was that 
    
+this would be treated the same way as with SETQ or SETF.  However, the
    
+proposal did not address order-of-evaluation issues.
    
+
    
+When dealing only with variables, the order in which
    
+MULTIPLE-VALUE-SETQ performs the assignments is not relevant.  On the
    
+other hand, the storing form that results from applying the
    
+SETF method of the macroexpansion of a symbol-macro can be fully
    
+general.  It might include references to other variables or "places"
    
+named by other symbol-macros in the variable list.  The question is,
    
+which other variables or "places" in the list have already been set
    
+when the storing form is evaluated?
    
+
    
+For example, consider something like
    
+
    
+  (defun foo (v i)
    
+    (symbol-macrolet ((element  (svref v i)))
    
+      (multiple-value-setq (v element i) ...)))
    
+
    
+Does the value corresponding to "element" get stored in the new
    
+or old value of the vector "v", at the new or old value of the index
    
+"i"?
    
+
    
+
    
+Proposal (MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES):
    
+
    
+  Clarify that
    
+
    
+      (multiple-value-setq (<place1> ... <placen>) <value-producing-form>)
    
+
    
+  is exactly equivalent to
    
+
    
+      (values (setf (values <place1> ... <placen>) <value-producing-form>))
    
+
    
+  under proposal SETF-OF-VALUES:ADD, with the additional constraint that 
    
+  each of the <placei> must be a symbol.
    
+
    
+  Rationale:
    
+
    
+    Assuming VALUES is added as a SETF place, it is obvious to define
    
+    of MULTIPLE-VALUE-SETQ (or MULTIPLE-VALUE-SETF) in terms of it.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera 8.0 does both assignments and evaluation of place
    
+  subforms in left-to-right order.
    
+  Utah Common Lisp appears to do the assignments (and evaluation of 
    
+  place subforms) right-to-left.
    
+  Chestnut's Lisp-to-C translator implements proposal SETF-OF-VALUES.
    
+ 
    
+
    
+Cost to Implementors:
    
+
    
+  Assuming proposal SETF-OF-VALUES:ADD is adopted, minor.
    
+
    
+Cost to Users:
    
+
    
+  Probably nobody depends on any particular behavior here, since
    
+  symbol-macros are a relatively new addition to the language.  This
    
+  definition of MULTIPLE-VALUE-SETQ is fully upward-compatible with its
    
+  definition in CLtL.
    
+
    
+Cost of non-adoption:
    
+
    
+  This part of the language specification remains vague.
    
+
    
+Performance impact:
    
+
    
+  The situation probably doesn't crop up enough for it to have a 
    
+  significant impact.
    
+
    
+Benefits:
    
+
    
+  This part of the language specification becomes less vague.
    
+
    
+Esthetics:
    
+
    
+  Any code that depends on any particular order is likely to be
    
+  pretty nasty.  However, defining MULTIPLE-VALUE-SETQ in terms of
    
+  SETF of VALUES seems like the right approach to me.
    
+
    
+Discussion:
    
+
    
+  An earlier version of this issue (with three different proposals) was
    
+  discussed at the June 90 meeting.
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246.htm new file mode 100644 index 00000000..4c97c96b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246_w.htm new file mode 100644 index 00000000..69f3ec25 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss246_w.htm @@ -0,0 +1,118 @@ + + + +CLHS: Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES Writeup

    + +
    Issue:             MULTIPLE-VALUES-LIMIT-ON-VARIABLES
    
+References:        MULTIPLE-VALUES-LIMIT,
    
+                   MULTIPLE-VALUE-SETQ, MULTIPLE-VALUE-BIND,
    
+                   NTH-VALUE
    
+Related issues:    none
    
+Category:          CLARIFICATION
    
+Edit history:      v1, 13 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The constant MULTIPLE-VALUES-LIMIT is defined in CLtL as the upper
    
+  exclusive bound on the number of values that may be returned from
    
+  a function.  Does this limit also apply to the number of variables
    
+  that may be bound or assigned by MULTIPLE-VALUE-BIND or 
    
+  MULTIPLE-VALUE-SETQ?  Or are the excess variables simply given values
    
+  of NIL?
    
+
    
+  There are two proposals, UNDEFINED and NIL.
    
+
    
+Proposal (MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED):
    
+
    
+  Clarify that MULTIPLE-VALUES-LIMIT applies to the number of variables
    
+  that may be bound or assigned by MULTIPLE-VALUE-BIND or 
    
+  MULTIPLE-VALUE-SETQ and the index argument to NTH-VALUE, as well 
    
+  as to the number values that can actually be returned.
    
+
    
+  Rationale:
    
+
    
+    It's conceivable that these forms for accessing multiple values 
    
+    could be implemented in such a way that they break if you try to
    
+    access values beyond MULTIPLE-VALUES-LIMIT.
    
+
    
+
    
+Proposal (MULTIPLE-VALUES-LIMIT-ON-VARIABLES:NIL):
    
+
    
+  Clarify that MULTIPLE-VALUES-LIMIT applies only to the number of values
    
+  that can actually be returned, and not to the number of variables that
    
+  may be bound or assigned by MULTIPLE-VALUE-BIND or MULTIPLE-VALUE-SETQ
    
+  or the index argument to NTH-VALUE.  As usual, NIL if there are not
    
+  enough values actually returned.
    
+
    
+  Rationale:
    
+
    
+    There are ways of implementing these forms for accessing multiple
    
+    values in such a way that they don't break if you try to access
    
+    values beyond MULTIPLE-VALUES-LIMIT.
    
+
    
+Current Practice:
    
+
    
+  I don't know.
    
+
    
+Cost to Implementors:
    
+
    
+  For proposal UNDEFINED, none.
    
+  For proposal NIL, more care needs to be taken in implementing multiple
    
+  values.
    
+
    
+Cost to Users:
    
+
    
+  For proposal NIL, none.
    
+  For proposal UNDEFINED, loss of portability for some programs (probably
    
+    very rare).
    
+
    
+Cost of non-adoption:
    
+
    
+  Confusion about what implementation techniques for multiple values are
    
+  valid.
    
+
    
+Performance impact:
    
+
    
+  Hard to say.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Proposal NIL is probably better from a purely theoretical point of view,
    
+  since it doesn't complicate the language by imposing arbitrary limits
    
+  on programs.
    
+
    
+Discussion:
    
+
    
+  Loosemore prefers proposal NIL, as long as it doesn't cause problems
    
+  for implementors.
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247.htm new file mode 100644 index 00000000..a6dbdf11 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue NINTERSECTION-DESTRUCTION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue NINTERSECTION-DESTRUCTION Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue NINTERSECTION-DESTRUCTION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_m.htm new file mode 100644 index 00000000..afdefd01 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue NINTERSECTION-DESTRUCTION Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue NINTERSECTION-DESTRUCTION Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_w.htm new file mode 100644 index 00000000..7a11250e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss247_w.htm @@ -0,0 +1,219 @@ + + + +CLHS: Issue NINTERSECTION-DESTRUCTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue NINTERSECTION-DESTRUCTION Writeup

    + +
    Issue:        NINTERSECTION-DESTRUCTION
    
+Document:     X3J13/91-412
    
+Reference:    CLtL-II, p.429
    
+              Issue REMF-DESTRUCTION-UNSPECIFIED
    
+              Draft 10.156 (X3J13/91-103)
    
+              Draft 12.24 (X3J13/92-102)
    
+              Barrett's public review comment #24 (X3J13/92-2524)
    
+Category:     CLARIFICATION
    
+Edit History: Version 1, 22-Dec-91, Kim Barrett
    
+              Version 2, 19-Apr-92, Kim Barrett
    
+                (Two proposals, note confused status)
    
+              Version 3, 20-Apr-92, Kim Barrett (KMP's comments)
    
+              Version 4, 7-Jun-92, Kim Barrett
    
+Status:       Confusion!  One of the proposals (REVERT or PERMIT) was passed at
    
+              the 12/91 meeting, but there is disagrement as to which.
    
+              Draft 12.24 (X3J13/92-102) was written assuming that REVERT was
    
+              the passed proposal.
    
+              Barrett now asks us to reconsider proposal PERMIT.
    
+	      Proposal REVERT passed 11-0 on letter ballot 93-302;
    
+              on same ballot, proposal PERMIT failed 2-6.
    
+
    
+
    
+Problem Description:
    
+
    
+ Issue REMF-DESTRUCTION-UNSPECIFIED permits NINTERSECTION to modify either list
    
+ argument, contrary to the description of NINTERSECTION in CLtL, which
    
+ explicitly states that the second argument (list2) is not destroyed.  It is
    
+ questionable whether this change was intentional or not, especially since
    
+ REMF-DESTRUCTION-UNSPECIFIED was categorized as a clarification rather than a
    
+ change.  
    
+
    
+Proposal (NINTERSECTION-DESTRUCTION:REVERT):
    
+
    
+ Affirm the wording from CLtL, prohibiting NINTERSECTION from modifying the
    
+ second (list2) argument.
    
+
    
+Proposal (NINTERSECTION-DESTRUCTION:PERMIT):
    
+
    
+ Affirm the wording from REMF-DESTRUCTION-UNSPECIFIED, permitting NINTERSECTION
    
+ to modify either list argument.
    
+
    
+Editorial Impact:
    
+
    
+ For REVERT:
    
+   None.  The 12.24 draft assumes that REVERT was accepted.
    
+
    
+ For PERMIT:
    
+   Small.  The two-line paragraph on p.14-51 of X3J13/92-102 describing the
    
+   difference between NINTERSECTION and INTERSECTION would have to be changed
    
+   slightly, specifying that both the LIST-1 and LIST-2 arguments may be
    
+   destroyed, rather than only permitting LIST-1 to be destroyed and requiring
    
+   that LIST-2 be preserved.
    
+
    
+Rationale:
    
+
    
+ For REVERT:
    
+   The intent of REMF-DESTRUCTION-UNSPECIFIED was not to change side-effect
    
+   behavior, but to tack down places where we had all pretty much agreed on
    
+   side-effect behavior but never spelled it out.  This was a case where CLtL
    
+   had spelled things out, and which was probably changed unintentionally.
    
+   Some older programs may depend on this argument not getting bashed, and it
    
+   would be a shame to have some implementation decide to bash it.
    
+
    
+   Don't make an apparently unintentional incompatible change.
    
+
    
+ For PERMIT:
    
+   Affirm the more recent decision, which went through more than two years of
    
+   discussion before finally being accepted.  The intent of
    
+   REMF-DESTRUCTION-UNSPECIFIED was to permit greater implementation freedom
    
+   in order to achieve better performance; prohibiting the destruction of one
    
+   of the lists may have a negative performance impact.
    
+
    
+   A ``destructive'' function that is only permitted to destroy one of it's two
    
+   arguments (with no rationale for which argument may be destroyed and which
    
+   may not) is confusing; this is the only case of such.
    
+
    
+Examples:
    
+
    
+Current Practice:
    
+
    
+ Apple Macintosh Common Lisp 2.0 obeys REVERT.
    
+
    
+ Symbolics Genera 8.2 (and before) obeys REVERT.
    
+
    
+Cost to Implementors:
    
+
    
+ None for PERMIT.
    
+
    
+ If REVERT is adopted, implementations that have been tracking the passed
    
+ cleanups and have taken advantage of the permission granted by
    
+ REMF-DESTRUCTION-UNSPECIFIED in this case will have to change.  It may require
    
+ a significant amount of work to achieve similar performance.  Implementations
    
+ that pre-existed the acceptance of that proposal may be able to revert to an
    
+ older source that obeyed the CLtL1 restriction.
    
+
    
+Cost to Users:
    
+
    
+ For REVERT, no semantic cost for users; there may be a performance cost.
    
+
    
+ For PERMIT, an incompatible change.  In some cases it may be quite difficult
    
+ to determine whether a call to NINTERSECTION can safely destroy the second
    
+ argument.
    
+
    
+Performance Impact:
    
+
    
+ There may be a negative performance impact in choosing REVERT over PERMIT.
    
+
    
+ The ``obvious'' implementation is to iterate over the elements of one of the
    
+ lists and if that element appears in the other list then collect it, reusing
    
+ storage from the first list in the collection process.  If the length of the
    
+ first list is less than the length of the second, this algorithm is
    
+ asymptotically as much as a factor of two slower than if the lists were
    
+ exchanged.  Thus, by preventing such a choice of which list to destroy, REVERT
    
+ might result in slower performance for NINTERSECTION.
    
+
    
+Discussion:
    
+
    
+ The status of this issue is unclear.
    
+
    
+    Date: Wed, 22 Jan 92 13:25:51 EST
    
+    From: kab (Kim Barrett)
    
+    To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    
+    Subject: Re: Issue: NINTERSECTION-DESTRUCTION (Version 1)
    
+
    
+    >     Date: Sun, 22 Dec 1991 14:48 EST
    
+    >     From: kab@cambridge.apple.com (Kim Barrett)
    
+    > 
    
+    >     Does this look ok to you?
    
+    > 
    
+    > No! My meeting notes say:
    
+    > 
    
+    >  "Move to say list-2 not modified.  PASS 8-2"
    
+    > 
    
+    > Lest you think I mis-noted this, I certainly remember lobbying for a
    
+    > position which said that REMF-DESTRUCTION-UNSPECIFIED had made the
    
+    > change unintentionally, and that we should revert the wording.  Had I
    
+    > wanted to retain the wording, I would not have raised the issue.
    
+
    
+    Looks like we have a problem here.  My notes just say
    
+
    
+      "NINTERSECTION-DESTRUCTION passed 8-2"
    
+
    
+    which is not very helpful.  My memory says that we voted to affirm the
    
+    words in the draft (as stated in the draft writeup I sent you), but
    
+    obviously I could be mistaken.  Unfortunately, the minutes are also
    
+    ambiguous:
    
+
    
+      REMF-DESTRUCTION-UNSPECIFIED
    
+      (In document 91-003b.)
    
+      Vote: 7 - 2. Passed.
    
+
    
+    There isn't any such thing in the specified document.  (I pointed this out
    
+    to Jan after the last version of minutes was mailed out).
    
+
    
+ The reference to REMF-DESTRUCTION-UNSPECIFIED in 91-003b was to the following
    
+ message:
    
+
    
+    Date: Tue, 16 Jul 1991 17:33-0400
    
+    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    
+    Subject: possible issue NINTERSECTION-DESTRUCTION
    
+    To: kab@chestnut.com
    
+    Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, barmar@think.com, GLS@Think.COM
    
+
    
+    [Addressed to Kim because he's been keeping a list of my little nitpicks
    
+     and figuring out which shoudl be written up and distributed.  Other
    
+     relevant individuals cc'd in case they have comments.]
    
+
    
+    One of Barmar's reviews turned up the following...
    
+
    
+    CLtL said plainly that list-2 was not destroyed by NINTERSECTION.
    
+
    
+    REMF-DESTRUCTION-UNSPECIFIED says quite clearly that it might be, even
    
+    though I think the intent of REMF-DESTRUCTION-UNSPECIFIED was mainly to
    
+    clarify points left vague by CLtL, not to introduce new things that were
    
+    possible to destroy.
    
+
    
+    The current draft is inconsistent in that in different places, it says
    
+    things that are consistent either with CLtL or with the cleanup issue.
    
+
    
+    The status quo is well-defined, so if no vote is taken I will believe
    
+    REMF-DESTRUCTION-UNSPECIFIED.   But I don't think that people realized
    
+    they were making an incompatible change in this particular case, so I
    
+    wonder if the issue should be raised at X3J13 for confirmation.
    
+
    
+    As an aside, I note that CLtL2's wording also implies that this was a
    
+    "clarification" without making it apparent that an actual change had
    
+    occurred.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss248.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss248.htm new file mode 100644 index 00000000..67ea1872 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss248.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue NINTERSECTION-DESTRUCTION:REVERT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue NINTERSECTION-DESTRUCTION:REVERT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue NINTERSECTION-DESTRUCTION:REVERT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249.htm new file mode 100644 index 00000000..4b7faf9d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249_w.htm new file mode 100644 index 00000000..eec27351 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss249_w.htm @@ -0,0 +1,84 @@ + + + +CLHS: Issue NOT-AND-NULL-RETURN-VALUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue NOT-AND-NULL-RETURN-VALUE Writeup

    + +
    Forum:          Public Review
    
+Issue:          NOT-AND-NULL-RETURN-VALUE
    
+References:     Margolin's public review comment #6
    
+		Pitman's public review comment #4
    
+Category:       CHANGE
    
+Edit history:   12 Sept 1993, Version 1 by Loosemore
    
+Status:		Proposal X3J13-MARCH-1993 passed 6-2 at the March 1993 meeting
    
+
    
+
    
+Problem description:
    
+
    
+  Due to an editing error, the semantics of NOT and NULL have been
    
+  changed to say that they return true/false rather than T/NIL.  This
    
+  change was accidentally introduced; there was no foundation for it in
    
+  any X3J13 vote.
    
+
    
+
    
+Proposal (NOT-AND-NULL-RETURN-VALUE:X3J13-MARCH-1993):
    
+
    
+  Restore the CLtL semantics.
    
+
    
+Rationale:
    
+
    
+  This is what users expect.  It supports idioms such as 
    
+    (EQ (NOT (NOT X)) 'T)
    
+  and 
    
+    (DEFUN BOOLEAN-EQUAL-P (X Y) (EQ (NOT X) (NOT Y)))
    
+
    
+Current practice:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to users:
    
+
    
+  None.
    
+
    
+
    
+Aesthetics:
    
+
    
+
    
+Editorial impact:
    
+
    
+
    
+Discussion:
    
+
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250.htm new file mode 100644 index 00000000..00ffca36 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue NTH-VALUE:ADD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue NTH-VALUE:ADD Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue NTH-VALUE:ADD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250_w.htm new file mode 100644 index 00000000..8de901a0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss250_w.htm @@ -0,0 +1,142 @@ + + + +CLHS: Issue NTH-VALUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue NTH-VALUE Writeup

    + +
    Status: Passed, as amended, Jan 89 X3J13
    
+Issue:         NTH-VALUE
    
+References:    Multiple values, pp. 133-139
    
+Category:      ADDITION
    
+Edit history:  16-Aug-88, Version 1 by Pierson
    
+               01-Oct-88, Version 2 by Pitman (minor edits)
    
+               5-Oct-88, Version 3 by Masinter
    
+			(add Current Practice as per Gray)
    
+                8-Dec-88, Version 4 by Masinter
    
+			(add comments to discussion)
    
+                17-Mar-89, Version 5, Masinter (as amended)
    
+
    
+Problem description:
    
+
    
+  The set of operations on multiple values in Common Lisp is incomplete:
    
+
    
+  The only ways to retrieve just one of several return values (other than
    
+  the first) are:
    
+
    
+   - Bind several variables and then ignore all but one.
    
+     eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
    
+     This is somewhat cumbersome to write and not perspicuous.
    
+
    
+   - Get a list of all return values and select from that.
    
+     eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
    
+     This is somewhat cumbersome, not perspicuous, and creates
    
+     needless garbage.
    
+
    
+Proposal (NTH-VALUE:ADD):
    
+
    
+  Add a new macro NTH-VALUE, described as
    
+
    
+  NTH-VALUE n form                                               [Macro]
    
+
    
+  N must be a non-negative integer.
    
+  Evaluates the FORM and returns the Nth value returned by the form as
    
+  a single value.  N is 0-based, i.e. the first returned value is 
    
+  value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
    
+  evaluated, in left-to-right order.
    
+
    
+  NTH-VALUE returns NIL if N is greater than or equal to the number
    
+  of values returned by FORM.
    
+
    
+Examples:
    
+
    
+  With this proposal MOD could be defined as:
    
+
    
+  (DEFUN MOD (NUMBER DIVISOR)
    
+    (NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
    
+
    
+  The same code would currently be:
    
+
    
+  (DEFUN MOD (NUMBER DIVISOR)
    
+    (MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
    
+        (FLOOR NUMBER DIVISOR)
    
+      (DECLARE (IGNORE DIVIDEND))
    
+      REMAINDER))
    
+
    
+Rationale:
    
+
    
+  This corrects the stated problem.
    
+
    
+Current practice:
    
+
    
+  The TI Explorer and LMI Lambda have this feature.
    
+ 
    
+Cost to Implementors:
    
+
    
+  Writing the macro version is fairly straightforward.
    
+
    
+  Some will choose to implement compiler hooks so that code written with
    
+  NTH-VALUE will be as efficient as possible. This may involve some
    
+  additional work, but presumably nothing major.
    
+
    
+Cost to Users:
    
+
    
+  This is an upward-compatible change.
    
+
    
+Cost of non-Adoption:
    
+
    
+  The occassional code where this comes up may be one or more of 
    
+  clumsier to write, more difficult to read, or less efficient.
    
+  (The feature is rarely used in implementations that have it.)
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  While it does add another function to the language it removes
    
+  some need for the hairier multiple-value forms.
    
+
    
+Discussion:
    
+
    
+  Pitman proposed this in the very late pre-CLtL days. It was
    
+  rejected then because it was too late in the cycle.
    
+
    
+  There was not strong sentiment for including this feature
    
+  in Common Lisp, but no active opposition.
    
+
    
+Comments at the October 1988 X3J13 meeting:
    
+
    
+"Trivial, gratuitous."
    
+
    
+"Not trivial -- allows index computation. Hard to do this
    
+ in a portable, efficient way."
    
+
    
+"Says he has an NTH-VALUE macro for a portable system that he
    
+ uses (which exploits the computed index feature) and that it's
    
+ a gross kludge in one implementation to make it efficient."
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251.htm new file mode 100644 index 00000000..de4d881f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue OPTIMIZE-DEBUG-INFO:NEW-QUALITY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue OPTIMIZE-DEBUG-INFO:NEW-QUALITY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue OPTIMIZE-DEBUG-INFO:NEW-QUALITY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251_w.htm new file mode 100644 index 00000000..434defa3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss251_w.htm @@ -0,0 +1,92 @@ + + + +CLHS: Issue OPTIMIZE-DEBUG-INFO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue OPTIMIZE-DEBUG-INFO Writeup

    + +
    Issue:		OPTIMIZE-DEBUG-INFO
    
+References:	CLtL p. 160
    
+Category:	ADDITION
    
+Edit History:   V1  9 Sep 1988, David Gray (initial version)
    
+                V2 19 Sep 1988, David Gray (delete first alternative)
    
+ 
    
+Problem Description:
    
+
    
+  The OPTIMIZE declaration provides a way to tell the compiler how important
    
+  various qualities are in order to guide which optimizations are done.
    
+  There is another quality, however, that is not mentioned, but is an
    
+  important consideration for the compiler:  how much information
    
+  should be included in the object code to facilitate debugging.  This
    
+  includes both annotation added to enable a debugger to display more
    
+  information to the user, and also suppression of optimizations that would
    
+  confuse debugging by making it harder to connect the object code with the
    
+  source code.
    
+
    
+Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:
    
+
    
+  In the description of the OPTIMIZE declaration, add an additional quality
    
+  named DEBUG, described as "ease of debugging".
    
+ 
    
+ Rationale:
    
+
    
+  Since ease of debugging is an issue that the user will be concerned with,
    
+  and is an issue that the compiler needs to consider, this provides a clear
    
+  way for the user to control the amount of debugging information placed in
    
+  the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
    
+  as possible".
    
+ 
    
+ Current Practice:
    
+
    
+  No current implementation of this is known.
    
+ 
    
+ Cost to implementors:
    
+
    
+  All would have to update their handling of OPTIMIZE declarations to accept
    
+  the new quality.
    
+ 
    
+ Cost to users:
    
+
    
+  One more little feature to learn.  Some problems may result from the
    
+  addition of the symbol DEBUG to the LISP package.
    
+  
    
+ Benefits:
    
+
    
+  Provides users a standard way to control the interaction between
    
+  the compiler and debugger, and saves implementors from having to invent
    
+  implementation-dependent solutions.
    
+
    
+ Costs of Non-Adoption: 
    
+
    
+  Continued confusion about how debug information should be controlled.
    
+ 
    
+Discussion:
    
+
    
+  Concern has been raised that there is already a problem with the
    
+  non-orthogonality of SPEED, SAFETY, and SPACE that would be made even
    
+  worse with DEBUG added, since users tend to be perplexed by the
    
+  interactions of these qualities. 
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252.htm new file mode 100644 index 00000000..2387d761 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue PACKAGE-CLUTTER:REDUCE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PACKAGE-CLUTTER:REDUCE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PACKAGE-CLUTTER:REDUCE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252_w.htm new file mode 100644 index 00000000..99f67f08 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss252_w.htm @@ -0,0 +1,271 @@ + + + +CLHS: Issue PACKAGE-CLUTTER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PACKAGE-CLUTTER Writeup

    + +
    Status:       Accepted v8 (superseding v7) on 15-0 vote, Jun-90
    
+Issue:        PACKAGE-CLUTTER
    
+References:   LISP, USER, SYSTEM packages (p181)
    
+
    
+Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE, 
    
+		MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
    
+		FUNCTION-NAME
    
+		 
    
+Category:     CHANGE/CLARIFICATION
    
+
    
+Edit history: 07-Jul-88, Version 1 by Pitman
    
+		  23-Sep-88, Version 2 by Masinter
    
+		  5-Oct-88, Version 3 by Masinter
    
+		  7-Oct-88, Version 4 by Masinter (response to KMP)
    
+		   8-Dec-88, Version 5 by Masinter
    
+			(add property lists)
    
+		  12-Dec-88, Version 6 by Masinter (respond to comments)
    
+		  17-Mar-89, Version 7 by Masinter (as amended Jan 89 X3J13)
    
+		   3-Jan-90, Version 8 by Barrett (add more cases)
    
+
    
+Problem Description:
    
+
    
+  CLtL specifies that
    
+
    
+   ``The package named LISP contains the primitives of
    
+     the Common Lisp system. Its external symbols include
    
+     all of the user-visible functions and global variables
    
+     that are present in the Common Lisp system, such as
    
+     CAR, CDR, *PACKAGE*, etc. Almost all other packages will
    
+     want to use LISP so that these symbosl will be accessible
    
+     without qualification.''
    
+
    
+  It specifies "all" but not "all and only".
    
+
    
+  Some implementations place their extensions in the Lisp package.
    
+  Nothing in CLtL explicitly prohibits this, but it leads to problems 
    
+  in general.  For example:
    
+
    
+  - A user defining a function by a name not mentioned in CLtL may be
    
+    surprised to clobber a system function in some implementations
    
+
    
+  - In one particular implementation, the variable HELP was a system
    
+    constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
    
+    signalled a correctable error (asking what variable to bind
    
+    instead of HELP :-).
    
+
    
+Proposal (PACKAGE-CLUTTER:REDUCE):
    
+
    
+  Specify that, not only must the LISP package contain at least all of the
    
+  symbols listed in the standard, it will have no other external symbols.
    
+  (The LISP package may have additional internal symbols.)
    
+
    
+  External symbols of the LISP package may have function, macro, or special
    
+  form definitions, setf method definition, top level value or SPECIAL
    
+  proclamations, or type definitions only if explicitly permitted in the
    
+  specification.  That is, a program is valid Common Lisp if it assumes that
    
+  this is true; for example, FBOUNDP will be false for all external symbols of
    
+  the LISP package except those documented to be functions, macros or special
    
+  forms; no setf method will be defined for such a symbol, and FBOUNDP on
    
+  (SETF symbol) will be false; BOUNDP will be false for all those except those
    
+  documented to be variables, and portable programs can use symbols in the
    
+  LISP package as local lexical variables with the presumption that the
    
+  variables are not proclaimed special, except for those variables specified
    
+  as constants or variables.
    
+
    
+  No external symbols of the LISP package may have properties with
    
+  property indicators that are either external symbols of packages
    
+  defined in the standard or are otherwise accessible in the USER
    
+  package.
    
+
    
+  This proposal constrains implementations as to what their
    
+  initial package configuration must be. That is, valid programs
    
+  can assume that the conformal Lisp implementation will not
    
+  have prohibited properties.  The proposal LISP-SYMBOL-REDEFINITION
    
+  addresses the converse; that is, what user programs are allowed
    
+  to do.
    
+
    
+  Eliminate the requirement that the initial Common Lisp system 
    
+  have a package named "SYSTEM". Specify that implementations may
    
+  have several other packages available, that these should be
    
+  documented. If it is appropriate, the standard might contain
    
+  as an example that implementations might have a package named
    
+  "SYSTEM".
    
+
    
+  Clarify that the "USER" package may have additional symbols interned
    
+  within it and that it may :USE other implementation-specific packages.
    
+
    
+ 
    
+ Examples:
    
+
    
+  #1: The symbol HELP may not be on the LISP package because it is not
    
+      mentioned in CLtL.
    
+
    
+  #2: The symbol VARIABLE is specified to be on the LISP package (because
    
+      it is a valid second argument to the DOCUMENTATION function). Since
    
+      it is not defined as a variable, type, or function, however, it will
    
+      not initially be bound, defined as a type, or defined as a function,
    
+      macro or special form.
    
+
    
+Rationale:
    
+
    
+  If extra symbols are permitted in the LISP package, users may be surprised
    
+  by relationships between the LISP package and other packages which they
    
+  did not expect, or may be surprised by functionality that they did not
    
+  expect. The degenerate case is:
    
+
    
+   (DEFCONSTANT LISP:A 'YOU-LOSE)
    
+   (DEFCONSTANT LISP:B 'YOU-LOSE)
    
+   (DEFCONSTANT LISP:C 'YOU-LOSE)   
    
+   ...
    
+   (DEFCONSTANT LISP:AA 'YOU-LOSE)
    
+   (DEFCONSTANT LISP:AB 'YOU-LOSE)
    
+   (DEFCONSTANT LISP:AB 'YOU-LOSE)
    
+   ...etc.
    
+
    
+  Given such an implementation, even things like (LAMBDA (X) X) are not
    
+  valid because they attempt to bind "system constants". It is necessary
    
+  that the programmer be able to know for sure that an arbitrary name is
    
+  "free for use" and best way to conveniently assure this is to require
    
+  that the LISP package be unadulterated.
    
+
    
+  As for the additional definitions, there are situations where additional
    
+  definitions would cause a problem. For example, if a symbol on the Lisp
    
+  package were declared as a special variable even though that value was
    
+  not mentioned in the standard, that variable would behave incorrectly when
    
+  used as a lexical variable. Similarly, if a symbol in the lisp package
    
+  were defined as an implementation-dependent special form, problems might
    
+  result if a user redefined or even bound (as by FLET or MACROLET) that
    
+  name.
    
+
    
+  The LISP package is the foothold from which portable programs establish
    
+  their desired environment. Careful control is desirable to make sure
    
+  everyone is starting off on the right foot.
    
+
    
+Current Practice:
    
+
    
+  Some implementations have been known to add additional symbols (usually
    
+  functional and/or variable extensions) to the LISP package.
    
+
    
+  Several implementations have restricted the LISP package to only contain
    
+  those symbols in CLtL. (The exact set was difficult to extract because not all
    
+  LISP package symbols appeared in the index of CLtL.)
    
+
    
+  Even in those implementations that have only the prescribed symbols in CLtL,
    
+  there can be extra definitions for those symbols. For example, in Symbolics Genera,
    
+  the symbols EVALHOOK, ROOM, and APPLYHOOK
    
+  are spuriously defined as special variables, and the symbol LAMBDA is defined
    
+  as a macro. 
    
+
    
+Performance Impact:
    
+
    
+  None
    
+
    
+Cost to Implementors:
    
+
    
+  The actual cost of moving the symbols out of the LISP package in cases
    
+  where they are not already gone is quite small. However, if any
    
+  implementation really has to do this, it may have a number of suppositions
    
+  about what is in what package, and the changes could potentially be extensive.
    
+
    
+Cost to Users:
    
+
    
+  This change is upward compatible with any portable program, but users
    
+  of a particular implementation's extensions may be forced to find their
    
+  functions in a different package, so there may be a measurable practical
    
+  cost.
    
+
    
+  In many cases where an extension symbol FOO is simply expected to have
    
+  been directly available (due to :USE "LISP"), it will work to just just
    
+  do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
    
+  declared.
    
+
    
+  More likely the extension symbols would be moved to one or more
    
+  extensions packages, e.g. ACME-COMMON-LISP, so user packages in which
    
+  the extensions were desired could simply :USE the extensions package(s).
    
+  Implementations might want to use this way of conforming with this
    
+  proposal in order to minimize cost to users.
    
+
    
+  In many cases where an extension symbol FOO is used by explicit package
    
+  prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
    
+  even `LISP:' to find the cases.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The potential for the LISP package to be adulterated and for supposedly
    
+  portable programs to have difficulty getting a foothold in some
    
+  implementations will be `noticeably non-zero'.
    
+
    
+Benefits:
    
+
    
+  Portability of some programs will be enhanced.
    
+
    
+Aesthetics:
    
+
    
+  This change probably supports the naive expectation of most programmers
    
+  writing portable code.
    
+
    
+Discussion:
    
+
    
+  This proposal basically affects what implementors are allowed to do;
    
+  it says that portable programs can rely on a standard initial package
    
+  structure with the same symbols in it. A separate proposal, 
    
+  LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
    
+  programs as far as redefining LISP symbols.
    
+
    
+  Whether the USER package may contain symbols other than those 
    
+  specified in the standard was controversial.  The smart programmer
    
+  of portable code will never rely on the contents of the
    
+  USER package. However, if someone wants a completely empty 
    
+  package that uses only Lisp, it's easy and portable to create one.
    
+
    
+  While it would improve portability slightly to disallow additional internal
    
+  symbols in the LISP package (since it affects what DO-SYMBOLS will do)
    
+  explicitly prohibiting a common practice didn't seem like the best way
    
+  to discourage a possibly troublesome implementation technique. 
    
+
    
+  Implementors should be especially careful about accidentally 
    
+  exporting unwanted additional definitions for symbols,e.g., a variable
    
+   definition for EVALHOOK which might show through because of
    
+   an unintended name collision.
    
+
    
+  It is likely that the recently included portions of the standard (CLOS and
    
+  the signal mechanism) will reside in their own packages. These externally
    
+  defined packages should have the same constraints as outlined for
    
+  the LISP package here.
    
+
    
+  There has been a suggestion that vendor-specific extensions should
    
+  be placed in a package named like ACME-COMMON-LISP for the "Acme"
    
+  company. 
    
+
    
+  A registry of packages (as well as features, modules and other global
    
+  names) would be useful, although probably not a part of the language
    
+  standard, per se.
    
+
    
+  Barrett and Pitman support superseding version 7 with version 8.
    
+
    
+----------
    
+Additional comments on the write-up:
    
+
    
+ "This is clearly correct." --Moon (9 Jan 90)
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253.htm new file mode 100644 index 00000000..9ec4a533 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue PACKAGE-DELETION:NEW-FUNCTION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PACKAGE-DELETION:NEW-FUNCTION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PACKAGE-DELETION:NEW-FUNCTION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253_w.htm new file mode 100644 index 00000000..30fe7a6c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss253_w.htm @@ -0,0 +1,235 @@ + + + +CLHS: Issue PACKAGE-DELETION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PACKAGE-DELETION Writeup

    + +
    Forum:	Cleanup
    
+Issue:        PACKAGE-DELETION
    
+References:   Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
    
+Category:     ADDITION
    
+Edit history: 30-Sep-88, Version 1 by Pitman
    
+	      01-Oct-88, Version 2 by Pitman
    
+	      04-Oct-88, Version 3 by Pitman
    
+		(provide for correctable errors in some cases)
    
+	      07-Oct-88, Version 4 by JonL
    
+		21-Nov-88, Version 5 by Masinter
    
+
    
+
    
+Problem Description:
    
+
    
+  There is no way to get rid of a package in Common Lisp.
    
+
    
+  This absence makes interactive development work tricky in some
    
+  implementations. If a package is accidentally built incorrectly, the
    
+  user must either rename the package to another package or start over
    
+  by reloading his program in a fresh lisp image.
    
+
    
+  Some programs need to create and destroy packages at runtime.
    
+  Without such a facility, some clumsy combination of RENAME-PACKAGE,
    
+  UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
    
+  easy for a casual programmer to forget to undo some of the 
    
+  bookkeeping, leading to unwanted effects.
    
+
    
+Proposal (PACKAGE-DELETION:NEW-FUNCTION):
    
+
    
+  Introduce the function DELETE-PACKAGE, described as follows:
    
+
    
+  DELETE-PACKAGE package                                 [Function]
    
+
    
+   Deletes PACKAGE from all package system data structures. PACKAGE may
    
+   be either a package or the name of a package.
    
+
    
+   If PACKAGE is a package name (i.e., not type PACKAGE) which does not
    
+   currently name a package, a correctable error is signalled. If
    
+   continued, no deletion action is attempted. Instead, DELETE-PACKAGE
    
+   immediately returns NIL.
    
+
    
+   If PACKAGE is a package object (i.e., an object of type PACKAGE)
    
+   which has already been deleted, no error is signalled and no further
    
+   deletion action is attempted. Instead, DELETE-PACKAGE immediately
    
+   returns NIL.
    
+
    
+   If the designated package is used by other packages, a correctable
    
+   error is signalled. If continued, the effect of UNUSE-PACKAGE is
    
+   done to remove any dependencies, causing its external symbols to stop
    
+   being accessible to those packages. Once this is done, DELETE-PACKAGE
    
+   goes on to delete the package just as it would had there been no 
    
+   packages that used it.
    
+
    
+   After this operation completes, the contents of the symbol-package  
    
+   slot of any symbol homed in the deleted package is unspecified; for 
    
+   those symbols not homed in that package, the contents remain unchanged.
    
+   Except for this, symbols in the deleted package are not modified in
    
+   any other way.  
    
+
    
+   The effect of DELETE-PACKAGE is that the name and
    
+   nicknames of the designated package cease to be recognized package
    
+   names.   The package object is still a package -- PACKAGEP is true
    
+   of it -- but  PACKAGE-NAME will return NIL.  The effect of any other 
    
+   package operation on PACKAGE once it has been deleted is undefined.
    
+   In particular, FIND-SYMBOL, INTERN and other functions that
    
+  look for a symbol name in a package will have unspecified results if
    
+  called with *PACKAGE* bound to the deleted package or with the
    
+  deleted package as an argument.
    
+
    
+   DELETE-PACKAGE returns T if the deletion attempt was successful
    
+   and NIL otherwise.
    
+
    
+Examples:
    
+
    
+  (SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
    
+  (SETQ *FOO-SYMBOL*  (INTERN "FOO" *FOO-PACKAGE*))
    
+  (EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
    
+
    
+  (SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
    
+  (SETQ *BAR-SYMBOL*  (INTERN "BAR" *BAR-PACKAGE*))
    
+  (EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
    
+  (EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
    
+
    
+  (SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
    
+
    
+  (SYMBOL-PACKAGE *FOO-SYMBOL*)        => #<Package "FOO">
    
+  (SYMBOL-PACKAGE *BAR-SYMBOL*)        => #<Package "BAR">
    
+
    
+  (PRIN1-TO-STRING *FOO-SYMBOL*)       => "FOO:FOO"
    
+  (PRIN1-TO-STRING *BAR-SYMBOL*)       => "BAR:BAR"
    
+
    
+  (FIND-SYMBOL "FOO" *BAR-PACKAGE*)    => FOO:FOO, :EXTERNAL
    
+
    
+  (FIND-SYMBOL "FOO" *BAZ-PACKAGE*)    => FOO:FOO, :INHERITED
    
+  (FIND-SYMBOL "BAR" *BAZ-PACKAGE*)    => BAR:BAR, :INHERITED
    
+
    
+  (PACKAGEP *FOO-PACKAGE*)             => T
    
+  (PACKAGEP *BAR-PACKAGE*)             => T
    
+  (PACKAGEP *BAZ-PACKAGE*)             => T
    
+
    
+  (PACKAGE-NAME *FOO-PACKAGE*)         => "FOO"
    
+  (PACKAGE-NAME *BAR-PACKAGE*)         => "BAR"
    
+  (PACKAGE-NAME *BAZ-PACKAGE*)         => "BAZ"
    
+
    
+  (PACKAGE-USE-LIST *FOO-PACKAGE*)     => ()
    
+  (PACKAGE-USE-LIST *BAR-PACKAGE*)     => (#<Package FOO>)
    
+  (PACKAGE-USE-LIST *BAZ-PACKAGE*)     => (#<Package BAR>)
    
+
    
+  (PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
    
+  (PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
    
+  (PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
    
+
    
+  (DELETE-PACKAGE *BAR-PACKAGE*)
    
+  Error: Package BAZ uses package BAR.
    
+  If continued, BAZ will be made to unuse-package BAR,
    
+	        and then BAR will be deleted.
    
+  Type :CONTINUE to continue.
    
+  Debug> :CONTINUE
    
+  				       => T
    
+
    
+  (SYMBOL-PACKAGE *FOO-SYMBOL*)        => #<Package "FOO">
    
+  (SYMBOL-PACKAGE *BAR-SYMBOL*)        is unspecified
    
+
    
+  (PRIN1-TO-STRING *FOO-SYMBOL*)       => "FOO:FOO"
    
+  (PRIN1-TO-STRING *BAR-SYMBOL*)       is unspecified
    
+
    
+  (FIND-SYMBOL "FOO" *BAR-PACKAGE*)    is undefined
    
+
    
+  (FIND-SYMBOL "FOO" *BAZ-PACKAGE*)    => NIL, NIL
    
+  (FIND-SYMBOL "BAR" *BAZ-PACKAGE*)    => NIL, NIL
    
+
    
+  (PACKAGEP *FOO-PACKAGE*)             => T
    
+  (PACKAGEP *BAR-PACKAGE*)             => T
    
+  (PACKAGEP *BAZ-PACKAGE*)             => T
    
+
    
+  (PACKAGE-NAME *FOO-PACKAGE*)         => "FOO"
    
+  (PACKAGE-NAME *BAR-PACKAGE*)         => NIL
    
+  (PACKAGE-NAME *BAZ-PACKAGE*)         => "BAZ"
    
+
    
+  (PACKAGE-USE-LIST *FOO-PACKAGE*)     => ()
    
+  (PACKAGE-USE-LIST *BAR-PACKAGE*)     is undefined
    
+  (PACKAGE-USE-LIST *BAZ-PACKAGE*)     => ()
    
+
    
+  (PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
    
+  (PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
    
+  (PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
    
+
    
+Rationale:
    
+
    
+  This facility corrects the deficiency described in the problem description.
    
+
    
+Current Practice:
    
+
    
+  Symbolics has a function PKG-KILL which satisfies the proposed behavior
    
+  except that an error is not signalled if the package is used.
    
+  When a package is killed by PKG-KILL, the home package of all symbols
    
+  in that package are left undisturbed (i.e., local symbols pointing to
    
+  the killed package); this aspect is compatible with the stated proposal.
    
+
    
+  Procyon Common Lisp has a function called DELETE-PACKAGE already. It
    
+  returns the name   of the package so deleted (as a string). [Perhaps it also
    
+  differs in the correctability of the errors it signals?]
    
+
    
+  Lucid Common Lisp implements DELETE-PACKAGE, except that the continuation
    
+  option for a name that doesn't name a package is different.
    
+
    
+Cost to Implementors:
    
+
    
+  The cost of providing this facility is probably small.
    
+
    
+Cost to Users:
    
+
    
+  Very slight to none. This change is essentially compatible.
    
+
    
+  Some code which cached packages in variables might have to be slightly
    
+  more cautious, but experience in the Symbolics implementation suggests
    
+  that it's really the responsibility of the person doing the DELETE-PACKAGE
    
+  to take care of worrying about the effects of having deleted the package:
    
+  normal programs need not bother testing a package for validity (using
    
+  PACKAGE-NAME) before using it.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Getting rid of a package would continue to be difficult to do portably.
    
+
    
+Benefits:
    
+
    
+  Better control of storage usage would be available portably.
    
+
    
+Aesthetics:
    
+
    
+  No significant effect.
    
+
    
+Discussion:
    
+
    
+  This was discussed as part of a larger bulk issue of how to undo all
    
+  sorts of definitions. Since that proposal has not gone anywhere 
    
+  (perhaps bogged down under its own weight), this subtopic has been
    
+  broken off for separate discussion.
    
+
    
+  Note that if a symbol's package component is modified as a result
    
+  of being "unintern'd" from a delete packaged, then it is unspecified
    
+  as to how it will  be printed.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254.htm new file mode 100644 index 00000000..1edad709 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254.htm @@ -0,0 +1,55 @@ + + + +CLHS: Issue PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254_w.htm new file mode 100644 index 00000000..aee49820 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss254_w.htm @@ -0,0 +1,133 @@ + + + +CLHS: Issue PACKAGE-FUNCTION-CONSISTENCY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PACKAGE-FUNCTION-CONSISTENCY Writeup

    + +
    Issue:        PACKAGE-FUNCTION-CONSISTENCY
    
+References:   11.7 Package System Functions and Variables (pp182-188)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 21-Oct-88, Version 1 by Pitman
    
+		12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
    
+		17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
    
+			amended & adopted at Jan 89 X3j13
    
+		17-Mar-89, Version 4, by Moon, correct amended wording
    
+
    
+Problem Description:
    
+
    
+  CLtL is vague about whether either or both of package or package name
    
+  are permissible in some cases.
    
+
    
+Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
    
+
    
+  Clarify that it is permissible to pass either a package object
    
+  or a package name (symbol or string) in the following situations:
    
+    - the :USE argument to MAKE-PACKAGE or IN-PACKAGE
    
+    - the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
    
+			or DELETE-PACKAGE
    
+    - the second argument to INTERN, FIND-SYMBOL, UNINTERN
    
+    - the second argument to EXPORT, UNEXPORT, IMPORT,
    
+      SHADOWING-IMPORT, and SHADOW
    
+    - the first argument (or a member of the list which is the first
    
+      argument) to USE-PACKAGE or UNUSE-PACKAGE.
    
+    - all package-name arguments in DEFPACKAGE except for the name and
    
+      nicknames of the package being defined.
    
+    - the first argument to PACKAGE-NAME, PACKAGE-NICKNAMES, 
    
+      PACKAGE-USE-LIST, or PACKAGE-USED-BY-LIST
    
+    - the PACKAGE argument to DO-SYMBOLS.
    
+    - the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
    
+    - the PACKAGE argument to DO-ALL-SYMBOLS.
    
+
    
+  If FIND-PACKAGE is given a package object as an argument, it simply
    
+  returns it.
    
+
    
+  Clarify that the function MAKE-PACKAGE permits only a package name
    
+  as an argument since it does not make sense to create an existing
    
+  package.
    
+
    
+  Clarify that package nicknames must always be expressed as package
    
+  names (symbols or strings) and may never be actual package objects.
    
+
    
+  In the list above, IN-PACKAGE may be changed to SELECT-PACKAGE
    
+  if IN-PACKAGE-FUNCTIONALITY:NEW-MACRO passes.
    
+
    
+Examples:
    
+
    
+  (INTERN "FOO" "KEYWORD") => :FOO
    
+
    
+  (DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
    
+  (RENAME-PACKAGE "FOO" "FOO0")
    
+  (PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
    
+
    
+
    
+  (PACKAGE-NAME "SYS") might return "SYSTEM".
    
+
    
+Rationale:
    
+
    
+   This makes things more consistent.
    
+   It also adds a generally useful capability.
    
+
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera & Lucid permit strings as package names.
    
+  Symbolics Cloe does not permit strings as package names.
    
+  In Lucid FIND-PACKAGE and IN-PACKAGE require names.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  None. This change is upward compatible.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Implementations would continue to vary gratuitously, leaving a potential
    
+  for portability problems.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  This makes things more regular, and so presumably more aesthetic.
    
+
    
+Discussion:
    
+
    
+  Pitman ran across this problem while trying to port Macsyma to various
    
+  implementations. Discussion with other maintainers of portable programs
    
+  shows this is a common source of aggravation in portable code.
    
+
    
+  It would be possible to say that MAKE-PACKAGE took package objects as
    
+  arguments and just returned that package. That might have limited
    
+  usefulness on rare occasions, but mostly seemed too far out in left
    
+  field to bother suggesting it.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255.htm new file mode 100644 index 00000000..a143a014 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255.htm @@ -0,0 +1,41 @@ + + + +CLHS: Issue PARSE-ERROR-STREAM:SPLIT-TYPES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PARSE-ERROR-STREAM:SPLIT-TYPES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PARSE-ERROR-STREAM:SPLIT-TYPES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255_w.htm new file mode 100644 index 00000000..46168c79 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss255_w.htm @@ -0,0 +1,95 @@ + + + +CLHS: Issue PARSE-ERROR-STREAM Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PARSE-ERROR-STREAM Writeup

    + +
    Status:		Version 3 passed, 6/8/90
    
+
    
+Issue:		PARSE-ERROR-STREAM
    
+Forum:		Cleanup
    
+References:	Condition System, Version 18
    
+		Issue READER-ERROR
    
+		Issue CLOS-CONDITIONS
    
+Category:	CHANGE/CLARIFICATION
    
+Edit History:	Version 1, 1/3/90 by Kim A. Barrett
    
+		Version 2, 6/6/90 by Kim A. Barrett
    
+		Version 3, 6/11/90 by Kim A. Barrett (X3J13 ammendments)
    
+
    
+Problem Description:
    
+  The recently passed issue READER-ERROR defined the new condition type
    
+  PARSE-ERROR as a subtype of STREAM-ERROR.  This means that PARSE-ERROR
    
+  inherits behavior on the function STREAM-ERROR-STREAM, and has :STREAM as
    
+  the associated initarg.  The description of STREAM-ERROR can be read to
    
+  imply that the value of STREAM-ERROR-STREAM is in fact a STREAM.  That is,
    
+  that (TYPEP (STREAM-ERROR-STREAM c) 'STREAM) -> true.  However, it is fairly
    
+  easy to imagine a program which might want to signal PARSE-ERROR under some
    
+  circumstance, but which is not using a Common Lisp stream as its source of
    
+  input.
    
+
    
+Proposal (PARSE-ERROR-STREAM:SPLIT-TYPES):
    
+
    
+  1. Define that PARSE-ERROR has the class precedence list
    
+      (PARSE-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  thus making it no longer be a subtype of STREAM-ERROR.
    
+
    
+  2. Define a new condition called READER-ERROR, with class precedence list
    
+  (READER-ERROR PARSE-ERROR STREAM-ERROR ERROR SERIOUS-CONDITION CONDITION T).
    
+
    
+  Issue READER-ERROR (version 3, passed 11/89) specified that the reader was to
    
+  signal errors of type PARSE-ERROR for serious conditions that relate to
    
+  lexical analysis (the building and interpretation of tokens) and parsing
    
+  (errors in reader macro syntax) by the Lisp reader.  Change this to instead
    
+  specify that the reader signals errors of type READER-ERROR for such
    
+  situations.  There are numerous places (especially in chapter 3) that would
    
+  be affected.
    
+
    
+Rational:
    
+  SPLIT-TYPES fixes the problem in the obvious way.  If a program needs a
    
+  condition which inherits from both is desired, such a condition can be
    
+  trivially defined, since issue CLOS-CONDITIONS says that we now have
    
+  multiple inheritance for conditions.
    
+
    
+Current Practice:
    
+  PARSE-ERROR is sufficiently new that few implementations are likely to
    
+  have added it.
    
+
    
+Cost to Implementors:
    
+  Should be trivial.
    
+
    
+Cost to Users:
    
+  If this does not passe then some programs which might otherwise reasonably
    
+  signal PARSE-ERRORs will not be able to do so.
    
+
    
+Discussion:
    
+  Barrett supports SPLIT-TYPES.  He had some qualms about the merging when
    
+  he first saw the READER-ERROR issue, but didn't have time to think about
    
+  it much before the issue was voted on.
    
+
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256.htm new file mode 100644 index 00000000..63fd7128 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256_w.htm new file mode 100644 index 00000000..581232c3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss256_w.htm @@ -0,0 +1,241 @@ + + + +CLHS: Issue PATHNAME-COMPONENT-CASE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-COMPONENT-CASE Writeup

    + +
    Status: passed, as amended here, Jun 89 X3J13
    
+Issue:        PATHNAME-COMPONENT-CASE
    
+References:   Pathnames (pp410-413),
    
+              MAKE-PATHNAME (p416),
    
+              PATHNAME-HOST (p417),
    
+              PATHNAME-DEVICE (p417),
    
+              PATHNAME-DIRECTORY (p417),
    
+              PATHNAME-NAME (p417),
    
+              PATHNAME-TYPE (p417)
    
+Related-issues: PATHNAME-WILD
    
+Category:     CHANGE
    
+Edit history: 1-Jul-88, Version 1 by Pitman
    
+              22-Mar-89, Version 2 by Moon, update and rewrite
    
+               9-May-89, Version 3 by Moon, remove alternate proposals
    
+               9-May-89, Version 4 by Moon, respond to discussion with KMP
    
+              17-Jun-89, Version 5 by Moon, fix typo, make minor improvements
    
+ 			to the presentation.
    
+              1-Jul-89, Version 6 by Masinter, as per Jun89X3J13 amendments
    
+
    
+Problem Description:
    
+
    
+  Issues of alphabetic case in pathnames are a major source of problems.
    
+  In some file systems, the customary case is lowercase, in some uppercase,
    
+  in some mixed.  In some file systems, case matters, in others it does
    
+  not.
    
+
    
+  There are two kinds of pathname case portability problems: moving
    
+  programs from one Common Lisp to another, and moving pathname component
    
+  values from one file system to another.  To solve the first problem, all
    
+  Common Lisp implementations that support a particular file system must
    
+  use compatible representations for pathname component values.  To solve
    
+  the second problem, there must be a common representation for the least
    
+  common denominator pathname component values that exist on all
    
+  interesting file systems.
    
+
    
+  This desire for a common representation directly conflicts with the
    
+  desire among programmers who only use one file system to work with the
    
+  local conventions and not think about issues of porting to other file
    
+  systems.  The common representation cannot be the same as every local
    
+  convention, since they vary.
    
+
    
+  In the current anarchy of pathname component case conventions:
    
+  
    
+  (NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
    
+  will produce foo.lisp in some Unix Common Lisp implementations
    
+  and will produce FOO.LISP in other Unix Common Lisp implementations.
    
+
    
+  (NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
    
+  will produce FOO.LISP in some Tops-20 Common Lisp implementations
    
+  and will produce "^Vf^Vo^Vo.^Vl^Vi^Vs^Vp"in other Tops-20 Common
    
+  Lisp implementations.
    
+
    
+  Problems like this make it difficult to use MAKE-PATHNAME for much of
    
+  anything without corrective (non-portable) code.
    
+
    
+  Other problems occur in merging because doing
    
+   (NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
    
+                                (PARSE-NAMESTRING "MY-UNIX:x.lisp")))
    
+  should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
    
+  "MY-TOPS-20:FOO.^Vl^Vi^Vs^Vp" in some implementations.
    
+
    
+  Problems like this make it difficult to use any merging primitives for
    
+  much of anything without corrective (non-portable) code.
    
+
    
+Proposal (PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT):
    
+
    
+  Add a keyword argument :CASE to MAKE-PATHNAME, PATHNAME-HOST,
    
+  PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, and PATHNAME-TYPE.
    
+  The possible values for the argument are :COMMON and :LOCAL.
    
+
    
+  :LOCAL means strings input to MAKE-PATHNAME or output by PATHNAME-xxx
    
+  follow the local file system's conventions for alphabetic case.
    
+  Strings given to MAKE-PATHNAME will be used exactly as written if
    
+  the file system supports both cases.  If the file system only
    
+  supports one case, the strings will be translated to that case.
    
+
    
+  :COMMON means strings input to MAKE-PATHNAME or output by PATHNAME-xxx
    
+  follow this common convention:
    
+    - all uppercase means to use a file system's customary case.
    
+    - all lowercase means to use the opposite of the customary case.
    
+    - mixed case represents itself.
    
+  The second and third bullets exist so that translation from local to
    
+  common and back to local is information-preserving.
    
+
    
+  The default is :LOCAL.
    
+
    
+  Namestrings always use local file system case conventions.
    
+
    
+  MERGE-PATHNAMES and TRANSLATE-WILD-PATHNAME map customary case in the
    
+  input pathnames into customary case in the output pathname.
    
+
    
+Implications of the proposal:
    
+
    
+  Unix is case-sensitive and prefers lowercase, so it translates between
    
+  common and local by inverting the case of non-mixed-case strings.
    
+  
    
+  Tops-20 is case-sensitive and prefers uppercase, so it uses identical
    
+  representations for common and local.
    
+
    
+  VAX/VMS is upper-case-only (that is, the file system translates all file
    
+  name arguments to upper case), so it translates common to local by
    
+  upcasing, and translates local to common with no change.
    
+
    
+  Macintosh is case-insensitive and prefers lowercase, so it translates
    
+  between common and local by inverting the case of non-mixed-case strings,
    
+  and ignores case in EQUAL of two pathnames.
    
+
    
+Test Case/Examples:
    
+
    
+  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
    
+                 :CASE :COMMON)                                 => "FOO"
    
+  (PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
    
+                 :CASE :COMMON)                                 => "FOO"
    
+  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
    
+                 :CASE :LOCAL)                                  => "foo"
    
+  (PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
    
+                 :CASE :LOCAL)                                  => "FOO"
    
+  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
    
+                 :CASE :COMMON)                                 => "TeX"
    
+  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
    
+                 :CASE :LOCAL)                                  => "TeX"
    
+  (NAMESTRING (MAKE-PATHNAME :HOST "MY-UNIX" :NAME "FOO"
    
+                             :CASE :COMMON)                     => "MY-UNIX:foo"
    
+
    
+Rationale:
    
+
    
+  This does not solve the whole pathname problem, but it does improve
    
+  the situation for a clearly defined set of very common problems.
    
+  Together with the other pathname proposals, the behavior of pathnames
    
+  should be sufficiently consistent across Common Lisp implementations
    
+  and across file systems to allow portability of pathname-manipulating
    
+  programs.
    
+
    
+  The current situation where different implementations talk about
    
+  the *same* file system in different ways will be corrected by this
    
+  and some of the other pathname proposals.
    
+
    
+  Upper case is chosen as the common case for no better reason than
    
+  consistency with Lisp symbols.
    
+
    
+  The :CASE keyword argument provides access to both common and local
    
+  conventions without introducing any new functions.  The default
    
+  convention is the common one, assuming that most programs are fully
    
+  portable and therefore :COMMON will be more frequently used.
    
+
    
+Current Practice:
    
+
    
+  There are no known implementations of exactly what is proposed.
    
+  Symbolics Genera uses common case normally, and provides a way to
    
+  access the local case (called "raw") that in practice is rarely used.
    
+  Symbolics Genera's own file system is case-insensitive and uses lower
    
+  case as the customary case, but transparent network access is available
    
+  to file systems using all known case conventions.
    
+
    
+  Several Common Lisp implementations behave as if :CASE :LOCAL was
    
+  specified (but accept no :CASE argument).
    
+
    
+Cost to Implementors:
    
+
    
+  The :CASE feature is easily added, but some implementations may have
    
+  to change the default behavior when :CASE is not specified.  No
    
+  implementation need change its internal representation, nor the way
    
+  pathnames print, just the interface functions listed above.
    
+
    
+Cost to Users:
    
+
    
+  Technically, this change is upward compatible.
    
+
    
+  In fact, since the existing CLtL spec is so poor, nearly everyone relies
    
+  heavily on implementation-specific behavior since there is little other
    
+  choice. As such, any change is almost certain to break lots of programs,
    
+  in usually superficial but nevertheless important ways. However, if we
    
+  really make the pathname facility more portable, the user community may
    
+  be willing to bear the consequences of these changes.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  We would be contributing to the perpetuation of the existing fiasco of a
    
+  pathname system.
    
+
    
+Performance Impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  One step closer to a usable pathname system.
    
+
    
+Aesthetics:
    
+
    
+  Anything that simplifies the user model of pathnames is an improvement.
    
+
    
+Discussion:
    
+
    
+  Some people would rather use lowercase as the common case.  The
    
+  decision is essentially arbitrary.  Everywhere else in Common Lisp
    
+  where case matters, uppercase was chosen.
    
+
    
+  It has been proposed that the Common Lisp specification should include
    
+  specifications of the exact behavior of pathnames for several popular
    
+  operating systems, so that multiple implementations for those
    
+  operating systems would be compatible with each other.  This proposal
    
+  does that for alphabetic case.
    
+
    
+  Some people want the default for :CASE to be :LOCAL instead of :COMMON.
    
+  See Rationale.
    
+
    
+  There should probably be a remark somewhere that says that portable
    
+  programs shouldn't expect to be able to create and/or access distinct
    
+  files whose pathname components differ only in case.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257.htm new file mode 100644 index 00000000..2596d2df --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue PATHNAME-COMPONENT-VALUE:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-COMPONENT-VALUE:SPECIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-COMPONENT-VALUE:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257_w.htm new file mode 100644 index 00000000..08d3ecc8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss257_w.htm @@ -0,0 +1,291 @@ + + + +CLHS: Issue PATHNAME-COMPONENT-VALUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-COMPONENT-VALUE Writeup

    + +
    Issue:         PATHNAME-COMPONENT-VALUE
    
+
    
+Related Issues:PATHNAME-CANONICAL-TYPE,
    
+               PATHNAME-SUBDIRECTORY-LIST,
    
+               PATHNAME-UNSPECIFIC-COMPONENT,
    
+               PATHNAME-WILD
    
+
    
+References:    CLtL pp.410-3
    
+
    
+Category:      CLARIFICATION and CHANGE
    
+
    
+Edit history:  Version 1, 20-Mar-89, by Moon
    
+               Version 2,  9-May-89, by Moon (rewrite based on mail)
    
+               Version 3, 17-Jun-89, by Moon (add discussion, current practice)
    
+
    
+Problem description:
    
+  
    
+  CLtL is overly restrictive on the possible values for pathname components.
    
+  These restrictions are described in a funny way that makes it unclear
    
+  whether they are requirements, guidelines, or just an example.
    
+  
    
+  The restrictions are not all written down in one place, but they appear
    
+  to be as follows:
    
+
    
+  Host          nil, :wild, string, or list of strings
    
+  Device        nil, :wild, string, or something else ("structured")
    
+  Directory     nil, :wild, string, or something else ("structured")
    
+  Name          nil, :wild, string, or something else ("structured")
    
+  Type          nil, :wild, or string
    
+  Version       nil, :wild, :newest, positive integer, implementation
    
+                dependent symbol, or implementation-dependent integer
    
+                less than or equal to zero.  Suggestions include :oldest,
    
+                :previous, :installed, 0, and -1.
    
+
    
+  PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
    
+  allow any component to be :UNSPECIFIC.  This has been voted in.
    
+
    
+  PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
    
+  symbols for the directory component.
    
+
    
+  PATHNAME-CANONICAL-TYPE proposes some new operations but does not
    
+  change the possible values of the type component.
    
+
    
+  PATHNAME-WILD proposes a portable way to test for implementation
    
+  dependent component values that indicate wildcard matching.  It
    
+  does not change the possible values of any component.
    
+
    
+Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
    
+
    
+  The points of the proposal have been numbered/lettered to facilitate
    
+  discussion of individual points.
    
+
    
+  0. Pathname component value strings never contain the punctuation
    
+  characters that are used to separate pathname fields (e.g. slashes and
    
+  dots in Unix).  Punctuation characters appear only in namestrings.
    
+  Characters used as punctuation can appear in pathname component values
    
+  with a non-punctuation meaning if the file system allows it (e.g. a Unix
    
+  file name that begins with a dot).
    
+
    
+  When examining pathname components, conforming programs must be prepared
    
+  to encounter any of the following values:
    
+  
    
+    1. Any component can be NIL, which means the component has not
    
+    been specified.
    
+  
    
+    2. Any component can be :UNSPECIFIC, which means the component has
    
+    no meaning in this particular pathname.
    
+  
    
+    3. The device, directory, name, and type can be strings.
    
+  
    
+    4. The host can be any object, at the discretion of the implementation.
    
+  
    
+    5. The directory can be a list of strings and symbols as detailed in
    
+    PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
    
+  
    
+    6. The version can be any symbol or any integer.  The symbol :NEWEST
    
+    refers to the largest version number that already exists in the file
    
+    system when reading, overwriting, appending, superseding, or directory
    
+    listing an existing file, and refers to the smallest version number
    
+    greater than any existing version number when creating a new file.
    
+    Other symbols and integers have implementation-defined meaning.
    
+    It is suggested, but not required, that implementations use positive
    
+    integers starting at 1 as version numbers, recognize the symbol :OLDEST
    
+    to designate the smallest existing version number, and use keyword
    
+    symbols for other special versions.
    
+
    
+  Wildcard pathnames can be used with DIRECTORY but not with OPEN, and
    
+  return true from WILD-PATHNAME-P (if issue PATHNAME-WILD passes).  When
    
+  examining wildcard components of a wildcard pathname, conforming programs
    
+  must be prepared to encounter any of the following additional values
    
+  in any component or any element of a list that is the directory component:
    
+
    
+    7. :WILD, which matches anything.
    
+
    
+    8. A string containing implementation-dependent special wildcard
    
+    characters.
    
+
    
+    9. Any object, representing an implementation-dependent wildcard
    
+    pattern.
    
+
    
+  When constructing a pathname from components, conforming programs
    
+  must follow these rules:
    
+  
    
+    a. Any component can be NIL.  NIL in the host may mean a default host
    
+    rather than an actual NIL in some implementations.
    
+    
    
+    b. The host, device, directory, name, and type can be strings.  There
    
+    are implementation-dependent limits on the number and type of
    
+    characters in these strings.
    
+  
    
+    c. The directory can be a list of strings and symbols as detailed in
    
+    PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)  There are
    
+    implementation-dependent limits on the list's length and contents.
    
+  
    
+    d. The version can be :NEWEST.
    
+
    
+    e. Any component can be taken from the corresponding component
    
+    of another pathname.  When the two pathnames are for different
    
+    file systems (in implementations that support multiple file
    
+    systems), an appropriate translation occurs.  If no meaningful
    
+    translation is possible, an error is signalled.  The definitions
    
+    of "appropriate" and "meaningful" are implementation-dependent.
    
+  
    
+    f. When constructing a wildcard pathname, the name, type, or version
    
+    can be :WILD, which matches anything.
    
+  
    
+    g. An implementation might support other values for some components,
    
+    but a portable program cannot use those values.  A conforming program
    
+    can use implementation-dependent values but this can make it
    
+    non-portable, for example, it might work only with Unix file systems.
    
+
    
+Consequences:
    
+
    
+  The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
    
+  are as follows:
    
+
    
+  The removal of punctuation characters during parsing is specified.
    
+
    
+  "Structured" components are disallowed in non-wildcard pathnames,
    
+  except for the specific structuring of directories specified
    
+  in issue PATHNAME-SUBDIRECTORY-LIST.
    
+  
    
+  "Structured" hosts are allowed, a generalization of CLtL's list
    
+  of strings.
    
+
    
+  The type and version can be "structured" in wildcard pathnames.
    
+  
    
+  The difference between what component values a program can depend
    
+  on being able to use, versus what component values a program must
    
+  be prepared to encounter, is clarified.
    
+
    
+  The implementation-dependent variations are identified explicitly.
    
+
    
+Rationale:
    
+  
    
+  This should make it easier to write portable programs that deal with
    
+  pathnames and make it easier for implementors by clarifying the
    
+  framework into which they must fit.  Also it should make it easier
    
+  to write the Common Lisp language specification by resolving some
    
+  things that were unclear about the status quo.
    
+
    
+  Adding "structured" hosts conforms to current practice.
    
+
    
+  Substituting a default host for NIL conforms to current practice
    
+  in implementations that require all pathnames to have a specific host.
    
+
    
+  Confining "structured" devices and names to wildcard pathnames, and
    
+  replacing "structured" directories with an explicit specification of
    
+  the form of the directory value, should improve portability without causing
    
+  any harm.
    
+
    
+  :WILD is only required to be supported in the name, type, or version,
    
+  which are the easiest to implement and the most useful in applications.
    
+
    
+Current practice:
    
+  
    
+  All versions of Symbolics Genera violate CLtL in the matter of hosts,
    
+  since it uses standard-objects as the host component.  Genera deviates
    
+  slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
    
+  PATHNAME-COMPONENT-VALUE:SPECIFY.
    
+
    
+  Like Genera, the Explorer current practice is to use an object instead of
    
+  a string for the host component.  The directory component is a list of
    
+  strings, not yet supporting the symbols specified in proposal
    
+  PATHNAME-SUBDIRECTORY-LIST; other than that, the Explorer conforms to
    
+  proposal PATHNAME-COMPONENT-VALUE:SPECIFY.
    
+
    
+  Macintosh Allegro Common Lisp 1.2.2 uses NIL and "" for :UNSPECIFIC,
    
+  and uses a string with punctuation characters instead of a list for
    
+  the directory.  MAKE-PATHNAME won't set a component to NIL when
    
+  :DEFAULTS is used, it merges with the defaults instead.
    
+  Otherwise it seems consistent with what is proposed.
    
+
    
+  Lucid Common Lisp 3.0.1 under Unix uses NIL for :UNSPECIFIC, and uses
    
+  a list for directories of somewhat different form from what is proposed
    
+  in PATHNAME-SUBDIRECTORY-LIST.  Lucid lets you store arbitrary information
    
+  in the version field with MAKE-PATHNAME :VERSION and will return it with
    
+  PATHNAME-VERSION (as long as it's a symbol or an integer), even though
    
+  it's not used.  Otherwise it seems consistent with what is proposed.
    
+
    
+  Ibuki Common Lisp Release 01/01 behaves the same as Lucid, including the
    
+  same form of structured directory, except it doesn't have the ability to
    
+  store information in the unused pathname version field, and it has the
    
+  same bug in MAKE-PATHNAME that the Macintosh has.  Otherwise it seems
    
+  consistent with what is proposed.
    
+
    
+  Other implementations were not surveyed.
    
+
    
+  This proposal assumes that no current or planned implementation
    
+  uses "structured" names except possibly for wildcards.
    
+
    
+Cost to Implementors:
    
+
    
+  Most implementations already conform, except for the changes required
    
+  by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
    
+  the cost of this proposal itself should be minimal.  It is conceivable
    
+  that an implementation may exist that has to change its pathname
    
+  representation, for example one that uses numbers as "structured" devices.
    
+  Some implementations may have to change their treatment of punctuation
    
+  characters.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+  
    
+  Pathnames will continue to be a poorly specified part of the language.
    
+
    
+Performance impact:
    
+
    
+  None of any significance.
    
+
    
+Benefits/Esthetics:
    
+
    
+  The boundary between the specified behavior of pathnames and the
    
+  implementation-dependent behavior of pathnames will be more clear.
    
+
    
+Discussion:
    
+
    
+  Sandra Loosemore comments:
    
+
    
+    As I've said before, I don't think that trying to construct or pick
    
+    apart pathnames by component can be accomplished portably in any case,
    
+    because even if you restrict the representation of what can appear in
    
+    the various components, the objects you stuff in may or may not make
    
+    sense for a particular file system.  Instead, I would much prefer to
    
+    deprecate MAKE-PATHNAME and the PATHNAME-xxx accessors and leave the
    
+    question of representation of components unspecified in the standard.
    
+    
    
+    I realize that this position may be seen as being too extreme.  In
    
+    that case I'd be willing to shut up and go along with proposal SPECIFY
    
+    as long as my position gets noted in the writeup.
    
+    
    
+  Larry Masinter and Dave Moon both feel that we should be able to
    
+  prescribe exact pathname component values for popular file systems, so
    
+  that multiple implementations will behave the same way when using the
    
+  same file system.  Obvious candidates as the key file systems are MS/DOS,
    
+  Macintosh, Unix, and VAX/VMS.  A call for volunteers to write up tables
    
+  for any of them produced absolutely no response, however.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258.htm new file mode 100644 index 00000000..0e4b6397 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258.htm @@ -0,0 +1,50 @@ + + + +CLHS: Issue PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258_w.htm new file mode 100644 index 00000000..5187b1d3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss258_w.htm @@ -0,0 +1,230 @@ + + + +CLHS: Issue PATHNAME-HOST-PARSING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-HOST-PARSING Writeup

    + +
    Issue:        PATHNAME-HOST-PARSING
    
+Forum:	      X3J13
    
+References:   Pathnames chapter
    
+Category:     CHANGE
    
+Edit history: 06-Jul-93, Version 1 by Pitman
    
+	      08-Jul-93, Version 2 by Pitman
    
+	        (fix Cost To Users and add Discussion per Barmar)
    
+              08-Jul-93, Version 3 by Pitman 
    
+	        (address physical/logical conflicts per Barmar)
    
+Status:		Proposal RECOGNIZE-LOGICAL-HOST-NAMES passed (6+3)-3
    
+		on letter ballot 93-306.
    
+
    
+
    
+Problem Description:
    
+
    
+ Substantial confusion has been caused to numerous users over the issue
    
+ of "FOO:BAR;BAZ.LISP" parsing as a non-logical pathname in namestring,
    
+ and (MAKE-PATHNAME :host "FOO" ...) constructing a non-logical pathname
    
+ when "FOO" designates a logical pathname host.  There is widespread
    
+ sentiment that this model must change.
    
+
    
+Proposal (PATHNAME-HOST-PARSING:HOST-COLON):
    
+
    
+ Define that when parsing a namestring with respect to an explicitly
    
+ named host (as with PARSE-NAMESTRING with a host argument), the 
    
+ namestring is parsed in the manner normal for that host.
    
+
    
+ Define that when parsing a namestring with no explicitly named host
    
+ (as with all calls to PATHNAME, and calls to PARSE-NAMESTRING where
    
+ no host is given explicitly):
    
+   - a namestring containing no colon is to be interpreted as a
    
+     host-specific namestring on the current default host.
    
+   - in a namestring that contains at least one colon, the first
    
+     colon is taken to terminate the end of a host name.  (If the host
    
+     name is the null string, "", the current default host is
    
+     assumed.)  Any subsequent string is a host-specific namestring
    
+     for the host named by the text preceding the colon.
    
+
    
+ Define that if host is defined as a logical host at namestring parse
    
+ time, then it will be recognized as such by the namestring parser, and
    
+ a logical pathname will result from a situation in which a logical host
    
+ was named in the host part of a namestring.
    
+
    
+ Remove the function LOGICAL-PATHNAME, since the functions PATHNAME
    
+ and PARSE-NAMESTRING suffice instead.
    
+
    
+ Require #P to always use a host name to print, for the sake of portability
    
+ among multiple implementations that all have access to the same file 
    
+ system.
    
+
    
+ If an attempt is made to parse a namestring containing a host name
    
+ that is defined both as a physical and a logical host, the effects
    
+ are implementation defined.
    
+
    
+Proposal (PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES):
    
+
    
+ Define that if host is defined as a logical host at pathname
    
+ construction time, then it will be recognized as such by the namestring
    
+ parser, and a logical pathname will result from a situation in which a
    
+ logical host was named in the host part of a namestring.
    
+
    
+ If an attempt is made to construct a pathname specifying a host name
    
+ that is defined both as a physical and a logical host, the effects
    
+ are implementation defined.
    
+
    
+Test Case:
    
+
    
+  For option HOST-COLON:
    
+
    
+    "BAR;BAZ"  is a filename on the default host.
    
+    ":BAR;BAZ" is notationally equivalent to "BAR;BAZ".
    
+    "FOO:BAR;BAZ" is a filename on a host "FOO".
    
+      If that host is a logical host, then this designates a logical
    
+      pathname. If that host is not a logical host, then this designates
    
+      a physical pathname.
    
+
    
+    In the case where an ambiguity might result, for example, where
    
+    there was both a device named "SYS" on a VMS host "V", and a host
    
+    named "SYS", the following notations (which follow from the rules
    
+    outlined above) can be used to disambiguate:
    
+
    
+      ":SYS:FOO" refers to device SYS on the default host.
    
+      "SYS:FOO"  refers to "FOO" on host "SYS".
    
+
    
+ For option RECOGNIZE-LOGICAL-HOST-NAMES:
    
+
    
+   (MAKE-PATHNAME :HOST "FOO")
    
+   works to name a logical host FOO just as
    
+   (MAKE-PATHNAME (PATHNAME-HOST (LOGICAL-PATHNAME "FOO:")))
    
+   would do.
    
+
    
+ For option 
    
+
    
+Rationale:
    
+
    
+ These options would legitimize the observed desires of numerous users.
    
+
    
+Current Practice:
    
+
    
+ Both of these options are consistent with long-standing Genera practice, 
    
+ which Symbolics users have generally been extremely happy with and have
    
+ often asked other vendors to be consistent with.
    
+
    
+Cost to Implementors:
    
+
    
+ Small to medium:
    
+  Some isolated changes to the pathname parsing code.
    
+  Probably the biggest cost will be in checking existing tools to make 
    
+   sure none make inappropriate assumptions about the parsing rules.
    
+
    
+Cost to Users:
    
+
    
+ Medium:
    
+
    
+  Probably most users don't do things that are in the boundary case, 
    
+  except that there may be some who use ":" in a namestring without 
    
+  it referring to a host.  Experience with Genera suggests that there
    
+  will be an initial flurry of concern about this, but that in the long
    
+  run users will be very much happier.
    
+
    
+  The one situation that might come up a lot is where programs prompt
    
+  users for a filename and then parse that name without adding a leading
    
+  ":".  Such calls could be fixed by using a host-specific parse instead.
    
+
    
+
    
+Cost of Non-Adoption:
    
+
    
+ Continued intermittent confusion and irritation about the rules for
    
+ logical pathname parsing.
    
+
    
+Benefits:
    
+
    
+ Making #P print portably will improve the portability of code that is 
    
+ processed through PRINT/READ and that has pathname literal constants 
    
+ in it.
    
+
    
+Editorial Impact:
    
+
    
+ Not trivial, but not huge:  A number of isolated small changes.
    
+
    
+Aesthetics:
    
+
    
+ This definitely improves the aesthetics for most users by putting logical
    
+ hosts on an even footing with physical hosts.  It also simplifies the user
    
+ model since most users don't understand why 
    
+   :host logical-host
    
+ is ok but
    
+   :host logical-host-name
    
+ is not, since most things that take names also take the named object, and
    
+ since there are other operators that can reliably perform this 
    
+ transformation.  This change makes the language more consistent in that 
    
+ regard.
    
+
    
+Discussion:
    
+
    
+ These changes address comments Yen #1 and Barrett #31.
    
+
    
+ Pitman thinks all of these changes are a good idea.
    
+
    
+ Barrett asked that we specify that:
    
+  ``logical pathname namestrings are valid pathname designators''
    
+ Pitman hopes that the above satisfies the intent of that, but 
    
+ worries that since some logical pathname namestrings already were
    
+ (e.g., "foo.bar") and just happened not to designate logical pathnames,
    
+ this would be a confusing way to express the change.  The change affects
    
+ only those logical pathname namestrings which have a host name visible
    
+ and for which there is no competing definition as a device, etc.
    
+ The wording chosen above is intended to make an end run around this
    
+ potential pitfall.
    
+
    
+ Barmar says:
    
+  Genera gets away with [HOST-COLON] because the Lisp parsing rules
    
+  are consistent with those used by the Genera OS (hardly a
    
+  coincidence).  Users expect pathname parsing to be consistent within
    
+  an OS, not subject to the choice of implementation language by the
    
+  programmer.
    
+
    
+  Consider a program that prompts the user for a file name and then parses
    
+  it.  The user will most likely use the normal pathname syntax for his
    
+  system; on a PC that would be something like "c:\foo\bar.baz", and on
    
+  VMS it might be "SYS$FOO:[BAR]BAZ.QUUX".  Users of such programs should
    
+  not be expected to know which programs are written in Lisp, which
    
+  imposes different pathname parsing rules from all other programs on the
    
+  OS.
    
+
    
+  At the very least there needs to be a way for programs to force the CLtL
    
+  pathname interpretation rules.  Are you proposing that such programs
    
+  should simply prepend a colon to the namestring read in?  Considering
    
+  that VMS has its own syntax for remote pathnames, what should be the
    
+  result of (pathname-host ":HOST::DEV:[DIR]NAME.EXT") on a VMS system?
    
+  The HOST-COLON proposal says that it should be the current default host,
    
+  but VMS pathname interpretation implies that it should be something
    
+  derived from "HOST".
    
+
    
+  I'd like to hear some commentary from vendors and users of Lisps for
    
+  VMS, Macs, and MS-DOS.  Does CLOE use this pathname parsing strategy?
    
+  Were users actually happy with it?
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259.htm new file mode 100644 index 00000000..0ac9f5ba --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259.htm @@ -0,0 +1,65 @@ + + + +CLHS: Issue PATHNAME-LOGICAL:ADD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-LOGICAL:ADD Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-LOGICAL:ADD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259_w.htm new file mode 100644 index 00000000..3cc8737c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss259_w.htm @@ -0,0 +1,670 @@ + + + +CLHS: Issue PATHNAME-LOGICAL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-LOGICAL Writeup

    + +
    Status:	Passed, Jun 89 X3J13
    
+Issue:          PATHNAME-LOGICAL
    
+Forum:          Cleanup
    
+References:     Pathnames (pp410-413)
    
+                OPEN (p.418), WITH-OPEN-FILE (p.422), RENAME-FILE (p.423),
    
+                DELETE-FILE (p.424), PROBE-FILE (p.424),
    
+                FILE-WRITE-DATE (p.424), FILE-AUTHOR (p.424), LOAD (p.426),
    
+                COMPILE-FILE (p.439), DIRECTORY (p.427), PATHNAME (p.413),
    
+                TRUENAME (p.413), MERGE-PATHNAMES (p.415), 
    
+                MAKE-PATHNAME (p.416), and PARSE-NAMESTRING (p.414).
    
+Related issues: PATHNAME-CANONICAL-TYPE, PATHNAME-COMPONENT-VALUES, 
    
+                PATHNAME-SUBDIRECTORY-LIST, and PATHNAME-WILD
    
+Category:       ADDITION
    
+Edit history:   Version 1, 11-May-89, by Moon
    
+                Version 2, 18-May-89, by Moon
    
+                Version 3, 21-Jun-89, by Moon (revise based on discussion
    
+                        in the cleanup committee)
    
+                Version 4, 23-Jun-89, by Moon (remove backtranslation)
    
+
    
+Problem description:
    
+
    
+  Pathname values are not portable, but they are sometimes part of a
    
+  program, for example the names of files containing the program and the
    
+  data used by the program.  Moving large programs between sites would
    
+  be easier if pathname values did not have to be translated.
    
+
    
+  Pathname values are nonportable because not all Common Lisp
    
+  implementations use the same operating system and file name syntax varies
    
+  widely among operating systems.  In addition, corresponding files at two
    
+  different sites may have different names even when the operating system
    
+  is the same; for example, they may be on different directories or
    
+  different devices.
    
+
    
+  The issue of portable pathname values is separate from the issues of
    
+  portable pathname operations.  See the related issues listed above.
    
+  For inter-issue interactions, see the discussion section below.
    
+
    
+  Note that issue PATHNAME-LOGICAL fundamentally depends on issue
    
+  PATHNAME-WILD.  If PATHNAME-WILD:NEW-FUNCTIONS does not pass,
    
+  PATHNAME-LOGICAL cannot pass.
    
+
    
+Proposal (PATHNAME-LOGICAL:ADD):
    
+
    
+  1. Define a "logical" file system that looks the same at every site.
    
+  This file system is implemented by translating each logical pathname into
    
+  a physical pathname on a real file system.  The logical pathnames are the
    
+  same at all sites, but the translations are different at each site, thus
    
+  the physical pathnames can be different at each site.
    
+
    
+  2a. The syntax of a logical pathname namestring is as follows:
    
+
    
+  [ host ":" ] [ ";" ] { directory ";" }* [ name ] [ "." type [ "." version ]]
    
+
    
+  2b. Terminology:
    
+
    
+  A <word> consists of one or more uppercase letters, digits, and hyphens.
    
+
    
+  A <wildcard word> consists of one or more asterisks, uppercase letters,
    
+  digits, and hyphens, including at least one asterisk, with no two
    
+  asterisks adjacent.  Each asterisk matches a sequence of zero or more
    
+  characters.  The <wildcard word> "*" parses into :WILD, the others parse
    
+  into strings.
    
+
    
+  In <words> and <wildcard words> lowercase letters are translated to
    
+  uppercase.  The consequences of using other characters are unspecified.
    
+
    
+  2c. Logical pathname components:
    
+
    
+  The host is a <word> that has been defined as a logical pathname host by
    
+  using SETF of LOGICAL-PATHNAME-TRANSLATIONS.
    
+
    
+  There is no device, so the device component of a logical pathname is
    
+  always :UNSPECIFIC.  No other component can be :UNSPECIFIC.
    
+
    
+  Each directory is a <word>, a <wildcard word>, or "**" (:WILD-INFERIORS).
    
+  If a semicolon precedes the directories, the directory component is
    
+  relative, otherwise it is absolute.
    
+
    
+  The name is a <word> or a <wildcard word>.
    
+
    
+  The type is a <word> or a <wildcard word>.
    
+
    
+  The version is a positive decimal integer or "NEWEST" (:NEWEST) or "*"
    
+  (:WILD).  The letters in "NEWEST" can be in either alphabetic case.
    
+
    
+  The consequences of using any value not specified here as a logical
    
+  pathname component are unspecified.
    
+
    
+  The null string "" is not a valid value for any component of a logical
    
+  pathname, since "" is not a <word> and not a <wildcard word>.
    
+
    
+  3. Parsing of logical pathname namestrings into logical pathnames
    
+  operates as follows:
    
+
    
+  3a. Logical pathname namestrings are recognized by the LOGICAL-PATHNAME
    
+  and TRANSLATE-LOGICAL-PATHNAME functions.  In this case the host portion
    
+  of the logical pathname namestring and its following colon are required.
    
+
    
+  3b. The PARSE-NAMESTRING function recognizes a logical pathname
    
+  namestring when the host argument is logical or the defaults argument is
    
+  a logical pathname.  In this case the host portion of the logical
    
+  pathname namestring and its following colon are optional.  If the host
    
+  portion of the namestring and the host argument are both present and do
    
+  not match, an error is signalled.
    
+
    
+  The host argument is logical if it is supplied and came from
    
+  PATHNAME-HOST of a logical pathname.  Whether a host argument is logical
    
+  if it is a string equal to a logical pathname host name is
    
+  implementation-defined.
    
+
    
+  3c. The MERGE-PATHNAMES function recognizes a logical pathname namestring
    
+  when the defaults argument is a logical pathname.  In this case the host
    
+  portion of the logical pathname namestring and its following colon are
    
+  optional.
    
+
    
+  3d. Whether the other functions that coerce strings to pathnames
    
+  (PATHNAME, TRUENAME, PARSE-NAMESTRING in other circumstances than those
    
+  described in point 3b, MERGE-PATHNAMES in other circumstances than those
    
+  described in point 3c, the :DEFAULTS argument to MAKE-PATHNAME,
    
+  PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME,
    
+  PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING,
    
+  DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING, OPEN,
    
+  WITH-OPEN-FILE, RENAME-FILE, DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE,
    
+  FILE-AUTHOR, LOAD, DIRECTORY, COMPILE-FILE, ED, DRIBBLE, WILD-PATHNAME-P,
    
+  PATHNAME-MATCH-P, TRANSLATE-PATHNAME, and COMPILE-FILE-PATHNAME)
    
+  recognize logical pathname namestrings is implementation defined.
    
+
    
+  4. Some real file systems do not have versions.  Logical pathname
    
+  translation to such a file system ignores the version.  This implies that
    
+  a program cannot rely on being able to store more than one version of a
    
+  file named by a logical pathname.
    
+
    
+  5. The type of a logical pathname for a Common Lisp source file is "LISP".
    
+  This should be translated into whatever type is appropriate in a physical
    
+  pathname.
    
+
    
+  6. The logical pathname host name "SYS" is reserved for the implementation.
    
+  The existence and meaning of SYS: logical pathnames is
    
+  implementation-defined.
    
+
    
+  7. File manipulation functions operate with logical pathnames as follows:
    
+
    
+  7a. The functions OPEN (and WITH-OPEN-FILE), RENAME-FILE, DELETE-FILE,
    
+  PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD, DIRECTORY, COMPILE-FILE,
    
+  ED, DRIBBLE, COMPILE-FILE-PATHNAME, and TRUENAME accept logical pathnames
    
+  and translate them into physical pathnames, as if by calling the
    
+  TRANSLATE-LOGICAL-PATHNAME function.
    
+
    
+  7b. PATHNAME of a stream created by OPEN (or WITH-OPEN-FILE) of a logical
    
+  pathname is a logical pathname.
    
+
    
+  7c. TRUENAME, PROBE-FILE, and DIRECTORY never return logical pathnames.
    
+
    
+  7d. RENAME-FILE with a logical pathname as the second argument returns a
    
+  logical pathname as the first value.
    
+
    
+  7e. MERGE-PATHNAMES returns a logical pathname if and only if its first
    
+  argument is a logical pathname or its first argument does not specify a
    
+  host and the default is a logical pathname.
    
+
    
+  7f. MAKE-PATHNAME returns a logical pathname if and only if the host is
    
+  logical.  If the :host argument to MAKE-PATHNAME is supplied, the host is
    
+  logical if it came from PATHNAME-HOST of a logical pathname.  Whether a
    
+  :host argument is logical if it is a string equal to a logical pathname
    
+  host name is implementation-defined.
    
+
    
+  7g. PARSE-NAMESTRING returns a logical pathname according to points 3b
    
+  and 3d.
    
+
    
+  Add these defined names to Common Lisp in support of logical pathnames:
    
+
    
+  8. LOGICAL-PATHNAME                                            [Class]
    
+
    
+    LOGICAL-PATHNAME is a subclass of PATHNAME.
    
+
    
+  9. LOGICAL-PATHNAME pathname                                   [Function]
    
+
    
+    Converts the argument to a logical pathname and returns it.  The
    
+    argument can be a logical pathname, a logical pathname namestring
    
+    containing a host component, or a stream for which the PATHNAME
    
+    function returns a logical pathname.  For any other argument,
    
+    LOGICAL-PATHNAME signals an error of type TYPE-ERROR.
    
+
    
+  10. TRANSLATE-LOGICAL-PATHNAME pathname &key                   [Function]
    
+
    
+    Translates a logical pathname to the corresponding physical pathname.
    
+    The pathname argument is first coerced to a pathname.  If it is not a
    
+    pathname, string, or file stream an error of type TYPE-ERROR is
    
+    signalled.
    
+
    
+    If the coerced argument is a physical pathname, it is returned.
    
+
    
+    If the coerced argument is a logical pathname, the first matching
    
+    translation (according to PATHNAME-MATCH-P) of the logical pathname
    
+    host is applied, as if by calling TRANSLATE-PATHNAME.  If the result is
    
+    a logical pathname, this process is repeated.  When the result is
    
+    finally a physical pathname, it is returned.
    
+
    
+    If no translation matches, an error of type FILE-ERROR is signalled.
    
+
    
+    TRANSLATE-LOGICAL-PATHNAME might perform additional translations,
    
+    typically to provide translation of file types to local naming
    
+    conventions, to accomodate physical file systems with limited length
    
+    names, or to deal with special character requirements such as
    
+    translating hyphens to underscores or uppercase letters to lowercase.
    
+    Any such additional translations are implementation defined.  Some
    
+    implementations do no additional translations.
    
+
    
+    There are no specified keyword arguments for
    
+    TRANSLATE-LOGICAL-PATHNAME, but implementations are permitted to extend
    
+    it by adding keyword arguments.  There is one specified return value
    
+    from TRANSLATE-LOGICAL-PATHNAME; implementations are permitted to
    
+    extend it by returning additional values.
    
+
    
+  11. LOGICAL-PATHNAME-TRANSLATIONS host                         [Function]
    
+
    
+    If <host> is not the host component of a logical pathname and not a
    
+    string that has been defined as a logical pathname host name by SETF of
    
+    LOGICAL-PATHNAME-TRANSLATIONS, signals an error of type TYPE-ERROR.
    
+    Otherwise returns the host's list of translations.  Each translation is
    
+    a list of at least two elements: from-wildcard and to-wildcard.  Any
    
+    additional elements are implementation defined.  From-wildcard is a
    
+    logical pathname whose host is <host>.  To-wildcard is a pathname.
    
+    Translations are searched in the order listed, so more specific
    
+    from-wildcards must precede more general ones.
    
+
    
+    (SETF (LOGICAL-PATHNAME-TRANSLATIONS host) translations) sets a logical
    
+    pathname host's list of translations.  If <host> is a string that has
    
+    not been previously used as logical pathname host, a new logical
    
+    pathname host is defined, otherwise an existing host's translations are
    
+    replaced.  Logical pathname host names are compared with STRING-EQUAL.
    
+
    
+    When setting the translations list, each from-wildcard can be a logical
    
+    pathname whose host is <host> or a logical pathname namestring
    
+    parseable by (PARSE-NAMESTRING string <<host>>), where <<host>>
    
+    represents the appropriate object as defined in point 3b.  Each
    
+    to-wildcard can be anything coercible to a pathname by
    
+    (PATHNAME to-wildcard).  If to-wildcard coerces to a logical pathname,
    
+    TRANSLATE-LOGICAL-PATHNAME will perform repeated translation steps when
    
+    it uses it.
    
+
    
+    Implementations can define additional functions that operate on
    
+    logical pathname hosts, for example to specify additional translation
    
+    rules or options.
    
+
    
+  12. LOAD-LOGICAL-PATHNAME-TRANSLATIONS host                    [Function]
    
+
    
+    If a logical pathname host named <host> (a string) is already defined,
    
+    return NIL.  Otherwise, search for a logical pathname host definition
    
+    in an implementation defined manner.  If none is found, signal an
    
+    error.  If a definition is found, install it and return T.
    
+
    
+    The search used by LOAD-LOGICAL-PATHNAME-TRANSLATIONS should be
    
+    documented, as logical pathname definitions will be created by users,
    
+    not only by Lisp implementors.  A typical search technique is to
    
+    look in a certain directory for a file whose name is derived from
    
+    the host name in an implementation-defined fashion.
    
+
    
+  13. COMPILE-FILE-PATHNAME pathname &key :output-file           [Function]
    
+
    
+    Returns the pathname that COMPILE-FILE would write into, if given the
    
+    same arguments.  If the pathname argument is a logical pathname and the
    
+    :output-file argument is unspecified, the result is a logical pathname.
    
+    If an implementation supports additional keyword arguments to
    
+    COMPILE-FILE, COMPILE-FILE-PATHNAME must accept the same arguments.
    
+
    
+Examples:
    
+
    
+  ;A very simple example of setting up a logical pathname host.  No
    
+  ;translations are necessary to get around file system restrictions, so
    
+  ;all that is necessary is to specify the root of the physical directory
    
+  ;tree that contains the logical file system.
    
+  ;The namestring syntax on the right-hand side is implementation-specific.
    
+  (setf (logical-pathname-translations "foo")
    
+        '(("**;*.*.*"              "MY-LISPM:>library>foo>**>")))
    
+
    
+  ;Sample use of that logical pathname.  All return values
    
+  ;are of course implementation-specific.
    
+  (translate-logical-pathname "foo:bar;baz;mum.quux.3")
    
+  => MY-LISPM:>library>foo>bar>baz>mum.quux.3
    
+
    
+  ;A more complex example, dividing the files among two file servers
    
+  ;and several different directories.  This Unix doesn't support
    
+  ;:WILD-INFERIORS in the directory, so each directory level must
    
+  ;be translated individually.  No file name or type translations
    
+  ;are required except for .MAIL to .MBX.
    
+  ;The namestring syntax on the right-hand side is implementation-specific.
    
+  (setf (logical-pathname-translations "prog")
    
+        '(("RELEASED;*.*.*"        "MY-UNIX:/sys/bin/my-prog/")
    
+          ("RELEASED;*;*.*.*"      "MY-UNIX:/sys/bin/my-prog/*/")
    
+          ("EXPERIMENTAL;*.*.*"    "MY-UNIX:/usr/Joe/development/prog/")
    
+          ("EXPERIMENTAL;DOCUMENTATION;*.*.*"
    
+                                   "MY-VAX:SYS$DISK:[JOE.DOC]")
    
+          ("EXPERIMENTAL;*;*.*.*"  "MY-UNIX:/usr/Joe/development/prog/*/")
    
+          ("MAIL;**;*.MAIL"        "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))
    
+
    
+  ;Sample use of that logical pathname.  All return values
    
+  ;are of course implementation-specific.
    
+  (translate-logical-pathname "prog:mail;save;ideas.mail.3")
    
+  => MY-VAX:SYS$DISK:[JOE.MAIL.PROG.SAVE]IDEAS.MBX.3
    
+
    
+  ;Example translations for a program that uses three files main.lisp,
    
+  ;auxiliary.lisp, and documentation.lisp.  These translations might be
    
+  ;supplied by a software supplier as examples.
    
+
    
+  ;For Unix with long file names
    
+  (setf (logical-pathname-translations "prog")
    
+        '(("CODE;*.*.*"             "/lib/prog/")))
    
+
    
+  ;Sample use of that logical pathname.  All return values
    
+  ;are of course implementation-specific.
    
+  (translate-logical-pathname "prog:code;documentation.lisp")
    
+  => /lib/prog/documentation.lisp
    
+
    
+  ;For Unix with 14-character file names, using .lisp as the type
    
+  (setf (logical-pathname-translations "prog")
    
+        '(("CODE;DOCUMENTATION.*.*" "/lib/prog/docum.*")
    
+          ("CODE;*.*.*"             "/lib/prog/")))
    
+
    
+  ;Sample use of that logical pathname.  All return values
    
+  ;are of course implementation-specific.
    
+  (translate-logical-pathname "prog:code;documentation.lisp")
    
+  => /lib/prog/docum.lisp
    
+
    
+  ;For Unix with 14-character file names, using .l as the type
    
+  ;The second translation shortens the compiled file type to .b
    
+  (setf (logical-pathname-translations "prog")
    
+        `(("**;*.LISP.*"            ,(logical-pathname "PROG:**;*.L.*"))
    
+          (,(compile-file-pathname (logical-pathname "PROG:**;*.LISP.*"))
    
+                                    ,(logical-pathname "PROG:**;*.B.*"))
    
+          ("CODE;DOCUMENTATION.*.*" "/lib/prog/documentatio.*")
    
+          ("CODE;*.*.*"             "/lib/prog/")))
    
+
    
+  ;Sample use of that logical pathname.  All return values
    
+  ;are of course implementation-specific.
    
+  (translate-logical-pathname "prog:code;documentation.lisp")
    
+  => /lib/prog/documentatio.l
    
+
    
+  ;For a Cray with 6 character names and no directories, types, or versions.
    
+  (setf (logical-pathname-translations "prog")
    
+        (let ((l '(("MAIN" "PGMN")
    
+                   ("AUXILIARY" "PGAUX")
    
+                   ("DOCUMENTATION" "PGDOC")))
    
+              (logpath (logical-pathname "prog:code;"))
    
+              (phypath (pathname "XXX")))
    
+          (append
    
+            ;; Translations for source files
    
+            (mapcar #'(lambda (x)
    
+                        (let ((log (first x))
    
+                              (phy (second x)))
    
+                          (list (make-pathname :name log
    
+                                               :type "LISP"
    
+                                               :version :wild
    
+                                               :defaults logpath)
    
+                                (make-pathname :name phy
    
+                                               :defaults phypath))))
    
+                    l)
    
+            ;; Translations for compiled files
    
+            (mapcar #'(lambda (x)
    
+                        (let* ((log (first x))
    
+                               (phy (second x))
    
+                               (com (compile-file-pathname
    
+                                      (make-pathname :name log
    
+                                                     :type "LISP"
    
+                                                     :version :wild
    
+                                                     :defaults logpath))))
    
+                          (setq phy (concatenate 'string phy "B"))
    
+                          (list com
    
+                                (make-pathname :name phy
    
+                                               :defaults phypath))))
    
+                    l))))
    
+
    
+  ;Sample use of that logical pathname.  All return values
    
+  ;are of course implementation-specific.
    
+  (translate-logical-pathname "prog:code;documentation.lisp")
    
+  => PGDOC
    
+
    
+Rationale:
    
+
    
+  1. Large programs can be moved between sites without changing any
    
+  pathnames, provided all pathnames used are logical.  A portable system
    
+  construction tool can be created that operates on programs defined as
    
+  sets of files named by logical pathnames.
    
+
    
+  2. Logical pathname syntax was chosen to be easily translated into most
    
+  popular file systems, while still being powerful enough for storing large
    
+  programs.  Although they have hierarchical directories, extended wildcard
    
+  matching, versions, and no limit on the length of names, they can be
    
+  mapped onto a less capable real file file system by translating each
    
+  directory that is used into a flat directory name, doing wildcards in
    
+  Lisp rather than in the file system, treating all versions as :newest,
    
+  and/or using translations to shorten long names.
    
+
    
+  Logical pathname words are restricted to non-case-sensitive letters,
    
+  digits, and hyphens to avoid creating problems with real file systems
    
+  that support limited character sets for file naming.  Other characters
    
+  could have been mapped onto such file systems through translations, but
    
+  that didn't seem worth the trouble.  Logical pathnames have to be
    
+  non-case-sensitive or it would be very difficult to map them onto a
    
+  non-case-sensitive file system.
    
+
    
+  Features such as :UP and :BACK relative directories and a namestring
    
+  syntax for the root directory were not felt to be necessary in logical
    
+  pathnames.  They could be added later if a need emerges.
    
+
    
+  It is not a goal of logical pathnames to be able to represent all
    
+  possible file names.  Their goal is rather to represent just enough file
    
+  names to be useful for storing software.  Real pathnames, in contrast,
    
+  need to provide a uniform interface to all possible file names, including
    
+  names and naming conventions that are not under the control of Common
    
+  Lisp.
    
+
    
+  The choice of logical pathname syntax, using colon, semicolon, and
    
+  period, was guided by the goals of being visually distinct from real file
    
+  systems and minimizing the use of special characters.
    
+
    
+  The consequences of using any value not specified here as a logical
    
+  pathname component are unspecified, for the benefit of the Explorer.
    
+
    
+  3. The LOGICAL-PATHNAME function is separate from the PATHNAME function
    
+  so that the syntax of logical pathname namestrings does not constrain the
    
+  syntax of physical pathname namestrings in any way.  Logical pathname
    
+  syntax must be defined by Common Lisp so that logical pathnames can be
    
+  conveniently exchanged between implementations, but physical pathname
    
+  syntax is dictated by forces outside our control.
    
+
    
+  3b,c. Allowing PARSE-NAMESTRING and MERGE-PATHNAMES to recognize logical
    
+  pathname namestrings in these situations provides for natural operations
    
+  on logical pathnames.  Frequently a string containing just a name, or a
    
+  name and a type, will be recognized as a logical pathname by merging it
    
+  against a default containing a logical pathname host and directory.
    
+
    
+  3d. Recognition of logical pathname namestrings by PATHNAME and related
    
+  functions is left up to each implementation because some implementations
    
+  definitely require this, other implementations don't want to do this, and
    
+  nobody wants to change.  In any case, Common Lisp historically has avoided
    
+  saying anything about the syntax of the strings accepted by the PATHNAME
    
+  function, and point 3d preserves that position.
    
+
    
+  3b,7f. Leaving it implementation defined whether a string, used as the
    
+  host argument to PARSE-NAMESTRING or the :host argument to MAKE-PATHNAME,
    
+  can be recognized as logical pathname host name is for the same reason as
    
+  point 3d.  It allows each implementation to decide whether there is one
    
+  namespace or two.  The correct way to write this is:
    
+
    
+    (MAKE-PATHNAME :HOST (PATHNAME-HOST (LOGICAL-PATHNAME "hostname:"))
    
+                   ...)
    
+
    
+  4. Logical pathname versions could have been supported on real file
    
+  systems that do not have versions by defining a kind of translation to
    
+  encode the version number in the name.  However, the typical use of
    
+  versions is such that on a file system without versions, people would
    
+  rather just store one version of a file, and not preserve the version
    
+  information by encoding it somehow in the name.  This is different from
    
+  the typical use of types or directories, where the files with different
    
+  values in those components are truly distinct and everything would break
    
+  if you only kept one file.
    
+
    
+  5,13. The COMPILE-FILE-PATHNAME function and the specification of "LISP"
    
+  as the type of a logical pathname for a Common Lisp source file together
    
+  provide enough information about compilation for a portable system
    
+  construction tool that uses logical pathnames to work.  Suppose you want
    
+  to call COMPILE-FILE only if the source file is newer than the compiled
    
+  file.  To do that, you have to have a way to know the name of the
    
+  compiled file without actually calling COMPILE-FILE.
    
+  No standard file type for compiler output is proposed, because in some
    
+  implementations the compiler produces one of several file types,
    
+  depending on a variety of implementation-dependent circumstances.
    
+  COMPILE-FILE-PATHNAME provides access to the "default[ing] in a manner
    
+  appropriate to the implementation's file system conventions" mentioned in
    
+  the CLtL documentation of COMPILE-FILE.
    
+
    
+  6. The use of the logical pathname host name "SYS" for the implementation
    
+  is current practice.  Standardizing on this name helps users choose
    
+  logical pathname host names that avoid conflicting with
    
+  implementation-defined names.
    
+
    
+  7. Accepting logical pathnames for file access is a natural extension
    
+  of the file access functions and makes it easier to program using only
    
+  logical pathnames in situations where that is appropriate.
    
+
    
+  8. The LOGICAL-PATHNAME class exists so that methods can distinguish
    
+  logical pathnames from regular pathnames.
    
+
    
+  9. See point 3 above.
    
+
    
+  10. TRANSLATE-LOGICAL-PATHNAME is the heart of the logical pathname
    
+  feature.  Allowing TRANSLATE-LOGICAL-PATHNAME on a physical pathname,
    
+  simply returning the argument, makes some programs easier to write.
    
+  Additional implementation defined translations make it possible for
    
+  implementations with unusual file systems to offer some help to the user
    
+  in setting up the translations for a logical pathname host, by handling
    
+  some of the work automatically.  Logical pathnames that translate to
    
+  other logical pathnames are a feature that several people have requested.
    
+
    
+  11. SETF of LOGICAL-PATHNAME-TRANSLATIONS is a simple way for a user to
    
+  define a new logical pathname host.  Using SETF makes it possible to add
    
+  to or modify the translations of an existing logical pathname host.
    
+
    
+  It is always up to the person who writes the translation rules for a
    
+  particular logical pathname host to a particular physical file system to
    
+  make sure that the logical pathnames that are actually going to be used
    
+  translate to valid pathnames for the particular file system, and that
    
+  no two logical pathnames that are supposed to be distinct translate to
    
+  the same physical pathname.
    
+
    
+  12. Loading of logical pathname translations from a site-dependent file
    
+  allows software to be distributed using logical pathnames.  The assumed
    
+  model of software distribution is a division of labor between the
    
+  supplier of the software and the user installing it.  The supplier
    
+  chooses logical pathnames to name all the files used or created by the
    
+  software, and supplies examples of logical pathname translations for a
    
+  few popular file systems.  Each example uses an assumed directory and/or
    
+  device name, assumes local file naming conventions, and provides
    
+  translations that will translate all the logical pathnames used or
    
+  generated by the particular software into valid physical pathnames.
    
+  For a powerful file system these translations can be quite simple.  For
    
+  a more restricted file system, it may be necessary to list an explicit
    
+  translation for every logical pathname used, for example when dealing
    
+  with restrictions on the maximum length of a file name.
    
+
    
+  The user installing the software decides on which device and/or directory
    
+  to store the files and edits the example logical pathname translations
    
+  accordingly.  If necessary, the user also adjusts the translations for
    
+  local file naming conventions and any other special aspects of the user's
    
+  local file system policy and local Common Lisp implementation.  For
    
+  example, the files might be divided among several file server hosts to
    
+  share the load.  The process of defining site-customized logical pathname
    
+  translations is quite easy for a user of a popular file system for which
    
+  the software supplier has provided an example.  A user of a more unusual
    
+  file system might have to take more time; the supplier can help by
    
+  providing a list of all the logical pathnames used or generated by the
    
+  software.
    
+
    
+  Once the user has created a suitable SETF of LOGICAL-PATHNAME-TRANSLATIONS
    
+  form, he can evaluate that form and then load and run the software.  It
    
+  may be necessary to use the translations again, or on another workstation
    
+  at the same site, so it is best to save the SETF form in the standard
    
+  place where it can be found later by LOAD-LOGICAL-PATHNAME-TRANSLATIONS.
    
+  Often a software supplier will include a program for restoring software
    
+  from the distribution medium to the file system, and a program for loading
    
+  the software from the file system into a Common Lisp, and these programs
    
+  will start by calling LOAD-LOGICAL-PATHNAME-TRANSLATIONS to make sure that
    
+  the logical pathname host is defined.
    
+
    
+  Note that the SETF of LOGICAL-PATHNAME-TRANSLATIONS form isn't part of
    
+  the program, it's separate.  It's written by the user, not by the
    
+  software supplier.  That separation, and a uniform convention for how to
    
+  do the separation, are the key aspects of logical pathnames.  For small
    
+  programs involving only a handful of files, it doesn't matter much.  The
    
+  real benefits come with large programs with hundreds or thousands of
    
+  files and more complicated situations such as program-generated file
    
+  names or porting a program developed on a system with long file names
    
+  onto a system with a very restrictive limit on the length of file names.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera has had a similar facility for many years.  It is used
    
+  extensively for software distribution by Symbolics and its customers.
    
+  The Genera facility uses the same logical pathname syntax but different
    
+  function names, and is somewhat more complicated.  The extra complexity
    
+  is not necessary in the Common Lisp standard.
    
+
    
+  The T.I. Explorer also has a comparable logical pathname facility,
    
+  although the translation mechanism is unfortunately less general than
    
+  proposed here.  The namestring syntax used is slightly different:
    
+  
    
+    host ":" [{directory "."}* directory ";"] [name] ["." type] ["#" version]
    
+  
    
+  The newest version is indicated by ">" instead of "newest".
    
+
    
+  Macintosh Allegro Common Lisp) has a logical pathname feature which is
    
+  somewhat simpler but aimed at solving the same problems.  It has logical
    
+  directory names, to simplify access to sets of files in differently named
    
+  directories (an especially severe problem on micros where everybody just
    
+  has to have a different pet name for their hard disk).  This isn't really
    
+  the same as simplifying access to different file systems, although of
    
+  course solving the latter automatically solves the former.  In general,
    
+  access to different file systems requires translating names and types,
    
+  not just translating directories.
    
+
    
+  Symbolics Genera offers a function for translating from a physical
    
+  pathname back to a logical pathname.  There are a number of problems with
    
+  this, and so it has not been proposed here.  An earlier version specified
    
+  TRANSLATE-LOGICAL-PATHNAME to return enough information to allow the user
    
+  program to perform the backtranslation itself, but that hsd problems
    
+  so it was removed.
    
+
    
+  The Genera equivalent of LOAD-LOGICAL-PATHNAME-TRANSLATIONS looks for
    
+  a file named SYS:SITE;hostname.TRANSLATIONS.
    
+
    
+  Current practice in Genera, Explorer, and Macintosh has one namespace for
    
+  both logical and physical namestrings.  This proposal allows an
    
+  implementation to choose to have one namespace or to have two separate
    
+  namespaces for namestrings.
    
+
    
+Cost to Implementors:
    
+
    
+  This is a fairly complex facility, but its performance is unimportant
    
+  so a straightforward implementation should suffice.  Most of the
    
+  complexity comes in dealing with unusual file systems, such as ones
    
+  that don't allow long file names.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Portable software construction and distribution will have to rely on
    
+  implementation-dependent kludges.  Lisp software will continue to be
    
+  difficult to install.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Avoid cost of non-adoption.
    
+
    
+Esthetics:
    
+
    
+  Improved portability of large programs.
    
+
    
+Discussion:
    
+
    
+  Issue PATHNAME-LOGICAL fundamentally depends on issue PATHNAME-WILD.  If
    
+  PATHNAME-WILD:NEW-FUNCTIONS does not pass, PATHNAME-LOGICAL cannot pass.
    
+
    
+  If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT passes, it will affect the
    
+  behavior of the function TRANSLATE-PATHNAME and therefore the behavior of
    
+  the function TRANSLATE-LOGICAL-PATHNAME.  When a logical pathname
    
+  translation has from-wildcard and to-wildcard type components that are
    
+  :WILD or omitted, translation of the type will be guided by canonical
    
+  types.  If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT fails to pass, it will
    
+  either have to be done behind the scenes by TRANSLATE-PATHNAME or users
    
+  will have to write more verbose translations that individually specify
    
+  the handling of each file type (as shown in some of the examples here).
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260.htm new file mode 100644 index 00000000..a316e7f1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue PATHNAME-PRINT-READ:SHARPSIGN-P Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-PRINT-READ:SHARPSIGN-P Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-PRINT-READ:SHARPSIGN-P:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260_w.htm new file mode 100644 index 00000000..75e4fc35 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss260_w.htm @@ -0,0 +1,157 @@ + + + +CLHS: Issue PATHNAME-PRINT-READ Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-PRINT-READ Writeup

    + +
    Status:		Passed, as amended, Jun89 X3J13
    
+
    
+Issue:        PATHNAME-PRINT-READ
    
+References:   File System Interface (pp409-427)
    
+Category:     CHANGE/ADDITION
    
+Edit history: 21-Oct-88, Version 1 by Pitman
    
+		3-Jul-89, Version 2 by Masinter
    
+
    
+Problem Description:
    
+
    
+  Although pathnames are required to print re-readably, there is no
    
+  standardized representation for pathnames and so no standardized
    
+  way in which they should print.
    
+
    
+  Further, it is common in programs to want pathnames to print in
    
+  their file-system specific format.
    
+
    
+Proposal (PATHNAME-PRINT-READ:SHARPSIGN-P):
    
+
    
+  Define the reader syntax #P"..." to be equivalent to 
    
+  #.(PARSE-NAMESTRING "...").
    
+
    
+  Define that when *PRINT-ESCAPE* is true, the syntax #P"..." is
    
+  how a pathname should be printed by WRITE (and hence by PRIN1,
    
+  PRINT, etc.). The "..." is the namestring representation of the
    
+  pathname.
    
+
    
+  Define that when *PRINT-ESCAPE* is NIL, WRITE writes a pathname
    
+  object P by writing (NAMESTRING p) instead.
    
+
    
+Test Case:
    
+
    
+  (PARSE-NAMESTRING "foo.lisp")
    
+  => #P"foo.lisp"
    
+
    
+  (FORMAT NIL "Written to ~A." #P"foo.bin")
    
+  => "Written to foo.bin."
    
+
    
+  (TYPEP #P"foo.bin" 'PATHNAME)
    
+  => T
    
+
    
+Rationale:
    
+
    
+  This satisfies the stated goals.
    
+
    
+  [For :ESCAPE T] It will not be possible to make the printed
    
+  pathname printed representation totally portable because of
    
+  variations in file systems, but for different Common Lisp
    
+  implementations on the same file system, or for Common Lisp
    
+  systems running on file systems having compatible syntax,
    
+  portability would be improved by this specification.
    
+
    
+  Also, some implementations (eg, Symbolics Genera) use
    
+  specialized representations for pathnames on different file
    
+  systems. Eg, an MSDOS pathname is of type MSDOS-PATHNAME,
    
+  not just type PATHNAME. #S(PATHNAME ...) is not only more
    
+  verbose than necessary but might be misleading to some users
    
+  because the object created will not have a TYPE-OF PATHNAME.
    
+
    
+  [For :ESCAPE NIL] Printing the namestring of a pathname is
    
+  a common operation and it is convenient to have a shorthand
    
+  for doing it. Further, some implementations may be able to
    
+  optimize the presentation of a pathname in this mode by
    
+  printing it without actually consing the string.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera implements the proposed behavior.
    
+
    
+Cost to Implementors:
    
+
    
+  Fairly minor changes to the readtable and the printer.
    
+
    
+Cost to Users:
    
+
    
+  Users who now use the non-portable syntax #S(...) in order
    
+  to enter literal pathnames might have to change. [However,
    
+  implementations would be free to continue to support this
    
+  read syntax for compatibility.]
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Portability of code and data involving pathnames within a
    
+  given file system (or between suitably similar file systems)
    
+  would be hampered needlessly.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  The #P syntax is pretty and hides unimportant details.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this change.
    
+
    
+-----
    
+Summary of discussion on CL-Cleanup:
    
+
    
+ EB noted that Lucid CL implements the proposed behavior and that there
    
+  is cost to users who define their own #P read macro. He weakly supports
    
+  the proposal but wishes someone had pursued a `generic pathnames' proposal.
    
+
    
+ Pierson noted that KCL uses #"...", but that this collides with proposed
    
+  syntax for Dick Waters' pretty printer. He also thinks #P is better
    
+  because it is already more widely used for that purpose.
    
+
    
+ Masinter noted that Envos Medley prints pathnames with the syntax
    
+  #.(pathname "asdf"), which he thinks is not as pretty as #P"asdf"
    
+  but currently more portable.
    
+
    
+ KMP and JonL raised the issues that #. has the disadvantage that it must
    
+  be parsed by the full Lisp engine, while #P can be parsed by something
    
+  simpler.  Permitting #. leaves a gaping hole for trojan horses, and
    
+  also requires the presence of the evaluator in a delivery system.
    
+
    
+ MLY, GSB, Peirson, and IIM argued for not using up an extra dispatch
    
+ character.
    
+
    
+ MLY suggested #S(PATHNAME namestring [optional-host]).
    
+
    
+ IIM noted they use #.(PATHNAME namestring host) because different file
    
+  systems have different parsing conventions. 
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261.htm new file mode 100644 index 00000000..0cde7e06 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261.htm @@ -0,0 +1,45 @@ + + + +CLHS: Issue PATHNAME-STREAM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-STREAM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-STREAM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_m.htm new file mode 100644 index 00000000..b06890eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue PATHNAME-STREAM Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue PATHNAME-STREAM Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_w.htm new file mode 100644 index 00000000..5b4036b6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss261_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue PATHNAME-STREAM Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-STREAM Writeup

    + +
    Issue:         PATHNAME-STREAM
    
+
    
+References:    PATHNAME (p.413), also the introductory text right above
    
+               it on the same page.
    
+               Derived references: TRUENAME (p.413), PARSE-NAMESTRING (p.414),
    
+               MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
    
+               OPEN (p.418), WITH-OPEN-FILE (p.422),
    
+               RENAME-FILE (p.423), DELETE-FILE (p.424)
    
+
    
+Edit History:  Version 1 by Moon 11-May-87
    
+               Version 2 by Masinter 29-May-87 (minor editing)
    
+               Version 3 by Masinter 11-Jun-87 (minor editing)
    
+               Version 4 by Masinter  8-Oct-87 (rewording)
    
+               Version 5 by Masinter  8-Oct-87 (explicitly only open)
    
+               Version 6 by Masinter 14-Nov-87
    
+
    
+Category:     	CHANGE/CLARIFICATION
    
+
    
+Problem Description:
    
+
    
+CLtL says that a stream can be used as an argument and converted to a pathname,
    
+but many sources or sinks of data that streams might be connected to have no
    
+pathnames associated with them; for example, streams created with
    
+MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no
    
+simple way to coerce such a stream to a pathname.
    
+
    
+Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
    
+
    
+Clarify that the use of a stream as an argument that expects a pathname (as
    
+described on p413 of CLtL) only applies to streams that are originally opened by
    
+use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound
    
+to such a stream. It is an error to attempt to obtain a pathname from a stream
    
+created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
    
+MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM,
    
+MAKE-STRING-OUTPUT-STREAM.
    
+
    
+The pathname used represents the name used to open the file. This may be, but is
    
+not required to be, the actual name of the file. The pathname used is the same
    
+as would be returned by the PATHNAME function.
    
+
    
+Rationale:
    
+
    
+This is probably what the designers of Common Lisp intended. This is the only
    
+thing that can be implemented without large changes to the language such as
    
+extending pathnames to things other than files. 
    
+
    
+Current Practice:
    
+
    
+Some systems signal an error if a non-file stream is used as a pathname. Others
    
+return an empty pathname.
    
+
    
+Some implementations do not return a meaningful value for PATHNAME of a synonym
    
+stream.
    
+
    
+Adoption Cost:
    
+
    
+Implementations that do not currently handle PATHNAME of a synonym stream will
    
+have to change to allow it. Otherwise, since the proposal says only "is an
    
+error" rather than "signals an error", no implementations other changes are
    
+necessary.
    
+
    
+Benefits:
    
+
    
+The description of pathname functions will make more sense.
    
+
    
+Conversion Cost: 
    
+
    
+Small: Users with code which accesses pathname components of streams in
    
+implementations which allow it might need to change their programs to make them
    
+portable.
    
+
    
+Aesthetics:
    
+
    
+Makes language a little cleaner.
    
+
    
+Discussion: 
    
+
    
+The only point of disagreement on this proposal has been on the issue of whether
    
+PATHNAME applies to synonym streams and returns the pathname of the stream
    
+designated. 
    
+
    
+This version of the proposal says yes, because CLtL p 329 says about synonym
    
+streams that  "Any operations on the new stream ..." and does not say anything
    
+about exceptions; earlier on the page the phrase "synonym streams that pass all
    
+operations on" is used.  This seems fairly unambiguous, although the word
    
+"operations" is not defined. There was a similar controversy about what CLOSE of
    
+a synonym stream means.
    
+
    
+Note that there is currently no way portable to determine whether a stream has a
    
+pathname available. 
    
+
    
+The entire PATHNAME section needs work to clarify the intent and enable portable
    
+code. This is just a minor issue among the major ones.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss262.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss262.htm new file mode 100644 index 00000000..43682f7e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss262.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue PATHNAME-STREAM:FILES-OR-SYNONYM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-STREAM:FILES-OR-SYNONYM Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue PATHNAME-STREAM:FILES-OR-SYNONYM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263.htm new file mode 100644 index 00000000..68579308 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263.htm @@ -0,0 +1,41 @@ + + + +CLHS: Issue PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263_w.htm new file mode 100644 index 00000000..c3c4abde --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss263_w.htm @@ -0,0 +1,334 @@ + + + +CLHS: Issue PATHNAME-SUBDIRECTORY-LIST Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-SUBDIRECTORY-LIST Writeup

    + +
    Status: passed, as amended, Jun 89 X3J13
    
+Issue:          PATHNAME-SUBDIRECTORY-LIST
    
+References:     Pathnames (pp410-413), MAKE-PATHNAME (p416),
    
+                PATHNAME-DIRECTORY (p417)
    
+Related-issues: PATHNAME-COMPONENT-CASE, PATHNAME-COMPONENT-VALUE
    
+Category:       CHANGE
    
+Edit history:   18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
    
+                05-Jul-88, Version 2 by Pitman (major revision)
    
+                28-Dec-88, Version 3 by Pitman (merge discussion)
    
+                22-Mar-89, Version 4 by Moon (fix based on discussion)
    
+                19-May-89, Version 5 by Moon (improve based on mail)
    
+                21-May-89, Version 6 by Moon (final cleanups)
    
+                17-Jun-89, Version 7 by Moon (add current practice
    
+                        and discussion; minor fixes based on discussion)
    
+                2-Jul-89, Version 8 by Masinter (add Jun89X3J13 amendment)
    
+
    
+Problem Description:
    
+
    
+  It is impossible to write portable code that can produce a pathname
    
+  in a subdirectory of a hierarchical file system. This defeats much of
    
+  the purpose of the pathname abstraction.
    
+
    
+  According to CLtL, only a string is a portable value for the directory
    
+  component of a pathname.  Thus in order to denote a subdirectory, the use
    
+  of punctuation characters (such as dots, slashes, or backslashes) would
    
+  be necessary. The very fact that such syntax varies from host to host
    
+  means that although the representation might be "portable", the code
    
+  using that representation is not portable.
    
+
    
+  This problem is even worse for programs running on machines on a network
    
+  that can retrieve files from multiple hosts, each using a different OS
    
+  and thus different subdirectory punctuation.
    
+
    
+  Related problems:
    
+
    
+  - In some implementations "FOO.BAR" might denote the "BAR" subdirectory
    
+    of "FOO", while in other implementations it would denote a top-level
    
+    directory, because "." is not treated as punctuation. To be safe,
    
+    portable programs must avoid all potential punctuation characters.
    
+
    
+  - Even in implementations where "." is used for subdirectories,
    
+    "FOO.BAR" may be recognized by some to mean the "BAR" subdirectory of
    
+    "FOO" and by others to mean `a seven character directory name with "."
    
+    as the fourth character.'
    
+
    
+  - In fact, CLtL does not even say whether punctuation characters are
    
+    part of the string. eg, is "foo" or "/foo" the directory component for
    
+    a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the
    
+    directory component for a VMS pathname "[FOO]ME.LSP"?
    
+    PATHNAME-COMPONENT-VALUE:SPECIFY says punctuation characters are not
    
+    part of the string.
    
+
    
+Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
    
+
    
+  Remove the "structured" directory feature mentioned on CLtL p.412.
    
+  
    
+  Allow the value of a pathname's directory component to be a list.  The
    
+  car of the list is one of the symbols :ABSOLUTE or :RELATIVE.
    
+  Each remaining element of the list is a string or a symbol (see below).
    
+  Each string names a single level of directory structure.  The strings
    
+  should contain only the directory names themselves -- no punctuation
    
+  characters.
    
+
    
+  A list whose car is the symbol :ABSOLUTE represents a directory path
    
+  starting from the root directory.  The list (:ABSOLUTE) represents
    
+  the root directory.  The list (:ABSOLUTE "foo" "bar" "baz") represents
    
+  the directory called "/foo/bar/baz" in Unix [except possibly for
    
+  alphabetic case -- that is the subject of a separate issue].
    
+
    
+  A list whose car is the symbol :RELATIVE represents a directory path
    
+  starting from a default directory.  The list (:RELATIVE) has the same
    
+  meaning as NIL and hence is not used.  The list (:RELATIVE "foo" "bar")
    
+  represents the directory named "bar" in the directory named "foo" in the
    
+  default directory.
    
+
    
+  In place of a string, at any point in the list, symbols may occur to
    
+  indicate special file notations. The following symbols have standard
    
+  meanings.  Implementations are permitted to add additional objects of any
    
+  non-string type if necessary to represent features of their file systems
    
+  that cannot be represented with the standard strings and symbols.
    
+  Supplying any non-string, including any of the symbols listed below, to a
    
+  file system for which it does not make sense signals an error of type
    
+  FILE-ERROR.  For example, Unix does not support :WILD-INFERIORS in
    
+  most implementations.
    
+
    
+   :WILD           - Wildcard match of one level of directory structure.
    
+   :WILD-INFERIORS - Wildcard match of any number of directory levels.
    
+   :UP             - Go upward in directory structure (semantic).
    
+   :BACK           - Go upward in directory structure (syntactic).
    
+
    
+  :ABSOLUTE or :WILD-INFERIORS immediately followed by :UP or :BACK
    
+  signals an error.
    
+
    
+  "Syntactic" means that the action of :BACK depends only on the pathname
    
+  and not on the contents of the file system.  "Semantic" means that the
    
+  action of :UP depends on the contents of the file system; to resolve
    
+  a pathname containing :UP to a pathname whose directory component
    
+  contains only :ABSOLUTE and strings requires probing the file system.
    
+  :UP differs from :BACK only in file systems that support multiple
    
+  names for directories, perhaps via symbolic links.  For example,
    
+  suppose that there is a directory
    
+    (:ABSOLUTE "X" "Y" "Z")
    
+  linked to 
    
+    (:ABSOLUTE "A" "B" "C")
    
+  and there also exist directories
    
+    (:ABSOLUTE "A" "B" "Q")
    
+    (:ABSOLUTE "X" "Y" "Q")
    
+  then
    
+    (:ABSOLUTE "X" "Y" "Z" :UP "Q")
    
+  designates
    
+    (:ABSOLUTE "A" "B" "Q")
    
+  while
    
+    (:ABSOLUTE "X" "Y" "Z" :BACK "Q")
    
+  designates
    
+    (:ABSOLUTE "X" "Y" "Q")
    
+
    
+  If a string is used as the value of the :DIRECTORY argument to
    
+  MAKE-PATHNAME, it should be the name of a toplevel directory and should
    
+  not contain any punctuation characters.  Specifying a string, str, is
    
+  equivalent to specifying the list (:ABSOLUTE str).  Specifying the symbol
    
+  :WILD is equivalent to specifying the list (:ABSOLUTE :WILD-INFERIORS),
    
+  or (:ABSOLUTE :WILD) in a file system that does not support :WILD-INFERIORS.
    
+
    
+  The PATHNAME-DIRECTORY function always returns NIL, :UNSPECIFIC, or a
    
+  list, never a string, never :WILD.
    
+
    
+  The list returned is not guaranteed to be "freshly consed" -- the
    
+  consequences of modifying this list is undefined.
    
+ 
    
+  In non-hierarchical file systems, the only valid list values for the
    
+  directory component of a pathname are (:ABSOLUTE string) and
    
+  (:ABSOLUTE :WILD).  :RELATIVE directories and the keywords
    
+  :WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
    
+  systems.
    
+
    
+  Pathname merging treats a relative directory specially.  Let
    
+  <pathname> and <defaults> be the first two arguments to
    
+  MERGE-PATHNAMES.  If (PATHNAME-DIRECTORY <pathname>) is a list whose
    
+  car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
    
+  the merged directory is the value of
    
+    (APPEND (PATHNAME-DIRECTORY <defaults>)
    
+            (CDR  ;remove :RELATIVE from the front
    
+              (PATHNAME-DIRECTORY <pathname>)))
    
+  except that if the resulting list contains a string or :WILD immediately
    
+  followed by :BACK, both of them are removed.  This removal of redundant
    
+  :BACKs is repeated as many times as possible.
    
+  If (PATHNAME-DIRECTORY <defaults>) is not a list or
    
+  (PATHNAME-DIRECTORY <pathname>) is not a list whose car is :RELATIVE, the
    
+  merged directory is
    
+    (OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))
    
+
    
+  A relative directory in the pathname argument to a function such as
    
+  OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
    
+  file system.
    
+
    
+Test Cases/Examples:
    
+
    
+  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
    
+  => (:ABSOLUTE "FOO" "BAR")
    
+
    
+  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
    
+  => (:ABSOLUTE "foo" "bar")
    
+  or (:ABSOLUTE "FOO" "BAR")
    
+  If PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT passes with a default of
    
+  :COMMON, the value is the second one shown.
    
+
    
+  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
    
+  => (:RELATIVE :UP)
    
+
    
+  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
    
+  => (:ABSOLUTE "foo" "bar" :UP "mum")
    
+
    
+  (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
    
+  => (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
    
+
    
+  (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
    
+  => (:ABSOLUTE "FOO" :WILD "BAR")
    
+
    
+Rationale:
    
+
    
+  This would allow programs to deal usefully with hierarchical file
    
+  systems, which are by far the most common file system type.
    
+  This would allow a system construction utility that organizes programs
    
+  by subdirectories to be portable to all implementations that have
    
+  hierarchical file systems.
    
+
    
+  Discussion indicated that "Implementations are permitted to add
    
+  additional objects of any non-string type if necessary to represent
    
+  features of their file systems that cannot be represented with the
    
+  standard strings and symbols" is a necessary escape hatch for things like
    
+  home directories and fancy pattern matching.  Implementations should
    
+  limit their use of this loophole and use the standard keyword symbols
    
+  whenever that is possible.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera implements something very similar to this. The main
    
+  differences are:
    
+   - In Genera, there is no :ABSOLUTE keyword at the head of the list.
    
+     This has been shown to cause some problems in dealing with root
    
+     directories. Genera represents the root directory by a keyword
    
+     symbol (rather than a list) because the list representation 
    
+     was not adequately general.
    
+   - Genera has no separate concepts of :UP and :BACK.  Genera
    
+     represents Unix ".." as :UP, but deals with :UP syntactically, not
    
+     semantically.
    
+
    
+  On the Explorer, the directory component is a list of strings, not yet
    
+  supporting the symbols specified in proposal PATHNAME-SUBDIRECTORY-LIST.
    
+
    
+  Macintosh Allegro Common Lisp 1.2.2 uses a string with punctuation
    
+  characters instead of a list for the directory.
    
+
    
+  Lucid Common Lisp 3.0.1 under Unix uses a list for directories of
    
+  somewhat different form from what is proposed in
    
+  PATHNAME-SUBDIRECTORY-LIST.  It uses :ROOT instead of :ABSOLUTE and uses
    
+  ".." instead of :UP.  It does use :RELATIVE.
    
+
    
+  Ibuki Common Lisp Release 01/01 uses a list for directories of somewhat
    
+  different form from what is proposed in PATHNAME-SUBDIRECTORY-LIST.  It
    
+  uses :ROOT instead of :ABSOLUTE, uses :PARENT instead of :UP, and omits
    
+  the leading keyword instead of using :RELATIVE.
    
+
    
+  IIM uses a list for directories of somewhat different form from what is
    
+  proposed in PATHNAME-SUBDIRECTORY-LIST.  It uses :ABSOLUTE-DIRECTORY
    
+  instead of :ABSOLUTE, uses :SUPER-DIRECTORY instead of :BACK, and omits
    
+  the leading keyword instead of using :RELATIVE.
    
+
    
+Cost to Implementors:
    
+
    
+  In principle, nothing about the implementation needs to change except
    
+  the treatment of the directory component by MAKE-PATHNAME and
    
+  PATHNAME-DIRECTORY. The internal representation can otherwise be left
    
+  as-is if necessary.
    
+
    
+  Implementations such as Genera, Explorer, Lucid, Ibuki, and IIM that
    
+  already have hierarchical directory handling will have to make an
    
+  incompatible change to switch to what is proposed here.
    
+
    
+  For implementations that choose to rationalize this representation
    
+  throughout their internals and any other implementation-specific
    
+  accessors, the cost will be necessarily higher.
    
+
    
+Cost to Users:
    
+
    
+  None for portable programs. This change is upward compatible with CLtL.
    
+  Nonportable programs will have to be changed if they use implementation
    
+  dependent hierarchical directory handling and the implementation
    
+  removes support for that when it adds support for this proposal.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Serious portability problems would continue to occur. Programmers would be
    
+  driven to the use of implementation-specific facilities because the need
    
+  for this is frequently impossible to ignore.
    
+
    
+Benefits:
    
+
    
+  The serious costs of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  This representation of hierarchical pathnames is easy to use and quite
    
+  general. Users will probably see this as an improvement in the aesthetics.
    
+
    
+Discussion:
    
+
    
+  This issue was raised a while back but no one was fond of the particular
    
+  proposal that was submitted. This is an attempt to revive the issue.
    
+
    
+  The original proposal, to add a :SUBDIRECTORIES component to a
    
+  pathname, was discarded because it imposed an unnatural distinction
    
+  between a toplevel directory and its subdirectories. Pitman's guess is
    
+  the the idea was to try to make it a compatible change, but since most
    
+  programmers will probably want to change from implementation-specific
    
+  primitives to portable ones anyway, that's probably not such a big
    
+  deal. Also, there could have been some programs which thought the
    
+  change was compatible and ended up ignoring important information (the
    
+  :SUBDIRECTORIES component). Pitman thought it would be better if
    
+  people just accepted the cost of an incompatible change in order to
    
+  get something really pretty as a result.
    
+
    
+  Some people feel it is unnecessary to standardize the format of
    
+  pathname components such as the directory.
    
+
    
+  Moon doesn't like having both :UP and :BACK, but admits that some
    
+  file systems do it one way and some do it the other.  He still thinks
    
+  it would be simpler if we got rid of :BACK and just had :UP.
    
+
    
+  To keep it simple, we chose not to add to this issue the functions
    
+  DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
    
+  the name of a directory from or to the directory component of a file
    
+  inferior to that directory.  This conversion is system-dependent, for
    
+  example TOPS-20 appends a type field and Unix does not.  Also in some
    
+  systems the root directory has a name and in others it doesn't.  Of
    
+  course these functions signal an error in non-hierarchical file
    
+  systems.  Examples (for Unix, assuming #P print syntax for pathnames):
    
+   (directory-pathname-as-file #P"/usr/bin/sh") => #P"/usr/bin"
    
+   (pathname-as-directory #P"/usr/bin") => #P"/usr/bin"/
    
+  These functions have not been proposed because they are mainly useful
    
+  in conjunction with additional functions for manipulating directories
    
+  (creating, expunging, setting access control) that have not been made
    
+  available in Common Lisp.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264.htm new file mode 100644 index 00000000..b861ff27 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue PATHNAME-SYMBOL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-SYMBOL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-SYMBOL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264_w.htm new file mode 100644 index 00000000..c159fc6f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss264_w.htm @@ -0,0 +1,143 @@ + + + +CLHS: Issue PATHNAME-SYMBOL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-SYMBOL Writeup

    + +
    Issue:		PATHNAME-SYMBOL
    
+
    
+References:   	PATHNAME (p.413),
    
+                Derived references: PARSE-NAMESTRING (p.414),
    
+                MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
    
+                NAMESTRING etc. (p.417), LOAD (p. 426), REQUIRE 
    
+                Cleanup issue PATHNAME-STREAM
    
+                Common LispCraft, Wilensky 1986, p 51
    
+
    
+
    
+Edit History:  Version 1 by Moon 11-May-87
    
+               Version 2 by Masinter 29-May-87
    
+               Version 3 by Masinter 23-Oct-87
    
+               Version 4 by Masinter 23-Nov-87
    
+               Version 5 by Masinter  5-Feb-88, fix minor typo
    
+
    
+
    
+Category:     	CHANGE
    
+
    
+Problem Description:
    
+
    
+Some Common Lisp functions are specified to accept a symbol where a pathname is
    
+expected.  Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are
    
+not specified to accept a symbol.
    
+
    
+Proposal PATHNAME-SYMBOL:NO
    
+
    
+Never allow symbols where pathnames are expected. More specifically, PATHNAME,
    
+TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE,
    
+PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
    
+FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING,
    
+REQUIRE are changed by this proposal to not allow symbols for their pathname
    
+argument.
    
+
    
+Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
    
+DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
    
+filename argument, and that DIRECTORY does not allow a symbol for its pathname
    
+argument. This is implied by the respective descriptions of those functions in
    
+CLtL, but not explicitly stated.
    
+
    
+Rationale:
    
+
    
+Allowing symbols for pathnames was based on an obsolete practice in MacLisp
    
+(which did not have strings) and causes much error-prone behavior.
    
+
    
+Current Practice:
    
+
    
+Varies.  Some implementations allow symbols here, some don't.  Symbolics doesn't
    
+allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them
    
+there is probably a bug in the implementation. 
    
+
    
+Cost to implementors:
    
+
    
+It's easy to change implementations to stop accepting symbols.  Since this
    
+appears to be an "is an error" rather than "signals an error" situation, no
    
+implementation change is actually necessary.
    
+
    
+Cost to users:
    
+
    
+Some users might be using symbols as pathnames, in implementations where that
    
+works, and they would have to switch to using strings. For example, some users
    
+are used to typing interactively (LOAD 'FOO) to mean (LOAD "FOO"). This is not
    
+explicitly allowed in CLtL, so such behavior has not been portable. However,
    
+such use is probably widespread among users of implementations that allow it
    
+(e.g., Common LISPCraft gives this form in an example.)
    
+
    
+Benefits:
    
+
    
+Pathname functions will be more consistent.  In implementations that check the
    
+type of this argument, program error checking will be improved. In dealing with
    
+case-sensitive file systems, users won't do (load 'foo) and wonder why file
    
+"FOO" (rather than "foo") is not found.
    
+
    
+One example of the type of bug caused by this occurs when NIL is erroneously
    
+substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table
    
+entry that was expected to exist and returned -false-.  In systems that accept
    
+symbols as pathnames, this causes a reference to a file named "NIL" on some
    
+perhaps unexpected directory.
    
+
    
+Aesthetics:
    
+
    
+Improved by the change.
    
+
    
+Discussion:
    
+
    
+Some users have reported that they thought MERGE-PATHNAMES was in error because
    
+it accepted symbols.
    
+
    
+We believe that this feature was accidentally introduced as a historical
    
+artifact and that it has limited utility. It is likely that the feature of
    
+accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied
    
+it from Maclisp.  The reason Maclisp allowed a symbol here was that it did not
    
+have strings at all.  While the feature was removed from Zetalisp before Common
    
+Lisp was defined due to the poor state of Zetalisp documentation at the time the
    
+change was overlooked by the designers of Common Lisp.
    
+
    
+If a symbol can be coerced into a string, and a string can be coerced into a
    
+pathname, why can't a symbol be coerced into a pathname? An explicit decision
    
+was made early in the design of CL not to make all coercions transitive.  For
    
+example, symbols coerce to strings (for string functions), and strings are
    
+sequences (and so can be mixed with other sequence types), but symbols are not
    
+sequences.
    
+
    
+There is some sentiment for extending COERCE to allow explicit coersion of
    
+STRINGs to PATHNAMEs, as a separate cleanup item.
    
+
    
+A careful reading of CLtL indicates that it is possible for an implementation to
    
+allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be
    
+disjoint.) While there is some sentiment for making this requirement in a
    
+separate cleanup issue, it would otherwise prevent both symbol->pathname and
    
+stream->pathname to have consistent meaning.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265.htm new file mode 100644 index 00000000..b3e919eb --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265_w.htm new file mode 100644 index 00000000..db4bccd4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss265_w.htm @@ -0,0 +1,238 @@ + + + +CLHS: Issue PATHNAME-SYNTAX-ERROR-TIME Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-SYNTAX-ERROR-TIME Writeup

    + +
    Issue:        PATHNAME-SYNTAX-ERROR-TIME
    
+References:   File System Interface (pp409-427)
    
+Category:     CLARIFICATION
    
+Edit history: 07-Jul-88, Version 1 by Pitman
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+  There exist conceivable pathnames for which there is no valid mapping in a
    
+  particular implementation. CLtL is not clear about the time at which this
    
+  error might be detected.
    
+
    
+  For example, on file systems which constrain pathname-types to be three
    
+  letters or fewer, the type "LISP" is not valid. The question arises: when
    
+  is this error detected?
    
+
    
+  In some implementations, the error might be detected while forming the
    
+  pathname. That is, (MAKE-PATHNAME :TYPE "LISP") signals an error.
    
+
    
+  In some implementations, the error might be detected while forming the
    
+  namestring. That is, (MAKE-PATHNAME :TYPE "LISP") succeeds, but
    
+  (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) signals an error.
    
+
    
+  In some implementations, validity checking might be done only by the host
    
+  operating system, so Lisp does not detect the error unless the operating
    
+  system complains. For example, (MAKE-PATHNAME :TYPE "LISP") succeeds,
    
+  and even (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) constructs a plausible
    
+  looking pathname, but (OPEN (NAMESTRING (MAKE-PATHNAME :TYPE "LISP"))) fails.
    
+
    
+  In some implementations, Lisp might make `friendly' corrections to the
    
+  pathname in order to form a namestring. For example,
    
+  (MAKE-PATHNAME :TYPE "LISP") might succeed, but 
    
+  (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) might produce a namestring with
    
+  an extension such as ".LIS" or ".LSP".
    
+
    
+  Similar issues might come up in file systems which don't allow wildcard
    
+  pathnames. Is :WILD allowed in a name or type slot and then disallowed
    
+  upon coercion to a pathname, or is :WILD complained about "up front"?
    
+
    
+  This phenomenon is a barrier to portability because if a program is
    
+  debugged in an implementation that does, for example, NAMESTRING-time
    
+  error checking, the programmer may be lulled into an expectation that
    
+  it is acceptable to construct and manipulate invalid pathnames as long
    
+  as the problem is caught before an attempt to call NAMESTRING is
    
+  attempted. On the other hand, another programmer may debug his code in
    
+  a Lisp which does early error checking of syntax and may assume that 
    
+  he is home free if the pathname gets constructed correctly.
    
+
    
+Proposal (PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION):
    
+
    
+  Clarify that operations such as MAKE-PATHNAME and MERGE-PATHNMES which
    
+  construct new pathnames do plausibility checking of their arguments
    
+  and signal an error rather than construct a pathname for which NAMESTRING
    
+  would not produce a valid pathname.
    
+
    
+  Rationale:
    
+
    
+    This would identify clearly to the programmer where he should expect an
    
+    error to be signalled for a pathname.
    
+
    
+    This would mean that fully constructed pathnames could reliably
    
+    be converted to namestrings.
    
+
    
+  Cost to Implementors:
    
+  
    
+    Some implementors, especially those which rely on the operating system
    
+    to be the sole authority on pathname syntax, might have to introduce
    
+    some new syntax-checking facilities.
    
+
    
+    Implementations where this error checking is done later would have to be
    
+    changed both to do it earlier, and to not make the unwarranted assumption
    
+    that pathnames with no valid namestring representation are constructable.
    
+
    
+  Cost to Users:
    
+
    
+    The ability to represent non-viable pathnames for the purpose of merging
    
+    would be lost. This feature was not portably available, but was available
    
+    in some operating systems.
    
+
    
+    Some code which expected an error, but expected it at a different time
    
+    would have to be changed.
    
+
    
+Proposal (PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION):
    
+
    
+  Clarify that it was valid to create a pathname which could not be
    
+  converted to a namestring. Require NAMESTRING (and related functions,
    
+  such as ENOUGH-NAMESTRING or any internal functions that might be used
    
+  in place of NAMESTRING by functions like OPEN and PROBE-FILE) to signal
    
+  an error for pathnames which do not represent valid filenames in the
    
+  designated file system.
    
+
    
+  Rationale:
    
+
    
+    This would identify clearly to the programmer where he should expect an
    
+    error to be signalled for a pathname.
    
+
    
+    This would allow the construction of pathnames for the sole purpose of
    
+    merging without causing what might seem to some as gratuitous errors.
    
+
    
+  Cost to Implementors:
    
+  
    
+    Implementors who rely on the operating system to be the sole authority
    
+    on pathname syntax, might have to introduce some new syntax-checking
    
+    facilities.
    
+
    
+    Implementations where this error checking is done earlier would have to
    
+    be changed both to do it later, and to not make the unwarranted
    
+    assumption that any pathname has a valid namestring representation.
    
+
    
+  Cost to Users:
    
+
    
+    Early error checking of faulty pathnames would be lost.
    
+
    
+    Some code which expected an error, but expected it at a different time
    
+    would have to be changed.
    
+
    
+  Benefits:
    
+  
    
+    Macsyma, for example, has encountered a need for "hostless" pathnames
    
+    (in merging). The concept makes no sense if every pathname must have
    
+    a namestring, because a pathname with no host cannot have a namestring.
    
+    However, if it's NAMESTRING's responsibility to signal an error, then
    
+    hostless pathnames are still useful for merging. Consider:
    
+	(MERGE-PATHNAMES (MAKE-PATHNAME :NAME "FRED") MARY)
    
+    This will override both the NAME and the HOST field of MARY because you
    
+    must currently have a host in every pathname. But if MAKE-PATHNAME did
    
+    not force the host, or if one could explicitly say :HOST NIL, then
    
+    such pathnames would be considerably more useful for merging.
    
+
    
+Proposal (PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE):
    
+
    
+  Clarify that we were unable to reach agreement on this issue and that
    
+  the time at which this error detection occurs is not well-specified.
    
+
    
+  Advise the editorial group to warn users clearly about this known source
    
+  of program portability problems.
    
+
    
+  Rationale:
    
+
    
+    This implements the status quo.
    
+
    
+  Cost to Implementors:
    
+  
    
+    None.
    
+
    
+  Cost to Users:
    
+
    
+    No existing code must be modified, but there is an ongoing cost
    
+    associated with providing error checking at multiple points in a
    
+    program because implementations disagree as to where an error
    
+    might be signalled. In some cases, the effects of having to handle
    
+    this in multiple places may cause unpleasant modularity violations.
    
+
    
+Test Case:
    
+
    
+  See problem description.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera signals an error at pathname construction time if a
    
+  pathname will be invalid. Once a pathname is successfully constructed,
    
+  it can generally be assumed that NAMESTRING will always succeed.
    
+
    
+Aesthetics:
    
+
    
+  Making this more well-defined would cause a definite aesthetic
    
+  improvement to some programs.
    
+
    
+Discussion:
    
+
    
+  Pitman prefers PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION but
    
+  believes that anything is an improvement over ...:EXPLICITLY-VAGUE.
    
+
    
+  CL pathname functions were not adequate for use in Macsyma because
    
+  they did not adequately represent to-be-merged-only pathnames (a
    
+  feature used very extensively in Macsyma), because errors could be
    
+  signalled at radically different times. To get around this, Pitman
    
+  had to create a data structure in Macsyma called an MPATHNAME which
    
+  was only trivially different than a PATHNAME but which made it
    
+  possible to deal portably with this issue of when errors occurred
    
+  and what kinds of errors occured. Unfortunately, since none of the
    
+  CL functions worked on MPATHNAMEs, a whole series of functions,
    
+  also only trivially different, had to be created: MAKE-MPATHNAME,
    
+  MNAMESTRING, MERGE-MPATHNAMES, MPATHNAME-NAME, MPATHNAME-TYPE, 
    
+  MOPEN, WITH-MOPEN-FILE, etc.
    
+
    
+------
    
+Summary of CL-Cleanup discussion:
    
+
    
+Most of the mail was endorsements for option PATHNAME-CREATION.
    
+Sandra brought up a tangential issue about truenames that eventually
    
+became a separate issue.
    
+
    
+I think I'm the only person pushing NAMESTRING-COERCION. I strongly
    
+believe it is the right thing, and that PATHNAME-CREATION is suboptimal,
    
+based on problems that have struck me with existing CL pathname system.
    
+However, even PATHNAME-CREATION would be an improvement from a
    
+portability standpoint and I am probably not going to push it because
    
+there are compatibility issues on the side of PATHNAME-CREATION (many
    
+implementations do this already), and because there are more important
    
+issues for us to spend time on at the meeting.
    
+
    
+[Please try to come prepared to vote yes on one or both of
    
+ PATHNAME-CREATION or NAMESTRING-COERCION so we don't have to fall back
    
+ on EXPLICITLY-VAGUE, which is a total loss for program portability.
    
+ -kmp]
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266.htm new file mode 100644 index 00000000..45c0bbda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266.htm @@ -0,0 +1,44 @@ + + + +CLHS: Issue PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266_w.htm new file mode 100644 index 00000000..1a2e7ca8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss266_w.htm @@ -0,0 +1,207 @@ + + + +CLHS: Issue PATHNAME-UNSPECIFIC-COMPONENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-UNSPECIFIC-COMPONENT Writeup

    + +
    Status:	      Accepted, as amended, Jan 89 X3J13
    
+Forum:        Cleanup
    
+Issue:        PATHNAME-UNSPECIFIC-COMPONENT
    
+Forum:        Cleanup
    
+References:   File System Interface (pp409-427)
    
+Category:     CHANGE
    
+Edit history: 27-Dec-88, Version 1 by Pitman
    
+	      17-Mar-89, Version 2 by Masinter (as amended)
    
+Subsumes:     Issue PATHNAME-TYPE-UNSPECIFIC
    
+
    
+Problem Description:
    
+
    
+  In some file systems, it is inappropriate to represent particular
    
+  pathname components, either all the time or in some specialized 
    
+  circumstance.
    
+
    
+   - Unix pathnames never have a version field.
    
+
    
+   - In some file systems, specifying a device and a directory means
    
+     something very different than specifying the device alone, 
    
+     particularly when the device is a "logical device" that may
    
+     already imply a directory.
    
+
    
+   - Some Unix pathnames have types and others do not. For example,
    
+     it is possible to make files named "foo." and "foo" which are
    
+     distinct. CLtL (p412) specifies that the type is ``always a
    
+     string, NIL, or :WILD.'' This description is too restrictive
    
+     to be practical in this case. One of these (usually the former)
    
+     can get a type of "" but it is not clear how to represent the
    
+     other. If NIL is used, merging primitives cannot detect that the
    
+     field is filled and should not be merged against. 
    
+
    
+   - ITS pathnames have either a version or a type, but never both.
    
+     "JOE;FILE 32" has a directory, a name, and a version.
    
+     "JOE;FILE TEXT" has a directory, a name, and a type.
    
+     "JOE;FILE TEXT 32" is not a possible ITS filename.
    
+
    
+Proposal (PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN):
    
+
    
+  Permit :UNSPECIFIC as a value of any field of a pathname,
    
+  including the HOST, DEVICE, DIRECTORY, NAME, TYPE, or
    
+  VERSION field of a pathname, for file systems in which it makes sense.
    
+
    
+  The results of supplying :UNSPECIFIC to a file system for which
    
+  it does not make sense are undefined.
    
+
    
+  When a pathname is converted to a namestring, NIL and :UNSPECIFIC
    
+  are treated as if the field were empty. That is, they both cause the
    
+  component not to appear in the string.
    
+
    
+  When merging, however, only a NIL value for a component will be
    
+  replaced with the default for that component, while :UNSPECIFIC
    
+  will be left alone as if the field were filled.
    
+
    
+  Portable programs should expect to find :UNSPECIFIC in the device,
    
+  directory, type, or version field in some implementations.
    
+
    
+  Portable programs should not explicitly place :UNSPECIFIC in any
    
+  field, since that it might not be permitted in some situations,
    
+  but portable programs may sometimes do so implicitly.
    
+
    
+Test Case:
    
+
    
+  ;; #1: Non-portable code. This may signal an error in some
    
+  ;;     implementations where an unspecific type makes no sense.
    
+
    
+  (MAKE-PATHNAME :TYPE :UNSPECIFIC)	;not portable
    
+
    
+  ;; #2: In this example, assume a Unix file system.
    
+
    
+  (PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
    
+  => ""
    
+
    
+  (PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
    
+  => :UNSPECIFIC
    
+
    
+  (PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
    
+				  (MAKE-PATHNAME :TYPE "BAR")))
    
+  => :UNSPECIFIC
    
+
    
+  ;; #3: In this example, assume an ITS file system.
    
+
    
+  (LET ((P (PARSE-NAMESTRING "FOO 32")))
    
+    (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
    
+  => (:UNSPECIFIC 32)
    
+
    
+  (LET ((P (PARSE-NAMESTRING "FOO TEXT")))
    
+    (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
    
+  => ("TEXT" :UNSPECIFIC)
    
+
    
+  (LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
    
+			    (PARSE-NAMESTRING "FOO TEXT"))))
    
+    (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
    
+  => (:UNSPECIFIC 32)
    
+
    
+  ;; Note: It is not the intent of this proposal to actually legislate
    
+  ;; the canonical representation of Unix pathnames "foo." and "foo",
    
+  ;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
    
+  ;; be done, but under separate cover. The above examples are intended
    
+  ;; only to demonstrate how this proposal will permit the representation
    
+  ;; of pathnames not usefully representable under CLtL.
    
+
    
+Rationale:
    
+
    
+  This is, by necessity, current practice in some implementations
    
+  already.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera uses a file types and versions of :UNSPECIFIC on
    
+  Unix and ITS file systems, for example.
    
+
    
+Cost to Implementors:
    
+
    
+  None. No change to any implementation is forced.
    
+
    
+  Some implementations which already do this are legitimized.
    
+
    
+  Some implementations which use a non-standard token other than 
    
+  :UNSPECIFIC to implement this functionality would want to switch
    
+  to use :UNSPECIFIC so that portable programs could expect it.
    
+
    
+Cost to Users:
    
+
    
+  Some programs which manipulate pathnames should be updated to expect
    
+  :UNSPECIFIC in the type fields in some situations.
    
+
    
+  Any program which doesn't already expect :UNSPECIFIC is already not really
    
+  portable, however, given that some implementations have been forced to
    
+  go beyond the standard in order to represent all possible pathnames.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some implementations would be unable to both represent all possible 
    
+  pathnames in a rational way and at the same time to conform to the
    
+  standard. Such an inability would seriously jeopardize the usefulness
    
+  of Common Lisp in the design of serious programs.
    
+
    
+Benefits:
    
+
    
+  Some programs involving pathnames would be more portable.
    
+
    
+Aesthetics:
    
+
    
+  Sweeping a hairy situation under the rug doesn't make it go away.
    
+  This change makes things appear less simple, but since in reality
    
+  they were less simple, it is effectively a simplification of the
    
+  correspondence between the CL model and reality.
    
+
    
+Discussion:
    
+
    
+  Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
    
+
    
+  This feature existed (for types) in the Colander draft edition of
    
+  CLtL, but was removed for the Laser edition. The following text is
    
+  excerpted from the Colander edition, p259:
    
+
    
+   ``??? Query: Is :unspecific really needed over and above nil?
    
+
    
+   ``A component of a pathname can also be the keyword
    
+     :UNSPECIFIC. This means that the component has been explicitly
    
+     determined not to be there, as opposed to be missing. One way
    
+     this can occur is with generic pathnames, which refer not to
    
+     a file but to a whole family of files. The version, and usually
    
+     the type, of a generic pathname are :unspecific. Another way
    
+     :unspecific is used to represent components that are not simply
    
+     supported by a file system. When a pathname is converted to a
    
+     namestring, nil and :unspecific both cause the component not to
    
+     appear in the string. When merging, however, a nil value for
    
+     a component will be replaced with the default for that
    
+     component, while :unspecific will be left alone.''
    
+
    
+"The stuff about generic pathnames in the discussion section
    
+was brain damage and may have lead to the confusion that caused
    
+:unspecific to be dropped from Common Lisp.  Only the stuff about
    
+components not supported by a file system makes sense."
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267.htm new file mode 100644 index 00000000..083a8cac --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267.htm @@ -0,0 +1,49 @@ + + + +CLHS: Issue PATHNAME-WILD:NEW-FUNCTIONS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PATHNAME-WILD:NEW-FUNCTIONS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PATHNAME-WILD:NEW-FUNCTIONS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267_w.htm new file mode 100644 index 00000000..060d8e85 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss267_w.htm @@ -0,0 +1,381 @@ + + + +CLHS: Issue PATHNAME-WILD Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PATHNAME-WILD Writeup

    + +
    Status: Passed, as amended, Jun 89 X3j13
    
+Issue:        PATHNAME-WILD
    
+Forum:        Cleanup
    
+References:   Pathnames (pp410-413)
    
+Related issues: PATHNAME-COMPONENT-VALUE, PATHNAME-LOGICAL
    
+Category:     ADDITION
    
+Edit history: 21-Jul-88, Version 1 by Pitman
    
+              06-Oct-88, Version 2 by Pitman
    
+               9-May-89, Version 3 by Moon (small fixes)
    
+              10-May-89, Version 4 by Moon (add two more functions)
    
+              13-May-89, Version 5 by Moon (minor cleanups, add clarification)
    
+              19-Jun-89, Version 6 by Moon (revise based on extensive
    
+                        discussion in the cleanup subcommittee; rewrite
    
+                        the description of TRANSLATE-PATHNAME so it is
    
+                        possible to understand it)
    
+              23-Jun-89, Version 7 by Moon (simplify TRANSLATE-PATHNAME
    
+                        based on last minute discussion of logical pathnames)
    
+	       2-Jul-89, Version 8 by Masinter (T -> True as per Jun89 X3J13)
    
+	
    
+Problem Description:
    
+
    
+  Some file systems provide more complex conventions for wildcards than
    
+  simple component-wise wildcards (:WILD). For example,
    
+
    
+  "F*O" might mean:
    
+    - a normal three character name
    
+    - a three-character name, with the middle char wild
    
+    - at least a two-character name, with the middle 0 or more chars wild
    
+    - a wild match spanning multiple directories
    
+
    
+  ">foo>*>bar" might imply:
    
+    - the middle directory is named "*"
    
+    - the middle directory is :WILD
    
+    - there may be zero or more :WILD middle directories
    
+    - the middle directory name matches any one-letter name
    
+
    
+  ">foo>**>bar" might mean
    
+    - the middle directory is named "**"
    
+    - the middle directory is :WILD
    
+    - there may be zero or more :WILD middle directories
    
+    - the middle directory name matches any two-letter name
    
+
    
+  Some file systems support even more complex wildcards, for example
    
+  regular expressions.
    
+
    
+  The CL pathname model does not specify a way to represent complex
    
+  wildcards, which means, for example, that (MAKE-PATHNAME :NAME "F*O")
    
+  cannot be recognized by portable code as containing a wildcard.
    
+
    
+  Common Lisp provides only the first of these four common operations
    
+  on wildcard pathnames:
    
+  (1) Enumerate the set of existing files that match the pathname;
    
+  this is provided by the DIRECTORY function.
    
+  (2) Test whether a pathname contains wildcards.
    
+  (3) Test whether a pathname matches a wildcard pathname.
    
+  (4) Translate one pathname into another according to a mapping specified
    
+  by a pair of wildcard pathnames.
    
+
    
+Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
    
+
    
+  Introduce the following three functions:
    
+
    
+  1. WILD-PATHNAME-P pathname &optional field-key
    
+  
    
+    Tests a pathname for the presence of wildcard components.  If the first
    
+    argument is not a pathname, string, or file stream an error of type
    
+    TYPE-ERROR is signalled.
    
+  
    
+    If no <field-key> is provided, or the <field-key> is NIL, the result is
    
+    true if <pathname> has any wildcard components, NIL if <pathname> has none.
    
+    If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
    
+    :DIRECTORY, :NAME, :TYPE, or :VERSION.  In this case, the result is true
    
+    if the indicated component of <pathname> is a wildcard, NIL if the
    
+    component is not a wildcard.  Note that not all implementations
    
+    support wildcards in all fields, according to PATHNAME-COMPONENT-VALUE.
    
+
    
+
    
+  2. PATHNAME-MATCH-P pathname wildcard
    
+
    
+    true if <pathname> matches <wildcard>, otherwise NIL.  The matching rules
    
+    are implementation-defined but should be consistent with the
    
+    DIRECTORY function.  Missing components of <wildcard> default to :WILD.
    
+
    
+    If either argument is not a pathname, string, or file stream an error
    
+    of type TYPE-ERROR is signalled.  It is valid for <pathname> to be a
    
+    wild pathname; a wildcard field in <pathname> will only match a
    
+    wildcard field in <wildcard>, i.e. the function is not commutative.
    
+    It is valid for <wildcard> to be a non-wild pathname.
    
+
    
+
    
+  3. TRANSLATE-PATHNAME source from-wildcard to-wildcard &key
    
+
    
+    Translates the pathname <source>, which matches <from-wildcard>, into
    
+    a corresponding pathname <result>, which matches <to-wildcard>, and
    
+    returns <result>.
    
+
    
+    The pathname <result> is <to-wildcard> with each wildcard or missing
    
+    field replaced by a portion of <source>.  A "wildcard field" is a
    
+    pathname component with a value of :WILD, a :WILD element of a
    
+    list-valued directory component, or an implementation-defined portion
    
+    of a component, such as the "*" in the complex wildcard string
    
+    "foo*bar" that some implementations support.  An implementation that
    
+    adds other wildcard features, such as regular expressions, must define
    
+    how TRANSLATE-PATHNAME extends to those features.  A "missing field" is
    
+    a pathname component with a value of NIL.
    
+
    
+    The portion of <source> that is copied into <result> is implementation
    
+    defined.  Typically it is determined by the user interface conventions
    
+    of the file systems involved.  Usually it is the portion of <source>
    
+    that matches a wildcard field of <from-wildcard> that is in the same
    
+    position as the wildcard or missing field of <to-wildcard>.  If there
    
+    is no wildcard field in <from-wildcard> at that position, then usually
    
+    it is the entire corresponding pathname component of <source>, or in
    
+    the case of a list-valued directory component, the entire corresponding
    
+    list element.  For example, if the name components of <source>,
    
+    <from-wildcard>, and <to-wildcard> are "gazonk", "gaz*", and "h*"
    
+    respectively, then in most file systems, the wildcard fields of the
    
+    name component of <from-wildcard> and <to-wildcard> are each "*", the
    
+    matching portion of <source> is "onk", and the name component of
    
+    <result> is "honk".  However, the exact behavior of TRANSLATE-PATHNAME
    
+    cannot be dictated by the Common Lisp language and must be allowed to
    
+    vary, depending on the user interface conventions of the file systems
    
+    involved.
    
+
    
+    During the copying of a portion of <source> into <result>, additional
    
+    implementation-defined translations of alphabetic case or file naming
    
+    conventions might occur, especially when <from-wildcard> and
    
+    <to-wildcard> are for different hosts.
    
+
    
+    If any of the first three arguments is not a pathname, string, or file
    
+    stream an error of type TYPE-ERROR is signalled.  It is valid for
    
+    <source> to be a wild pathname; in general this will produce a wild
    
+    result.  It is valid for <from-wildcard> and/or <to-wildcard> to be
    
+    non-wild pathnames.  (PATHNAME-MATCH-P <source> <from-wildcard>) must
    
+    be true or an error is signalled.
    
+    
    
+    There are no specified keyword arguments for TRANSLATE-PATHNAME, but
    
+    implementations are permitted to extend it by adding keyword arguments.
    
+    There is one specified return value from TRANSLATE-PATHNAME;
    
+    implementations are permitted to extend it by returning additional
    
+    values.
    
+
    
+    Implementation guideline: one file system performs this operation by
    
+    examining each piece of the three pathnames in turn, where a piece is a
    
+    pathname component or a list element of a structured component such as
    
+    a hierarchical directory.  Hierarchical directory elements in
    
+    <from-wildcard> and <to-wildcard> are matched by whether they are
    
+    wildcards, not by depth in the directory hierarchy.  If the piece in
    
+    <to-wildcard> is present and not wild, it is copied into the result.
    
+    If the piece in <to-wildcard> is :WILD or NIL, the piece in <source> is
    
+    copied into the result.  Otherwise, the piece is <to-wildcard> might be
    
+    a complex wildcard such as "foo*bar" and the piece in <from-wildcard>
    
+    should be wild; the portion of the piece in <source> that matches the
    
+    wildcard portion of the piece in <from-wildcard> replaces the wildcard
    
+    portion of the piece in <to-wildcard> and the value produced is used in
    
+    the result.
    
+
    
+  4. Clarify that the functions OPEN (and WITH-OPEN-FILE), PROBE-FILE,
    
+  FILE-WRITE-DATE, FILE-AUTHOR, and TRUENAME only accept non-wildcard
    
+  pathnames and signal an error if given a pathname for which
    
+  WILD-PATHNAME-P returns true.
    
+
    
+  5. Clarify that the functions RENAME-FILE, DELETE-FILE, LOAD, and
    
+  COMPILE-FILE have implementation-defined consequences when given a
    
+  wildcard pathname.  Each function might signal an error or might operate
    
+  on all files that match the wildcard pathname.
    
+
    
+
    
+Examples:
    
+
    
+  ;The following examples are not portable.  They are written to run
    
+  ;with particular file systems and particular wildcard conventions.
    
+  ;Other implementations will behave differently.  These examples are
    
+  ;intended to be illustrative, not to be prescriptive.
    
+
    
+  (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
    
+  (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
    
+  (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
    
+  (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T   ;Lispm
    
+  (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T    ;Most places
    
+
    
+  ;This example assumes one particular set of wildcard conventions
    
+  ;Not all file systems will run this example exactly as written
    
+  (DEFUN RENAME-FILES (FROM TO)
    
+    (DOLIST (FILE (DIRECTORY FROM))
    
+      (RENAME-FILE FILE (TRANSLATE-PATHNAME FILE FROM TO))))
    
+  (RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")
    
+    ;Renames /usr/me/init.lisp to /dev/her/init.l
    
+  (RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")
    
+    ;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
    
+    ;In some file systems the result might be /sys/pcl/5-may/low.lisp
    
+  (RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")
    
+    ;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
    
+    ;In some file systems the result might be /sys/library/5-may/low.lisp
    
+  (RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")
    
+    ;Renames /usr/me/foo.bar to /usr/me2/foo.bar
    
+  (RENAME-FILES "/usr/joe/*-recipes.text" "/usr/jim/cookbook/joe's-*-rec.text")
    
+    ;Renames /usr/joe/lamb-recipes.text to /usr/jim/cookbook/joe's-lamb-rec.text
    
+    ;Renames /usr/joe/pork-recipes.text to /usr/jim/cookbook/joe's-pork-rec.text
    
+    ;Renames /usr/joe/veg-recipes.text to /usr/jim/cookbook/joe's-veg-rec.text
    
+
    
+  ;This example assumes one particular set of wildcard conventions
    
+  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz")) => "barbaz"
    
+  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*"))    => "foobar"
    
+  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*"    "foo*")) => "foofoobar"
    
+  (PATHNAME-NAME (TRANSLATE-PATHNAME "bar"    "*"    "foo*")) => "foobar"
    
+
    
+  ;Using Unix syntax and the wildcard conventions used by the
    
+  ;particular version of Unix on which I tried this:
    
+  (NAMESTRING
    
+    (TRANSLATE-PATHNAME "/usr/dmr/hacks/frob.l"
    
+                        "/usr/d*/hacks/*.l"
    
+                        "/usr/d*/backup/hacks/backup-*.*"))
    
+   => "/usr/dmr/backup/hacks/backup-frob.l"
    
+  (NAMESTRING
    
+    (TRANSLATE-PATHNAME "/usr/dmr/hacks/frob.l"
    
+                        "/usr/d*/hacks/fr*.l"
    
+                        "/usr/d*/backup/hacks/backup-*.*"))
    
+   => "/usr/dmr/backup/hacks/backup-ob.l"
    
+
    
+  ;This is similar to the above example but uses two different hosts,
    
+  ;U: which is a Unix and V: which is a VMS.  Note the translation
    
+  ;of file type and alphabetic case conventions.
    
+  (NAMESTRING
    
+    (TRANSLATE-PATHNAME "U:/usr/dmr/hacks/frob.l"
    
+                        "U:/usr/d*/hacks/*.l"
    
+                        "V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
    
+   => "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-FROB.LSP"
    
+  (NAMESTRING
    
+    (TRANSLATE-PATHNAME "U:/usr/dmr/hacks/frob.l"
    
+                        "U:/usr/d*/hacks/fr*.l"
    
+                        "V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
    
+   => "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-OB.LSP"
    
+
    
+  ;This example presumes background information described in PATHNAME-LOGICAL
    
+  (DEFUN TRANSLATE-LOGICAL-PATHNAME-1 (PATHNAME RULES)
    
+    (LET ((RULE (ASSOC PATHNAME RULES :TEST #'PATHNAME-MATCH-P)))
    
+      (UNLESS RULE (ERROR "No translation rule for ~A" PATHNAME))
    
+      (TRANSLATE-PATHNAME PATHNAME (FIRST RULE) (SECOND RULE))))
    
+  (TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"
    
+                        '(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
    
+                          ("FOO:CODE;"          "MY-UNIX:/lib/foo/")
    
+                          ("FOO:PATCHES;*;"     "MY-UNIX:/lib/foo/patch/*/")))
    
+   => the pathname MY-UNIX:/lib/foo/basic.l
    
+
    
+Rationale:
    
+
    
+  1,2,3. These three functions provide a standardized interface to the
    
+  idiosyncratic wildcard functionality of each host file system.
    
+
    
+  1. WILD-PATHNAME-P makes it possible to detect wild pathnames reliably and
    
+  do something useful (give up, merge out the bothersome components, call
    
+  DIRECTORY for a list of matching pathnames, etc.)
    
+
    
+  2,3. TRANSLATE-PATHNAME is needed by many application programs that deal
    
+  with wildcard pathnames.  PATHNAME-MATCH-P and TRANSLATE-PATHNAME are
    
+  needed by logical pathnames.  The PATHNAME-LOGICAL proposal cannot be
    
+  implemented without these features.  Implementing PATHNAME-LOGICAL could
    
+  involve adding additional capabilities to TRANSLATE-PATHNAME, depending
    
+  on the type of file system used, but those capabilities do not need to
    
+  be in the standard.
    
+
    
+  4. Since these functions return a value connected with one file, there
    
+  is no meaningful way to extend them to work on wildcard pathnames.  It
    
+  seems best to specify that they signal an error, rather than leaving
    
+  the consequences undefined.
    
+
    
+  5. The consequences are proposed to be implementation-defined because
    
+  current practice varies and no one wants to change.
    
+
    
+Current Practice:
    
+
    
+  Presumably no implementation supports the proposal exactly as stated.
    
+  Symbolics Genera has had similar features under different names for many
    
+  years:
    
+
    
+    (SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
    
+    etc., indicating the first wild field.
    
+
    
+    (SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
    
+    etc. test individual fields.
    
+
    
+    The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
    
+    :PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
    
+    PATHNAME-MATCH-P.
    
+
    
+  The Explorer also supports the messages :WILD-P (although it only
    
+  returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
    
+  :PATHNAME-MATCH.
    
+
    
+  Points 4 and 5 are current practice as far as the authors are aware.
    
+  The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
    
+  all files that match.
    
+
    
+Cost to Implementors:
    
+
    
+  Many implementations probably have a substrate which is capable of this
    
+  or something similar already. In such cases, it's a relatively small
    
+  matter to add the proposed interface.
    
+
    
+  Even in cases where an implementation doesn't have ready code, it's clearly
    
+  better for the implementor to write that code once and for all than to ask
    
+  each user of wildcards to write it.
    
+
    
+  Since the detailed behavior is at the implementor's discretion, the cost
    
+  is unlikely to be large.  Some file systems will do all the work and the
    
+  implementor need only provide an interface to the file system or to a
    
+  standard library routine.  For other file systems the implementor has to
    
+  write the actual matching and translation algorithms.
    
+
    
+Cost to Users:
    
+
    
+  None.  This change is upward compatible.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Wild pathnames would continue to be mistaken for ordinary pathnames in
    
+  many situations.  User programs that deal with wildcard pathnames would
    
+  have to operate on implementation-dependent representations and hence
    
+  would not be easily portable.
    
+
    
+  The biggest cost is that the logical pathnames proposal would be stymied.
    
+
    
+Performance Impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  A more complete set of wildcard pathname operations.  Portable user
    
+  programs that deal with wildcard pathnames will be more consistent
    
+  and reliable.  A portable system construction tool can be written
    
+  and the foundations are laid for a `logical pathname' facility
    
+  (proposed separately in PATHNAME-LOGICAL).
    
+
    
+Aesthetics:
    
+
    
+  This change would make some portable code less kludgey.
    
+
    
+Discussion:
    
+
    
+  There was some question about the name. The name PATHNAME-WILD-P
    
+  suggests a ``slot'' of a pathname (like PATHNAME-HOST),
    
+  while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
    
+  The committee was split on what to call it. Since it is more
    
+  like a type than a slot, the name WILD-PATHNAME-P was chosen.
    
+
    
+  It's been suggested that WILD-PATHNAME-P and PATHNAME-MATCH-P be allowed
    
+  to return a value other than T to represent "truth", which would
    
+  somehow encode some additional information.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268.htm new file mode 100644 index 00000000..01ed5f24 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268_w.htm new file mode 100644 index 00000000..0e938c07 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss268_w.htm @@ -0,0 +1,224 @@ + + + +CLHS: Issue PEEK-CHAR-READ-CHAR-ECHO Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PEEK-CHAR-READ-CHAR-ECHO Writeup

    + +
    Status:	Passed, Jan 89 X3J13
    
+Issue:        PEEK-CHAR-READ-CHAR-ECHO
    
+References:   READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
    
+	      MAKE-ECHO-STREAM (p330), Streams (p327-328),
    
+	      READ-PRESERVING-WHITESPACE (p376), 
    
+	      READ-DELIMITED-LIST (p377)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 06-Mar-87, Version 1 by Pitman
    
+              23-Jun-88, Version 2 by Pitman (remove interactive stuff)
    
+               8-Oct-88, Version 3 by Pitman & Masinter
    
+	      
    
+Problem Description:
    
+
    
+  The interaction between PEEK-CHAR, READ-CHAR and streams made by
    
+  MAKE-ECHO-STREAM is not made adequately clear about how many times
    
+  a particular character may be echoed and at what time such echo
    
+  is permissible.
    
+
    
+  For example, given:
    
+   (WITH-INPUT-FROM-STRING (STRING-STREAM "A")
    
+     (LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
    
+					       *STANDARD-OUTPUT*)))
    
+       (LET ((CHAR NIL))
    
+	 (PEEK-CHAR)             (PRIN1 '---)
    
+	 (PEEK-CHAR)             (PRIN1 '---)
    
+	 (SETQ CHAR (READ-CHAR)) (PRIN1 '---)
    
+	 (UNREAD-CHAR CHAR)      (PRIN1 '---)
    
+	 (READ-CHAR))))
    
+  what is seen on the terminal? There are at least these possibilities:
    
+
    
+  [1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
    
+      a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
    
+      re-fetching the char by READ-CHAR doesn't echo.
    
+      A------------
    
+
    
+  [2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
    
+      Characters are not unechoed by UNREAD-CHAR.
    
+      A---A---A---A---
    
+
    
+  [3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
    
+      No `unecho' action is done by UNREAD-CHAR.
    
+      ------A------A
    
+
    
+  [4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echoes
    
+      but UNREAD-CHAR does not `unecho'.
    
+      A---A---A------A
    
+
    
+  [5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echoes
    
+      but UNREAD-CHAR unechoes (a magic Erase character must be 
    
+      presupposed for display terminals, a file stream that can randomly
    
+      access during output and/or back up must be presupposed for files,
    
+      paper terminals just lose):
    
+      A<Erase>---A<Erase>---A---<Erase>---A
    
+
    
+  [6] PEEK-CHAR is implemented by peeking and does not echo. The first
    
+      time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
    
+      echo, re-fetching the char by READ-CHAR doesn't echo:
    
+      ------A------
    
+
    
+  This list is not believed to be exhaustive. It is only to illustrate
    
+  of the variety of possible ways in which the current specification can 
    
+  be implemented without technically being in conflict with the written 
    
+  word of CLtL. Obviously not all of these interpretations are considered 
    
+  useful by all people, but usefulness has not been determined to be 
    
+  criterial in satisfying the specification.
    
+
    
+  The description of streams (p327-328) is also [probably deliberately]
    
+  fuzzy on this issue as it relates to operating systems on which echoing 
    
+  is done by the operating system. That is, some systems are line-at-a-time
    
+  and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
    
+  have long since been resolved by a system call that reads and echoes input 
    
+  a line at a time. Other systems are character-at-a-time and these issues 
    
+  hit home in a different way. It will probably be necessary to continue
    
+  leaving things slightly unspecified in order to accomodate the native 
    
+  style of the variety of operating systems now trying to support Common 
    
+  Lisp, but we should be more up front about the game we are playing. (For
    
+  example, code which must port between character-at-a-time and 
    
+  line-at-a-time systems must be more careful about whether it does 
    
+  newline-preceded or newline-terminated output than many CL programmers 
    
+  might realize given the current wording.) Additionally, though, we should
    
+  be on the lookout for less ambitious goals involving only partial
    
+  compatibility to improve the situation wherever we can find a way to.
    
+
    
+  Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
    
+  are implicitly affected by any decisions made on this issue since their
    
+  descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.
    
+
    
+Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):
    
+
    
+  Ammend the description of READ-CHAR to say that when the stream is
    
+  an echo stream (a stream created by MAKE-ECHO-STREAM), the character
    
+  will be echoed on the stream the first time those characters are seen.
    
+  (Characters which are not echoed by READ-CHAR are those which were
    
+  put there by UNREAD-CHAR and hence are assumed to have been echoed
    
+  already by a previous call to READ-CHAR.)
    
+
    
+  Ammend the description of UNREAD-CHAR to say that when the stream
    
+  is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
    
+  will be made to undo any echoing of the character which might already
    
+  have been done on the stream. However, characters placed on the
    
+  stream by UNREAD-CHAR will be marked in such as way as to inhibit
    
+  later re-echo by READ-CHAR.
    
+
    
+  Ammend the description of PEEK-CHAR to say that when the stream is
    
+  an echo stream (a stream created by MAKE-ECHO-STREAM), characters
    
+  which are only peeked at are not echoed. Note however that in the
    
+  case that the PEEK-TYPE argument is not NIL, the characters which
    
+  are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
    
+  echoed unless they have been marked otherwise by READ-CHAR.
    
+
    
+  Ammend the description of abstract input functions 
    
+  READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
    
+  that they are implicitly affected by these new echoing rules of 
    
+  READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
    
+
    
+  Note: This is consistent with behavior [6] in the problem description.
    
+
    
+  Clarify that the echo behavior of interactive streams such as
    
+  *TERMINAL-IO* continues to be implementation dependent.
    
+
    
+Rationale:
    
+
    
+  Although this is not known to be in use in any particular system,
    
+  nothing prevents its use. It proposes a more rational interpretation
    
+  of the echoing behavior of UNREAD-CHAR which might make it possible
    
+  for programmers concerned about echo behavior not to have to shy
    
+  away from UNREAD-CHAR. (It would probably also improve the behavior
    
+  of READ-PRESERVING-WHITESPACE with regard to echoing, since its
    
+  description mentions using UNREAD-CHAR.)
    
+
    
+  Correct echoing behavior is important to programs which do batch
    
+  processing, parsing, etc. Allowing multiple or premature echoing
    
+  is clearly unsatisfactory.
    
+
    
+Current Practice:
    
+
    
+  A wide variety of behaviors are in use.
    
+
    
+Cost to Implementors:
    
+
    
+  Unknown.
    
+
    
+  The code to implement the proposed change itself is probably fairly
    
+  localized.
    
+
    
+  In some operating systems, there may be echoing constraints which
    
+  are overlooked here. 
    
+
    
+  In some cases, there may be second order effects in the system 
    
+  itself which would also require a somewhat less predictable amount 
    
+  of work to fix. 
    
+
    
+Cost to Users:
    
+
    
+  Any change is effectively upward compatible since the previous
    
+  behavior is so ill-specified.
    
+
    
+  Most users probably naively expect (perhaps even without realizing
    
+  it explicitly) that echoing will take care of itself. That is, they
    
+  probably expect that echoing will occur at the time of the
    
+  READ-CHAR and probably do not give a lot of thought to the effect
    
+  of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most 
    
+  of their naive intuitions.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The streams returned by MAKE-ECHO-STREAM would continue to be
    
+  significantly hard to use portably.
    
+
    
+Benefits:
    
+
    
+  A number of applications involving of parsers, batch script
    
+  interpreters, and such would be possible to implement
    
+  straightforwardly and portably.
    
+
    
+Aesthetics:
    
+
    
+  ?
    
+
    
+Discussion:
    
+
    
+  Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
    
+  he feels it is more practically coherent. However, he says he has
    
+  only mental exercises and no actual personal experience upon which
    
+  to base that belief.
    
+
    
+  Version 1 of this proposal treated interactive streams on par
    
+  with echo streams, but while people agreed that this issue is
    
+  a severe portability problem, some considered that the treatment
    
+  of interactive streams got involved in operating system issues
    
+  that were beyond the scope of the standard, so that part of the
    
+  text was removed.
    
+ 
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269.htm new file mode 100644 index 00000000..38be0044 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269.htm @@ -0,0 +1,45 @@ + + + +CLHS: Issue PLIST-DUPLICATES:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PLIST-DUPLICATES:ALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PLIST-DUPLICATES:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269_w.htm new file mode 100644 index 00000000..e6fe7fa0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss269_w.htm @@ -0,0 +1,140 @@ + + + +CLHS: Issue PLIST-DUPLICATES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PLIST-DUPLICATES Writeup

    + +
    Issue:        PLIST-DUPLICATES
    
+Reference:    X3J13/92-102, dpANS 12.24
    
+                Glossary, p.26-33, initialization argument list
    
+                Glossary, p.26-49
    
+                Section 7.1.1, Initialization Arguments
    
+                Section 3.4.1.4, Specifiers for keyword parameters
    
+              X3J13/92-3107, Kim Barrett comment #7
    
+Category:     CHANGE
    
+Edit History: Version 1, 1/6/93, Kim Barrett
    
+Status:       Proposal ALLOW accepted 8-0, March 1993
    
+
    
+
    
+Problem Description:
    
+
    
+ The definition of \term{property list} states that the keys must all be
    
+ distinct under EQ.  This requirement goes all the way back to CLtL1.
    
+ However, it causes some problems.  It forced the editor to define the term
    
+ \term{property list format} and describe some things in terms of that new
    
+ term rather than describing them as simply being property lists, because
    
+ these things were not required to satisfy the distinct keys requirement.
    
+ Initialization argument lists and keyword argument lists are among the most
    
+ pervasive, with the result that, strictly speaking, GETF and friends cannot
    
+ be used to maniplulate such lists.  Instead, users must either write their
    
+ own functions for manipulation of such lists (with a possible concomitant
    
+ performance loss) or rely on implementors to use the "obvious" implementations
    
+ of these functions and hope for the best.
    
+
    
+ GET-PROPERTIES is incorrectly documented as accepting a list in
    
+ \term{property list format}, rather than a \term{property list}.  This is a
    
+ technical change without basis in committee decision.  It then goes on to
    
+ refer to that argument as a \term{property list}.
    
+
    
+ The terms \term{property}, \term{property indicator}, and \term{property
    
+ value} should probably all be defined in terms of lists in \term{property
    
+ list format} rather than in terms of \term{property lists}.
    
+
    
+ The term \term{initialization argument list} is not defined in terms of
    
+ the term \term{property list format}.
    
+
    
+Proposal (PLIST-DUPLICATES:ALLOW):
    
+
    
+ 1. Remove the unique key requirement for \term{property lists}, by deleting
    
+ the following phrase from its definition in the glossary
    
+    ", and in which all \term{keys} are \term{different} under \funref{eq}"
    
+ and adding the following sentence
    
+    "When there is more than one \term{name} and \term{value} pair with
    
+     the \term{same} under \funref{eq} \term{name} in a \term{property list},
    
+     the first such pair determines the \term{property}."
    
+
    
+ 2. Remove the term \term{property list format}, instead using the term
    
+ \term{property list} throughout the document.
    
+
    
+ 3. Specify that REMF and REMPROP only remove the first occurance (the
    
+ \term{property}, as specified by (3) above) when there are multiple occurances
    
+ of the same key.  Similarly, specify that SETF of GETF and SETF of GET update
    
+ only the first occurance.
    
+
    
+ 4. Change the definition of the term \term{initialization argument list} to
    
+ specify that it is a \term{property list}.  This allows the removal of some
    
+ redundant text from the second paragraph of section 7.1.1.
    
+
    
+ 5. Change the description of keyword argument processing in section 3.4.1.4 to
    
+ use the terms \term{property list}, \term{property}, \term{property indicator},
    
+ and \term{property value} where appropriate.
    
+
    
+Editorial Impact:
    
+
    
+ One global query replace, a few changes to one glossary entry, and a small
    
+ amount of rewriting of a couple paragraphs.  In some cases the rewriting
    
+ essentially amounts to deleting a bunch of text and then cleaning up.
    
+
    
+Rationale:
    
+
    
+ Addresses the problem description.
    
+
    
+ Item 1 is the leftmost rule used by initialization and keyword arguments.
    
+
    
+Current Practice:
    
+
    
+ With the possible exception of REMF/REMPROP, does anybody *not* implement
    
+ exactly this?
    
+
    
+Cost to Implementors:
    
+
    
+ Probably none.
    
+
    
+Cost to Users:
    
+
    
+ None.
    
+
    
+Performance Impact:
    
+
    
+ Users can use built-in operators for parsing such things as keyword argument
    
+ lists, possibly improving performance slightly.
    
+
    
+Benefits:
    
+
    
+ Gets rid of some ugly terminalogical warts.  Makes the document slightly
    
+ smaller.
    
+
    
+Discussion:
    
+
    
+ In item 3, alternatively, could make it unspecified whether REMF, REMPROP,
    
+ SETFof GETF and SETF of GET affect all or only the first occurance.  However,
    
+ only affecting the first is more consistent with the new definition of a
    
+ property list and property.  Not deleting all means that in some cases where
    
+ using REMF the idiom (do () ((not (remf plist property)))) is useful.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270.htm new file mode 100644 index 00000000..c1d07016 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270.htm @@ -0,0 +1,54 @@ + + + +CLHS: Issue PRETTY-PRINT-INTERFACE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRETTY-PRINT-INTERFACE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PRETTY-PRINT-INTERFACE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270_w.htm new file mode 100644 index 00000000..b86b05f3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss270_w.htm @@ -0,0 +1,1515 @@ + + + +CLHS: Issue PRETTY-PRINT-INTERFACE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRETTY-PRINT-INTERFACE Writeup

    + +
    Version 3 (by Guy Steele Jr) supersedes version 2 and is changed from
    
+version 1 as follows: adds a functional interface to supplement the
    
+interface through FORMAT, and reflects comments by Barrett and
    
+Pierson.
    
+
    
+Version 4 (by Dick Waters) is changed from version 3 as follows: The
    
+short summary is updated to reflect the functional interface.  The
    
+functional interface is changed following suggestions made by Dave Moon.
    
+The proposal is amended in a few minor ways to increase the
    
+compatibility with variable width fonts.  Additional discussion has been
    
+added with regard to the advantages of XP with respect to handling
    
+ detection and abbreviation, the interaction with CLOS, and
    
+the extended type specifier CONS used by XP.
    
+
    
+Version 5 (by Waters, Haflich, Laubsch, Loosemore, Pierson, and van Roggen).
    
+  On June 27 it was voted 12 to 4 in a plenary session of X3J13 that an add
    
+hoc committee on pretty printing be created containing the above members
    
+with the charter of ironing out the final details of the pretty print
    
+interface and that if this committee could come to a unanimous decision on
    
+the interface, the interface would become part of the draft Common Lisp
    
+standard without the need of a further vote by the full committee.  The
    
+unanimity of the add hoc committee has been signaled by having each member
    
+of the committee send a message to X3J13 to this effect.
    
+  In addition to the main vote above, five straw polls were taken.  Three
    
+of these votes were overwhelming; however, two appeared too close to be
    
+definitive.  In order of the clarity of the outcome the straw votes were:
    
+ 16-0 in favor of the basic functional interface,
    
+ 10-4 against the inclusion of #"...",
    
+ 12-7 in favor of having some way to convert a FORMAT string into a function,
    
+ 11-8 in favor of allowing FORMAT to take a function as well as a string,
    
+ 10-8 against the pretty printer extensions of FORMAT.
    
+The subcommittee followed these recommendations except for the last.
    
+(See the end of the discussion section.)
    
+  Version 5 is changed from version 4 as follows:  The names of the
    
+functions and variables have been changed to better reflect that (for the
    
+most part) they are a group that applies only to pretty printing.  The
    
+variables *DEFAULT-RIGHT-MARGIN* and *LAST-ABBREVIATED-PRINTING* have been
    
+eliminated.  The readmacro construct #"..." has been eliminated and a new
    
+macro FORMATTER introduced in its place.  The way *PRINT-LINES*
    
+abbreviation is indicated has been improved to ensure that the delimiters
    
+will be balanced in the output and to ensure that the reader will complain
    
+if you later try to read the output.  The macros LOGICAL-BLOCK-POP and
    
+LOGICAL-BLOCK-COUNT have been eliminated and the functionality they
    
+supported provided in a slightly different form by two new macros
    
+PPRINT-POP and PPRINT-EXIT-IF-LIST-EXHAUSTED.  The macro
    
+DEFINE-PRINT-DISPATCH has been replaced by a function SET-PPRINT-DISPATCH.
    
+The proposal has been reorganized to show that the functional interface is
    
+more fundamental than the FORMAT interface, to clarify exactly what happens
    
+in error situations, and to indicate that the examples are merely examples
    
+and not part of the proposal.
    
+
    
+================================================================================
    
+
    
+Issue:		PRETTY-PRINT-INTERFACE
    
+
    
+References:	Description of XP by Dick Waters (attached)
    
+		*PRINT-PRETTY* (CLtL p. 371)
    
+		WRITE (CLtL p. 382)
    
+		PPRINT (CLtL p. 383)
    
+		FORMAT (CLtL pp. 385-407)
    
+		FORMAT ~T directive (CLtL pp. 398-399)
    
+		FORMAT ~< directive (CLtL pp. 404-406)
    
+
    
+Related issues: 
    
+
    
+Category:	CLARIFICATION CHANGE ADDITION
    
+
    
+Edit history:	Version 1, 24-Feb-89 by Steele
    
+		Version 2, 15-Mar-89 by Steele and Waters
    
+		Version 3, 15-Mar-89 by Steele
    
+		Version 4, 22-Mar-89 by Waters
    
+		Version 5, 20-Jul-89 by Waters et al
    
+
    
+Problem description:
    
+ At present, Common Lisp provides no specification whatsoever of how
    
+pretty-printing is to be accomplished, and no way for the user to control
    
+it.  In particular, there is no protocol by which a user can write a
    
+print-function for a structure, or a method for PRINT-OBJECT, that will
    
+interact smoothly with the built-in pretty-printer in a portable manner.
    
+
    
+Proposal (PRETTY-PRINT-INTERFACE:XP):
    
+
    
+Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
    
+described in full in the attached document.  Here is a very brief summary
    
+of the proposal.
    
+
    
+New variables:	*PRINT-PPRINT-DISPATCH*
    
+		*PRINT-MISER-WIDTH*
    
+		*PRINT-RIGHT-MARGIN*
    
+		*PRINT-LINES*
    
+
    
+New functions:	COPY-PPRINT-DISPATCH
    
+		SET-PPRINT-DISPATCH
    
+		PPRINT-DISPATCH
    
+		PPRINT-NEWLINE
    
+		PPRINT-TAB
    
+		PPRINT-INDENT
    
+		PPRINT-FILL
    
+		PPRINT-LINEAR
    
+		PPRINT-TABULAR
    
+
    
+New macros:	PPRINT-LOGICAL-BLOCK
    
+		PPRINT-POP
    
+		FORMATTER
    
+
    
+New FORMAT directives:	~W  ~_  ~I  ~:T  ~/name/  ~<...~:>
    
+
    
+The function WRITE is extended to accept four additional keyword arguments
    
+:PPRINT-DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to
    
+the four new variables.
    
+
    
+The function FORMAT is extended so that it can accept a function instead of
    
+a FORMAT string.  (This change is also made in the other functions that
    
+accept FORMAT strings such as ERROR and WARN.)
    
+
    
+Examples:	See attached document.
    
+
    
+Rationale:
    
+ There ought to be a good user interface to the pretty printer.
    
+This is the only proposal for which there is a portable implementation
    
+that has seen extensive use and is being made freely available.
    
+
    
+Current practice:
    
+ XP son of PP son of GPRINT son of #PRINT is the latest in a line of pretty
    
+printers that goes back 13 years.  All of these printers use essentially
    
+the same basic algorithm and conceptual interface.  Further, except for
    
+#PRINT, which was implemented solely to satisfy the author's personal
    
+needs, each of these printers has had extensive use.  XP has been in
    
+experimental use as the pretty printer in CMU Common Lisp for 6 months.  PP
    
+has been the pretty printer in DEC Common Lisp for the past 3 years.  Prior
    
+to three years ago, GPRINT was used for 2 years as the pretty printer in
    
+DEC Common Lisp.  In addition, GPRINT has been the pretty printer in
    
+various generations of Symbolics Lisp for upwards of 5 years.
    
+(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
    
+5(4):513--531, October 1983.)
    
+
    
+Cost to Implementors:  A fair amount of effort (several man-weeks at most).
    
+ Source code for XP is available to all comers from Dick Waters.  It has
    
+been arranged with MIT for anyone who wants to to get a non-exclusive
    
+royalty-free license for XP from MIT.  The system is documented in great
    
+detail in:
    
+  Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
    
+  Artificial Intelligence Laboratory Technical Memo 1102a,
    
+  Massachusetts Institute of Technology, Cambridge MA, July 1989.
    
+
    
+Cost to Users:  None (I think).  This is an upward-compatible extension.
    
+ Cost of non-adoption:  Continued inability for user print-functions
    
+to interact with the pretty-printer in a useful and portable manner.
    
+
    
+Performance impact:  XP is claimed to be quite fast.
    
+
    
+Benefits:  User control of pretty-printing in a portable manner.
    
+
    
+Aesthetics:
    
+ Using ~<...~:> may strike some as uncomfortably close in the syntactic
    
+space of FORMAT directives to the existing ~<...~>.  However, it is very
    
+unlikely that both of these directives (pretty-print logical block and
    
+columnar justification, respectively) will be used in the same call to
    
+FORMAT.  Previous versions of XP used ~!...~. instead of ~<...~:> but this
    
+made FORMAT strings very difficult to read; it is preferable to have a
    
+directive that looks like matching brackets of some sort.
    
+
    
+Dan Pierson comments:  You might mention that some people will undoubtedly
    
+find piling more hair on FORMAT ugly (of course these same people may
    
+well find FORMAT in general ugly :-)).
    
+
    
+Discussion:
    
+
    
+Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
    
+suggested here may be a problem.  If so, another suggestion for naming
    
+this directive would be appreciated.
    
+
    
+The ~/.../ directive is already in Zetalisp, and is not an idea new
    
+to this proposal.  However, it should be noted that the proposal for
    
+~/.../ here is simpler than, and incompatible with, the current Zatalisp
    
+practice.
    
+
    
+Guy Steele and Dick Waters strongly support this proposal.  (As an example,
    
+Guy Steele has a portable simulator for Connection Machine Lisp, and would
    
+like very much to have xappings and xectors pretty-print properly.)
    
+
    
+---
    
+
    
+Dan Pierson comments: You can add me to the list of strong supporters of
    
+this proposal.  While the proposal is long and complex, it is supported by
    
+a long history of usage in several different Lisp environments.
    
+
    
+The utility of *PRINT-LINES* becomes more obvious if it is pointed out
    
+that Dick's pretty printers are implemented to print each line as it
    
+is computed.  This means that a small value for *PRINT-LINES* saves
    
+significant time as well as output medium space.
    
+
    
+The advantages of compiled format strings (format functions) should be
    
+brought out as benefits in their own right.  The current proposal just
    
+mentions them as a minor feature of XP.
    
+
    
+At first this struck me a very cute end run around the failure of
    
+STREAM-INFO, then I realized that one of the problems with STREAM-INFO
    
+may have been that it was a standard at the wrong level.  STREAM-INFO
    
+permitted people to use XP, but not to count on it.  This proposal
    
+makes it possible to write portable code whose new data structures and
    
+language elements print correctly in whatever Common Lisp environment
    
+they're run in.  [End of comments by Pierson]
    
+
    
+---
    
+
    
+It has been noted by Guy Steele that some places in the initial document
    
+where it says that circularity detection is handled correctly, this is
    
+true a fortiori following the decision on PRINT-CIRCLE-STRUCTURE.
    
+However, Waters notes that the vote on PRINT-CIRCLE-STRUCTURE said
    
+nothing about the handling of *PRINT-LEVEL*.  Therefore, the fact that
    
+XP handles *PRINT-LEVEL* correctly is an improvement.
    
+
    
+In addition, PRINT-CIRCLE-STRUCTURE is also silent on what is supposed
    
+to happen if a user program decomposes a list itself (e.g., with DOLIST
    
+or ~{~}) rather than calling a print function.  Assumedly *PRINT-CIRCLE*
    
+etc. is not handled in this case.  In contrast, if one uses
    
+PPRINT-LOGICAL-BLOCK or ~<~:>, then *PRINT-CIRCLE*, *PRINT-LEVEL*, and
    
+*PRINT-LENGTH* are all automatically handled correctly.
    
+
    
+For example, (format nil "-~1{~A ~A ~A ~A ~A ~}-" '#1=(1 #1# 2 . #1#))
    
+produces "-1 #1=(1 #1# 2 . #1#) 2 1 #1=(1 #1# 2 . #1#) -"
    
+even under PRINT-CIRCLE-STRUCTURE and
    
+(format nil "-~1{~A ~}-" '#1=(1 #1# 2 . #1#)) 
    
+causes infinite looping.  However, in XP,
    
+(format nil "-~:<~W ~W ~W ~W ~W~:>-" '#1=(1 #1# 2 . #1#))
    
+produces "-#1=(1 #1# 2 . #1#)-".
    
+This proves to be very useful when writing pretty printing functions for
    
+things.  Note also that ~<~:> supports *PRINT-LEVEL* and *PRINT-LENGTH*
    
+correctly.  All the same things can be said about the functional interface
    
+and using PPRINT-LOGICAL-BLOCK rather than traversing a list yourself in
    
+some fashion.
    
+
    
+All in all, Waters claims that PRINT-CIRCLE-STRUCTURE covers at most 1/4
    
+of what XP does in support of *PRINT-CIRCLE* and does not cover anything
    
+of what XP does to support *PRINT-LEVEL*, *PRINT-LENGTH*, and
    
+robustness in the face of malformed arguments.  These are vital
    
+features for writing printing functions that really work right all the time.
    
+
    
+---
    
+
    
+It has been suggested that objects should be looked up in pprint dispatch
    
+tables by looking for the most specific type specifier that applies, rather
    
+than looking for the highest priority type specifier that applies.  There
    
+are two problems with this.  First, it is possible for two type specifiers
    
+to apply without one being more specific than the other.  For example,
    
+consider the type specifiers (OR INTEGER FLOAT) and (OR INTEGER RATIONAL)
    
+or the type specifiers (NOT COMPLEX) and (NOT INTEGER).
    
+
    
+A much more serious problem is that the only way to tell whether one type
    
+specifier is more specific than another is to use SUBTYPEP.  Unfortunately,
    
+even with the clarifications and extensions introduced by X3J13 with regard
    
+to SUBTYPEP in particular and the type system in general, SUBTYPEP is not
    
+very dependable.  There are critical situations where it cannot reasonably
    
+work in any implementation (e.g., when a type specifier contains SATISFIES)
    
+and many other situations where it can vary from one implementation to
    
+another.  Unfortunately, pprint dispatch tables are expected to contain
    
+type specifiers containing SATISFIES on a regular basis.  In addition, the
    
+variability in SUBTYPEP would reduce the portability of user-defined pprint
    
+dispatch tables if dispatching through them depended on SUBTYPEP.  All in
    
+all, it seems much better for the pretty printing to rely on priorities
    
+rather than on SUBTYPEP
    
+
    
+---
    
+
    
+It has been noted by Dave Moon that things would be much more elegant if
    
+SET-PPRINT-DISPATCH could be expressed directly as a CLOS DEFMETHOD for
    
+an appropriate generic function.  Dick Waters agrees with this.  However,
    
+SET-PPRINT-DISPATCH depends on type specifiers that are more complex than
    
+the ones CLOS deals with and ones that do not have clear subtype/supertype
    
+relationships, compensating for the latter problem by supporting numerical
    
+priorities to disambiguate things.  (The defaulting behavior is a key
    
+feature of the pretty printer.)  At the very least, this means that
    
+SET-PPRINT-DISPATCH will not fit into CLOS in a simple way.
    
+
    
+Given the problems, Moon suggests that "it does seem that right now it
    
+might be best to keep a separate SET-PPRINT-DISPATCH macro, with the
    
+idea that the expansion is implementation-dependent at the moment, but
    
+might some day be changed to be defined to expand into DEFMETHOD.  I
    
+haven't looked to see whether any syntactic changes would be appropriate
    
+to make that transition smoother."
    
+
    
+(Waters also worries that the overhead needed to locate the right CLOS
    
+method would seriously degrade the pretty printer, because the printer
    
+has to do this for every part of every object printed.  This dispatching is
    
+currently done by very fast code that is tuned to take advantage of the
    
+observed distribution of kinds of objects that have special pretty
    
+printers attached to them.  Even with this special purpose code,
    
+dispatching takes a significant part of the pretty printer's time.)
    
+
    
+---
    
+
    
+Dave Moon also comments that it is not good to have something that looks
    
+like a type specifier (i.e., the extended form of the CONS type specifier
    
+used by SET-PPRINT-DISPATCH) and yet is not a real type specifier.  He
    
+suggests that we should either amend Common Lisp to accept the extended
    
+form of the CONS type specifier, or stop having SET-PPRINT-DISPATCH use it.  
    
+
    
+Many of the members of the ad hoc pretty printing subcommittee agree that
    
+(CONS car-type cdr-type) should be made a full fledged type specifier.  In
    
+fact it has been suggested that there should be a much wider variety of
    
+ways to talk about lists and their contents than currently exists.
    
+However, the subcommittee feels that it would be going significantly beyond
    
+our charter to change anything about the type system.
    
+
    
+Therefore, we opted for the opposite tack of making it very clear in this
    
+proposal that while the function SET-PPRINT-DISPATCH accepts the form
    
+(CONS car-type cdr-type), this form is not a type specifier.
    
+
    
+---
    
+
    
+To a considerable extent, the design of the XP interface is completely
    
+neutral about the issue of variable- versus fixed- width fonts.  In
    
+particular, most of the discussion of how the formating proceeds either
    
+talks about absolute positions of zero or talks about something being
    
+in the same horizontal position as something else.  These statements are
    
+all font-independent.  (Further, although Waters' current implementation
    
+does not support variable-width fonts, the algorithms used could be
    
+extended to support them without radical changes.)
    
+
    
+Nevertheless, there are 8 places where users specify explicit non-zero
    
+lengths: the variables *PRINT-RIGHT-MARGIN* and *PRINT-MISER-WIDTH*,
    
+the numeric arguments to ~T, ~I, and ~/pprint-tabular/ and their associated
    
+functions PPRINT-TAB, PPRINT-INDENT, and PPRINT-TABULAR.
    
+
    
+It is proposed that all of these lengths be in the same units, and that
    
+this unit be ems (the length of an "m" in the font currently being used
    
+to output characters to the relevant output stream at the moment that
    
+the command is encountered or a variable is consulted).
    
+
    
+It is further proposed that users and implementors be advised to set things
    
+up so that explicit lengths do not have to be specified.  For implementors,
    
+this means making streams smart enough that they know how wide they are.
    
+(This avoids the use of *PRINT-RIGHT-MARGIN*.)  For users, this means
    
+relying on streams knowing their own widths (which is a good idea for
    
+adaptability in any case) and using ~:I (instead of just ~I) to specify
    
+indentations wherever possible.  Further, it should be noted that since
    
+*PRINT-MISER-WIDTH* is essentially heuristic in nature, it does not
    
+matter if its value is only an approximate length and users will only need
    
+to change the value of *PRINT-MISER-WIDTH* in unusual situations.
    
+This leaves only tabbing as an area where explicit lengths have to be
    
+specified on a regular basis.  Fortunately, approximate lengths are often
    
+acceptable in this situation as well.
    
+
    
+---
    
+
    
+The currently proposed syntax for PPRINT-LOGICAL-BLOCK was suggested by
    
+Dave Moon based on his experience with similar constructs at Symbolics.
    
+Waters had originally suggested using a standard binding pair to specify
    
+the underlying stream separately from the variable used to hold the special
    
+stream used within the logical block.  However, this invites user mistakes.
    
+The problem is that peculiar results will be obtained if any I/O is sent
    
+directly to the underlying stream from within the logical block.  By
    
+arranging the syntax as proposed, the same variable is always used for the
    
+special stream within the logical block as is used for the underlying
    
+stream outside of the block.  As a result, it is syntactically impossible
    
+to directly access the underlying stream (unless it is stored in two
    
+different variables) and the user is painlessly saved from making mistakes.
    
+Also, the PPRINT-LOGICAL-BLOCK macro is rendered more compact.
    
+
    
+---
    
+
    
+Another interesting issue is the interaction between pretty-printing and
    
+*PRINT-READABLY*.  Note first, that WITH-STANDARD-IO-SYNTAX binds
    
+*PRINT-PRETTY* to NIL.  In general one should expect that maximum machine
    
+readability will be achieved when *PRINT-PRETTY* is nil.  However, in
    
+analogy with issue DATA-IO, it is reasonable to require that
    
+PPRINT-DISPATCH functions must obey *PRINT-READABLY*.  Note that XP
    
+supports a number of features (e.g., automatic handling of malformed lists)
    
+that are explicitly designed to make it easier to write pprint functions
    
+that reliably produce machine readable output.
    
+
    
+---
    
+
    
+Steve Haflich comments that the macro FORMATTER provides an opportunity at
    
+some later time to do something about making FORMAT control strings more
    
+readable.  Specifically, when using FORMATTER, one should not hesitate to
    
+insert lots of newlines, because they will not waste any space since the
    
+FORMAT string will be converted into a function in any case.  Second, it
    
+would be nice to add some feature to format strings that would allow
    
+comments to appear in a FORMAT string.  (This is what ~; probably should
    
+have been reserved to mean.)
    
+
    
+---
    
+
    
+Walter van Roggen notes that the automatic handling of *PRINT-LEVEL* by XP
    
+obsoletes the need for the third argument to print functions for
    
+structures.  (This argument was very seldom used in any case.)  It might be
    
+appropriate at some future time to get rid of the third argument to print
    
+functions for structures.  However, this would not be an upward compatible
    
+change.
    
+
    
+---
    
+
    
+The pretty printer control interface is included in this proposal for two
    
+key reasons:
    
+
    
+(A) Something like the following is probably a key part of the argument
    
+against the pretty-printer-control FORMAT interface in the minds of those
    
+that oppose it.  "Including the pretty-printer-control FORMAT interface
    
+might be a gain or a loss for Common Lisp, but nothing could possibly be
    
+lost by not including it.  You can always just use FORMAT as it is now, and
    
+you can get pretty printing control with the new functions."  However, this
    
+argument is not quite true.
    
+
    
+As can be seen in the example below, pretty printer control information has
    
+to be highly intertwined with the rest of the output functions.  As a
    
+practical matter, this means that if there is no pretty-printer-control
    
+FORMAT interface you cannot make much if any use of FORMAT when specifying
    
+output that contains pretty-printer-control information.  (For instance in
    
+the 20 line example below, there is not even one place where there are two
    
+printing operations in a row that could be combined into a call on FORMAT
    
+if there were no pretty-printer-control FORMAT interface.  This means that
    
+there would be no benefit to using FORMAT anywhere in this example.)
    
+
    
+The consequence of the above is that, even though pretty printer control
    
+and FORMAT inherently have nothing to do with each other, adding pretty
    
+printer control facilities without adding a pretty-printer-control FORMAT
    
+interface, effectively requires people to choose between FORMAT and pretty
    
+printer control.  In order to allow people to separately decide whether
    
+they do or do not want to user FORMAT and do or do not want to get involved
    
+with controlling the pretty printer, you have to provide a
    
+pretty-printer-control FORMAT interface.
    
+
    
+This issue is intensified given a pretty printer such as XP that is
    
+within epsilon of just as fast as the ordinary non-pretty printer,
    
+because many people choose to set *PRINT-PRETTY* to T all of the time.
    
+They are therefore naturally led to wanting to specify at least some
    
+pretty printing control information whenever defining a print function
    
+for a structure, or an error message, or in fact essentially any kind
    
+of output.  If there is no pretty-printer-control FORMAT interface,
    
+then this would effectively bar the use of FORMAT for these users.
    
+
    
+In summary, rather than pushing FORMAT into new territory, the
    
+pretty-printer-control FORMAT interface is required to prevent FORMAT from
    
+sliding into obsolescence.
    
+
    
+
    
+(B) Although it probably is not convincing to those that do not like
    
+FORMAT, a additional reason for having a pretty-printer-control FORMAT
    
+interface is exactly the same as the reason for having FORMAT at all:
    
+compactness.  For example, as shown in the main proposal, the format string:
    
+
    
+  "~:<~W~^ ~:<~@{~:<~@{~W~^ ~_~}~:>~^ ~:_~}~:>~1I~@{~^ ~_~W~}~:>"
    
+
    
+is the same as the expression:
    
+
    
+  (pprint-logical-block (nil list :prefix "(" :suffix ")")
    
+    (write (pprint-pop))
    
+    (pprint-exit-if-list-exhausted)
    
+    (write-char #\space)
    
+    (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
    
+      (pprint-exit-if-list-exhausted)
    
+      (loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
    
+	      (pprint-exit-if-list-exhausted)
    
+	      (loop (write (pprint-pop))
    
+		    (pprint-exit-if-list-exhausted)
    
+		    (write-char #\space)
    
+		    (pprint-newline :linear)))
    
+	    (pprint-exit-if-list-exhausted)
    
+	    (write-char #\space)
    
+	    (pprint-newline :fill)))
    
+    (pprint-indent :block 1)
    
+    (loop (pprint-exit-if-list-exhausted)
    
+	  (write-char #\space)
    
+	  (pprint-newline :linear)
    
+	  (write (pprint-pop)))))
    
+
    
+It is of course also true that a line of FORMAT control string is a
    
+lot harder to read than a line of Lisp code.  However, FORMAT has
    
+become a permanent fixture of Common Lisp, because a line of FORMAT
    
+control string is a lot easier to read and work with than 20 lines of
    
+Lisp code.
    
+
    
+
    
+(C) It should also be noted that the way the XP proposal was first written
    
+up made the FORMAT interface look a lot more complex than it is.  Only six
    
+things are being added.  Two of these just fix problems with FORMAT and do
    
+not have anything to do with pretty printing.  Of the remaining four, three
    
+are very simple.  Only ~<...~:> could be called complex.
    
+
    
+~A and ~S both force the value of *PRINT-ESCAPE*.  ~W is needed in
    
+order to write FORMAT strings that obey *PRINT-ESCAPE*.
    
+
    
+~/.../ restores (in a simplified form) a feature of FORMAT that was
    
+lost in the first version of Common Lisp.  A number of people have
    
+commented that this is something that they like, having nothing to do
    
+with pretty printing.  (Note that ~/PPRINT-LINEAR/, ~/PPRINT-FILL/,
    
+and ~/PPRINT-TABULAR/ are not new directives, they are just a
    
+consequence of the fact that ~/.../ can call the functions
    
+PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR.)
    
+
    
+
    
+ 
    
+========================= ``Attached Document'' =========================
    
+
    
+Proposal (PRETTY-PRINT-INTERFACE:XP):
    
+
    
+Full description of XP accompanying version 5 of the proposal
    
+
    
+--------------------
    
+
    
+			   Pretty Printing
    
+
    
+			  Richard C. Waters
    
+
    
+
    
+Pretty printing has traditionally been a black box process, displaying
    
+program code using a set of fixed layout rules.  Its utility can be greatly
    
+enhanced by opening it up to user control.
    
+
    
+By providing direct access to the mechanisms within the pretty printer that
    
+make dynamic decisions about layout, the macros and functions
    
+PPRINT-LOGICAL-BLOCK, PPRINT-NEWLINE, and PPRINT-INDENT make it possible to
    
+specify pretty printing layout rules as a part of any function that
    
+produces output.  They also make it very easy for the detection of
    
+circularity and sharing, and abbreviation based on length and nesting depth
    
+to be supported by the function.  The function SET-PPRINT-DISPATCH makes it
    
+possible to associate a user-defined pretty printing function with any type
    
+of object.  Together, these facilities enable users to redefine the way
    
+code is displayed and allow the full power of pretty printing to be applied
    
+to complex combinations of data structures.
    
+
    
+		  Pretty Printing Control Variables
    
+
    
+*PRINT-RIGHT-MARGIN*                                             [variable]
    
+
    
+A primary goal of pretty printing is to keep the output between a pair of
    
+margins.  The left margin is set at the column where the output begins.  If
    
+this cannot be determined, the left margin is set to zero.
    
+
    
+When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
    
+when making layout decisions.  When *PRINT-RIGHT-MARGIN* is NIL (the
    
+initial value), the right margin is set at the maximum line length that can
    
+be displayed by the output stream without wraparound or truncation.  If
    
+this cannot be determined, the right margin is set to an implementation
    
+dependent value.
    
+
    
+To allow for the possibility of variable-width fonts, *PRINT-RIGHT-MARGIN*
    
+is interpreted in terms of ems---the length of an "m" in the font being
    
+used to display characters on the relevant output stream at the moment when
    
+the variables are consulted.
    
+
    
+*PRINT-MISER-WIDTH*                                              [variable]
    
+
    
+If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
    
+style of output (called miser style) whenever the width available for
    
+printing a substructure is less than or equal to *PRINT-MISER-WIDTH* ems.
    
+The initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
    
+
    
+*PRINT-LINES*                                                    [variable]
    
+
    
+When given a value other than its initial value of NIL, *PRINT-LINES*
    
+limits the number of output lines produced when something is pretty
    
+printed.  If an attempt is made to go beyond *PRINT-LINES* lines, "
    
+.." is printed at the end of the last line followed by all of the
    
+suffixes (closing delimiters) that are pending to be printed.
    
+
    
+(let ((*print-right-margin* 25) (*print-lines* 3))
    
+  (pprint '(progn (setq a 1 b 2 c 3 d 4))))
    
+
    
+(PROGN (SETQ A 1
    
+             B 2
    
+             C 3 ..))
    
+
    
+(The symbol ".." is printed out to ensure that a reader error will occur
    
+if the output is later read.  A symbol different than "..." is used to
    
+indicate that a different kind of abbreviation has occurred.)
    
+
    
+*PRINT-PPRINT-DISPATCH*                                          [variable]
    
+
    
+When *PRINT-PRETTY* is not NIL, printing is controlled by the `pprint
    
+dispatch table' stored in the variable *PRINT-PPRINT-DISPATCH*.  The
    
+initial value of *PRINT-PPRINT-DISPATCH* is implementation dependent and
    
+causes traditional pretty printing of Lisp code.  The last section of this
    
+proposal explains how the contents of this table can be changed.
    
+
    
+
    
+The function WRITE accepts keyword arguments :PPRINT-DISPATCH,
    
+:RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to
    
+*PRINT-PPRINT-DISPATCH*, *PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and
    
+*PRINT-MISER-WIDTH*.
    
+
    
+
    
+	     Dynamic Control of the Arrangement of Output
    
+
    
+The following functions and macros support precise control of what should
    
+be done when a piece of output is too large to fit in the space available.
    
+Three concepts underlie the way these operations work---`logical blocks',
    
+`conditional newlines', and `sections'.  Before proceeding further, it is
    
+important to define these terms.
    
+
    
+The first line of Figure 1 shows a schematic piece of output.  The
    
+characters in the output are represented by "-"s.  The positions of
    
+conditional newlines are indicated by digits.  The beginnings and ends of
    
+logical blocks are indicated by "<" and ">" respectively.
    
+
    
+The output as a whole is a logical block and the outermost section.  This
    
+section is indicated by the 0's on the second line of Figure 1.  Logical
    
+blocks nested within the output are specified by the macro
    
+PPRINT-LOGICAL-BLOCK.  Conditional newline positions are specified by calls
    
+on PPRINT-NEWLINE.  Each conditional newline defines two sections (one
    
+before it and one after it) and is associated with a third (the section
    
+immediately containing it).
    
+
    
+The section after a conditional newline consists of: all the output up to,
    
+but not including, (a) the next conditional newline immediately contained
    
+in the same logical block; or if (a) is not applicable, (b) the next
    
+newline that is at a lesser level of nesting in logical blocks; or if (b)
    
+is not applicable, (c) the end of the output.
    
+
    
+The section before a conditional newline consists of: all the output back
    
+to, but not including, (a) the previous conditional newline that is
    
+immediately contained in the same logical block; or if (a) is not
    
+applicable, (b) the beginning of the immediately containing logical block.
    
+The last four lines in Figure 1 indicate the sections before and after the
    
+four conditional newlines.
    
+
    
+The section immediately containing a conditional newline is the shortest
    
+section that contains the conditional newline in question.  In Figure 1,
    
+the first conditional newline is immediately contained in the section
    
+marked with 0's, the second and third conditional newlines are immediately
    
+contained in the section before the fourth conditional newline, and the
    
+fourth conditional newline is immediately contained in the section after
    
+the first conditional newline.
    
+
    
+
    
+                 <-1---<--<--2---3->--4-->->
    
+                 000000000000000000000000000
    
+                 11 111111111111111111111111
    
+                           22 222
    
+                              333 3333
    
+                        44444444444444 44444
    
+
    
+Figure 1: Example of logical blocks, conditional newlines, and sections.
    
+
    
+Whenever possible, the pretty printer displays the entire contents of a
    
+section on a single line.  However, if the section is too long to fit in
    
+the space available, line breaks are inserted at conditional newline
    
+positions within the section.
    
+
    
+
    
+PPRINT-NEWLINE kind &OPTIONAL (stream *STANDARD-OUTPUT*)    [Function]
    
+
    
+STREAM (which defaults to *STANDARD-OUTPUT*) follows the standard
    
+conventions for stream arguments to printing functions (i.e., NIL stands
    
+for *STANDARD-OUTPUT* and T stands for *TERMINAL-IO*).  The KIND argument
    
+specifies the style of conditional newline.  It must be one of :LINEAR,
    
+:FILL, :MISER, or :MANDATORY.  An error is signalled if any other value is
    
+supplied.  If STREAM is a pretty printing stream created by
    
+PPRINT-LOGICAL-BLOCK, a line break is inserted in the output when the
    
+appropriate condition below is satisfied.  Otherwise, PPRINT-NEWLINE has no
    
+effect.  The value NIL is always returned.
    
+
    
+If KIND is :LINEAR, it specifies a `linear-style' conditional newline.  A
    
+line break is inserted if and only if the immediately containing section
    
+cannot be printed on one line.  The effect of this is that line breaks are
    
+either inserted at every linear-style conditional newline in a logical
    
+block or at none of them.
    
+
    
+If KIND is :MISER, it specifies a `miser-style' conditional newline.  A
    
+line break is inserted if and only if the immediately containing section
    
+cannot be printed on one line and miser style is in effect in the
    
+immediately containing logical block.  The effect of this is that
    
+miser-style conditional newlines act like linear-style conditional
    
+newlines, but only when miser style is in effect.  Miser style is in effect
    
+for a logical block if and only if the starting position of the logical
    
+block is less than or equal to *PRINT-MISER-WIDTH* from the right margin.
    
+
    
+If KIND is :FILL, it specifies a `fill-style' conditional newline.  A line
    
+break is inserted if and only if either (a) the following section cannot be
    
+printed on the end of the current line, (b) the preceding section was not
    
+printed on a single line, or (c) the immediately containing section cannot
    
+be printed on one line and miser style is in effect in the immediately
    
+containing logical block.  If a logical block is broken up into a number of
    
+subsections by fill-style conditional newlines, the basic effect is that
    
+the logical block is printed with as many subsections as possible on each
    
+line.  However, if miser style is in effect, fill-style conditional
    
+newlines act like linear-style conditional newlines.
    
+
    
+If KIND is :MANDATORY, it specifies a `mandatory-style' conditional
    
+newline.  A line break is always inserted.  This implies that none of the
    
+containing sections can be printed on a single line and will therefore
    
+trigger the insertion of line breaks at linear-style conditional newlines
    
+in these sections.
    
+
    
+When a line break is inserted by any type of conditional newline, any
    
+blanks that immediately precede the conditional newline are omitted from
    
+the output and indentation is introduced at the beginning of the next line.
    
+By default, the indentation causes the following line to begin in the same
    
+horizontal position as the first character in the immediately containing
    
+logical block.  (The indentation can be changed via PPRINT-INDENT.)
    
+
    
+There are a variety of ways unconditional newlines can be introduced into
    
+the output (e.g., via TERPRI or by printing a string containing a newline
    
+character).  As with mandatory conditional newlines, this prevents any of
    
+the containing sections from being printed on one line.  In general, when
    
+an unconditional newline is encountered, it is printed out without
    
+suppression of the preceding blanks and without any indentation following
    
+it.  However, if a per-line prefix has been specified (see
    
+PPRINT-LOGICAL-BLOCK), this prefix will always be printed no matter how a
    
+newline originates.
    
+
    
+
    
+PPRINT-LOGICAL-BLOCK (stream-symbol list                     [Macro]
    
+                      &KEY :prefix :per-line-prefix :suffix)
    
+                     &BODY body
    
+
    
+This macro causes printing to be grouped into a logical block.  The value
    
+NIL is always returned.
    
+
    
+STREAM-SYMBOL must be a symbol.  If it is NIL, it is treated the same as
    
+if it were *STANDARD-OUTPUT*.  If it is T, it is treated the same as if
    
+it were *TERMINAL-IO*.  The run-time value of STREAM-SYMBOL must be a
    
+stream (or NIL standing for *STANDARD-OUTPUT* or T standing for *TERMINAL-IO*).
    
+The logical block is printed into this destination stream.
    
+
    
+The BODY can contain any arbitrary Lisp forms.  Within the BODY,
    
+STREAM-SYMBOL (or *STANDARD-OUTPUT* if STREAM-SYMBOL is NIL, or
    
+*TERMINAL-IO* if STREAM-SYMBOL is T) is bound to a `pretty printing' stream
    
+that supports decisions about the arrangement of output and then forwards
    
+the output to the destination stream.  All the standard printing functions
    
+(e.g., WRITE, PRINC, TERPRI) can be used to print output the pretty
    
+printing stream created by PPRINT-LOGICAL-BLOCK.  All and only the output
    
+sent to this pretty printing stream is treated as being in the logical
    
+block.
    
+
    
+PPRINT-LOGICAL-BLOCK and the pretty printing stream it creates have dynamic
    
+extent.  It is undefined what happens if output is attempted outside of
    
+this extent to the pretty printing stream created.  It is unspecified what
    
+happens if, within this extent, any output is sent directly to the
    
+underlying destination stream.
    
+
    
+The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that (at
    
+run time) evaluate to strings.  :SUFFIX (which defaults to the null string)
    
+specifies a suffix that is printed just after the logical block.  The
    
+:PREFIX and :PRE-LINE-PREFIX arguments are mutually exclusive.  If neither
    
+:PREFIX or :PER-LINE-PREFIX is specified, a :PREFIX of the null string is
    
+assumed.  :PREFIX specifies a prefix to be printed before the beginning of
    
+the logical block.  :PER-LINE-PREFIX specifies a prefix that is printed
    
+before the block and at the beginning of each new line in the block.  An
    
+error is signalled if :PREFIX and :PRE-LINE-PREFIX are both used or if the
    
+:SUFFIX, :PREFIX, or :PER-LINE-PREFIX do not evaluate to strings.
    
+
    
+LIST is interpreted as being a list that BODY is responsible for
    
+printing.  (See PPRINT-EXIT-IF-LIST-EXHAUSTED and PPRINT-POP.)  If
    
+LIST does not (at run time) evaluate to a list, it is printed using
    
+WRITE.  (This makes it easier to write printing functions that are
    
+robust in the face of malformed arguments.)  If *PRINT-CIRCLE* (and
    
+possibly *PRINT-SHARED*) is not NIL and LIST is a circular (or shared)
    
+reference to a cons, then an appropriate #n# marker is printed.  (This
    
+makes it easy to write printing functions that provide full support
    
+for circularity and sharing abbreviation.)  If *PRINT-LEVEL* is not
    
+NIL and the logical block is at a dynamic nesting depth of greater
    
+than *PRINT-LEVEL* in logical blocks, # is printed.  (This makes easy
    
+to write printing functions that provide full support for depth
    
+abbreviation.)
    
+
    
+If either of the three conditions above occurs, the indicated output is
    
+printed on STREAM-SYMBOL and the BODY is skipped along with the printing of
    
+the :PREFIX and :SUFFIX.  (If the BODY is not responsible for printing a
    
+list, then the first two tests above can be turned off by supplying NIL for
    
+the LIST argument.)
    
+
    
+In addition to the LIST argument of PPRINT-LOGICAL-BLOCK, the arguments of
    
+the standard printing functions such as WRITE, PRINT, PPRINT, PRINT1, and
    
+PPRINT, as well as the arguments of the standard FORMAT directives such as
    
+~A, ~S, (and ~W) are all checked (when necessary) for circularity and
    
+sharing.  However, such checking is not applied to the arguments of the
    
+functions WRITE-LINE, WRITE-STRING, and WRITE-CHAR or to the literal text
    
+output by FORMAT.  A consequence of this is that you must use one of the
    
+latter functions if you want to print some literal text in the output that
    
+is not supposed to be checked for circularity or sharing.  (See the
    
+examples below.)
    
+
    
+----------------------------------------
    
+
    
+Implementation note:  detection of circularity and sharing is supported by
    
+the pretty printer by in essence performing requested output twice.
    
+On the first pass, circularities and sharing are detected and the
    
+actual outputting of characters is suppressed.  On the second pass, the
    
+appropriate #n= and #n# markers are inserted and characters are output.
    
+
    
+A consequence of this two-pass approach to the detection of circularity and
    
+sharing is that the BODY of a PPRINT-LOGICAL-BLOCK must not perform any
    
+side-effects on the surrounding environment.  This includes not modifying
    
+any variables that are bound outside of its scope.  Obeying this
    
+restriction is facilitated by using PPRINT-POP, instead of an ordinary POP
    
+when traversing a list being printed by the BODY of a
    
+PPRINT-LOGICAL-BLOCK.)
    
+
    
+----------------------------------------
    
+
    
+
    
+PPRINT-EXIT-IF-LIST-EXHAUSTED                                       [Macro]  
    
+
    
+PPRINT-EXIT-IF-LIST-EXHAUSTED tests whether or not the LIST passed to
    
+PPRINT-LOGICAL-BLOCK has been exhausted (see PPRINT-POP).  If this list has
    
+been reduced to NIL, PPRINT-EXIT-IF-LIST-EXHAUSTED terminates the execution
    
+of the immediately containing PPRINT-LOGICAL-BLOCK except for the printing
    
+of the suffix.  Otherwise PPRINT-EXIT-IF-LIST-EXHAUSTED returns NIL.  An
    
+error message is issued if PPRINT-EXIT-IF-LIST-EXHAUSTED is used anywhere
    
+other than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.  It
    
+is undefined what happens if PPRINT-IF-LIST-EXHAUSTED is executed outside
    
+of the dynamic extent of this PPRINT-LOGICAL-BLOCK.
    
+
    
+
    
+PPRINT-POP                                                          [Macro]  
    
+
    
+PPRINT-POP pops elements one at a time off the LIST passed to
    
+PPRINT-LOGICAL-BLOCK obeying *PRINT-LENGTH*, *PRINT-CIRCLE*, and
    
+*PRINT-SHARED*.  An error message is issued if it is used anywhere
    
+other than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.
    
+It is undefined what happens if PPRINT-POP is executed outside of the
    
+dynamic extent of this PPRINT-LOGICAL-BLOCK.
    
+
    
+Each time PPRINT-POP is called, it pops the next value off the LIST
    
+passed to PPRINT-LOGICAL-BLOCK and returns it.  However, before doing
    
+this, it performs three tests.  If the remaining list is not a list
    
+(i.e., a cons or NIL), ". " is printed followed by the remaining list.
    
+(This makes it easier to write printing functions that are robust in
    
+the face of malformed arguments.)  If *PRINT-LENGTH* is NIL and
    
+PPRINT-POP has already been called *PRINT-LENGTH* times within the
    
+immediately containing logical block, "..." is printed.  (This makes
    
+it easy to write printing functions that properly handle
    
+*PRINT-LENGTH*.)  If *PRINT-CIRCLE* (and possibly *PRINT-SHARED*) is
    
+not NIL, and the remaining list is a circular (or shared) reference,
    
+then ". " is printed followed by an appropriate #n# marker.  (This
    
+catches instances of cdr circularity and sharing in lists.)
    
+
    
+If either of the three conditions above occurs, the indicated output is
    
+printed on the pretty printing stream created by the immediately containing
    
+PPRINT-LOGICAL-BLOCK and the execution of the immediately containing
    
+PPRINT-LOGICAL-BLOCK is terminated except for the printing of the suffix.
    
+
    
+If PPRINT-LOGICAL-BLOCK is given a LIST argument of NIL---because it is not
    
+processing a list---PPRINT-POP can still be used to obtain support for
    
+*PRINT-LENGTH* (see the example function PPRINT-VECTOR below).  In this
    
+situation, the first and third tests above are disabled and
    
+PPRINT-POP always returns NIL.
    
+
    
+
    
+PPRINT-INDENT relative-to n &OPTIONAL (stream *STANDARD-OUTPUT*) [Function]
    
+
    
+PPRINT-INDENT specifies the indentation to use in a logical block.  STREAM
    
+(which defaults to *STANDARD-OUTPUT*) follows the standard conventions for
    
+stream arguments to printing functions.  N specifies the indentation in
    
+ems.  If RELATIVE-TO is :BLOCK, the indentation is set to the horizontal
    
+position of the first character in the block plus N ems.  If RELATIVE-TO is
    
+:CURRENT, the indentation is set to the current output position plus N ems.
    
+(For robustness in the face of variable-width fonts, it is advisable to use
    
+:CURRENT with an N of zero whenever possible.)
    
+
    
+N can be negative; however, the total indentation cannot be moved left of
    
+the beginning of the line or left of the end of the rightmost per-line
    
+prefix.  Changes in indentation caused by PPRINT-INDENT do not take
    
+effect until after the next line break.  In addition, in miser mode all
    
+calls on PPRINT-INDENT are ignored, forcing the lines corresponding to the
    
+logical block to line up under the first character in the block.
    
+
    
+An error is signalled if a value other than :BLOCK or :CURRENT is supplied
    
+for RELATIVE-TO.  If STREAM is a pretty printing stream created by
    
+PPRINT-LOGICAL-BLOCK, PPRINT-INDENT sets the indentation in the innermost
    
+dynamically enclosing logical block.  Otherwise, PPRINT-INDENT has no
    
+effect.  The value NIL is always returned.
    
+
    
+
    
+PPRINT-TAB kind colnum colinc &OPTIONAL (stream *STANDARD-OUTPUT*) [function]
    
+
    
+PPRINT-TAB specifies tabbing as performed by the standard FORMAT directive
    
+~T.  STREAM (which defaults to *STANDARD-OUTPUT*) follows the standard
    
+conventions for stream arguments to printing functions.  The arguments
    
+COLNUM and COLINC correspond to the two parameters to ~T and are in terms
    
+of ems.  The KIND argument specifies the style of tabbing.  It must be one
    
+of :LINE (tab as by ~T) :SECTION (tab as by ~T, but measuring horizontal
    
+positions relative to the start of the dynamically enclosing section),
    
+:LINE-RELATIVE (tab as by ~@T), or :SECTION-RELATIVE (tab as by ~@T, but
    
+measuring horizontal positions relative to the start of the dynamically
    
+enclosing section).  An error is signalled if any other value is supplied
    
+for KIND.  If STREAM is a pretty printing stream created by
    
+PPRINT-LOGICAL-BLOCK, tabbing is performed.  Otherwise, PPRINT-TAB has no
    
+effect.  The value NIL is always returned.
    
+
    
+
    
+PPRINT-FILL STREAM LIST &OPTIONAL (COLON? T) ATSIGN?                 [function]
    
+PPRINT-LINEAR STREAM LIST &OPTIONAL (COLON? T) ATSIGN?               [function]
    
+PPRINT-TABULAR STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16) [function]
    
+
    
+These three functions specify particular ways of pretty printing lists.
    
+STREAM follows the standard conventions for stream arguments to printing
    
+functions.  Each function prints parentheses around the output if and only
    
+if COLON? (default T) is not NIL.  Each function ignores its ATSIGN?
    
+argument and returns NIL.  (These two arguments are included in this way so
    
+that these functions can be used via ~/.../ and as SET-PPRINT-DISPATCH
    
+functions as well as directly.)  Each function handles abbreviation and the
    
+detection of circularity and sharing correctly, and uses WRITE to print
    
+LIST when given a non-list argument.
    
+
    
+The function PPRINT-LINEAR prints a list either all on one line, or with
    
+each element on a separate line.  The function PPRINT-FILL prints a list
    
+with as many elements as possible on each line.  The function
    
+PPRINT-TABULAR is the same as PPRINT-FILL except that it prints the
    
+elements so that they line up in columns.  This function takes an
    
+additional argument TABSIZE (default 16) that specifies the column
    
+spacing in ems.
    
+
    
+---
    
+
    
+As an example of the interaction of logical blocks, conditional newlines,
    
+and indentation, consider the function SIMPLE-PPRINT-DEFUN below.  This
    
+function prints out lists whose cars are DEFUN in the standard way assuming
    
+that the list has exactly length 4.
    
+
    
+(defun simple-pprint-defun (*standard-output* list)
    
+  (pprint-logical-block (*standard-output* list :prefix "(" :suffix ")")
    
+    (write (first list))
    
+    (write-char #\space)
    
+    (pprint-newline :miser)
    
+    (pprint-indent :current 0)
    
+    (write (second list))
    
+    (write-char #\space)
    
+    (pprint-newline :fill)
    
+    (write (third list))
    
+    (pprint-indent :block 1)
    
+    (write-char #\space)
    
+    (pprint-newline :linear)
    
+    (write (fourth list))))
    
+
    
+Suppose that one evaluates the following:
    
+
    
+(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y)))
    
+
    
+If the line width available is greater than or equal to 26, then all of the
    
+output appears on one line.  If the line width available is reduced to 25,
    
+a line break is inserted at the linear-style conditional newline before the
    
+expression (* X Y), producing the output shown.  The (PPRINT-INDENT :BLOCK 1)
    
+causes (* X Y) to be printed at a relative indentation of 1 in the logical block.
    
+
    
+(DEFUN PROD (X Y) 
    
+  (* X Y))
    
+
    
+If the line width available is 15, a line break is also inserted at the
    
+fill style conditional newline before the argument list.  The call on
    
+(PPRINT-INDENT :CURRENT 0) causes the argument list to line up under the
    
+function name.
    
+
    
+(DEFUN PROD
    
+       (X Y)
    
+  (* X Y))
    
+
    
+If *PRINT-MISER-WIDTH* were greater than or equal to 14, the example output
    
+above would have been as follows, because all indentation changes are
    
+ignored in miser mode and line breaks are inserted at miser-style
    
+conditional newlines.
    
+
    
+(DEFUN
    
+ PROD
    
+ (X Y)
    
+ (* X Y))
    
+
    
+---
    
+
    
+As an example of a per-line prefix, consider that evaluating the following
    
+produces the output shown with a line width of 20 and *PRINT-MISER-WIDTH*
    
+of NIL.
    
+
    
+(pprint-logical-block (*standard-output* nil :per-line-prefix ";;; ")
    
+  (simple-pprint-defun *standard-output* '(defun prod (x y) (* x y))))
    
+
    
+;;; (DEFUN PROD
    
+;;;        (X Y)
    
+;;;   (* X Y))
    
+
    
+---
    
+
    
+As a more complex (and realistic) example, consider the function PPRINT-LET
    
+below.  This specifies how to print a LET in the standard style.  It is more
    
+complex than the example above, because it has to deal with nested structure.
    
+Also, unlike the example above it contains complete code to readably print any
    
+possible list that begins with the symbol LET.  The outermost
    
+PPRINT-LOGICAL-BLOCK handles the printing of the input list as a whole and
    
+specifies that parentheses should be printed in the output.  The second
    
+PPRINT-LOGICAL-BLOCK handles the list of binding pairs.  Each pair in the list
    
+is itself printed by the innermost PPRINT-LOGICAL-BLOCK.  (A LOOP is used
    
+instead of merely decomposing the pair into two elements so that readable
    
+output will be produced no matter whether the list corresponding to the pair
    
+has one element, two elements, or (being malformed) has more than two
    
+elements.)   A space and a fill-style conditional newline are placed after
    
+each pair except the last.  The loop at the end of the topmost
    
+PPRINT-LOGICAL-BLOCK prints out the forms in the body of the LET separated by
    
+spaces and linear-style conditional newlines.
    
+
    
+(defun pprint-let (*standard-output* list)
    
+  (pprint-logical-block (nil list :prefix "(" :suffix ")")
    
+    (write (pprint-pop))
    
+    (pprint-exit-if-list-exhausted)
    
+    (write-char #\space)
    
+    (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
    
+      (pprint-exit-if-list-exhausted)
    
+      (loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
    
+	      (pprint-exit-if-list-exhausted)
    
+	      (loop (write (pprint-pop))
    
+		    (pprint-exit-if-list-exhausted)
    
+		    (write-char #\space)
    
+		    (pprint-newline :linear)))
    
+	    (pprint-exit-if-list-exhausted)
    
+	    (write-char #\space)
    
+	    (pprint-newline :fill)))
    
+    (pprint-indent :block 1)
    
+    (loop (pprint-exit-if-list-exhausted)
    
+	  (write-char #\space)
    
+	  (pprint-newline :linear)
    
+	  (write (pprint-pop)))))
    
+
    
+Suppose that one evaluates the following with *PRINT-LEVEL* 4, and
    
+*PRINT-CIRCLE* T.
    
+
    
+(pprint-let *standard-output*
    
+	    '#1=(let (x (*print-length* (f (g 3))) 
    
+		      (z . 2) (k (car y)))
    
+		  (setq x (sqrt z)) #1#))
    
+
    
+If the line length is greater than or equal to 77, the output produced
    
+appears on one line.  However, if the line length is 76, line breaks are
    
+inserted at the linear-style conditional newlines separating the forms in
    
+the body and the output below is produced.  Note that, the degenerate
    
+binding pair X is printed readably even though it fails to be a list; a
    
+depth abbreviation marker is printed in place of (G 3); the binding pair
    
+(Z . 2) is printed readably even though it is not a proper list; and
    
+appropriate circularity markers are printed.
    
+
    
+#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y))) 
    
+     (SETQ X (SQRT Z))
    
+     #1#)
    
+
    
+If the line length is reduced to 35, a line break is inserted at one of the
    
+fill-style conditional newlines separating the binding pairs.
    
+
    
+#1=(LET (X (*PRINT-PRETTY* (F #))
    
+         (Z . 2) (K (CAR Y)))
    
+     (SETQ X (SQRT Z))
    
+     #1#)
    
+
    
+Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
    
+set to 3. In this situation, line breaks are inserted after both the first
    
+and second binding pairs.  In addition, the second binding pair is itself
    
+broken across two lines.  Clause (b) of the description of fill-style
    
+conditional newlines prevents the binding pair (Z . 2) from being printed
    
+at the end of the third line.  Note that the length abbreviation hides the
    
+circularity from view and therefore the printing of circularity markers
    
+disappears.
    
+
    
+(LET (X
    
+      (*PRINT-LENGTH*
    
+       (F #))
    
+      (Z . 2) ...)
    
+  (SETQ X (SQRT Z))
    
+  ...)
    
+
    
+---
    
+
    
+The function PPRINT-TABULAR could be defined as follows.
    
+
    
+(defun pprint-tabular (s list &optional (colon? T) atsign? (tabsize nil))
    
+  (declare (ignore atsign?))
    
+  (when (null tabsize) (setq tabsize 16))
    
+  (pprint-logical-block (s list :prefix (if colon? "(" "")
    
+			        :suffix (if colon? ")" ""))
    
+    (pprint-exit-if-list-exhausted)
    
+    (loop (write (pprint-pop) :stream s)
    
+	  (pprint-exit-if-list-exhausted)
    
+	  (write-char #\space s)
    
+	  (pprint-tab :section-relative 0 tabsize s)
    
+	  (pprint-newline :fill s))))
    
+
    
+Evaluating the following with a line length of 25 produces the output shown.
    
+
    
+(princ "Roads ") 
    
+(pprint-tabular *standard-output* '(elm main maple center) nil nil 8)
    
+
    
+Roads ELM     MAIN
    
+      MAPLE   CENTER
    
+
    
+---
    
+    
    
+The function below prints a vector using #(...) notation.
    
+     
    
+(defun pprint-vector (*standard-output* v)
    
+  (pprint-logical-block (nil nil :prefix "#(" :suffix ")")
    
+    (let ((end (length v)) (i 0))
    
+      (when (plusp end)
    
+	(loop (pprint-pop)
    
+	      (write (aref v i))
    
+	      (if (= (incf i) end) (return nil))
    
+	      (write-char #\space)
    
+	      (pprint-newline :fill))))))
    
+
    
+Evaluating the following with a line length of 15 produces the output shown.
    
+
    
+(pprint-vector *standard-output* '#(12 34 567 8 9012 34 567 89 0 1 23))
    
+
    
+#(12 34 567 8 
    
+  9012 34 567 
    
+  89 0 1 23)
    
+
    
+                     Format Directive Interface
    
+
    
+The primary interface to operations for dynamically determining the
    
+arrangement of output is provided through the functions above.  However, an
    
+additional interface is provided via a set of new format directives.
    
+This is done, because as shown by the examples in this section and the
    
+next, FORMAT strings are typically a much more compact way to specify
    
+pretty printing.  In addition, without such an interface, one would have to
    
+abandon the use of FORMAT when interacting with the pretty printer.
    
+
    
+~W                                                        [format directive]
    
+
    
+WRITE -- An arg, any Lisp object, is printed obeying every printer control
    
+variable (as by WRITE).  In addition, ~W interacts correctly with depth
    
+abbreviation, by not resetting the depth counter to zero.  ~W does not
    
+accept parameters.  If given the colon modifier, ~W binds *PRINT-PRETTY* to
    
+T.  If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
    
+to NIL.
    
+
    
+~W provides automatic support for the detection of circularity and
    
+sharing.  If *PRINT-CIRCLE* (and possibly *PRINT-SHARED*) is not NIL
    
+and ~W is applied to an argument that is a circular (or shared)
    
+reference, an appropriate #n# marker is inserted in the output instead
    
+of printing the argument.
    
+
    
+~_                                                        [format directive]
    
+
    
+CONDITIONAL-NEWLINE -- Without any modifiers, ~_ is the same as
    
+(PPRINT-NEWLINE :LINEAR).  ~@_ is the same as (PPRINT-NEWLINE :MISER).
    
+~:_ is the same as (PPRINT-NEWLINE :FILL).  ~:@_ is the same as
    
+(PPRINT-NEWLINE :MANDATORY).
    
+
    
+~<...~:>                                                  [format directive]
    
+
    
+LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
    
+is equivalent to a call on PPRINT-LOGICAL-BLOCK.  The FORMAT argument
    
+corresponding to the ~<...~:> directive is treated in the same way as
    
+the LIST argument to PPRINT-LOGICAL-BLOCK, thereby providing automatic
    
+support for non-list arguments and the detection of circularity,
    
+sharing, and depth abbreviation.  The portion of the FORMAT control
    
+string nested within the ~<...~:> specifies the :PREFIX (or
    
+:PER-LINE-PREFIX), :suffix}, and body of the PPRINT-LOGICAL-BLOCK.
    
+
    
+The FORMAT string portion enclosed by ~<...~:> can be divided into
    
+segments ~<prefix~;body~;suffix~:> by ~; directives.  If the first
    
+section is terminated by ~@;, it specifies a per-line prefix rather
    
+than a simple prefix.  The prefix and suffix cannot contain FORMAT
    
+directives.  An error is signalled if either the prefix or suffix
    
+fails to be a constant string or if the enclosed portion is divided
    
+into more than three segments.
    
+
    
+If the enclosed portion is divided into only two segments, the suffix
    
+defaults to the null string.  If the enclosed portion consists of only
    
+a single segment, both the prefix and the suffix default to the null
    
+string.  If the colon modifier is used (i.e., ~:<...~:>), the prefix
    
+and suffix default to "(" and ")" (respectively) instead of the null
    
+string.
    
+
    
+The body segment can be any arbitrary FORMAT control string.  This
    
+FORMAT control string is applied to the elements of the list
    
+corresponding to the ~<...~:> directive as a whole.  Elements are
    
+extracted from this list using PPRINT-POP, thereby providing automatic
    
+support for malformed lists, and the detection of circularity,
    
+sharing, and length abbreviation.  Within the body segment, ~^ acts
    
+like PPRINT-EXIT-IF-LIST-EXHAUSTED.
    
+
    
+~<...~:> supports a feature not supported by PPRINT-LOGICAL-BLOCK.  If
    
+~:@> is used to terminate the directive (i.e., ~<...~:@>), then a
    
+fill-style conditional newline is automatically inserted after each
    
+group of blanks immediately contained in the body (except for blanks
    
+after a ~<newline> directive).  This makes it easy to achieve the
    
+equivalent of paragraph filling.
    
+
    
+If the atsign modifier is used with ~<...~:>, the entire remaining argument
    
+list is passed to the directive as its argument.  All of the remaining
    
+arguments are always consumed by ~@<...~:>, even if they are not all used
    
+by the FORMAT string nested in the directive.  Other than the difference in
    
+its argument, ~@<...~:> is exactly the same as ~<...~:> except that
    
+circularity detection is not applied if ~@<...~:> is encountered at top
    
+level in a {\cd format} string.  This ensures that circularity detection is
    
+applied only to data lists, not to {\cd format} argument lists.
    
+
    
+" . #n#" is printed if circularity or sharing has
    
+to be indicated for its argument as a whole.
    
+
    
+To a considerable extent, the basic form of the directive ~<...~> is
    
+incompatible with the dynamic control of the arrangement of output by
    
+~W, ~_, ~<...~:>, ~I, and ~:T.  As a result, an error is signalled if
    
+any of these directives is nested within ~<...~>.  Beyond this, an
    
+error is also signalled if the ~<...~:;...~> form of ~<...~> is used
    
+in the same FORMAT string with ~W, ~_, ~<...~:>, ~I, or ~:T.
    
+
    
+~I                                                        [format directive]
    
+
    
+INDENT -- ~nI is the same as (PPRINT-INDENT :BLOCK N).
    
+~n:I is the same as (PPRINT-INDENT :CURRENT N).  In both cases, N defaults
    
+to zero, if it is omitted.
    
+
    
+~:T                                                       [format directive]
    
+
    
+TABULATE -- If the colon modifier is used with the ~T directive, the
    
+tabbing computation is done relative to the horizontal position where the
    
+section immediately containing the directive begins, rather than with
    
+respect to a horizontal position of zero.  The numerical parameters are
    
+both interpreted as being in units of ems and both default to 1.
    
+~n,m:T is the same as (PPRINT-TAB :SECTION N M).
    
+~n,m:@T is the same as (PPRINT-TAB :SECTION-RELATIVE N M).
    
+
    
+~/name/                                                   [format directive]
    
+
    
+CALL FUNCTION -- User defined functions can be called from within a FORMAT
    
+string by using the directive ~/name/.  The colon modifier, the atsign
    
+modifier, and arbitrarily many parameters can be specified with the ~/name/
    
+directive.  NAME can be any arbitrary string that does not contain a "/".
    
+All of the characters in NAME are treated as if they were upper case.  If
    
+NAME contains a ":" or "::", then everything up to but not including the
    
+first ":" or "::" is taken to be a string that names a package.  Everything
    
+after the first ":" or "::" (if any) is taken to be a string that names a
    
+symbol.  The function corresponding to a ~/name/ directive is obtained by
    
+looking up the symbol that has the indicated name in the indicated package.
    
+If NAME does not contain a ":" or "::", then the whole name string is
    
+looked up in the USER package.
    
+
    
+When a ~/name/ directive is encountered, the indicated function is called
    
+with four or more arguments.  The first four arguments are: the output
    
+stream, the FORMAT argument corresponding to the directive, the value T if
    
+the colon modifier was used (NIL otherwise), and the value T if the atsign
    
+modifier was used (NIL otherwise).  The remaining arguments consist of any
    
+parameters specified with the directive.  The function should print the
    
+argument appropriately.  Any values returned by the function are ignored.
    
+
    
+The three functions PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR are
    
+specifically designed so that they can be called by ~/.../ (i.e.,
    
+~/PPRINT-LINEAR/, ~/PPRINT-FILL/, and ~/PPRINT-TABULAR/).  In particular
    
+they take colon and atsign arguments.
    
+
    
+---
    
+
    
+As examples of the convenience of specifying pretty printing with FORMAT
    
+strings, consider that the first two functions used as examples in the last
    
+section can be compactly defined as follows.  The function PPRINT-VECTOR
    
+cannot be defined using FORMAT, because the data structure it traverses is
    
+not a list.  The function PPRINT-TABULAR is inconvenient to define using
    
+FORMAT, because of the need to pass its TABSIZE argument through to a ~:T
    
+directive nested within an iteration over a list.
    
+
    
+(defun simple-pprint-defun (*standard-output* list)
    
+  (format T "~:<~W ~@_~:I~W ~:_~W~1I ~_~W~:>" list))
    
+
    
+(defun pprint-let (*standard-output* list)
    
+  (format T "~:<~W~^ ~:<~@{~:<~@{~W~^ ~_~}~:>~^ ~:_~}~:>~1I~@{~^ ~_~W~}~:>" list)) 
    
+
    
+		   Compiling Format Control Strings
    
+
    
+The control strings used by FORMAT are essentially programs that perform
    
+printing.  The macro FORMATTER provides the efficiency of using a compiled
    
+function for printing without losing the compactness of FORMAT control
    
+strings.
    
+
    
+FORMATTER control-string                                           [macro]
    
+
    
+CONTROL-STRING must be a literal string.  An error is signalled if
    
+CONTROL-STRING is not a valid FORMAT control string.  The macro FORMATTER
    
+expands into an expression of the form (FUNCTION (LAMBDA (STREAM &REST
    
+ARGS) ...))  that does the printing specified by CONTROL-STRING.  The
    
+LAMBDA created accepts an output stream as its first argument and zero or
    
+more data values as its remaining arguments.  The value returned by the
    
+LAMBDA is the tail (if any) of the data values that are not printed out by
    
+CONTROL-STRING.  (E.g., if the CONTROL-STRING is "~A~A" the CDDR (if any)
    
+of the data values is returned.)
    
+
    
+For instance: (formatter "~%~2@{~S, ~}") is equivalent to
    
+
    
+#'(lambda (stream &rest args)
    
+    (terpri stream)
    
+    (dotimes (n 2)
    
+      (if (null args) (return nil))
    
+      (prin1 (pop args) stream)
    
+      (write-string ", " stream))
    
+    args)
    
+
    
+In support of the above, FORMAT is extended so that it accepts functions as
    
+its second argument as well as strings.  When a function is provided, it
    
+must be a function of the form created by FORMATTER.  The function is called
    
+with the appropriate output stream as its first argument and the data
    
+arguments to FORMAT as its remaining arguments.  The function should
    
+perform whatever output is necessary and return the unused tail of the
    
+arguments (if any).  The directives ~? and ~{~} with no body are also
    
+extended so that they accept functions as well as control strings.
    
+Every other standard function that takes a FORMAT string as an argument
    
+(e.g., ERROR and WARN) are also extended so that they can accept functions
    
+of the form above instead.
    
+
    
+			Pretty Print Dispatch Tables
    
+
    
+When *PRINT-PRETTY* is not NIL, the pprint dispatch table in the variable
    
+*PRINT-PPRINT-DISPATCH* controls how objects are printed.  The information
    
+in this table takes precedence over all other mechanisms for specifying how
    
+to print objects.  In particular, it overrides user-defined PRINT-OBJECT
    
+methods and print functions for structures.  However, if there is no
    
+specification for how to pretty print a particular kind of object, it is then
    
+printed using the standard mechanisms as if *PRINT-PRETTY* were NIL.
    
+
    
+Pprint dispatch tables are mappings from keys to pairs of values.  The keys
    
+are type specifiers.  The values are functions and numerical priorities.
    
+Basic insertion and retrieval is done based on the keys with the equality
    
+of keys being tested by EQUAL.  The function to use when pretty printing an
    
+object is chosen by finding the highest priority function from
    
+*PRINT-PPRINT-DISPATCH* that is associated with a type specifier that
    
+matches the object.
    
+
    
+
    
+COPY-PPRINT-DISPATCH &optional (table *PRINT-PPRINT-DISPATCH*)    [function]
    
+
    
+A copy is made of TABLE, which defaults to the current pprint dispatch
    
+table.  If TABLE is NIL, a copy is returned of the initial value of
    
+*PRINT-PPRINT-DISPATCH*.
    
+
    
+
    
+PPRINT-DISPATCH object &optional (table *PRINT-PPRINT-DISPATCH*)   [function] 
    
+
    
+This retrieves the highest priority function from a pprint table that is
    
+associated with a type specifier in the table that matches OBJECT.  The
    
+function is chosen by finding all the type specifiers in TABLE that match
    
+the object and selecting the highest priority function associated with any
    
+of these type specifiers.  If there is more than one highest priority
    
+function, an arbitrary choice is made.  If no type specifiers match the
    
+object, a function is returned that prints object with *PRINT-PRETTY* bound
    
+to NIL.
    
+
    
+As a second return value, PPRINT-DISPATCH returns a flag that is T if a
    
+matching type specifier was found in TABLE and NIL if not.
    
+
    
+TABLE (which defaults to *PRINT-PPRINT-DISPATCH*) must be a pprint dispatch
    
+table.  TABLE can be NIL, in which case retrieval is done in the initial
    
+value of *PRINT-PPRINT-DISPATCH*.
    
+
    
+When *PRINT-PRETTY* is T, (WRITE OBJECT :STREAM S) is equivalent to
    
+(FUNCALL (PPRINT-DISPATCH OBJECT) S OBJECT).
    
+
    
+
    
+SET-PPRINT-DISPATCH type-specifier function                        [function]
    
+                    &optional (priority 0) (table *PRINT-PPRINT-DISPATCH*)
    
+
    
+This puts an entry into a pprint dispatch table and returns NIL.
    
+TYPE-SPECIFIER must be a valid type specifier and is the key of the entry.
    
+The first action of SET-PPRINT-DISPATCH is to remove any pre-existing entry
    
+associated with TYPE-SPECIFIER.  This guarantees that there will never be
    
+two entries associated with the same type specifier in a given pprint
    
+dispatch table.  Equality of type specifiers is tested by EQUAL.
    
+
    
+Two values are associated with each type specifier in a pprint dispatch
    
+table: a function and a priority.  FUNCTION must accept two arguments: the
    
+stream to send output to and the object to be printed.  FUNCTION should
    
+pretty print the object on the stream.  FUNCTION can assume that object
    
+satisfies TYPE-SPECIFIER.  Function must obey *PRINT-READABLY* (see issue
    
+DATA-IO).  Any values returned by FUNCTION are ignored.
    
+
    
+PRIORITY (which defaults to 0) must be a non-complex number.  This
    
+number is used as a priority to resolve conflicts when an object
    
+matches more than one entry.  An error is signalled if priority fails
    
+to be a non-complex number.
    
+
    
+TABLE (which defaults to *PRINT-PPRINT-DISPATCH*) must be a pprint dispatch
    
+table.  The specified entry is placed in this table.
    
+
    
+It is permissible for FUNCTION to be NIL.  In this situation, there will be
    
+no TYPE-SPECIFIER entry in TABLE after SET-PPRINT-DISPATCH is evaluated.
    
+
    
+To facilitate the use of pprint dispatch tables for controlling the pretty
    
+printing of Lisp code, the TYPE-SPECIFIER argument of the function
    
+SET-PPRINT-DISPATCH is allowed to contain constructs of the form 
    
+
    
+           (CONS car-type cdr-type)
    
+
    
+This signifies that the corresponding object must be a cons cell whose car
    
+matches the type specifier CAR-TYPE and whose cdr matches the type specifier
    
+CDR-TYPE.  The CDR-TYPE can be omitted in which case it defaults to T.
    
+
    
+
    
+The initial value of *PRINT-PPRINT-DISPATCH* is implementation dependent.
    
+However, the initial entries all use a special class of priorities that
    
+have the property that they are less than every priority that can be
    
+specified using SET-PPRINT-DISPATCH.  The benefit of this is that it
    
+guarantees that any pretty printing functions users specify will override
    
+everything in the initial value of *PRINT-PPRINT-DISPATCH*.
    
+
    
+----------------------------------------------------------------------
    
+
    
+Implementation note:  The restriction above is very useful to users
    
+without actually limiting what Common Lisp implementors can do.  It is
    
+possible for implementors to set up any kind of pretty printing they
    
+desire using the range of priorities available to them.
    
+
    
+----------------------------------------------------------------------
    
+
    
+
    
+Consider the following examples.  The first form restores
    
+*PRINT-PPRINT-DISPATCH* to its initial value.  The next two forms then set
    
+up a special way to pretty print ratios.  Note that the more specific type
    
+specifier has to be associated with a higher priority.
    
+
    
+(setq *print-pprint-dispatch* (copy-pprint-dispatch nil))
    
+
    
+(set-pprint-dispatch 'ratio
    
+  #'(lambda (s obj)
    
+      (format s "#.(/ ~W ~W)" (numerator obj) (denominator obj))))
    
+
    
+(set-pprint-dispatch '(and ratio (satisfies minusp))
    
+  #'(lambda (s obj)
    
+      (format s "#.(- (/ ~W ~W))" (- (numerator obj)) (denominator obj)))
    
+  5)
    
+
    
+(pprint '(1/3 -2/3)) prints: (#.(/ 1 3) #.(- (/ 2 3)))
    
+
    
+The following two forms illustrate the definition of pretty printing
    
+functions for types of Lisp code.  The first form illustrates how to
    
+specify the traditional method for printing quoted objects using "'"
    
+syntax.  Note the care taken to ensure that data lists that happen to begin
    
+with QUOTE will be printed readably.  The second form specifies that lists
    
+beginning with the symbol MY-LET should print the same way that lists
    
+beginning with LET print when the initial pprint dispatch table is in effect.
    
+
    
+(set-pprint-dispatch '(cons (member quote)) () 
    
+  #'(lambda (s list)
    
+      (if (and (consp (cdr list)) (null (cddr list)))
    
+	  (funcall (formatter "'~W") s (cadr list))
    
+	  (pprint-fill s list)))))
    
+
    
+(set-pprint-dispatch '(cons (member my-let)) (pprint-dispatch '(let) nil))
    
+
    
+The next example specifies a default method for printing lists that do not
    
+correspond to function calls.  Note that, as shown in the definition of
    
+PPRINT-TABULAR above, PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR are
    
+all defined with optional COLON? and ATSIGN? arguments so that they can be
    
+used as pprint dispatch functions as well as ~/.../ functions.
    
+
    
+(set-pprint-dispatch '(cons (not (and symbol (satisfies fboundp))))
    
+                     #'pprint-fill -5)
    
+
    
+with a line length of 9, (pprint '(0 b c d e f g h i j k)) prints: 
    
+(0 b c d
    
+ e f g h
    
+ i j k)
    
+
    
+This final example shows how to define a pretty printing function for a
    
+user defined data structure.
    
+
    
+(defstruct family mom kids)
    
+
    
+(set-pprint-dispatch 'family
    
+  #'(lambda (s f)
    
+      (funcall (formatter "~@<#<~;~W and ~2I~_~/pprint-fill/~;>~:>")
    
+	       s (family-mom f) (family-kids f))))
    
+
    
+The pretty printing function for the structure FAMILY specifies how to
    
+adjust the layout of the output so that it can fit aesthetically into
    
+a variety of line widths.  In addition, it obeys the printer control
    
+variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*,
    
+*PRINT-CIRCLE*, *PRINT-SHARED* and *PRINT-ESCAPE*, and can tolerate
    
+several different kinds of malformity in the data structure.  The
    
+output below shows what is printed out with a right margin of 25,
    
+*PRINT-PRETTY* T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.
    
+
    
+(write (list 'principal-family
    
+             (make-family :mom "Lucy"
    
+                          :kids '("Mark" "Bob" . "Dan")))
    
+       :right-margin 25 :pretty T :escape nil :miser-width nil)
    
+
    
+(PRINCIPAL-FAMILY
    
+ #<Lucy and
    
+     Mark Bob . Dan>)
    
+ 
    
+Note that a pretty printing function for a structure is different from the
    
+structure's print function.  While print functions are permanently
    
+associated with a structure, pretty printing functions are stored in pprint
    
+dispatch tables and can be rapidly changed to reflect different printing
    
+needs.  If there is no pretty printing function for a structure in the
    
+current print dispatch table, the print function (if any) is used instead.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271.htm new file mode 100644 index 00000000..2347424a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271.htm @@ -0,0 +1,47 @@ + + + +CLHS: Issue PRINC-READABLY:X3J13-DEC-91 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINC-READABLY:X3J13-DEC-91 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PRINC-READABLY:X3J13-DEC-91:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271_w.htm new file mode 100644 index 00000000..d52f8f33 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss271_w.htm @@ -0,0 +1,154 @@ + + + +CLHS: Issue PRINC-READABLY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINC-READABLY Writeup

    + +
    Issue:         PRINC-READABLY
    
+References:    FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
    
+               WRITE (p. 382), *PRINT-PRETTY* (p. 371)
    
+Related Issues: DATA-IO, FORMAT-PRETTY-PRINT, PRINT-CIRCLE-SHARED
    
+Category:      CHANGE
    
+Edit history:  Version 1 by Moon 9/25/91
    
+
    
+Problem description:
    
+
    
+ What do you think this form outputs?
    
+
    
+ (let ((*print-readably* t))
    
+   (format t "<~A>" '|Foo|))
    
+
    
+ If you said <Foo>, that's what I expect it to output.  However a close
    
+ reading of CLtL2 shows that it is specified to print <|Foo|>.  Similarly
    
+ ~A is specified to put on a package prefix if ~S would, when
    
+ *PRINT-READABLY* is T.  ~D, etc. have the same problem, as does PRINC.
    
+ If *PRINT-READABLY* is true, the binding of *PRINT-ESCAPE* by these
    
+ FORMAT operators and by PRINC has no effect. 
    
+
    
+ See CLtL2 p.558 for the specification that *print-readably* overrides
    
+ *print-escape*, CLtL2 p.583 for the specification that ~A only binds
    
+ the printer control variables it is explicitly specified to bind,
    
+ CLtL2 p.584 for the specification that ~A only binds *print-escape*
    
+ (*print-readably* is not listed), and CLtL2 p.578 for the specification
    
+ that princ is the same as write with :escape nil (but not :readably nil).
    
+
    
+ Part of the problem appears to be that issue DATA-IO was written up
    
+ without any reference to issue FORMAT-PRETTY-PRINT.  I apologize.
    
+
    
+ A related problem is that the following form
    
+
    
+   (let ((*print-circle* t) (s "foo"))
    
+     (format t "~A ~A(~A, ~A)"
    
+             "moe" "bar" s s))
    
+
    
+ is specified to print ``moe bar(#1=foo, #1#)'' rather than
    
+ printing ``moe bar(foo, foo)''.
    
+
    
+ I discovered these problems when Macintosh Common Lisp was changed to
    
+ obey the letter of the law (as handed down in CLtL2) and a program of
    
+ mine stopped working.
    
+
    
+Proposal (PRINC-READABLY:FIX-BUGS):
    
+
    
+ 1. Specify that ~A binds *PRINT-READABLY* to NIL.
    
+
    
+ 2. Specify the same for ~B, ~D, ~E, ~F, ~G, ~O, ~nR, ~X, and ~$ (which
    
+    all turn into ~A for non-numeric arguments).
    
+
    
+ 3. Change the specification of (PRINC object stream) as equivalent to 
    
+
    
+      (WRITE object :STREAM stream :ESCAPE NIL)
    
+
    
+    to instead be equivalent to
    
+
    
+      (WRITE object :STREAM stream :ESCAPE NIL :READABLY NIL)
    
+
    
+ 4. Change PRINC-TO-STRING the same way.
    
+
    
+ 5. Change items 1 and 2 above also to bind *PRINT-CIRCLE* to NIL.
    
+    Change items 3 and 4 above also to specify :CIRCLE NIL.
    
+    This has been broken out into a separate numbered item to allow
    
+    for the possibility of voting separately on this change.
    
+
    
+Test Cases/Examples:
    
+
    
+ See "Problem description."
    
+
    
+Rationale:
    
+
    
+ Proposal DATA-IO:ADD-SUPPORT was not intended to "break" ~A;
    
+ this was an accident.
    
+
    
+ ~A and PRINC are supposed to produce "human-readable" output, so
    
+ they should not put on machine-readability decorations such as
    
+ vertical bars, backslashes, package prefixes, and #1#.
    
+
    
+ Point 5 means that ~A might not terminate when given a circular
    
+ structure to print, even if *PRINT-CIRCLE* is true.  The real problem
    
+ here is that *PRINT-CIRCLE* is being used for two distinct purposes,
    
+ detecting circular structure and detecting shared structure.  We do
    
+ not propose here to separate those two features (X3J13 voted
    
+ down a proposal, PRINT-CIRCLE-SHARED:NEW-VARIABLE, to do so once before).
    
+
    
+Current practice:
    
+
    
+ Macintosh Common Lisp 2.0b3c4 does not implement this proposal; it
    
+ implements exactly what CLtL2 specifies.
    
+
    
+ Symbolics Genera 8.1 implements the proposal, or at least produces the
    
+ proposed result for both test cases.  This might be due to assuming
    
+ that CLtL2 says something reasonable rather than reading the book with
    
+ a magnifying glass.
    
+
    
+Cost to Implementors:
    
+
    
+ Implementing the changes should take very little effort.
    
+
    
+Cost to Users:
    
+
    
+ Conceivably existing code could depend on the specified behavior,
    
+ but that seems quite unlikely, so the cost to users is probably minimal.
    
+
    
+Cost of non-Adoption:
    
+
    
+ A silly hassle for anyone using ~A and ~S to generate comments and
    
+ code respectively, with *PRINT-READABLY* and/or *PRINT-CIRCLE* turned
    
+ on for the benefit of the ~S.
    
+
    
+Benefits:
    
+
    
+ Fewer silly hassles.
    
+
    
+Aesthetics:
    
+
    
+ Does FORMAT have aesthetics?  If it does, I think the change improves
    
+ them slightly.
    
+
    
+Discussion:
    
+
    
+ Dave Moon and Guy Steele were both surprised that CLtL2 says what it says.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272.htm new file mode 100644 index 00000000..34a29ddc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue PRINT-CASE-BEHAVIOR:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINT-CASE-BEHAVIOR:CLARIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PRINT-CASE-BEHAVIOR:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272_w.htm new file mode 100644 index 00000000..5f11d975 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss272_w.htm @@ -0,0 +1,139 @@ + + + +CLHS: Issue PRINT-CASE-BEHAVIOR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINT-CASE-BEHAVIOR Writeup

    + +
    Issue:        PRINT-CASE-BEHAVIOR
    
+Forum:        X3J13 Letter Ballot
    
+References:   *PRINT-CASE* (X3J13/92-102, p22-65)
    
+	      *PRINT-ESCAPE* (X3J13/92-102, p22-67)
    
+	      Public review comment Pitman-8
    
+Category:     CLARIFICATION
    
+Edit history: 21-Jun-93, Version 1 by Steele (based on text by Loosemore)
    
+Status:		Proposal CLARIFY passed 11-0 on letter ballot 93-304.
    
+
    
+Problem Description:
    
+
    
+  This seems to be a case of poorly integrated cleanup issues.
    
+
    
+  We need to resolve ambiguities in the handling of *PRINT-CASE*.
    
+
    
+  The apparent contradictions are due to text from two proposals,
    
+  PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE and
    
+  READ-CASE-SENSITIVITY:READTABLE-KEYWORDS, that were previously adopted
    
+  by the committee.  Going by the order of the votes on these issues,
    
+  READ-CASE-SENSITIVITY has priority over PRINT-CASE-PRINT-ESCAPE-INTERACTION,
    
+  which in turn has priority over any text derived from the base document.
    
+
    
+Proposal (PRINT-CASE-BEHAVIOR:CLARIFY):
    
+
    
+  (a) This sentence on page 22-65:
    
+
    
+    Under no circumstance is
    
+    any character that is lowercase in the internal representation ever presented
    
+    as uppercase due to \varref{*print-case*}.
    
+
    
+  is quoted from the PRINT-CASE-PRINT-ESCAPE-INTERACTION proposal, which
    
+  was made obsolete by the subsequent adoption of the
    
+  READ-CASE-SENSITIVITY issue.  We propose to remove this sentence.
    
+
    
+  (b) The text in section 22.1.3.6.2 was derived from the 
    
+  READ-CASE-SENSITIVITY proposal (which actually says "vertical-bar
    
+  syntax" rather than "escape syntax").  We propose to replace the phrase
    
+
    
+    When \term{escape} syntax is not being used,
    
+
    
+  with
    
+
    
+    When both \varref{*print-escape*} and \varref{*print-readably*} are
    
+    \term{false}, or the characters under consideration are not already 
    
+    quoted specifically by \term{single escape} or \term{multiple escape}
    
+    syntax,
    
+
    
+  This choice is consistent with the decision from the
    
+  PRINT-CASE-PRINT-ESCAPE-INTERACTION proposal that the case in which
    
+  symbols print is affected by *PRINT-CASE* even when *PRINT-ESCAPE* is
    
+  false.  It is also consistent with the Guy Steele's interpretation
    
+  in the second edition of "Common Lisp, the Language".
    
+
    
+  (c) This text from the first paragraph of section 22.1.3.6
    
+
    
+    (but the case in which to print any uppercase characters in the
    
+    \term{name} is controlled by \thevariable{*print-case*}).
    
+
    
+  was derived from the base document and was made obsolete by the adoption
    
+  of the READ-CASE-SENSITIVITY proposal.  We propose to replace this with
    
+
    
+    (but the case in which to print characters in the \term{name} is
    
+    controlled by \varref{*print-case*};
    
+    \seesection{ReadtableCasePrintEffect}).
    
+  
    
+Test Case:
    
+
    
+  Not provided.
    
+
    
+Rationale:
    
+
    
+  We should better document the relationship between *PRINT-CASE* and
    
+  other printer control variables such as *PRINT-ESCAPE*.
    
+
    
+Current Practice:
    
+
    
+  Not provided.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably relatively small.
    
+
    
+Cost to Users:
    
+
    
+  None.  This change doesn't affect anything already guaranteed to the user.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Vagueness in the language specification.
    
+
    
+Benefits:
    
+
    
+  Better program portability.
    
+
    
+Editorial Impact:
    
+
    
+  Small.  A few small, localized edits.
    
+
    
+Aesthetics:
    
+
    
+  Mostly neutral.
    
+
    
+Discussion:
    
+  
    
+  This addresses comment Pitman #8.
    
+
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273.htm new file mode 100644 index 00000000..da12b00a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273_w.htm new file mode 100644 index 00000000..72b7e260 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss273_w.htm @@ -0,0 +1,215 @@ + + + +CLHS: Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION Writeup

    + +
    Status: proposal VERTICAL-BAR-RULE-NO-UPCASE passed, Jun 89 X3J13
    
+
    
+Issue:        PRINT-CASE-PRINT-ESCAPE-INTERACTION
    
+Forum:	      Cleanup
    
+References:   *PRINT-ESCAPE* (pp370-371), *PRINT-CASE* (pp372), WRITE
    
+Category:     CLARIFICATION
    
+Edit history: 26-Jan-89, Version 1 by Pitman
    
+
    
+Problem Description:
    
+
    
+  The wording on page 372 of CLtL uses fuzzy terms that make it hard
    
+  to tell if *PRINT-ESCAPE* interacts with *PRINT-CASE*.
    
+
    
+  Paragraph 1 of the description of *PRINT-CASE* says "This variable
    
+  controls the case (upper, lower, or mixed) in which to print any
    
+  uppercase characters in the names of symbols when vertical-bar
    
+  syntax is used."
    
+
    
+  Paragraph 2 begins with the seemingly unambiguous statement "Lowercase
    
+  characters in the internal print name are always printed in lowercase"
    
+  but then goes on to muddy the water by saying "and are preceded by
    
+  a single escape character or enclosed by multiple escape characters".
    
+  This escaping presumably only happens in *PRINT-ESCAPE* T mode, which
    
+  leads one to wonder if other parts of the *PRINT-ESCAPE* description are
    
+  implicitly controlled by *PRINT-ESCAPE* as well.
    
+
    
+  The function WRITE is affected by implication.
    
+
    
+Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-PRIN1):
    
+
    
+  Define that *PRINT-CASE* cases characters the same as PRIN1 would.
    
+
    
+Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-WRITE-STRING):
    
+
    
+  Define that *PRINT-CASE* has an effect only when *PRINT-ESCAPE* is T.
    
+  When *PRINT-CASE* is NIL, WRITE-STRING is used directly.
    
+
    
+Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE):
    
+
    
+  Define that *PRINT-CASE* has an effect at all times when *PRINT-ESCAPE*
    
+  is NIL. Define that *PRINT-CASE* also has an effect when *PRINT-ESCAPE*
    
+  is T unless inside an escape context (i.e., unless between vertical bars
    
+  or after a slash). Under no circumstance is any character which was 
    
+  lowercase in the internal representation ever presented as uppercase
    
+  due to *PRINT-CASE*.
    
+
    
+Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-PERMIT-UPCASE):
    
+
    
+  Like VERTICAL-BAR-RULE-NO-UPCASE, but permit *PRINT-CASE* to upcase
    
+  lowercase characters in the *PRINT-ESCAPE* NIL case since preservation of
    
+  Lisp syntax is not important there.
    
+
    
+Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:EXPLICITLY-VAGUE):
    
+
    
+  Specify that the effect of *PRINT-CASE* when *PRINT-ESCAPE* is NIL
    
+  is implementation-dependent.
    
+
    
+Test Case:
    
+
    
+  (LET ((RESULT '()) (TABWIDTH 12))
    
+    (DOLIST (SYMBOL '(|x| |FoObAr| |fOo|))
    
+      (LET ((TAB -1))
    
+	(FORMAT T "~&")
    
+	(DOLIST (ESCAPE '(T NIL))
    
+	  (DOLIST (CASE '(:UPCASE :DOWNCASE :CAPITALIZE))
    
+	    (FORMAT T "~VT" (* (INCF TAB) TABWIDTH))
    
+ 	    (WRITE SYMBOL :ESCAPE ESCAPE :CASE CASE))))))
    
+
    
+  For each of the following, two clusters of output is shown. The first is
    
+  how an implementation which leans heavily on vertical bars might work.
    
+  The second is how an implementation which leans heavily on slash might
    
+  work. In fact, other interpretations are possible (mixing slash and 
    
+  vertical bar). These examples are not an exhaustive analysis of the 
    
+  implications of each proposal.
    
+
    
+  Possible outputs under LIKE-PRIN1:
    
+
    
+  |x|        |x|         |x|         x           x           x
    
+  |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      FoObAr      FoObAr
    
+  |fOo|      |fOo|       |fOo|       fOo         fOo         fOo
    
+
    
+  \x         \x          \x          x           x           x
    
+  F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FoObAr      foobar      Foobar   
    
+  \fO\o      \fo\o       \fo\o       fOo         foo         foo
    
+
    
+  Possible output under LIKE-WRITE-STRING:
    
+
    
+  |x|        |x|         |x|         x           x           x
    
+  |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      FoObAr      FoObAr
    
+  |fOo|      |fOo|       |fOo|       fOo         fOo         fOo
    
+
    
+  \x         \x          \x          x           x           x
    
+  F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FoObAr      FoObAr      FoObAr
    
+  \fO\o      \fo\o       \fo\o       fOo         fOo         fOo
    
+
    
+  Possible output under VERTICAL-BAR-RULE-NO-UPCASE:
    
+
    
+  |x|        |x|         |x|         x           x           x
    
+  |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      foobar      Foobar
    
+  |fOo|      |fOo|       |fOo|       fOo         foo         foo
    
+
    
+  \x         \x          \x          x           x           x
    
+  F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FoObAr      foobar      Foobar
    
+  \fO\o      \fo\o       \fo\o       fOo         foo         foo
    
+
    
+  Possible output under VERTICAL-BAR-RULE-PERMIT-UPCASE:
    
+
    
+  |x|        |x|         |x|         X           x           X
    
+  |FoObAr|   |FoObAr|    |FoObAr|    FOOBAR      foobar      Foobar
    
+  |fOo|      |fOo|       |fOo|       FOO         foo         Foo
    
+
    
+  \x         \x          \x          X           x           X
    
+  F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FOOBAR      foobar      Foobar
    
+  \fO\o      \fO\o       \fO\o       FOO         foo         Foo
    
+
    
+Rationale:
    
+
    
+  It's silly for implementations to vary on this point.
    
+
    
+Current Practice:
    
+
    
+  A strict reading of CLtL suggests that probably VERTICAL-BAR-RULE-NO-UPCASE
    
+  is the most correct. 
    
+
    
+  Symbolics Genera doesn't do any of these. It was trying to do 
    
+  VERTICAL-BAR-NO-UPCASE, but it had a bug which was about to be fixed when
    
+  this issue was raised.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably trivial.
    
+
    
+Cost to Users:
    
+
    
+  Negligible in most cases. Probably very few users depend on this.
    
+  Those who do depend on it probably do so because they think the
    
+  behavior doesn't vary and probably don't get the portable behavior they
    
+  expect.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Gratuitous variation between implementations.
    
+
    
+Benefits:
    
+
    
+  Cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  Anything that makes the language tighter probably improves aesthetics.
    
+
    
+  Only VERTICAL-BAR-RULE-PERMIT-UPCASE and LIKE-WRITE-STRING have really
    
+  useful behaviors in the :ESCAPE NIL situation. Of these, perhaps only
    
+  VERTICAL-BAR-RULE-PERMIT-UPCASE is really visually pleasant.
    
+
    
+Discussion:
    
+
    
+  Pitman doesn't think the particular choice is very important. He just
    
+  wants the issue to be resolved. His slight preference is for
    
+  VERTICAL-BAR-RULE-PERMIT-UPCASE, then LIKE-WRITE-STRING, then either
    
+  of LIKE-PRIN1 or VERTICAL-BAR-RULE-NO-UPCASE. He sees no reason to go
    
+  with EXPLICITLY-VAGUE unless we deadlock.
    
+
    
+  Michael Greenwald, who raised the issue at Symbolics, doesn't have
    
+  a preference either but believes that CLtL (perhaps unintentionally)
    
+  leans toward VERTICAL-BAR-RULE-NO-UPCASE.
    
+
    
+-----
    
+Additional Discussion from CL-Cleanup:
    
+
    
+  David Gray responds:
    
+    >   Possible output under VERTICAL-BAR-RULE-NO-UPCASE:
    
+    > 
    
+    >   |x|        |x|         |x|         x           x           x
    
+    >   |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      foobar      Foobar
    
+    >   |fOo|      |fOo|       |fOo|       fOo         foo         foo
    
+    This is exactly what the Explorer does.
    
+
    
+There are several options for this issue, but if you're looking for one
    
+to focus on, VERTICAL-BAR-RULE-NO-UPCASE is probably the one we'll push
    
+if this issue comes up for discussion since it is believed most compatible
    
+with current practice.
    
+ -kmp
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274.htm new file mode 100644 index 00000000..9b317cb8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274_w.htm new file mode 100644 index 00000000..9e8854ad --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss274_w.htm @@ -0,0 +1,74 @@ + + + +CLHS: Issue PRINT-CIRCLE-SHARED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINT-CIRCLE-SHARED Writeup

    + +
    Status: proposal RESPECT-PRINT-CIRCLE passed, as amended, Jun 89 X3J13
    
+ (another proposal NEW-VALUE was passed and then reconsidered.)
    
+
    
+Issue: PRINT-CIRCLE-SHARED
    
+Edit history: Version 1, 		KMP 3/30/89
    
+	      Version 2, Masinter, 2 Jul 89, as amended Jun 89 X3J13
    
+
    
+Problem Description:
    
+
    
+ A label defined with #n= is valid for the rest of 
    
+ the top-level call to READ on input, permitting
    
+    '(#1=(A B) #1#)
    
+ to designate ((A B) (A B)), where the two lists
    
+ (A B) are EQ.  However, on output the implementations
    
+ are only required to detect circularities, not sharing,
    
+ when *PRINT-CIRCLE* is T.  That is
    
+    (PRINT '(#1=(A #1#) #1#))
    
+ may print as
    
+    (#1=(A #1#) #2=(A #2#))
    
+ or (#1=(A #1#) #1#)
    
+
    
+Proposal (PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE):
    
+
    
+ Require the printer to use #n# to identify sharing
    
+ of EQL objects that would not READ to be EQL
    
+ when *PRINT-CIRCLE* is true, and not if false.
    
+
    
+Proposal (PRINT-CIRCLE-SHARED:NEW-VARIABLE):
    
+
    
+ Introduce *PRINT-SHARED*.  When *PRINT-CIRCLE*
    
+ and *PRINT-SHARED* are both true [rationale: 
    
+ check one variable first for efficiency], identify sharing 
    
+ with #n# in the printer. Otherwise, don't.
    
+
    
+Cost to Users:
    
+
    
+ Storage needed for detecting shared structure is slightly more.
    
+
    
+Current Practice:
    
+
    
+ Several implementations implement RESPECT-PRINT-CIRCLE.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275.htm new file mode 100644 index 00000000..2082dcbd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275_w.htm new file mode 100644 index 00000000..45c44c5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss275_w.htm @@ -0,0 +1,146 @@ + + + +CLHS: Issue PRINT-CIRCLE-STRUCTURE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINT-CIRCLE-STRUCTURE Writeup

    + +
    Status: Passed, Jan 89 X3J13, as amended
    
+Issue:         	PRINT-CIRCLE-STRUCTURE
    
+References:    	pp. 370-371
    
+Category:      	CLARIFICATION
    
+Edit history:	Version 4, Masinter, 17-Mar-89 (as amended)
    
+		Version 3, Masinter 10/8/88 (minor cleanup)
    
+                Version 2, Chris McConnell 10/05/88
    
+                Version 1, Chris McConnell 09/20/88
    
+
    
+Problem description:
    
+
    
+When a lisp object is printed that points to a structure with a user
    
+defined print-function and there is a pointer back to the containing
    
+object, the printer will recurse infinitely even when *print-circle*
    
+is set to T.  This prevents printing circular structures that point to
    
+objects that cannot be printed and prevents the development of new
    
+printed representations that can be read by the reader.
    
+
    
+Proposal PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK: 
    
+
    
+When *print-circle* is T, a user defined print-function can print
    
+objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
    
+and expect circularities to be detected and printed using #n# syntax.
    
+If a user defined print-function prints to a stream other than the one
    
+that was supplied, then circularity detection starts over for that
    
+stream. This applies to methods on PRINT-OBJECT in addition to
    
+:PRINT-FUNCTION options.
    
+
    
+Test Cases/Examples:
    
+
    
+;;;
    
+;;; Define a structure that can be circular and that has a slot with a
    
+;;; value that cannot be printed.
    
+;;;
    
+(defstruct (TEST (:print-function print-test))
    
+  ptr
    
+  (function #'(lambda (x) 
    
+		(error "No function is defined."))))
    
+
    
+;;;
    
+;;; This print function generates a machine readable printed
    
+;;; representation for a structure with a slot that cannot be printed.
    
+;;;
    
+(defun PRINT-TEST (structure stream depth)
    
+  (format stream "#S(TEST PTR ~S)" (test-ptr structure)))
    
+
    
+;;;
    
+;;; Define two structures that point to each other.  If this
    
+;;; expression successfully evaluates at the top level, then the
    
+;;; printed result should look like:
    
+;;; #1=#S(TEST PTR #S(TEST PTR #1#))
    
+;;;
    
+;;; If it does not work then it will generate an infinite printed
    
+;;; representation. 
    
+(setf *print-circle* t
    
+      *a (make-test)
    
+      *b (make-test)
    
+      (test-ptr *a) *b
    
+      (test-ptr *b) *a)
    
+
    
+
    
+Rationale:
    
+
    
+Many structures are circular and point to complex data structures that
    
+may include things like closures that cannot be printed.  It should be
    
+possible to define a way to print these data structures such that they
    
+can be read back in.  Common LISP provides two mechanisms for these
    
+problems (*print-circle* and the :print-function option to defstruct),
    
+but they do not currently work together in most implementations.
    
+
    
+Current practice:
    
+
    
+Lucid 3.0 and the Genera do work on the test case.  (Previous versions
    
+did not.)  KCL, Coral and Franz do not work.
    
+
    
+Cost to Implementors:
    
+
    
+Lucid and Symbolics have done it, so they could give an idea of the
    
+difficulty.  Possible techniques include passing the printer state
    
+information by dynamic binding rather than by explicit parameters or
    
+by supplying an internal stream to the user print function.
    
+
    
+Cost to Users: None
    
+
    
+Cost of non-adoption: 
    
+
    
+Currently this problem causes an infinite recursion whenever a user
    
+print-function prints a lisp object that contains the structure that
    
+is being printed by the user print function.  If nothing is done, this
    
+error will remain and the whole effort to provide a portable printed
    
+representation of LISP structures is of minimal usefulness.  In almost
    
+any real application, there are circular structures with non printable
    
+objects such as closures and hash tables that need to be printed.  In
    
+addition the development of printers for new reader macros becomes
    
+much more of an effort then it should be since it requires
    
+reimplementing the complete circularity detection mechanism.
    
+
    
+Benefits:
    
+
    
+If the proposal is adopted, then it becomes easier to define new
    
+printed representations that are compact and that still capture the
    
+information needed to rebuild data structure instances.  It allows a
    
+printed representation to hide the actual details of how a data
    
+structure is implemented in terms of underlying LISP data structures.
    
+
    
+Esthetics: 
    
+
    
+This proposal increases the uniformity of the language by making
    
+*print-circle* work in all cases including where a user has defined a
    
+new print function.
    
+
    
+Discussion:
    
+
    
+At least three members of the cleanup committee read this and think
    
+it looks good.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276.htm new file mode 100644 index 00000000..dfe7a690 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276.htm @@ -0,0 +1,46 @@ + + + +CLHS: Issue PRINT-READABLY-BEHAVIOR:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINT-READABLY-BEHAVIOR:CLARIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PRINT-READABLY-BEHAVIOR:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276_w.htm new file mode 100644 index 00000000..a657b422 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss276_w.htm @@ -0,0 +1,150 @@ + + + +CLHS: Issue PRINT-READABLY-BEHAVIOR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINT-READABLY-BEHAVIOR Writeup

    + +
    Issue:        PRINT-READABLY-BEHAVIOR
    
+Forum:        X3J13 Letter Ballot
    
+References:   *PRINT-READABLY* (X3J13/92-102, p22-74)
    
+	      Public review comment Loosemore-24
    
+Category:     CLARIFICATION
    
+Edit history: 21-Jun-93, Version 1 by Steele (based on text by Loosemore)
    
+Status:		Proposal CLARIFY passed (9+2)-0 on letter ballot 93-304.
    
+
    
+Problem Description:
    
+
    
+  In E-mail amongst the public review committee, we had agreed that this
    
+  was another case of a previous cleanup vote that had not been adequately
    
+  integrated with the rest of the document.  Supposedly, there are no
    
+  technical changes being recommended here.
    
+
    
+  The proposal DATA-IO:ADD-SUPPORT that was the basis for adding
    
+  *PRINT-READABLY* to the language is clear on this issue.  However,
    
+  the document as it now stands does not accurately reflect
    
+  the proposal, or contain adequate cross-references.
    
+
    
+Proposal (PRINT-READABLY-BEHAVIOR:CLARIFY):
    
+
    
+  Make the following changes to the dpANS:
    
+
    
+  (1) Remove this inaccurate statement from the "Notes" section for
    
+  *PRINT-READABLY*:
    
+
    
+    The printing of interned \term{symbols}, of \term{strings}, 
    
+    and of \term{bit vectors} is not affected by \varref{*print-readably*}.
    
+
    
+  (2) In the "Description" section for *PRINT-READABLY*, add after the
    
+  first paragraph:
    
+
    
+    Specifically, if \varref{*print-readably*} is \term{true}, printing
    
+    proceeds as if \varref{*print-escape*}, \varref{*print-array*}, and
    
+    \varref{*print-gensym*} were also \term{true}, and as if 
    
+    \varref{*print-length*}, \varref{*print-level*}, and 
    
+    \varref{*print-lines*} were \term{false}.
    
+
    
+  (3) In section 22.1.3, change numerous references to *PRINT-ESCAPE*
    
+  to include both *PRINT-ESCAPE* and *PRINT-READABLY*.
    
+
    
+  (4) Rewrite section 22.1.3.10 as follows.  Prefix the first paragraph
    
+  with:
    
+
    
+    If \varref{*print-array*} is \term{true} and \varref{*print-readably*}
    
+    is \term{false}, any \term{vector} ....
    
+
    
+  Change the beginning of the next-to-last paragraph to:
    
+
    
+    If both \varref{*print-array*} and \varref{*print-readably*} are 
    
+    \term{false}, the \term{vector} is not printed ...
    
+
    
+  Add a new paragraph before the last paragraph:
    
+
    
+    If \varref{*print-readably*} is true, the \term{vector} prints in an
    
+    \term{implementation-defined} manner.  See \varref{*print-readably*}.
    
+
    
+
    
+  (5) Rewrite section 22.1.3.11 as follows.  Prefix the first paragraph
    
+  with:
    
+
    
+    If \varref{*print-array*} is \term{true} and \varref{*print-readably*}
    
+    is \term{false}, any \term{array} ...
    
+
    
+  Change the beginning of the next-to-last paragraph to:
    
+
    
+    If both \varref{*print-array*} and \varref{*print-readably*} are 
    
+    \term{false}, the \term{array} is printed ...
    
+
    
+  Add a new paragraph before the last paragraph:
    
+
    
+    If \varref{*print-readably*} is true, the \term{array} prints in an
    
+    \term{implementation-defined} manner.  See \varref{*print-readably*}.
    
+  
    
+Test Case:
    
+
    
+  Not provided.
    
+
    
+Rationale:
    
+
    
+  We should better document the relationship between *PRINT-READABLY* and
    
+  other printer control variables such as *PRINT-ESCAPE*.
    
+
    
+Current Practice:
    
+
    
+  Not provided.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably relatively small.
    
+
    
+Cost to Users:
    
+
    
+  None.  This change doesn't affect anything already guaranteed to the user.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Vagueness in the language specification.
    
+
    
+Benefits:
    
+
    
+  Better program portability.
    
+
    
+Editorial Impact:
    
+
    
+  Small.  A few small, localized edits.
    
+
    
+Aesthetics:
    
+
    
+  Mostly neutral.
    
+
    
+Discussion:
    
+  
    
+  This addresses comment Loosemore #24.
    
+
    
+
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277.htm new file mode 100644 index 00000000..5c4f016c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue PRINTER-WHITESPACE:JUST-ONE-SPACE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PRINTER-WHITESPACE:JUST-ONE-SPACE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PRINTER-WHITESPACE:JUST-ONE-SPACE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277_w.htm new file mode 100644 index 00000000..b52b727c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss277_w.htm @@ -0,0 +1,120 @@ + + + +CLHS: Issue PRINTER-WHITESPACE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PRINTER-WHITESPACE Writeup

    + +
    Issue:        PRINTER-WHITESPACE
    
+Forum:	      X3J13 Letter Ballot
    
+References:   22.1.3.8 (pp22-7..22-8),
    
+	      22.1.3.10 (p22-9)
    
+Category:     CLARIFICATION
    
+Edit history: 16-Jun-93, Version 1 by Pitman
    
+Status:       Proposal JUST-ONE-SPACE passed (7+1)-3 on letter ballot 93-304
    
+
    
+
    
+Problem Description:
    
+
    
+  In the descriptions of how lists and vectors print, the draft 
    
+  standard says "whitespace" is printed where CLtL1 says "a space".
    
+  Is this an unintentional change?
    
+
    
+Proposal (PRINTER-WHITESPACE:JUST-ONE-SPACE):
    
+
    
+  When *print-pretty* is false, require the printer to use exactly
    
+  one space in the indicated situations.  In general, when *print-pretty*
    
+  is false, recommend that implementations and users output a minimum
    
+  of space in this situation.  [This is status quo under CLtL1]
    
+
    
+  Rationale: This forces implementations to use very little space
    
+             and makes printer behavior more regular across implementations.
    
+
    
+Proposal (PRINTER-WHITESPACE:WHITESPACE):
    
+
    
+  Affirm that where the printer is defined to output whitespace,
    
+  arbitrary whitespace is permissible.  Recommend that implementations
    
+  and users use a minum of whitespace when *print-pretty* is false,
    
+  but permit flexibility.  [This is status quo under dpANS]
    
+
    
+  Rationale: This makes it less likely that users will write code
    
+	     that is not robust in the face of varying amounts of 
    
+	     whitespace inserted by entities other than the printer
    
+	     (e.g., a human being).
    
+
    
+Test Cases:
    
+
    
+  #1: (CHAR (FORMAT NIL "~S" '(A B)) 2)
    
+  might return #\Space in some implementations and #\Newline in others.
    
+
    
+  #2: (CHAR (FORMAT NIL "~S" '(A B)) 3)
    
+  might return #\Space in some implementations and #\B in others.
    
+
    
+  #3: (LENGTH (FORMAT NIL "~S" '(A B)))
    
+  might return 5 in some implementations or greater numbers in others.
    
+
    
+Current Practice:
    
+
    
+  Not provided.
    
+
    
+Cost to Implementors:
    
+
    
+  JUST-ONE-SPACE: Relatively small.
    
+  WHITESPACE:     None. (status quo)
    
+
    
+Cost to Users:
    
+
    
+  JUST-ONE-SPACE: None.
    
+  WHITESPACE:     None. (status quo)
    
+
    
+Cost of Non-Adoption:
    
+
    
+  See Rationale above.
    
+
    
+Benefits:
    
+
    
+  See above.
    
+
    
+Editorial Impact:
    
+
    
+  Small.
    
+
    
+Aesthetics:
    
+
    
+  Some people might quibble a little, but mostly pretty neutral.
    
+
    
+Discussion:
    
+
    
+  This is in response to Public Review comment Loosemore #15.
    
+
    
+  Pitman prefers option WHITESPACE.
    
+
    
+  Pitman believes the complained-about change occurred during 
    
+  the integration of the pretty printer description with the 
    
+  printer chapter.  At Waters' direction,  he allowed this change 
    
+  to be taken as editorial--probably a bad idea in retrospect.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278.htm new file mode 100644 index 00000000..2c235c6e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278_w.htm new file mode 100644 index 00000000..988bafc5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss278_w.htm @@ -0,0 +1,211 @@ + + + +CLHS: Issue PROCLAIM-ETC-IN-COMPILE-FILE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PROCLAIM-ETC-IN-COMPILE-FILE Writeup

    + +
    Issue:		PROCLAIM-ETC-IN-COMPILE-FILE
    
+References:	CLtL p. 182 [package functions],
    
+		  p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];
    
+                Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    
+		Issue IN-PACKAGE-FUNCTIONALITY
    
+		Issue EVAL-WHEN-NON-TOP-LEVEL
    
+		Issue DEFINING-MACROS-NON-TOP-LEVEL
    
+Category:	CLARIFICATION, CHANGE, ADDITION
    
+Edit History:   15 Sep 88, V1 by David Gray
    
+                23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
    
+		11 Mar 89, V3 by Sandra Loosemore (rewrite)
    
+		13 Mar 89, V4 by Sandra Loosemore (discussion)
    
+Status:		**DRAFT**
    
+ 
    
+
    
+Problem Description:
    
+
    
+  Should the compiler treat top-level calls to PROCLAIM specially?
    
+
    
+  Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
    
+  to the following package functions as though they were wrapped in an
    
+  (EVAL-WHEN (COMPILE LOAD EVAL) ...):
    
+
    
+    EXPORT  IMPORT  IN-PACKAGE  MAKE-PACKAGE SHADOW
    
+    SHADOWING-IMPORT  UNEXPORT  UNUSE-PACKAGE  USE-PACKAGE
    
+
    
+  CLtL is silent on whether top-level calls to PROCLAIM should also be
    
+  evaluated at compile-time, which presumably means they shouldn't be.
    
+  However, some implementations do evaluate PROCLAIM at compile-time.
    
+
    
+  In the model of how COMPILE-FILE works that is presented in issues
    
+  EVAL-WHEN-NON-TOP-LEVEL and DEFINING-MACROS-NON-TOP-LEVEL, the special
    
+  form EVAL-WHEN is the only thing that can cause compile-time evaluation
    
+  to occur.  The compile-time side-effects of macros such as DEFMACRO
    
+  and DEFPACKAGE are explained by having them include EVAL-WHEN in their
    
+  expansions.  Any functions that are treated specially, however, must
    
+  be included as special cases in the compiler.
    
+
    
+  Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the
    
+  requirement that the package functions be treated specially.  Do we
    
+  wish to make an exception to the model for PROCLAIM?
    
+
    
+
    
+Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
    
+
    
+  Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
    
+  were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).
    
+
    
+  Rationale:
    
+
    
+    Proclamations affect compilation semantics and should be made 
    
+    available to the compiler.
    
+
    
+
    
+Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
    
+
    
+  Clarify that calls to PROCLAIM should be treated the same as any
    
+  other function call.  Users should wrap an explicit EVAL-WHEN around
    
+  top-level calls to PROCLAIM if they want them to affect compilation.
    
+
    
+  Rationale:
    
+
    
+    This makes the semantics of COMPILE-FILE more uniform and easier 
    
+    to understand.  In particular, if we remove the magic compile-time
    
+    behavior of the package functions, it seems silly to add another
    
+    exception for PROCLAIM.
    
+
    
+
    
+Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
    
+
    
+  Add a new macro:
    
+
    
+  DEFPROCLAIM &rest decl-specs					[Macro]
    
+
    
+  This macro PROCLAIMs the given <decl-specs>, which are not
    
+  evaluated.  If a call to this macro appears at top-level in a file
    
+  being processed by the file compiler, the proclamations are also
    
+  made at compile-time.  As with other defining macros, it is 
    
+  unspecified whether or not the compile-time side-effects of a 
    
+  DEFPROCLAIM persist after the file has been compiled.
    
+
    
+  Clarify that calls to PROCLAIM should be treated the same as any
    
+  other function call.  Users should wrap an explicit EVAL-WHEN around
    
+  top-level calls to PROCLAIM if they want them to affect compilation,
    
+  or use the macro DEFPROCLAIM.
    
+
    
+  Rationale:
    
+
    
+    The macro makes the proclamations available to the compiler in such
    
+    a way that does not require any special exceptions to be made in
    
+    the model of how COMPILE-FILE works.
    
+
    
+Current Practice:
    
+
    
+  The TI explorer apparently implements proposal YES, except that
    
+  (EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.
    
+  The Symbolics compiler has special top-level handling for PROCLAIM,
    
+  although the details are not clear.
    
+
    
+  Lisps developed at Utah (UCL, A-Lisp, PSL/PCLS) do not give PROCLAIM
    
+  any special compile-time handling.
    
+
    
+  Lucid does not evaluate calls to PROCLAIM at compile-time.
    
+
    
+  The IIM compiler has special top-level handling for PROCLAIM when
    
+  the argument is a constant.  The information is recorded in the remote
    
+  environment.
    
+
    
+Cost to implementors:
    
+
    
+  Since implementations are already required to have a mechanism for
    
+  compile-time handling of the package functions, it would probably
    
+  only require minor adjustments to add handling for PROCLAIM.
    
+
    
+Cost to users:
    
+
    
+  For proposal YES, users would have no way to suppress compile-time
    
+  evaluation of a top-level call to PROCLAIM.  Wrapping it in an
    
+  (EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
    
+  EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
    
+
    
+  Under any of these proposals, some users would probably have to
    
+  make minor changes to their code.
    
+  
    
+Benefits:
    
+
    
+  Users will know what to expect when they use PROCLAIM.
    
+  
    
+Costs of Non-Adoption: 
    
+
    
+  Users will not know what to expect when they use PROCLAIM.
    
+
    
+Aesthetics:
    
+
    
+  At least two people consider requiring magic behavior for certain
    
+  top-level function calls to be "semantically bletcherous".  Removing
    
+  all special cases for functions that are implicitly evaluated at
    
+  compile-time would simplify the model of how COMPILE-FILE works.
    
+
    
+  Programs look cleaner if EVAL-WHEN is only needed for unusual cases
    
+  instead of being required for the normal cases.
    
+ 
    
+Discussion:
    
+
    
+  The first version of this writeup also included REQUIRE with PROCLAIM,
    
+  but we have now voted to remove REQUIRE from the language entirely.
    
+  It also specified that OPTIMIZE proclamations should only have a local
    
+  effect within the file being compiled.  This was removed for 
    
+  consistency with other compile-time side-effects (such as those from
    
+  DEFMACRO), where their persistence is explicitly left unspecified.
    
+
    
+  Loosemore favors proposal NO, but wouldn't oppose proposal NEW-MACRO.
    
+
    
+  Kim Barrett says:
    
+
    
+    Proposal YES violates the general approach we've been taking of trying
    
+    to limit side-effects on the local environment during compilation.
    
+
    
+    Proposal NO makes PROCLAIM virtually worthless.
    
+
    
+    Proposal NEW-MACRO -- While this matches up with other stuff we've
    
+    been doing, I'm concerned about two things.  First, I really dislike
    
+    the name DEFPROCLAIM.  This thing isn't defining anything!  It sounds
    
+    like something that modifies the behavior of PROCLAIM, not something
    
+    that actually makes a proclamation.  Second, I'm concerned about the
    
+    cost to users.  I think the statement that
    
+
    
+    "Under any of these proposals, some users would probably have to make 
    
+    minor changes to their code."
    
+
    
+    is rather misleading for this case.  There are a lot of PROCLAIMs out
    
+    there.
    
+
    
+Loosemore replies:
    
+
    
+    ....but all of those uses of PROCLAIM are already nonportable.  No
    
+    matter what we do here, somebody is going to get burned.
    
+
    
+    Suggestions for better names for the macro are welcome.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279.htm new file mode 100644 index 00000000..672bc85e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279.htm @@ -0,0 +1,45 @@ + + + +CLHS: Issue PUSH-EVALUATION-ORDER:FIRST-ITEM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PUSH-EVALUATION-ORDER:FIRST-ITEM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue PUSH-EVALUATION-ORDER:FIRST-ITEM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_m.htm new file mode 100644 index 00000000..6ea1a586 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue PUSH-EVALUATION-ORDER Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue PUSH-EVALUATION-ORDER Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_w.htm new file mode 100644 index 00000000..3a877616 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss279_w.htm @@ -0,0 +1,236 @@ + + + +CLHS: Issue PUSH-EVALUATION-ORDER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PUSH-EVALUATION-ORDER Writeup

    + +
    Issue:         PUSH-EVALUATION-ORDER
    
+References:    CLtL p. 99 (generalized variables)
    
+               p. 270 (PUSH)
    
+               All macros that manipulate generalized variables
    
+               (SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
    
+               POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
    
+               ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
    
+               Issue SETF-FUNCTION-VS-MACRO.
    
+Category:      CLARIFICATION
    
+Edit History:  Version 1, 15-Oct-87, Jeff Peck
    
+               Version 2, 23-Oct-87, Larry Masinter
    
+               Version 3, 8-Nov-87, David Moon 
    
+               Version 4, 14-Nov-87, Larry Masinter 
    
+               Version 5, 25-Nov-87, Larry Masinter
    
+
    
+Problem Description:
    
+
    
+In the form (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1) should be
    
+evaluated before (ref2). 
    
+
    
+CLtL, page 99, in a discussion of generalized variable macros, states: 
    
+
    
+"Macros that manipulate generalized variables must guarantee the `obvious'
    
+semantics: subforms of generalized-variable references are evaluated ... in
    
+exactly the same order as they appear in the *source* program. The expansion of
    
+these macros must consist of code that follows these rules or has the same
    
+effect as such code.  This is accomplished by introducing temporary variables
    
+bound to the subforms of the reference."
    
+
    
+This paragraph and a discussion of SETF on the previous pages may also be
    
+interpreted as requiring that *all* subforms of such macro calls should be
    
+evaluated once, in source order, left to right.
    
+
    
+However, CLtL, page 270 states:
    
+
    
+"The effect of (PUSH Item Place) is roughly equivalent to
    
+
    
+    (SETF Place (CONS Item Place))
    
+
    
+except that the latter would evaluate any subforms of Place twice while PUSH
    
+takes care to evaluate them only once."
    
+
    
+Place and Item appear in different order in the PUSH form and the indicated
    
+equivalent SETF form.  Should the PUSH form have primacy over the obvious SETF
    
+form with respect to the left-to-right evaluation?
    
+
    
+Are all subforms in a macro call guaranteed to be evaluated in order, or only
    
+those subforms representing generalized variable references?
    
+
    
+The same question arises for other forms which manipulate generalized variables,
    
+e.g., PUSHNEW, INCF, DECF, and those defined with DEFINE-MODIFY-MACRO.
    
+
    
+Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
    
+
    
+This proposal is hard to state, although the intent is fairly clear: evalution
    
+proceeds from left to right whenever possible. The left-to-right rule does not
    
+remove the obligation on writers of macros and define-setf-method  to ensure
    
+left-to-right order, however. 
    
+
    
+In this proposal, a form is something whose syntactic use is such that it will
    
+be evaluated. A "subform" means a form that is nested inside another form -- not
    
+any object nested inside a form regardless of syntactic context. 
    
+
    
+(1) The evaluation ordering of subforms within a generalized variable reference
    
+is determined by the order specified by the second value returned by
    
+GET-SETF-METHOD. For all predefined generalized variable references (GETF, LDB),
    
+this order of evaluation is exactly left-to-right. When a generalized variable
    
+reference is derived from a macro expansion, this rule is applied *after* the
    
+macro is expanded to find the appropriate generalized variable reference. 
    
+
    
+This is intended to make it clear that if the user writes a DEFMACRO or
    
+DEFINE-SETF-METHOD that doesn't preserve order, the the order specified in the
    
+user's code holds; e.g., given 
    
+  (DEFMACRO WRONG-ORDER (X Y) `(GETF ,Y ,X))
    
+ that (PUSH <value> (WRONG-ORDER <place1> <place2>)).
    
+
    
+will evaluate <place2> first and then <place1> because that is the order they
    
+are evaluated in the macro expansion.
    
+ 
    
+(2) For the macros that manipulate generalized variables (PUSH, PUSHNEW, GETF,
    
+REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF, POP, and those defined with
    
+DEFINE-MODIFY-MACRO) the subforms of the macro call are evaluated exactly once
    
+in left to right order, with the subforms of the generalized variable references
    
+evaluted in the order specified in (1).
    
+
    
+PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, POP evaluate all
    
+subforms before modifying any of the generalized variable locations. SETF (in
    
+the case when the SETF macro has more than two arguments) performs its operation
    
+on each pair in sequence, i.e., in (SETF <place1> <value1> <place2> <value2>
    
+...), the subforms of <place1> and <value1> are evaluated, the location
    
+specified by <place1> is modified to contain the value returned by <value1>, and
    
+then the rest of the SETF form is processed in a like manner.
    
+
    
+(3) For the macros CHECK-TYPE, CTYPECASE, and CCASE, subforms of the generalized
    
+variable reference are evaluted once as in (1), but may be evaluted again if the
    
+type check files in the case of CHECK-TYPE or none of the cases hold in
    
+CTYPECASE and CCASE.
    
+
    
+(4) For the macro ASSERT, the order of evaluation of the generalized variable
    
+references is not specified.  
    
+
    
+(Rules 2, 3 and 4 cover all macros defined in Common Lisp that manupulate
    
+generalized variable references.)
    
+
    
+Examples:
    
+
    
+(LET ((REF2 (LIST '())))
    
+ (PUSH (PROGN (PRINC "1") 'REF-1)
    
+       (CAR (PROGN (PRINC "2") REF2))))
    
+
    
+Under this proposal, this would be required to print 12 and not 21.
    
+
    
+(LET (X)
    
+   (PUSH (SETQ X (LIST 'A))
    
+         (CAR (SETQ X (LIST 'B))))
    
+    X)
    
+
    
+; the PUSH first evalutes (SETQ X (LIST 'A)) =>  (A)
    
+; then evaluates (SETQ X (LIST 'B)) => (B)
    
+; then modifies the CAR of (this latest value) to be ((A) . B).
    
+; The result is (((A) . B)). 
    
+
    
+
    
+Documentation impact:
    
+
    
+PUSH should more appropriately be described as:
    
+
    
+"(PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item Place))
    
+except that the subforms of Place are evaluated only once, and Item is evaluated
    
+before Place."
    
+
    
+The phase "subforms of the reference" which appears several times in CLtL should
    
+be made more specific to be "subforms of the macro call," referring to the
    
+entire form that calls the generalized-variable manipulating macro.
    
+
    
+Rationale:
    
+
    
+This is the unstated intention of the page 97-100 discussion of
    
+generalized-variable referencing macros, and indeed the intended definition of
    
+"obvious semantics" for all macros.
    
+
    
+Current practice:
    
+
    
+Many implementations do not currently follow this evaluation order. In the form
    
+(PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place then Item.
    
+Symbolics evaluates Item then Place.
    
+
    
+
    
+For example, in Franz:
    
+
    
+(macroexpand '(push (ref1) (car (ref2))))
    
+
    
+    (LET* ((#:G8 (REF2))
    
+           (#:G7 (CONS (REF1) (CAR #:G8))))
    
+      (EXCL::.INV-CAR #:G8 #:G7)) 
    
+    
    
+In Symbolics Common Lisp, it returns:
    
+    
    
+    (LET* ((#:G5 (REF1))
    
+           (#:G4 (REF2)))
    
+      NIL
    
+      (SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
    
+
    
+
    
+Cost to implementors:
    
+
    
+Minimal, PUSH etc. could simply be defined by the appropriate macros.
    
+
    
+Cost to users:
    
+
    
+No currently portable program should be affected. However, this is a minor
    
+incompatible change for some implementations. No serious performance impact is
    
+expected; while some macro expansions may appear to be more verbose, most
    
+compilers deal reasonably with the required order of evaluation.
    
+
    
+Benefits:
    
+
    
+The implementation and semantics of PUSH become more well specified. This
    
+removes a source of non-portability, abeit likely rare.
    
+
    
+Esthetics:
    
+
    
+Common Lisp defines order of evaluation as left-to-right; this clarification
    
+ensures consistency across the language. 
    
+
    
+Discussion:
    
+
    
+This seems to be the intent of most of the relevant language in CLtL.
    
+
    
+For example, the second to last paragraph on page 99
    
+
    
+"As an example of these semantic rules, in the generalized-variable reference
    
+(setf reference value), the value form must be evaluated after all the subforms
    
+of the reference because the value form appears to the right of them."
    
+
    
+makes it clear that in this context the phrase "generalized-variable reference"
    
+was meant to refer to the entire macro call, not just the Place, and that order
    
+of evaluation rules are not limited to subforms of Places.  We hope the
    
+specification should adopt more consistent terminology.
    
+
    
+Note that DEFINE-SETF-METHOD is immune to the exception specified about DEFMACRO
    
+and DEFINE-SETF-METHOD, because since CLtL p.103 says about DEFINE-SETF-METHOD: 
    
+
    
+"This binding permits the body forms to be written without regard for
    
+order-of-evaluation issues."
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss280.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss280.htm new file mode 100644 index 00000000..9259ccbf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss280.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue PUSH-EVALUATION-ORDER:ITEM-FIRST Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PUSH-EVALUATION-ORDER:ITEM-FIRST Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue PUSH-EVALUATION-ORDER:ITEM-FIRST:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281.htm new file mode 100644 index 00000000..3a6709b3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue PUSHNEW-STORE-REQUIRED:UNSPECIFIED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue PUSHNEW-STORE-REQUIRED:UNSPECIFIED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue PUSHNEW-STORE-REQUIRED:UNSPECIFIED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281_w.htm new file mode 100644 index 00000000..cd87df0d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss281_w.htm @@ -0,0 +1,121 @@ + + + +CLHS: Issue PUSHNEW-STORE-REQUIRED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue PUSHNEW-STORE-REQUIRED Writeup

    + +
    Issue:              PUSHNEW-STORE-REQUIRED
    
+References:         PUSHNEW
    
+Related issues:     PUSH-EVALUATION-ORDER
    
+                    SETF-GET-DEFAULT
    
+Category:           CLARIFICATION
    
+Edit history:       v1, 14 Feb 1991, Sandra Loosemore
    
+                    v2, 26 Mar 1991, Sandra Loosemore (amendment from meeting)
    
+Status:             v2 (proposal UNSPECIFIED) accepted by X3J13, Mar 1991
    
+
    
+Problem description:
    
+
    
+  The description of the PUSHNEW macro says contradictory things about
    
+  whether the storing form for its place subform must or must not be 
    
+  evaluated in the situation where the <item> is already a member of
    
+  the list.
    
+
    
+  In CLtL, PUSHNEW is first described as:
    
+
    
+    If the <item> is not already a member of the list (...), then the 
    
+    <item> is consed onto the front of the list, and the augmented list is
    
+    stored back into <place> and returned; otherwise the unaugmented list
    
+    is returned.
    
+
    
+  This passage implies that PUSHNEW is effectively (modulo order of
    
+  evaluation issues and keyword arguments): 
    
+
    
+    (if (not (member <item> <place>))
    
+        (setf <place> (cons <item> <place>))
    
+        <place>)
    
+
    
+  which executes the storing form for <place> only if the member test
    
+  fails.
    
+
    
+  However, later on it's said that PUSHNEW is effectively (again modulo
    
+  order of evaluation issues and keyword arguments):
    
+
    
+    (setf <place> (adjoin <item> <place>))
    
+
    
+  which executes the storing form for <place> unconditionally.
    
+
    
+  So which of these two models for its expansion is correct?
    
+
    
+
    
+Proposal (PUSHNEW-STORE-REQUIRED:UNSPECIFIED):
    
+
    
+  Clarify that it is not specified whether PUSHNEW executes the storing
    
+  form for its <place> subform in the situation where the <item> is
    
+  already a member of the list.
    
+
    
+Rationale:
    
+
    
+  The store operation might be expensive and there's no point in doing
    
+  it if the value being stored hasn't changed.  On the other hand, in
    
+  some implementations PUSHNEW always does the store.
    
+
    
+Current Practice:
    
+
    
+  In both Lucid and Allegro, PUSHNEW always does the store.
    
+
    
+Cost to Implementors:
    
+
    
+  None.  No implementation is required to change.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.  
    
+
    
+Cost of non-adoption:
    
+
    
+  The description of PUSHNEW is confusing.
    
+
    
+Performance impact:
    
+
    
+  Not doing the store when it's not necessary can speed things up.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  PUSHNEW would be less confusing if we could just agree on one or 
    
+  the other of the two models as being correct and remove all mention
    
+  of the other from its description in the standard.
    
+
    
+Discussion:
    
+
    
+  There is a potential for generalization to other read-modify-write 
    
+  macros.  See the discussion section of issue SETF-GET-DEFAULT.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282.htm new file mode 100644 index 00000000..16a320da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue QUOTE-SEMANTICS:NO-COPYING Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue QUOTE-SEMANTICS:NO-COPYING Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue QUOTE-SEMANTICS:NO-COPYING:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282_w.htm new file mode 100644 index 00000000..bc6f96da --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss282_w.htm @@ -0,0 +1,257 @@ + + + +CLHS: Issue QUOTE-SEMANTICS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue QUOTE-SEMANTICS Writeup

    + +
    Forum:		Compiler
    
+Issue:		QUOTE-SEMANTICS
    
+Subsumes:	Issue QUOTE-MAY-COPY
    
+References:	CLtL p. 55, 78, 86, 143
    
+		Issue CONSTANT-COLLAPSING
    
+		Issue CONSTANT-COMPILABLE-TYPES
    
+		Issue CONSTANT-CIRCULAR-COMPILATION
    
+Category:	CLARIFICATION
    
+Edit History:   V1, 22 Jan 1989, Sandra Loosemore
    
+		V2, 13 Mar 1989, Sandra Loosemore (discussion)
    
+		V3, 22 Mar 1989, Sandra Loosemore (suggestions from Moon)
    
+Status:		Ready for release
    
+
    
+
    
+Problem Description:
    
+
    
+Is it permissible for COMPILE and EVAL to coalesce or copy constants?
    
+Are there constraints upon what kinds of objects may appear as
    
+constants in code processed by COMPILE or EVAL, similar to those for
    
+COMPILE-FILE?
    
+
    
+CLtL p86 states that (QUOTE <x>) simply returns <x>.  On p55 it is
    
+mentioned that the only self-evaluating forms that may be copied are
    
+numbers or characters.  It is also stated that an implementation is
    
+permitted to collapse (or coalesce) EQUAL constants "appearing in code
    
+to be compiled" (p78), which is defined to mean self-evaluating forms
    
+or objects contained in a QUOTE form (without reference to whether the
    
+form is processed by EVAL, COMPILE, or COMPILE-FILE).
    
+
    
+Because of its nature as a file processor, COMPILE-FILE generally must
    
+cause copies of constants to be constructed when the compiled code is
    
+loaded.  In a number of existing Lisp implementations, COMPILE also
    
+causes constant objects to be copied and/or coalesced.  There is also
    
+at least one implementation where constants are copied by EVAL in some
    
+circumstances.
    
+
    
+In the proposals that follow, "copying" is used to mean the process of
    
+constructing an object that is "similar as a constant" (as defined in
    
+proposal CONSTANT-COMPILABLE-TYPES:SPECIFY), but not necessarily EQL,
    
+to the original.
    
+
    
+The term "coalescing" is defined in the writeup for issue 
    
+CONSTANT-COLLAPSING.
    
+
    
+
    
+Proposal QUOTE-SEMANTICS:NO-COPYING:
    
+
    
+State that copying or coalescing of constants appearing in code
    
+processed by EVAL and COMPILE is not permitted; the resulting program
    
+must reference objects that are EQL to the corresponding objects in
    
+the source code.  The constraints on what kinds of objects may appear
    
+as constants (described in issues CONSTANT-COMPILABLE-TYPES and
    
+CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
    
+
    
+  Rationale:
    
+
    
+  This proposal is consistent with what many people think of as the
    
+  "traditional" semantics for QUOTE.  It gives users maximum flexibility
    
+  about what kinds of objects may appear as constants.
    
+
    
+
    
+Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:
    
+
    
+State that copying or coalescing of constants appearing in code
    
+processed by EVAL and COMPILE is permitted.  Copying or coalescing may
    
+only take place when the source code is "promoted" to being a program
    
+by EVAL or COMPILE, not at runtime.  Function definitions are promoted
    
+to being a program when the form enclosing the definition (e.g., a
    
+FUNCTION or DEFUN form) is promoted.
    
+
    
+Any object may validly appear as a constant in code processed by EVAL
    
+or COMPILE.  The constraints on what kinds of objects may appear as
    
+constants (described in issues CONSTANT-COMPILABLE-TYPES and
    
+CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.  For data
    
+types where proposal CONSTANT-COMPILABLE-TYPES:SPECIFY does not define
    
+the notion of "similar as a constant", an implementation is permitted
    
+to copy objects of that type only if it has extended "similar as a
    
+constant" to include that type.
    
+
    
+  Rationale:
    
+
    
+  This proposal is the most consistent with the semantics stated in CLtL.
    
+  It gives users maximum flexibility about what kinds of objects may
    
+  appear as constants.
    
+
    
+  Allowing constants to be coalesced or copied has advantages for
    
+  memory management; for example, constants can be copied to read-only
    
+  memory that does not need to be garbage-collected.
    
+
    
+
    
+Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:
    
+
    
+State that copying or coalescing of constants appearing in code
    
+processed by EVAL and COMPILE is permitted.  Copying or coalescing may
    
+only take place when the source code is "promoted" to being a program
    
+by EVAL or COMPILE, not at runtime.  Function definitions are promoted
    
+to being a program when the form enclosing the definition (e.g., a
    
+FUNCTION or DEFUN form) is promoted.
    
+
    
+The constraints on what kinds of objects may appear as constants
    
+(described in issues CONSTANT-COMPILABLE-TYPES and
    
+CONSTANT-CIRCULAR-COMPILATION) apply to EVAL and COMPILE as well as to
    
+COMPILE-FILE.
    
+
    
+  Rationale:
    
+
    
+  This makes the rules for handling of constants consistent between
    
+  EVAL, COMPILE, and COMPILE-FILE.  It gives implementors maximum 
    
+  flexibility in handling constants in EVAL and COMPILE.
    
+
    
+  Allowing constants to be coalesced or copied has advantages for
    
+  memory management; for example, constants can be copied to read-only
    
+  memory that does not need to be garbage-collected.
    
+
    
+
    
+Current Practice:
    
+
    
+Implementations in which COMPILE attempts to copy all constants
    
+include PSL/PCLS, Utah Common Lisp, and Kyoto Common Lisp.  UCL and
    
+KCL both implement COMPILE effectively as a combination of
    
+COMPILE-FILE and LOAD.
    
+
    
+In Lucid Common Lisp, constants are not normally copied by COMPILE,
    
+but since COMPILE does coalesce constants, it may cause QUOTE to
    
+return an object which is not EQL to the object which appeared in the
    
+source code.
    
+
    
+Symbolics Genera has COMPILE copy list, string, non-displaced array,
    
+and (I-Machine only) closure constants, but Moon says he thinks this
    
+is wrong.
    
+
    
+There is known to be at least one implementation where expanding the
    
+DEFUN macro causes all constants in the body of the function to be
    
+copied.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Proposal NO-COPYING would involve a significant cost in those
    
+implementations where constants are now copied or coalesced by EVAL
    
+and COMPILE.  The aspect that is likely to cause the most problems is
    
+that, in some implementations, the garbage collector assumes that
    
+constants referenced in compiled code have been copied to read-only
    
+storage and do not need to be scanned or relocated.  Changing this
    
+would require major changes to the internal representation of
    
+functions, memory management strategy, and/or the implementation of
    
+COMPILE.
    
+
    
+Some implementations would also require substantial changes to support
    
+proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS.  Implementations that
    
+would have garbage collection problems under proposal NO-COPYING would
    
+have the same problems under COPYING-ALLOWED-BUT-NO-CONSTRAINTS,
    
+unless they can define a copying behavior that will correctly handle
    
+objects of all possible datatypes.
    
+
    
+Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is
    
+required to support issues CONSTANT-COMPILABLE-TYPES and
    
+CONSTANT-CIRCULAR-COMPILATION.
    
+
    
+
    
+Cost to users:
    
+
    
+Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE
    
+may break some existing programs that assume constants in code
    
+processed by EVAL or COMPILE are always EQL to the corresponding
    
+objects in the source code.  Proposal SAME-AS-COMPILE-FILE may also
    
+break existing programs that depend on referencing "undumpable"
    
+constants in code processed by EVAL or COMPILE.  In both cases,
    
+however, the behavior is already nonportable.  Both proposals would
    
+permit implementations in which these programs now work to continue to
    
+provide their existing behavior.
    
+
    
+
    
+Benefits:
    
+
    
+The semantics of QUOTE are clarified.
    
+
    
+
    
+Discussion:
    
+
    
+This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy
    
+debate on the cl-compiler mailing list.
    
+
    
+This issue relates to conformance requirements.  Accepting either of
    
+proposals NO-COPYING or COPYING-ALLOWED-BUT-NO-CONSTRAINTS would mean
    
+that not all conforming programs could be compiled with COMPILE-FILE.
    
+Some people may find this disturbing, particularly since one of the
    
+goals of Common Lisp has been to try to eliminate differences in
    
+semantics between compiled and interpreted code.
    
+
    
+Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,
    
+since it requires essentially no conversion cost for implementors and
    
+does not break any user programs that are not already nonportable.
    
+
    
+JonL White says:
    
+  Since we have already passed the proposal that permits constants to 
    
+  be "read-only" -- it is an error to modify them -- and have already 
    
+  passed  the proposal that allows access to updateable structures -- 
    
+  LOAD-TIME-EVAL -- then there is no excuse for being overly concerned
    
+  with the storage address of quoted data.  People who have mistakenly 
    
+  used structured constants as updatable data should convert over to 
    
+  either LOAD-TIME-EVAL or DEFPARAMETER.
    
+
    
+Kent Pitman says:
    
+  The problem is that a lot of copying advocates have been going around
    
+  trying to use "the need for copying" as leverage for restricting
    
+  the set of things which I may quote. My view is that it is my write [sic]
    
+  to quote whatever I want, and it's up to the person who thinks they
    
+  can do something fun with copying to not get themselves in deeper than
    
+  they can handle.
    
+
    
+Jeff Dalton says: 
    
+  I would agree [with Pitman's remarks] too.  My only quibble is that
    
+  it's not just "the need for copying" that's used a lever.
    
+  "Consistency with file compilation" is also being used as a lever.
    
+
    
+UCL implements COMPILE by dumping and loading a temporary file using
    
+the same mechanisms as COMPILE-FILE and LOAD.  Leigh Stoller (one of
    
+the UCL compiler implementors) says that, even if this implementation
    
+technique is disallowed by the outcome of this issue, they would
    
+rather be nonconforming than change the implementation of COMPILE.  In
    
+addition to the change being a lot of work, he says he thinks that
    
+making COMPILE-FILE and COMPILE different would be "really dumb", and
    
+that having different conformance requirements for compiled and
    
+interpreted code would just encourage people to write programs that
    
+can't be compiled correctly.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283.htm new file mode 100644 index 00000000..264e6c7d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283_w.htm new file mode 100644 index 00000000..f36458f7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss283_w.htm @@ -0,0 +1,190 @@ + + + +CLHS: Issue RANGE-OF-COUNT-KEYWORD Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue RANGE-OF-COUNT-KEYWORD Writeup

    + +
    Issue:        RANGE-OF-COUNT-KEYWORD
    
+References:   :COUNT (p247), REMOVE[-xxx] (p253), DELETE[-xxx] (p254),
    
+	      [N]SUBSTITUTE[-xxx] (pp255-256)
    
+Category:     CLARIFICATION
    
+Edit history: 21-Aug-88, Version 1 by Dave Touretzky
    
+	      22-Aug-88, Version 2 by Pitman
    
+	      09-Oct-88, Version 3 by Pitman
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+ CLtL is overly vague about legal values for the :COUNT keyword
    
+ parameters to builtin functions such as the sequence functions. It
    
+ says that the keyword ``limits the number of elements [affected]''.
    
+ Implementations have varied in their interpretation of this phrase,
    
+ however.
    
+
    
+ CLtL p247 specifies that if the :COUNT parameter to functions such
    
+ as REMOVE and DELETE ``is NIL or is not supplied, all matching items
    
+ are affected.'' Because of the placement of this requirement
    
+ outside of the description of the functions affected, some
    
+ implementations have overlooked this requirement and had to be 
    
+ changed later.
    
+ 
    
+ CLtL doesn't say explicitly that the value of :COUNT must be an
    
+ integer, nor does it say what to do for negative values.
    
+
    
+ The fact that reasonable implementations disagree on some of the
    
+ details make this an obvious candidate for cleanup.
    
+
    
+Proposal (RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER):
    
+
    
+ Clarify that for the functions
    
+
    
+   REMOVE	REMOVE-IF	REMOVE-IF-NOT
    
+   DELETE	DELETE-IF	DELETE-IF-NOT
    
+   SUBSTITUTE	SUBSTITUTE-IF	SUBSTITUTE-IF-NOT
    
+   NSUBSTITUTE	NSUBSTITUTE-IF	NSUBSTITUTE-IF-NOT
    
+
    
+ the following restrictions on the :COUNT keyword parameter exist:
    
+
    
+   * The value of this parameter must be NIL or an integer.
    
+
    
+   * Using a negative integer value is functionally equivalent to
    
+     using a value of zero.
    
+
    
+Test Case:
    
+
    
+  #1: (REMOVE 'A '(A B A B) :COUNT  0)   => (A B A B)
    
+  #2: (REMOVE 'A '(A B A B) :COUNT -3)   => (A B A B)
    
+  #3: (REMOVE 'A '(A B A B) :COUNT NIL)  => (B B)
    
+  #4: (REMOVE 'A '(A B A B) :COUNT  1.0) is an error.
    
+  #5: (REMOVE 'A '(A B A B) :COUNT 'FOO) is an error.
    
+
    
+Rationale:
    
+
    
+ Disallowing non-integer numbers is probably the original intent and
    
+ is consistent with other functions such as NTH (p265) which accept
    
+ count-like arguments that are explicitly required to integers. This
    
+ restriction would presumably permit better optimizations in low-safety
    
+ mode on stock hardware.
    
+
    
+ Allowing NIL to be equivalent to no value allows a simplified flow
    
+ of control in some situations. For example, one can write
    
+  (DEFUN MYDEL (ITEM &OPTIONAL COUNT)
    
+    (DELETE ITEM *MYLIST* :COUNT COUNT))
    
+ where otherwise it might be necessary to write something like
    
+  (DEFUN MYDEL (ITEM &OPTIONAL (COUNT NIL COUNT-P))
    
+    (IF COUNT-P
    
+        (DELETE ITEM *MYLIST* :COUNT COUNT)
    
+        (DELETE ITEM *MYLIST*)))
    
+
    
+ Allowing negative numbers frees users from having to do an explicit
    
+ check for negative numbers when the value of :COUNT is computed by
    
+ some complicated expression. For example:
    
+  (DEFUN LEAVE-AT-MOST (N ITEM SEQUENCE &KEY (FROM-END T))
    
+    (REMOVE ITEM SEQUENCE 
    
+      :COUNT (PRINT (- (COUNT ITEM SEQUENCE) N))
    
+      :FROM-END FROM-END))
    
+  (LEAVE-AT-MOST 2 #\A "BANANAS")  ==>  "BANANS"
    
+  (LEAVE-AT-MOST 2 #\S "BANANAS")  ==>  "BANANAS"
    
+
    
+Current Practice:
    
+
    
+ [Note: Pitman didn't try these examples in KCL or CMU Common Lisp. He's
    
+  working from data in Touretzky's last draft of this proposal, so someone
    
+  from those camps might want to test the assertions made here.]
    
+
    
+ #1: All correct implementations presumably return (A B A B).
    
+     This value is consisent with this proposal.
    
+
    
+ #2: Symbolics Cloe returns (A B A B).
    
+     KCL returns (A B A B) for lists.
    
+     This value is forced by this proposal.
    
+
    
+     Symbolics Genera and CMU Common Lisp return (B B).
    
+     KCL does something bizarre for vectors (``pads with n blanks or
    
+      NILs, where -n is the value of the :count keyword parameter'',
    
+      says Touretzky.)
    
+     These implementations would have to change.
    
+
    
+ #3: All correct implementations presumably return (B B).
    
+     This value is consisent with this proposal.
    
+
    
+     Some implementations have been known to signal a wrong type
    
+     argument error in the past, but have presumably been fixed.
    
+
    
+ #4: Symbolics Genera and Symbolics Cloe return (B A B).
    
+     CMU Common Lisp returns (B B).
    
+     These behaviors are consistent with this proposal.
    
+  
    
+ #5: Symbolics Cloe and Symbolics Genera signal an error.
    
+     CMU Common Lisp returns (A B A B).
    
+     These behaviors are consistent with this proposal.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+  Some implementations would have to change. These functions are typically
    
+  heavily optimized by compilers. Not only source code, but also compiler
    
+  optimizers and perhaps even microcode or hardware might have to be
    
+  modified to fully accomodate this change, so it might be quite expensive.
    
+
    
+Cost to Users:
    
+
    
+  None for Common Lisp users. This change is an upward compatible
    
+  clarification of standard practice.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The behavior of these functions when given degenerate keyword values would
    
+  be unintuitive. In many such cases, considerable additional user code must
    
+  be written to watch for and avoid creating such situations.
    
+
    
+Benefits:
    
+
    
+  More compact, more intuitive, and more portable code.
    
+
    
+Aesthetics:
    
+
    
+  This change improves language aesthetics.
    
+
    
+Discussion:
    
+
    
+  In the past there has been some argument about what SUBSEQ should do when
    
+  given positions greater than the length of the sequence.  Currently it 
    
+  "is an error" to specify positions less than zero or greater than the
    
+  length of the sequence.  Touretzky doesn't think the same should apply to
    
+  the :COUNT keyword. The inputs to SUBSEQ are ordinal numbers: they specify
    
+  positions, like array subscripts.  The value of :COUNT is not an ordinal,
    
+  it is an upper bound on the size of the set of affected items (which is
    
+  a cardinal number).
    
+ 
    
+  Pitman supports this proposal. [Hopefully Touretzky supports it, too?]
    
+
    
+  van Roggen says he personally supports the stated proposal but that a
    
+  survey he did of users at DEC showed up a number of people who thought
    
+  that negative count arguments should be an error.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284.htm new file mode 100644 index 00000000..b4ef8fb9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284.htm @@ -0,0 +1,54 @@ + + + +CLHS: Issue RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284_w.htm new file mode 100644 index 00000000..eff6c355 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss284_w.htm @@ -0,0 +1,126 @@ + + + +CLHS: Issue RANGE-OF-START-AND-END-PARAMETERS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue RANGE-OF-START-AND-END-PARAMETERS Writeup

    + +
    Issue:        RANGE-OF-START-AND-END-PARAMETERS
    
+References:   COUNT (p257), COUNT-IF (p257), COUNT-IF-NOT (p257),
    
+	      DELETE (p257), DELETE-DUPLICATES (p254), DELETE-IF (p254),
    
+	      DELETE-IF-NOT (p254), FILL (p252), FIND (p257), FIND-IF (p257),
    
+	      FIND-IF-NOT (p257), MAKE-STRING-INPUT-STREAM (p330),
    
+	      MISMATCH (p257), NSTRING-CAPITALIZE (p304), 
    
+	      NSTRING-DOWNCASE (p304), NSTRING-UPCASE (p304), SUBSTITUTE (p255),
    
+	      NSUBSTITUTE-IF (p256), NSUBSTITUTE-IF-NOT (p256), 
    
+	      PARSE-INTEGER (p381), PARSE-NAMESTRING (p414), POSITION (p257),
    
+	      POSITION-IF (p257), POSITION-IF-NOT (p257), 
    
+	      READ-FROM-STRING (p381), REDUCE (p251), REMOVE (p253), 
    
+	      REMOVE-DUPLICATES (p254), REMOVE-IF (p253), REMOVE-IF-NOT (p253),
    
+	      REPLACE (p252), SEARCH (p258), STRING-CAPITALIZE (p303),
    
+	      STRING-EQUAL (p301), STRING-DOWNCASE (p303), STRING-GREATERP (p302),
    
+	      STRING-LESSP (p302), STRING-NOT-EQUAL (p302),
    
+	      STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
    
+	      STRING-UPCASE (p303), STRING/= (p301), STRING< (p301), 
    
+	      STRING<= (p301), STRING= (p300), STRING> (p301), STRING>= (p301),
    
+	      SUBSEQ (p248), SUBSTITUTE (p255), SUBSTITUTE-IF (p255), 
    
+	      SUBSTITUTE-IF-NOT (p255), WRITE-LINE (p384), WRITE-STRING (p384)
    
+Category:     CLARIFICATION
    
+Edit history: 14-Sep-88, Version 1 by Pitman
    
+
    
+Problem Description:
    
+
    
+  CLtL is not always clear about the possible values which the START and END
    
+  parameters of built-in Common Lisp can take.
    
+
    
+Proposal (RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL):
    
+
    
+  Clarify that for functions permitting a parameter named START, START1,
    
+  or START2 which delimits the beginning point in a sequence to be
    
+  considered for some operation, that paremeter must be a non-negative
    
+  integer. If the argument is optional or key (as is the case for all
    
+  functions referenced above except SUBSEQ), the value will default to
    
+  0 if not supplied. It is not permissible to pass NIL as this argument.
    
+
    
+  Clarify that for functions permitting a parameter named END, END1,
    
+  or END2 which delimits the end point in a sequence to be considered
    
+  for some operation, that paremeter must be a non-negative integer
    
+  indicating a termination point or NIL indicating the last element
    
+  in the sequence. If the argument is optional or key (as is the case
    
+  for all functions referenced above), the value will default to NIL
    
+  if not supplied. Supplying NIL is, therefore, equivalent to not
    
+  supplying this argument.
    
+
    
+Test Case:
    
+
    
+  (SEARCH "F" "FOO" :START1 NIL) is an error.
    
+
    
+  (SEARCH "F" "FOO" :START2 0) is permissible and is equivalent to
    
+  (SEARCH "F" "FOO")
    
+
    
+  (SEARCH "F" "FOO" :END2 NIL) is permissible and is equivalent to
    
+  (SEARCH "F" "FOO")
    
+
    
+Rationale:
    
+
    
+  To keep data flow between programs from becoming excessively complicated,
    
+  it's a good idea to specify what the default values are so that they can
    
+  be passed explicitly rather than requiring an alternate calling sequence
    
+  for all possible cases where the value might need to default.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera implements the proposed behavior.
    
+
    
+Cost to Implementors:
    
+
    
+  Hopefully most implementations already do this. Those that do not will
    
+  probably have to make quite a number of small changes to both the code
    
+  for these functions and to any associated compiler optimizers.
    
+
    
+Cost to Users:
    
+
    
+  This change is upward compatible with existing user code. Any program
    
+  which did not conform to this proposal was already not portable.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Subtle gratuitous differences in the handling of these arguments would
    
+  continue to be a possibility and a barrier to portability.
    
+
    
+Benefits:
    
+
    
+  The language would be more regular and well-defined.
    
+
    
+Aesthetics:
    
+
    
+  If it makes things clearer, it's an improvement.
    
+
    
+Discussion:
    
+
    
+  Pitman supports RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285.htm new file mode 100644 index 00000000..a9b51d3b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue READ-AND-WRITE-BYTES:NEW-FUNCTIONS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue READ-AND-WRITE-BYTES:NEW-FUNCTIONS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue READ-AND-WRITE-BYTES:NEW-FUNCTIONS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285_w.htm new file mode 100644 index 00000000..2e56ded2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss285_w.htm @@ -0,0 +1,226 @@ + + + +CLHS: Issue READ-AND-WRITE-BYTES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue READ-AND-WRITE-BYTES Writeup

    + +
    Issue:        READ-AND-WRITE-BYTES
    
+Reference:    X3J13/92-102, dpANS 12.24
    
+              X3J13/92-2601, Jeremy Wertheimer comment #1
    
+Category:     ADDITION
    
+Edit History: Version 1, 1/5/92, Kim Barrett
    
+Status:	      Proposal NEW-FUNCTIONS passed (5+3)-3 on letter ballot 93-302.
    
+
    
+Problem Description:
    
+
    
+ Common Lisp should have a facility for reading and writing blocks of 
    
+ binary bytes.  The lack of such a facility makes it impossible to write 
    
+ portable efficient programs to access binary files.  This lack might make 
    
+ common lisp unsuitable for various applications such as database management 
    
+ and image processing.  This lack is not simply a matter of convenience that
    
+ could be remedied by user programming.  If the standard does not provide at 
    
+ least one method for efficiently reading and writing blocks of binary bytes, 
    
+ users cannot later construct one using available common lisp facilities.
    
+
    
+ In addition, some users have complained about the lack of a non-consing
    
+ variant of READ-STRING, to which an existing string could be passed to receive
    
+ the data.
    
+
    
+Proposal (READ-AND-WRITE-BYTES:NEW-FUNCTIONS):
    
+
    
+ Add the following dictionary entries to Chapter 21, Streams.
    
+
    
+ %%% ========== READ-SEQUENCE
    
+ \begincom{read-sequence}\ftype{Function}
    
+
    
+ \label Syntax::
    
+
    
+ \DefunWithValues {read-sequence} {sequence stream {\key} start end} {position}
    
+
    
+ \param{sequence}---a \term{sequence}.
    
+
    
+ \param{stream}---an \term{input} \term{stream}.
    
+
    
+ \param{start}, \param{end}---\term{bounding index designators} of
    
+  \param{sequence}.  \Defaults{\param{start} and \param{end}}{\f{0} and \nil}
    
+
    
+ \param{position}---an \term{integer} greater than or equal to zero, and
    
+  less than or equal to the \term{length} of the \param{sequence}.
    
+
    
+ \label Description::
    
+
    
+ Destructively modifies \param{sequence} by replacing the \term{elements}
    
+ of \param{sequence} \term{bounded} by \param{start} and \param{end} with
    
+ \term{elements} read from \param{stream}.
    
+
    
+ \param{Sequence} is destructively modified by copying successive
    
+ \term{elements} into it from \param{stream}.  If the \term{end of file} for
    
+ \param{stream} is reached before copying all \term{elements} of the
    
+ subsequence, then the extra \term{elements} near the end of \param{sequence}
    
+ are not updated.
    
+
    
+ \param{Position} is the index of the first \term{element} of \param{sequence}
    
+ that was not updated, which might be less than \param{end} because the
    
+ \term{end of file} was reached.
    
+
    
+ \label Examples::
    
+
    
+ \code
    
+  (defvar *data* (make-array 15 :initial-element nil))
    
+  (values (read-sequence *data* (make-string-input-stream "test string")) *data*)
    
+  \EV 11, #(#\t #\e #\s #\t #\Space #\s #\t #\r #\i #\n #\g NIL NIL NIL NIL)
    
+ \endcode
    
+
    
+ \label Side Effects::
    
+
    
+ Modifies \param{stream} and \param{sequence}.
    
+
    
+ \label Affected By:\None
    
+
    
+ \label Exceptional Situations::
    
+
    
+ \Lazychecktype{sequence}{a \term{proper sequence}}
    
+ \Shouldchecktype{start}{a non-negative \term{integer}}
    
+ \Shouldchecktype{end}{a non-negative \term{integer} or \nil}
    
+
    
+ Might signal an error \oftype{type-error} if an \term{element} read from
    
+ the \param{stream} is not a member of the \term{element type} of the
    
+ \param{sequence}.
    
+
    
+ \label See Also::
    
+
    
+ {\secref\ConstantModification}, \funref{write-sequence}, \funref{read-line}
    
+
    
+ \label Notes::
    
+
    
+ \funref{read-sequence} is identical in effect to iterating over the indicated
    
+ subsequence and reading one \term{element} at a time from \param{stream} and
    
+ storing it into \param{sequence}, but may be more efficient than the
    
+ equivalent loop.  An efficient implementation is more likely to exist
    
+ for the case where the \param{sequence} is a \term{vector} with the same
    
+ \term{element type} as the \param{stream}.
    
+
    
+ %%% ========== WRITE-SEQUENCE
    
+ \begincom{write-sequence}\ftype{Function}
    
+
    
+ \label Syntax::
    
+
    
+ \DefunWithValues {write-sequence} {sequence stream {\key} start end} {sequence}
    
+
    
+ \param{sequence}---a \term{sequence}.
    
+
    
+ \param{stream}---an \term{output} \term{stream}.
    
+
    
+ \param{start}, \param{end}---\term{bounding index designators} of
    
+  \param{sequence}.  \Defaults{\param{start} and \param{end}}{\f{0} and \nil}
    
+
    
+ \label Description::
    
+
    
+ \funref{write-sequence} writes the \term{elements} of the subsequence
    
+ of \param{sequence} \term{bounded} by \param{start} and \param{end} to
    
+ \param{stream}.
    
+
    
+ \label Examples::
    
+
    
+ \code
    
+  (write-sequence "bookworms" *standard-output* :end 4)
    
+  \OUT book
    
+  \EV "bookworms"
    
+ \endcode
    
+
    
+ \label Side Effects::
    
+
    
+ Modifies \param{stream}.
    
+
    
+ \label Affected By:\None
    
+
    
+ \label Exceptional Situations::
    
+
    
+ \Lazychecktype{sequence}{a \term{proper sequence}}
    
+ \Shouldchecktype{start}{a non-negative \term{integer}}
    
+ \Shouldchecktype{end}{a non-negative \term{integer} or \nil}
    
+
    
+ Might signal an error \oftype{type-error} if an \term{element} of the
    
+ \term{bounded} \term{sequence} is not a member of the
    
+ \term{stream element type} of the \param{stream}.
    
+
    
+ \label See Also::
    
+
    
+ {\secref\ConstantModification}, \funref{read-sequence}, \funref{write-string},
    
+ \funref{write-line}
    
+
    
+ \label Notes::
    
+
    
+ \funref{write-sequence} is identical in effect to iterating over the indicated
    
+ subsequence and writing one \term{element} at a time to \param{stream}, but
    
+ may be more efficient than the equivalent loop.  An efficient implementation
    
+ is more likely to exist for the case where the \param{sequence} is a
    
+ \term{vector} with the same \term{element type} as the \param{stream}.
    
+
    
+Editorial Impact:
    
+
    
+ Just drop in a couple more dictionary entries.  Might want to add a few more
    
+ cross references.
    
+
    
+Rationale:
    
+
    
+ Addresses the problem description.
    
+
    
+Current Practice:
    
+
    
+ Symbolics Genera provides :string-in and :string-out operations on streams
    
+ that could easily be used to implement these functions.
    
+
    
+ IIM Common Lisp provides functions with similar capabilities but under
    
+ slightly different names.
    
+
    
+Cost to Implementors:
    
+
    
+ Depends on the details of the implementation of the stream operators, but
    
+ probably not very difficult in most cases.  Getting maximum efficiency might
    
+ require some significant work, but some of that work has probably already
    
+ been done to support existing operators or extensions.
    
+
    
+Cost to Users:
    
+
    
+ None.  This is an upwardly compatible addition.
    
+
    
+Performance Impact:
    
+
    
+ Some existing code that uses iteration could be rewritten to use the new
    
+ operators, with a potentially substantial improvement in performance.
    
+
    
+Benefits:
    
+
    
+ Improved performance, and clearer code.
    
+
    
+Aesthetics:
    
+
    
+ The use of these operators is probably clearer than the corresponding
    
+ iteration code, and therefor more aesthetic.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286.htm new file mode 100644 index 00000000..0aa1e2c9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue READ-CASE-SENSITIVITY:READTABLE-KEYWORDS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue READ-CASE-SENSITIVITY:READTABLE-KEYWORDS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue READ-CASE-SENSITIVITY:READTABLE-KEYWORDS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286_w.htm new file mode 100644 index 00000000..437bbacd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss286_w.htm @@ -0,0 +1,349 @@ + + + +CLHS: Issue READ-CASE-SENSITIVITY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue READ-CASE-SENSITIVITY Writeup

    + +
    Status: passed, as amended, Jun 89 X3J13
    
+
    
+Issue:        READ-CASE-SENSITIVITY
    
+Forum:	      Cleanup
    
+References:   CLtL p 334 ff: What the Read Function Accepts,
    
+                especially p 337, step 8, point 1.
    
+              CLtL p 360 ff: The Readtable
    
+              COPY-READTABLE (CLtL, p 361)
    
+              *PRINT-CASE* (CLtL, p 372)
    
+
    
+Category:     ADDITION/CHANGE
    
+
    
+Edit history: Version 1, 15-Feb-89, by Dalton
    
+              Version 2, 23-Mar-89, by Dalton,
    
+                (completely new proposal after comments from
    
+                 Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
    
+              Version 3, 16-Jun-89, by Dalton
    
+                (very minor changes in presentation
    
+                 and some additions to the discussion)
    
+              Version 4, 22-Jun-89, by Dalton
    
+                (removal of the FUNCTION proposal and a different
    
+                 specification for :INVERT after discussion with Moon)
    
+              Version 5, 23-Jun-89, by Dalton
    
+                (minor revisions in presentation and better test case,
    
+                 as suggested by Pitman; also fixed some errors)
    
+              Version 6, 24-Jun-89, by Dalton (small correction)
    
+	      Version 7, 2-Jul-89, by Masinter (as amended, Jun89X3J13)
    
+
    
+Problem Description:
    
+
    
+  The Common Lisp reader always converts unescaped constituent
    
+  characters to upper case.  (See CLtL, p 337, step 8, point 1.)
    
+  This behavior is not always desirable.
    
+
    
+  1.  Lisp applications often use the Lisp reader to read their data.
    
+  This is often significantly easier than writing input routines
    
+  from scratch, especially if the input can be structured as lists.
    
+  However, certain applications want to make use of case distinctions,
    
+  and Common Lisp makes this unreasonably difficult.  (You must define
    
+  every letter as a read macro and have the macro function read the
    
+  rest of the symbol, or else you must write a reader from scratch.)
    
+
    
+  2.  Some programming languages distinguish between upper and lower
    
+  case in identifiers, and useful conventions are often built around
    
+  such distinctions.  For example, in C, constants are often written
    
+  in upper case and variables in lower.  In Mesa(?) and Smalltalk(?),
    
+  a capital letter is used to indicate the beginning of a new word
    
+  in identifiers made up of several words.  In Edinburgh Prolog,
    
+  variables begin with upper-case letters and constant symbols do
    
+  not.  The case-insensitivity of the Common Lisp reader makes
    
+  it difficult to use conventions of this sort.
    
+
    
+Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
    
+
    
+  Define a new settable function, (READTABLE-CASE <readtable>) to
    
+  control the reader's interpretation of case.  The following values
    
+  may be given: :UPCASE, :DOWNCASE, :PRESERVE, and :INVERT.
    
+
    
+    When the value is :UPCASE, unescaped constituent characters
    
+    are converted to upper-case, as specified by CLtL on page 337.
    
+
    
+    When the value is :DOWNCASE, unescaped constituent characters
    
+    are converted to lower-case.
    
+
    
+    When the value is :PRESERVE, the case of all characters remains
    
+    unchanged.
    
+
    
+    When the value is :INVERT, then if all of the unescaped letters
    
+    in the extended token are of the same case, those (unescaped)
    
+    letters are converted to the opposite case.
    
+
    
+  COPY-READTABLE copies the setting of READTABLE-CASE.  The value of
    
+  READTABLE-CASE for the standard readtable is :UPCASE.
    
+
    
+  The READTABLE-CASE of *READTABLE* also has significance when printing
    
+  The case in which letters are printed, when vertical-bar syntax is not
    
+  used, is determined as follows:
    
+
    
+    When READTABLE-CASE is :UPCASE, upper-case letters are printed
    
+    in the case specified by *PRINT-CASE*, and lower-case letters
    
+    are printed in their own case.
    
+
    
+    When READTABLE-CASE is :DOWNCASE, lower-case letters are printed
    
+    in the case specified by *PRINT-CASE*, and upper-case letters
    
+    are printed in their own case.
    
+
    
+    When READTABLE-CASE is :PRESERVE, all letters are printed in their
    
+    own case.
    
+
    
+    When READTABLE-CASE is :INVERT, the case of all letters in single-
    
+    case symbol names is inverted.  Mixed-case symbol names are printed
    
+    as-is.
    
+
    
+  The rules for escaping letters in symbol names are also affected by
    
+  the READTABLE-CASE.  If *PRINT-ESCAPE* is true, letters are escaped
    
+  as follows:
    
+
    
+    When READTABLE-CASE is :UPCASE, all lower-case letters must be
    
+    escaped.
    
+
    
+    When READTABLE-CASE is :DOWNCASE, all upper-case letters must be
    
+    escaped.
    
+
    
+    When READTABLE-CASE is :PRESERVE, no letters need be escaped.
    
+
    
+    When READTABLE-CASE is :INVERT, no letters need be escaped.
    
+    
    
+Rationale:
    
+
    
+  There are a number of different ways to achieve case-sensitivity.
    
+  This proposal is fairly simple but provides all of the functionality
    
+  that one could reasonably expect.
    
+
    
+  By using a property of the readtable, we avoid introducing a new
    
+  special variable.  Any code that wishes to control all of the
    
+  reader's parameters already takes *READTABLE* into account.  A new
    
+  special variable would require such code to change.
    
+
    
+  :DOWNCASE is included for symmetry with :UPCASE.  
    
+
    
+  :INVERT is included so that case conventions can be used in Common
    
+  Lisp code without requiring that the names of symbols in the "LISP"
    
+  package be written in upper case.  (Opinions vary as to whether is
    
+  is advisable to use such conventions, but this proposal leaves that
    
+  choice to the user.)
    
+
    
+  :INVERT has an effect only for single-case names so that mixed-
    
+  case names can be interpreted in a more straightforward way.
    
+
    
+  In order to avoid complex interactions between the case setting of
    
+  the readtable and *PRINT-CASE*, this proposal specifies a
    
+  significance for *PRINT-CASE* only when the case setting is :UPCASE
    
+  or :DOWNCASE.  The meaning of *PRINT-CASE* when the readtable
    
+  setting is :DOWNCASE was chosen for its simplicity and for symmetry
    
+  with :UPCASE while still being useful.
    
+
    
+Test Cases:
    
+
    
+  ;;; Test 1 -- reading
    
+
    
+  (defun test1 ()
    
+    (let ((*readtable* (copy-readtable nil)))
    
+      (format t "READTABLE-CASE  Input   Symbol-name~
    
+	       ~%-----------------------------------~
    
+	       ~%")
    
+      (dolist (readtable-case '(:upcase :downcase :preserve :invert))
    
+	(setf (readtable-case *readtable*) readtable-case)
    
+	(dolist (input '("ZEBRA" "Zebra" "zebra"))
    
+	  (format t "~&:~A~16T~A~24T~A"
    
+		  (string-upcase readtable-case)
    
+		  input
    
+		  (symbol-name (read-from-string input)))))))
    
+
    
+  The output from (TEST1) should be as follows:
    
+
    
+    READTABLE-CASE  Input   Symbol-name
    
+    -----------------------------------
    
+    :UPCASE         ZEBRA   ZEBRA
    
+    :UPCASE         Zebra   ZEBRA
    
+    :UPCASE         zebra   ZEBRA
    
+    :DOWNCASE       ZEBRA   zebra
    
+    :DOWNCASE       Zebra   zebra
    
+    :DOWNCASE       zebra   zebra
    
+    :PRESERVE       ZEBRA   ZEBRA
    
+    :PRESERVE       Zebra   Zebra
    
+    :PRESERVE       zebra   zebra
    
+    :INVERT         ZEBRA   zebra
    
+    :INVERT         Zebra   Zebra
    
+    :INVERT         zebra   ZEBRA
    
+
    
+  ;;; Test 2 -- printing
    
+
    
+  (defun test2 ()
    
+    (let ((*readtable* (copy-readtable nil))
    
+	  (*print-case* *print-case*))
    
+      (format t "READTABLE-CASE *PRINT-CASE*  Symbol-name  Output~
    
+	       ~%--------------------------------------------------~
    
+	       ~%")
    
+      (dolist (readtable-case '(:upcase :downcase :preserve :invert))
    
+	(setf (readtable-case *readtable*) readtable-case)
    
+	(dolist (print-case '(:upcase :downcase :capitalize))
    
+	  (dolist (symbol '(|ZEBRA| |Zebra| |zebra|))
    
+	    (setq *print-case* print-case)
    
+	    (format t "~&:~A~15T:~A~29T~A~42T~A"
    
+		    (string-upcase readtable-case)
    
+		    (string-upcase print-case)
    
+		    (symbol-name symbol)
    
+		    (prin1-to-string symbol)))))))
    
+
    
+  The output from (TEST2) should be as follows:
    
+
    
+    READTABLE-CASE *PRINT-CASE*  Symbol-name  Output
    
+    --------------------------------------------------
    
+    :UPCASE        :UPCASE       ZEBRA        ZEBRA
    
+    :UPCASE        :UPCASE       Zebra        |Zebra|
    
+    :UPCASE        :UPCASE       zebra        |zebra|
    
+    :UPCASE        :DOWNCASE     ZEBRA        zebra
    
+    :UPCASE        :DOWNCASE     Zebra        |Zebra|
    
+    :UPCASE        :DOWNCASE     zebra        |zebra|
    
+    :UPCASE        :CAPITALIZE   ZEBRA        Zebra
    
+    :UPCASE        :CAPITALIZE   Zebra        |Zebra|
    
+    :UPCASE        :CAPITALIZE   zebra        |zebra|
    
+    :DOWNCASE      :UPCASE       ZEBRA        |ZEBRA|
    
+    :DOWNCASE      :UPCASE       Zebra        |Zebra|
    
+    :DOWNCASE      :UPCASE       zebra        ZEBRA
    
+    :DOWNCASE      :DOWNCASE     ZEBRA        |ZEBRA|
    
+    :DOWNCASE      :DOWNCASE     Zebra        |Zebra|
    
+    :DOWNCASE      :DOWNCASE     zebra        zebra
    
+    :DOWNCASE      :CAPITALIZE   ZEBRA        |ZEBRA|
    
+    :DOWNCASE      :CAPITALIZE   Zebra        |Zebra|
    
+    :DOWNCASE      :CAPITALIZE   zebra        Zebra
    
+    :PRESERVE      :UPCASE       ZEBRA        ZEBRA
    
+    :PRESERVE      :UPCASE       Zebra        Zebra
    
+    :PRESERVE      :UPCASE       zebra        zebra
    
+    :PRESERVE      :DOWNCASE     ZEBRA        ZEBRA
    
+    :PRESERVE      :DOWNCASE     Zebra        Zebra
    
+    :PRESERVE      :DOWNCASE     zebra        zebra
    
+    :PRESERVE      :CAPITALIZE   ZEBRA        ZEBRA
    
+    :PRESERVE      :CAPITALIZE   Zebra        Zebra
    
+    :PRESERVE      :CAPITALIZE   zebra        zebra
    
+    :INVERT        :UPCASE       ZEBRA        zebra
    
+    :INVERT        :UPCASE       Zebra        Zebra
    
+    :INVERT        :UPCASE       zebra        ZEBRA
    
+    :INVERT        :DOWNCASE     ZEBRA        zebra
    
+    :INVERT        :DOWNCASE     Zebra        Zebra
    
+    :INVERT        :DOWNCASE     zebra        ZEBRA
    
+    :INVERT        :CAPITALIZE   ZEBRA        zebra
    
+    :INVERT        :CAPITALIZE   Zebra        Zebra
    
+    :INVERT        :CAPITALIZE   zebra        ZEBRA
    
+
    
+Current Practice:
    
+
    
+  While there may not be any current implementation that supports
    
+  exactly this proposal, several implementations provide some means
    
+  for changing case sensitivity.
    
+
    
+  Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
    
+  the "preferred case" (the case of characters in the print names of
    
+  standard symbols such as CAR) and whether or not the reader is case-
    
+  sensitive.
    
+
    
+  In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
    
+  can be used to make the translation of a letter be that same letter,
    
+  thus achieving case-sensitivity.
    
+
    
+  Xerox Medley has a function for setting a readtable flag that
    
+  determines case sensitivity.
    
+
    
+Cost to Implementors:
    
+
    
+  Fairly small.  The reader will be slightly slower and readtables
    
+  will be slightly more complex.
    
+
    
+Cost to Users:
    
+
    
+  Slight.  Programmers must already take into account the possibility
    
+  that *READTABLE* will be a non-standard readtable.  Case-sensitivity
    
+  is no worse than character macros in this respect.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Applications that want to read mixed-case expressions will not
    
+  be able to use the Common Lisp reader to do so (except, perhaps,
    
+  by tortuous use of read macros).
    
+
    
+  Programming styles that rely on case distinctions (without escape
    
+  characters) will effectively be impossible in Common Lisp.
    
+
    
+Benefits:
    
+
    
+  Applications will be able to read mixed-case expressions.
    
+
    
+  Programmers will be able to make use of case distinctions.
    
+
    
+Aesthetics:
    
+
    
+  For the proposal: 
    
+
    
+    The language will have greater symmetry, because it will be
    
+    possible to control the treatment of case on both input and output
    
+    instead of only on output (as is now the case).
    
+
    
+    The language will look less old-fashioned.
    
+
    
+  Against the proposal:
    
+  
    
+    It is, perhaps, inconsistent to control case-sensitivity by a
    
+    readtable operation when other aspects of the reader, such as the
    
+    input base and the default float format (not to mention the
    
+    package), are controlled by special variables.  However, it can be
    
+    argued that character-level syntax is determined chiefly by the
    
+    readtable.  Case-sensitivity can be seen as analogous to character
    
+    macros in this respect.
    
+
    
+Discussion:
    
+
    
+  Dalton supports the proposal READTABLE-KEYWORDS.
    
+
    
+  Version 1 of the proposal suggested a new global variable rather
    
+  than a property of the readtable.  Pitman was strongly opposed to
    
+  that proposal and gave convincing arguments that it should be
    
+  dropped.  Gray suggested that the readtable property should be a
    
+  function.  Versions 2 and 3 included a FUNCTION proposal as well
    
+  as the KEYWORD one.  But at the March 1989 X3J13 meeting it was
    
+  felt that there should be only a single proposal and, since
    
+  opinion seemed to favor the KEYWORD proposal, the FUNCTION
    
+  proposal was dropped.
    
+
    
+  In earlier versions of the proposal, :INVERT worked a letter at
    
+  a time (rather than operating on extended tokens) so that, for
    
+  example, Zebra read as zEBRA.  However, the purpose of :INVERT
    
+  is to let the programmer get the standard internal case (ie,
    
+  upper case) by writing lower case rather than upper.  This
    
+  matters when referring to single-case symbols such as those
    
+  in the LISP package.  But, in most cases, mixed-case identifiers
    
+  will already have the right case.  For example, one would use
    
+  TheNextWindow to get TheNextWindow, not tHEnEXTwINDOW.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287.htm new file mode 100644 index 00000000..5ccd8faa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287_w.htm new file mode 100644 index 00000000..467a33b4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss287_w.htm @@ -0,0 +1,201 @@ + + + +CLHS: Issue READ-MODIFY-WRITE-EVALUATION-ORDER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue READ-MODIFY-WRITE-EVALUATION-ORDER Writeup

    + +
    Issue:            READ-MODIFY-WRITE-EVALUATION-ORDER
    
+References:       DEFINE-MODIFY-MACRO
    
+                  DECF, INCF, POP, PUSH, PUSHNEW, REMF
    
+Related issues:   Issue SETF-SUB-METHODS
    
+                  Issue PUSH-EVALUATION-ORDER
    
+Category:         Clarification, change
    
+Edit history:     v1, 17 Dec 1990, Sandra Loosemore
    
+                  v2, 19 Feb 1991, Sandra Loosemore
    
+
    
+
    
+Problem description:
    
+
    
+Proposal SETF-SUB-METHODS:DELAYED-ACCESS-STORES states that "reading
    
+the value" of a generalized variable reference is not part of the
    
+series of evaluations that must be done in left-to-right order.  That
    
+issue only addressed the problem in the context of SETF places such
    
+as GETF, LDB, and MASK-FIELD whose SETF methods include an implicit
    
+read-modify-write operation on a nested place form.
    
+
    
+There is a similar order-of-evaluation issue for explicit
    
+read-modify-write macros such as INCF and those defined with
    
+DEFINE-MODIFY-MACRO: if the access to the place is performed before
    
+other arguments to the macro are evaluated, any side-effects of those
    
+evaluations on the value of the place are lost.
    
+
    
+In the case of SETF of GETF and friends, issue SETF-SUB-METHODS placed
    
+constraints on the order of evaluation of subforms within the values
    
+returned by GET-SETF-METHOD.  In the case of INCF and friends, the
    
+question is the order of evaluation in the expansion of the
    
+read-modify-write macro.
    
+
    
+
    
+Proposal READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES:
    
+
    
+Clarify that the exception of "reading the value" of a generalized
    
+variable reference from the series of evaluations that must be done in
    
+left-to-right order applies to the read-modify-write macros DECF,
    
+INCF, POP, PUSH, PUSHNEW, REMF, SHIFTF and all macros defined with
    
+DEFINE-MODIFY-MACRO.
    
+
    
+Specifically:
    
+
    
+  For DECF, INCF, POP, REMF, and all macros defined with
    
+  DEFINE-MODIFY-MACRO:
    
+
    
+  These macros are of the form
    
+    (<operator> <place> . <other-arguments>)
    
+  The order of evaluation should be:
    
+    - all subforms of the <place>, in the order specified by the second
    
+      value of GET-SETF-METHOD for that <place>
    
+    - the <other-arguments>, in left-to-right order
    
+    - the access to <place>
    
+    - the computation of the new value to be stored
    
+    - the store into <place>
    
+
    
+
    
+  For PUSH and PUSHNEW:
    
+
    
+  These macros are of the form
    
+    (<operator> <object> <place> . <other-arguments>) 
    
+  The order of evaluation should be:
    
+    - the <object>
    
+    - all subforms of the <place>, in the order specified by the second
    
+      value of GET-SETF-METHOD for that <place>
    
+    - the <other-arguments>, in left-to-right order
    
+    - the access to <place>
    
+    - the computation of the new value to be stored
    
+    - the store into <place>
    
+
    
+In other words, the subforms of the <place> argument and any other
    
+argument subforms should be evaluated in left-to-right order, but the
    
+actual access of the <place> happens after all of the subform evaluations
    
+and just before the computation and store of the new value.
    
+
    
+
    
+Examples:
    
+
    
+These two examples parallel examples 6 and 7 (respectively) from
    
+issue SETF-SUB-METHODS.
    
+
    
+1. (setq r (list 'a 1 'b 2 'c 3))
    
+   (setf (getf r 'b) (progn (setq r nil) 6))
    
+   r => (b 6)
    
+
    
+   (setq r 5)
    
+   (incf r (progn (setq r 0) 1))
    
+   r => 1
    
+
    
+   In both cases, the place form that is the target of the read-modify-write
    
+   operation is the variable R.  The access of this place is delayed until
    
+   the other subforms have been evaluated, so the value of R that is
    
+   read as part of the read-modify-write operation reflects the SETQ.
    
+
    
+2. (setq s (setq r (list (list 'a 1 'b 2 'c 3))))
    
+   (setf (getf (car r) 'b)
    
+         (progn (setq r nil) 6))
    
+   r => nil
    
+   s => ((A 1 B 6 C 3))
    
+
    
+   (setq s (setq r (list 5)))
    
+   (incf (car r) (progn (setq r (list 0)) 1))
    
+   r => (0)
    
+   s => (6)
    
+
    
+   In both cases, the nested place form is the value of (CAR R).  Note that
    
+   the SETQ does not affect the read-modify-write operation because the
    
+   value of R has already been saved in a temporary variable as part of
    
+   evaluating the subforms of the nested place form.  The read-modify-write
    
+   operation applies to the CAR of this value.
    
+
    
+
    
+Rationale:
    
+
    
+This makes the rules for conceptual "read-modify-write" operations
    
+consistent, regardless of whether or not the operation is specified by
    
+a special-case SETF place (such as GETF) or a macro such as those
    
+defined by DEFINE-MODIFY-MACRO.
    
+
    
+
    
+Current Practice:
    
+
    
+Neither Lucid CL nor Allegro CL implement this proposal.  In both
    
+implementations, the access to the place subform apparently happens in
    
+its normal left-to-right order.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Small.
    
+
    
+
    
+Cost to Users:
    
+
    
+Hard to say.  Some programs that depend on the strict left-to-right
    
+order of evaluation now supported in some implementations may break,
    
+but probably such programs are no more common than those that were
    
+broken by the adoption of proposal SETF-SUB-METHODS:DELAYED-ACCESS-STORES.
    
+
    
+
    
+Cost of non-adoption:
    
+
    
+Read-modify-write macros such as INCF and macros defined with
    
+DEFINE-MODIFY-MACRO continue to have the same problems with losing
    
+multiple updates to the place that were solved for SETF of GETF by
    
+adoption of SETF-SUB-METHODS:DELAYED-ACCESS-STORES.
    
+
    
+
    
+Performance impact:
    
+
    
+Probably not applicable.
    
+
    
+
    
+Benefits:
    
+
    
+The cost of non-adoption is avoided.  
    
+
    
+
    
+Esthetics:
    
+
    
+Specifying the same order of evaluation rules for all conceptual 
    
+read-modify-write operations is better than arbitrarily having a 
    
+difference between those defined as special-case SETF places (like GETF)
    
+and those defined as macros.
    
+
    
+
    
+Discussion:
    
+
    
+This proposal does not change the order of evaluation for the macros
    
+ROTATEF, SHIFTF, ASSERT, CHECK-TYPE, CTYPECASE, and CCASE.  These
    
+macros all have their own peculiar order-of-evaluation rules already.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288.htm new file mode 100644 index 00000000..9fcc2d52 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue READ-SUPPRESS-CONFUSING:GENERALIZE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue READ-SUPPRESS-CONFUSING:GENERALIZE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue READ-SUPPRESS-CONFUSING:GENERALIZE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288_w.htm new file mode 100644 index 00000000..15859bf5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss288_w.htm @@ -0,0 +1,188 @@ + + + +CLHS: Issue READ-SUPPRESS-CONFUSING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue READ-SUPPRESS-CONFUSING Writeup

    + +
    Forum:		Public Review
    
+Issue:		READ-SUPPRESS-CONFUSING
    
+References:	Margolin's PR comment #2 (X3J13/92-1402)
    
+		Margolin's PR comment #18 (X3J13/92-1418)
    
+		Flanagan's PR comment #7 (X3J13/92-1907)
    
+		Philpot's PR comment #1 (X3J13/92-2901)
    
+		Barrett's PR comment #9 (X3J13/92-3109), part 2
    
+		*READ-SUPPRESS* (X3J13/92-102 pp.23-21..22)
    
+		Sharpsign P (X3J13/92-102 sec.2.4.8.14)
    
+		Sharpsign C (X3J13/92-102 sec.2.4.8.11)
    
+Category:	CHANGE
    
+Edit history:	5 Jan 1993, Version 1 by Margolin
    
+                22 May 1993, Version 2 by Loosemore (delete bogus reference
    
+                  to ":" and "@" in dispatching macro syntax)
    
+Status:		Proposal GENERALIZE passed 9-2 on letter ballot 93-302
    
+
    
+
    
+Problem description:
    
+
    
+  The description of *READ-SUPPRESS* is confusing and incomplete.  By
    
+  specifying the behavior of particular read syntaxes rather than a simple,
    
+  general strategy, some syntaxes (#C, #P, and#') have unintentionally been
    
+  omitted.  And the wording of the description of the behavior of #(...) is
    
+  unclear as to whether the vector syntax is parsed and ignored or a vector
    
+  is actually constructed (there's a subtle difference between the CLtL and
    
+  dpANS wording, due to the lack of a pair of parentheses in the dpANS).
    
+
    
+  A strict reading of the current description of *READ-SUPPRESS* implies
    
+  that the reader must still construct objects in response to these
    
+  syntaxes (as well as user-defined reader macros that don't check the
    
+  variable).  This is pretty wasteful considering that *READ-SUPPRESS*
    
+  exists primarily to support #+ and #-, which discard what they read with
    
+  *READ-SUPPRESS* true anyway.
    
+
    
+  In the case of #P, the lack of specification of its *READ-SUPPRESS*
    
+  behavior is a real annoyance, because some implementations have extended
    
+  it to allow non-strings to follow it.  Users expect to be able to hide
    
+  such extensions using #+, but this isn't valid.
    
+
    
+Proposal (READ-SUPPRESS-CONFUSING:GENERALIZE):
    
+
    
+  1) Replace the portion of the Description of *READ-SUPPRESS* from
    
+  "Extended tokens" through the entry for "#A, #S, #:" with:
    
+
    
+      When *READ-SUPPRESS* is true, READ, READ-PRESERVING-WHITESPACE,
    
+      READ-DELIMITED-LIST, and READ-FROM-STRING all return a first value of
    
+      NIL when they complete successfully; however, they continue to parse
    
+      the representation of an object in the normal way, in order to skip
    
+      over the object, and continue to indicate end-of-file in the normal
    
+      way.  Except as noted below, any standard macro character (including
    
+      dispatching macro sub-characters) that is defined to read a following
    
+      object or token will do so, but not signal an error if the object
    
+      read is not of an appropriate type or syntax.  Standard syntaxes and
    
+      macro characters will not construct any new objects (e.g. when
    
+      reading the representation of a symbol, no symbol will be constructed
    
+      or interned).
    
+
    
+      Dispatching macro characters (including #)
    
+
    
+	  Dispatching macro characters continue to parse an infix numerical
    
+	  argument, and invoke the
    
+	  dispatch function.  The standard # dispatching macro characters
    
+	  do not enforce any constraints on the value or existence of the
    
+	  numerical argument.
    
+
    
+  2) Create a Notes section that recommends that user-defined and
    
+  implementation-defined macro characters behave analogously to the
    
+  standard macro character, i.e. when *READ-SUPPRESS* is true they should
    
+  ignore type errors when reading a following object and dispatching macro
    
+  characters should allow NIL as an infix parameter.
    
+
    
+  3) Change the specifications of #C and #P to specify that they are
    
+  followed by the representation of an object.  Then specify how they are
    
+  interpreted when those objects are a list of two real numbers (for #C) or
    
+  a string (for #P).
    
+
    
+Examples:
    
+
    
+  (let ((*read-suppress* t))
    
+    (dolist (string '("#(foo bar baz)" "#P(:type :lisp)" "#c1.2" "foo"))
    
+      (unless 
    
+        (ignore-errors
    
+          (progn (print (read-from-string string))
    
+                 t))
    
+        (print 'error))))
    
+  could print
    
+  #(NIL NIL NIL)
    
+  ERROR
    
+  ERROR
    
+
    
+Test Cases:
    
+
    
+  (let ((*read-suppress* t))
    
+    (mapcar #'read-from-string
    
+            '("#(foo bar baz)" "#P(:type :lisp)" "#c1.2")))
    
+  -> (NIL NIL NIL)
    
+
    
+Rationale:
    
+
    
+  1) Specifies a general behavior for *READ-SUPPRESS* that is applicable to
    
+  all reader syntaxes that are described in terms of the representations of
    
+  objects.
    
+
    
+  2) Encourages implementors and users to extrapolate from this standard
    
+  behavior.
    
+
    
+  3) Specifies #P and #C in such a way that change 1 applies.
    
+
    
+Current practice:
    
+
    
+  For the Example form, Genera 8.1 prints NIL, NIL, NIL (it seems to
    
+  implement the proposal); Lucid 4.1 and CMU CL 16d print NIL, ERROR, NIL;
    
+  WCL 2.1 prints #(NIL NIL NIL), ERROR, ERROR.
    
+
    
+Cost to Implementors:
    
+
    
+  Should be minor.
    
+
    
+Cost to Users:
    
+
    
+  When *READ-SUPPRESS* is bound via #+ or #-, the change should be upward
    
+  compatible, since any objects constructed by the reader will not be
    
+  visible.  Direct users of *READ-SUPPRESS* may notice the difference, but
    
+  it seems unlikely that anyone is depending on any of the current
    
+  behaviors.
    
+
    
+Cost of non-adoption:
    
+
    
+  Users will have to avoid using some implementation-dependent syntaxes in
    
+  #P macros.
    
+
    
+Performance impact:
    
+
    
+  Minor.
    
+
    
+Benefits:
    
+
    
+  More ability to include implementation-dependent syntax extensions in
    
+  portable source code.
    
+
    
+Esthetics:
    
+
    
+  A general description of behavior is better than lots of specific cases.
    
+
    
+Editorial Impact:
    
+
    
+  Minor.  The changes are confined to the three sections mentioned above.
    
+
    
+Discussion:
    
+
    
+  Barmar originally wanted to specify that standard dispatching macros
    
+  would parse the numerical argument but ignore it (always passing NIL to
    
+  the dispatch function).  Flanagan convinced him to leave that part as it
    
+  was originally (the numeric argument is parsed but standard dispatch
    
+  functions don't enforce restrictions on it).  It doesn't seem to be a big
    
+  deal either way.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289.htm new file mode 100644 index 00000000..8af2db4f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue READER-ERROR:NEW-TYPE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue READER-ERROR:NEW-TYPE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue READER-ERROR:NEW-TYPE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289_w.htm new file mode 100644 index 00000000..873ab57d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss289_w.htm @@ -0,0 +1,128 @@ + + + +CLHS: Issue READER-ERROR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue READER-ERROR Writeup

    + +
    Forum:		Cleanup
    
+Issue:		READER-ERROR
    
+References:	Chapter 3, "Syntax"
    
+		Section 2.2, "Types"
    
+Category:	ADDITION, CHANGE
    
+Edit History:   V1, 23 Oct 1989, Sandra Loosemore
    
+		V2, 02 Nov 1989, Sandra Loosemore
    
+			(change supertypes, update discussion)
    
+                V3, 10 Jul 1990, David Moon (include amendment from meeting)
    
+
    
+
    
+Problem Description:
    
+
    
+Chapter 3 of the current draft is not consistent about the types of
    
+errors that must be signalled by the reader.  In most places where it
    
+specifies that an error is to be signalled, it does not indicate a
    
+particular type of error, but in at least one situation it requires
    
+the error to be of type PROGRAM-ERROR, and in other cases it requires
    
+the error to be of type ERROR.
    
+
    
+None of the ERROR subtypes described in section 2.2 really seem
    
+appropriate for syntactic errors detected by the reader.  In
    
+particular, the description of PROGRAM-ERROR implies that its purpose
    
+is for errors relating to program syntax which are detectable during
    
+evaluation or compilation rather than read-time errors.  It seems
    
+especially inappropriate to use PROGRAM-ERROR for this purpose since
    
+the reader can be used to read things other than programs.  Likewise,
    
+STREAM-ERROR appears to have been intended to be used for errors
    
+relating to character-level transactions on the stream rather than
    
+lexical analysis or parsing.
    
+
    
+
    
+Proposal (READER-ERROR:NEW-TYPE):
    
+
    
+Add a new type specifier, PARSE-ERROR.  This is a subtype of the
    
+types STREAM-ERROR, ERROR, SERIOUS-CONDITION, CONDITION, and T.  The
    
+type PARSE-ERROR consists of serious conditions that relate to
    
+lexical analysis (the building and interpretation of tokens) and
    
+parsing (errors in reader macro syntax) by the Lisp reader.
    
+
    
+Since PARSE-ERROR is a subtype of STREAM-ERROR, objects of this type
    
+inherit a STREAM slot, which can be accessed using the function
    
+STREAM-ERROR-STREAM.
    
+
    
+Change the discussion in chapter 3 to specify that the type of errors
    
+signalled by the reader is PARSE-ERROR.  There are numerous places
    
+that would be affected.
    
+
    
+
    
+Rationale:
    
+
    
+The general policy that has been followed in other areas of the
    
+language where errors must, should, or might be signalled is to
    
+specify a particular subtype of ERROR which covers that class of
    
+errors.  Doing the same for reader errors would be consistent with the
    
+overall policy, but none of the existing error types seem appropriate
    
+for reader-related errors.
    
+
    
+
    
+Current Practice:
    
+
    
+LispWorks (from Harlequin) reportedly already uses such a condition.
    
+
    
+
    
+Cost to implementors:
    
+
    
+Trivial.
    
+
    
+
    
+Cost to users:
    
+
    
+Probably no user programs rely on the reader signalling any particular
    
+type of error yet.
    
+
    
+
    
+Benefits:
    
+
    
+Increased consistency in the language design.
    
+Ability to set up handlers specifically for reader errors.
    
+
    
+
    
+Discussion:
    
+
    
+Pitman says:
    
+  Our later comments will show that i would like this condition to be
    
+  called PARSE-ERROR so that it doesn't seem to be useful only for 
    
+  READ-related problems but can in fact be used for other parser-style
    
+  applications (e.g., a FORTRAN parser, a user-written English-language
    
+  interface, etc.).
    
+
    
+The initial version of this proposal specified that PARSE-ERROR was
    
+disjoint from (rather than a subtype of) STREAM-ERROR.  This was
    
+changed because there was a suggestion that some conditions should be
    
+both a PARSE-ERROR and a STREAM-ERROR.  Making it a subtype also allows
    
+it to inherit the STREAM slot and the STREAM-ERROR-STREAM accessor.
    
+
    
+Prior to version 3 the condition PARSE-ERROR was named READER-ERROR.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290.htm new file mode 100644 index 00000000..54b15eda --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290.htm @@ -0,0 +1,62 @@ + + + +CLHS: Issue REAL-NUMBER-TYPE:X3J13-MAR-89 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REAL-NUMBER-TYPE:X3J13-MAR-89 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue REAL-NUMBER-TYPE:X3J13-MAR-89:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290_w.htm new file mode 100644 index 00000000..ea1d6874 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss290_w.htm @@ -0,0 +1,206 @@ + + + +CLHS: Issue REAL-NUMBER-TYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REAL-NUMBER-TYPE Writeup

    + +
    Issue:        REAL-NUMBER-TYPE
    
+Forum:	      CLEANUP
    
+References:   Table 4-1.
    
+Category:     ADDITION
    
+Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
    
+                         and John Aspinall
    
+              08-JAN-89, Version 2 by Bob Cassels -- incorporate
    
+                         Masinter's suggestion and make REAL a CLOS class
    
+              13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
    
+                         suggestions clarifying the relationship between CL
    
+                         numeric type names and mathematical names
    
+	      05-APR-89, Version 4 by Pitman (changes per X3J13)
    
+Status:	      Accepted v3 Mar-89 by X3J13 (on a 12-3 vote) with 
    
+	      amendments. The proposal as amended is v4.
    
+
    
+Problem Description:
    
+
    
+  There is no standard type specifier symbol for the CL type
    
+  '(OR RATIONAL FLOAT). 
    
+
    
+Proposal (REAL-NUMBER-TYPE:X3J13-MAR-89):
    
+
    
+  Make REAL be a CL data type:
    
+
    
+  p.13 "Numbers"
    
+
    
+    Add:     The NUMBER data type encompasses all of these kinds of
    
+             numbers.  For convenience, there are names for some
    
+             subclasses of numbers.  @i[Integers] and @i[ratios] are of
    
+             type RATIONAL.  @i[Rational numbers] and @[floating-point
    
+             numbers] are of type REAL.  @i[Real numbers] and @i[complex
    
+             numbers] are of type NUMBER.
    
+
    
+	     Although the names of these types were chosen with the
    
+	     terminology of mathematics in mind, the correspondences
    
+	     are not always exact.  Integers and ratios model the
    
+	     corresponding mathematical concepts directly.  Numbers
    
+	     of the FLOAT type may be used to approximate real
    
+	     numbers, both rational and irrational.  The REAL type
    
+	     includes all Common Lisp numbers which represent
    
+	     mathematical real numbers, though there are
    
+	     mathematical real numbers (irrational numbers)
    
+	     which do not have an exact Common Lisp representation.
    
+	     Only REAL numbers may be ordered using the <, >, <=,
    
+	     and >= functions.
    
+
    
+             Compatibility note:  The Fortran standard defines the term
    
+             "real datum" to mean "a processor approximation to the value
    
+             of a real number."  In practice the Fortran "basic real" type
    
+             is the floating-point data type Common Lisp calls
    
+             SINGLE-FLOAT.  The Fortran "double precision" type is
    
+             Common Lisp's DOUBLE-FLOAT.  The Pascal "real" data type is
    
+             an "implementation-defined subset of the real numbers."  In
    
+             practice this is usually a floating-point type, often what
    
+             Common Lisp calls DOUBLE-FLOAT.
    
+
    
+             A translation of an algorithm written in Fortran or Pascal
    
+             which uses "real" data usually will use some appropriate
    
+             precision of Common Lisp's FLOAT type.  Some algorithms may
    
+             gain accuracy and/or flexibility by using Common Lisp's
    
+             RATIONAL or REAL types instead.
    
+
    
+  p.33 "Overlap, Inclusion, and Disjointness of Types":
    
+
    
+    Remove:  The types RATIONAL, FLOAT, and COMPLEX are pairwise
    
+             disjoint subtypes of NUMBER.
    
+
    
+             Rationale: It might be thought that INTEGER and RATIO ...
    
+
    
+             Rationale: It might be thought that FIXNUM and BIGNUM ...
    
+
    
+    Add:     The types RATIONAL and FLOAT are pairwise disjoint subtypes
    
+             of REAL.
    
+
    
+             The types REAL and COMPLEX are pairwise disjoint subtypes
    
+             of NUMBER.
    
+
    
+             Rationale: It might be thought that FIXNUM and BIGNUM should 
    
+             form an exhaustive partition of the type INTEGER, that INTEGER
    
+             and RATIO should form an exhaustive partition of RATIONAL,
    
+             that RATIONAL and FLOAT should form an exhaustive partition of 
    
+             REAL, and that REAL and COMPLEX should form an exhaustive
    
+             partition of NUMBER.  These are all purposely avoided in order 
    
+             to permit compatible experimentation with extensions to the
    
+             Common Lisp number system, such as the idea of adding explicit 
    
+             representations of infinity or of positive and negative infinity.
    
+
    
+   p.43 Table 4-1 "Standard Type Specifier Symbols"
    
+
    
+    Add:     REAL
    
+
    
+   p.49 "Type Specifiers that Abbreviate"
    
+
    
+     Add:    (REAL low high)
    
+             Denotes the set of real numbers between low and high.  ...
    
+             [As with RATIONAL and FLOAT.]
    
+
    
+
    
+  Make REAL a built-in CLOS class.
    
+
    
+  Add a specific data type predicate REALP which tests for membership in
    
+  this type.  [By analogy with NUMBERP.]
    
+
    
+Test Case:
    
+
    
+  If a programmer wishes to test for "a number between 1 and 10", the
    
+  only current CL types would be '(or (rational 1 10) (float 1 10)) or
    
+  something like '(and numberp (not complexp) (satisfies range-1-10))
    
+  with (defun range-1-10 (real) (<= 1 real 10)).  Both of these are
    
+  likely less efficient, and certainly less expressive than '(real 1 10).
    
+
    
+Rationale:
    
+
    
+  Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
    
+  This class is important because it is all the numbers which can be
    
+  ordered.
    
+
    
+  Throughout the "Numbers" chapter, the phrase "non-complex number" is
    
+  used.
    
+  MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
    
+  CIS p. 207 "The argument ... may be any non-complex number."
    
+
    
+Current Practice:
    
+
    
+  Probably nobody does this.
    
+  
    
+Cost to Implementors:
    
+
    
+  Some work is necessary to add this name.  But since the underlying
    
+  type already exists the amount of work should be minimal.
    
+  
    
+Cost to Users:
    
+
    
+  Since this is an upward-compatible extension, it may be ignored by
    
+  users.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Occasional inconvenience and/or inefficiency.
    
+
    
+Benefits:
    
+
    
+  Mathematical clarity.
    
+
    
+  Ability to do CLOS method dispatch on the type.
    
+
    
+Aesthetics:
    
+
    
+  As mentioned under "rationale," this would be a more concise way to
    
+  express a common programming idiom.
    
+
    
+Discussion:
    
+
    
+  The name "non-complex number" is incorrect because future
    
+  implementations may wish to include numerical types which are neither
    
+  complex nor real.  [e.g. pure imaginary numbers or quaternions]
    
+  
    
+  The name "scalar" is incorrect because the mathematical concept of
    
+  scalar may indeed include complex numbers.
    
+
    
+  Fortran and Pascal use the name "real" to mean what CL calls
    
+  SINGLE-FLOAT.  That should cause no significant problem, since a Lisp
    
+  program written using the type REAL will do mathematically what the
    
+  equivalent Fortran program would do.  This is because Fortran's "real"
    
+  data-type is a subtype of the CL REAL type.  The only differences
    
+  might be that the Lisp program could be less efficient and/or more
    
+  accurate.
    
+
    
+  A survey of several Fortran and Pascal books shows that the distinction
    
+  between INTEGER and REAL is that REAL numbers may have fractional
    
+  parts, while INTEGERs do not.  Later discussions explain that REALs
    
+  cover a greater range.  Much later discussions cover precision
    
+  considerations, over/underflow, etc.  So the average Fortran or Pascal
    
+  programmer should be completely comfortable with the proposed Lisp
    
+  concept of REAL.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291.htm new file mode 100644 index 00000000..fc7dd12d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291_w.htm new file mode 100644 index 00000000..1ad873fa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss291_w.htm @@ -0,0 +1,191 @@ + + + +CLHS: Issue RECURSIVE-DEFTYPE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue RECURSIVE-DEFTYPE Writeup

    + +
    Issue:        RECURSIVE-DEFTYPE
    
+Forum:	      Editorial
    
+References:   DEFTYPE (p50)
    
+Category:     CLARIFICATION
    
+Edit history: 05-Mar-91, Version 1 by Pitman
    
+	      15-Mar-91, Version 2 by Pitman, Loosemore
    
+	       (expand scope of proposal to treat both program and
    
+		structural circularities, and to treat both macros
    
+		and type specifiers equivalently)
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  In discussion of issue CONS-TYPE-SPECIFIER, it became apparent that some
    
+  users thought it might be ok to have non-terminating recursive DEFTYPE
    
+  definitions.  Some vendors balked at this.  The case in question, which
    
+  is not [yet] valid Common Lisp at the time the proposal is written, but 
    
+  which nevertheless illustrates the point, is Barry Margolin's:
    
+
    
+   (deftype proper-list (&optional (element-type t))
    
+     `(or null (cons ,element-type proper-list)))
    
+
    
+  Another case, which is also not valid Common Lisp but which illustrates
    
+  a case that might be more tolerable is Allan Wechsler's:
    
+
    
+   (deftype list-of-length (length)
    
+     (if (= 0 length)
    
+	 'null
    
+	 `(cons t (list-of-length ,(- length 1)))))
    
+
    
+Proposal (RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE):
    
+
    
+  Clarify that recursive expansion of the type specifier returned as
    
+  the expansion of a DEFTYPE must terminate, including the expansion
    
+  of type specifiers which are nested within the expansion.
    
+
    
+  Clarify that the consequences are undefined if the result of
    
+  fully expanding a type specifier contains any circular structure,
    
+  except within the objects referred to by MEMBER and EQL type
    
+  specifiers.
    
+
    
+  Clarify that recursive expansion of the form returned as the
    
+  expansion of a DEFMACRO must terminate, including the expansion 
    
+  of other macros which are subforms of other forms returned by
    
+  DEFMACRO.
    
+
    
+  Clarify that the consequences are undefined if the result of fully
    
+  macroexpanding a form contains any non-constant circular list
    
+  structure.
    
+
    
+Rationale:
    
+
    
+  This probably protects the status quo in most implementations,
    
+  while giving users a clear sense of what's reasonable and what's not.
    
+
    
+Test Cases:
    
+
    
+  These test cases are more contrived in nature, but are chosen to be 
    
+  actually plausible to test in existing implementations (something not
    
+  true of the cases mentioned in the problem description):
    
+
    
+  #1: (DEFUN RETURNS-T (X) X)
    
+      (DEFTYPE FOO () '(OR (SATISFIES RETURNS-T) FOO))
    
+
    
+      This is an error because in (TYPEP X 'FOO), FOO cannot, in general,
    
+      be fully expanded because the expansion does not terminate.
    
+
    
+  #2: (DEFTYPE FOO (&KEY (FAST NIL))
    
+        (IF FAST 
    
+	    `(SATISFIES FOO-FAST)
    
+	    `(AND SYMBOL (FOO :FAST T))))
    
+
    
+      This is well-defined because in (TYPEP X 'FOO), FOO can, in general,
    
+      be fully expanded without error because the recursion always terminates.
    
+
    
+  #3: Macro definitions like:
    
+
    
+      (DEFMACRO MAPCAR1 (FN LIST)
    
+	`(IF (NULL ,LIST) '()
    
+	     (CONS (FUNCALL ,FN (CAR ,LIST))
    
+	           (MAPCAR1 ,FN (CDR ,LIST)))))
    
+
    
+      would be explicitly undefined.
    
+
    
+  #4: Forms involving explicit circularities, such as
    
+
    
+      (PROGN . #1=((PRINT 'FOO) . #1#))
    
+
    
+      would be explicitly undefined.
    
+
    
+  #5: Type specifiers involving explicit circularities, such as
    
+
    
+      a. (TYPEP 3 '(AND #1=(T . #1#)))
    
+
    
+      would be explicitly undefined, except for cases like
    
+
    
+      b. (TYPEP 3 '(EQL #1=(T . #1#)))
    
+
    
+      which would still be well-defined.
    
+
    
+Current Practice:
    
+
    
+  Genera implements this proposal.
    
+
    
+  #1: The proposal makes this an error.
    
+      Genera uses a TYPE-EXPAND function internally at compile time and
    
+      so cannot handle this case.
    
+
    
+  #2: The proposal requires this to work.
    
+      Genera handles this case.
    
+
    
+  #3: The proposal makes this an error.
    
+      Genera can manage to do (MAPCAR #'1+ '(1 2 3)) as a standalone form,
    
+      but blows out during lexical analysis both in the interpreter and
    
+      compiler if you put it in a definition.
    
+
    
+  #4: The proposal makes this case an error.
    
+      Genera can't handle this case at all.
    
+
    
+  #5: The proposal makes #5a an error but requires #5b to work.
    
+      Genera doesn't handle #5a but does handle #5b.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably none.
    
+
    
+Cost to Users:
    
+
    
+  Little or none.  Code which exploited the erroneous cases were already
    
+  not portable in practice, so probably no users relied on them.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Portability pitfalls waiting for unsuspecting users.
    
+
    
+Benefits:
    
+
    
+  Compiler writers who didn't want to handle this won't go to sleep every
    
+  night in fear that they really should have and that some day someone will
    
+  be knocking on their door asking why not.
    
+
    
+Aesthetics:
    
+
    
+  This is intended to be equivalent to the status quo for macros, although
    
+  it doesn't have to be spelled out there because the presence of MACROEXPAND
    
+  pretty much forces it.  In any case, it clarifies that DEFTYPE and DEFMACRO
    
+  must be essentially consistent on this issue.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal.
    
+
    
+  If Sandra Loosemore's TYPE-EXPAND proposal (part of issue TYPE-SPECIFIER-P)
    
+  passed, this view of the world would pretty much be forced anyway.
    
+
    
+  Of Margolin's example, Rob MacLachlan (at CMU) wrote:
    
+   ``I am fairly sure that nobody has addressed this issue.  
    
+     Although I have been aware of it, I kept quiet about it, 
    
+     because my compiler gags on recursive deftypes, and I was
    
+     afraid someone would decide that was a bug.''
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292.htm new file mode 100644 index 00000000..ce0e351c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue REDUCE-ARGUMENT-EXTRACTION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REDUCE-ARGUMENT-EXTRACTION Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue REDUCE-ARGUMENT-EXTRACTION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292_w.htm new file mode 100644 index 00000000..3dc3d60d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss292_w.htm @@ -0,0 +1,118 @@ + + + +CLHS: Issue REDUCE-ARGUMENT-EXTRACTION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REDUCE-ARGUMENT-EXTRACTION Writeup

    + +
    Issue:         REDUCE-ARGUMENT-EXTRACTION
    
+References:    REDUCE (pp. 251-252), :KEY arguments (p. 246), 
    
+               the astronaut structure (pp. 312-313)
    
+Category:      ADDITION
    
+Edit history:  Version 1 by Pierson 5-Dec-87
    
+               Version 2 by Pierson 30-Dec-87
    
+               Version 3 by Masinter 13-Feb-88
    
+
    
+Problem description:
    
+
    
+REDUCE is the only one of the Common Lisp functions that modify or
    
+search lists and sequences which does not accept a :KEY argument.
    
+This complicates many uses of REDUCE.
    
+
    
+Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
    
+
    
+Change the definition of REDUCE to take a :KEY keyword described as
    
+follows: 
    
+
    
+If a :KEY argument is supplied, its value must be a function of one
    
+argument which will be used to extract the values to reduce.  The :KEY
    
+function will be applied exactly once to each element of the sequence
    
+in the order implied by the reduction order but not to the value of
    
+the :INITIAL-VALUE argument, if any.
    
+
    
+Example:
    
+
    
+Using REDUCE to obtain the total of the ages of the possibly empty
    
+sequence of astronauts ASTROS, would currently require:
    
+
    
+    (REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
    
+
    
+If this proposal is adopted, the same result could be obtained without
    
+creating a new list by: 
    
+
    
+    (REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
    
+
    
+Rationale:
    
+
    
+This proposal makes many common situations where REDUCE would be useful
    
+much less cumbersome.
    
+
    
+Current practice:
    
+
    
+We know of no implementation which currently supports this feature.
    
+
    
+Cost to Implementors:
    
+
    
+This will require most implementations to make a trivial modification
    
+to REDUCE.  Implementations which wish to use this as an opportunity to
    
+further optimize compiled calls to REDUCE will have to undertake more
    
+work (which would be much more difficult today).
    
+
    
+Cost to Users:
    
+
    
+None, this is an upward compatible extension.
    
+
    
+Cost of non-Adoption:
    
+
    
+REDUCE will continue to be more difficult to use than other sequence
    
+functions on sequences of complex objects.
    
+
    
+Benefits:
    
+
    
+REDUCE will become easier to use on sequences of complex objects.  It
    
+will be easier for compilers to convert some calls to REDUCE into
    
+efficient loops.
    
+
    
+Aesthetics:
    
+
    
+Slightly damaged in one way.  All :KEY arguments are currently defined
    
+to be used for predicates, this proposal will implicitly broaden :KEY
    
+to support general extraction for any purpose.
    
+
    
+Slightly improved in another way. Many common situations where REDUCE
    
+could be used would be easier to write and easier to later read.
    
+
    
+Discussion:
    
+
    
+Several members of the committee feel that the increased functionality
    
+outweighs the damage to the definition of :KEY.  No one has objected
    
+to this change in the recent round of discussions.
    
+
    
+There is some controversy over whether the "definition" of :KEY
    
+arguments on page 246 of CLtL really constitutes a definition or just
    
+an "unwritten rule".
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293.htm new file mode 100644 index 00000000..d1635efe --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293.htm @@ -0,0 +1,47 @@ + + + +CLHS: Issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293_w.htm new file mode 100644 index 00000000..57773ae7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss293_w.htm @@ -0,0 +1,320 @@ + + + +CLHS: Issue REMF-DESTRUCTION-UNSPECIFIED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REMF-DESTRUCTION-UNSPECIFIED Writeup

    + +
    Status: v6 accepted by X3J13 with amendments to fix typos (see v7) on 16-1 vote
    
+Issue:        REMF-DESTRUCTION-UNSPECIFIED
    
+References:   (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
    
+	      REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
    
+	      DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256); 
    
+	      NCONC, NRECONC (p269); NUNION, NINTERSECTION,
    
+	      NSET-EXCLUSIVE-OR (pp276-279).
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
    
+	      29-Oct-87, Version 2 by Pitman (flesh out proposals)
    
+	      28-Nov-88, Version 3 by Pitman (revised presentation)
    
+	      29-Nov-88, Version 4 by Pitman (slight editing per DLA)
    
+	      15-Mar-89, Version 5 by Margolin (amendments discussed in
    
+			 Hawaii, removed -NOT functions)
    
+	      17-Mar-89, Version 6 by Margolin (make NSUBSTITUTE* less vague)
    
+	      05-Apr-89, Version 7 by Pitman (typos corrected per X3J13)
    
+
    
+Problem Description:
    
+
    
+ Currently, the exact nature of the side-effect performed by list
    
+ modification routines is not specified.
    
+
    
+ Either the specific modifications allowed should be specified so that
    
+ programmers can rely on them and implementors can avoid accidentally
    
+ causing problems by introducing well-meaning optimizations, or else
    
+ the documentation should explicitly state that the effects are
    
+ unspecified so that programmers will not depend on them and 
    
+ implementors will feel comfortable about doing interesting optimizations.
    
+
    
+Proposal (REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89):
    
+
    
+ Clarify that the way in which the destructive behavior of the
    
+ operators below is achieved is explicitly vague in a number of ways,
    
+ in order to provide individual implementations the necessary
    
+ flexibility to do useful optimizations.
    
+
    
+ (SETF (GETF place indicator) value)
    
+  is permitted to either SETF place or to SETF any part, CAR or
    
+  CDR, of the top-level list structure held by that place.
    
+
    
+ (REMF place indicator)
    
+  is permitted to either SETF place or to SETF any part, CAR or
    
+  CDR, of the top-level list structure held by that place.
    
+
    
+ (SETF (GET symbol indicator) value)
    
+  is constrained to behave exactly the same as
    
+  (SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
    
+
    
+ (REMPROP symbol indicator)
    
+  is constrained to behave exactly the same as
    
+  (REMF (SYMBOL-PLIST symbol) indicator).
    
+
    
+ (NREVERSE sequence)
    
+  when sequence is a list, is permitted to SETF any part, CAR or
    
+   CDR, of the top-level list structure in that sequence.
    
+  when sequence is an array is permitted to re-order the elements
    
+   of the given sequence in order to produce the resulting array.
    
+
    
+ (DELETE object sequence ...)
    
+  when sequence is a list, is permitted to SETF any part, CAR or
    
+   CDR, of the top-level list structure held in that sequence.
    
+  when sequence is an array is permitted to change the dimensions
    
+   of the array and to slide its elements into new positions without
    
+   permuting them to produce the resulting array.
    
+  
    
+ (DELETE-IF test sequence ...)
    
+  is constrained to behave exactly like
    
+  (DELETE NIL sequence
    
+	  :TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
    
+	  ...).
    
+
    
+ (DELETE-DUPLICATES sequence ...)
    
+  when sequence is a list, is permitted to SETF any part, CAR or
    
+   CDR, of the top-level list structure held in that sequence.
    
+  when sequence is an array is permitted to change the dimensions
    
+   of the array and to slide its elements into new positions without
    
+   permuting them to produce the resulting array.
    
+
    
+ (NRECONC list tail)
    
+  is constrained to have side-effect behavior equivalent to:
    
+  (NCONC (NREVERSE list) tail).
    
+
    
+ (NUNION list1 list2 ...)
    
+ (NINTERSECTION list1 list2 ...)
    
+ (NSET-EXCLUSIVE-OR list1 list2 ...)
    
+  is permitted to SETF any part, CAR or CDR, of the top-level of
    
+  any of the given lists.
    
+
    
+  Note, however, that since this side-effect is not required,
    
+  these functions should still not be used in for-effect-only
    
+  positions in portable code.
    
+
    
+ (NCONC . lists)
    
+  is defined using the following recursive relationship:
    
+
    
+    (NCONC) => NIL
    
+    (NCONC NIL . args) == (NCONC . args)
    
+    (NCONC arg) => arg
    
+    (NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
    
+		      and returns arg1 
    
+    (NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)
    
+
    
+  [If a previous cleanup issue prohibited NIL as a non-last argument
    
+   then ignore the (NCONC NIL . args) case.]
    
+
    
+ (NSUBSTITUTE new-object old-object sequence ...)
    
+ (NSUBSTITUTE-IF new-object test sequence ...)
    
+  is required to SETF any CAR (if SEQUENCE is a list) or AREF (if it's
    
+  a vector) of SEQUENCE which is required to be replaced with
    
+  NEW-OBJECT.  If SEQUENCE is a list, none of the CDRs of the
    
+  top-level list may be modified.  These functions, therefore, may be
    
+  used in for-effect-only positions in code (some may find this
    
+  stylistically distasteful, though).
    
+
    
+ Note: The above clarifications are not intended as complete functional
    
+ descriptions. They are intended to augment (rather than to replace)
    
+ other descriptions already in effect.
    
+
    
+Test Cases:
    
+
    
+ For GETF...
    
+
    
+    (SETQ FOO (LIST 'A 'B 'C 'D 'E 'F))    ==> (A B C D E F)
    
+    (SETQ BAR (CDDR FOO))                  ==> (C D E F)
    
+    (REMF FOO 'C)
    
+    BAR				           ==> ??
    
+
    
+    In Symbolics Common Lisp, BAR holds (C D E F).
    
+    CLtL allows other interpretations. eg, BAR might hold
    
+    (C), (NIL), (C NIL) or (C D).
    
+    Under this proposal, any of these interpretations (and others as well)
    
+    would still be valid
    
+
    
+ For DELETE...
    
+
    
+    (SETQ FOO (LIST 'A 'B 'C))   ==> (A B C)
    
+    (SETQ BAR (CDR FOO))         ==> (B C)
    
+    (SETQ FOO (DELETE 'B FOO))   ==> (A C)
    
+    BAR                          ==> ??
    
+    (EQ (CDR FOO) (CAR BAR))     ==> ??
    
+
    
+    In Symbolics Common Lisp, these last two expressions return ((C)) and T.
    
+    Under this proposal, either of these interpretations (and others
    
+    as well) would be valid.
    
+
    
+ For NCONC...
    
+
    
+    (SETQ FOO (LIST 'A 'B 'C 'D 'E)
    
+	  BAR (LIST 'F 'G 'H 'I 'J)
    
+	  BAZ (LIST 'K 'L 'M)) => (K L M)
    
+    (SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
    
+    FOO => (A B C D E F G H I J K L M)
    
+    BAR => (F G H I J K L M)
    
+    BAZ => (K L M)
    
+
    
+    (SETQ FOO (LIST 'A 'B 'C 'D 'E)
    
+	  BAR (LIST 'F 'G 'H 'I 'J)
    
+	  BAZ (LIST 'K 'L 'M)) => (K L M)
    
+    (SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M) 
    
+    FOO => (A B C D E F G H I J K L M)
    
+    BAR => (F G H I J K L M)
    
+    BAZ => (K L M)
    
+
    
+
    
+Rationale:
    
+
    
+ Implementations already vary widely on their implementation techniques
    
+ for these functions. This effectively clarifies the status quo, making
    
+ it more clear to programmers what they may rely upon in portable code.
    
+
    
+ In the case of NCONC, however, the precise definition is useful because
    
+ it is what users expect, it is how NCONC has been defined for many
    
+ years, and it is how current implementations generally work.  It may
    
+ not always be the most efficient way (e.g. it may result in invisible
    
+ pointers in CDR-coded implementations), but callers of NCONC probably
    
+ use it specifically for its precise side effects.
    
+
    
+ In the case of NSUBSTITUTE, this seems like the only reasonable
    
+ implementation mechanism, and there doesn't seem to be a reason not to
    
+ guarantee it.
    
+
    
+Current Practice:
    
+
    
+ All valid implementations are believed to comply with the vague
    
+ definitions.  Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
    
+ conform to the NCONC spec.
    
+
    
+Cost to Implementors:
    
+
    
+ None. This is probably the status quo for most implementors.  If there
    
+ are any implementations that don't implement NCONC and NSUBSTITUTE as
    
+ above (which I doubt) they will have to be changed.
    
+
    
+Cost to Users:
    
+
    
+ This change would not affect programs coded with "good programming
    
+ practice".  That is, only programs which rely on currently undocumented
    
+ features would be in any danger of breaking.  In fact, those programs
    
+ are already in such danger, and this change to the documentation would
    
+ just publicize it.  The clarification would -encourage- good programming
    
+ practice by warning people to only obey the published contract of the
    
+ above-mentioned functions.
    
+
    
+ There is, however, no automatic technique for making this check for
    
+ programs already in error. Bugs due to unexpected side-effects are in
    
+ general among the hardest to reckon with.
    
+
    
+Cost of Non-Adoption:
    
+
    
+ Programmers may naively believe there is only one possible or reasonable
    
+ implementation of these functions. Some implementors may shy away from
    
+ reasonable optimizations out of a paranoid belief that deviating from 
    
+ some vague, unspoken rules will lead to programmer unrest. Making these
    
+ things explicitly vague clarifies the implementor's rights in a way that
    
+ permits numerous useful optimizations.
    
+
    
+Benefits: 
    
+
    
+ Users would be discouraged from taking advantage of subtle details
    
+ of these destructive operations because such details would be explicitly
    
+ not guaranteed to be portable.
    
+
    
+ Implementations can improve performance of many of the above-mentioned
    
+ functions when they are not under the constraint to implement them
    
+ in a highly constrained fashion. For example, in Symbolics systems,
    
+ DELETE of a cdr-coded list could use the implementation primitive
    
+ %CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
    
+ pointers.
    
+
    
+ Garbage collection effectiveness can also be improved. For example,
    
+ all of the destructive operations which remove objects (eg, REMF)
    
+ could remove CAR pointers to removed objects which are more volatile
    
+ than the list itself, assisting the garbage collector and thereby
    
+ improving memory usage and paging performance.
    
+
    
+ Tightening the definition of NCONC and NSUBSTITUTE permits users to
    
+ predict their programs' behavior more precisely.
    
+
    
+Non-Benefits:
    
+
    
+ Users who inadvertently depend on side-effect behavior may be rudely
    
+ surprised when moving between implementations.
    
+
    
+ Compatibility with older Lisp dialects is diminished.
    
+
    
+ Implementors have less flexibility in implementing NCONC efficiently.
    
+ This is true of NSUBSTITUTE, but this is less likely to cause problems.
    
+
    
+Performance Impact:
    
+
    
+ Metering in Symbolics test  systems have shown that there are substantial
    
+ performance gains to be had by allowing implementations flexibility in
    
+ these areas.
    
+
    
+ In the case of NCONC, this implementation flexibility, and hence
    
+ potential performance improvements, is sacrificed.
    
+
    
+ If anyone ever invents CAR-coding, the required implementation of
    
+ NSUBSTITUTE could be a performance hindrance.
    
+
    
+Aesthetics:
    
+
    
+ Most of these functions implement abstract operations. For example,
    
+ REMPROP implements an abstract operation on a "property list".
    
+ Proper language design should not encourage people to delve below the
    
+ level of abstraction into the nitty gritty.
    
+
    
+ NCONC is a "less abstract" function than the rest of the functions
    
+ described above.  It is usually used precisely because of the way it
    
+ interacts with list implementation.  Similarly for NSUBSTITUTE.
    
+
    
+Discussion:
    
+
    
+ Andre's original version of this proposal pushed for explicitly vague
    
+ descriptions of these functions' side-effect behavior.  He believes
    
+ that if users want more predictability from these functions, they
    
+ should write private variants that implement whatever predictability
    
+ they require. 
    
+
    
+ Pitman originally opposed this position because he weighed portability
    
+ a higher concern. Since the original discussion, however, his views on
    
+ how to resolve this priority have been refined, and he now believes
    
+ that leaving things vague is appropriate. As such, he now supports what
    
+ is effectively Andre's original proposal.
    
+
    
+ Pitman and Andre supported version 4.  [I don't know how they feel
    
+ about v6 -- Barmar].
    
+
    
+ Moon supports version 6.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294.htm new file mode 100644 index 00000000..34c4be1a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294.htm @@ -0,0 +1,42 @@ + + + +CLHS: Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294_w.htm new file mode 100644 index 00000000..6d8af324 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss294_w.htm @@ -0,0 +1,113 @@ + + + +CLHS: Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN Writeup

    + +
    Issue:        REQUIRE-PATHNAME-DEFAULTS-AGAIN
    
+Forum:	      X3J13
    
+References:   PROVIDE, REQUIRE, *MODULES* (all on CLtL1 p188),
    
+	      Issue REQUIRE-PATHNAME-DEFAULTS
    
+Category:     CHANGE
    
+Edit history: 05-Feb-92, Version 1 by Pitman
    
+Status:	      Approved by X3J13 on vote of 9-0-1 at December 1991 meeting
    
+
    
+Problem Description:
    
+
    
+  REQUIRE, PROVIDE, and *MODULES* were flushed but are still used by many 
    
+  Common Lisp programs.  Many in the user community have expressed dismay.
    
+
    
+Proposal (REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91):
    
+
    
+  Return REQUIRE, PROVIDE, and *MODULES* to the language,
    
+  as described in CLtL1, except for the following changes:
    
+
    
+   1. Remove the second argument to REQUIRE.
    
+
    
+   2. Deprecate all three functions.
    
+
    
+   3. If any intervening cleanups have been passed and 
    
+      would have referred to these functions (other than the cleanups
    
+      that removed them, of course), those cleanups would apply.
    
+
    
+Rationale:
    
+
    
+  This diminishes the compatibility problems caused by previous votes.
    
+
    
+  1. The second argument is what was problematic, so remove only that.
    
+
    
+  2. All of these functions are questionable to some committee members,
    
+     but deprecation allows for a suitable transition period for people to
    
+     find something better.
    
+
    
+  3. We have said that the original CLtL1 wording is reinstated,
    
+     and we don't believe there are any cleanups which are in conflict,
    
+     but if one is later discovered to be in conflict, we want to give
    
+     precedence to the cleanup, not to CLtL1.
    
+
    
+Test Case:
    
+
    
+  (PROVIDE '*MODULES*)
    
+  (REQUIRE '*MODULES*)
    
+
    
+Current Practice:
    
+
    
+  No previously-conforming implementation could have had these functions.
    
+  Some implementations (e.g., Genera) were continuing to provide these 
    
+  functions but in a different package.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small, and highly localized.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Many users who have expressed the opinion that removing these things was
    
+  gratuitous would continue to be upset.
    
+
    
+Benefits:
    
+
    
+  Cost of non-adoption is avoided.
    
+
    
+Editorial Impact:
    
+
    
+  A modular change of relatively small nature.  Just whatever it takes to
    
+  dredge up the old text and dust it off for current editorial style, etc.,
    
+  make it conform to changes cited in the proposal.
    
+
    
+Aesthetics:
    
+
    
+  Some users believe that PROVIDE and REQUIRE are aethetic.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295.htm new file mode 100644 index 00000000..bb980fee --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295_w.htm new file mode 100644 index 00000000..b02215c1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss295_w.htm @@ -0,0 +1,148 @@ + + + +CLHS: Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN Writeup

    + +
    Forum:		Public Review
    
+Issue:		REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN
    
+References:	Barrett's public review comment #26
    
+		Loosemore's public review comment #7
    
+		REQUIRE
    
+		Issue REQUIRE-PATHNAME-DEFAULTS
    
+		Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN
    
+Category:	CHANGE
    
+Edit history:	20 Dec 1992, Version 1 by Loosemore
    
+Status:		Proposal RESTORE-ARGUMENT passed 11-0 on letter ballot
    
+                92-302.
    
+
    
+
    
+Problem description:
    
+
    
+  In the base document (CLtL), the REQUIRE function was specified as
    
+  accepting a required module name argument and an optional pathname
    
+  argument.  In the current specification, the optional pathname
    
+  argument has been removed.  The rationale given for this in
    
+  X3J13/91-415 is that it was the second argument that led to
    
+  portability problems.  This claim is incorrect.  It was the case that
    
+  both the one argument and the two argument forms had portability
    
+  problems in the past, but the addition of logical pathnames made the
    
+  two argument version easier to use in a portable way.  Elimination of the
    
+  second argument means that we're left with the same problem the single
    
+  argument form has always had, namely that there are several competing,
    
+  incompatible mechanisms for dealing with the situation where the
    
+  module being required has not already been provided.
    
+
    
+
    
+Proposal (REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT):
    
+
    
+  Restore the optional pathname argument to REQUIRE, as specified
    
+  in the base document.
    
+
    
+  Replace the examples with ones that better illustrate portable and
    
+  nonportable uses of REQUIRE, such as those suggested below.
    
+
    
+
    
+Rationale:
    
+
    
+  Restoring the second argument makes it at least *possible* to use
    
+  REQUIRE in a portable way.
    
+
    
+
    
+Examples:
    
+
    
+  ;;; This illustrates a nonportable use of REQUIRE, because it
    
+  ;;; depends on the implementation-dependent file-loading mechanism.
    
+
    
+  (require "CALCULUS")
    
+
    
+  ;;; This use of REQUIRE is nonportable because of the literal 
    
+  ;;; physical pathname.  
    
+
    
+  (require "CALCULUS" "/usr/lib/lisp/calculus")
    
+
    
+  ;;; One form of portable usage involves supplying a logical pathname,
    
+  ;;; with appropriate translations defined elsewhere.
    
+
    
+  (require "CALCULUS" "lib:calculus")
    
+
    
+  ;;; Another form of portable usage involves using a variable or
    
+  ;;; table lookup function to determine the pathname, which again
    
+  ;;; must be initialized elsewhere.
    
+
    
+  (require "CALCULUS" *calculus-module-pathname*)
    
+
    
+
    
+Current practice:
    
+
    
+  Who knows?
    
+
    
+
    
+Cost to implementors:
    
+
    
+  Minor.
    
+
    
+
    
+Cost to users:
    
+
    
+  None.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Having a feature in the language which is impossible to use portably
    
+  is unaesthetic.
    
+
    
+
    
+Editorial impact:
    
+
    
+  The changes are confined to the dictionary entry for REQUIRE.
    
+
    
+
    
+Discussion:
    
+
    
+  The proposal to restore REQUIRE to the language without its second
    
+  argument was brought up at the Dec 1991 meeting without the benefit of
    
+  a formal writeup or any advance discussion on the mailing list, which
    
+  accounts for the resulting technical blunder.  We don't have a very
    
+  good record when it comes to technical decisions made on the fly at
    
+  meetings.
    
+
    
+  Loosemore says: I would still prefer to remove this broken feature
    
+  from the language entirely, but I'd rather not waste any more time
    
+  arguing about that given that some people seem to feel strongly about
    
+  keeping it in.  I'm willing to accept proposal RESTORE-ARGUMENT
    
+  as a compromise, but doing nothing would not be acceptable to me.
    
+
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296.htm new file mode 100644 index 00000000..b6abb6cf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue REQUIRE-PATHNAME-DEFAULTS:ELIMINATE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REQUIRE-PATHNAME-DEFAULTS:ELIMINATE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue REQUIRE-PATHNAME-DEFAULTS:ELIMINATE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296_w.htm new file mode 100644 index 00000000..8102d77a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss296_w.htm @@ -0,0 +1,135 @@ + + + +CLHS: Issue REQUIRE-PATHNAME-DEFAULTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REQUIRE-PATHNAME-DEFAULTS Writeup

    + +
    Issue:         REQUIRE-PATHNAME-DEFAULTS
    
+References:    *MODULES*, PROVIDE, REQUIRE, pp 188-191
    
+               LOAD, pp 426-427
    
+Category:      CHANGE
    
+Edit history:  Version 1 by Pierson 9/13/88
    
+               Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
    
+               Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
    
+               Version 4 by Pierson 10/31/88, remove from language
    
+               Version 5 by Pierson 11/15/88, cleanup, fix discussion
    
+               Version 6 by Pierson 12/9/88, remove *MODULES* as well
    
+
    
+Problem description:
    
+
    
+PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
    
+to provide multi-file Common Lisp programs with a single mechanism to
    
+detect and correct incorrect load sequences.  These functions were
    
+also designed to be used for general file inclusion in Common Lisp.
    
+Unfortunately, the file loading feature of REQUIRE is specified such
    
+that it is inherently non-portable and environment dependent.
    
+
    
+Proposal (REQUIRE-PATHNAME-DEFAULTS:ELIMINATE):
    
+
    
+Remove PROVIDE, REQUIRE, and *MODULES* from the Common Lisp standard.
    
+
    
+Test Cases/Examples:
    
+
    
+(PROVIDE 'fft)
    
+
    
+Would not be Common Lisp.
    
+
    
+(REQUIRE 'fft)
    
+
    
+Would not be Common Lisp.
    
+
    
+Rationale:
    
+
    
+The file loading feature of REQUIRE is non-portable.  The remaining
    
+functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
    
+can easily be implemented by user code.  Since some implementations
    
+will retain the automatic module loading features of REQUIRE and some
    
+won't, use of REQUIRE will almost always make code less portable.
    
+
    
+Current practice:
    
+
    
+All implementations currently support some sort of file loading via
    
+single-argument REQUIRE.  In general, the Lisp Machine implementations
    
+invoke the system module building/loading facility while the Unix
    
+implementations simply try to load a file in the current directory.
    
+
    
+Cost to Implementors:
    
+
    
+Implementations will have to move PROVIDE and REQUIRE to their package
    
+for implementation extensions and change their documentation to
    
+indicate that PROVIDE and REQUIRE are non-standard.  This is a fairly
    
+small change.
    
+
    
+Cost to Users:
    
+
    
+Non-portable programs that rely on PROVIDE and REQUIRE will probably
    
+be unaffected since implementations will probably maintain their
    
+existing functionality.  Since the current behavior is decidedly
    
+non-portable, portable programs have to aviod or special-case PROVIDE
    
+and REQUIRE anyway.
    
+
    
+Cost of non-Adoption:
    
+
    
+PROVIDE and REQUIRE will continue as impediments to portability.
    
+
    
+Benefits:
    
+
    
+The non-portability of PROVIDE and REQUIRE will be made obvious.
    
+
    
+Aesthetics:
    
+
    
+This simplifies the language by removing an environment-dependent
    
+feature. 
    
+
    
+Discussion:
    
+
    
+The cleanup committee tried to come up with a proposal to restrict
    
+PROVIDE and REQUIRE to the portable subset of their functionality.
    
+This failed because several implementors objected that it compelled
    
+them to significantly reduce the functionality they provided users in
    
+order to create a trivial feature which any user could easily write
    
+for herself.
    
+
    
+Fahlman, Gregor, Grey, Loosemore, Moon, Pierson, Pitman, Steele, and
    
+Zacharias have expressed support for removing PROVIDE and REQUIRE from
    
+the language, at least as the lesser of several evils.
    
+
    
+JonL would much rather see PROVIDE and REQUIRE remain in the language
    
+as a safety net behind any implementation-specific system building
    
+facility.  Pierson likes the safety net idea, but doesn't think it's
    
+workable without forbidding REQUIRE from loading files.
    
+
    
+Pitman suggested that PROVIDE and REQUIRE should be depricated rather
    
+than removed entirely.  Pierson agrees, but notes that Larry wants us
    
+to deal with deprication versus elimination as a separate global topic.
    
+
    
+Several people have expressed a desire not to break existing user
    
+code.  If accepted, this proposal should not break existing code
    
+because all implementations are expected to retain their current
    
+PROVIDE and REQUIRE functionality as an extension to Common Lisp.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297.htm new file mode 100644 index 00000000..d86f52f5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue REST-LIST-ALLOCATION:MAY-SHARE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue REST-LIST-ALLOCATION:MAY-SHARE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue REST-LIST-ALLOCATION:MAY-SHARE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297_w.htm new file mode 100644 index 00000000..aa2ded6f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss297_w.htm @@ -0,0 +1,260 @@ + + + +CLHS: Issue REST-LIST-ALLOCATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue REST-LIST-ALLOCATION Writeup

    + +
    Forum:         Cleanup
    
+Issue:         REST-LIST-ALLOCATION
    
+
    
+References:    CLtL pp 107-108 (APPLY)
    
+
    
+Related issues: DYNAMIC-EXTENT
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  8-Dec-88, Version 1 by Masinter
    
+               9-Dec-88, Version 2 by Clinger (add rationale, more discussion)
    
+               12-Dec-88, Version 3 by Clinger (delete bogus examples)
    
+
    
+Problem description:
    
+
    
+In the special case of calling a function with an &REST list via APPLY,
    
+Common Lisp fails to specify whether a new copy of the list is freshly
    
+allocated.  For example, given
    
+
    
+ (DEFVAR *MY-LIST* '(A B C))
    
+
    
+ (DEFUN FOO (&REST X) (EQ X *MY-LIST*))
    
+
    
+does 
    
+(APPLY #'FOO *MY-LIST*)
    
+return T?
    
+
    
+This issue is different from the question of the extent of "rest lists" in
    
+the case when they *are* newly allocated which is indefinite; the issue
    
+DYNAMIC-EXTENT also contains some proposals about extent.
    
+
    
+
    
+Proposal (REST-LIST-ALLOCATION:NEWLY-ALLOCATED): 
    
+
    
+Specify that &REST lists are newly allocated in the case when the function
    
+is called via APPLY.
    
+
    
+Proposal (REST-LIST-ALLOCATION:MAY-SHARE): 
    
+
    
+Specify that the value of an &REST parameter is permitted, but not required,
    
+to share (top-level) structure with the last argument to APPLY.
    
+
    
+Proposal (REST-LIST-ALLOCATION:MUST-SHARE)
    
+
    
+Specify that the value of an &REST parameter is required
    
+to share (top-level) structure with the last argument to APPLY.
    
+
    
+>> this needs better spec about how the args match << 
    
+
    
+Examples:
    
+
    
+ (DEFVAR *MY-LIST* '(A B C))
    
+
    
+ (DEFUN FOO (&REST X) (EQ X *MY-LIST*))
    
+
    
+ (APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
    
+			      ; many stock hardware implementations
    
+
    
+This implies that
    
+
    
+ (DEFUN BAR (&REST X) (RPLACA X 'D))
    
+
    
+ (APPLY #'BAR *MY-LIST*)
    
+
    
+ *MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
    
+		      ; hardware implementations
    
+
    
+Another example: which of the following have the same semantics?
    
+
    
+    (setq x '(1 2 3))
    
+
    
+    [1] (apply #'foo 1 2 3 NIL)
    
+    [2] (apply #'foo 1 2 (cddr x))
    
+    [3] (apply #'foo 1 (cdr x))
    
+    [4] (apply #'foo x)
    
+    [5] (funcall #'foo 1 2 3)
    
+
    
+Under REST-LIST-ALLOCATION:NEWLY-ALLOCATED:
    
+  [1]-[5] are equivalent.
    
+Under REST-LIST-ALLOCATION:MAY-SHARE:
    
+  Any answer to the question is correct for some conceivable implementation.
    
+  Abstracting over implementations, this means that [1]-[5] are pairwise
    
+  non-equivalent.
    
+Under REST-LIST-ALLOCATION:MUST-SHARE:
    
+  [1]-[4] are pairwise non-equivalent in all implementations.  This proposal
    
+  leaves open the question of whether [1] is equivalent to [5].
    
+
    
+And finally:
    
+
    
+Should     (defun foo (&rest x) ...)
    
+    
    
+     behave (aside from efficiency) as if it were defined:
    
+    
    
+(defun foo (&rest G0047)     ;Gensym really
    
+      (let ((x (copy-list G0047)))
    
+         ...))
    
+    
    
+
    
+Rationale:
    
+
    
+The semantics of APPLY is unclear.  In consequence it is impossible
    
+to write portable code that relies on &REST arguments sharing structure
    
+with the last argument to APPLY.  Portable code can rely on &REST arguments
    
+*not* sharing structure with the last argument to APPLY, but only by
    
+performing an explicit COPY-LIST on all &REST arguments; this is redundant
    
+and inefficient in implementations where &REST arguments are newly
    
+allocated anyway.
    
+
    
+Current practice:
    
+
    
+Some implementations always share. Some implementations never share.
    
+A few may share interpreted and not share compiled, or vice versa.
    
+
    
+Cost to Implementors:
    
+
    
+None for MAY-SHARE, since that is the status quo.  Both of the other
    
+proposals entail a significant cost for some implementations.
    
+If MUST-SHARE is adopted, then implementations that don't share structure
    
+may be nearly impossible to convert.  If NEWLY-ALLOCATED is adopted, then
    
+implementations that do share will have to insert a call to COPY-LIST
    
+inside either APPLY or &REST list handling, which will slow things down
    
+and may be difficult as well.
    
+
    
+Cost to Users:
    
+
    
+No matter what, somebody gets hurt.  MAY-SHARE means you have to
    
+write awkward and inefficient code if you care.  (This is already
    
+the case for portable code.)  MUST-SHARE means you have to add
    
+explicit calls to COPY-LIST to code that assumes the contrary.
    
+NEWLY-ALLOCATED means you have to rewrite code that assumes sharing.
    
+
    
+Cost of non-adoption:
    
+
    
+Great confusion over the issue.  A certain amount of awkwardness and
    
+inefficiency would remain inevitable if you want to write portable code.
    
+
    
+Performance impact:
    
+
    
+MUST-SHARE costs least in consing, but might slow down function call 
    
+for some implementations.  MAY-SHARE lets implementations pick, has
    
+least impact.  NEWLY-ALLOCATED requires consing in cases where it
    
+didn't before.
    
+
    
+Benefits:
    
+
    
+Less confusion.  Improved portability.
    
+
    
+Esthetics:
    
+
    
+Differing, strongly held opinions.
    
+
    
+Discussion:
    
+
    
+The Revised3 Report on Scheme specifies that the equivalent of a
    
+&REST argument must be a newly allocated list, to avoid precisely this
    
+problem.
    
+
    
+The argument for MUST-SHARE is that copying is inefficient, so
    
+&REST should never cause copying of a list passed to it from APPLY.
    
+Functions that desire a new copy can just call COPY-LIST.
    
+
    
+Two arguments for MAY-SHARE are:
    
+
    
+1. In no other place does Common Lisp automatically unshare structure,
    
+except when the user is explicitly modifying the structure (as in REMOVE).
    
+Making APPLY automatically unshare would be a semantic wart.
    
+
    
+2. If APPLY copies its last argument, recursive programs that receive an
    
+&REST argument and pass it to APPLY become inefficient.  A linear time
    
+algorithm can change to a quadratic time algorithm.  While the efficiency
    
+could be regained through compiler flow analysis in many cases, it's
    
+better not to put the inefficiency into the language in the first place.
    
+
    
+The DYNAMIC-EXTENT proposal would allow &REST lists
    
+that were "newly allocated" to have dynamic extent if they were
    
+to be passed down via APPLY.  This puts the burden in the
    
+right place.
    
+
    
+Two (closely related) arguments for NEWLY-ALLOCATED:
    
+
    
+1. The programmer's model of function calling is simpler: functions
    
+take arguments, and any two calls that pass the same arguments to the
    
+same function are equivalent.  The MAY-SHARE and MUST-SHARE proposals
    
+require a model in which functions generally take their arguments in
    
+the form of a list, and the extent to which that list shares structure
    
+with other lists in the system becomes an important part of the
    
+semantics of a function call.
    
+
    
+2.  It's not only smashing a &rest argument that's a problem, it's
    
+smashing any list that has been given as the last argument to APPLY as
    
+well.  Consider the following in an implementation that doesn't copy
    
+the last argument to APPLY when it is passed as a &rest argument:
    
+
    
+> (defvar *message*)
    
+*MESSAGE*
    
+> (defun set-message (&rest mess)
    
+    (setq *message* mess))
    
+SET-MESSAGE
    
+> (let ((winner (list 'a 'winner)))
    
+    (apply #'set-message winner)
    
+    (setf (cdr winner) (list 'loser))
    
+    winner)
    
+(A LOSER)
    
+
    
+Is *message* (A WINNER) or (A LOSER)?  (It might be
    
+(#<DTP-LOCATIVE 76123756> #<DTP-ODD-PC 12313453> ...)
    
+but that's a different problem.)  This suggests that once a list has
    
+been given as the last argument to APPLY it is no longer OK to modify
    
+it.
    
+
    
+Gail Zacharias talked about the common idiom of simply doing a COPY-LIST
    
+on every &rest argument, to insure some normalcy.  Her reasoning seems
    
+to bolster the case for those who claim that the current CL semantics
    
+(MAY-SHARE) are deficient:
    
+
    
+    Subject: &REST Lists
    
+    Date: 24 Mar 88 12:23:15 EST (Thu)
    
+    From: gz@spt.entity.com (Gail Zacharias)
    
+    . . . 
    
+    If Common Lisp doesn't require unshared &rest lists, then I think
    
+    it must provide a declarative version of this idiom so the COPY-LIST can
    
+    be portably avoided when it's redundant.  Seems to me that the fact that
    
+    this is a common case where users find a need for conditionalization
    
+    indicates a real deficiency in Common Lisp's specification.
    
+    . . . 
    
+
    
+So we have a responsibility to resolve the very thorny issue
    
+of REST-LIST-ALLOCATION.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298.htm new file mode 100644 index 00000000..a59a6a12 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue RESULT-LISTS-SHARED:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue RESULT-LISTS-SHARED:SPECIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue RESULT-LISTS-SHARED:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298_w.htm new file mode 100644 index 00000000..cb0f4525 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss298_w.htm @@ -0,0 +1,127 @@ + + + +CLHS: Issue RESULT-LISTS-SHARED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue RESULT-LISTS-SHARED Writeup

    + +
    Issue:        RESULT-LISTS-SHARED
    
+Forum:	      Editorial
    
+References:   DIRECTORY (p427), LIST-ALL-PACKAGES (p184)
    
+Category:     CLARIFICATION
    
+Edit history: 02-Mar-91, Version 1 by Pitman
    
+	      15-Mar-91, Version 2 by Pitman (repair current practice)
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  CLtL does not specify whether the list returned by each of these
    
+  functions is freshly-consed each time, or whether it must be treated
    
+  as immutable: LIST-ALL-PACKAGES, DIRECTORY.
    
+
    
+Proposal (RESULT-LISTS-SHARED:SPECIFY):
    
+
    
+  Specify that the lists returned by LIST-ALL-PACKAGES and DIRECTORY are
    
+  freshly consed on every call.  The list resulting from calls to these
    
+  functions may therefore be freely modified by the caller.
    
+
    
+Example:
    
+
    
+  ;Example of recycling list structure from LIST-ALL-PACKAGES
    
+  (DEFUN ALIST-ALL-PACKAGES ()
    
+    (LET ((P (LIST-ALL-PACKAGES)))
    
+      (DO ((L P (CDR L)))
    
+	  ((NULL L) P)
    
+	(SETF (CAR L)
    
+	      (LIST* (CAR L)
    
+		     (PACKAGE-NAME (CAR L))
    
+		     (PACKAGE-NICKNAMES (CAR L)))))))
    
+
    
+  ;Example of recycling list structure from DIRECTORY
    
+  (DEFUN FULL-DIRECTORY (SPEC)
    
+    (LET ((D (DIRECTORY SPEC)))
    
+      (DO ((L D (CDR L)))
    
+          ((NULL L) D)
    
+        (SETF (CAR L)
    
+ 	      (LIST (CAR L)
    
+		    :AUTHOR (FILE-AUTHOR (CAR L))
    
+		    :WRITE-DATE (FILE-WRITE-DATE (CAR L))
    
+		    :LENGTH (IGNORE-ERRORS
    
+			      (WITH-OPEN-FILE (S (CAR L))
    
+				(FILE-LENGTH S))))))))
    
+
    
+Rationale:
    
+
    
+  In most implementations, packages are stored in a hash table for
    
+  faster access by the reader, so the list returned by LIST-ALL-PACKAGES
    
+  is probably freshly consed already.  Also, LIST-ALL-PACKAGES is
    
+  probably called sufficiently seldom that there is no serious
    
+  efficiency issue here.
    
+
    
+  In most implementations, information about the file system is external
    
+  to Lisp and must be freshly computed each time a directory listing is
    
+  done anyway.  Better not to force the caller to do a COPY-LIST on a
    
+  call when the list can easily be guaranteed to be fresh to begin with.
    
+
    
+  Even in situations where it was possible to return a
    
+  non-freshly-consed list, this might put internal data structures of
    
+  the implementation at risk for no really good efficiency reason.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera freshly conses the list returned by DIRECTORY.
    
+  Symbolics Genera does not freshly cons the list returned by LIST-ALL-PACKAGES.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Users wouldn't know what to expect and would be forced to do a
    
+  COPY-LIST just to be sure when they planned to modify the result.  If
    
+  they forgot, and the implementation decided to return a
    
+  non-freshly-consed list, an attempt to modify that list might
    
+  compromise the integrity of the running Lisp.
    
+
    
+Benefits:
    
+
    
+  Clearer specfication
    
+
    
+Aesthetics:
    
+
    
+  Negligible effect.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal.  (He's more than once wanted to modify
    
+  the result list of DIRECTORY and had to do a gratuitous COPY-LIST just
    
+  to be safe.)
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299.htm new file mode 100644 index 00000000..8934e932 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue RETURN-VALUES-UNSPECIFIED:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue RETURN-VALUES-UNSPECIFIED:SPECIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue RETURN-VALUES-UNSPECIFIED:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299_w.htm new file mode 100644 index 00000000..5de8faa6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss299_w.htm @@ -0,0 +1,133 @@ + + + +CLHS: Issue RETURN-VALUES-UNSPECIFIED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue RETURN-VALUES-UNSPECIFIED Writeup

    + +
    Issue:        RETURN-VALUES-UNSPECIFIED
    
+References:   CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
    
+	      TRACE (p 440), UNTRACE (p 440), INSPECT (p 442), 
    
+	      SET-SYNTAX-FROM-CHAR (p 361),
    
+	      LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
    
+
    
+Related issues: REQUIRE-PATHNAME-DEFAULTS
    
+                CLOSED-STREAM-OPERATIONS
    
+Category:     CLARIFICATION
    
+Edit history: 26-Aug-88, Version 1 by Chapman
    
+	      19-Sept-88, Version 2 by Chapman
    
+		 6-Oct-88, Version 3 by Masinter
    
+		 7-Oct-88, Version 4 by Masinter
    
+		26-Nov-88, Version 5 by Masinter
    
+ 		 9-Dec-88, Version 6 by Masinter
    
+
    
+
    
+Problem Description:
    
+ 
    
+The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
    
+INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE 
    
+are not clear about the values returned from those constructs.
    
+ 
    
+Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
    
+ 
    
+Clarify that the return values for the listed constructs are as follows:
    
+ 
    
+CLOSE -- T
    
+IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
    
+execution of IN-PACKAGE.
    
+RENAME-PACKAGE -- the renamed package.
    
+TRACE (when called with arguments) -- implementation-dependent.
    
+UNTRACE -- implementation-dependent.
    
+INSPECT -- implementation-dependent.
    
+SET-SYNTAX-FROM-CHAR -- T
    
+LOCALLY -- the return values of the last form of its body, i.e. the body is
    
+	surrounded by an implicit PROGN.
    
+PROVIDE -- implementation-dependent.
    
+REQUIRE -- implementation-dependent.
    
+ 
    
+(NB: the issue CLOSED-STREAM-OPERATIONS proposes modifying
    
+the return value of CLOSE on closed streams. The issue 
    
+REQUIRE-PATHNAME-DEFAULTS proposes removing 
    
+REQUIRE and PROVIDE. Those proposals would take 
    
+priority over this one.)
    
+
    
+Rationale:
    
+ 
    
+This clarification allows users to know when they can and can not
    
+count on the values returned from these constructs. 
    
+ 
    
+Current Practice:
    
+
    
+Varies; the choices made here are consistent with many but
    
+not all implementations.
    
+  
    
+Cost to Implementors:
    
+ 
    
+Small.
    
+
    
+Benefits:
    
+ 
    
+This clarification will assist users in writing portable code.
    
+ 
    
+Cost to users:
    
+ 
    
+Small; it seems unlikely that there is much code that currently
    
+depends on the return values of these functions; such code isn't
    
+portable.
    
+
    
+Aesthetics:
    
+ 
    
+Specified is better than not, when it makes sense.
    
+ 
    
+Discussion:
    
+ 
    
+PROVIDE and REQUIRE are not likely to appear except in the "top level" of
    
+files, and so their return value is possibly moot.  Another proposal would
    
+eliminate them from the language, and then their return value would definitely
    
+be moot!
    
+
    
+There is some sentiment for leaving unspecified the values of the
    
+debugging/environment features such as TRACE and UNTRACE,
    
+for the same reasons that so much else of their behavior is unspecified.
    
+
    
+Notes from Oct 88 X3J13:
    
+
    
+Except for LOCALLY, why bother?
    
+
    
+That just causes portability problems. Don't want to leave it
    
+unspecified -unless- someone can cite a reason to do so.
    
+
    
+"If many weren't defined, maybe we should leave 'em, but
    
+since nearly all -are- defined, let's just go ahead and
    
+round out the set."
    
+
    
+Most text books she's seen show CLOSE returning NIL.
    
+One text book shows it returning T.
    
+Since some people like to think of T as success and NIL
    
+as failure, maybe it should always return T.
    
+(See Issue: CLOSED-STREAM-OPERATIONS.)
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300.htm new file mode 100644 index 00000000..0477628b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue ROOM-DEFAULT-ARGUMENT:NEW-VALUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue ROOM-DEFAULT-ARGUMENT:NEW-VALUE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue ROOM-DEFAULT-ARGUMENT:NEW-VALUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300_w.htm new file mode 100644 index 00000000..813a4ca4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss300_w.htm @@ -0,0 +1,109 @@ + + + +CLHS: Issue ROOM-DEFAULT-ARGUMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue ROOM-DEFAULT-ARGUMENT Writeup

    + +
    Issue:        ROOM-DEFAULT-ARGUMENT
    
+References:   ROOM (p442)
    
+Category:     ADDITION
    
+Edit history: 12-Sep-88, Version 1 by Pitman
    
+
    
+Problem Description:
    
+
    
+  Passing no argument to ROOM is not equivalent to any argument which
    
+  can be passed. This makes data-flow from another function which wants
    
+  to call ROOM inconvenient. Rather than simply passing a value through,
    
+  the correct calling sequence must be selected as well. For example,
    
+  one might have to do something like
    
+  (CASE FLAG
    
+    (:DEFAULT (ROOM))
    
+    ((T NIL) (ROOM FLAG)))
    
+  where (ROOM FLAG) would suffice
    
+
    
+Proposal (ROOM-DEFAULT-ARGUMENT:NEW-VALUE):
    
+
    
+  Specify that passing an argument of :DEFAULT is equivalent to passing
    
+  no argument to ROOM.
    
+
    
+Test Case:
    
+
    
+  (ROOM ':DEFAULT) is functionally equivalent to (ROOM).
    
+
    
+Rationale:
    
+
    
+  Minimal change needed to get around the stated problem.
    
+
    
+  Allows ROOM to be describable without reference to supplied-p
    
+  information.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera defines ROOM using &REST and looks for NIL, (T), or (NIL).
    
+  [This reduces its ability to do compile-time number-of-argument checking.]
    
+
    
+  Some other implementations probably have a magic undocumented value
    
+  to avoid use of a SUPPLIED-P argument.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably it involves negligible resources to change this.
    
+  In most implementations, the resulting code would probably look better.
    
+
    
+Cost to Users:
    
+
    
+  None. This change is upward compatible.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The description of ROOM will look yucky in the emerging specification.
    
+  The source code for ROOM will look yucky.
    
+  [How's that for objective? -kmp]
    
+  Error checking in some implementations may be sub-optimal.
    
+
    
+Benefits:
    
+
    
+  The description of ROOM in the now-being-written specification would
    
+  be less complicated.
    
+
    
+Aesthetics:
    
+
    
+  This proposal would make a minor improvement in aesthetics.
    
+
    
+Discussion:
    
+
    
+  This is obviously a low-priority issue, but would require such little
    
+  resources to fix that it seems worth doing.
    
+
    
+  Pitman supports this addition.
    
+
    
+  It's perhaps too bad that keywords like :SHORT, :MEDIUM, and :LONG
    
+  weren't chosen instead of T and NIL, since T and NIL have a bit of a
    
+  binary feel to them and it's hard to think of a good name for the
    
+  default case.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301.htm new file mode 100644 index 00000000..f7e34551 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SELF-MODIFYING-CODE:FORBID Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SELF-MODIFYING-CODE:FORBID Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SELF-MODIFYING-CODE:FORBID:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301_w.htm new file mode 100644 index 00000000..33ce0b87 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss301_w.htm @@ -0,0 +1,113 @@ + + + +CLHS: Issue SELF-MODIFYING-CODE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SELF-MODIFYING-CODE Writeup

    + +
    Forum:		Public Review
    
+Issue:		SELF-MODIFYING-CODE
    
+References:	Moon's public review comment #14 (X3J13/92-3214)
    
+                Section 3.2.2.1.1 (purpose of compiler macros), p 3-17
    
+                Section 3.1.2.1.2.2 (macro forms), p 3-7
    
+                Issue DEFINE-COMPILER-MACRO
    
+                Issue MACRO-CACHING
    
+Category:	CLARIFICATION/CHANGE
    
+Edit history:	21 Dec 1992, Version 1 by Loosemore
    
+		08 Jan 1993, Version 2 by Loosemore (comment from Moon)
    
+Status:         Proposal FORBID accepted 7-2-0, March 1993
    
+
    
+
    
+Problem description:
    
+
    
+  The last sentence of the second paragraph of section 3.2.2.1.1 on page
    
+  3-17 says compiler-macro expanders aren't allowed to modify the source
    
+  code.  Is there a similar restriction on normal macro expanders?  I
    
+  expect that there would be, but I couldn't find it.
    
+
    
+
    
+Proposal (SELF-MODIFYING-CODE:FORBID):
    
+
    
+  Add to section 3.1.2.1.2.2 a statement that the consequences are 
    
+  undefined if a macro function destructively modifies any part of its
    
+  form argument.
    
+
    
+
    
+Rationale:
    
+
    
+  This would make the specification more complete.
    
+
    
+
    
+Current practice:
    
+
    
+  Unknown.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  None.
    
+
    
+
    
+Cost to users:
    
+
    
+  Conceivably this proposal might cause some existing conforming programs
    
+  to become non-conforming, but we don't know of any such programs.
    
+
    
+
    
+Aesthetics:
    
+
    
+  I think everybody agrees that writing self-modifying code is a
    
+  bletcherous practice.
    
+
    
+
    
+Editorial impact:
    
+
    
+  Trivial.
    
+
    
+
    
+Discussion:
    
+
    
+  Loosemore says:
    
+   The DEFINE-COMPILER-MACRO proposal included the explicit prohibition
    
+   against modification of the form argument because of the way a
    
+   compiler macro function must return the original form to indicate it
    
+   declines to expand it.  Ordinary macros don't have to deal with this
    
+   problem, but it's generally accepted that self-modifying macros are
    
+   bad for other reasons.  The problem description section of issue
    
+   MACRO-CACHING, for example, touches upon this problem: "Caching by
    
+   displacement won't work because the same (EQ) macro call form may
    
+   appear in distinct lexical contexts.  In addition, the macro call form
    
+   may be a read-only constant."
    
+
    
+  Moon says:
    
+   I agree with SELF-MODIFYING-CODE:FORBID (Version 1).
    
+
    
+   This is consistent with the chucking-out of displacing macros from
    
+   Common Lisp.
    
+
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302.htm new file mode 100644 index 00000000..6b6331db --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue SEQUENCE-TYPE-LENGTH:MUST-MATCH Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SEQUENCE-TYPE-LENGTH:MUST-MATCH Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SEQUENCE-TYPE-LENGTH:MUST-MATCH:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302_w.htm new file mode 100644 index 00000000..e81c2711 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss302_w.htm @@ -0,0 +1,147 @@ + + + +CLHS: Issue SEQUENCE-TYPE-LENGTH Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SEQUENCE-TYPE-LENGTH Writeup

    + +
    Issue:         SEQUENCE-TYPE-LENGTH
    
+
    
+References:    CLtL p.51, p.249, p.260, p.252, p.354
    
+               CONCATENATE, COERCE, MAKE-SEQUENCE, MAP, MERGE
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  16-Jun-89, version 1, by Moon
    
+
    
+Problem description:
    
+
    
+  In several functions that take a type specifier as an argument and create
    
+  a sequence of the specified type, it isn't clear what happens if the type
    
+  specifier has an explicit length that doesn't match the length implied by
    
+  the other arguments.
    
+
    
+Proposal (SEQUENCE-TYPE-LENGTH:MUST-MATCH):
    
+
    
+  COERCE should signal an error if the new sequence type specifies the
    
+  number of elements and the old sequence has a different length.
    
+
    
+  MAKE-SEQUENCE should signal an error if the sequence type specifies the
    
+  number of elements and the size argument is different.
    
+
    
+  CONCATENATE should signal an error if the sequence type specifies the
    
+  number of elements and the sum of the argument lengths is different.
    
+
    
+  MAP should signal an error if the sequence type specifies the number of
    
+  elements and the minimum of the argument lengths is different.
    
+
    
+  MERGE should signal an error if the sequence type specifies the number of
    
+  elements and the sum of the lengths of the two sequence arguments is
    
+  different.
    
+
    
+Examples:
    
+
    
+  ;; All of the following forms should signal an error
    
+  (coerce '(a b c) '(vector * 4))
    
+  (coerce #(a b c) '(vector * 4))
    
+  (coerce '(a b c) '(vector * 2))
    
+  (coerce #(a b c) '(vector * 2))
    
+  (coerce "foo" '(string 2))
    
+  (coerce #(#\a #\b #\c) '(string 2))
    
+  (coerce '(0 1) '(simple-bit-vector 3))
    
+  (make-sequence '(vector * 2) 3)
    
+  (make-sequence '(vector * 4) 3)
    
+  (concatenate '(vector * 2) "a" "bc")
    
+  (map '(vector * 4) #'cons "abc" "de")
    
+  (merge '(vector * 4) '(1 5) '(2 4 6) #'<)
    
+
    
+Rationale:
    
+
    
+  If CLtL hadn't overlooked this situation, it's likely that it would have
    
+  said it "is an error".  The best translation of that to ANSI CL error
    
+  terminology seemed to be "should signal".  There doesn't seem to be any
    
+  reason to require signalling this error even in unsafe code.  There
    
+  doesn't seem to be any reason to define this situation to do something
    
+  other than signalling an error, such as ignoring the length in the
    
+  type specifier or forcing the sequence to have the correct length by
    
+  truncating or extending it with elements of implementation-dependent
    
+  value.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 7.2 and 7.4 usually ignore the length in the type
    
+  specifier in the above situations, but sometimes signal an error.
    
+  The type of error signalled is sometimes somewhat random.
    
+  Other implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+  This does not seem like difficult checking to add.  I have not examined
    
+  the code in any implementation to try to evaluate what it would cost.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Aesthetic.
    
+
    
+Performance impact:
    
+
    
+  Probably small, just have to keep track of the length when dealing
    
+  with sequence type specifiers in safe code.  I have not attempted to
    
+  evaluate the exact impact.
    
+
    
+Benefits:
    
+
    
+  Less ambiguity in the language specification.  Less deviation among
    
+  implementations, hence fewer porting problems.
    
+
    
+Esthetics:
    
+
    
+  Since the length field is present in sequence type specifiers, it
    
+  seems unesthetic to ignore it, and even more unesthetic not to say
    
+  what is done with it.
    
+
    
+Discussion:
    
+
    
+  Moon doesn't know what error condition is appropriate.  TYPE-ERROR
    
+  doesn't seem quite appropriate here.  One idea is not to say, just let it
    
+  be any subtype of ERROR.  Another idea is to produce the result object
    
+  and then signal a TYPE-ERROR that this object doesn't match the
    
+  type-specifier for the result type.
    
+
    
+  Cassels points out that two similar operations are defined in CLtL to be
    
+  inconsistent with each other:
    
+
    
+  (replace (make-array 4) #(1 2 3)) just picks the shortest length, and
    
+     "the extra elements near the end of the longer subsequence are not
    
+     involved in the operation" so the result is #(1 2 3 NIL)
    
+
    
+  #4(1 2 3) duplicates the last element, so it's like #(1 2 3 3)
    
+  #2(1 2 3) "is an error".
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303.htm new file mode 100644 index 00000000..f6555706 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SETF-APPLY-EXPANSION:IGNORE-EXPANDER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-APPLY-EXPANSION:IGNORE-EXPANDER Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SETF-APPLY-EXPANSION:IGNORE-EXPANDER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303_w.htm new file mode 100644 index 00000000..03cca9de --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss303_w.htm @@ -0,0 +1,69 @@ + + + +CLHS: Issue SETF-APPLY-EXPANSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-APPLY-EXPANSION Writeup

    + +
    Status:       Proposal IGNORE-EXPANDER passed 12/91
    
+Issue:        SETF-APPLY-EXPANSION
    
+Reference:    CLtL-II, p.127
    
+              Draft 10.156, p.5-10
    
+Category:     CHANGE
    
+Edit History: Version 1, 12-Dec-91, Kim Barrett
    
+
    
+Problem Description:
    
+
    
+ In Draft 10.156, the description of a call to APPLY as a place for SETF does
    
+ not include some text from CLtL.  Specifically, the draft says that for a
    
+ user-defined function,
    
+
    
+   (SETF (APPLY #'name a1 a2 ...) v1)
    
+
    
+ is equivalent to
    
+
    
+   (APPLY #'(SETF name) v1 a1 a2 ...)
    
+
    
+ except that the proper left-to-right evaluation order is maintained.  Instead
    
+ of this, CLtL talks about APPLY as a place in terms of the expander for the
    
+ function name as a place, saying that the last argument to the store form must
    
+ be the same as the last argument of the access call.
    
+
    
+Proposal (SETF-APPLY-EXPANSION:IGNORE-EXPANDER):
    
+ 
    
+ Affirm the draft text, eliminating the mechanism prescribed by CLtL for
    
+ handling APPLY as a place for SETF.
    
+
    
+Editorial impact:
    
+
    
+ None.  This affirms the wording in the draft.
    
+
    
+Rationale:
    
+
    
+ Implementation of the mechanism described in CLtL places some unmentioned
    
+ requirements on the SETF expander of functions that will be used with SETF of
    
+ APPLY.  Some people consider the whole mechanism an ugly and unreliable hack.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304.htm new file mode 100644 index 00000000..5e686900 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SETF-FIND-CLASS:ALLOW-NIL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-FIND-CLASS:ALLOW-NIL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SETF-FIND-CLASS:ALLOW-NIL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304_w.htm new file mode 100644 index 00000000..36743363 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss304_w.htm @@ -0,0 +1,100 @@ + + + +CLHS: Issue SETF-FIND-CLASS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-FIND-CLASS Writeup

    + +
    Issue:         SETF-FIND-CLASS
    
+
    
+References:    FIND-CLASS in 88-002R
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+               30-Apr-90, Version 2 by Moon (update current practice)
    
+               2-May-90, Version 3 by Moon (remove incorrect reference
    
+                     to Loosemore issue #7 of 27 Feb 90)
    
+               4-May-90, Version 4 by Moon (update discussion and current
    
+                                            practice)
    
+
    
+Problem description:
    
+
    
+  Is (SETF (FIND-CLASS 'FOO) NIL) permitted as a way to break the link from
    
+  a name to a class?  I can't find anything in the CLOS spec for or against
    
+  this.
    
+
    
+  This is Symbolics issue #27.
    
+
    
+Proposal (SETF-FIND-CLASS:ALLOW-NIL):
    
+
    
+  Define (SETF (FIND-CLASS 'FOO) NIL) to cause FOO no longer to name a class.
    
+  If FOO already does not name a class, the operation has no effect.
    
+
    
+  This does not affect the class formerly named by FOO, if any, except that
    
+  if FOO was that class's proper name, the class no longer has a proper name.
    
+
    
+Rationale:
    
+
    
+  This is simpler than putting in a new function to break the association
    
+  between a name and a class.  When CMAKUNBOUND was removed from an early
    
+  draft of 88-002R, it was probably intended to add this SETF of FIND-CLASS
    
+  feature to replace it, but the document was accidentally not updated.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera 8.0, TI Explorer release 6.0, and Lucid 4.0.0 Beta-1
    
+  implement the proposal.  Other CLOS implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+  Easy.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  There will be no portable way to break the association between a name and
    
+  a class.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Adds a useful feature that was probably intended to be there all along.
    
+
    
+Esthetics:
    
+
    
+  More complete language.
    
+
    
+Discussion:
    
+
    
+  Gregor Kiczales says he supports SETF-FIND-CLASS:ALLOW-NIL.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305.htm new file mode 100644 index 00000000..6a62dd0f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305_w.htm new file mode 100644 index 00000000..006f48cc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss305_w.htm @@ -0,0 +1,124 @@ + + + +CLHS: Issue SETF-FUNCTIONS-AGAIN Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-FUNCTIONS-AGAIN Writeup

    + +
    Issue:              SETF-FUNCTIONS-AGAIN
    
+References:         SETF, FBOUNDP, FDEFINITION, DEFSTRUCT
    
+Related issues:     Issue FUNCTION-NAME
    
+                    Issue SETF-OF-APPLY
    
+Category:           CLARIFICATION
    
+Edit history:       V1, 13 May 90, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+The addition of SETF functions to the language has left some
    
+lingering questions:
    
+
    
+- Whether (FBOUNDP '(SETF <name>)) is supposed to be true of <name>s 
    
+that have SETF methods (as defined with DEFSETF or DEFINE-SETF-METHOD)
    
+defined, or only <name>s where there are globally defined
    
+functions named (SETF <name>).  (Issue #17 from Loosemore's
    
+list.)
    
+
    
+- Whether DEFSTRUCT is required to generate SETF functions, or required
    
+to generate SETF methods, or whether this is unspecified.  (Issue
    
+#19)
    
+
    
+- Whether SETF places defined in the standard are required to be
    
+implemented by SETF functions, by SETF methods, or whether this
    
+is unspecified.  (Issue #20)
    
+
    
+- Whether it is permissible for a <name> to have both a SETF
    
+method defined via DEFSETF or DEFINE-SETF-METHOD, and an associated
    
+SETF function at the same time.  
    
+
    
+
    
+Proposal (SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES):
    
+
    
+  (1) Clarify that (FBOUNDP '(SETF <name>)) must return true if and
    
+  only if there is a function named (SETF <name>) defined.  It must
    
+  return NIL if <name> has a SETF method defined but not a SETF
    
+  function.
    
+
    
+  (2) Clarify that it is unspecified whether DEFSTRUCT generates
    
+  SETF methods or SETF functions for non-:READ-ONLY slot accessors.
    
+
    
+  (3) Clarify that, unless a SETF function is explicitly documented
    
+  in the standard, it is unspecified whether SETF places defined in
    
+  the standard must be implemented as SETF methods or SETF functions.
    
+  In combination with item (1), this implies that it is unspecified
    
+  whether (SETF <name>) is FBOUNDP for these standard SETF
    
+  places.
    
+
    
+  (4) Clarify that it is possible, but generally not very useful, 
    
+  to have both a SETF method and a SETF function defined for the same
    
+  name.
    
+
    
+Rationale:
    
+
    
+  This proposal requires minimal changes for implementors.
    
+
    
+Current Practice:
    
+
    
+  Most implementations use SETF methods (and not SETF functions)
    
+  to implement DEFSTRUCT accessors and the standard SETF places.
    
+  In most implementations, the namespaces for SETF methods and
    
+  SETF functions are disjoint.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably none.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.
    
+
    
+Cost of non-adoption:
    
+
    
+  Imprecision in the language specification.
    
+
    
+Performance impact:
    
+
    
+  Probably not significant.
    
+
    
+Benefits:
    
+
    
+   The language specification is made more precise.
    
+
    
+Esthetics:
    
+
    
+  It would probably be better to specify whether standard SETF
    
+  places must be implemented as SETF functions or as SETF
    
+  methods, instead of leaving it explicitly vague.  See also
    
+  issue SETF-OF-APPLY for one particular case (AREF) where it
    
+  seems like a good idea to specify that the SETF place must be
    
+  implemented as a SETF function.
    
+
    
+Discussion:
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306.htm new file mode 100644 index 00000000..d3402315 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306_w.htm new file mode 100644 index 00000000..49ecbe0e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss306_w.htm @@ -0,0 +1,152 @@ + + + +CLHS: Issue SETF-GET-DEFAULT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-GET-DEFAULT Writeup

    + +
    Issue:             SETF-GET-DEFAULT
    
+References:        SETF of GET (CLtL-II p. 240)
    
+                   SETF of GETF (CLtL-II p. 242)
    
+                   SETF of GETHASH (CLtL-II p. 438)
    
+Related issues:    Issue PUSHNEW-STORE-REQUIRED
    
+Category:          CLARIFICATION
    
+Edit history:      V1, 12 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  In the descriptions of SETF of GET, GETF, and GETHASH, it is stated
    
+  that the optional default argument is ignored by SETF.  It is not
    
+  clear whether this means that the *subform* corresponding to the
    
+  default argument that is ignored, or only the *result* of evaluating
    
+  the subform.  The behavior is distinguishable in situations where the
    
+  subform has observable side-effects.
    
+
    
+
    
+Proposal (SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED):
    
+
    
+  Clarify that if the optional "default" argument is supplied in a call
    
+  to GET, GETF, or GETHASH appearing as a SETF place, that subform
    
+  is evaluated according to the normal left-to-right evaluation rules for
    
+  subforms of a SETF place.  However, its value is ignored.
    
+
    
+
    
+Examples:
    
+
    
+  #1: (setf (get 'foo 'message (print "hello world"))
    
+            "goodbye, cruel world")
    
+      => prints "hello world"
    
+  
    
+  #2: (let ((x  nil))
    
+        (setf (getf x 'message (print "hello world"))
    
+              "goodbye, cruel world"))
    
+      => prints "hello world"
    
+  
    
+  #3: (let ((x  (make-hash-table :test #'eq)))
    
+        (setf (gethash 'message x (print "hello world"))
    
+              "goodbye, cruel world"))
    
+      => prints "hello world"
    
+
    
+
    
+Rationale:
    
+
    
+  Discarding the form corresponding to the default argument would be
    
+  inconsistent with the rule that subforms of a SETF place are
    
+  evaluated in left-to-right order.
    
+
    
+Current Practice:
    
+
    
+  Lucid version 4.0 does tests 1 and 3 correctly but fails on test 2.
    
+  Allegro version 3.1 performs all three tests correctly.
    
+  Symbolics Genera reportedly fails at least test 2.
    
+
    
+Cost to Implementors:
    
+
    
+  Minor.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Implementations will continue to differ for no good reason.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  The language specification is made more precise and consistent.
    
+
    
+Esthetics:
    
+
    
+  Making the language more consistent is a good thing.
    
+
    
+Discussion:
    
+
    
+  Kent Pitman notes:
    
+
    
+    Btw, someone (I think it was Allan Wechsler at Symbolics), that it
    
+    should be permissible for:
    
+    
    
+     (LET ((X '(A 1 B 2)))
    
+       (SETF (GETF X 'C 3) 3)
    
+       X)
    
+     => (A 1 B 2)
    
+    
    
+    because what the SETF -really- says is to make sure that (GETF X 'C 3)
    
+    will later return 3, which that value of X does.  As such, I don't
    
+    even think the code should be ignored.  I would prefer this
    
+    interpretation if we could get consensus, and would appreciate your
    
+    listing it as an option in your writeup, with me favoring it.  Two
    
+    pieces of rationale you might add to the writeup are that (a) this
    
+    permits an application to be more space-conservative and (b) this
    
+    permits an application to not gratuitously modify pages of data that
    
+    don't really need to be modified, and hence may sometimes result in
    
+    smaller dumps or smaller working sets in some implementations that
    
+    either permit dumping an incremental image containing only the
    
+    modified pages, or that have an initial data set of copy-on-modify
    
+    pages.
    
+    
    
+    As a fall-back, I think your clarification would be an improvement
    
+    over the status quo.  But I think it's not as elegant.
    
+
    
+  Sandra Loosemore says:
    
+
    
+    I think we'd need to spec this out very carefully.  Should this 
    
+    behavior be required or simply permitted?  Does an explicit default 
    
+    of NIL do the same thing as no default?  Does only SETF of GETF 
    
+    behave this way, or should we generalize this to require/permit 
    
+    *any* SETF place not to actually update the place unnecessarily?
    
+    In the general case, what predicate would be used to compare the 
    
+    new value to the value that would be returned by the accessor?  
    
+    While I agree this is an attractive idea on the surface, the more I 
    
+    think about these questions, the more I become convinced that this 
    
+    is an incompatible change and probably not a good idea overall.
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307.htm new file mode 100644 index 00000000..5a8ee42e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SETF-MACRO-EXPANSION:LAST Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-MACRO-EXPANSION:LAST Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SETF-MACRO-EXPANSION:LAST:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307_w.htm new file mode 100644 index 00000000..7fa895a2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss307_w.htm @@ -0,0 +1,126 @@ + + + +CLHS: Issue SETF-MACRO-EXPANSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-MACRO-EXPANSION Writeup

    + +
    Issue:         SETF-MACRO-EXPANSION
    
+
    
+References:    DEFSETF, DEFINE-SETF-METHOD, SETF
    
+	       CLtL pages 97, 102, 105
    
+               ANSI CL spec 6-162 (Sep 89 version)
    
+
    
+Related issues: FUNCTION-NAME:LARGE
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+
    
+Problem description:
    
+  
    
+  CLtL is inconsistent because pages 102 and 105 say DEFSETF and
    
+  DEFINE-SETF-METHOD can be used with a function or a macro, while page 97
    
+  says that SETF expands macros before it looks for setf-methods.
    
+  
    
+  This is Symbolics issue #9.
    
+
    
+Proposal (SETF-MACRO-EXPANSION:LAST):
    
+  
    
+  Clarify that SETF (actually GET-SETF-METHOD-MULTIPLE-VALUE) only expands
    
+  macros after exhausting all other possibilities other than expanding into
    
+  a call to a function named (SETF reader).  Clarify that it expands macros
    
+  in the style of MACROEXPAND-1 rather than MACROEXPAND (this was point 11
    
+  of FUNCTION-NAME:LARGE and is repeated here for clarity only).
    
+
    
+Examples:
    
+
    
+  (defvar *foo-trace* nil)
    
+  
    
+  (defmacro foo (x y) `(aref ,x ,y))
    
+
    
+  (defun (setf foo) (z x y)	;wrong
    
+    (push `(,x ,y ,z) *foo-trace*)
    
+    (setf (aref x y) z))
    
+
    
+  (defsetf foo (x y) (z)	;right
    
+    `(progn
    
+       (push `(,,x ,,y ,,z) *foo-trace*)
    
+       (setf (aref ,x ,y) ,z)))
    
+
    
+  (macroexpand-1 '(setf (foo array i) (val)))
    
+
    
+  The last form should include a push onto *foo-trace*, rather than
    
+  first macroexpanding (foo array i) into (aref array i) and then
    
+  setf'ing that.
    
+
    
+  The defun form has no effect because SETF expands macros before expanding
    
+  into a call to such a function, so this function will not be used.
    
+
    
+Rationale:
    
+
    
+  In the absence of this clarification, the language specification is not
    
+  self-consistent.  The example given above will not work in implementations
    
+  that chose to believe CLtL page 97 rather than page 102.
    
+
    
+  The rationale for FUNCTION-NAME:LARGE point 11 suggests that we thought
    
+  we had exchanged the two bullets on page 97, so that SETF looks for setf
    
+  methods before it expands macros.  However there doesn't seem to be any
    
+  cleanup issue that explicitly addresses this.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera looks for setf methods before expanding macros, I didn't
    
+  check any other implementations.
    
+
    
+Cost to Implementors:
    
+
    
+  Trivial.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  The Common Lisp language will be a joke.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Consistency.
    
+
    
+Esthetics:
    
+
    
+  Consistency.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308.htm new file mode 100644 index 00000000..5116b617 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308.htm @@ -0,0 +1,51 @@ + + + +CLHS: Issue SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308_w.htm new file mode 100644 index 00000000..91e4cee9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss308_w.htm @@ -0,0 +1,174 @@ + + + +CLHS: Issue SETF-METHOD-VS-SETF-METHOD Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-METHOD-VS-SETF-METHOD Writeup

    + +
    Issue:        SETF-METHOD-VS-SETF-METHOD
    
+Forum:	      Editorial
    
+References:   DEFINE-SETF-METHOD (CLtL, p106),
    
+	      GET-SETF-METHOD (CLtL, p106),
    
+	      GET-SETF-METHOD-MULTIPLE-VALUE (CLtL, p107),
    
+	      "setf method" (27.1 Glossary, page 27-27, Draft 8.81)
    
+Category:     CHANGE
    
+Edit history: 08-Mar-91, Version 1 by Pitman
    
+	      15-Mar-91, Version 2 by Pitman (merge much discussion)
    
+	      08-Apr-91, Version 3 by Pitman
    
+		(GET-SETF-EXPANDER => GET-SETF-EXPANSION, per X3J13)
    
+Status:	      X3J13 passed option RENAME-OLD-TERMS on 10-3 vote, March 1991.
    
+	        (Note that option +ADD-ACCESSOR was not voted upon,
    
+	         and so it is not in effect.)
    
+
    
+Problem Description:
    
+
    
+  The terms "@bold(setf) @italic(method)" and "@italic(setf method)"
    
+  mean two different things.  The former means a CLOS method defined
    
+  using DEFMETHOD, which among other things might be used by SETF.
    
+  The latter means a macro-like entity defined by DEFSETF or 
    
+  DEFINE-SETF-METHOD, data about which can be retrieved by
    
+  GET-SETF-METHOD[-MULTIPLE-VALUE].
    
+
    
+  Verbal confusion will almost surely result from the similarity of
    
+  these two terms.
    
+
    
+  Visual confusion will almost surely result if people don't happen to
    
+  notice the font, or to realize the important distinction which it 
    
+  seeks to make.
    
+
    
+Proposal (SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS):
    
+
    
+  Rename DEFINE-SETF-METHOD to DEFINE-SETF-EXPANDER.
    
+  Remove GET-SETF-METHOD.
    
+  Rename GET-SETF-METHOD-MULTIPLE-VALUE to GET-SETF-EXPANSION.
    
+
    
+  Rename the glossary term "setf method" to "setf expander".
    
+  That is, a "setf expander" is a function which tells how to
    
+  store into a generalized reference.
    
+
    
+  Create a glossary term "setf expansion" to refer to the five
    
+  magic values returned by a "setf expander".
    
+
    
+  Clarify that the glossary term "setf method" is to be synonymous
    
+  with "SETF method" That is, a "setf method" is a CLOS method 
    
+  named (SETF <something>).
    
+
    
+  Rationale:
    
+  
    
+    Avoids massive terminological confusion.
    
+  
    
+    Simplifies the language by promoting GET-SETF-METHOD-MULITPLE-VALUE,
    
+    the general purpose routine, into active duty and removing its
    
+    simpleton pal GET-SETF-METHOD.
    
+
    
+Proposal (SETF-METHOD-VS-SETF-METHOD:+ADD-ACCESSOR):
    
+
    
+  Add a new function:
    
+
    
+   SETF-EXPANDER-FUNCTION name &OPTIONAL environment            [Function]
    
+ 
    
+   If <name> has a SETF expander function (defined with DEFSETF or 
    
+   DEFINE-SETF-METHOD), and the global functional binding of <name> is
    
+   not lexically shadowed within the <environment>, 
    
+   SETF-EXPANDER-FUNCTION returns that function.  Otherwise NIL is 
    
+   returned.
    
+ 
    
+   A SETF expander function is a function which accepts two arguments, 
    
+   the "place" form and an environment, and returns the five values 
    
+   representing the SETF expansion for that "place".
    
+ 
    
+   SETF may be used with SETF-EXPANDER-FUNCTION.  The value must either
    
+   be a SETF expander function or NIL (which removes any existing SETF
    
+   expander function associated with the <name>).  [The consequences of
    
+   supplying an environment other than NIL when using SETF of 
    
+   SETF-EXPANDER-FUNCTION are not defined.]
    
+
    
+  Rationale:
    
+
    
+    This is symmetric with having MACRO-FUNCTION and 
    
+    COMPILER-MACRO-FUNCTION.
    
+
    
+Current Practice:
    
+
    
+  Presumably no one already does this.
    
+
    
+Cost to Implementors:
    
+
    
+  RENAME-OLD-TERMS:  Small.  Trivial renaming of functions.  
    
+    Old names can be retained as an extension for compatibility
    
+    if necessary to ease transition.
    
+
    
+  +ADD-ACCESSOR:  Probably small.  Implementations have to represent
    
+    this information somehow already, so this just provides access to
    
+    what is already there.
    
+
    
+Cost to Users:
    
+
    
+  RENAME-OLD-TERMS:
    
+   Small.  It's clearly incompatible, but hopefully the motivation is strong
    
+   enough that users will realize that the change is needed.  A simple
    
+   find-and-replace operation is likely to fix these, or compatibility names
    
+   can be trivially established locally by users for code that can't easily 
    
+   be changed in implementations that don't already provide the compatibility
    
+   support for old names.
    
+
    
+  +ADD-ACCESSOR: None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Risk of a `fonto' in the spec causing major havoc.
    
+  Risk of implementors getting confused.
    
+  Risk of confusing new users.
    
+  Either some places in the spec could be harder to word unambiguously,
    
+   or else glossary terms might have to be chosen which do not match
    
+   function names in the language itself.
    
+
    
+Benefits:
    
+
    
+  Much easier to have casual verbal discussions.
    
+
    
+Aesthetics:
    
+
    
+  RENAME-OLD-TERMS: Major improvement in aesthetics.
    
+
    
+  +ADD-ACCESSOR: Language is slightly more uniform.
    
+
    
+Discussion:
    
+
    
+  Pitman supports this proposal but is not fussy about the specific
    
+  term that's used as long as it's not the status quo (`method').
    
+
    
+  The terms "strategy", "technique", "macroexpander", "macro expander",
    
+  "expander", and "transformer" were discussed after v1. Eric Benson, 
    
+  JonL, Sandra, and Pitman all seemed happy with "expander", so it 
    
+  v2 was changed to use that.
    
+
    
+  There was also support (from Moon and Sandra) for merging 
    
+  GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE back into one,
    
+  so v2 added that as well.
    
+
    
+  Sandra asked for SETF-EXPANDER-FUNCTION.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309.htm new file mode 100644 index 00000000..372b8cb7 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue SETF-MULTIPLE-STORE-VARIABLES:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-MULTIPLE-STORE-VARIABLES:ALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SETF-MULTIPLE-STORE-VARIABLES:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309_w.htm new file mode 100644 index 00000000..0d9b6a35 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss309_w.htm @@ -0,0 +1,180 @@ + + + +CLHS: Issue SETF-MULTIPLE-STORE-VARIABLES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-MULTIPLE-STORE-VARIABLES Writeup

    + +
    Issue:         SETF-MULTIPLE-STORE-VARIABLES
    
+
    
+References:    CLtL, pp.93-107
    
+               Lisp Pointers, v2n2, pp.27-41
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1,  5-Dec-88, Pavel
    
+               Version 2, 22-Mar-89, Moon, simplify, update from discussion
    
+
    
+Problem description:
    
+  
    
+  The description of GET-SETF-METHOD-MULTIPLE-VALUE on page 107 of CLtL
    
+  states that there are no cases in Common Lisp that allow multiple values
    
+  to be stored into a generalized variable.  This is seen by some as an
    
+  arbitrary decision in light of the fact that a very reasonable semantics
    
+  exists for multiple values being assigned by several Common Lisp macros,
    
+  including SETF.  The rationale on page 103 of CLtL suggests that this
    
+  decision might be changed in the future.
    
+
    
+Proposal (SETF-MULTIPLE-STORE-VARIABLES:ALLOW):
    
+
    
+  Extend the semantics of the macros SETF, PSETF, SHIFTF, ROTATEF, and
    
+  ASSERT to allow "places" whose SETF methods have more than one "store
    
+  variable".  In such cases, the macros accept as many values from the
    
+  newvalue form as there are store variables.  As usual, extra values
    
+  are ignored and missing values default to NIL.
    
+
    
+  Extend the long form of DEFSETF to allow the specification of more
    
+  than one "store variable", with the obvious semantics.
    
+
    
+  Clarify that GET-SETF-METHOD signals an error if there would be more
    
+  than one store-variable.
    
+
    
+Test Cases/Examples:
    
+  
    
+  (defstruct region width height)
    
+  
    
+  (defun region-size (region)
    
+     (values
    
+        (region-width region)
    
+        (region-height region)))
    
+  
    
+  (defsetf region-size (region) (width height)
    
+     `(values
    
+         (setf (region-width ,region) ,width)
    
+         (setf (region-height ,region) ,height)))
    
+  
    
+  (setf my-reg (make-region :width 10 :height 20))
    
+  => #S(REGION :WIDTH 10 :HEIGHT 20)
    
+  
    
+  (region-size my-reg)
    
+  => 10
    
+     20
    
+  
    
+  (setf (region-size my-reg) (values 30 40))
    
+  => 30
    
+     40
    
+  
    
+  (region-size my-reg)
    
+  => 30
    
+     40        
    
+
    
+Rationale:
    
+  
    
+  This change removes an artificial restriction on the semantics of
    
+  several Common Lisp macros, allowing a broader set of contexts in
    
+  which generalized variables can be used.  For example, it is not
    
+  difficult to write a reasonable SETF method for the VALUES function,
    
+  yielding a powerful MULTIPLE-VALUE-SETF form:
    
+
    
+        (setf (values (car a) (gethash b 'c) (aref d 13))
    
+              (some-hairy-computation))
    
+
    
+  In the language as currently defined, this example would have to be
    
+  written:
    
+
    
+        (multiple-value-bind (x y z)
    
+                             (some-hairy-computation)
    
+           (setf (car a)        x
    
+                 (gethash b 'c) y
    
+                 (aref d 13)    z))
    
+
    
+  Many other (perhaps more compelling) examples of generalized variables
    
+  holding more than one value can easily be imagined.  Their use,
    
+  however, is severely discouraged by Common Lisp as defined in CLtL,
    
+  since none of the built-in macros will accept them.
    
+
    
+  The clarification of GET-SETF-METHOD makes explicit what is implied
    
+  by CLtL (CLtL uses the word "guarantee", whose relationship to
    
+  signalling of errors is unclear).
    
+
    
+Current practice:
    
+
    
+  I do not know of any implementations that allow all of this extension.
    
+  Xerox Lisp does not signal an error, but this is probably due to a bug
    
+  in GET-SETF-METHOD.  Lucid signals an error in GET-SETF-METHOD.
    
+  Symbolics Genera supports the proposal in SETF and PSETF, but not in
    
+  SHIFTF, ROTATEF, and ASSERT.
    
+
    
+Cost to Implementors:
    
+
    
+  A relatively minor fix to each of the affected macros suffices.  For
    
+  example, to fix SETF itself, one need only call
    
+  GET-SETF-METHOD-MULTIPLE-VALUE instead of GET-SETF-METHOD and emit a
    
+  MULTIPLE-VALUE-BIND instead of a LET for binding the store variables.
    
+
    
+Cost to Users:
    
+
    
+  This is an upward-compatible change; no user code must change.
    
+
    
+Cost of non-adoption:
    
+
    
+  Yet another non-uniformity in the language, yet another piece of
    
+  mechanism without a clear use (GET-SETF-METHOD-MULTIPLE-VALUE).
    
+
    
+Benefits:
    
+
    
+  Wider applicability of a reasonably nice abstraction, the removal of
    
+  an artificial prohibition.
    
+
    
+Aesthetics:
    
+
    
+  People may disagree about whether this is a simplification or not.  I
    
+  am firmly on the side that believes that such removal of
    
+  non-uniformities is a simplifying force in the language.
    
+
    
+Discussion:
    
+
    
+  Pavel supports this proposal.
    
+
    
+  Moon supports this proposal except he is not sure about the
    
+  inclusion of ASSERT.
    
+
    
+  GSB suggests that this is a clarification rather than an addition,
    
+  because the lack of any predefined setf-methods that use multiple
    
+  store variables should not mean that SETF, etc. should not work with
    
+  such a setf-method if the user defined one.  The problem is that CLtL
    
+  examples such as the ones for SHIFTF on p.98 and the simplified
    
+  definition for SETF on p.107 contradict this proposal, and might have
    
+  been taken as specifications, rather than simplified examples, by
    
+  some readers.
    
+
    
+  Predefined SETF methods for such functions as VALUES, CONS, and VECTOR
    
+  could have been proposed, but we refrained.  This proposal is necessary
    
+  to allow the user to write such methods for himself, but if this
    
+  proposal is adopted those setf-methods are very easy to write in
    
+  a portable fashion.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310.htm new file mode 100644 index 00000000..f821a9d8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310_w.htm new file mode 100644 index 00000000..6fb18690 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss310_w.htm @@ -0,0 +1,124 @@ + + + +CLHS: Issue SETF-OF-APPLY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-OF-APPLY Writeup

    + +
    Issue:               SETF-OF-APPLY
    
+References:          SETF
    
+Related issues:      SETF-FUNCTIONS-AGAIN
    
+Category:            CLARIFICATION
    
+Edit history:        V1, 10 May 90, Sandra Loosemore
    
+                     V2, 29 May 90, Sandra Loosemore (forgot BIT & SBIT)
    
+
    
+
    
+Problem description:
    
+
    
+CLtL requires that (SETF (APPLY #'foo ...)) can be used only for
    
+places "foo" whose SETF expansion is implemented in such a way that
    
+the last subform of the accessing form appears as the last
    
+argument of the storing call.  The discussion and example imply that
    
+the SETF method for AREF is required to implemented in this way.  Are 
    
+there any other SETF places defined in the standard that are
    
+required to be usable with APPLY?
    
+
    
+This is Loosemore's issue #28.
    
+
    
+Proposal (SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS):
    
+
    
+  Require that (SETF (APPLY #'<place> ...) ...) work for the standard
    
+  <place>s AREF, BIT, and SBIT, but document that the consequences of
    
+  using any of the other standard SETF <place>s with APPLY are
    
+  undefined.  
    
+
    
+  This proposal does not change the behavior of (SETF (APPLY ...)) 
    
+  with user-defined SETF methods; any SETF methods that are defined 
    
+  by the user in such a way that the last subform of the accessing 
    
+  form appears as the last argument of the storing call continue
    
+  to work with SETF of APPLY.
    
+
    
+Rationale:
    
+
    
+  Of all the standard SETF places, AREF, BIT, and SBIT appear to be 
    
+  the only functions that are defined with &REST arguments and where 
    
+  one might have a real need to use them with APPLY.  Not requiring 
    
+  (SETF (APPLY #'AREF ...) ...) to work might be seen as an
    
+  incompatible change to the language since CLtL implies that it
    
+  is legitimate.  BIT and SBIT are very similar to AREF.  Requiring 
    
+  other SETF places to work with APPLY might be seen as putting 
    
+  unnecessary restrictions on implementors.
    
+
    
+Current Practice:
    
+
    
+   Unknown.
    
+
    
+Cost to Implementors:
    
+
    
+   Probably small.  At most, you'd have to provide a new
    
+   definition for the SETF method for AREF and friends, or write some
    
+   special-case handling for these places in the SETF method for APPLY.
    
+
    
+Cost to Users:
    
+
    
+   Probably none.  Any programs that rely on using SETF of APPLY
    
+   with other standard SETF places are almost certainly
    
+   nonportable anyway.
    
+
    
+Cost of non-adoption:
    
+
    
+   The language specification is unclear on this point.
    
+
    
+Performance impact:
    
+
    
+   Probably none.
    
+
    
+Benefits:
    
+
    
+   The language specification is made more clear.
    
+  
    
+Esthetics:
    
+
    
+   Ugly.
    
+
    
+Discussion:
    
+
    
+Loosemore isn't really satisfied with proposal ONLY-AREF-AND-FRIENDS.
    
+It is probably closest to the status quo, but it seems like an overly
    
+complicated and messy way of dealing with a few special cases.
    
+
    
+From a purely esthetic point of view, it would be much cleaner
    
+to require that the SETF method for AREF be implemented by a 
    
+function (SETF AREF) and then either remove the SETF-of-APPLY
    
+feature completely or redefine it so that
    
+    (SETF (APPLY #'<name> . <args>) <value>)
    
+is equivalent to
    
+    (APPLY #'(SETF <name>) <value> . <args>)
    
+except for preserving the left-to-right order of evaluation of
    
+the original call.  This kind of change might be seen as too much
    
+of a restriction on implementors and too major to be considered
    
+at this point, however.  See issue SETF-FUNCTIONS-AGAIN.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311.htm new file mode 100644 index 00000000..9868d75c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue SETF-OF-VALUES:ADD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-OF-VALUES:ADD Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SETF-OF-VALUES:ADD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311_w.htm new file mode 100644 index 00000000..de8288d5 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss311_w.htm @@ -0,0 +1,150 @@ + + + +CLHS: Issue SETF-OF-VALUES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-OF-VALUES Writeup

    + +
    Issue:             SETF-OF-VALUES
    
+References:        SETF, GET-SETF-METHOD-MULTIPLE-VALUE
    
+Related issues:    SETF-MULTIPLE-STORE-VARIABLES
    
+                   LISP-SYMBOL-REDEFINITION
    
+                   PACKAGE-CLUTTER
    
+                   MULTIPLE-VALUE-SETQ-ORDER
    
+Category:          ADDITION, CHANGE
    
+Edit history:      v1, 12 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  The writeup for issue SETF-MULTIPLE-STORE-VARIABLES indicates that
    
+  adding support for multiple store variables makes it easy to write
    
+  a SETF method for the VALUES function, yielding a powerful
    
+  MULTIPLE-VALUE-SETF-like form.  The proposal didn't actually
    
+  define VALUES as a SETF place on the rationale that this could be
    
+  easily done by users in a portable fashion; however, issue
    
+  issue LISP-SYMBOL-REDEFINITION prohibits users from defining a SETF 
    
+  method for VALUES or any other symbol that is exported from the
    
+  COMMON-LISP package.  (Issue PACKAGE-CLUTTER does not prohibit
    
+  implementations from defining VALUES as a SETF place as an extension,
    
+  though.)
    
+
    
+  There are two proposals, ADD and REMOVE-PROHIBITION.  The two proposals
    
+  are not mutually exclusive.
    
+
    
+
    
+Proposal (SETF-OF-VALUES:ADD):
    
+  
    
+  Define VALUES as a SETF place in the standard.
    
+
    
+  For a form such as
    
+
    
+  (setf (values <place1> .... <placen>) <value-producing-form>)
    
+
    
+  the setf methods for each of the nested <placei> are obtained as if by
    
+  GET-SETF-METHOD-MULTIPLE-VALUE.  The order of evaluation is as follows:
    
+
    
+  (1) subforms of the nested <placei> are evaluated in left-to-right order.
    
+  (2) The <value-producing-form> is evaluated, and the first store variable
    
+      from each <placei> bound to the values as by MULTIPLE-VALUE-BIND.
    
+      If the setf method for a nested <placei> involves more than one store
    
+      variable, then the additional store variables are bound to NIL.
    
+  (3) Finally the storing forms for the nested <placei> are evaluated in
    
+      left-to-right order.
    
+
    
+  Note that (as required by CLtL), the storing form for SETF of VALUES
    
+  returns the values of the store variables as its values.  (This might
    
+  be more or fewer values than what the <value-producing-form> returns.)
    
+
    
+  Rationale for proposal ADD:
    
+
    
+    SETF of VALUES is a powerful feature.  Even if it were made possible to
    
+    define it portably, it is useful enough to warrant being included as
    
+    a standard, built-in part of the language.  Standardizing this feature
    
+    will prevent problems with a proliferation of similar features that all
    
+    have slightly different names or semantics.
    
+
    
+
    
+Proposal (SETF-OF-VALUES:REMOVE-PROHIBITION):
    
+
    
+  Permit users to define SETF methods and/or SETF functions for places 
    
+  whose names are external symbols in the COMMON-LISP package, provided 
    
+  that the standard does not already define the symbol as a name of a 
    
+  SETF place.
    
+
    
+  Rationale for proposal REMOVE-PROHIBITION:
    
+
    
+    There are other potential SETF places besides VALUES that a user might
    
+    conceivably wish to define SETF methods for, that are named by external
    
+    symbols in the COMMON-LISP package.  The writeup for issue 
    
+    SETF-MULTIPLE-STORE-VALUES suggested CONS and VECTOR, for example.
    
+  
    
+
    
+Examples:
    
+
    
+Current Practice:
    
+
    
+  Chestnut's Lisp-to-C translator implements proposal ADD.
    
+
    
+Cost to Implementors:
    
+
    
+  For proposal ADD, the SETF method for VALUES will need to be written.
    
+
    
+  For proposal REMOVE-PROHIBITION, implementors will have to be careful
    
+  about defining additional SETF places on symbols exported from the
    
+  COMMON-LISP package, since those definitions might be overridden by
    
+  user-supplied definitions.
    
+
    
+Cost to Users:
    
+
    
+  None.  This is an upward-compatible extension.
    
+
    
+Cost of non-adoption:
    
+
    
+  Users are prohibited from doing something useful for no good reason.
    
+
    
+Performance impact:
    
+
    
+  Probably none.
    
+
    
+Benefits:
    
+
    
+  The costs of non-adoption are avoided.
    
+
    
+Esthetics:
    
+
    
+  It looks OK to me.
    
+
    
+Discussion:
    
+
    
+  CLtL-II notes that a proposal to add VALUES as a SETF place was 
    
+  submitted in September 89, but I can find no record of it in the
    
+  minutes from either the November 89 or June 90 meetings.
    
+
    
+  I have no idea what the semantics of a SETF method on CONS or VECTOR
    
+  might be.
    
+
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312.htm new file mode 100644 index 00000000..2e5aeef0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SETF-SUB-METHODS:DELAYED-ACCESS-STORES Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SETF-SUB-METHODS:DELAYED-ACCESS-STORES Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SETF-SUB-METHODS:DELAYED-ACCESS-STORES:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312_w.htm new file mode 100644 index 00000000..8f91317b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss312_w.htm @@ -0,0 +1,407 @@ + + + +CLHS: Issue SETF-SUB-METHODS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SETF-SUB-METHODS Writeup

    + +
    Issue: 		SETF-SUB-METHODS
    
+
    
+References: 	CLtL pp. 95-96, 99, 105-106, 166
    
+		Issue: PUSH-EVALUATION-ORDER
    
+
    
+Category: 	CLARIFICATION
    
+
    
+Edit history:  Version 1: JonL White & Ken D. Olum 12-Feb-88
    
+		(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
    
+               Version 2: JonL White 23-May-88 (fix references and spellings).
    
+               Version 3: JonL White 25-May-88 
    
+               Version 4: JonL White & Ken D. Olum 26-May-88 (final insights!)
    
+	       Version 5: Masinter (respond to comments)
    
+
    
+
    
+Problem description:
    
+
    
+Implementations differ in the left-to-right order
    
+of evaluation in the following form:
    
+
    
+     (setq r '(a 1 b 2 c 3))
    
+     (setq s r)
    
+     (setf (getf r 'b) (progn (setq r nil) 6))
    
+
    
+In some implementations, the side-effect of the setq appears to happen before
    
+the evaluation of the place form (getf r 'b) which is necessary to fetch the 
    
+list being updated.   A typical result is 'r' = (B 6), 's' = (A 1 B 2 C 3)
    
+after the operation. 
    
+
    
+There is a similar problem with SETF's over LDB, MASK-FIELD, and CHAR-BIT.
    
+
    
+CLtL p99 is explicit about left-to-right order of evaluation.
    
+However, the specification is less clear about computations involved
    
+in "evaluation" of the subforms, and other computations that are implicit
    
+in the notion of "doing an access" or "doing a store".
    
+
    
+Proposal:	SETF-SUB-METHODS:DELAYED-ACCESS-STORES
    
+
    
+This proposal specifies more explicilty the behavior of SETF in the case  
    
+of access forms whose sub-forms are permitted to be generalized variable 
    
+references [and which thus need to call GET-SETF-METHOD during setf macro 
    
+expansion].
    
+
    
+Remember, first, that GET-SETF-METHOD returns the following:
    
+
    
+   -- Some temporary variables
    
+   -- A list of value-producing forms
    
+   -- A list of store-variables (normally one).
    
+   -- A storing form.
    
+   -- An accessing form.
    
+
    
+The code produced as the macro expansion of a SETF form that
    
+itself admits a generalized variable as an argument must essentially
    
+do the following major steps:
    
+
    
+  ** It evaluates the value-producing sub-forms, in left-to-right order, and 
    
+     binds the temporary variables to them.  This will be called "binding the 
    
+     temporaries."
    
+
    
+  ** It "reads the value" from the generalized variable using the supplied 
    
+     accessing form, to get the "old value";  this will be called "doing the
    
+     access."  [Note that this is done after all the evaluations of the 
    
+     preceeding step, including any side-effects they may have.]
    
+
    
+  ** It binds the store-variable to a new value, and then installs this
    
+     new value into the generalized variable using the supplied "storing 
    
+     form".   This will be called "doing the store."
    
+
    
+"Reading the value" of a generalized variable reference is not part of
    
+the series of evaluations  that must be done in left-to-right order. 
    
+
    
+The place-specifier forms listed at the top of CLtL p96 permit admit (other)
    
+place-specifiers as arguments; during the SETF expansion of these forms, it 
    
+is necessary to call GET-SETF-METHOD in order to figure out how the inner, 
    
+nested generalized variable must be treated.  This proposal requires GETF be 
    
+listed among these forms, since it must have a sub-recursive <place> specifier 
    
+[however, there is no Common Lisp function serving as a pseudo-update function
    
+for it, the way DPB serves for LDB].  
    
+
    
+For each place-specifier form with a sub-recursive place specifier, 
    
+ the information from GET-SETF-METHOD is used as follows.
    
+
    
+  CHAR-BIT:
    
+
    
+    In a form such as:
    
+
    
+        (SETF (CHAR-BIT <place-form> <bit-name>) <value-form>)
    
+
    
+    the place referred to by the <place-form> must always be both accessed 
    
+    and updated; note that the update is to the generalized variable 
    
+    specified by <place-form> -- not to a character object itself.
    
+
    
+    Thus this SETF should generate code to do the following:
    
+
    
+    1. Bind the temporaries for <place-form>
    
+    2. Evaluate <bit-name> (and bind into a temporary)
    
+    3. Evaluate <value-form> (and bind into the store variable)
    
+    4. Do the access to <place-form>
    
+    5. Do the store into <place-form>, with the given bit-name of the 
    
+       character fetched in step 4 changed to reflect the value from step 3.
    
+
    
+    If the evaluation of <value-form> in step 3 alters what is found in the 
    
+    given "place" -- such as setting a different "bit" of the character --
    
+    then the change of the bit denoted by <bit-name> will be to that altered
    
+    character, because the "access" step is done after the <value-form>
    
+    evaluation.  See example 1 in the test cases section.  Nevertheless, the 
    
+    evaluations required for binding the temporaries are done in steps 1 and 
    
+    2, and thus the expected left-to-right evaluation order is seen.
    
+
    
+
    
+  LDB: 
    
+
    
+    In a form such as:
    
+
    
+        (SETF (LDB <byte-spec> <place-form>) <value-form>)
    
+
    
+    the place referred to by the <place-form> must always be both accessed 
    
+    and updated;  note that the update is to the generalized variable 
    
+    specified by <place-form> -- not to any object of type integer.
    
+
    
+    Thus this SETF should generate code to do the following:
    
+
    
+    1. Evaluate <byte-spec> (and bind into a temporary)
    
+    2. Bind the temporaries for <place-form>
    
+    3. Evaluate <value-form>  (and bind into the store variable)
    
+    4. Do the access to <place-form>
    
+    5. Do the store into <place-form> with the given bit-field of the integer
    
+       fetched in step 4 replaced with the value from step 3.
    
+
    
+    If the evaluation of <value-form> in step 3 alters what is found in the 
    
+    given "place" -- such as setting a different bit-field of the integer --
    
+    then the change of the bit-field denoted by <byte-spec> will be to that 
    
+    altered integer, because the "access" step is done after the <value-form>
    
+    evaluation.  See example 2 in the test cases section.  Nevertheless, the 
    
+    evaluations required for binding the temporaries are done in steps 1 and 
    
+    2, and thus the expected left-to-right evaluation order is seen.
    
+
    
+
    
+  MASK-FIELD:
    
+
    
+   This case is the same as LDB in all essential aspects.
    
+
    
+
    
+  GETF:
    
+
    
+    In a form such as:
    
+
    
+        (SETF (GETF <place-form> <ind-form>) <value-form>)
    
+
    
+    the place referred to by the <place-form> must always be both accessed 
    
+    and updated;  note that the update is to the generalized variable 
    
+    specified by <place-form> -- not necessarily to the particular list
    
+    which is the property list in question.
    
+
    
+    Thus this SETF should generate code to do the following:
    
+
    
+    1. Bind the temporaries for <place-form> 
    
+    2. Evaluate <ind-form> (and bind into a temporary)
    
+    3. Evaluate the <value-form> (and bind into the store variable)
    
+    4. Do the access to <place-form>
    
+    5. Do the store into <place-form> with a possibly-new property list
    
+       obtained by combining the values from steps 2, 3, and 4.  
    
+
    
+    If the evaluation of <value-form> in step 3 alters what is found in the 
    
+    given "place" -- such as setting a different named property in the list,
    
+    then the change of the property denoted by <ind-form> will be to that 
    
+    altered list, because the "access" step is done after the <value-form>
    
+    evaluation.  See example 7 in the test cases section.  Nevertheless, the 
    
+    evaluations required for binding the temporaries are done in steps 1 and 
    
+    2,  and thus the expected left-to-right evaluation order is seen.
    
+
    
+    Note that this phrase "possibly-new property list" treats the 
    
+    implementation of property lists as a "black box"  -- it can mean that 
    
+    the former property list is somehow destructively re-used, or it can 
    
+    mean partial or full copying of it.  This is like the question of REMOVE
    
+    or DELETE -- do you copy or do you destructively alter.  Since the answer
    
+    could go either way, the treatment of the resultant value for the 
    
+    "possibly-new property list" must proceed as if it were a different copy
    
+    needing to be stored back into the generalized variable.
    
+
    
+The "read-modify-write" macros such as INCF, DECF, PUSH, POP, 
    
+and REMF, as well as PSETF, SHIFTF, and ROTATEF should be 
    
+specified to have the same evalauation order for the subforms of
    
+the "place" arguments; this would generally follow from their definition
    
+in terms of SETF.
    
+
    
+Test Cases:
    
+
    
+  1. (setq char (make-char #\A 1))         ==>  #\Control-A
    
+     (rotatef (char-bit char :control) 
    
+              (char-bit char :meta)) 
    
+     char  ==>  #\Meta-A
    
+     ;; It's as if you start with #\Control-A, and then first turn the
    
+     ;;  :control bit off, because the :meta bit was originally off; and
    
+     ;;  then to the resulting #\A,  you add the :meta bit since the
    
+     ;;  :control bit was originally on.
    
+
    
+     Note, however, that if an implementation doesn't support both of these
    
+     character 'bits', then this test case would have to be re-written to
    
+     reference two independent bits actually supported.  If an implementation
    
+     supports fewer than two independent character bits, then this test case
    
+     is entirely moot.
    
+
    
+  2. (setq integer #x69)                   ==>  #x69
    
+     (rotatef (ldb (byte 4 4) integer) 
    
+              (ldb (byte 4 0) integer))
    
+     integer  ==>  #x96
    
+     ;; This very-realistic example is simply trying to swap two
    
+     ;;  independent bit fields in an integer.  Note that the generalized
    
+     ;;  variable of interest here is just the (possibly local) program
    
+     ;;  variable 'integer'.
    
+
    
+  3a.(setq l1 (setq l2 (list #x69)))                ==>  (#x69)
    
+     (setf (ldb (byte 4 4) (car l1))
    
+	   (ldb (byte 4 0) (car (prog1 l1 
    
+                                  (setq l1 nil))))) 
    
+     l1 ==> nil
    
+     l2 ==> (#x99)
    
+     ;; Note that the (setq l1 nil) didn't affect the actions of the setf
    
+     ;;  at all, since l1 was evaluated and its value was saved away in a
    
+     ;;  temporary variable as part of the step "2. Bind the temporaries 
    
+     ;;  for <place-form>", and this was done before the evaluation of the
    
+     ;;  <value-form> which contains the (setq l1 nil).  Note also that the
    
+     ;;  step "4. Do the access to <place-form>" means fetching the CAR of
    
+     ;;  the saved (temporary) value of 'l1'; it does not mean doing a LDB
    
+     ;;  on anything like that.
    
+
    
+
    
+  3b.(setq l1 (setq l2 (list #x69)))                ==>  (#x69)
    
+     (setf (ldb (byte 4 4) (car l1))
    
+	   (ldb (byte 4 0) (car (rplaca l1 #x17))))
    
+     l1 ==> (#x77)
    
+     l2 ==> (#x77)
    
+     ;; Note that the (rplaca l1 #x17) altered the contents of what l1
    
+     ;;  was pointing to.  Thus even though l1 was evaluated and its  
    
+     ;;  value was saved away in a temporary variable as part of the step 
    
+     ;;  "2. Bind the temporaries for <place-form>", and even though this 
    
+     ;;  was done before the evaluation of the <value-form> which contains 
    
+     ;;  the rplaca, still the side-effect changes things because it alters
    
+     ;;  what will be fetched during the "do the access" step.
    
+
    
+  4. (setq integer #x69)
    
+     (setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
    
+     integer ==> #x6A
    
+
    
+  5. (setq integer #x6A)
    
+     (setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
    
+     integer => #xBB
    
+
    
+  6. (setq s (setq r (list 'a 1 'b 2 'c 3)))         ==>  (a 1 b 2 c 3)
    
+     (setf (getf r 'b) 
    
+           (progn (setq r nil) 6))                   ==>  6
    
+     r ==> (b 6)
    
+     s ==> (a 1 b 2 c 3)
    
+     ;; Note that the generalized variable of concern here is the (degenerate?)
    
+     ;;  one of simply the program variable 'r'; it is not a property-list 
    
+     ;;  slot denoted by (getf r 'b).   At the time the step "4. Do the access
    
+     ;;  to <place-form>" is performed, the evaluation of the <value-form>
    
+     ;;  has already altered the generalized variable 'r', and thus a nil is
    
+     ;;  returned for this access; that is why a fresh property-list (B 6) is
    
+     ;;  created an stored back into 'r'.
    
+
    
+  7. (setq s (setq r (list (list 'a 1 'b 2 'c 3))))  ==>  ((a 1 b 2 c 3))
    
+     (setf (getf (car r) 'b) 
    
+           (progn (setq r nil) 6))                   ==>  6
    
+     r ==> nil
    
+     s ==> ((A 1 B 6 C 3))
    
+     ;; Note that the (setq r nil) does not affect the actions of the setf 
    
+     ;;  because the value of R had already been saved in a temporary variable
    
+     ;;  as part of the step "1. Bind the temporaries for <place-form>".  Only
    
+     ;;  the CAR of this value will be accessed, and subsequently modified 
    
+     ;;  after the value computation.
    
+
    
+
    
+Rationale:
    
+
    
+As a principle,
    
+
    
+    (setf (foo-a x) (progn (setf (foo-b x) ...)
    
+                           new-a-value))
    
+
    
+should always set both of the "slots" of 'x', even if these slots are 
    
+implemented as bit-fields, getf-properties, and so on.  Only by separating 
    
+out evaluation from "generalized variable access", and by specifying that
    
+the access is done after all the evaluations, can this correctly be done.
    
+
    
+Current Practice:
    
+
    
+Lucid Common Lisp already operates pretty much according to this proposal.
    
+Symbolics Genera 7.2 foolishly adopted an earlier proposal
    
+(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
    
+its parent standards organization.  This proposal is incompatible with
    
+that one, so Genera 7.2 does not implement the behavior described here,
    
+and fails test cases 1, 2, 4, 5, and 6.  Symbolics Genera 7.1
    
+is probably closer to this proposal. 
    
+
    
+Performance impact:
    
+
    
+Small. This proposal might slow down macro-expansion slightly,
    
+might cause some current optimizations not to work as well. However,
    
+the net effect is likely negligible.
    
+
    
+Cost to Implementors:
    
+
    
+In some implementations, this would require a careful revisiting of
    
+the handling of SETF and generalized variable modifiers.
    
+
    
+Cost to Users:
    
+
    
+Small; although this will impose an incompatible change on 
    
+implementations that don't behave as proposed, and might have
    
+an effect on (non-portable) code, we believe the effects
    
+are not widespread.
    
+
    
+Cost of non-adoption:
    
+
    
+SETF left-to-right order of evaluation will not be well specified;
    
+implementations will differ for no good reason.
    
+
    
+Benefits:
    
+
    
+Uniform semantics and portability in the face of recursive "place specifiers"
    
+for SETF.  Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
    
+uniformly no matter the nature of the <place>.
    
+
    
+Anyone who has copied examples from p105 and p106 will continue to
    
+be able to use them.
    
+
    
+Esthetics:
    
+
    
+See "Cost of non-adoption"
    
+
    
+Discussion:
    
+
    
+This is a difficult proposal to specify.
    
+
    
+In the detailed descriptions for each access form, the phrase
    
+    "the place referred to by the <place-form> must always be both 
    
+     accessed and updated; note that the update is to the generalized 
    
+     variable specified by <place-form>"
    
+is not intended to prevent optimizations that could occur when the
    
+code "knows" that the new value will be EQ to the old one.  The only
    
+requirements is that the results be semantically equivalent.
    
+
    
+There is an interesting parallel between this case for GETF and the
    
+very common mistake made by Lisp programmers with respect to the 
    
+function DELETE.  How often the complaint is filed that DELETE didn't
    
+do anything when it should have; but in fact the filer simply forgot
    
+that delete, although permitted to destructively modify the original
    
+list, may also return some tail of the list originally give it, 
    
+whether or not an alteration occurs.
    
+
    
+      (setq l '(a a b c d)) ==> (a a b c d)
    
+      (delete 'a l)         ==> (b c d)
    
+      l 		    ==> (a a b c d)
    
+
    
+The unwary user thinks that because 'l' is still EQ to the original value 
    
+that "DELETE didn't do anything".  The temptation to ignore the resultant 
    
+value of DELETE parallels the temptation to forget about a need to perform
    
+a final update to <place-form> in the setf-of-getf case.
    
+
    
+In the (degenerate?) case when a generalized variable 
    
+is in fact simply a program variable, then there are no sub-forms to be
    
+considered "value-producing" forms; in fact, "doing the access" for such
    
+a generalized variable (i.e. a program variable) is functionally the
    
+same as evaluating it.  This explains why the behaviour in the "Problem 
    
+Description" is at first perplexing -- the "do the access" step has the same
    
+semantics as an evaluation step, even though it is done after all the
    
+prescribed evaluations.
    
+
    
+The issue PUSH-EVALUATION-ORDER is a clarification about just the point
    
+of the evaluation order for the various subforms to a PUSH;  thus there
    
+is a similarity to this issue, but the present issue has a much deeper
    
+problem because of the need to call GET-SETF-METHOD during setf macro
    
+expansion.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313.htm new file mode 100644 index 00000000..a4073032 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SHADOW-ALREADY-PRESENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SHADOW-ALREADY-PRESENT Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SHADOW-ALREADY-PRESENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_m.htm new file mode 100644 index 00000000..04b79c71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue SHADOW-ALREADY-PRESENT Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue SHADOW-ALREADY-PRESENT Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_w.htm new file mode 100644 index 00000000..65bedfff --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss313_w.htm @@ -0,0 +1,151 @@ + + + +CLHS: Issue SHADOW-ALREADY-PRESENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SHADOW-ALREADY-PRESENT Writeup

    + +
    Issue:         SHADOW-ALREADY-PRESENT
    
+
    
+References:    CLtL p.186
    
+
    
+Category:      CLARIFICATION/CHANGE
    
+
    
+Edit history:  Version 1 Moon 24 Aug 87 
    
+               Version 2 Moon 27 Aug 87 incorporate JonL's suggestions 
    
+               Version 3 Masinter 26-Oct-87
    
+               Version 4 Masinter 10-Nov-87
    
+
    
+Problem description:
    
+
    
+The description of the SHADOW function can be interpreted as saying that the
    
+function has no effect, if the symbol is already present in the package.  This
    
+happens if the third sentence in the description ("then nothing is done") is
    
+interpreted as applying to the entire description rather than just to the fourth
    
+sentence.
    
+
    
+SHADOW is said to take symbols as arguments, however only the print-name is
    
+meaningful for this operation (that fact is already documented).
    
+
    
+Proposal SHADOW-ALREADY-PRESENT:WORKS:
    
+
    
+1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
    
+list, even when the symbol is already present in the package. 
    
+
    
+2) The first argument to SHADOW is allowed to be or contain strings as well as
    
+symbols. The specification "the print name of each symbol is extracted" is to be
    
+modified accordingly.
    
+
    
+Test Case:
    
+
    
+;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
    
+;;; list of a package
    
+
    
+(make-package 'test-1)
    
+(intern "TEST" (find-package 'test-1))
    
+(shadow 'test-1::test (find-package 'test-1))
    
+(assert (not (null (member 'test-1::test (package-shadowing-symbols
    
+                                           (find-package 'test-1))))))
    
+
    
+(make-package 'test-2)
    
+(intern "TEST" (find-package 'test-2))
    
+(export 'test-2::test (find-package 'test-2))
    
+(use-package 'test-2 (find-package 'test-1))    ;should not error
    
+
    
+;;; To test the use of strings in place of symbols
    
+;;; change the third line of the test case to
    
+;;;     (shadow "TEST" (find-package 'test-1))
    
+;;; Note the use of capital letters in the string.
    
+
    
+Rationale:
    
+
    
+CLtL p. 180 describes a name conflict problem that can occur when calling the
    
+function USE-PACKAGE. The name conflict is between a symbol directly present in
    
+the using package and an external symbol of the used package. This name conflict
    
+may be resolved in favor of the symbol directly present in the using package by
    
+making it a shadowing symbol. For this to work, SHADOW must add the symbol to
    
+the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
    
+package.
    
+
    
+Since only the print name of a symbol argument is meaningful, a string should
    
+also be accepted.  This is particularly useful to avoid problems when compiling
    
+code in one package environment and loading it into a slightly different package
    
+environment, where the symbol that was referred to at compile time may not be
    
+present at load time.  This is particularly important because the symbol
    
+referred to by the print name may be changed by evaluation of the SHADOW form.
    
+A close reading of CLtL shows that one can already use (shadow '#:bar) in place
    
+of (shadow 'bar), to achieve much the same effect as (shadow "BAR").  But the
    
+user should not have to play such games, strings should be accepted.
    
+
    
+Current practice:
    
+
    
+Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list,
    
+even when the symbol is already present in the package.  Kyoto Common Lisp,
    
+Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is
    
+already present in the package.  It seems likely that we will find several
    
+implementations in each camp.
    
+
    
+SHADOW accepts strings in Symbolics Common Lisp.
    
+
    
+Cost to implementors:
    
+
    
+This should be a minor change to implementations that do not currently work this
    
+way.
    
+
    
+Cost to users:
    
+
    
+Technically this would be an incompatible change to implementations that do not
    
+already behave as proposed, however it is difficult to conceive of a user
    
+program that would require any conversion to cope with the change. Some users
    
+might want to remove kludges that were only necessary to get around the former
    
+misbehavior of SHADOW.
    
+
    
+Cost of non-adoption:
    
+
    
+Inconsistency among implementations and lack of a clear way to resolve the name
    
+conflict mentioned in Rationale.
    
+
    
+Benefits:
    
+
    
+Consistency among implementations and fewer mysterious package problems.
    
+
    
+Esthetics:
    
+
    
+The proposal would remove an unnecessary special case, thus simplifying the
    
+language slightly.
    
+
    
+Discussion:
    
+
    
+The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
    
+
    
+It would be useless for SHADOW to fail to put a symbol that is already present
    
+in the package onto the PACKAGE-SHADOWING-SYMBOLS list.  Moon believes CLtL
    
+intended to describe what is being proposed, but unfortunately used ambiguous
    
+language.
    
+
    
+The cleanup committee endorses this proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss314.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss314.htm new file mode 100644 index 00000000..f6342b56 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss314.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SHADOW-ALREADY-PRESENT:WORKS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SHADOW-ALREADY-PRESENT:WORKS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SHADOW-ALREADY-PRESENT:WORKS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315.htm new file mode 100644 index 00000000..b9876a13 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue SHARP-COMMA-CONFUSION:REMOVE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SHARP-COMMA-CONFUSION:REMOVE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SHARP-COMMA-CONFUSION:REMOVE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315_w.htm new file mode 100644 index 00000000..8cacee1b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss315_w.htm @@ -0,0 +1,138 @@ + + + +CLHS: Issue SHARP-COMMA-CONFUSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SHARP-COMMA-CONFUSION Writeup

    + +
    Forum:		Compiler
    
+Issue:		SHARP-COMMA-CONFUSION
    
+References:	CLtL p. 356
    
+		Issue LOAD-TIME-EVAL
    
+Category:	CHANGE
    
+Edit History:   V1, 17 Oct 1988, Sandra Loosemore
    
+		V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)
    
+Status:		Proposal REMOVE passed Jan 89
    
+
    
+
    
+Problem Description:
    
+
    
+The way the read macro #, is defined in CLtL does not make it clear
    
+that it can only appear inside of (implicitly) quoted structure to
    
+guarantee consistent handling between the interpreter and the
    
+compiler.  Examples of inconsistent uses would be #, forms appearing
    
+outside of a QUOTE that expand into list or symbol forms that could be
    
+interpreted as code, or strings that could be interpreted as
    
+documentation strings.  Users are even more likely to be confused
    
+because the wording in CLtL compares the behavior of #, to the special
    
+form EVAL-WHEN, which must appear in a for-evaluation position.
    
+
    
+#, also presents a serious problem to program-analyzing programs
    
+because evaluation is tied to the reader, rather than the interpreter
    
+or compiler.  In theory, this could be handled by altering the read table
    
+to have #, construct a "magic cookie" instead of performing read-time
    
+evaluation and having the code walker examine quoted structures, but I've
    
+never seen this actually done in practice.
    
+
    
+
    
+Proposal SHARP-COMMA-CONFUSION:REMOVE:
    
+
    
+Remove the #, read macro from the language.
    
+
    
+
    
+Rationale:
    
+
    
+Removing #, is simpler than trying to redefine it.  Removing it from
    
+the standard, rather than redefining it to mean something else (see
    
+issue LOAD-TIME-EVAL), would allow implementations to continue to
    
+provide it as an extension.  (Although CLtL does not appear to
    
+explicitly address the question of whether implementations may extend
    
+the reader syntax, some implementations already provide sharp-sign
    
+read macros other than those described in CLtL, such as #P syntax for
    
+pathnames.)
    
+
    
+
    
+Current Practice:
    
+
    
+#, is not used very frequently, but the functionality it provides is
    
+important in some advanced applications; one such application that has
    
+been cited is CLOS.  Maintainers of such applications have generally
    
+expressed a willingness to give up #, only if a suitable alternative
    
+is offered (see issue LOAD-TIME-EVAL).
    
+
    
+PSL/PCLS has never bothered to implement #, correctly (it's treated
    
+just like #.), and nobody has ever complained about it being broken.
    
+
    
+
    
+Cost to implementors:
    
+
    
+None.
    
+
    
+
    
+Cost to users:
    
+
    
+Because #, is used so infrequently, most users would probably not even
    
+notice its absence.
    
+
    
+Issue LOAD-TIME-EVAL proposes to add a special form that would provide
    
+a somewhat cleaner mechanism for load-time evaluation.
    
+
    
+It is also possible to use a global variable to get the similar effect as
    
+#,, although this is sometimes awkward and carries a space and 
    
+performance penalty in many implementations.
    
+
    
+
    
+Benefits:
    
+
    
+The language specification is simplified by removing a peculiar
    
+feature of the language that is accessible only through the reader.
    
+
    
+Removing #, may also allow simpler strategies for implementing
    
+compiled file loaders to be used.
    
+
    
+
    
+Discussion:
    
+
    
+If this proposal is rejected, the definition of #, in the standard will
    
+still need to be clarified to indicate that #, can only appear in
    
+quoted structure.  It should probably also include some mention of the
    
+problems that #, can cause code walkers.
    
+
    
+Kent Pitman says:
    
+
    
+  I approve of the ideas being discussed, but ONLY contingent on
    
+  LOAD-TIME-VALUE being introduced.
    
+
    
+  I am optimistic that LOAD-TIME-EVAL will pass, and so I don't think this
    
+  will keep #, from passing, but:
    
+   - I want people who vote for this to realize the importance of voting
    
+     for LOAD-TIME-EVAL.
    
+   - On the off chance LOAD-TIME-EVAL doesn't pass, I want people to have
    
+     been warned that the consequences were severe for some major 
    
+     applications.
    
+   - I want the records to reflect the actual rationale people should and 
    
+     hopefully will be using to make these decisions.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316.htm new file mode 100644 index 00000000..4bca6849 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316_w.htm new file mode 100644 index 00000000..a2336384 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss316_w.htm @@ -0,0 +1,97 @@ + + + +CLHS: Issue SHARP-O-FOOBAR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SHARP-O-FOOBAR Writeup

    + +
    Forum:		Public Review
    
+Issue:		SHARP-O-FOOBAR
    
+References:	Loosemore's public review comment #5
    
+		#b, #o, #x, #r reader syntax 
    
+		  (sections 2.4.8.7 to 2.4.8.10, pages 2-30..2-31)
    
+Category:	CLARIFICATION
    
+Edit history:	21 Dec 1992, Version 1 by Loosemore
    
+Status:         Proposal CONSEQUENCES-UNDEFINED passed (8+2)-1 on 
    
+                letter ballot 93-302.
    
+
    
+
    
+Problem description:
    
+
    
+  Is #ofoobar valid syntax?  In other words, what happens if the
    
+  object following #b, #o, #x, or #r doesn't have the syntax of
    
+  a rational in the given radix?
    
+
    
+
    
+Proposal (SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED):
    
+
    
+  Clarify that the consequences are undefined if the token following
    
+  #b, #o, #x, or #r does not have the syntax of a rational in the given
    
+  radix.
    
+
    
+
    
+Rationale:
    
+
    
+  At least some implementations signal an error.  Other implementations
    
+  apparently just rebind *READ-BASE* and call READ recursively.
    
+
    
+
    
+Current practice:
    
+
    
+  Lucid, CMU CL, and AKCL all signal an error.  WCL reads #ofoobar
    
+  as the symbol FOOBAR.
    
+
    
+
    
+Cost to implementors:
    
+
    
+  None.
    
+
    
+
    
+Cost to users:
    
+
    
+  None, since the behavior already differs among implementations.
    
+
    
+
    
+Aesthetics:
    
+
    
+  Being explicitly vague is better than being implicitly vague.
    
+
    
+
    
+Editorial impact:
    
+
    
+  Adding one sentence to each of the four referenced sections.
    
+
    
+
    
+Discussion:
    
+
    
+
    
+
    
+
    
+
    
+  
    
+
    
+  
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317.htm new file mode 100644 index 00000000..75b9f5cd --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SHARP-STAR-DELIMITER:NORMAL-DELIMITER Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SHARP-STAR-DELIMITER:NORMAL-DELIMITER Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SHARP-STAR-DELIMITER:NORMAL-DELIMITER:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317_w.htm new file mode 100644 index 00000000..d38b8459 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss317_w.htm @@ -0,0 +1,197 @@ + + + +CLHS: Issue SHARP-STAR-DELIMITER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SHARP-STAR-DELIMITER Writeup

    + +
    Issue:        SHARP-STAR-DELIMITER
    
+Forum:	      Editorial
    
+References:   *READ-SUPPRESS* (p345), #* (p355)
    
+Category:     CLARIFICATION
    
+Edit history: 05-Mar-91, Version 1 by Pitman
    
+	      15-Mar-91, Version 2 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  What constitutes a delimiter at the end of #* ?
    
+
    
+  In the description of #* on p355, CLtL says:
    
+
    
+    ``A series of binary digits (0 and 1) preceded by #* is read 
    
+      as a simple bit-vector. ... If an unsigned decimal integer 
    
+      appears between the # and *, it specifies explicitly the 
    
+      length of the vector.   In that case, it is an error if too
    
+      many bits are specified, and if too few are specified the 
    
+      last one (it is an error if there are none in this case) is
    
+      used to fill all remaining elements of the bit-vector.
    
+      ... The notation #* denotes an empty bit-vector, as does
    
+      #0* (which is legitimate because it is not the case that
    
+      too few elements are specified.)''
    
+
    
+  This seems to imply that the bit vector ends when the sequence
    
+  of 0's and 1's ends.
    
+
    
+  In the discussion of *READ-SUPPRESS* on p345, it says:
    
+
    
+   ``The #* construction always scans over a following token and
    
+     produces the value NIL.  It will not signal an error even if
    
+     the token does not consist solely of the characters 0 and 1.''
    
+
    
+  This seems to imply that the bit vector ends at the first normal
    
+  delimiter.
    
+
    
+Proposal (SHARP-STAR-DELIMITER:NORMAL-DELIMITER):
    
+
    
+  Specify that a bit vector is delimited like any normal numeric
    
+  token, and that an error of type READER-ERROR is signalled if all
    
+  the characters in the token are not 0's and 1's.  Clarify
    
+  that | and \ are not permitted as part of the token.
    
+
    
+  Rationale:
    
+
    
+  This will seem most natural to people already familiar with the 
    
+  parsing of other tokens in the language.  This is most consistent
    
+  with the wording in *READ-SUPPRESS*, which is slightly more explicit
    
+  than the wording in #* itself.
    
+
    
+  Also, this is safest for interchange with other dialects since it 
    
+  forces users not to rely on non-standard delimiters (like "2" in
    
+  Test Case #1 below), and therefore it makes it more likely that
    
+  when in a read-suppress context in another dialect, the tokenization
    
+  a CL program has used will be the same as the tokenization such an
    
+  `other dialect' expects. 
    
+
    
+Proposal (SHARP-STAR-DELIMITER:NOT-ZERO-OR-ONE):
    
+
    
+  Specify that a bit vector is delimited by any character that 
    
+  is not a 0 or 1.  Correct the description of *READ-SUPPRESS*
    
+  to indicate that #* stops reading and returns NIL as soon as
    
+  any character other than 0 or 1.
    
+
    
+  Rationale:
    
+
    
+  This prefers a very literal reading of the wording in CLtL's description
    
+  of #*, and reverses the behavior of *read-suppress* to be consistent.
    
+
    
+Test Cases:
    
+
    
+  These should signal an error under NORMAL-DELIMITER, and
    
+  should return 3 under NOT-ZERO-OR-ONE:
    
+
    
+    1. (LENGTH '(#*012 3))
    
+    2. (LENGTH '(#*0123 4))
    
+
    
+  These should return 1 under NORMAL-DELIMITER, and
    
+  should return 2 under NOT-ZERO-OR-ONE:
    
+
    
+    3. (LENGTH '(#+NO-SUCH-FEATURE #*012 3))
    
+    4. (LENGTH '(#+NO-SUCH-FEATURE #*0123 4))
    
+
    
+  These should signal an error under NORMAL-DELIMITER since
    
+  # is not a terminating readmacro, and should return 2 under
    
+  proposal NOT-ZERO-OR-ONE.  (Note that in case 5 the two
    
+  tokens are both bit-vectors under NOT-ZERO-OR-ONE, but in 
    
+  cases 6 and 7 the second token is a symbol.)
    
+
    
+    5. (LENGTH '(#*01#*01))
    
+    6. (LENGTH '(#*012#*012))
    
+    7. (LENGTH '(#*0123#*0123))
    
+
    
+  These should return 0 under NORMAL-DELIMITER, and
    
+  should return 1 under proposal NOT-ZERO-OR-ONE.  (Note that
    
+  in case 8 the token that is seen is a bit-vector under
    
+  NOT-ZERO-OR-ONE, but in cases 9 and 10 it is a symbol.)
    
+
    
+    8. (LENGTH '(#+NO-SUCH-FEATURE #*01#*01))
    
+    9. (LENGTH '(#+NO-SUCH-FEATURE #*012#*012))
    
+   10. (LENGTH '(#+NO-SUCH-FEATURE #*0123#*0123))
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera 8.1 implements NOT-ZERO-OR-ONE. 
    
+
    
+  Symbolics Cloe implements neither (being closer to the confusing
    
+  thing that CLtL actually demands).
    
+
    
+  Specific results:
    
+
    
+           Cloe   Genera
    
+
    
+   #1        3       3
    
+   #2        3       3
    
+   #3        1       2
    
+   #4        1       2
    
+   #5        2       2
    
+   #6        2       2
    
+   #7        2       2
    
+   #8        0       1
    
+   #9        0       1
    
+   #10       0       1
    
+
    
+  Moon, commenting on the test cases for the previous version of this
    
+  writeup, says MCL 2.0 is similar to Genera, but differs on one 
    
+  or two examples.  [New sample data for this version not available.]
    
+
    
+  JonL says Lucid has always supported NORMAL-DELIMITER.
    
+
    
+Cost to Implementors:
    
+
    
+  For implementations that are not already compatible, the cost is 
    
+  probably relatively small.
    
+
    
+Cost to Users:
    
+
    
+  Problem situations could be mechanically detected, and semi-automatically
    
+  corrected in a straightforward way.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Implementations could differ on how #* expressions were parsed,
    
+  causing portability problems.
    
+
    
+Benefits:
    
+
    
+  Cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  The effect of NOT-ZERO-OR-ONE, while seemingly what CLtL intends,
    
+  is often suprising (i.e., unintuitive) to new users.
    
+  The NORMAL-DELIMITER is probably more aesthetic since it uses 
    
+  conventional rules for delimiters.
    
+
    
+Discussion:
    
+
    
+  Moon, Barmar, and Pitman support NORMAL-DELIMITER.
    
+
    
+  Moon says ``if we vote for NOT-ZERO-OR-ONE then I think we're
    
+  inconsistent if we don't say that (length '(#o12399)) is 2.''
    
+  Barmar disagrees that this particular consistency is in issue.
    
+  Moon cited another test case of #o2+2.
    
+  JonL noted that Lucid barfs not only on #o2+2 but even on #o12399.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318.htm new file mode 100644 index 00000000..c91f9669 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318_w.htm new file mode 100644 index 00000000..96eebc21 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss318_w.htm @@ -0,0 +1,124 @@ + + + +CLHS: Issue SHARPSIGN-PLUS-MINUS-PACKAGE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SHARPSIGN-PLUS-MINUS-PACKAGE Writeup

    + +
    Issue:        SHARPSIGN-PLUS-MINUS-PACKAGE
    
+References:   #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit history: Version 1 by Pitman   01-Mar-87
    
+              Version 2 by Masinter 10-Nov-87
    
+              Version 3 by Masinter 14-Nov-87
    
+
    
+Problem Description:
    
+
    
+No information is provided in the description of #+ and #- (pp. 358-359) about
    
+what package the features are read on.
    
+
    
+In some systems, the current package is used. Since there is no wording in CLtL
    
+to the contrary, it's reasonable to assume that this would be done, but a
    
+consequence of this is that you must be much more sensitive to the package
    
+you're in at any given time when using #+ or #- even for system-provided
    
+features. (This is a problem if the LISP package can contain only the symbols in
    
+CLtL because system-provided features will likely not have the names of symbols
    
+on LISP and hence will require package prefixes. Having a symbol named
    
+LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like
    
+#+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
    
+some such, which might get a read error in a non-Symbolics implementation that
    
+didn't export SYMBOLICS from SYSTEM...)
    
+
    
+In some systems, a canonical package (such as KEYWORD) is used. This means that
    
+package prefixes are rarely necessary in sharpsign conditionals for
    
+system-provided features regardless of the current package or restrictions about
    
+what may be in LISP. (For example, the KEYWORD package can have any symbol so
    
+it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).
    
+
    
+This has implications about what goes on the *FEATURES*  list (p. 448).
    
+
    
+
    
+Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
    
+
    
+Specify that the default package while reading feature specs is the keyword
    
+package. Other packages may be designated by use of explicit package prefixes.
    
+
    
+Symbols on *FEATURES* may be in any package but  that in practice they will
    
+mostly be on the keyword package because that's the package #+/#- uses by
    
+default. If symbols in a package other than keyword appear on *FEATURES*, they
    
+will be seen by #+/#- only if marked by explicit package  prefixes in the
    
+written feature-spec.
    
+
    
+Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448
    
+is KEYWORD.
    
+
    
+Rationale:
    
+
    
+Making the behavior of #+ and #- well defined is important for people writing
    
+portable code that manipulate *FEATURES* directly.
    
+
    
+Current Practice:
    
+
    
+Some implementations bind *PACKAGE* while reading feature specs and others do
    
+not.
    
+
    
+Adoption Cost:
    
+
    
+Changes to implementations to make them conform should be fairly minor if not
    
+trivial.
    
+
    
+Benefits:
    
+
    
+As currently specified, using #+ and #- in truly portable code can have
    
+bootstrapping problems, since it is sometimes required to conditionally set up
    
+*FEATURES* in different ways for different systems.
    
+
    
+Conversion Cost:
    
+
    
+Few changes to user code will be required; code that uses #+ and #- will
    
+continue to work, although code that manipulates *FEATURES* directly may require
    
+editing. 
    
+
    
+Aesthetics:
    
+
    
+Most users would perceive this as a bug fix either to CLtL or to certain
    
+implementations.
    
+
    
+Discussion:
    
+
    
+The cleanup committee supports this proposal.
    
+
    
+It might be reasonable to suggest that only vendors should add keyword symbols
    
+to the *FEATURES* list, and that users should add features on their personal
    
+packages so that collisions due to user applications were less likely. This idea
    
+might be a subject of controversy though, so is not part of this proposal.
    
+
    
+It would be useful to create a non-binding registry of feature names (and
    
+package names) already in use, so that Lisp implementors could pick otherwise
    
+unused feature names, and users who wanted to write portable code could know
    
+what feature names were preferred.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319.htm new file mode 100644 index 00000000..a20bc2ec --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319.htm @@ -0,0 +1,41 @@ + + + +CLHS: Issue SLOT-MISSING-VALUES:SPECIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SLOT-MISSING-VALUES:SPECIFY Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SLOT-MISSING-VALUES:SPECIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319_w.htm new file mode 100644 index 00000000..f57d3c1e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss319_w.htm @@ -0,0 +1,102 @@ + + + +CLHS: Issue SLOT-MISSING-VALUES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SLOT-MISSING-VALUES Writeup

    + +
    Issue:         SLOT-MISSING-VALUES
    
+
    
+References:    88-002R p.2-78..79
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+
    
+Problem description:
    
+
    
+  The document says that all values returned by a SLOT-UNBOUND or
    
+  SLOT-MISSING method are returned from SLOT-VALUE, SETF, SLOT-BOUNDP, or
    
+  SLOT-MAKUNBOUND.  However, the language mandates particular values to be
    
+  returned by SETF and by SLOT-MAKUNBOUND, and mandates that SLOT-VALUE and
    
+  SLOT-BOUNDP return exactly one value.  If methods can change this,
    
+  efficient compilation becomes very difficult.
    
+
    
+  This is Symbolics issue #19.
    
+
    
+Proposal (SLOT-MISSING-VALUES:SPECIFY):
    
+
    
+  Specify exactly what is done with the values returned from a SLOT-UNBOUND
    
+  or SLOT-MISSING method, as follows:
    
+
    
+  If the operation was SETF or SLOT-MAKUNBOUND, the values are ignored.
    
+
    
+  If the operation was SLOT-VALUE or SLOT-BOUNDP, exactly one value is
    
+  returned; extra values returned by the method are ignored, and if the
    
+  method returns no values, NIL is returned.
    
+
    
+  If the operation was SLOT-BOUNDP and the method returns a value other
    
+  than NIL, SLOT-BOUNDP might return any object other than NIL that it can
    
+  validly return; only the truth or falsity of the method's value matters.
    
+
    
+Current practice:
    
+
    
+  It's likely that all CLOS implementations already conform to the proposal,
    
+  since implementing what the document says would be extremely difficult.
    
+  I have not actually tested any implementations.
    
+
    
+Cost to Implementors:
    
+
    
+  What's proposed is what's easiest to implement.
    
+
    
+Cost to Users:
    
+
    
+  None, since it's unlikely that any users would depend on being able to
    
+  force SLOT-VALUE to return two values, or to force SETF of SLOT-VALUE to
    
+  return something different from new-value.
    
+
    
+Cost of non-adoption:
    
+
    
+  CLOS will be seriously difficult to implement correctly.
    
+
    
+Performance impact:
    
+
    
+  Implementing CLOS correctly will cause a serious efficiency impact on
    
+  SLOT-VALUE if this proposal is not adopted, since it will have to be
    
+  capable of dynamically deciding at run time to return multiple values.
    
+
    
+Benefits:
    
+
    
+  Simpler and more consistent language.
    
+
    
+Esthetics:
    
+
    
+  Simpler and more consistent language.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320.htm new file mode 100644 index 00000000..8fab9260 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue SLOT-VALUE-METACLASSES:LESS-MINIMAL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SLOT-VALUE-METACLASSES:LESS-MINIMAL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SLOT-VALUE-METACLASSES:LESS-MINIMAL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320_w.htm new file mode 100644 index 00000000..bf1a707d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss320_w.htm @@ -0,0 +1,164 @@ + + + +CLHS: Issue SLOT-VALUE-METACLASSES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SLOT-VALUE-METACLASSES Writeup

    + +
    Issue:              SLOT-VALUE-METACLASSES
    
+References:         SLOT-VALUE (CLOS chapter 2)
    
+		    SLOT-UNBOUND
    
+		    SLOT-MAKUNBOUND
    
+		    SLOT-BOUNDP
    
+		    SLOT-EXISTS-P
    
+Related issues:     Issue CLOS-CONDITIONS
    
+                    Issue CLOS-CONDITIONS-AGAIN
    
+Category:           CLARIFICATION, CHANGE
    
+Edit history:       V1, 09 May 90, Sandra Loosemore
    
+                    V2, 13 May 90, Sandra Loosemore (update discussion)
    
+		    V3, 29 May 90, Sandra Loosemore (clean up)
    
+		    V4,  1 Jun 90, Gabriel (only proposal SPECIFY)
    
+		    V5, 06 Jun 90, Sandra Loosemore (three proposals)
    
+                    V6, 11 Mar 91, Sandra Loosemore (one proposal)
    
+                    V7, 26 Mar 91, Sandra Loosemore (amendment from meeting)
    
+Status:             V7 (proposal LESS-MINIMAL) accepted by X3J13, Mar 1991
    
+
    
+
    
+Problem description:
    
+
    
+The description of the function SLOT-VALUE in CLOS chapter 2
    
+requires it to be implemented using SLOT-VALUE-USING-CLASS, which
    
+is not defined in the standard.  Because of this omission, it is
    
+not clear on what metaclasses SLOT-VALUE is defined.
    
+
    
+There are similar problems with the description of SLOT-UNBOUND
    
+(references SLOT-VALUE-USING-CLASS), SLOT-MAKUNBOUND (references
    
+SLOT-MAKUNBOUND-USING-CLASS), SLOT-BOUNDP (references 
    
+SLOT-BOUNDP-USING-CLASS) and SLOT-EXISTS-P (references 
    
+SLOT-EXISTS-P-USING-CLASS, which is not even in the current MOP
    
+draft).
    
+
    
+It is stated in CLOS chapter 2 (in the section "Integrating Types 
    
+and Classes") that calling SLOT-VALUE on an instance of a built-in 
    
+class signals an error, but nothing is said here about the other 
    
+functions.
    
+
    
+
    
+Proposal (SLOT-VALUE-METACLASSES:LESS-MINIMAL):
    
+
    
+  (1) Remove references to SLOT-VALUE-USING-CLASS, 
    
+      SLOT-MAKUNBOUND-USING-CLASS, SLOT-BOUNDP-USING-CLASS, and 
    
+      SLOT-EXISTS-P-USING-CLASS from the language specification.  Add
    
+      implementation notes to the description of SLOT-VALUE, SLOT-UNBOUND,
    
+      SLOT-MAKUNBOUND, SLOT-BOUNDP, and SLOT-EXISTS-P which reference
    
+      the corresponding functions in the metaobject protocol document.
    
+
    
+  (2) Clarify that the function SLOT-EXISTS-P may be called with any
    
+      object as its first argument, returning true if the object has a 
    
+      slot of the given name and false otherwise.
    
+
    
+  (3) Clarify that the standard defines the behavior of SLOT-VALUE, SETF of
    
+      SLOT-VALUE, SLOT-BOUNDP, and SLOT-MAKUNBOUND according to
    
+      the metaclass of their first argument, as follows:
    
+        STANDARD-CLASS -- all four functions work as already specified.
    
+        BUILT-IN-CLASS -- all four functions signal an error.
    
+
    
+  (4) Specify that the consequences are unspecified if any of the functions
    
+      SLOT-VALUE, SETF of SLOT-VALUE, SLOT-BOUNDP, or SLOT-MAKUNBOUND are
    
+      called on objects of any metaclass other than STANDARD-CLASS or
    
+      BUILT-IN-CLASS.  An error might be signaled in this situation.  Note
    
+      in particular that the behavior of these functions on condition
    
+      objects and objects of metaclass STRUCTURE-CLASS is unspecified.
    
+
    
+  Rationale for proposal LESS-MINIMAL:
    
+
    
+    Point by point:
    
+
    
+    (1) This gets rid of dangling pointers into hyperspace.
    
+
    
+    (2) This corresponds to the current MOP draft.  It is also just what
    
+        88-002R would say if the remark mentioning SLOT-EXISTS-P-USING-CLASS
    
+        were removed.
    
+
    
+    (3) This is clearly the "right" behavior.
    
+
    
+    (4) This constrains SLOT-VALUE and friends from causing "crash and burn"
    
+        errors, but doesn't overconstrain implementors.
    
+
    
+Current Practice:
    
+
    
+  I don't know.
    
+  
    
+Cost to Implementors:
    
+
    
+  Probably small for any of the proposals.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.
    
+
    
+Cost of non-adoption:
    
+
    
+  Part of the language specification will be left vague and
    
+  confusing.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  The language specification is made more concise.
    
+
    
+Esthetics:
    
+
    
+  Making this point clear would be an improvement over leaving
    
+  it unspecified.
    
+
    
+Discussion:
    
+
    
+  This writeup has undergone a lot of revision because both the MOP 
    
+  document and people's perceptions of it have also been undergoing change.
    
+  It has been difficult to find a balance between not permitting "crash 
    
+  and burn" errors and giving implementations freedom to support 
    
+  additional behaviors via the MOP.
    
+
    
+  Gregor says:
    
+
    
+    The MOP draft says very little about STRUCTURE-CLASS.  What it used to
    
+    say about STRUCTURE-CLASS was removed in response to concern that it
    
+    would make it more difficult to build delivery systems (a concern which
    
+    I don't share by the way).  But, one thing the current draft does say is
    
+    that SLOT-EXISTS-P won't ever signal an error.
    
+
    
+    I guess my suggestion for X3J13 would be to be compatible with the MOP
    
+    draft on SLOT-EXISTS-P and "allow implementations to extend" what
    
+    happens when the slot-xxx functions are called on structure and built-in
    
+    instances.
    
+
    
+  It's assumed that, for item (1), the editor will make the implementation
    
+  notes say something that agrees with the current MOP document.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321.htm new file mode 100644 index 00000000..77b28c4d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue SPECIAL-FORM-P-MISNOMER:RENAME Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SPECIAL-FORM-P-MISNOMER:RENAME Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SPECIAL-FORM-P-MISNOMER:RENAME:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321_w.htm new file mode 100644 index 00000000..850733b9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss321_w.htm @@ -0,0 +1,104 @@ + + + +CLHS: Issue SPECIAL-FORM-P-MISNOMER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SPECIAL-FORM-P-MISNOMER Writeup

    + +
    Issue:        SPECIAL-FORM-P-MISNOMER
    
+Forum:	      Cleanup
    
+References:   SPECIAL-FORM-P (p91)
    
+Category:     CHANGE
    
+Edit history: 05-Oct-90, Version 1 by Pitman (internal Symbolics draft)
    
+	      05-Oct-90, Version 2 by Pitman (mostly add endorsements)
    
+Status:	      For Internal Discussion
    
+
    
+Problem Description:
    
+
    
+  The thing for which SPECIAL-FORM-P returns true is not a form.
    
+  This complicates the terminology used in the specification and
    
+  is a nuisance to those trying to teach the language.
    
+
    
+Proposal (SPECIAL-FORM-P-MISNOMER:RENAME):
    
+
    
+  Rename the function named SPECIAL-FORM-P to SPECIAL-OPERATOR-P.
    
+
    
+Test Case:
    
+
    
+  1. (FIND-SYMBOL "SPECIAL-FORM-P" "COMMON-LISP")
    
+     => NIL, NIL
    
+
    
+  2. (FIND-SYMBOL "SPECIAL-OPERATOR-P" "COMMON-LISP")
    
+     => SPECIAL-OPERATOR-P, :EXTERNAL
    
+
    
+  3. (SPECIAL-OPERATOR-P 'SETQ) => true
    
+     (SPECIAL-OPERATOR-P 'CAR)  => NIL
    
+
    
+Rationale:
    
+
    
+  This is makes the function consistent with the uses of the 
    
+  term "form" and "operator" throughout the spec.
    
+
    
+Current Practice:
    
+
    
+  Hopefully no one implements this yet, since it's not conforming.
    
+
    
+Cost to Implementors:
    
+
    
+  Very small.
    
+
    
+Cost to Users:
    
+
    
+  Small.  Most code doesn't do meta-linguistic things that require the use
    
+  of SPECIAL-FORM-P.  Code that does use it can probably be fixed by 
    
+  simple textual replacement.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  It's nearly impossible to explain the term SPECIAL-FORM-P gracefully
    
+  in the specification.
    
+
    
+Benefits:
    
+
    
+  Spec is incrementally easier to write.
    
+  Language is incrementally easier to teach.
    
+
    
+Aesthetics:
    
+
    
+  A locally major improvement in aesthetics in this small corner of
    
+  the language.
    
+
    
+Discussion:
    
+
    
+  Allan Wechsler, who has taught Lisp at Symbolics for several years,
    
+  strongly supports this proposal.  He says the existing name has
    
+  been a source of confusion for students.
    
+
    
+  Pitman strongly supports the proposal.
    
+
    
+  Moon said "I wouldn't expect it to be controversial." Pitman couldn't
    
+  figure out if that was an endorsement.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322.htm new file mode 100644 index 00000000..67d0b296 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SPECIAL-TYPE-SHADOWING:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SPECIAL-TYPE-SHADOWING:CLARIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SPECIAL-TYPE-SHADOWING:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322_w.htm new file mode 100644 index 00000000..0318fb07 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss322_w.htm @@ -0,0 +1,115 @@ + + + +CLHS: Issue SPECIAL-TYPE-SHADOWING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SPECIAL-TYPE-SHADOWING Writeup

    + +
    Issue:         SPECIAL-TYPE-SHADOWING
    
+
    
+References:    CLtL pages 156, 158
    
+
    
+Related issues: DECLARE-TYPE-FREE
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  Version 1, 04-Nov-88 by David Gray
    
+
    
+Problem description:
    
+
    
+  A Common Lisp user raised the question of whether something like the
    
+  following is legal:
    
+
    
+    (PROCLAIM '(TYPE NUMBER *X*))
    
+    (DEFVAR *X*)
    
+    (DEFUN FOO ()
    
+      (LET ((*X* T))
    
+        (DECLARE (TYPE SYMBOL *X*))
    
+        (BAR)))
    
+
    
+  Page 156 of CLtL says that a proclamation is "always in force unless
    
+  locally shadowed" and page 158 says type declarations "only affect
    
+  variable bindings", which might be interpreted to mean that the DECLARE
    
+  locally shadows the PROCLAIM.  However, that interpretation would make
    
+  the global type proclamation useless because it could not be relied on
    
+  when compiling a function such as BAR. 
    
+
    
+Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
    
+  
    
+  Clarify that if there is a local type declaration for a special
    
+  variable, and there is also a global type proclamation for that same
    
+  variable, then the value of the variable within the scope of the local
    
+  declaration must be a member of the intersection of the two declared
    
+  types.
    
+
    
+Rationale:
    
+
    
+  Some restriction on local type declarations for special variables is
    
+  needed in order for type proclamations to be meaningful.  The wording
    
+  used here was chosen for consistency with proposal DECLARE-TYPE-FREE.
    
+
    
+Current practice:
    
+
    
+  The TI, Symbolics, and Lucid implementations do not report any error
    
+  on the example above, but it isn't clear that they really do anything
    
+  with type declarations for special variables anyway.
    
+
    
+Cost to Implementors:
    
+
    
+  This is unlikely to require a change in any current implementation.
    
+
    
+Cost to Users:
    
+
    
+  Anyone who has written code like the example above would have to
    
+  modify it if compilers started enforcing this restriction.
    
+
    
+Cost of non-adoption:
    
+
    
+  A minor ambiguity in the language specification that could confuse
    
+  users.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  A clearer definition of the meaning of type declarations for special
    
+  variables.
    
+
    
+Discussion:
    
+
    
+  This is obviously very closely related to issue DECLARE-TYPE-FREE, but
    
+  this is an ambiguity in the existing language that should be resolved
    
+  even if the language extension of proposal DECLARE-TYPE-FREE is not
    
+  accepted.  Note also that DECLARE-TYPE-FREE makes no mention of type
    
+  proclamations.
    
+
    
+  Other possible resolutions of the ambiguity would be to either rule
    
+  out use of local type declarations for special variables, or to say
    
+  that the local type must be a subtype of the global type.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323.htm new file mode 100644 index 00000000..a1c4aff8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323_w.htm new file mode 100644 index 00000000..15696212 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss323_w.htm @@ -0,0 +1,208 @@ + + + +CLHS: Issue STANDARD-INPUT-INITIAL-BINDING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STANDARD-INPUT-INITIAL-BINDING Writeup

    + +
    Status:	Passed, Jan 89 X3J13
    
+Issue:         STANDARD-INPUT-INITIAL-BINDING
    
+References:    Standard streams (pp. 327-329)
    
+Category:      CHANGE
    
+Edit history:  Version 1 by Pierson and Haflich 1/19/87
    
+    	       Version 2 by Pierson 2/29/88
    
+	       Version 3 by Pierson 5/23/88, per comments by Moon
    
+               Version 4 by Pierson 5/26/88, clean up
    
+    	       Version 5 by Pierson 6/28/88, simple design per Masinter
    
+    	       Version 6 by Pierson 7/ 5/88, clean up and split issue
    
+	       Version 7 by Pierson 7/ 8/88, clean up per Pitman
    
+	       Version 8 by Pierson 7/ 8/88, yet more clean up
    
+
    
+Problem description:
    
+
    
+CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
    
+*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
    
+initially bound to synonym streams to *TERMINAL-IO*.  This requirement
    
+hampers the integration of Common Lisp with many existing and
    
+potential operating environments.
    
+
    
+For example, a Unix implementation is currently unable to legally
    
+support Unix standard error output even though Common Lisp defines
    
+*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
    
+to the same stream as *STANDARD-OUTPUT*.  A workstation environnment
    
+which provides stream access to windows as an extension is currently
    
+forbidden to make trace output appear in a separate window by default
    
+because *TRACE-OUTPUT* is required to start out bound to the same
    
+stream as *STANDARD-OUTPUT*.
    
+
    
+Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
    
+
    
+A Common Lisp implementation is required to provide the following
    
+initial streams.  Each initial stream has a specific purpose as
    
+defined in CLtL.  This proposal redefines the initial bindings of
    
+the streams and leaves the rest of the CLtL description unchanged.
    
+
    
+    *TERMINAL-IO*
    
+    *STANDARD-INPUT*
    
+    *STANDARD-OUTPUT*
    
+    *ERROR-OUTPUT*
    
+    *TRACE-OUTPUT*
    
+    *QUERY-IO*
    
+    *DEBUG-IO*
    
+
    
+    	The initial bindings of these variables are undefined except
    
+	that:
    
+	    1. They are all initially bound to open streams.
    
+	    2. The streams must support input and/or output as
    
+	       indicated by the variable name.
    
+    	    3. None of the standard streams (including *TERMINAL-IO*)
    
+	       may be directed by synonym streams to another of these
    
+	       stream variables (except *TERMINAL-IO*), whether
    
+	       directly or by indirection via some composite stream
    
+	       such as a two way stream with one of the arms being a
    
+	       synonym stream.
    
+	    4. Any or all of these streams may be synonyms for the
    
+	       common implementation dependent stream.  For example,
    
+	       in an interactive Common Lisp invocation running on a
    
+	       character terminal, all of the streams mentioned here
    
+	       might be synonym streams (or two-way streams to synonym
    
+	       streams) to a pair of hidden terminal input/output
    
+	       streams maintained by the implementation.
    
+
    
+	The intent of the above rules is to ensure that it is always
    
+	safe to bind any of the above variables to another of the
    
+	above variables without unduly restricting implementation
    
+	flexibility.
    
+
    
+
    
+Examples:
    
+
    
+(PROGN
    
+   (PRINT "Output" *STANDARD-OUTPUT*)
    
+   (PRINT "Error" *ERROR-OUTPUT*))
    
+
    
+In current Common Lisp will write:
    
+    ------
    
+    Output
    
+    Error
    
+    ------
    
+
    
+With proposal *might* write:
    
+    ------
    
+    Output
    
+    ------
    
+    and "Error" appears somewhere else.
    
+
    
+
    
+(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
    
+  ...)
    
+
    
+In current Common Lisp: 
    
+    Might cause a circular stream reference if *DEBUG-IO* was
    
+    bound to a two-way stream made up of synonym streams to
    
+    *STANDARD-INPUT* and *STANDARD-OUTPUT*.
    
+
    
+With this proposal:
    
+    Would be guaranteed not to cause a circular stream reference
    
+    unless the initial value of *DEBUG-IO* had been changed to a value
    
+    that did not conform the restrictions in this proposal.  While no
    
+    Common Lisp implementation should do this, a user program might.
    
+
    
+
    
+(LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
    
+      (*STANDARD-OUTPUT* *TERMINAL-IO*))
    
+  ...)
    
+
    
+In current Common Lisp: 
    
+    Might cause a circular stream reference because *TERMINAL-IO* was
    
+    bound to a two-way stream made up of synonym streams to
    
+    *STANDARD-INPUT* and *STANDARD-OUTPUT*.
    
+
    
+With this proposal:
    
+    Would be guaranteed not to cause a circular stream reference.
    
+
    
+
    
+Rationale:
    
+
    
+This proposal attempts to provide a balance between over-specifying
    
+behavior to the point that Lisp programs can't behave like other
    
+programs in conventional operating systems and providing enough
    
+specification that Common Lisp programs can perform portable input and
    
+output.
    
+
    
+Current practice:
    
+
    
+Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
    
+binds *TERMINAL-IO* to a special internal stream type for terminal
    
+streams which reads from Unix standard input and writes to Unix
    
+standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
    
+with input from Unix standard input and output to Unix standard
    
+output.  Symbolics Genera binds *TERMINAL-IO* as appropriate for each
    
+process, usually to a window for interactive applications or to a
    
+stream which will conjure an interaction window on demand for
    
+background tasks.
    
+
    
+Cost to Implementors:
    
+
    
+All implementations will have to change to some degree but the changes
    
+will probably be simple and localized.  All known implementations
    
+already support the underlying streams required to implement this
    
+proposal.
    
+
    
+Cost to Users:
    
+
    
+User code which depends on the strict binding hierarchy in CLtL may
    
+have to change.  
    
+
    
+Cost of non-Adoption:
    
+
    
+It will continue to be difficult or impossible to integrate portable
    
+Common Lisp progams in conventional operating system environments.
    
+Many implementations will have to continue to choose between
    
+conforming to the standard and providing a superior user environment.
    
+
    
+Benefits:
    
+
    
+Implementations will be more able to match their IO behavior to their
    
+environment and their user's expectations.
    
+
    
+Aesthetics:
    
+
    
+Improved because this area becomes better defined.
    
+
    
+Discussion:
    
+
    
+Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
    
+*DEBUG-IO*) should fail to work in a non-interactive environment where
    
+nothing like a terminal exists.  This proposal fails to address this.
    
+
    
+Masinter notes that:
    
+    ``In many multi-processing multi-window environments,
    
+      the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
    
+      differs for each process.''  
    
+
    
+Pierson and Pitman support STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324.htm new file mode 100644 index 00000000..fce8c08d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue STANDARD-REPERTOIRE-GRATUITOUS:RENAME Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STANDARD-REPERTOIRE-GRATUITOUS:RENAME Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue STANDARD-REPERTOIRE-GRATUITOUS:RENAME:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324_w.htm new file mode 100644 index 00000000..ecd9fd64 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss324_w.htm @@ -0,0 +1,98 @@ + + + +CLHS: Issue STANDARD-REPERTOIRE-GRATUITOUS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STANDARD-REPERTOIRE-GRATUITOUS Writeup

    + +
    Issue:		STANDARD-REPERTOIRE-GRATUITOUS
    
+Forum:		Cleanup
    
+References:	Character Committee Report, 7/25/89, Proposals 2.2.1 and 2.4.3
    
+Category:	Change
    
+Edit history:	Version 1, 1/3/90 by Kim A. Barrett
    
+
    
+Problem Description
    
+  The Character Committee Report Proposal 2.2.1 (passed 3/89) requires
    
+  implementations to support and document a STANDARD character subrepertoire,
    
+  whose elements are the specified set of characters.  This set of characters
    
+  corresponds exactly to those characters which are of type STANDARD-CHAR.
    
+
    
+  The Character Committee Report Proposal 2.4.3 (passed 6/89) states that
    
+  every character repertoire name is a type specifier.
    
+
    
+  Thus we have two atomic type specifiers for precisely the same thing.  The
    
+  type STANDARD is equivelent to the type STANDARD-CHAR.
    
+
    
+Proposal (STANDARD-REPERTOIRE-GRATUITOUS:RENAME):
    
+  Change the name of the STANDARD character subrepertoire required by
    
+  Character Proposal 2.2.1 to be STANDARD-CHAR.
    
+
    
+Rationale:
    
+  This removes the duplication.
    
+
    
+Current Practice:
    
+  Probably none.
    
+
    
+Cost to Implementors:
    
+  Probably none.
    
+
    
+Cost to Users:
    
+  Probably none.
    
+
    
+Benefits:
    
+  Eliminates possible confusion when a person reading some code sees
    
+    (TYPEP foo 'STANDARD)
    
+  and wonders "STANDARD what?  Transmission?"
    
+
    
+Discussion:
    
+  Pitman and Barrett support this proposal (RENAME).
    
+
    
+  There was initally some concern that STANDARD-CHAR might not be a valid
    
+  repertoire name, but there are no restrictions placed on the names of
    
+  repertoires in any of the proposals in the Character Committee Report
    
+  dated 7/25/89.  There is a footnote (#15) that constrains character
    
+  scripts and labels to only use Latin capitals A-Z, hyphen, and digits
    
+  0-9, which the name STANDARD-CHAR satisfies.  Since this is a footnote,
    
+  it can be argued that it has no force anyway.
    
+
    
+  Unfortunately, this still doesn't remove STANDARD as a defined name
    
+  (i.e., exported symbol of the cl package) since it's used by CLOS for
    
+  what might be argued to be an equally ungeneric purpose.  There's a 
    
+  fair chance that somebody somewhere along the line is going to get 
    
+  annoyed by the inter-package sharing that occurs due to this symbol
    
+  being present.
    
+
    
+-----
    
+Additional comments on the write-up:
    
+
    
+Moon (9 Jan 90):
    
+
    
+  I support this.  I think it's only an accident of the process for
    
+  amending the character committee's proposals that the duplication
    
+  between STANDARD and STANDARD-CHAR was overlooked.  Given that we
    
+  want to get rid of one of the two duplicate names, it's clear
    
+  that STANDARD-CHAR is a better name.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325.htm new file mode 100644 index 00000000..6181cace --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue STEP-ENVIRONMENT:CURRENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STEP-ENVIRONMENT:CURRENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue STEP-ENVIRONMENT:CURRENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325_w.htm new file mode 100644 index 00000000..7de3680f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss325_w.htm @@ -0,0 +1,141 @@ + + + +CLHS: Issue STEP-ENVIRONMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STEP-ENVIRONMENT Writeup

    + +
    Status: Passed, Jan 89 X3J13, as amended
    
+
    
+Issue:         STEP-ENVIRONMENT
    
+ 
    
+References:    STEP (CLtL p.441)
    
+               TIME (CLtL p.441)
    
+ 
    
+Category:      CLARIFICATION/CHANGE
    
+ 
    
+Edit history:  Version 1, 12-Mar-88, Moon
    
+               Version 2, 10-Jun-88, Masinter (add discussion)
    
+	       Version 3, 20-Jun-88, Loosemore (not a special form)
    
+	       version 4, 17-Mar-89, Masinter (as amended)
    
+ 
    
+Problem description:
    
+ 
    
+CLtL does not specify in what lexical environment the form given to STEP
    
+is evaluated.  Some people think it's supposed to be evaluated in the
    
+null environment, others think it is supposed to be evaluated in the
    
+current environment, the one in which the STEP form was evaluated.
    
+ 
    
+The same considerations apply to TIME.
    
+ 
    
+Proposal (STEP-ENVIRONMENT:CURRENT):
    
+ 
    
+1. Clarify that STEP and TIME evaluate the form in the current environment.
    
+
    
+2. Clarify that calls to both STEP and TIME may be compiled, but that
    
+in the case of STEP, it is acceptable for an implementation to
    
+interactively step through only those parts of the computation that are
    
+interpreted.
    
+
    
+Examples:
    
+ 
    
+;Assuming X is not a special variable
    
+(setq x 1)
    
+(let ((x 2))
    
+  (step (print x)))
    
+ 
    
+This should print and return 2, not 1, when interpreted.
    
+ 
    
+Rationale:
    
+ 
    
+1. It is more useful for the lexical environment to pass transparently
    
+through STEP and TIME than to reset to the null environment.
    
+
    
+2. Although STEP is primarily a debugging tool, there is no reason to
    
+prevent it from being compiled correctly.
    
+
    
+Current practice:
    
+
    
+Vax Lisp behaves as proposed.  Symbolics Common Lisp treats STEP as a special 
    
+form and does not allow it to be compiled. 
    
+
    
+Cost to Implementors:
    
+ 
    
+Minimal.
    
+
    
+Cost to Users:
    
+ 
    
+None.
    
+
    
+Cost of non-adoption:
    
+ 
    
+These debugging tools will continue to have vague specifications.
    
+ 
    
+Benefits:
    
+ 
    
+Slightly more preicse specification of Common Lisp.
    
+ 
    
+Esthetics:
    
+ 
    
+Slightly improved.
    
+ 
    
+Discussion:
    
+ 
    
+There was some discussion of separating this out into two separate
    
+proposals, but it didn't seem useful.
    
+ 
    
+Eric Benson contributed the definition of TIME in Lucid Common Lisp:
    
+ 
    
+(defmacro time (form)
    
+  `(time-internal #'(lambda () ,form)))
    
+ 
    
+ 
    
+The function TIME-INTERNAL looks something like:
    
+ 
    
+(defun time-internal (thunk)
    
+  (let ((before-time (get-time-state)))
    
+    (unwind-protect
    
+        (funcall thunk)
    
+      (print-time-information before-time (get-time-state)))))
    
+ 
    
+The definition of STEP is similar.  This is just to show that it is
    
+easy to get the right lexical environment even though TIME and STEP
    
+are macros.
    
+
    
+VaxLisp expands STEP into something like:
    
+
    
+(defmacro step (form)
    
+    `(let ((*eval-hook* #'step-command-loop))
    
+        ,form))
    
+
    
+
    
+ 
    
+Additional comments:
    
+
    
+Verbally this was explained to mean that the body of the STEP would
    
+not be stepped when compiled, but if it just happened to call an
    
+interpreted function, that function would get stepped.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326.htm new file mode 100644 index 00000000..81f52368 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue STEP-MINIMAL:PERMIT-PROGN Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STEP-MINIMAL:PERMIT-PROGN Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue STEP-MINIMAL:PERMIT-PROGN:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326_w.htm new file mode 100644 index 00000000..19886688 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss326_w.htm @@ -0,0 +1,123 @@ + + + +CLHS: Issue STEP-MINIMAL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STEP-MINIMAL Writeup

    + +
    Issue:        STEP-MINIMAL
    
+Forum:	      Editorial
    
+References:   STEP (p441)
    
+Category:     CLARIFICATION
    
+Edit history: 04-Mar-91, Version 1 by Pitman
    
+Status:	      For X3J13 consideration
    
+
    
+Problem Description:
    
+
    
+  What is the minimal interpretation of STEP?  Specifically, must it
    
+  pause for some user interaction, or can it just proceed without
    
+  pausing in implementations (probably `compiled-only' implementations)
    
+  which do not choose to implement this feature?
    
+
    
+  In particular, are either of the following implementations valid?
    
+
    
+  (DEFMACRO STEP (FORM) `(PROGN ,FORM))
    
+
    
+  or
    
+
    
+  (DEFMACRO STEP (FORM) 
    
+    `(LET ((VALUES (MULTIPLE-VALUE-LIST ,FORM)))
    
+       (FORMAT T "~&~S => ~{~S~^, ~}~%" ',FORM VALUES)
    
+       (VALUES-LIST VALUES)))
    
+
    
+Proposal (STEP-MINIMAL:PERMIT-PROGN):
    
+
    
+  Clarify that it is permissible to implement (STEP x) as (PROGN x)
    
+  in implementations which do not wish to provide more elaborate
    
+  functionality.
    
+
    
+  Rationale:
    
+
    
+  For a delivery Lisp, this would be a minimal amount of work.
    
+
    
+Proposal (STEP-MINIMAL:REQUIRE-PAUSE):
    
+
    
+  Clarify that (STEP x) must, at minimum, pause in some way that permits
    
+  user intervention.
    
+
    
+  This also implies that in implementaions which do have a query loop, 
    
+  some form of query must occur even for constant forms, like (STEP 5).
    
+
    
+  Rationale:
    
+
    
+  Users who introduce STEP into a program might do so on the assumption
    
+  that execution will not proceed beyond that point (e.g., into some 
    
+  dangerous code that follows) without offering them a way to intervene 
    
+  first.
    
+
    
+Current Practice:
    
+
    
+  Symbolics Genera requires intervention.
    
+
    
+  Symbolics Cloe Runtime (the part that runs on the 386) behaves like PROGN
    
+  in the example I tried (a couple of nested arithmetic operations).
    
+
    
+Cost to Implementors:
    
+
    
+  REQUIRE-PAUSE:  Probably none.  If there are any minimalist 
    
+   implementations which do not currently require a pause now, they
    
+   would need a very small amount of additional code.
    
+
    
+  PERMIT-PROGN:  None.
    
+
    
+Cost to Users:
    
+
    
+  None.  This is a debugging feature that affects -how- Lisp is used in
    
+  subtle ways, but is not likely to be present in stable code so wouldn't 
    
+  have a direct cost.  It might be argued that there was a slight cost
    
+  to PERMIT-PROGN for users who wanted the pause and didn't get it in
    
+  some implementation; there is also a risk of larger cost with 
    
+  PERMIT-PROGN of users who expect a pause and don't get it and fall 
    
+  through to code they didn't intend to run.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Unclear specification.  Implementors of certain implementations won't
    
+  know what to do.  Users won't know what to expect.
    
+
    
+Benefits:
    
+
    
+  See above.
    
+
    
+Aesthetics:
    
+
    
+  Probably negligible.
    
+
    
+Discussion:
    
+
    
+  Pitman has a slight preference for REQUIRE-PAUSE, but supports any
    
+  interpretation that makes this clear.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327.htm new file mode 100644 index 00000000..aeba2e07 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327.htm @@ -0,0 +1,60 @@ + + + +CLHS: Issue STREAM-ACCESS:ADD-TYPES-ACCESSORS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STREAM-ACCESS:ADD-TYPES-ACCESSORS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue STREAM-ACCESS:ADD-TYPES-ACCESSORS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327_w.htm new file mode 100644 index 00000000..bb1e4ec3 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss327_w.htm @@ -0,0 +1,193 @@ + + + +CLHS: Issue STREAM-ACCESS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STREAM-ACCESS Writeup

    + +
    Proposal ADD-TYPES-ACCESSORS was accepted at the January 1989 meeting.
    
+
    
+-----
    
+Issue:		STREAM-ACCESS
    
+References:	streams (Chapter 21 of CLtL)
    
+Category:	ADDITION
    
+Edit History:	17-Jun-88, version 1 by Walter van Roggen
    
+			30-Nov-88, version 2 by Masinter
    
+
    
+Problem Description:
    
+
    
+  There are many components of streams which are specified upon creation
    
+  but are not accessible afterwards.  Furthermore there is no way in
    
+  Common Lisp to determine the type of a stream to see if it has particular
    
+  components, or even if it is OPEN.
    
+
    
+  The accessors wanted are those associated with broadcast streams,
    
+  concatenated streams, echo streams, file streams, string streams, 
    
+  synonym streams, two way streams.
    
+
    
+  There are three proposals, which differ only by the whether
    
+  they include types, type predicates, or both, in addition to
    
+  the stream component acessors. Ballots can be either for
    
+  one of the proposals or none. (Other combinations of, say, 
    
+  accessors without either predicates or types, or types without
    
+  accessors, do not seem reasonable and are not being proposed
    
+  at this time.)
    
+
    
+
    
+Proposal STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
    
+
    
+
    
+First, add a function to determine whether a stream is "OPEN":
    
+
    
+OPEN-STREAM-P stream			[Function]
    
+
    
+      Returns T if a stream is open, NIL if it is closed.  It is an error
    
+      if the argument is not a stream.
    
+
    
+    Streams are "open" until they have been closed with
    
+    CLOSE, or, the dynamic context of the creating/accessing
    
+    macros of  WITH-OUTPUT-TO-STRING, WITH-OPEN-FILE, 
    
+    WITH-INPUT-FROM-STRING,  WITH-OPEN-STREAM, 
    
+    have been exited.
    
+    
    
+There are three kinds of things to add associated with each kind of
    
+stream: data types, predicates, accessors.
    
+
    
+Stream data types:
    
+   BROADCAST-STREAM (returned by MAKE-BROADCAST-STREAM)
    
+   CONCATENATED-STREAM (returned by MAKE-CONCATENATED-STREAM)
    
+   ECHO-STREAM (returned by MAKE-ECHO-STREAM)
    
+   FILE-STREAM (returned by OPEN or created by WITH-OPEN-FILE)
    
+   STRING-STREAM (returned by MAKE-STRING-INPUT-STREAM, 
    
+	MAKE-STRING-OUTPUT-STREAM, and created by WITH-INPUT-FROM-STRING
    
+      and WITH-OUTPUT-TO-STRING and FORMAT with second argument NIL)
    
+  SYNONYM-STREAM (created by MAKE-SYNONYM-STREAM)
    
+  TWO-WAY-STREAM (created by  MAKE-TWO-WAY-STREAM)
    
+
    
+  The stream data types are all subtypes of type STREAM and are mutually
    
+  exclusive. (In particular, a synonym stream is only of type SYNONYM-STREAM.)
    
+
    
+Stream Predicates:
    
+
    
+  Each of these returns T if the object is of the corresponding type,
    
+  and NIL otherwise.
    
+
    
+    BROADCAST-STREAM-P, CONCATENATED-STREAM-P,
    
+    ECHO-STREAM-P, FILE-STREAM-P, STRING-STREAM-P,
    
+    SYNONYM-STREAM-P, TWO-WAY-STREAM-P
    
+
    
+  Note that the predicates do not "follow the link" of a synonym
    
+  stream.
    
+
    
+Stream Informational Functions:
    
+
    
+  BROADCAST-STREAM-STREAMS broadcast-stream       ==> list of streams
    
+
    
+      This function returns a list of output streams that constitute
    
+      all the streams the broadcast stream is broadcasting to.  It is
    
+      an error if the argument is not of type BROADCAST-STREAM.
    
+
    
+  CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
    
+
    
+      This function returns a list of input streams that constitute
    
+      the ordered set of streams the concatenated stream still has to
    
+      to read from, starting with the current one it is reading from.
    
+      The list may be () if no more streams remain to be read.
    
+      It is an error if the argument is not of type CONCATENATED-STREAM.
    
+
    
+  ECHO-STREAM-INPUT-STREAM echo-stream            ==> input-stream
    
+  ECHO-STREAM-OUTPUT-STREAM echo-stream           ==> output-stream
    
+
    
+      These functions return the corresponding component stream.  It is
    
+      an error if the argument is not of type ECHO-STREAM.
    
+
    
+  SYNONYM-STREAM-SYMBOL synonym-stream            ==> symbol
    
+
    
+      This function returns the symbol whose SYMBOL-VALUE the
    
+      synonym stream is using.  It is
    
+      an error if the argument is not of type SYNONYM-STREAM.
    
+
    
+  TWO-WAY-STREAM-INPUT-STREAM two-way-stream      ==> input-stream
    
+  TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream     ==> output-stream
    
+
    
+      These functions return the corresponding component stream.  It is
    
+      an error if the argument is not of type TWO-WAY-STREAM.
    
+
    
+
    
+Proposal: STREAM-ACCESS:ADD-TYPES-ACCESSORS
    
+
    
+Identical to ADD-TYPES-PREDICATES-ACCESSORS except to leave out the 
    
+stream type predicates.
    
+
    
+Proposal: STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
    
+
    
+Identical to ADD-TYPES-PREDICATES-ACCESSORS except to not
    
+identify new data types. The accessors act as if the types were specified
    
+(i.e., are mutually excusive).
    
+
    
+Current Practice:
    
+
    
+VAX LISP implements ADD-TYPES-PREDICATES-ACCESSORS.
    
+ We have not surveyed other implementations. 
    
+
    
+Cost to Implementors:
    
+
    
+  All of the proposals are reasonably simple to implement, since the information
    
+  must be present for nearly all types. 
    
+
    
+Cost to Users:
    
+
    
+  The proposals are upward-compatible, and should have little impact.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  The benefits would not be available in a portable fashion.
    
+
    
+Benefits:
    
+
    
+  Programs would be able to access useful information otherwise hidden.
    
+
    
+Discussion:
    
+
    
+  This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
    
+
    
+  The behavior of OPEN-STREAM-P on, for example, broadcast streams, might
    
+  be specified in a variety of alternative ways. This specification seems the simplest.
    
+
    
+  There are three proposals for voting because there was no agreement at the
    
+  October X3J13 on the issue of whether types, predicates, or both should be
    
+ added.
    
+
    
+  There was a proposal at one time to add a new function FOLLOW-SYNONYM-STREAM
    
+  which could be written as
    
+   (defun follow-synonym-stream (x)
    
+     (if (synonym-stream-p x)
    
+         (follow-synonym-stream (symbol-value (synonym-stream-symbol x)))
    
+         x))
    
+
    
+  i.e., which chases through zero or more synonym stream indirections.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328.htm new file mode 100644 index 00000000..d76c44ab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue STREAM-CAPABILITIES:INTERACTIVE-STREAM-P Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STREAM-CAPABILITIES:INTERACTIVE-STREAM-P Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue STREAM-CAPABILITIES:INTERACTIVE-STREAM-P:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328_w.htm new file mode 100644 index 00000000..14ffb58c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss328_w.htm @@ -0,0 +1,137 @@ + + + +CLHS: Issue STREAM-CAPABILITIES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STREAM-CAPABILITIES Writeup

    + +
    Issue:         STREAM-CAPABILITIES
    
+References:    Standard streams (pp. 327-329)
    
+Category:      ADDITION
    
+Edit history:  Version 1 by Pierson 5-Jul-88, add redesign per Pitman
    
+               Version 2 by Moon, 10-May-89, remove controversial parts
    
+               Version 3 by Moon, 12-May-89, improve wording and examples
    
+
    
+Problem description:
    
+
    
+  Programs cannot currently distinguish between interactive use and batch
    
+  (or background) use without using implementation-dependent extensions.
    
+  For example, there is currently no way to tell whether it is useful to
    
+  ask a question when an unexpected situation is encountered.
    
+
    
+  Note: earlier versions of this issue tried to solve another problem
    
+  as well.  See discussion section.
    
+
    
+Proposal (STREAM-CAPABILITIES:INTERACTIVE-STREAM-P):
    
+
    
+  Add the following function:
    
+
    
+    INTERACTIVE-STREAM-P stream
    
+
    
+    Returns T if the stream is interactive, otherwise NIL.  Signals
    
+    an error of type TYPE-ERROR if the argument is not a stream.
    
+
    
+    The precise meaning of INTERACTIVE-STREAM-P is implementation
    
+    dependent, and may depend on the underlying operating system.  However
    
+    the general intent is to distinguish between interactive and batch (or
    
+    background or command-file) operations.
    
+
    
+    Some examples of the things that might identify a stream as interactive
    
+    include:
    
+       1. The stream is connected to a person (or equivalent) in
    
+          such a way that the program can prompt for information and
    
+          expect to receive different input depending on the prompt.
    
+       2. The program is expected to prompt for input and support
    
+          "normal input editing".
    
+       3. READ-CHAR might hang waiting for the user to type something
    
+          instead of quickly returning a character or EOF.
    
+
    
+    *TERMINAL-IO* might or might not be interactive.
    
+
    
+Examples:
    
+
    
+  (when (> measured limit)
    
+    (let ((error (round (* (- measured limit) 100)
    
+                        limit)))
    
+      (unless (if (interactive-stream-p *query-io*)
    
+                  (yes-or-no-p "The frammis is out of tolerance by ~D%.~@
    
+                                Is it safe to proceed? " error)
    
+                  (< error 15))  ;15% is acceptable
    
+        (error "The frammis is out of tolerance by ~D%." error))))
    
+
    
+Rationale:
    
+
    
+  INTERACTIVE-STREAM-P has been proposed several times and is clearly
    
+  needed by any program that alters its behavior depending on whether
    
+  it is interacting with a user or running in a "batch" mode.
    
+
    
+Current practice:
    
+
    
+  Most implementations have this feature already, often under a
    
+  different name.
    
+
    
+Cost to Implementors:
    
+
    
+  Implementations will have to support this new function.  Correct support
    
+  will require some thought for each operating system supported.
    
+
    
+Cost to Users:
    
+
    
+  None, this is an upward-compatible extension.
    
+
    
+Cost of non-adoption:
    
+
    
+  Less featureful language. 
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  More featureful language.
    
+
    
+Esthetics:
    
+
    
+  More featureful language.
    
+
    
+Discussion:
    
+
    
+  It's not possible to make a specific definition of "interactive" that
    
+  applies to all operating systems, we concluded from earlier discussion.
    
+  However, "everyone knows" appoximately what it means.  Hence the idea
    
+  of describing it by example rather than defining it.
    
+
    
+  Note that some proposed features for telling whether two streams are
    
+  connected to the same source or sink of information have been removed
    
+  from this version of the proposal.  These were the functions
    
+  STREAM-SAME-SOURCE-P, STREAM-SAME-DESTINATION-P, STREAM-SOURCE-ID-LIST,
    
+  and STREAM-DESTINATION-ID-LIST.  These could be revived in another
    
+  proposal if desired, but Moon thought INTERACTIVE-STREAM-P was
    
+  important and didn't want it to be lost due to controversy over these 
    
+  unrelated functions.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329.htm new file mode 100644 index 00000000..e3c9dc31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue STRING-COERCION:MAKE-CONSISTENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STRING-COERCION:MAKE-CONSISTENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue STRING-COERCION:MAKE-CONSISTENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329_w.htm new file mode 100644 index 00000000..fe33feb8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss329_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue STRING-COERCION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STRING-COERCION Writeup

    + +
    Issue:          STRING-COERCION
    
+References:     Strings (pp299-304),
    
+                STRING= (p300), STRING-EQUAL (p301), STRING< (p301),
    
+                STRING> (p301), STRING<= (p301), STRING>= (p301),
    
+                STRING/= (p301), STRING-LESSP (p302), STRING-GREATERP (p302),
    
+                STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
    
+                STRING-NOT-EQUAL (p302), STRING-TRIM (p302), STRING-LEFT-TRIM (p302),
    
+                STRING-RIGHT-TRIM (p302), STRING-UPCASE (p303), STRING-DOWNCASE (p303),
    
+                and STRING-CAPITALIZE (p303).
    
+Related issues: none
    
+Category:       CLARIFICATION
    
+Edit history:   Version 1, 9-May-89 by Moon
    
+                Version 2, 9-May-89 by Pitman (editorial changes)
    
+
    
+Problem description:
    
+
    
+  CLtL is inconsistent about the argument coercion performed by the
    
+  referenced functions. Page 299 says that the <string> argument can
    
+  be either a symbol or a string.  Page 304 says that these functions
    
+  effectively call the STRING function, thus accepting a symbol,
    
+  a string, or a character.
    
+
    
+  Neither page lists the set of affected functions explicitly.
    
+
    
+  Page 304 says that if any other data type is used, an error is
    
+  signalled.  But some implementations allow other types, such as
    
+  pathnames, to be coerced to strings, which page 299 appears to allow
    
+  but page 304 appears to forbid.  In some implementations these
    
+  coercions are under user control via methods for a generic function.
    
+
    
+Proposal (STRING-COERCION:MAKE-CONSISTENT):
    
+
    
+  Specify that the referenced functions perform coercion identical to
    
+  the action of the STRING function.
    
+
    
+  Specify that the STRING function can perform additional implementation
    
+  dependent coercions.  In all cases the returned value is of type STRING.
    
+  Only in the case where no coercion is defined is the STRING function
    
+  required to signal an error; in that case, the error is of type TYPE-ERROR.
    
+
    
+Examples:
    
+
    
+  (string-lessp #\a "B") => T
    
+
    
+Rationale:
    
+
    
+  Our choices are to make the coercion identical to the STRING function,
    
+  identical to the COERCE function, or different from both of them.  The
    
+  COERCE function won't coerce non-null symbols to strings, so it is out.
    
+  Being consistent with the STRING function seems better than inventing
    
+  yet another set of string coercion rules.  Removing the ability for the
    
+  STRING function to coerce characters to strings would be an incompatible
    
+  change, so instead we clarify that the other functions have that ability.
    
+
    
+  Allowing additional coercions is harmless and consistent with current
    
+  practice.
    
+
    
+Current practice:
    
+
    
+  Symbolics Genera follows page 304 except for allowing additional
    
+  coercions.  Symbolics Cloe follows page 299 except for not allowing
    
+  additional coercions.
    
+
    
+Cost to Implementors:
    
+
    
+  Small changes to eighteen functions.
    
+
    
+Cost to Users:
    
+
    
+  None, this is upward-compatible.
    
+
    
+Cost of non-adoption:
    
+
    
+  Inconsistency and confusion about what coercions are allowed.
    
+
    
+Performance impact:
    
+
    
+  None.  If these things have to accept symbols, accepting characters
    
+  too can't make much difference.  The implementation of character
    
+  arguments to string functions might cons a string, but this has no
    
+  performance impact on programs that don't use the feature.
    
+
    
+Benefits:
    
+
    
+  Consistency.
    
+
    
+Esthetics:
    
+
    
+  Consistency.
    
+
    
+Discussion:
    
+
    
+  None.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330.htm new file mode 100644 index 00000000..5e876d97 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue STRING-OUTPUT-STREAM-BASHING:UNDEFINED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STRING-OUTPUT-STREAM-BASHING:UNDEFINED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue STRING-OUTPUT-STREAM-BASHING:UNDEFINED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330_w.htm new file mode 100644 index 00000000..9cbee0e8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss330_w.htm @@ -0,0 +1,141 @@ + + + +CLHS: Issue STRING-OUTPUT-STREAM-BASHING Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STRING-OUTPUT-STREAM-BASHING Writeup

    + +
    Issue:              STRING-OUTPUT-STREAM-BASHING
    
+References:         WITH-OUTPUT-TO-STRING
    
+                    GET-OUTPUT-STREAM-STRING
    
+                    FORMAT
    
+Related issues:     MAPPING-DESTRUCTIVE-INTERACTION
    
+                    WITH-OUTPUT-TO-STRING-APPEND-STYLE
    
+Category:           CLARIFICATION
    
+Edit history:       V1, 12 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  Is it valid to call GET-OUTPUT-STREAM-STRING on a stream bound by
    
+  WITH-OUTPUT-TO-STRING?  If so, must the WITH-OUTPUT-TO-STRING still 
    
+  return a string containing *all* of the collected output to the 
    
+  stream?  Or should only output collected since the last call to
    
+  GET-OUTPUT-STREAM-STRING be returned?
    
+
    
+  The ambiguity exists for both the case where no string argument is
    
+  provided to WITH-OUTPUT-TO-STRING (where the string is returned as its
    
+  value) and where a string with a fill pointer is provided and
    
+  destructively modified.  There is also a problem with string output
    
+  streams created by calls to FORMAT when its stream argument is NIL or
    
+  a string with a fill pointer, although users have to try harder to
    
+  get their hands on the stream object in that case.
    
+
    
+  It is also not clear what the effects of destructive modifications to
    
+  a string supplied as an argument to WITH-OUTPUT-TO-STRING or FORMAT
    
+  are supposed to be.
    
+
    
+Proposal (STRING-OUTPUT-STREAM-BASHING:UNDEFINED):
    
+
    
+  Clarify that the consequences of calling GET-OUTPUT-STREAM-STRING
    
+  on a stream created by WITH-OUTPUT-TO-STRING or FORMAT are undefined.
    
+  In the cases where a string argument with a fill pointer is supplied
    
+  as an argument to WITH-OUTPUT-TO-STRING or FORMAT, the consequences
    
+  are undefined if destructive modifications are performed directly on
    
+  the string during the dynamic extent of the call.
    
+
    
+Examples:
    
+
    
+  #1: (with-output-to-string (s)
    
+        (prin1 'foo s) (print (get-output-stream-string s))
    
+        (prin1 'bar s) (print (get-output-stream-string s)))
    
+
    
+      => Under proposal UNDEFINED, this program is in error.
    
+
    
+  #2: (let ((x  (make-array 100 :element-type 'standard-char :fill-pointer 0)))
    
+        (with-output-to-string (s x)
    
+          (prin1 'foo s) (print (get-output-stream-string s))
    
+          (prin1 'bar s) (print (get-output-stream-string s)))
    
+        x)
    
+  
    
+      => Under proposal UNDEFINED, this program is in error.
    
+
    
+  #3: (let ((x  (make-array 100 :element-type 'standard-char :fill-pointer 0)))
    
+        (with-output-to-string (s x)
    
+          (prin1 'foo s) (setf (fill-pointer x) 0)
    
+          (prin1 'bar s) (setf (fill-pointer x) 0))
    
+        x)
    
+
    
+      => Under proposal UNDEFINED, this program is in error.
    
+
    
+Rationale:
    
+
    
+  Calling GET-OUTPUT-STREAM-STRING is a destructive modification of
    
+  the stream being manipulated by WITH-OUTPUT-TO-STRING or FORMAT.  
    
+  It would be consistent with issue MAPPING-DESTRUCTIVE-INTERACTION 
    
+  to prohibit this.  Likewise, some implementations become confused if
    
+  the string with fill pointer underlying a string output stream is
    
+  modified directly.
    
+      
    
+Current Practice:
    
+
    
+  Lucid, Allegro, and Symbolics Genera all print "FOO" and "BAR" and 
    
+  return "" from test case 1, but vary in the behavior of the other
    
+  cases.
    
+
    
+Cost to Implementors:
    
+
    
+  No implementation would be forced to change by this proposal.
    
+
    
+Cost to Users:
    
+
    
+  Probably few user programs rely on any particular behavior here.
    
+
    
+Cost of non-adoption:
    
+
    
+  Continuing vagueness in the language specification.
    
+
    
+Performance impact:
    
+
    
+  N/A
    
+
    
+Benefits:
    
+
    
+  The costs of non-adoption are avoided.
    
+
    
+Esthetics:
    
+
    
+  It might be more esthetic to try to specify the behavior.  In the
    
+  case of WITH-OUTPUT-TO-STRING where no string argument is provided
    
+  and FORMAT with a stream argument of NIL, the behavior could easily
    
+  be explained in terms of the obvious implementation of these constructs 
    
+  using MAKE-STRING-OUTPUT-STREAM and GET-OUTPUT-STREAM-STRING.  However,
    
+  there are no corresponding primitives for creating a string stream from
    
+  a string with a fill pointer.
    
+
    
+Discussion:
    
+
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331.htm new file mode 100644 index 00000000..094ac4e1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331_w.htm new file mode 100644 index 00000000..d5dabce8 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss331_w.htm @@ -0,0 +1,111 @@ + + + +CLHS: Issue STRUCTURE-READ-PRINT-SYNTAX Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue STRUCTURE-READ-PRINT-SYNTAX Writeup

    + +
    Issue:              STRUCTURE-READ-PRINT-SYNTAX
    
+References:         DEFSTRUCT
    
+Related issues:     Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
    
+Category:           CHANGE
    
+Edit history:       V1, 11 May 90, Sandra Loosemore
    
+                    V2, 29 May 90, Sandra Loosemore (cross-references)
    
+  
    
+
    
+Problem description:
    
+
    
+The use of non-keywords for slot names in #S reader/printer
    
+syntax is ugly.  The standard ought to encourage a cleaner
    
+style.
    
+
    
+Proposal (STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS):
    
+
    
+  (1) Deprecate the use of non-keywords to name slots in #S syntax
    
+      for reading structures.
    
+
    
+  (2) Require that #S syntax for printing structures print slot
    
+      names as keywords.
    
+
    
+Rationale:
    
+
    
+  This encourages a cleaner style while maintaining backward
    
+  compatibility for users.
    
+   
    
+Current Practice:
    
+
    
+  Some implementations already use keywords for printing
    
+  structures, while some use unqualified symbols.  Practice among
    
+  users is also mixed.  Many users tend to follow the example of
    
+  whatever implementation they use most frequently.
    
+
    
+Cost to Implementors:
    
+
    
+  The actual implementation cost of changing the #S printer 
    
+  is trivial, but there may be more work involved in updating 
    
+  documentation.
    
+
    
+Cost to Users:
    
+
    
+   None.
    
+
    
+Cost of non-adoption:
    
+
    
+  See "esthetics".
    
+
    
+Performance impact:
    
+
    
+  Using keywords is probably slightly more efficient than using
    
+  unqualified symbols, at least on the reader end.
    
+
    
+Benefits:
    
+
    
+  See "esthetics".
    
+
    
+Esthetics:
    
+
    
+  The use of non-keywords to name slots in #s syntax is ugly.
    
+  Technically, there is no reason now why both users and
    
+  implementors cannot use keywords, but the fact that CLtL
    
+  goes out of its way to explain that it's not necessary to
    
+  do so, and that all of the examples of #s syntax use non-keywords, 
    
+  has encouraged both users and implementors to follow this style.
    
+
    
+Discussion:
    
+
    
+  Proposal DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR made
    
+  it clear that DEFSTRUCT slot names must have unique
    
+  symbol-names.  Therefore there is no possibility for conflicts
    
+  if the slot names are printed as keyword symbols.
    
+
    
+  Several people have voiced support for at least changing the
    
+  examples in the standard to use keywords, to encourage both
    
+  users and implementors to adopt the style.
    
+
    
+  Dan Pierson says:
    
+    Yes, YEs, YES!  I've been wanting this fix for bogus implementations
    
+    since CLtL came out and ******lisp interpreted it the other way.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332.htm new file mode 100644 index 00000000..74710de0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332.htm @@ -0,0 +1,54 @@ + + + +CLHS: Issue SUBSEQ-OUT-OF-BOUNDS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SUBSEQ-OUT-OF-BOUNDS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SUBSEQ-OUT-OF-BOUNDS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332_w.htm new file mode 100644 index 00000000..ecaa9738 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss332_w.htm @@ -0,0 +1,134 @@ + + + +CLHS: Issue SUBSEQ-OUT-OF-BOUNDS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SUBSEQ-OUT-OF-BOUNDS Writeup

    + +
    Issue:         SUBSEQ-OUT-OF-BOUNDS
    
+
    
+References:    :START and :END arguments (246-247), SUBSEQ (248)
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  24-Mar-88, Version 1 by Steele
    
+	       29-Mar-88, Version 2 by Steele, in response to Moon's comments
    
+
    
+Problem description:
    
+
    
+The descriptions of :START and :END arguments, and of SUBSEQ, do not
    
+explicitly address the question of out-of-bounds indices.  (The language on
    
+page 246, "These arguments should be integer indices into the sequence," is
    
+considered too vague on this point.)
    
+
    
+Also, the language on page 246 does not make clear whether the prohibition
    
+against "start > end" applies to defaulted values as well as explicit
    
+values, and does not specify clearly whether the default value for the
    
+end argument is the allocated length or the active length.
    
+
    
+
    
+Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):
    
+
    
+Specify that it is an error for the :START argument of any standard
    
+function, or the second argument to SUBSEQ, to be less than zero.
    
+
    
+Specify that it is an error for the :END argument of any standard function,
    
+or the third argument to SUBSEQ, to be greater than the active length of
    
+the sequence in question (as returned by LENGTH).
    
+
    
+Specify that the start value, after defaulting, must not be greater than
    
+the end value, after defaulting.
    
+
    
+Specify that the default value for the end argument is the active length of
    
+the sequence in question.
    
+
    
+This may be summarized as follows:
    
+
    
+Let X be the sequence within which indices are to be considered.  Let S be
    
+the :START argument of any standard function, or the second argument to
    
+SUBSEQ, whether explicitly specified or defaulted, through omission, to
    
+zero.  Let E be the :END argument of any standard function, or the third
    
+argument to SUBSEQ, whether explicitly specified or defaulted, through
    
+omission or an explicitly passed NIL value, to the active length of X, as
    
+returned by LENGTH.  It is an error if the condition (<= 0 S E (LENGTH X))
    
+is not true.
    
+
    
+Test Cases/Examples:
    
+
    
+(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".
    
+
    
+(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".
    
+
    
+(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".
    
+
    
+(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".
    
+
    
+Under this proposal each of these situations is an error, and portable
    
+programs may not rely on their behavior.
    
+
    
+Rationale:
    
+
    
+We don't want code indexing off the ends of arrays.
    
+
    
+Current practice:
    
+
    
+KCL interpreted and compiled code signals an error.
    
+
    
+Symbolics Common Lisp interpreted and compiled code signals an error; the
    
+compiler also issued an out-of-range warning (possible because the
    
+arguments were all constant).
    
+
    
+Lucid Common Lisp interpreted and compiled code signals an error.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+None.
    
+
    
+Cost to Users:
    
+
    
+Users who depended on some specific implementation behavior in these cases
    
+may find that their pragmatically unportable code is now officially
    
+unportable.
    
+
    
+Cost of non-adoption:
    
+
    
+Confusion.
    
+
    
+Benefits:
    
+
    
+Removal of a small but important ambiguity in the spec.
    
+
    
+Esthetics:
    
+
    
+It seems cleaner not to allow indexing off the end of an array, and
    
+by extension not allow it for any sequence.
    
+
    
+Discussion:
    
+
    
+This merely clarifies the original intent of the passage on page 246.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333.htm new file mode 100644 index 00000000..84f03488 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SUBSETTING-POSITION:NONE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SUBSETTING-POSITION:NONE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SUBSETTING-POSITION:NONE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333_w.htm new file mode 100644 index 00000000..5f878797 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss333_w.htm @@ -0,0 +1,165 @@ + + + +CLHS: Issue SUBSETTING-POSITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SUBSETTING-POSITION Writeup

    + +
    Issue:        SUBSETTING-POSITION
    
+References:   X3J13 committee and sub-committee meetings
    
+Category:     Policy
    
+Edit history: 12-DEC-88, Version 1 by Chapman
    
+              9-JAN-89, Version 2 by Chapman 
    
+              10-JAN-89, Version 3 by Chapman 
    
+              20-FEB-89, Version 4 by Chapman 
    
+              
    
+ 
    
+Problem Description:
    
+ 
    
+Should the CL standard be partitioned such that an implementation
    
+could chose a subset of all the CL facilities to implement and 
    
+still be a conforming implementation?
    
+What subsets should be specified in the draft standard we submit to
    
+ANSI?
    
+What position should we take if someone should propose a subset?
    
+
    
+Subsets might omit syntax, functions, admissable values or arguments
    
+to functions, or data types. For example, a subset might disallow SPECIAL
    
+declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
    
+might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
    
+to work on proper lists, or might omit complex numbers. Each of these is a
    
+"subset" in the sense that a subset of correct programs for the "full"
    
+language would be correct for the "subset" language.
    
+ 
    
+Subsets can have various levels of "determinability" for programs. The
    
+issue is: how easy is it to tell whether a program written in the "full"
    
+language would run in a "subset" implementation?  Except for the
    
+(non-trivial) issue of macro expansions, some subsets are "lexically"
    
+determinable, e.g., if a function is omitted, you can tell if the program
    
+uses it by scanning the program. Some subsets are "dynamically"
    
+determinable, e.g, a subset might signal an error if the :TEST argument to
    
+MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
    
+dynamically determinable, e.g., if the subset implements dynamic extent for
    
+rest lists, it may be impossible to tell even with run-type checks whether
    
+the a program written in the "full" language would conform.
    
+ 
    
+Some "subsets" might be merely restrictive interpretations, e.g., a
    
+"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
    
+BREAK halt the program execution rather than "enter the debugger"; since we
    
+cannot define what "enter the debugger" means, we might want to define
    
+explicitly this subset as a reasonable one for embedded systems.
    
+ 
    
+Proposal (SUBSETTING-POSITION:NONE)
    
+
    
+The draft standard we submit to ANSI contains *no* subsets. 
    
+In the section on "subsetting" it should be mentioned
    
+that Lisp is a "small" language with a "big" library.
    
+ 
    
+We are not opposed in principle to one or more subset definitions.
    
+ 
    
+ 
    
+Rationale:
    
+
    
+We have no well-defined proposals for subset definitions, and didn't have
    
+the time or energy to pursue their definition, or confidence that we could
    
+reach convergence on a reasonable definition.
    
+ 
    
+There are several properties that a subset definition must have to be
    
+considered: it must be well defined in terms of conformance of code, programs, 
    
+and implementations; all valid programs in the subset must be valid programs in
    
+the full language; the subset definition should address how it can be
    
+determined if  a program in the full language is valid in the subset. 
    
+ 
    
+ 
    
+ 
    
+Current Practice:
    
+ 
    
+Pascal has two levels of conforming implementations -- level 1 contains
    
+level 0 and conformant arrays. This was a compromise necessary to achieve
    
+international agreement. The 1981 PL/I was subsetted and the 
    
+results were a range of implementations between the
    
+subset and the full language; nobody wanted to use the subset so vendors
    
+were forced to implement the full language eventually anyway.
    
+Cobol had multiple levels of subsets. However, 
    
+the only two levels that were important were the minimum 
    
+subset and the full language. The middle levels were
    
+seldom used other than transient points to the full language.
    
+Fortran was subsetted. It was felt that subsetting encouraged
    
+vendors to implement Fortran and therefore proliferate its usage,
    
+but users were quite annoyed that one Fortran was considerably
    
+different from another. 
    
+The new Fortran language standards committee is
    
+banning subsetting.
    
+At one point, there was an ANSI standard for "Minimal Basic".  It was 
    
+too minimal. Later work on ANSI Basic involved a rather different-looking 
    
+language and a number of optional extensions for such things as real-time process control. 
    
+SPARC feels that subsets aren't good for facilitating interchange, but serve the
    
+purpose of allowing timely implementation of the standard.
    
+ 
    
+ 
    
+Adoption Cost:
    
+ 
    
+None.
    
+ 
    
+Benefits:
    
+ 
    
+This policy will provide a basis for making decisions in X3J13.
    
+ 
    
+Conversion Cost:
    
+ 
    
+None.
    
+ 
    
+Aesthetics:
    
+ 
    
+None.
    
+ 
    
+Discussion:
    
+Jeff Dalton says: 
    
+"I'd be happier if it were fairly easy for someone reading the standard
    
+to determine which part was the "library" and which the core language.
    
+For example, where do we find FUNCALL and APPLY?
    
+The draft C standard has an explicit division.  Section 3 is
    
+"Language" and section 4 is "Library".  It may not be necessary
    
+to go that far for Common Lisp."
    
+
    
+GLS says: "I am in agreement with SUBSETTING-POSITION:NONE."
    
+
    
+Loosemore says: "... even if the standard doesn't define
    
+any subsets, that is not going to prevent subsets from happening, and
    
+perhaps the standard ought to define some terminology to describe such
    
+implementations (even if it's only to say that they can't call
    
+themselves Common Lisps at all)."
    
+ 
    
+
    
+RPG says: "One point worth making might be that a conforming program that is
    
+delivered may not also be a conforming implementation."
    
+Paraphrased: 
    
+A conforming implementation does not have to be present in order to deliver
    
+a conforming program.
    
+One could produce a linkable version of an application that would 
    
+include almost no part of the Lisp environment.
    
+Therefore, subsets are not mandated for this case. 
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334.htm new file mode 100644 index 00000000..38c80f1c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue SUBTYPEP-ENVIRONMENT:ADD-ARG Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SUBTYPEP-ENVIRONMENT:ADD-ARG Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SUBTYPEP-ENVIRONMENT:ADD-ARG:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334_w.htm new file mode 100644 index 00000000..32a6f369 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss334_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue SUBTYPEP-ENVIRONMENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SUBTYPEP-ENVIRONMENT Writeup

    + +
    Issue:             SUBTYPEP-ENVIRONMENT
    
+References:        DEFTYPE,
    
+                   TYPEP, SUBTYPEP,
    
+                   UPGRADED-ARRAY-ELEMENT-TYPE,
    
+                   UPGRADED-COMPLEX-PART-TYPE
    
+Related issues:    Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    
+                   Issue CLOS-MACRO-COMPILATION
    
+                   Issue DEFTYPE-DESTRUCTURING
    
+                   Issue CONSTANTP-ENVIRONMENT
    
+Category:          CHANGE, ADDITION
    
+Edit history:      V1, 02 Jan 1989, ???
    
+                   V2, 12 Feb 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  Defining macros including DEFTYPE, DEFSTRUCT, DEFCLASS, and
    
+  DEFINE-CONDITION are permitted to note type definitions at
    
+  compile-time in such a way that those definitions are visible only to
    
+  the file compiler and not to the evaluator.  This can lead to
    
+  incorrect behavior in user code that deals with the type system, for
    
+  example in macro expansion functions.  Such code needs to explicitly
    
+  indicate in some way whether it wishes to deal with the type system as
    
+  seen by the file compiler (the "remote environment"), or in the 
    
+  current environment.
    
+
    
+Proposal (SUBTYPEP-ENVIRONMENT:ADD-ARG):
    
+
    
+  Add an optional environment argument to TYPEP, SUBTYPEP,
    
+  UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE.  If the
    
+  argument is NIL or not supplied, it defaults to the null lexical
    
+  environment and current global environment.
    
+
    
+  Clarify that &ENVIRONMENT may appear in the lambda-list of a DEFTYPE 
    
+  form, as with DEFMACRO.
    
+
    
+Examples:
    
+
    
+  ???
    
+
    
+Rationale:
    
+
    
+  This is consistent with the mechanism used elsewhere to specify what
    
+  environment name/definition lookups should be performed in.
    
+  
    
+Current Practice:
    
+
    
+  Chestnut's Lisp-to-C translator supports this mechanism.
    
+
    
+Cost to Implementors:
    
+
    
+  Minor.  Implementations that don't support the notion of "remote
    
+  environments" can ignore the environment arguments.
    
+
    
+Cost to Users:
    
+
    
+  Minor.  Users may have to be more careful about passing environment
    
+  arguments around.
    
+
    
+Cost of non-adoption:
    
+
    
+  Programs that try to manipulate type information at compile-time will
    
+  break in some implementations.
    
+
    
+Performance impact:
    
+
    
+  Minor.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Looks OK to me.
    
+
    
+Discussion:
    
+
    
+  Version 1 of this issue was lost.  Version 2 is a completely new
    
+  writeup.
    
+
    
+  Loosemore and Barrett support this proposal.
    
+
    
+  There may be confusion about why TYPE-OF does not need an
    
+  environment argument.  Recall that compile-time type definitions made
    
+  by DEFSTRUCT, DEFCLASS, and DEFINE-CONDITION are permitted to be
    
+  partial or incomplete.  Essentially, the only information that is
    
+  required at compile-time is that a name/type mapping exists and the
    
+  subtype/supertype relationships between all of the type specifiers.
    
+  On the other hand, the type must be fully defined before instances can
    
+  be created.  If no instances can be created, then TYPE-OF has no need
    
+  to know about the type.  TYPE-OF also has no need to know about type
    
+  specifiers defined with DEFTYPE.
    
+
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335.htm new file mode 100644 index 00000000..cdaac081 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SUBTYPEP-TOO-VAGUE:CLARIFY-MORE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SUBTYPEP-TOO-VAGUE:CLARIFY-MORE Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SUBTYPEP-TOO-VAGUE:CLARIFY-MORE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335_w.htm new file mode 100644 index 00000000..ccfd097d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss335_w.htm @@ -0,0 +1,169 @@ + + + +CLHS: Issue SUBTYPEP-TOO-VAGUE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SUBTYPEP-TOO-VAGUE Writeup

    + +
    Status:	Passed, as amended, Jun89 X3J13
    
+Issue:		SUBTYPEP-TOO-VAGUE
    
+References:	CLtL p. 72-73
    
+Category:	CLARIFICATION
    
+Edit History:   Version 1, 11 Jul 1988 (Sandra Loosemore)
    
+                Version 2, 19 Jul 1988 (Sandra Loosemore)
    
+                Version 3,  6-Oct-88 (Masinter)
    
+                Version 4,  7-Oct-88 (Masinter, per Moon's comments)
    
+		Version 5, 15-Mar-89 Steele
    
+		Version 6, 2-Jul-89 Masinter (as per Jun89X3J13)
    
+Problem Description:
    
+
    
+[From version 4]
    
+
    
+The description of SUBTYPEP allows it to return a second value of NIL
    
+when the relationship between the two types cannot be determined.  In
    
+some cases this is a reasonable thing to do because it is impossible
    
+to tell (if the SATISFIES type specifier is involved), and in other
    
+cases the relationships between types are not well-defined (for
    
+example, the VALUES type specifier or the list form of the FUNCTION
    
+type specifier). 
    
+
    
+Some implementations, however, have apparently interpreted this to
    
+mean that it is permissible for SUBTYPEP to "give up" and return a
    
+second value of NIL in some cases where it actually would be possible
    
+to determine the relationship.  This makes it difficult to depend on
    
+subtype relationships in portable code.
    
+
    
+[Addition for version 5]
    
+
    
+There are two problems with version 4.  First is that of the first three
    
+bulleted points in the version 4 proposal:
    
+
    
+    * Clarify that SUBTYPEP will return a second value of NIL
    
+    only when either of the type specifiers involves the SATISFIES, NOT, 
    
+    AND, OR, MEMBER. SUBTYPEP will not return a second
    
+    value of NIL when both arguments involve only the words in Table 4-1, or
    
+    names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
    
+    that expand into only those words and/or names.
    
+
    
+    * SUBTYPEP should signal an error when handed (for either argument)
    
+    a type specifier that involves VALUES or the list form of the FUNCTION
    
+    type.
    
+
    
+    * SUBTYPEP must always return values T T in the case where the two
    
+    type specifiers (or their expansions) are EQUAL.
    
+
    
+any two have significant overlap, and indeed all three can overlap;
    
+version 4 contained no indication of how this conflict should be resolved.
    
+
    
+Second is that version 4 calls for SUBTYPEP to signal an error (at least at
    
+high safety)even when the arguments are valid type specifiers, but this can
    
+make it harder to use SUBTYPEP.  These are cases that returning NIL NIL
    
+was supposed to cover.
    
+
    
+This version replaces the three bulleted points above with a single point
    
+and some observations about its consequences.  This version eliminates
    
+the requirement to signal an error.
    
+
    
+
    
+Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
    
+
    
+A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
    
+if it either contains it directly as a type specifier, 
    
+or as the result of expansion of a DEFTYPE  defined type specifier. 
    
+(While the type specifiers listed in CLtL Table 4-1 and names of
    
+DEFSTRUCT or DEFCLASS-defined types may, in some cases, be implemented
    
+in terms of DEFTYPE, they are to be regarded for this purpose as not
    
+being "user-defined". Therefore, SUBTYPEP must regard elements as
    
+primitive with respect to the question of returning NIL NIL.)
    
+
    
+* Clarify that SUBTYPEP is permitted to return NIL NIL only when
    
+  at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
    
+  VALUES, or the list form of FUNCTION.
    
+
    
+  Note that one consequence of this is that if neither argument
    
+  involves any of these type specifiers, then SUBTYPEP is obliged
    
+  to determine the relationship accurately.  In particular, SUBTYPEP
    
+  must return T T if the arguments are EQUAL and do not involve
    
+  any of the above-stated type specifiers.
    
+
    
+* Clarify that the relationships between types reflected by SUBTYPEP
    
+are those specific to the particular implementation.  For example, if
    
+an implementation supports only a single type of floating-point numbers,
    
+in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
    
+(since the two types would be identical).
    
+
    
+Rationale:
    
+
    
+Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
    
+programs cannot rely on any more than NIL NIL as return values.
    
+
    
+It is generally conceded that it is impossible to determine the
    
+relationships between types defined with the SATISFIES specifier.
    
+MEMBER, AND, OR, and NOT are messy to deal with.   
    
+
    
+Current Practice:
    
+
    
+The implementation of SUBTYPEP in (the original) HPCL does not try to
    
+expand type specifiers defined with DEFTYPE and does not recognize
    
+EQUAL type specifiers as being equivalent.  Most other implementations
    
+appear to be substantially in conformance with the proposal.
    
+
    
+Cost to implementors:
    
+
    
+Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
    
+
    
+Cost to users:
    
+
    
+Its hard to imagine a portable program that depends heavily
    
+on SUBTYPEP. This proposal does not require any implementation
    
+to "handle" fewer cases of SUBTYPEP.
    
+
    
+Benefits:
    
+
    
+An area of confusion in the language is cleared up.  Usages of SUBTYPEP
    
+will be more portable.
    
+
    
+Discussion:
    
+
    
+The handling of FLOAT and SINGLE-FLOAT  appeared to be the 
    
+consensus from a discussion on the common-lisp mailing list some
    
+ time ago.
    
+
    
+It would not be too onerous to require implementations to handle
    
+the cases where one but not the other type specifier involves
    
+OR, AND, NOT or MEMBER, but the specification becomes 
    
+cumbersome.
    
+
    
+A related issue is clarifying what kinds of type specifiers must be
    
+recognized by functions such as MAKE-SEQUENCE and COERCE.  For example,
    
+HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
    
+sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
    
+recognize it to be a subtype of SEQUENCE.  Should this proposal be
    
+extended to deal with these issues, or is another proposal in order?
    
+
    
+The rules for comparing the various type specifiers (such as ARRAY)
    
+need to be spelled out in detail.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336.htm new file mode 100644 index 00000000..c775fbcc --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SXHASH-DEFINITION:SIMILAR-FOR-SXHASH Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SXHASH-DEFINITION:SIMILAR-FOR-SXHASH Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SXHASH-DEFINITION:SIMILAR-FOR-SXHASH:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336_w.htm new file mode 100644 index 00000000..083a439a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss336_w.htm @@ -0,0 +1,194 @@ + + + +CLHS: Issue SXHASH-DEFINITION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SXHASH-DEFINITION Writeup

    + +
    Issue:            SXHASH-DEFINITION
    
+References:       SXHASH, "similarity as constants"
    
+Related issues:   CONSTANT-COMPILABLE-TYPES
    
+                  COMPILE-FILE-SYMBOL-HANDLING
    
+                  CONSTANT-COLLAPSING
    
+                  HASH-TABLE-KEY-MODIFICATION
    
+Category:         CLARIFICATION, CHANGE
    
+Edit history:     v1, 14 Feb 1991, Sandra Loosemore
    
+                  v2, 19 Feb 1991, Sandra Loosemore (comments from KAB)
    
+                  v3, 11 Mar 1991, Sandra Loosemore (additional proposals)
    
+                  v4, 13 Mar 1991, Sandra Loosemore (new proposal)
    
+                  v5, 26 Mar 1991, Sandra Loosemore (amendment from meeting)
    
+Status:           v5 (proposal SIMILAR-FOR-SXHASH) accepted by X3J13, Mar 1991
    
+
    
+Problem description:
    
+
    
+  The definition of the SXHASH function is confusing.  The relevant
    
+  words from CLtL are:
    
+
    
+    SXHASH computes a hash code for an object and returns the hash
    
+    code as a non-negative fixnum.  A property of SXHASH is that
    
+    (EQUAL <x> <y>) implies (= (SXHASH <x>) (SXHASH <y>)).
    
+  
    
+    The manner in which the hash code is computed is implementation-
    
+    dependent but independent of the particular "incarnation" or "core
    
+    image".  Hash values produced by SXHASH may be written out to files,
    
+    for example, and meaningfully read in again into an instance of the
    
+    same implementation.
    
+
    
+  Different people have different interpretations of what the second
    
+  paragraph is trying to say.
    
+
    
+  An additional problem is that the effects on SXHASH of destructive 
    
+  operations on the object are not well-specified.  Issue 
    
+  HASH-TABLE-KEY-MODIFICATION dealt only with objects used as keys in 
    
+  hash tables, not with SXHASH.
    
+
    
+
    
+Proposal (SXHASH-DEFINITION:SIMILAR-FOR-SXHASH):
    
+
    
+  Define SXHASH as a function with these properties:
    
+
    
+  (1) The result is a non-negative fixnum.
    
+
    
+  (2) (EQUAL x y) implies (= (SXHASH x) (SXHASH y)).
    
+
    
+  (3) If x and y are "similar for SXHASH", then (SXHASH x) and 
    
+      (SXHASH y) return the same mathematical value even if x and y
    
+      exist in different sessions of the same Lisp implementation.
    
+
    
+      Objects are "similar for SXHASH" if they are of type string, 
    
+      bit-vector, character, cons, number, pathname or symbol, and
    
+      are "similar as constants".
    
+
    
+      [This assumes that a bug in the specification of "similar as
    
+      constants" for pathnames (from issue CONSTANT-COMPILABLE-TYPES) is
    
+      going to be fixed by the editor.  The problem is that the definition
    
+      of "similar as constants" now implies that the pathname components are
    
+      recursively compared for being "similar as constants", while EQUAL
    
+      talks about components merely being "equivalent".  If this change to
    
+      "similar as constants" is not made, then the presentation of SXHASH
    
+      must describe the relationship for pathnames separately, in a way that
    
+      is compatible with EQUAL.]
    
+
    
+  (4) The function is intended for hashing so implementations should
    
+      return values well distributed within the range of non-negative
    
+      fixnums.
    
+
    
+  (5) The value returned by SXHASH on an object within a single session 
    
+      is constant provided that the object is not visibly modified with 
    
+      regard to the equivalence test EQUAL (as defined in proposal
    
+      HASH-TABLE-KEY-MODIFICATION:SPECIFY).
    
+
    
+  (6) SXHASH must terminate.
    
+
    
+
    
+Implementation Notes:
    
+
    
+  For objects of other types that EQUAL compares with EQ, item 5
    
+  restricts SXHASH to assigning the hash code based on some immutable
    
+  attribute of the identity of the object, such as its type.  Another
    
+  legitimate implementation technique would be to have SXHASH assign 
    
+  (and cache) a random hash code for these objects, since there is
    
+  no requirement that "similar" but non-EQ objects have the same hash
    
+  code.
    
+  
    
+  Although the "similar as constants" relationship on symbols is defined
    
+  in terms of both the symbol's name and the packages it is accessible
    
+  in, item 5 disallows using package information to compute the hash
    
+  code, since changes to the package status of a symbol are not visible
    
+  to EQUAL.
    
+  
    
+Rationale:
    
+
    
+  This is probably what CLtL meant to say.  Basically, what the proposal
    
+  does is to combine the original definition of SXHASH's relationship
    
+  with EQUAL with using "similar as constants" to compare objects that
    
+  exist in different Lisp sessions.  For types where EQUAL and "similar
    
+  as constants" differ, or where "similar as constants" is not
    
+  well-defined, the relationship between Lisp sessions is unspecified.
    
+
    
+Current Practice:
    
+
    
+  Unknown.  In many implementations, the hash values returned by
    
+  SXHASH for objects of types that EQUAL compares with EQ are 
    
+  apparently based on the type of the object.
    
+
    
+  JonL says he knows of at least one implementation that keeps a
    
+  hash-number slot inside every stored object.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably not too large.
    
+
    
+Cost to Users:
    
+
    
+  The current definition of SXHASH is pretty garbled and probably
    
+  most uses of SXHASH do not depend on much more than the relationship to
    
+  EQUAL.  That relationship is preserved in proposal SIMILAR-FOR-SXHASH.
    
+
    
+  Some users may have interpreted the read/print consistency language
    
+  in CLtL to require stricter behavior for SXHASH than is specified by
    
+  the current proposal.  For example, some uses of SXHASH might assume 
    
+  that arrays that are "similar" under read/print consistency have
    
+  the same hash codes.  These applications could break in implementations
    
+  that choose to assign unique hash codes to non-EQ arrays.
    
+  
    
+Cost of non-adoption:
    
+
    
+  The definition of SXHASH will continue to be garbled.  SXHASH will
    
+  be of limited usefulness.
    
+
    
+Performance impact:
    
+
    
+  Probably small.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Better than the way things are now.
    
+
    
+Discussion:
    
+
    
+  This issue was discussed briefly on the x3j13 mailing list in 
    
+  November 89, but not written up until now.
    
+
    
+  There has been quite a bit of discussion about whether SXHASH should
    
+  be required to "work" on circular objects.  Some have argued that such
    
+  a requirement would make it more useful, but others claim that it's
    
+  pointless to make the requirement since EQUAL doesn't have to "work"
    
+  on circular objects.
    
+
    
+  Barrett says he is concerned about proposal SIMILAR-FOR-SXHASH 
    
+  potentially breaking applications that depend on SXHASH returning
    
+  the same values for arrays, etc. that are "similar", but concludes
    
+  that trying to specify what attributes of these objects might or might
    
+  not be used to compute the hash value is probably not practical.
    
+
    
+  Loosemore, Barrett, Moon, and MacLachlan have expressed agreement in
    
+  principle with proposal SIMILAR-FOR-SXHASH.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337.htm new file mode 100644 index 00000000..bb084664 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue SYMBOL-MACROLET-DECLARE:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SYMBOL-MACROLET-DECLARE:ALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SYMBOL-MACROLET-DECLARE:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337_w.htm new file mode 100644 index 00000000..74f10a66 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss337_w.htm @@ -0,0 +1,108 @@ + + + +CLHS: Issue SYMBOL-MACROLET-DECLARE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SYMBOL-MACROLET-DECLARE Writeup

    + +
    Issue:         SYMBOL-MACROLET-DECLARE
    
+
    
+References:    SYMBOL-MACROLET (88-002R page 2-81)
    
+               WITH-ACCESSORS (88-002R page 2-88)
    
+               WITH-SLOTS (88-002R page 2-92)
    
+
    
+Related Issues: SYMBOL-MACROLET-SEMANTICS
    
+               FLET-DECLARATIONS (passed)
    
+
    
+Category:      ADDITION
    
+
    
+Edit history:  Version 1, 12-Sep-88, Moon
    
+               Version 2,  9-Dec-88, Masinter
    
+                 (add cross reference, discussion)
    
+
    
+Problem description:
    
+
    
+It would be both natural and nice to be able to write
    
+
    
+  (with-slots (rho theta) point
    
+    (declare (single-float rho theta))
    
+    ...computation...)
    
+
    
+Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
    
+	  
    
+Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
    
+in WITH-ACCESSORS and WITH-SLOTS.  Exactly the same declarations are
    
+allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
    
+if a SPECIAL declaration names one of the symbols being defined as a
    
+symbol-macrolet.  A type declaration of one of these symbols is equivalent
    
+to wrapping a THE expression around the expansion of that symbol.
    
+
    
+Example:
    
+
    
+See problem description.
    
+
    
+Rationale:
    
+
    
+If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
    
+allow declarations.  When writing a SYMBOL-MACROLET directly, the user
    
+could just as easily write a THE expression instead of a type
    
+declaration.  However, when invoking a macro such as WITH-SLOTS that
    
+expands into SYMBOL-MACROLET, the user does not have this option since
    
+the expansion is not supplied explicitly by the user.
    
+
    
+Current practice:
    
+
    
+SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
    
+
    
+Cost to Implementors:
    
+
    
+Less than one man-hour.
    
+
    
+Cost to Users:
    
+
    
+None.
    
+
    
+Cost of non-adoption:
    
+
    
+Minor wart in the language.
    
+
    
+Benefits:
    
+
    
+More consistent language definition.
    
+
    
+Esthetics:
    
+
    
+More consistent language definition.
    
+
    
+Discussion:
    
+
    
+This issue is related to SYMBOL-MACROLET-SEMANTICS.
    
+
    
+"A macro-definition for SYMBOL-MACROLET would leave the issue of
    
+DECLARE open.  But the special-form version of SYMBOL-MACROLET
    
+really should address it."
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338.htm new file mode 100644 index 00000000..5a161c28 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338.htm @@ -0,0 +1,40 @@ + + + +CLHS: Issue SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338_w.htm new file mode 100644 index 00000000..24a56f3e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss338_w.htm @@ -0,0 +1,174 @@ + + + +CLHS: Issue SYMBOL-MACROLET-SEMANTICS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SYMBOL-MACROLET-SEMANTICS Writeup

    + +
    Status: Version 5 passed Jan 89 X3J13
    
+	Version 6 passed Mar 89 X3J13
    
+
    
+Issue:		SYMBOL-MACROLET-SEMANTICS
    
+References:	SYMBOL-MACROLET (88-002R page 2-81)
    
+
    
+
    
+Related Issues: SYMBOL-MACROLET-DECLARE
    
+Category:	CHANGE
    
+Edit history:	29-July-88, Version 1 by Piazza
    
+		21-September-88, Version 2 by Piazza
    
+		22-September-88, Version 3 by Piazza 
    
+		22-September-88, Version 4 by Piazza
    
+		30-Nov-88, Version 5 by Masinter
    
+		14-Mar-89, Version 6 by Steele
    
+
    
+Problem Description:
    
+
    
+    The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
    
+    88-002R, profoundly alters the interpretation of symbols appearing as
    
+    forms in a Common Lisp program--what previously was necessarily a variable
    
+    might now be a symbol macro instead.  Macros which appear in the body of a
    
+    SYMBOL-MACROLET form are currently unable to determine whether a symbol
    
+    form is a variable or a symbol macro, and, if the latter, what the
    
+    expansion of the symbol macro is.  Consequently, complex macros (such as
    
+    SETF or PUSH) which depend on the form of their argument(s), are unable to
    
+    produce their desired results in some cases, as in the following example:
    
+
    
+	    (let ((a (make-array 5))
    
+		  (i 0))
    
+	      (symbol-macrolet ((place  (aref a (incf i))))
    
+	        (push x place))
    
+	      i)		==> 2
    
+
    
+    In addition, it would be both natural and nice to be able to write
    
+
    
+  (with-slots (rho theta) point
    
+    (declare (single-float rho theta))
    
+    ...computation...)
    
+
    
+    as well as DECLARE within SYMBOL-MACROLET forms.
    
+
    
+Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
    
+
    
+    Change the definition of SYMBOL-MACROLET to specify that it is a special
    
+    form, which affects the evaluation environment for symbols.  Enhance
    
+    MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
    
+    Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
    
+    even symbol subforms.  Specify that the expansion of a symbol macro IS
    
+    subject to further macro expansion in the same lexical environment as the
    
+    symbol macro invocation, exactly analogous to normal macros. Clarify that
    
+    within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
    
+    a symbol macro will be treated as if it were a SETF.
    
+
    
+    Furthermore PSETQ of a symbol defined as a symbol macro will
    
+    behave as if it were a PSETF, and MULTIPLE-VALUE-SETQ will behave
    
+    as if SETQ were used on each variable to be set.
    
+
    
+    When MACROEXPAND or MACROEXPAND-1 sees a symbol macro, it calls
    
+    the value of *MACROEXPAND-HOOK* in the same manner as for an
    
+    ordinary macro.  The three values given to the hook function
    
+    in this case will be an expansion function, a form (in this case
    
+    the symbol naming the symbol macro), and an environment.  The
    
+    only guaranteed property of the expansion function is that when
    
+    it is applied to the form and the environment it will return the
    
+    correct expansion of the symbol macro.  (In particular, nothing
    
+    it said in this specification whether the expansion is conceptually
    
+    stored in the expansion function, the environment, or both.)
    
+
    
+Rationale:
    
+
    
+    The potential for interaction between macros is exactly why &environment
    
+    arguments were originally added to macros.  Changing SYMBOL-MACROLET to be
    
+    a special form, which communicates through the &environment arguments to
    
+    macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
    
+    (among others) to work with SYMBOL-MACROLET in the same way they work with
    
+    MACROLET.
    
+
    
+    This change cannot (reasonably) support the currently specified semantics
    
+    that the expansion text is "outside" the scope of the symbol macro.  For
    
+    indeed, when the symbol macro is expanded, (a copy of) the expansion is
    
+    then within the scope of the SYMBOL-MACROLET, and should then be subject
    
+    to further scrutiny.  The issue of "infinite expansion" of symbol macros is
    
+    no more dangerous than that of normal macros.
    
+
    
+Current Practice:
    
+
    
+    Portable Common Loops provides a code-walking implementation of
    
+    SYMBOL-MACROLET as specified in 88-002R.  Symbolics Cloe has both a
    
+    code-walking version of a SYMBOL-MACROLET macro and compiler support for
    
+    a SYMBOL-MACROLET special form.
    
+
    
+Cost to Implementors:
    
+
    
+    If SYMBOL-MACROLET is modified to be a special form, compilers and
    
+    interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
    
+    PUSH, INCF, DECF, and others.
    
+
    
+Cost to Users:
    
+
    
+    If SYMBOL-MACROLET is converted to a special form, code-walking programs
    
+    will have to be modified to handle SYMBOL-MACROLET correctly.  Those same
    
+    programs would have to be modified to handle the other special forms
    
+    specified in CLOS, anyway.
    
+
    
+Cost of Non-Adoption:
    
+
    
+    SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
    
+    it interacts with complex macros and forms which produce side-effects.
    
+
    
+    Implementations which support ONCE-ONLY will break.  For that matter, any
    
+    mechanism which examines code and assumes that "variables" have no side
    
+    effects will break.
    
+
    
+Benefits:
    
+
    
+    SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
    
+    surrounding interaction of macros (like SETF) and side effects, and makes
    
+    SYMBOL-MACROLET consistent with MACROLET.
    
+
    
+Aesthetics:
    
+
    
+    If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
    
+    by making symbol macros consistent with normal macros.
    
+
    
+Discussion:
    
+
    
+    A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
    
+    a dual of MACRO-FUNCTION.  However, symbol macros are simpler than normal
    
+    macros: a symbol macro is associated with a single expansion form, rather
    
+    than an arbitrary function which computes the expansion.  For this reason,
    
+    the augmented MACROEXPAND-1 proposed here can also fill the role of
    
+    SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
    
+    T if and only if sym is a symbol macro, while the first value gives the
    
+    expansion of sym, if it has one.
    
+
    
+    Rather than extending the existing MACROEXPAND and MACROEXPAND-1
    
+   functions, new functions could be introduced to expand symbol macros. 
    
+   However, there seems to be no particular reason to do this.
    
+
    
+
    
+
    
+     ----- End Forwarded Messages -----
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339.htm new file mode 100644 index 00000000..003a102a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SYMBOL-MACROLET-TYPE-DECLARATION:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SYMBOL-MACROLET-TYPE-DECLARATION:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SYMBOL-MACROLET-TYPE-DECLARATION:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339_w.htm new file mode 100644 index 00000000..c4f82045 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss339_w.htm @@ -0,0 +1,162 @@ + + + +CLHS: Issue SYMBOL-MACROLET-TYPE-DECLARATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SYMBOL-MACROLET-TYPE-DECLARATION Writeup

    + +
    Issue:              SYMBOL-MACROLET-TYPE-DECLARATION
    
+References:         SYMBOL-MACROLET, DECLARE
    
+Related issues:     SYMBOL-MACROLET-DECLARE
    
+                    SYNTACTIC-ENVIRONMENT-ACCESS
    
+Category:           CLARIFICATON
    
+Edit history:       v1, 13 Feb 1991, Sandra Loosemore
    
+                    v2, 11 Mar 1991, Sandra Loosemore (new proposal PROBABLY)
    
+
    
+Problem description:
    
+
    
+Proposal SYMBOL-MACROLET-DECLARE:ALLOW says that a type declaration of
    
+a symbol defined as a symbol-macro "is equivalent to wrapping a THE
    
+expression around the expansion of that symbol".  There is disagreement
    
+about whether "equivalence" was intended to mean "semantic equivalence"
    
+or "literal equivalence".  In other words, must (or might) the value 
    
+returned by MACROEXPAND or MACROEXPAND-1 include a THE form if there
    
+are type declarations that apply to the symbol-macro being expanded?
    
+
    
+There are four proposals, YES, NO, MAYBE, and PROBABLY.
    
+
    
+Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:YES):
    
+
    
+  Clarify that the equivalence is literal.  If a type declaration
    
+  is provided for a name that is bound as a symbol-macro, that type
    
+  information must appear in the expansion of the symbol-macro 
    
+  returned by MACROEXPAND or MACROEXPAND-1 as a THE form wrapped around 
    
+  the expansion provided in its definition.
    
+
    
+  Rationale for proposal YES:
    
+
    
+    If the macroexpansion doesn't include the type information, it can
    
+    be lost completely.
    
+
    
+
    
+Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:NO):
    
+
    
+  Clarify that the equivalence is only in effect.  The macroexpansion 
    
+  of a symbol-macro returned by MACROEXPAND or MACROEXPAND-1 is exactly
    
+  the expansion provided in its definition.
    
+
    
+  Rationale for proposal NO:
    
+
    
+    As long as we permit implementations to discard declarations as a 
    
+    matter of policy, it's unreasonable type declarations on symbol
    
+    macros to be collected.
    
+
    
+    Type declarations about symbol-macros need not be lost during
    
+    macroexpansion, since this information is returned by the
    
+    VARIABLE-INFORMATION function.  A code walker could wrap a THE
    
+    form around the expansion returned by MACROEXPAND-1 itself, if
    
+    it wished to do so.
    
+
    
+    Maybe some programs depend on the expansion of a symbol-macro being
    
+    exactly the same as what was specified in its definition.
    
+
    
+
    
+Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:MAYBE):
    
+
    
+  Clarify that the equivalence may be either literal or only in effect.
    
+  The macroexpansion of a symbol-macro returned by MACROEXPAND or
    
+  MACROEXPAND-1 might or might not include a THE form wrapped around
    
+  the the expansion provided in its definition.
    
+
    
+  Rationale for proposal MAYBE:
    
+
    
+    Some implementations might want to do things this way.  Other
    
+    implementations might not.
    
+
    
+
    
+Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:PROBABLY):
    
+
    
+  Clarify that the equivalence is literal.  If there is type information
    
+  available in the environment in which the expansion occurs, then that
    
+  type information must appear in the expansion of the symbol-macro 
    
+  returned by MACROEXPAND or MACROEXPAND-1 as a THE form wrapped around 
    
+  the expansion provided in its definition.
    
+
    
+  Rationale for proposal PROBABLY:
    
+
    
+    If the macroexpansion doesn't include the type information, it can
    
+    be lost completely.  However, this proposal makes no requirement that
    
+    type declarations actually be collected (but it does imply that
    
+    type declarations added by an explicit use of AUGMENT-ENVIRONMENT
    
+    will be reflected in the expansions).
    
+
    
+
    
+Current Practice:
    
+
    
+  I don't know.
    
+
    
+Cost to Implementors:
    
+
    
+  In an implementation that discards type declarations, probably quite
    
+  a bit of work would be involved to support proposal YES.  However it
    
+  may be that the implementors are doing this work anyway to support
    
+  the other syntactic-environment-access proposals.
    
+
    
+Cost to Users:
    
+
    
+  Hard to say.  Probably there are few programs that depend on any
    
+  particular behavior here.
    
+
    
+Cost of non-adoption:
    
+
    
+  Continuing confusion about how to write a code walker.
    
+
    
+Performance impact:
    
+
    
+  Most of the overhead is in keeping track of type declarations.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Seems to depend on who you talk to.
    
+
    
+Discussion:
    
+
    
+  Kim Barrett supports proposal PROBABLY.
    
+
    
+  Kent Pitman says:
    
+    ...unless we're going to force declarations to be enforced, it 
    
+   isn't reasonable to make this requirement on macroexpansion.
    
+
    
+  Loosemore supports proposal NO, not only because of this problem,
    
+  but because it just seems unnecessarily complicated to force 
    
+  MACROEXPAND to deal with declarations when there are other mechanisms 
    
+  for retrieving this information available to code walkers.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340.htm new file mode 100644 index 00000000..bbdef249 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340_w.htm new file mode 100644 index 00000000..dba9a307 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss340_w.htm @@ -0,0 +1,186 @@ + + + +CLHS: Issue SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS Writeup

    + +
    Issue:            SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS
    
+References:       SYMBOL-MACROLET, SPECIAL proclamation,
    
+                  AUGMENT-ENVIRONMENT,
    
+                  CONSTANTP, VARIABLE-INFORMATION
    
+Related issues:   Issue SYMBOL-MACROLET-DECLARE
    
+                  Issue SYMBOL-MACROLET-SEMANTICS
    
+                  Issue SYNTACTIC-ENVIRONMENT-ACCESS
    
+                  Issue CONSTANTP-ENVIRONMENT
    
+                  Issue CONSTANTP-DEFINITION
    
+Category:         CLARIFICATION
    
+Edit history:     v1, 15 Feb 1991, Sandra Loosemore
    
+                  v2, 13 Mar 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  Can a symbol-macro definition shadow a variable that has been
    
+  PROCLAIMed SPECIAL or defined as a constant using DEFCONSTANT?
    
+
    
+  Both SPECIAL proclamations and DEFCONSTANT definitions pervasively
    
+  affect the semantics of variable bindings.  The question is whether a
    
+  symbol-macro binding of a symbol in the variable namespace is a 
    
+  variable binding in this sense.
    
+
    
+  Note that issues SYMBOL-MACROLET-DECLARE and SYNTACTIC-ENVIRONMENT-ACCESS
    
+  require that an error be signalled if a SPECIAL declaration is supplied 
    
+  for a name being bound as a symbol-macro.
    
+
    
+  There are two proposals, SHADOWING-PERMITTED and SIGNALS-AN-ERROR.
    
+
    
+Proposal (SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED):
    
+
    
+  Clarify that a SYMBOL-MACRO definition of a symbol shadows any other
    
+  interpretation of that symbol as a variable, even if the symbol is
    
+  a keyword or has been PROCLAIMed SPECIAL or defined as a constant 
    
+  using DEFCONSTANT.
    
+
    
+  Note that lexical shadowing of keywords and defined constants 
    
+  requires the use of an environment argument with CONSTANTP (see issue 
    
+  CONSTANTP-ENVIRONMENT).  Clarify that if the first argument to
    
+  CONSTANTP is a symbol that is a keyword or globally defined as a 
    
+  constant, CONSTANTP must return true only if that symbol is not 
    
+  lexically shadowed by a symbol-macro definition in the specified 
    
+  environment.  Likewise, VARIABLE-INFORMATION returns :SYMBOL-MACRO 
    
+  rather than :CONSTANT as its first value if the symbol is a keyword 
    
+  or defined constant that has been lexically shadowed by a symbol-macro 
    
+  definition in the specified environment.
    
+
    
+  Rationale:
    
+
    
+    This is a reasonable interpretation to some people.
    
+
    
+
    
+Proposal (SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR):
    
+
    
+  Clarify that a SYMBOL-MACRO definition of a symbol that is a keyword
    
+  or that has been PROCLAIMed SPECIAL or defined as a constant using
    
+  DEFCONSTANT is not permitted.
    
+
    
+  Require SYMBOL-MACROLET to signal an error if any of the symbols being 
    
+  bound as a symbol-macro are keywords, PROCLAIMed SPECIAL or defined as
    
+  a constant using DEFCONSTANT.
    
+
    
+  Require AUGMENT-ENVIRONMENT to signal an error if any of the symbols in 
    
+  the :SYMBOL-MACRO alist are keywords, PROCLAIMed SPECIAL or defined as a
    
+  constant using DEFCONSTANT.
    
+
    
+  Rationale:
    
+
    
+    This is a reasonable interpretation to some people.
    
+
    
+    There is also a compatibility problem if CONSTANTP is permitted to
    
+    be sensitive to the lexical environment in which the form appears 
    
+    (see the cost to users section below).
    
+
    
+
    
+Examples:
    
+
    
+  #1:  (defvar *foo* nil)
    
+       (symbol-macrolet ((*foo*  t))
    
+           *foo*)
    
+
    
+       Under proposal SHADOWING-PERMITTED, this returns T.
    
+       Under proposal SIGNALS-AN-ERROR, an error is signalled.
    
+
    
+
    
+  #2:  (defconstant frob "frob-constant")
    
+       (defmacro see-if-constant (form)
    
+           `(progn ,form ,(constantp form)))
    
+       (symbol-macrolet ((frob (funcall #'some-hairy-function)))
    
+           (see-if-constant frob))
    
+
    
+       Under proposal SHADOWING-PERMITTED, this returns T; note that
    
+           the call to CONSTANTP returns a value appropriate for the
    
+           null lexical environment but does not take into account the
    
+           local symbol-macro definition of FROB.
    
+
    
+       Under proposal SIGNALS-AN-ERROR, an error is signalled.
    
+
    
+
    
+Current Practice:
    
+
    
+  Apparently shadowing is permitted in some implementations but not
    
+  others.
    
+
    
+Cost to Implementors:
    
+
    
+  Proposal SHADOWING-PERMITTED is more work than SIGNALS-AN-ERROR
    
+  since all calls to CONSTANTP within the implementation need to be 
    
+  examined to see whether an environment argument must be passed.  This
    
+  also requires that something other than EVAL (like FUNCALL of ENCLOSE)
    
+  be used to compute the value of something that is CONSTANTP.
    
+
    
+Cost to Users:
    
+
    
+  Many applications that now use CONSTANTP assume that the value it returns
    
+  is not sensitive to the lexical environment in which the form appears.
    
+  (Since CONSTANTP has not previously been specified to accept an 
    
+  environment argument, it is hard to see how any other interpretation
    
+  could be made.)  Proposal SHADOWING-PERMITTED represents an incompatible 
    
+  change in this respect.  All calls to CONSTANTP within user programs 
    
+  would have to be examined to see whether an environment argument must 
    
+  be passed.  This also requires that something other than EVAL (like 
    
+  FUNCALL of ENCLOSE) be used to compute the value of something that is 
    
+  CONSTANTP.
    
+
    
+Cost of non-adoption:
    
+
    
+  The language specification is unnecessarily vague.
    
+
    
+Performance impact:
    
+
    
+  Probably none.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Seems to depend on who you talk to.
    
+
    
+  Most people seem to acknowledge that shadowing proclaimed specials and
    
+  defined constants with symbol-macros is abominable programming style.
    
+
    
+  Some people think disallowing shadowing complicates the language
    
+  unnecessarily by introducing yet another special case.
    
+
    
+  Some people think permitting shadowing complicates the language
    
+  unnecessarily by destroying the "globalness" of special proclamations 
    
+  and constant definitions.
    
+  
    
+
    
+Discussion:
    
+
    
+  This issue was discussed on the x3j13 mailing list in May/June 1990.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341.htm new file mode 100644 index 00000000..0d933985 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341_w.htm new file mode 100644 index 00000000..127d007a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss341_w.htm @@ -0,0 +1,119 @@ + + + +CLHS: Issue SYMBOL-PRINT-ESCAPE-BEHAVIOR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SYMBOL-PRINT-ESCAPE-BEHAVIOR Writeup

    + +
    Issue:        SYMBOL-PRINT-ESCAPE-BEHAVIOR
    
+Forum:        X3J13 Letter Ballot
    
+References:   *PRINT-ESCAPE* (X3J13/92-102, p22-4)
    
+	      Public review comment Moon-1
    
+	      Public review comment Loosemore-17
    
+	      Public review comment Pitman-9
    
+Category:     CLARIFICATION
    
+Edit history: 21-Jun-93, Version 1 by Steele (based on text by Loosemore)
    
+Status:		Proposal CLARIFY passed 10-1 on letter ballot 93-304.
    
+
    
+Problem Description:
    
+
    
+  The description of how symbols are printed when *PRINT-ESCAPE* is
    
+  true is too vague.  Three PR commentors remarked on this.
    
+
    
+Proposal (SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY):
    
+
    
+  Replace the text:
    
+
    
+    \term{Backslashes} and \term{vertical-bars} are included as required.  
    
+    The \term{current output base} at the time of printing might be relevant.
    
+    For example, if \thevalueof{*print-base*} were \f{16} 
    
+    when printing the symbol \f{face}, it would have to be printed as
    
+    \f{\\FACE} or \f{\\Face} or \f{|FACE|}, 
    
+    because the token \f{face} would be read as a hexadecimal
    
+    number (decimal value 64206) if \thevalueof{*read-base*} were \f{16}.
    
+
    
+  with:
    
+
    
+    When printing a \term{symbol}, the printer inserts enough 
    
+    \term{single escape} and/or \term{multiple escape}
    
+    characters (\term{backslashes} and/or \term{vertical-bars}) so that if
    
+    \funref{read} were called with the same \varref{*readtable*} and
    
+    with \varref{*read-base*} bound to the \term{current output base}, it
    
+    would return the same \term{symbol} (if it is not 
    
+    \term{apparently uninterned}) or an \term{uninterned} \term{symbol}
    
+    with the same \term{print name} (otherwise).
    
+
    
+    For example, if \thevalueof{*print-base*} were \f{16} 
    
+    when printing the symbol \f{face}, it would have to be printed as
    
+    \f{\\FACE} or \f{\\Face} or \f{|FACE|}, 
    
+    because the token \f{face} would be read as a hexadecimal
    
+    number (decimal value 64206) if \thevalueof{*read-base*} were \f{16}.
    
+
    
+    See \varref{*print-readably*} for additional restrictions concerning
    
+    characters with  nonstandard \term{syntax types} in the 
    
+    \term{current readtable}.
    
+  
    
+Test Case:
    
+
    
+  Not provided.
    
+
    
+Rationale:
    
+
    
+  Explain more fully what is meant by "as required".
    
+
    
+Current Practice:
    
+
    
+  Not provided.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably relatively small.
    
+
    
+Cost to Users:
    
+
    
+  None.  This change doesn't affect anything already guaranteed to the user.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Vagueness in the language specification.
    
+
    
+Benefits:
    
+
    
+  Better program portability.
    
+
    
+Editorial Impact:
    
+
    
+  Small.  A small, localized edit.
    
+
    
+Aesthetics:
    
+
    
+  Mostly neutral.
    
+
    
+Discussion:
    
+  
    
+  This addresses comments Moon #1, Loosemore #17, and Pitman #9.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342.htm new file mode 100644 index 00000000..3c266fed --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342.htm @@ -0,0 +1,41 @@ + + + +CLHS: Issue SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342_w.htm new file mode 100644 index 00000000..2b2658ab --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss342_w.htm @@ -0,0 +1,631 @@ + + + +CLHS: Issue SYNTACTIC-ENVIRONMENT-ACCESS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue SYNTACTIC-ENVIRONMENT-ACCESS Writeup

    + +
    Forum:          Compiler
    
+Issue:          SYNTACTIC-ENVIRONMENT-ACCESS
    
+References:     CLtL Chapter 8: Macros,
    
+                CLtL Chapter 9: Declarations,
    
+                Issue COMPILE-FILE-ENVIRONMENT,
    
+                Issue DEFINING-MACROS-NON-TOP-LEVEL,
    
+                Issue DESTRUCTURING-BIND,
    
+                Issue EVAL-WHEN-NON-TOP-LEVEL,
    
+                Issue GET-SETF-METHOD-ENVIRONMENT,
    
+                Issue FUNCTION-NAME,
    
+                Issue FUNCTION-TYPE,
    
+                Issue MACRO-ENVIRONMENT-EXTENT,
    
+                Issue MACRO-FUNCTION-ENVIRONMENT,
    
+                Issue PROCLAIM-LEXICAL,
    
+		Issue PACKAGE-CLUTTER
    
+Category:       ADDITION
    
+Edit history:   Version 1, 2-Oct-88, Eric Benson
    
+                Version 2, 17-Feb-89, Kim A. Barrett
    
+                Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
    
+                Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
    
+                Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
    
+                Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
    
+                Version 7,  7-Apr-89, Moon & Barrett (more revisions)
    
+                Version 8,  9-Jun-89, Kim A. Barrett (add DEFDECLARE)
    
+                Version 9, 13-Jun-89, Moon (small corrections)
    
+		Version 10, 22-Jun-89, Loosemore (more clarifications,
    
+			primarily relating to DEFDECLARE)
    
+		Version 11, 04-Jul-89, Loosemore (amendments from June mtg)
    
+
    
+Status:         Proposal SMALL passed June 89
    
+
    
+
    
+Problem description:
    
+
    
+ When macro forms are expanded, the expansion function is called with two
    
+ arguments: the form to be expanded, and the environment in which the form was
    
+ found.  The environment argument is of limited utility.  The only use
    
+ sanctioned currently is as an argument to MACROEXPAND or MACROEXPAND-1 or
    
+ passed directly as an argument to another macro expansion function.  Recently
    
+ passed cleanup issues allow it as an argument to MACRO-FUNCTION and to
    
+ GET-SETF-METHOD.
    
+
    
+ It is very difficult to write a code walker that can correctly handle local
    
+ macro and function definitions, due to insufficient access to the information
    
+ contained in environments and the inability to augment environments with local
    
+ definitions.
    
+
    
+
    
+Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
    
+
    
+ The following functions provide information about syntactic environment
    
+ objects.  In all of these functions the argument named ENV is an environment
    
+ of the sort received by the &ENVIRONMENT argument to a macro or as the
    
+ environment argument for EVALHOOK.  (It is not required that implementations
    
+ provide a distinguished representation for such objects.)  Optional "env"
    
+ arguments default to NIL, which represents the local null lexical environment
    
+ (containing only global definitions and proclamations that are present in the
    
+ runtime environment).  All of these functions should signal an error of type
    
+ TYPE-ERROR if the value of an environment argument is not a syntactic
    
+ environment.
    
+
    
+ The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
    
+ DECLARATION-INFORMATION retrieve information about declarations that are in
    
+ effect in the environment.  Since implementations are permitted to ignore
    
+ declarations (except for SPECIAL declarations and OPTIMIZE SAFETY
    
+ declarations if they ever compile unsafe code), these accessors are required
    
+ only to return information about declarations that were explicitly added to
    
+ the environment using AUGMENT-ENVIRONMENT.  They might also return
    
+ information about declarations recognized and added to the environment by the
    
+ interpreter or the compiler, but that is optional at the discretion of the
    
+ implementer.  Implementations are also permitted to canonicalize
    
+ declarations, so the information returned by the accessors might not be
    
+ identical to the information that was passed to AUGMENT-ENVIRONMENT.
    
+
    
+ VARIABLE-INFORMATION variable &optional env            [Function]
    
+
    
+  This function returns information about the interpretation of the symbol
    
+  VARIABLE when it appears as a variable within the lexical environment ENV.
    
+  The following three values are returned.
    
+
    
+  The first value indicates the type of definition or binding which is apparent
    
+  in ENV:
    
+
    
+    NIL            There is no apparent definition or binding for variable.
    
+
    
+    :SPECIAL       VARIABLE refers to a special variable, either declared 
    
+                   or proclaimed. 
    
+
    
+    :LEXICAL       VARIABLE refers to a lexical variable.
    
+
    
+    :SYMBOL-MACRO  VARIABLE refers to a SYMBOL-MACROLET binding.
    
+
    
+    :CONSTANT      VARIABLE refers to a named constant, defined by
    
+                   DEFCONSTANT, or VARIABLE is a keyword symbol.
    
+
    
+ [Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result will also
    
+  refer to variables proclaimed lexical.]
    
+
    
+  The second value indicates whether there is a local binding of the name.  If
    
+  the name is locally bound, the second value is true.  Otherwise, NIL is
    
+  returned.
    
+
    
+  The third value is an a-list containing information about declarations
    
+  that apply to the apparent binding of the variable.  The keys in the a-list
    
+  are symbols which name declaration-specifiers, and the format of the
    
+  corresponding value in the CDR of each pair depends on the particular 
    
+  declaration name involved.  The standard declaration names
    
+  that might appear as keys in this a-list are:
    
+
    
+    DYNAMIC-EXTENT a non-NIL value indicates that the variable has been
    
+                declared DYNAMIC-EXTENT. If the value is NIL, the pair
    
+                might be omitted.
    
+
    
+    IGNORE      a non-NIL value indicates that the variable has been declared
    
+                IGNORE. If the value is NIL, the pair might be omitted.
    
+
    
+    TYPE        a type specifier associated with the variable by a TYPE
    
+                declaration or an abbreviated declaration such as (FIXNUM VAR).
    
+                If no explicit association exists, either by PROCLAIM or
    
+                DECLARE, then the type specifier is T.  It is permissible for
    
+                implementations to use a type specifier that is equivalent
    
+                to or a supertype of the one appearing in the original
    
+                declaration.  If the value is T, the pair might be
    
+                omitted.
    
+
    
+  If an implementation supports additional declaration-specifiers that
    
+  apply to variable bindings, those declaration names might also
    
+  appear in the a-list.  However, the corresponding key must not
    
+  be a symbol that is external in any package defined in the standard
    
+  or that is otherwise accessible in the USER package.
    
+
    
+  The a-list might contain multiple entries for a given key.
    
+  The consequences of destructively modifying the list
    
+  structure of this a-list or its elements (except for values that 
    
+  appear in the a-list as a result of DEFINE-DECLARATION) are undefined.
    
+
    
+  Programmers are reminded that the global binding might differ from the
    
+  local one, and can be retrieved by calling VARIABLE-INFORMATION
    
+  again with a null lexical environment.
    
+
    
+
    
+ FUNCTION-INFORMATION function &optional env            [Function]
    
+
    
+  This function returns information about the interpretation of the function
    
+  name FUNCTION when it appears in a functional position within lexical 
    
+  environment ENV.  The following three values are returned.
    
+
    
+  The first value indicates the type of definition or binding of the function
    
+  name which is apparent in ENV:
    
+
    
+    NIL            There is no apparent definition for FUNCTION.
    
+
    
+    :FUNCTION      FUNCTION refers to a function.
    
+
    
+    :MACRO         FUNCTION refers to a macro.
    
+
    
+    :SPECIAL-FORM  FUNCTION refers to a special form.
    
+
    
+  Some function names can refer to both a global macro and a global special
    
+  form.  In such a case, the macro takes precedence, and :MACRO is returned as
    
+  the first value.
    
+
    
+  The second value specifies whether the definition is local or global.  If
    
+  local, the second value is true, and it is false when the definition is
    
+  global.
    
+
    
+  The third value is an a-list containing information about declarations
    
+  that apply to the apparent binding of the function.  The keys in the a-list
    
+  are symbols which name declaration-specifiers, and the format of the
    
+  corresponding values in the CDR of each pair depends on the particular 
    
+  declaration name involved.  The standard declaration names
    
+  that might appear as keys in this a-list are:
    
+
    
+    INLINE      one of the symbols INLINE, NOTINLINE, or NIL to indicate
    
+                whether the function name has been declared INLINE, has been
    
+                declared NOTINLINE, or neither.  If the value is NIL, the
    
+                pair might be omitted.
    
+
    
+    FTYPE       the type specifier associated with the function name in the
    
+                environment, or the symbol FUNCTION if there is no functional
    
+                type declaration or proclamation associated with the function
    
+                name.  This value might not include all the apparent FTYPE
    
+                declarations for the function name.  It is permissible for
    
+                implementations to use a type specifier that is equivalent
    
+                to or a supertype of the one that appeared in the original
    
+                declaration.  If the value is FUNCTION, the pair might be
    
+                omitted. 
    
+
    
+    DYNAMIC-EXTENT  a non-NIL value indicates that the function has been
    
+                declared DYNAMIC-EXTENT.  If the value is NIL, thie pair
    
+                might be omitted.
    
+
    
+  If an implementation supports additional declaration-specifiers that
    
+  apply to function bindings, those declaration names might also
    
+  appear in the a-list.  However, the corresponding key must not be
    
+  a symbol that is external in any package defined in the standard or
    
+  that is otherwise accessible in the USER package.
    
+
    
+  The a-list might contain multiple entries for a given key.
    
+  In this case the value associated with the first entry has
    
+  precedence.  The consequences of destructively modifying the list
    
+  structure of this a-list or its elements (except for values
    
+  that appear in the a-list as a result of DEFINE-DECLARATION) are 
    
+  undefined.
    
+
    
+  Programmers are reminded that the global binding might differ from the local
    
+  one, and can be retrieved by calling FUNCTION-INFORMATION again with a null
    
+  lexical environment.
    
+
    
+
    
+ DECLARATION-INFORMATION decl-name &optional env        [Function]
    
+
    
+  This function returns information about declarations named by the
    
+  symbol DECL-NAME that are in force in the environment ENV.
    
+  Only declarations that do not apply to function or variable bindings
    
+  can be accessed with this function.  The format of the information
    
+  that is returned depends on the DECL-NAME involved.
    
+
    
+  It is required that this function recognize OPTIMIZE and DECLARATION as
    
+  DECL-NAMEs.  The values returned for these two cases are as follows:
    
+
    
+    OPTIMIZE    a list whose entries are of the form (quality value), where
    
+                "quality" is one of the optimization qualities defined by the
    
+                standard (SPEED, SAFETY, COMPILATION-SPEED, SPACE, and DEBUG)
    
+                or some implementation-specific optimization quality, and
    
+                "value" is an integer in the range 0 to 3.  The returned list
    
+                always contains an entry for each of the standard qualities and
    
+                for each of the implementation-specific qualities.  In the
    
+                absence of any previous declarations, the associated values are
    
+                implementation-dependent.  The list might contain multiple
    
+                entries for a quality, in which case the first such entry
    
+                specifies the current value.
    
+                The consequences of destructively modifying this list or
    
+		its elements are undefined.
    
+                
    
+
    
+    DECLARATION a list of the declaration names which have been proclaimed as
    
+                valid through the use of the DECLARATION proclamation.
    
+                The consequences of destructively modifying this list or
    
+		its elements are undefined.
    
+
    
+  If an implementation has been extended to recognize additional
    
+  declaration specifiers in DECLARE or PROCLAIM, it is required that
    
+  either the DECLARATION-INFORMATION function should also recognize those
    
+  declarations, or that the implementation provide an accessor that is
    
+  specialized for that declaration specifier.  If DECLARATION-INFORMATION
    
+  is used to return the information, the corresponding DECL-NAME must not
    
+  be a symbol that is external in any package defined in the standard or
    
+  that is otherwise accessible in the USER package.
    
+
    
+
    
+ AUGMENT-ENVIRONMENT env &KEY variable
    
+                              symbol-macro
    
+                              function
    
+                              macro
    
+                              declare                           [Function]
    
+
    
+  This function returns a new environment containing the information present in
    
+  ENV, augmented with the information provided by the keyword arguments.  It is
    
+  intended to be used by program analyzers that perform a code walk.
    
+
    
+  The arguments are supplied as follows:
    
+
    
+  :VARIABLE     A list of symbols which shall be visible as bound variables in
    
+                the new environment.  Whether each binding is to be interpreted
    
+                as special or lexical depends on SPECIAL declarations recorded
    
+                in the environment or provided in the :DECLARE argument list.
    
+
    
+  :SYMBOL-MACRO A list of symbol macro definitions, specified as a list of
    
+                (name definition) lists (that is, in the same format as the
    
+                CADR of a SYMBOL-MACROLET special form).  The new environment
    
+                will have local symbol-macro bindings of each symbol to the
    
+                corresponding expansion, so that MACROEXPAND will be able to
    
+                expand them properly.  A type declaration in the :DECLARE
    
+                argument which refers to a name in this list implicitly
    
+                modifies the definition associated with the name.  The effect
    
+                is to wrap a THE form mentioning the type around the
    
+                definition.
    
+
    
+  :FUNCTION     A list of function names which shall be visible as local
    
+                function bindings in the new environment.
    
+
    
+  :MACRO        A list of local macro definitions, specified as a list of (name
    
+                definition) lists.  Each definition must be a function of two
    
+                arguments (a form and an environment).  The new environment
    
+                will have local macro bindings of each name to the
    
+                corresponding expander function, which will be returned by
    
+                MACRO-FUNCTION and used by MACROEXPAND.
    
+
    
+  :DECLARE      A list of decl-specs.  Information about these declarations can
    
+                be retrieved from the resulting environment using the
    
+                VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
    
+                DECLARATION-INFORMATION accessors.
    
+
    
+  An error is signalled if any of the symbols naming macros in the
    
+  :SYMBOL-MACRO alist are also included in the :VARIABLE list.  An error is
    
+  signaled if any of the symbols naming macros in the :SYMBOL-MACRO alist are
    
+  also included in a SPECIAL decl-spec in the :DECLARE argument.  An error is
    
+  signalled if any of the names of macros in the :MACRO alist are also included
    
+  in the :FUNCTION list.  The consequences of destructively modifying the list
    
+  structure of any of the arguments to this function are undefined.
    
+
    
+  The condition type of each of these errors is PROGRAM-ERROR.
    
+
    
+  The extent of the returned environment is the same as the extent of the
    
+  argument environment.  The result might share structure with the argument
    
+  environment, but the argument environment is not modified.
    
+
    
+  While an environment argument from EVALHOOK is permitted to be used as the
    
+  environment argument for this function, the reverse is not true.  If an
    
+  attempt is made to use the result of AUGMENT-ENVIRONMENT as the environment
    
+  argument for EVALHOOK, the consequences are undefined.  The environment
    
+  returned by AUGMENT-ENVIRONMENT can only be used for syntactic analysis, ie.
    
+  the functions specified by this proposal and functions such as MACROEXPAND.
    
+
    
+
    
+ DEFINE-DECLARATION decl-name lambda-list &body body               [Macro]
    
+
    
+  Define a handler for the named declaration.  This is the mechanism by which
    
+  AUGMENT-ENVIRONMENT is extended to support additional declaration
    
+  specifiers.  The function defined by this macro will be called with two
    
+  arguments, a decl-spec whose CAR is decl-name, and the ENV argument to
    
+  AUGMENT-ENVIRONMENT.  Two values must be returned by the function.  The
    
+  first value must be one of the following keywords:
    
+
    
+  :VARIABLE     the declaration applies to variable bindings.
    
+  :FUNCTION     the declaration applies to function bindings.
    
+  :DECLARE      the declaration does not apply to bindings.
    
+
    
+  For the case where the first value indicates the declaration applies to
    
+  bindings, the second value is a list, the elements of which are lists of the
    
+  form (binding-name key value).  If the corresponding information
    
+  function (either VARIABLE-INFORMATION or FUNCTION-INFORMATION) is applied to
    
+  the binding name and the augmented environment, the a-list which is
    
+  the third value returned by the information function will contain the value
    
+  under the specified key.
    
+
    
+  When the first value is :DECLARE, the second value is a cons whose CAR is a
    
+  key and whose CDR is the associated value.  The function
    
+  DECLARATION-INFORMATION, when applied to the key and the augmented
    
+  environment, will return the associated value.
    
+
    
+  DEFINE-DECLARATION causes DECL-NAME to be proclaimed to be a
    
+  declaration (it is as if its expansion included a call (PROCLAIM
    
+  '(DECLARATION decl-name))).  As is the case with standard
    
+  declaration specifiers, the evaluator and compiler are permitted,
    
+  but not required, to add information about declaration specifiers
    
+  defined with DEFINE-DECLARATION to the macroexpansion and evalhook
    
+  environments.
    
+
    
+  The consequences are undefined if DECL-NAME is a symbol which can
    
+  appear as the CAR of any declaration specifier defined in the standard.
    
+
    
+  The consequences are also undefined if the return value from a 
    
+  declaration handler defined with DEFINE-DECLARATION includes a key name
    
+  that is used by the corresponding accessor to return information about
    
+  any declaration specifier defined in the standard.  (For example, if
    
+  the first return value from the handler is :VARIABLE, the second return
    
+  value may not use the symbols DYNAMIC-EXTENT, IGNORE, or TYPE as key
    
+  names.)
    
+
    
+  The DEFINE-DECLARATION macro does not have any special compile-time
    
+  side-effects.
    
+
    
+
    
+ PARSE-MACRO name lambda-list body &optional env        [Function]
    
+
    
+  This function is used to process a macro definition in the same way
    
+  as DEFMACRO and MACROLET.  It returns a lambda-expression that accepts
    
+  two arguments (a form and an environment).  The "name", "lambda-list",
    
+  and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
    
+  definition.
    
+
    
+  The "lambda-list" argument can include &ENVIRONMENT and &WHOLE.  The "name"
    
+  argument is used to enclose the "body" in an implicit BLOCK, and might also
    
+  be used for implementation-dependent purposes (such as including the name of
    
+  the macro in error messages if the form does not match the lambda-list).
    
+
    
+
    
+ ENCLOSE lambda-expression &optional env                [Function]
    
+
    
+  This function returns an object of type FUNCTION that is equivalent to what
    
+  would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION) in syntactic
    
+  environment ENV.  The LAMBDA-EXPRESSION is permitted to reference only the
    
+  parts of the environment argument ENV that are relevant only to syntactic
    
+  processing, specifically declarations and the definitions of macros and
    
+  symbol-macros.  The consequences are undefined if the LAMBDA-EXPRESSION
    
+  contains any references to variable or function bindings that are 
    
+  lexically visible in ENV; any GO to a tag that is lexicaly visible in 
    
+  the environment ENV; or any RETURN-FROM a block name that is lexically 
    
+  visible in the environment ENV.
    
+
    
+
    
+Rationale:
    
+
    
+  This proposal defines a minimal set of accessors (VARIABLE-INFORMATION,
    
+  FUNCTION-INFORMATION, and DECLARATION-INFORMATION) and a constructor
    
+  (AUGMENT-ENVIRONMENT) for environments.
    
+
    
+  All of the standard declaration specifiers, with the exception of SPECIAL,
    
+  can be defined fairly easily using DEFINE-DECLARATION.  It also
    
+  seems to be able to handle most extended declarations.
    
+
    
+  The PARSE-MACRO function is provided so that users don't have to write their
    
+  own code to destructure macro arguments.  With the addition of
    
+  DESTRUCTURING-BIND to the language, this function is not entirely necessary.
    
+  However, it is probably worth including anyway, since any program-analyzing
    
+  program is going to need to define it, and the definition isn't completely
    
+  trivial.
    
+
    
+  ENCLOSE is needed to allow expander functions to be defined in a non-NULL
    
+  lexical environment, as required by DEFINING-MACROS-NON-TOP-LEVEL:ALLOW.  It
    
+  also provides a mechanism by which the forms in an (EVAL-WHEN (COMPILE) ...)
    
+  can be executed in the enclosing environment (see Issue
    
+  EVAL-WHEN-NON-TOP-LEVEL).
    
+
    
+  Making declarations from an &ENVIRONMENT or EVALHOOK environment optional
    
+  continues to allow implementations the freedom simply to ignore all such
    
+  declarations in the compiler or interpreter.
    
+
    
+
    
+Examples:
    
+
    
+#1:  This example illustrates the first two values returned by the function
    
+     VARIABLE-INFORMATION.
    
+
    
+  (DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
    
+    (MULTIPLE-VALUE-BIND (KIND BINDINGP)
    
+                         (VARIABLE-INFORMATION VAR ENV)
    
+      `(LIST ',VAR ',KIND ',BINDINGP)))
    
+
    
+  (DEFVAR A)
    
+
    
+  (DEFCONSTANT B 43)
    
+
    
+  (DEFUN TEST ()
    
+    (LET (C)
    
+      (LET (D)
    
+        (DECLARE (SPECIAL D))
    
+        (SYMBOL-MACROLET ((E ANYTHING))
    
+          (LIST (KIND-OF-VARIABLE A)
    
+                (KIND-OF-VARIABLE B)
    
+                (KIND-OF-VARIABLE C)
    
+                (KIND-OF-VARIABLE D)
    
+                (KIND-OF-VARIABLE E)
    
+                (KIND-OF-VARIABLE F))))))
    
+
    
+  (TEST) -> ((A :SPECIAL NIL)
    
+             (B :CONSTANT NIL)
    
+             (C :LEXICAL T)
    
+             (D :SPECIAL T)
    
+             (E :SYMBOL-MACRO T)
    
+             (F NIL NIL))
    
+
    
+      
    
+#2:  This example illustrates the first two values returned by the function
    
+     FUNCTION-INFORMATION.
    
+
    
+  (DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
    
+    (MULTIPLE-VALUE-BIND (KIND BINDINGP)
    
+                         (FUNCTION-INFORMATION FUNCTION-NAME ENV)
    
+      `(LIST ',FUNCTION-NAME ',KIND ',BINDING)))
    
+
    
+  (DEFUN A ())
    
+
    
+  (DEFUN (SETF A) (V))
    
+
    
+  (DEFMACRO B ())
    
+
    
+  (DEFUN TEST ()
    
+    (FLET ((C ()))
    
+      (MACROLET ((D ()))
    
+        (LIST (KIND-OF-FUNCTION A)
    
+              (KIND-OF-FUNCTION B)
    
+              (KIND-OF-FUNCTION QUOTE)
    
+              (KIND-OF-FUNCTION (SETF A))
    
+              (KIND-OF-FUNCTION C)
    
+              (KIND-OF-FUNCTION D)
    
+              (KIND-OF-FUNCTION E)))))
    
+
    
+  (TEST) -> ((A :FUNCTION NIL)
    
+             (B :MACRO NIL)
    
+             (QUOTE :SPECIAL-FORM NIL)
    
+             ((SETF A) :FUNCTION NIL)
    
+             (C :FUNCTION T)
    
+             (D :MACRO T)
    
+             (E NIL NIL))
    
+
    
+
    
+#3: This example shows how a code-walker might walk a MACROLET special form.
    
+    It assumes that the revised MACROLET semantics described in proposal
    
+    DEFINING-MACROS-NON-TOP-LEVEL:ALLOW are in effect. 
    
+
    
+  (DEFUN WALK-MACROLET (FORM ENV)
    
+    (LET ((MACROS  (MAKE-MACRO-DEFINITIONS (CADR FORM) ENV)))
    
+      (MULTIPLE-VALUE-BIND (BODY DECLS) (PARSE-BODY (CDDR FORM))
    
+        (WALK-IMPLICIT-PROGN
    
+          BODY
    
+          (AUGMENT-ENVIRONMENT ENV :MACRO MACROS :DECLARE DECLS)))))
    
+
    
+  (DEFUN MAKE-MACRO-DEFINITIONS (DEFS ENV)
    
+    (MAPCAR #'(LAMBDA (DEF)
    
+                (LET ((NAME (CAR DEF)))
    
+                  (LIST NAME
    
+                        (ENCLOSE (PARSE-MACRO NAME (CADR DEF) (CDDR DEF) ENV)
    
+                                 ENV))))
    
+            DEFS))
    
+
    
+
    
+Cost to Implementors:
    
+
    
+ Most implementations already record some of this information in some form.
    
+ Providing these functions should not be too difficult, but it is a more than
    
+ trivial amount of work.
    
+
    
+Cost to Users:
    
+
    
+ This change is upward compatible with user code.
    
+
    
+Current practice:
    
+
    
+ No implementation provides all of this interface currently.  Portable Common
    
+ Loops defines a subset of this functionality for its code walker and
    
+ implements it on a number of diffent versions of Common Lisp.
    
+
    
+Discussion:
    
+
    
+ The first version of this proposal expressly did not deal with the objects
    
+ which are used as environments by EVALHOOK.  This version is extended to
    
+ support them in the belief that such environments share a lot of functionality
    
+ with the syntactic environments needed by a compiler.  While the two types of
    
+ environments might have very different implementations, there are many
    
+ operations which are reasonable to perform on either type, including all of
    
+ the accessor functions described by this proposal.
    
+
    
+ There has been discussion about a macro called WITH-AUGMENTED-ENVIRONMENT,
    
+ either in addition to or instead of AUGMENT-ENVIRONMENT.  The point of this
    
+ would be to say that the extent of the augmented environment is the dynamic
    
+ extent of the WITH-AUGMENTED-ENVIRONMENT form.  There was some concern that
    
+ there might be cases where the macro was awkward to use.  Such a macro is not
    
+ included in this proposal.  If AUGMENT-ENVIRONMENT is provided, then such a
    
+ macro is trivially written in terms of the function.  There are places in the
    
+ processing of sequential binding forms where using such a macro might be more
    
+ difficult than using the specified function.
    
+
    
+ Some people have indicated they think that the :MACRO argument (and the
    
+ :SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an a-list of the
    
+ form ((name . definition)...) rather than the form ((name definition)...).
    
+
    
+ Some people have indicated they think that implementations must never discard
    
+ any declarations, even if they are not otherwise used by the interpreter or
    
+ compiler.  Proposal SMALL is consistent with what CLtL says (implementations
    
+ are free to ignore all declarations except SPECIAL declarations), but the
    
+ DECLARATION-INFORMATION function might not be particularly useful unless it is
    
+ guaranteed to do something.  Requiring implementations to keep track of
    
+ declarations they'd otherwise ignore would involve some implementation cost
    
+ and also might incur a performance penalty.
    
+
    
+ ENCLOSE happens to subsume the extension to COERCE for converting a lambda
    
+ expression into a function (see Issue FUNCTION-TYPE, passed in June 1988).
    
+ Perhaps the extension to COERCE should be backed out?
    
+
    
+There have been some suggestions for related functionality that have not
    
+been included in this proposal because we haven't had the time to give
    
+them adequate consideration, and some of them might be controversial.
    
+These suggestions include:
    
+
    
+- Adding a function to canonicalize type specifiers.
    
+
    
+- Extending VARIABLE-INFORMATION to return a value indicating whether there
    
+  is a special binding of the variable in the environment, regardless of
    
+  whether or not it has been shadowed by a lexical or symbol-macro binding
    
+  of the same name.
    
+
    
+- A function to map over all names that are defined in the lexical 
    
+  environment:
    
+
    
+    MAP-ENVIRONMENT fn key &optional env
    
+ 
    
+    KEY must be one of the symbols :FUNCTION, :VARIABLE, or :DECLARATION.
    
+
    
+    when key is :FUNCTION,
    
+      for every symbol S for which (FUNCTION-INFORMATION s ENV)
    
+      would return the values X, true, Y, for any X and Y,
    
+      FN is applied to the arguments S, X, and Y.
    
+
    
+    when key is :VARIABLE,
    
+      for every symbol S for which (VARIABLE-INFORMATION s ENV)
    
+      would return the values X, true, Y, for any X and Y,
    
+      FN is applied to the arguments S, X, and Y.
    
+
    
+    when key is :DECLARATION,
    
+      for every symbol S for which (VARIABLE-INFORMATION s ENV)
    
+      would return a non-nil value L
    
+      FN is applied to the arguments S and L. 
    
+
    
+- Adding additional accessors and keyword arguments to AUGMENT-ENVIRONMENT
    
+  for BLOCK and TAGBODY labels.
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343.htm new file mode 100644 index 00000000..d437603e --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue TAGBODY-TAG-EXPANSION:NO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TAGBODY-TAG-EXPANSION:NO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue TAGBODY-TAG-EXPANSION:NO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343_w.htm new file mode 100644 index 00000000..8257e878 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss343_w.htm @@ -0,0 +1,139 @@ + + + +CLHS: Issue TAGBODY-TAG-EXPANSION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TAGBODY-TAG-EXPANSION Writeup

    + +
    Issue:             TAGBODY-TAG-EXPANSION
    
+References:        TAGBODY (CLtL-II p 173-175)
    
+Related issues:
    
+Category:          CLARIFICATION
    
+Edit history:      v1, 27 Feb 91, Sandra Loosemore
    
+                   v2, 11 Mar 91, Sandra Loosemore (update discussion)
    
+                   v3, 14 Mar 91, Sandra Loosemore (fix bug in example)
    
+Status:            v3 (proposal NO) accepted by X3J13, Mar 1991
    
+
    
+Problem description:
    
+
    
+  It's not clear whether items in the body of a TAGBODY are 
    
+  macroexpanded before determining whether they are "tags" or
    
+  "statements".  The (original) text on p. 173 of CLtL-II seems to 
    
+  imply that they are not, but the (new) commentary on p. 175 
    
+  hints that some implementations might expand macros.  This ambiguity
    
+  can lead to different behavior in different implementations.
    
+
    
+Proposal (TAGBODY-TAG-EXPANSION:NO):
    
+
    
+  Clarify items in the body of a TAGBODY are not macroexpanded in 
    
+  determining whether they are "tags" or "statements".  
    
+
    
+Examples:
    
+
    
+  #1: (macrolet ((foo-macro () 'foo))
    
+        (let ((count 0) (foo nil))
    
+          (tagbody
    
+            (foo-macro)
    
+            (when (< count 5) (incf count) (go foo)))))
    
+
    
+      This example is in error because (FOO-MACRO) is treated as a "statement" 
    
+      rather than as a "tag".  Therefore there is no tag FOO as a target
    
+      of the GO.
    
+
    
+  #2: (symbol-macrolet ((foo  (print 'loses)))
    
+        (let ((count 0))
    
+          (tagbody
    
+            foo
    
+            (when (< count 5) (incf count) (go foo)))))
    
+
    
+      This example returns NIL without printing anything, because FOO is
    
+      treated as a "tag" rather than as a "statement".
    
+
    
+Rationale:
    
+
    
+  This seems to be consistent with current practice.
    
+
    
+Current Practice:
    
+
    
+  Lucid CL version 4.0, Allegro CL version 3.1, Chestnut's Lisp-to-C
    
+  translator, and Symbolics Genera all signal an error for test case #1.
    
+
    
+Cost to Implementors:
    
+
    
+  Small.
    
+
    
+Cost to Users:
    
+
    
+  Probably the only class of programs that would be affected are 
    
+  codewalkers.  Codewalkers that produce code in which macro calls are 
    
+  replaced with macro expansions need to be careful that things that
    
+  are initially parsed as tagbody "statements" still appear to be 
    
+  "statements" in the output of the codewalker.
    
+
    
+Cost of non-adoption:
    
+
    
+  Unnecessary confusion in the language standard.  Implementations might
    
+  differ for no good reason.  Without an explicit clarification, people
    
+  writing codewalkers might not realize that this is something they need
    
+  to watch out for.
    
+
    
+Performance impact:
    
+
    
+  Probably none.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  I think the alternatives are worse.
    
+  
    
+Discussion:
    
+
    
+  This issue doesn't address the questions of whether duplicate tags are
    
+  permitted or whether items that are not symbols, integers, or lists are
    
+  permitted.  It is probably acceptable to leave these unspecified in
    
+  the standard on the assumption that syntax that isn't explicitly 
    
+  documented as being meaningful, isn't.  
    
+
    
+  Kent Pitman says:
    
+
    
+    Ugh.  Yes, please count me as a supporter of TAGBODY-TAG-EXPANSION:NO.
    
+
    
+  Barry Margolin says:
    
+
    
+    I've always been satisfied to treat this as implicitly vague, and I
    
+    tell people to make sure their macros expand into a PROGN form if they
    
+    want to be able to expand into an atom (e.g. expand into (PROGN)
    
+    rather than NIL to do nothing).
    
+
    
+  Loosemore notes:
    
+
    
+    I think the idea of forcing *every* user-defined macro to deal with 
    
+    this lossage is pretty disgusting.  The "right" place to deal with
    
+    this is in the code-walkers that do the parsing of TAGBODY forms.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344.htm new file mode 100644 index 00000000..0738e056 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue TAILP-NIL:T Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TAILP-NIL:T Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue TAILP-NIL:T:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344_w.htm new file mode 100644 index 00000000..23d1eee1 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss344_w.htm @@ -0,0 +1,193 @@ + + + +CLHS: Issue TAILP-NIL Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TAILP-NIL Writeup

    + +
    Issue:        TAILP-NIL
    
+References:   TAILP (p275)
    
+Category:     CLARIFICATION/CHANGE
    
+Edit History: 13-Sep-88, version 1 by Walter van Roggen,
    
+              13-Sep-88, version 2 by Pitman
    
+              18-Oct-88, version 3 by van Roggen (just one proposal)
    
+              01-Dec-88, version 4 by Pitman (minor edits per discussion)
    
+               9-Dec-88, Version 5 by Masinter (clarify EQL)
    
+
    
+Problem Description:
    
+ 
    
+  CLtL (p275) specifies TAILP as:
    
+ 
    
+    TAILP sublist list				[Function]
    
+ 
    
+    This predicate is true if SUBLIST is a sublist of LIST (i.e.,
    
+    one of the conses that makes up LIST); otherwise, it is false.
    
+    Another way to look at this is that TAILP is true if
    
+    (NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
    
+ 
    
+  Two implementations of this definition might be:
    
+ 
    
+   (defun tailp (sublist list)			;Definition "A"
    
+     (do ((list list (cdr list)))
    
+	 ((endp list) nil)
    
+       (if (eql sublist list)
    
+	   (return t))))
    
+ 
    
+   (defun tailp (sublist list)			;Definition "B"
    
+     (do ((list list (cdr list)))
    
+	 ((atom list) (eql list sublist))
    
+       (if (eql sublist list)
    
+	   (return t))))
    
+ 
    
+  They differ only in their treatment of the atomic case.
    
+ 
    
+  At issue is the fact that () is a list, and hence some would
    
+  argue that it is a sublist of all other lists. On the other hand,
    
+  the definition of TAILP seems to imply that being a cons is a
    
+  necessary precondition of being a "sublist".
    
+
    
+  Also at issue is the question of whether dotted lists are permissible
    
+  second arguments.
    
+
    
+Proposal (TAILP-NIL:T):
    
+ 
    
+  Strike any text in the definition of TAILP which suggests that a
    
+  sublist must be a cons.
    
+ 
    
+  Clarify that (TAILP sublist list) returns true iff (NTHCDR n list) is
    
+  sublist for some value of n, and false otherwise.
    
+
    
+  Note, however, that since the list may be dotted, so the end test
    
+  used by TAILP must be ATOM, not ENDP. That is, if (TAILP x l)
    
+  returns true, it means there was n such that (NTHCDR n list) would
    
+  return x; however, it doesn't follow that if TAILP returns false,
    
+  it is safe to go blithely NTHCDR's into the list looking for it, 
    
+  since the list might be dotted and NTHCDR might hit bad data.
    
+
    
+  Note that TAILP uses EQL or  equivalent to compare
    
+  sublist to list in the case where sublist is a number, etc.
    
+
    
+Rationale:
    
+ 
    
+  This is more consistent with the definition of LDIFF, which
    
+  gives a useful meaning to arbitrary atomic SUBLIST arguments.
    
+ 
    
+  This gives a more elegant definition of SUBLIST, allowing it to
    
+  refer to any list -- including the empty list -- which is a
    
+  part of another list.
    
+ 
    
+  Some reasons for preferring an ATOM check to ENDP include:
    
+   - The name TAILP suggests tails, not sublists. Some users might
    
+     expect this distinction to mean that data more general than
    
+     proper sublists.
    
+   - Making TAILP require lists limits its usefulness. If we did
    
+     not make this choice, some users would end up having to write
    
+     their own extended TAILP which we could just as well have
    
+     provided compatibly.
    
+   - TAILP is not considered to be used frequently enough in code
    
+     that the minor loss in speed to an ATOM check is worth the
    
+     lost functionality. Indeed, expanding the scope of its 
    
+     capabilities may lead to more uses for TAILP.
    
+   - Other operators (eg, APPEND) have recently been extended to
    
+     treat dotted lists in an interesting way because users have
    
+     expressed a desire for this. As such, this change is 
    
+     culturally consistent.
    
+   - Some implementations already support this feature, and the 
    
+     wording in CLtL is sufficiently ambiguous that some users
    
+     might think it appropriate to depend on the feature. In the
    
+     absence of compelling efficiency reasons to the contrary,
    
+     we should lean toward extending some implementations rather
    
+     than tightening others in our efforts to achieve cross-dialect
    
+     consistency.
    
+
    
+Examples:
    
+ 
    
+ #1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
    
+     should return T in all implementations.
    
+ 
    
+ #2: (TAILP '(X Y) '(A B C))
    
+     should return NIL in all implementations.
    
+ 
    
+ #3: (TAILP '() '(A B C))
    
+     returns T under this proposal.
    
+ 
    
+ #4: (TAILP 3 '(A B C))
    
+     returns NIL under this proposal.
    
+ 
    
+ #5: (TAILP 3 '(A B C . 3))
    
+     returns T under this proposal.
    
+ 
    
+ #6: (TAILP '(X Y) '(A B C . 3))
    
+     returns NIL under this proposal.
    
+ 
    
+Current Practice:
    
+ 
    
+  Symbolics Genera is consistent with TAILP-NIL:T.
    
+
    
+  Neither Lucid nor VAX LISP currently implements TAILP-NIL:T.
    
+
    
+  VAX LISP effectively implements definition "A" from the 
    
+  Problem Description above.
    
+
    
+Cost to Implementors:
    
+ 
    
+  An implementation of TAILP-NIL:T is given as Definition "B" in the
    
+  problem description.
    
+ 
    
+  Some implementations might have compiler optimizers for these definitions
    
+  as well, so a slight amount of additional effort might be required.
    
+ 
    
+Cost to Users:
    
+ 
    
+  Given that current practice varies widely on the disputed case,
    
+  this is unlikely to have a practical effect on existing portable code.
    
+ 
    
+Benefits:
    
+ 
    
+  Avoids unnecessary incompatibilities between implementations.
    
+ 
    
+Non-Benefits:
    
+
    
+  Slows down TAILP slightly in some implementations because ENDP is
    
+  potentially faster than ATOM.
    
+
    
+Discussion:
    
+ 
    
+  This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
    
+  It recommended an earlier proposal, TAILP-NIL:NIL, which is effectively
    
+  equivalent to Definition "A" from the Problem Description.
    
+
    
+  Pitman introduced TAILP-NIL:T as an alternative, arguing that the
    
+  definition TAILP-NIL:NIL offered no practical value to programmers
    
+  in the disputed situations, while TAILP-NIL:T was of arguable usefulness.
    
+
    
+  Pitman and van Roggen support TAILP-NIL:T.
    
+
    
+  It was suggested more than once by more than one cleanup 
    
+  committee member that we remove TAILP from the language
    
+  "since almost nobody uses it". 
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345.htm new file mode 100644 index 00000000..027c9cbf --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345.htm @@ -0,0 +1,57 @@ + + + +CLHS: Issue TEST-NOT-IF-NOT:FLUSH-ALL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TEST-NOT-IF-NOT:FLUSH-ALL Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue TEST-NOT-IF-NOT:FLUSH-ALL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345_w.htm new file mode 100644 index 00000000..68c15f81 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss345_w.htm @@ -0,0 +1,174 @@ + + + +CLHS: Issue TEST-NOT-IF-NOT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TEST-NOT-IF-NOT Writeup

    + +
    status: Passed, as amended, Jan 89 X3J13
    
+Note: some confusion in minutes as to whether COMPLEMENT was added
    
+	as part of TEST-NOT-IF-NOT or whether FUNCTION-COMPOSITION was
    
+	passed but with only COMPLEMENT preserved.
    
+	In any case: TEST-NOT-IF-NOT:FLUSH-ALL as stated here
    
+	passed with "Remove" -> "Deprecate". See issue
    
+	FUNCTION-COMPOSITION for more details.
    
+
    
+Forum: Cleanup
    
+Issue:          TEST-NOT-IF-NOT
    
+References:     Functions offering a :TEST-NOT keyword:
    
+                 ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
    
+                 DELETE-DUPLICATES (p254), FIND (p257),
    
+                 INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
    
+                 NINTERSECTION (p277), NSET-DIFFERENCE (p278),
    
+                 NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
    
+                 NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
    
+                 RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
    
+                 SEARCH (p258), SET-DIFFERENCE (p278), 
    
+                 SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
    
+                 SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
    
+                 UNION (p276);
    
+                Functions with "-IF-NOT" in their name:
    
+                 ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
    
+                 DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
    
+                 MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
    
+                 NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
    
+                 RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
    
+                 SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
    
+Related Issue:  FUNCTION-COMPOSITION
    
+Category:       CHANGE
    
+Edit history:   02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
    
+                05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
    
+                01-Dec-88, Version 3 by Masinter (add discussion)
    
+                18-Mar-89, Version 4 by Masinter (as amended)
    
+
    
+Problem Description:
    
+
    
+  The -IF-NOT functions are functionally unnecessary.
    
+
    
+  The :TEST-NOT keywords are not only functionally unnecessary but
    
+  also problematic because it's not clear what to do when both :TEST
    
+  and :TEST-NOT are provided.
    
+
    
+  Many people think Common Lisp is more `bloated' than it needs
    
+  to be and these aspects of the language are commonly cited
    
+  specific examples.
    
+
    
+Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
    
+
    
+  Deprecate all -IF-NOT functions (named above) from Common Lisp.
    
+
    
+  Deprecate the :TEST-NOT keyword from the Common Lisp functions which 
    
+  currently provide them (named above).
    
+
    
+
    
+  Rationale:
    
+  
    
+    This makes the language a bit simpler.
    
+  
    
+    The removal of :TEST-NOT also makes the language easier to explain.
    
+  
    
+  Cost to Implementors:
    
+  
    
+    Very slight.
    
+  
    
+    Some symbols would disappear from the LISP package but could
    
+    still be offered in proprietary packages if deemed important
    
+    enough.
    
+  
    
+    Implementations could compatibly retain the :TEST-NOT keywords
    
+    for an interim period.
    
+  
    
+Current Practice:
    
+
    
+  Presumably no one has done this yet.
    
+
    
+Cost to Users:
    
+
    
+  Some rewrites would be needed.
    
+
    
+  Those rewrites, which are already fairly simple, would be even
    
+  more simple if some form of the FUNCTION-COMPOSITION issue is
    
+  voted in -- in particular, the COMPLEMENT function which it 
    
+  proposes would help enormously in this regard.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Common Lisp would continue to be what some people feel is
    
+  "bigger than it needs to be".
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  Presumably this makes the language easier to teach.
    
+
    
+Performance impact:
    
+
    
+  Very small; removing the :TEST-NOT keywords would
    
+  make the simple implementation of the functions that
    
+  used to have them slightly faster, but the resulting
    
+  code of the inner loop is likely to be much slower.
    
+
    
+Discussion:
    
+
    
+  Many people objected strongly to this proposals --
    
+  they might have been a nice idea five years ago, but are
    
+  gratuitous incompatibilities now: incompatible changes with
    
+  insufficient payback.
    
+
    
+  Some of those objections might be tempered if some additional
    
+  changes were made to Common Lisp: adding a COMPLEMENT
    
+  function, or if there were a strategy to declare some parts of the
    
+  language "obsolete". Since these conditions haven't been done,
    
+  their objections stand.
    
+
    
+  Steele noted that one main reservation to FLUSH-ALL is that
    
+  he uses REMOVE-IF-NOT much more than REMOVE-IF.
    
+
    
+  This issue is related to FUNCTION-COMPOSITION, but is not
    
+  dependent on it.  Some support the combination of  FLUSH-ALL and 
    
+  the NEW-FUNCTIONS part of FUNCTION-COMPOSITION in spite of
    
+  the incompatible change because of the aesthetic appeal.
    
+
    
+  Some people expressed their intention to vote for FLUSH-ALL
    
+  only if FUNCTION-COMPOSITION:NEW-FUNCTIONS.
    
+
    
+  It was noted that and
    
+  adding a #~ readmacro such that 
    
+      (FIND-IF-NOT #'ZEROP '(0 0 3))
    
+   == (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
    
+   == (FIND-IF #~ZEROP '(0 0 3))
    
+
    
+  The modification of these functions is moot for those who
    
+  prefer to use extended LOOP macro/iteration constructs
    
+  in lieu of the sequence functions.
    
+
    
+  Several alternative names for REMOVE-IF-NOT were
    
+  suggested: KEEP-IF, ABSTRACT, FILTER. We did not
    
+  pursue these suggestions.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346.htm new file mode 100644 index 00000000..c3353495 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue THE-AMBIGUITY:FOR-DECLARATION Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue THE-AMBIGUITY:FOR-DECLARATION Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue THE-AMBIGUITY:FOR-DECLARATION:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346_w.htm new file mode 100644 index 00000000..72671076 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss346_w.htm @@ -0,0 +1,163 @@ + + + +CLHS: Issue THE-AMBIGUITY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue THE-AMBIGUITY Writeup

    + +
    Forum:        cleanup
    
+Issue:        THE-AMBIGUITY
    
+References:   THE (page 161)
    
+Category:     CLARIFICATION
    
+Edit history: 21-Oct-88, version 1 by Rees
    
+              11-Jan-89, version 2 by Masinter (fix typos)
    
+
    
+Problem description:
    
+
    
+  CLtL does not explicitly say whether the type specifier in a THE
    
+  form may be any type specifier or must be a type specifier suitable
    
+  for discrimination.  Although THE is decsribed as a "declaration"
    
+  form, some CL implementations have assumed that the specifier must
    
+  be for discrimination, and disallow e.g.,
    
+
    
+    (THE (FUNCTION (T T) CONS) #'CONS)
    
+
    
+  We should either say that the implementations are right, or
    
+  explicitly say that they are wrong, since this case is easily
    
+  overlooked.
    
+
    
+Proposal (THE-AMBIGUITY:FOR-DECLARATION):
    
+
    
+  Clarify that the type specifier in
    
+
    
+	(THE type exp)
    
+
    
+  may be any valid type specifier.  In the case that exp returns one
    
+  value and type is not a VALUES type specifier, (THE type exp) is
    
+  equivalent to
    
+
    
+	(LET ((g exp))
    
+	  (DECLARE (TYPE type g))
    
+	  g)
    
+
    
+  where "g" is a gensym.
    
+  
    
+Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION):
    
+
    
+  Clarify that the type specifier in
    
+
    
+	(THE type exp)
    
+
    
+  must be a valid type for discrimination, as for TYPEP, or it must
    
+  be of the form (VALUES type*) where type* are all valid for discrimination.
    
+
    
+Current practice:
    
+
    
+  The Symbolics Genera and VAX LISP V2.2 interpreters signal errors for
    
+
    
+	(THE (FUNCTION (T T) CONS) #'CONS),
    
+
    
+  but this may not be intentional.  CLtL would seem to allow it.
    
+
    
+Test case:
    
+
    
+  (THE (FUNCTION (T T) CONS) #'CONS),
    
+
    
+  should return the CONS function under FOR-DECLARATION,
    
+  and should be an error under FOR-DISCRIMINATION.
    
+
    
+Cost to implementors:
    
+
    
+  Trivial cost for THE-AMBIGUITY:FOR-DISCRIMINATION; this is a compatible
    
+  restriction.
    
+
    
+  For THE-AMBIGUITY:FOR-DECLARATION, implementations that do not
    
+  already allow arbitrary type specifiers but which want to check that
    
+  the type in a THE is satisfied would have to create an internal
    
+  version of TYPEP which could manage not to signal invalid-type-specifier
    
+  errors in those situations where TYPEP would because the type is a
    
+  declaration-only one.
    
+
    
+Cost to users:
    
+
    
+  Users of implementations that support THE-AMBIGUITY:FOR-DECLARATION
    
+  might have to remove or change some uses of THE in their code if the
    
+  opposing alternative is adopted.
    
+
    
+Benefits:
    
+
    
+  Either way, an ambiguity in the language specification would be clarified.
    
+
    
+Aesthetics:
    
+
    
+  THE-AMBIGUITY:FOR-DECLARATION would seem to be more consistent with
    
+  DECLARE and with the intent of THE, which is supposed to be a way to
    
+  provide information for documentation and for the benefit of compilation.
    
+
    
+Discussion:
    
+
    
+  Rees supports THE-AMBIGUITY:FOR-DECLARATION.
    
+
    
+  Appropriate error situation terminology must be chosen for the
    
+  situation that a THE declaration (or other declaration) is
    
+  unsatisfied, but that must be done regardless of this proposal.
    
+
    
+  This proposal would suggest that a function should be added to CL to
    
+  do the checking that THE would want to do:
    
+
    
+	  (PROBABLY-TYPEP object type-spec)
    
+
    
+  [terrible name of course] returns multiple values a la SUBTYPEP: T T
    
+  if the object definitely has the type, NIL T if it definitely
    
+  doesn't, and T NIL (or NIL NIL?) otherwise.  Assuming that an
    
+  interpreted THE-expression actually checks types, you could almost
    
+  define this function using the condition system and EVAL.  (Ugh!)
    
+  Without PROBABLY-TYPEP, a meta-circular interpreter is more
    
+  difficult to write.
    
+
    
+  If a suitable name was found for this function, the additional
    
+  functionality could be suggested as an independent proposal, since
    
+  regardless of the outcome of this issue, the functionality is still
    
+  useful for checking DECLARE's.
    
+
    
+  Various implementation mechanisms were discussed for dealing
    
+  with THE checking.
    
+
    
+  Are there any remaining type specifiers beyond the list form
    
+  of the FUNCTION type that differ between "declaration" and
    
+  "discrimination"?
    
+
    
+  "I support FOR-DECLARATION.  Lucid CL has the same bug in
    
+  the interpreter as the others (a "bug" assuming FOR-DECLARATION).
    
+  TYPEP is used to check the legality of the type specifier in THE."
    
+
    
+  In considering possible ways in which the type-checking logic
    
+  for THE and DECLARE might work, don't forget things like
    
+	(the (not (function (t t) integer)) 7),
    
+  which you would want to signal an error.  I don't think this can be
    
+  done with only TYPEP and conditions.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347.htm new file mode 100644 index 00000000..a05ac7c6 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue THE-VALUES:RETURN-NUMBER-RECEIVED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue THE-VALUES:RETURN-NUMBER-RECEIVED Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue THE-VALUES:RETURN-NUMBER-RECEIVED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347_w.htm new file mode 100644 index 00000000..2fcba139 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss347_w.htm @@ -0,0 +1,185 @@ + + + +CLHS: Issue THE-VALUES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue THE-VALUES Writeup

    + +
    Issue:                 THE-VALUES
    
+References:            THE special form, VALUES type specifier
    
+Related issues:        THE-AMBIGUITY
    
+Category:              CLARIFICATION
    
+Edit history:          v1, 24 Feb 1991, Sandra Loosemore
    
+Status: X3J13 passed v1:RETURN-NUMBER-RECEIVED on vote of 10-1, Mar-91
    
+
    
+Problem description:
    
+
    
+  Are the following forms valid, and if so how many values are returned 
    
+  in each case?
    
+
    
+  #1: (truncate 7 3)
    
+  #2: (the integer (truncate 7 3))
    
+  #3: (the (values integer) (truncate 7 3))
    
+  #4: (the (values integer integer) (truncate 7 3))
    
+  #5: (the (values integer integer symbol) (truncate 7 3))
    
+
    
+There are two proposals, RETURN-NUMBER-RECEIVED and STRICT-MATCHING.
    
+
    
+Proposal (THE-VALUES:RETURN-NUMBER-RECEIVED):
    
+
    
+  (1) Clarify that the THE special form returns the exact values as 
    
+      its subform.
    
+
    
+  (2) Clarify that it is not an error if the subform returns more values 
    
+      than what is specified by the type specifier, provided that the
    
+      values for which types are declared are indeed of those types.
    
+      (In particular, if the type specifier is not a VALUES type 
    
+      specifier, multiple values may still be returned.)
    
+
    
+  (3) Clarify that it is not an error if the subform returns fewer values
    
+      than what is specified by the type specifier.  Missing values are
    
+      treated as NIL for the purposes of checking their types.
    
+
    
+  Rationale for proposal RETURN-NUMBER-RECEIVED:
    
+
    
+    Point by point,
    
+  
    
+    (1) THE is supposed to act purely as a declaration.  It should not
    
+        change the number of values that are returned by its subform.
    
+  
    
+    (2) This is consistent with the way extra values are simply ignored
    
+        by MULTIPLE-VALUE-BIND and friends.
    
+  
    
+    (3) This is consistent with the way missing values are treated as NIL
    
+        by MULTIPLE-VALUE-BIND and friends.
    
+
    
+
    
+Proposal (THE-VALUES:STRICT-MATCHING):
    
+
    
+  (1) Clarify that the THE special form returns the exact values as 
    
+      its subform.
    
+
    
+  (2) Clarify that it is an error if the number and syntax of values 
    
+      returned by the subform do not match the given type specifier
    
+      exactly.  In particular, if the type specifier is not a VALUES
    
+      type specifier then only a single value may be returned.
    
+
    
+  Rationale for proposal STRICT-MATCHING:
    
+  
    
+    Point by point,
    
+  
    
+    (1) THE is supposed to act purely as a declaration.  It should not
    
+        change the number of values that are returned by its subform.
    
+
    
+    (2) This is consistent with the description of the VALUES type 
    
+        specifier as specifying the arguments of a function which could
    
+        capture the values via MULTIPLE-VALUE-CALL.  Since argument
    
+        mismatches are clearly "is an error" situations, this should be
    
+        too.  This is also apparently closer to current practice than
    
+        proposal RETURN-NUMBER-RECEIVED.
    
+
    
+Examples:
    
+
    
+  Under proposal RETURN-NUMBER-RECEIVED, all of the examples given in 
    
+  the problem description section are valid and return the values 2 and 1.
    
+
    
+  Under proposal STRICT-MATCHING, tests 2, 3, and 5 are in error.  Tests
    
+  1 and 4 are valid and return the values 2 and 1.
    
+  
    
+Current Practice:
    
+
    
+  Lucid CL version 4.0 signals an error in cases 3 and 5 (at least in the
    
+  interpreter).  It returns the values 2 and 1 in case 2.
    
+
    
+  Allegro CL version 3.1 signals an error in cases 2, 3, and 5.
    
+
    
+Cost to Implementors:
    
+
    
+  Probably small.  Neither proposal requires checking to be performed in
    
+  any situation.  However under proposal RETURN-NUMBER-RECEIVED, some 
    
+  implementations will have to be changed to not do some checks they 
    
+  currently do.
    
+
    
+Cost to Users:
    
+
    
+  Users may find the stricter error checking permitted by proposal 
    
+  STRICT-MATCHING helpful.  However, if implementations that currently
    
+  do not check these errors begin to do so, some programs that currently
    
+  work in those implementations to stop working.
    
+
    
+Cost of non-adoption:
    
+
    
+  Confusion about what the THE type specifier really means.
    
+
    
+Performance impact:
    
+
    
+  Probably small, but proposal STRICT-MATCHING might permit compilers
    
+  to be more aggressive about some kinds of type and multiple-value
    
+  optimizations.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Seems to depend on who you talk to.  In the best of all possible
    
+  worlds, MULTIPLE-VALUE-BIND and friends would have ordinary lambda-list
    
+  syntax and follow the same rules as for ordinary lambda-binding, so there 
    
+  wouldn't be the an inconsistency with MULTIPLE-VALUE-CALL to have to
    
+  resolve one way or the other.
    
+
    
+Discussion:
    
+
    
+
    
+  This issue was discussed on the common-lisp mailing list some time ago,
    
+  but never written up.  Here's the last message from that discussion:
    
+
    
+    Date: Thu, 20 Apr 1989 17:53 EDT
    
+    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    
+    
    
+        Date: Thu, 20 Apr 89 16:59:15 EDT
    
+        From: Guy Steele <gls@Think.COM>
    
+           ...
    
+           PROPOSAL:
    
+    
    
+           What it boils down to, is that THE should check only as many types
    
+           as requested (and pass back only as many).
    
+    
    
+        No, this is not cool.  THE is supposed to act purely as a declaration,
    
+        but you are changing it to require it to pass on only as many values
    
+        as the type specifer indicates.  This could change the semantics of
    
+        a suitably devious program.
    
+    
    
+        Better to say that it checks as many types as requsted, but passes on
    
+        exactly the values it receives.
    
+        --Guy
    
+    
    
+    Even though I agree with your position, I think it's worth our writing up
    
+    a clarification issue to make sure we're all agreed and that it's 100% 
    
+    clear in the ANSI spec.
    
+-------
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348.htm new file mode 100644 index 00000000..31e03102 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue TIME-ZONE-NON-INTEGER:ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TIME-ZONE-NON-INTEGER:ALLOW Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue TIME-ZONE-NON-INTEGER:ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348_w.htm new file mode 100644 index 00000000..e12e2f24 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss348_w.htm @@ -0,0 +1,114 @@ + + + +CLHS: Issue TIME-ZONE-NON-INTEGER Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TIME-ZONE-NON-INTEGER Writeup

    + +
    Status:       Passed v1 (as amended in v2) Mar-89 by 18-0 vote.
    
+Issue:        TIME-ZONE-NON-INTEGER
    
+References:   Section 25.4.1 (Time Functions) (p. 443-444)
    
+Category:     CLARIFICATION
    
+Edit history: 1-Mar-89, Version 1 by Chapman
    
+	      10-Apr-89, Version 2 by Pitman (amendments per X3J13)
    
+
    
+Problem Description:
    
+
    
+ CLtL states that the time zone part of Decoded Time is an integer.
    
+ However, it is possible to have a non-integer time-zone.
    
+
    
+Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
    
+
    
+ Specify that the time zone part of Decoded Time is 
    
+   1. a rational number (either an integer or a ratio)
    
+   2. in the range -24 to 24 (inclusive on both ends)
    
+   3. a multiple of 1/3600.
    
+
    
+Rationale:
    
+
    
+ 1. For CL to accommodate all possible time designations, it is
    
+    necessary to allow time zone to be non-integer.  Some places
    
+    in the world are on half-hour or quarter-hour times.
    
+
    
+    There is no demand for floating point time zones.  Since such
    
+    zones would introduce inexact arithmetic, we did not consider
    
+    adding them at this time.
    
+    
    
+ 2. This prohibits the perverse use of very incredibly time zone
    
+    magnitudes to get around the year restriction on times
    
+    in portable code.
    
+
    
+ 3. This requires time zones to be represented as even multiples
    
+    of 1 second.
    
+
    
+Current Practice:
    
+
    
+ VAX LISP allows time zone to be non-integer.
    
+
    
+Cost to Implementors:
    
+
    
+ Very slight. Implementations which use integer-only arithmetic
    
+ in dealing with time zones might have to switch to a more generic
    
+ kind of arithmetic.
    
+
    
+Cost to Users:
    
+
    
+ Depends on situation. Very slight negative to very strong positive
    
+ effects will be seen by users.
    
+
    
+ In some cases, this legitimizes time zones which are already a
    
+ political necessity and may make life easier for users.
    
+
    
+ In at least one known case, this will make things a little harder
    
+ because `very large' time zones will not be permitted.  However, 
    
+ such time zones probably were not really portable to begin with
    
+ so this is more just a recognition of the status quo.
    
+
    
+Benefits:
    
+
    
+ See Rationale.
    
+
    
+Conversion Cost:
    
+
    
+ In most cases, no user code will have to be modified.
    
+
    
+ In the one known case using `very large' time zones, the user may
    
+ have to write his own time manipulation software if he really wants
    
+ to be portable.
    
+
    
+Aesthetics:
    
+
    
+ Probably slightly improved.
    
+
    
+Discussion:
    
+
    
+ Haflich was claiming he might want to use very large negative time zones
    
+ to go back in history beyond 1900 (where universal times supposedly 
    
+ bottom out).  However, most implementations probably don't represent the
    
+ shifts in calendar system which occurred at various points before that
    
+ time, most implementors present at the Mar-89 meeting seemed to think this
    
+ `hack' was probably not really going to work portably anyway.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349.htm new file mode 100644 index 00000000..d7e48766 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349_w.htm new file mode 100644 index 00000000..2b9f651d --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss349_w.htm @@ -0,0 +1,199 @@ + + + +CLHS: Issue TYPE-DECLARATION-ABBREVIATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TYPE-DECLARATION-ABBREVIATION Writeup

    + +
    TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL was passed 11-0 at the June 1990 meeting.
    
+TYPE-DECLARATION-ABBREVIATION:FORBID-ALL failed 5-8 at the June 1990 meeting.
    
+
    
+Issue:         TYPE-DECLARATION-ABBREVIATION
    
+
    
+References:    CLtL p.158, and CLtL Table 4-1 (p.43)
    
+               ANSI CL draft spec p.6-56 (rev 7.31 of 8/29/89)
    
+               ANSI CL draft spec Fig 2-10, 2-11 (p.2-28, 2-29)
    
+
    
+Related Issues: COMPILE-ENVIRONMENT-CONSISTENCY
    
+                LISP-SYMBOL-REDEFINITION
    
+                PACKAGE-CLUTTER
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  1-May-90, Version 1 by Moon
    
+               4-May-90, Version 2 by Moon (update discussion)
    
+               6-Jun-90, Version 3 by Moon (update discussion)
    
+               8-Jun-90, Version 4 by Moon (reflect the X3J13 meeting)
    
+
    
+Problem description:
    
+
    
+  TYPE declaration abbreviation, the ability to write
    
+    (DECLARE (<type-specifier> <var> <var>...))
    
+  in place of
    
+    (DECLARE (TYPE <type-specifier> <var> <var>...))
    
+  is allowed only for some <type-specifier>s, not for all of them.
    
+
    
+  CLtL allows the abbreviation only when <type-specifier> is a symbol
    
+  and not a user-defined or implementation-defined type.
    
+
    
+  The draft ANSI CL specification is unclear since it refers to the wrong
    
+  table.  If it really meant to refer to Figure 2-11 rather than 2-10, then
    
+  it says the same thing as CLtL, assuming the mistakes in Figure 2-11 get
    
+  corrected (e.g. standard-generic-function is missing).
    
+
    
+  This makes a distinction between type specifiers specified by the
    
+  language standard and type specifiers defined by the user or by the
    
+  implementation.  Do programmers have to know whether types they use come
    
+  from the kernel language or from a library in order to know whether they
    
+  are allowed to use abbreviated type declarations?  Do they have to refer
    
+  to this table that currently contains 91 entries and is still growing?
    
+
    
+  This also makes an unnecessary distinction between type specifiers that
    
+  are symbols and those that are lists or classes.
    
+
    
+  This issue contains two proposals.
    
+
    
+  This is Symbolics issue #31 and is related to Loosemore's issue #8
    
+  of 27 Feb 90.
    
+
    
+Proposal (TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL):
    
+
    
+  Allow the word TYPE to be omitted from all TYPE declarations.
    
+
    
+  A symbol cannot be both the name of a type and the name of a
    
+  declaration.  Defining a symbol as a class, structure, condition,
    
+  or type name, when the symbol has been defined or proclaimed
    
+  as a declaration name, or vice versa, signals an error.
    
+
    
+Examples:
    
+
    
+  (DEFUN SUBSTRING (STRING &OPTIONAL (START 0) END)
    
+    (DECLARE (STRING STRING)
    
+             ((INTEGER 0 *) START)
    
+             ((OR NULL (INTEGER 0 *)) END))
    
+    (SUBSEQ STRING START END))
    
+  
    
+  (DEFSTRUCT SHIP HEADING TONNAGE PASSENGER-LIST)
    
+  
    
+  (DEFUN EMBARK (P S)
    
+    (DECLARE (SHIP S))
    
+    (PUSHNEW P (SHIP-PASSENGER-LIST S)))
    
+
    
+  (DEFCLASS ASTRONAUT () (HELMET-SIZE FAVORITE-BEVERAGE))
    
+
    
+  (DEFUN CHECKOUT (A)
    
+    (DECLARE (#.(FIND-CLASS 'ASTRONAUT) A))
    
+    (UNLESS (EQ (SLOT-VALUE A 'FAVORITE-BEVERAGE) 'TANG)
    
+      (ERROR "~A is not a proper astronaut" A)))
    
+
    
+Rationale:
    
+
    
+  Arbitrary syntactic differences between built-in facilities and
    
+  user-defined extensions are not in the spirit of Lisp.
    
+
    
+  Making type names and declaration names be a single namespace
    
+  eliminates any issue of ambiguity in interpreting a decl-spec.
    
+
    
+Proposal (TYPE-DECLARATION-ABBREVIATION:FORBID-ALL):
    
+
    
+  Do not allow the word TYPE to be omitted from any TYPE declarations.
    
+  This would be an incompatible change.
    
+
    
+Current practice:
    
+
    
+  I don't know of any implementation that implements either proposal.
    
+
    
+Cost to Implementors of ALLOW-ALL:
    
+
    
+  Small.  It should be easy to change the declaration parser to check
    
+  whether the car of a decl-spec is a valid type-specifier, and if so
    
+  either insert the word TYPE or signal an error, depending on whether it's
    
+  also a proclaimed declaration.
    
+
    
+Cost to Users of ALLOW-ALL:
    
+
    
+  None to most users.  Some users might have programs that use the same
    
+  symbol as both a declaration name and a type name, and they would have
    
+  to rename either the declaration or the type.
    
+
    
+Cost of non-adoption:
    
+
    
+  An aesthetic wart on the language will remain.
    
+
    
+  Implementors will continue to have to maintain a large and seemingly
    
+  ever-changing table of type names that are acceptable as declarations.
    
+
    
+Performance impact:
    
+
    
+  There might be a trivial increase in compilation speed as a result of
    
+  adopting either proposal.  There should be no run-time performance impact.
    
+
    
+Benefits:
    
+
    
+  Improved language consistency and aesthetics.
    
+
    
+Esthetics:
    
+
    
+  Arbitrary syntactic differences between built-in facilities and
    
+  user-defined extensions are not in the spirit of Lisp.
    
+
    
+Discussion:
    
+
    
+  Rob MacLachlan was concerned in February about non-obvious side-effects
    
+  of allowing user types here, but never mentioned a specific problem.
    
+  From re-reading his mail, he was most likely concerned only about things
    
+  that are not in this proposal.
    
+
    
+  Another possible approach would be to eliminate type declaration
    
+  abbreviation, however no one liked that idea when it was mentioned a few
    
+  months ago.
    
+
    
+  David Gray is opposed to allowing abbreviation for all types on the
    
+  grounds that infrequently-used types might not be recognized as types by
    
+  someone reading a program.  Asked for suggestions, he said:
    
+
    
+    Well, if I had to be limited to twelve, I would choose:
    
+
    
+            ARRAY CHARACTER CONS FIXNUM FLOAT INTEGER LIST NUMBER
    
+            STREAM STRING SYMBOL VECTOR
    
+
    
+    but I suspect that this small a list would be too much of an incompatibility
    
+    to be acceptable since other people are sure to have a different favorite
    
+    twelve.  It might be possible to agree on a list of around twenty, such as:
    
+
    
+            ARRAY BIT BIT-VECTOR CHARACTER COMPLEX CONS FIXNUM FLOAT 
    
+            INTEGER KEYWORD LIST NUMBER PACKAGE PATHNAME REAL SEQUENCE
    
+            STREAM STRING SYMBOL VECTOR
    
+
    
+  David Moon prefers not to single out some types as special cases.
    
+
    
+  Glenn Burke is not entirely comfortable with the proposal, but doesn't like
    
+  restricting programmers' use of data-abstraction by singling out some types
    
+  as special cases.
    
+
    
+  Kim Barrett is concerned that signalling an error when there is a collision
    
+  between a type name and a declaration name doesn't really solve the problem.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350.htm new file mode 100644 index 00000000..88739cef --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_m.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_m.htm new file mode 100644 index 00000000..f2179451 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_m.htm @@ -0,0 +1,32 @@ + + + +CLHS: Issue TYPE-OF-AND-PREDEFINED-CLASSES Summary Menu + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    + +
    + + + +

    Issue TYPE-OF-AND-PREDEFINED-CLASSES Summary Menu

    + +Changes related to this issue are cross-referenced in the specification in differing ways. Please select one:

    + +

    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_w.htm new file mode 100644 index 00000000..39c85b46 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss350_w.htm @@ -0,0 +1,405 @@ + + + +CLHS: Issue TYPE-OF-AND-PREDEFINED-CLASSES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TYPE-OF-AND-PREDEFINED-CLASSES Writeup

    + +
    Issue:          TYPE-OF-AND-PREDEFINED-CLASSES
    
+Forum:          Cleanup
    
+References:     Draft 8/29/89, sections 2.2 and 2.3
    
+                Draft 8/29/89, TYPE-OF
    
+                Issue TYPE-OF-UNDERCONSTRAINED
    
+                Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED
    
+                Issue FUNCTION-TYPE
    
+                Issue FLOATING-POINT-CONDITION-NAMES
    
+                Issue READER-ERROR
    
+                Condition System, Version 18
    
+Category:       Change
    
+Edit History:   Version 1, 1/2/90 by Kim A. Barrett
    
+                Version 2, 2/16/90 by Kim A. Barrett (from Moon's comments)
    
+
    
+Problem Description:
    
+
    
+ In the 8/29/89 Draft there are three different lists of built-in type
    
+ specifiers, all of which are slightly different.  Since some of the
    
+ differences seem to be simply oversights, it would probably be helpful if they
    
+ could be merged together. 
    
+
    
+ The locations of these lists in the Draft are (1) Section 2.2, in the
    
+ description of the type disjointness requirements in the subsection entitled
    
+ "Type Relationships", (2) Section 2.3, in Figure 2-13 "Classes that correspond
    
+ to pre-defined type specifiers", and (3) in the description of the function
    
+ TYPE-OF. 
    
+
    
+ The following table indicates which type names do not appear in all three
    
+ places.  The groupings were made to facilitate the discussion below. 
    
+
    
+                        (1)            (2)             (3)
    
+  Group 1
    
+  CONDITION             x                               x
    
+  LIST                  x               x
    
+  LOGICAL-PATHNAME
    
+  REAL                  x               x
    
+  RESTART               x                               x
    
+  Group 2
    
+  SHORT-FLOAT           special                         x
    
+  SINGLE-FLOAT          special                         x
    
+  DOUBLE-FLOAT          special                         x
    
+  LONG-FLOAT            special                         x
    
+  Group 3
    
+  BROADCAST-STREAM      x
    
+  CONCATENATED-STREAM   x
    
+  ECHO-STREAM           x
    
+  FILE-STREAM           x
    
+  STRING-STREAM         x
    
+  SYNONYM-STREAM        x
    
+  TWO-WAY-STREAM        x
    
+  Group 4
    
+  SIMPLE-BIT-VECTOR     x
    
+  SIMPLE-STRING         x
    
+  SIMPLE-VECTOR         x
    
+  Group 5
    
+  SERIOUS-CONDITION     x
    
+  SIMPLE-CONDITION      x
    
+  WARNING               x
    
+  Group 6
    
+  FIXNUM                x
    
+  BIGNUM                x
    
+
    
+Proposal (TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND)
    
+
    
+ 1. Make the following changes to the disjointness requirements specified in
    
+ Section 2.2, subsection Type Relationships.  This supersedes issue
    
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED and the corresponding sections of issue
    
+ FUNCTION-TYPE.
    
+
    
+ 1a. Change the third bullet to
    
+
    
+   "Among the types which correspond to predefined classes (listed in Figure
    
+    {insert figure number here, currently 2-13 }) only the subtype
    
+    relationships specified for those classes may exist.  Any type created by
    
+    DEFSTRUCT, DEFCLASS, or DEFINE-CONDITION is disjoint from any of the
    
+    listed types and from any other type created by these forms, except for
    
+    type relationships explicitly established by specifying superclasses in
    
+    DEFCLASS or DEFINE-CONDITION, or through the use of the :include option of
    
+    DEFSTRUCT."
    
+
    
+ 1b. Strike bullets 4-6 and 21 (since they now follow from bullet 3).
    
+
    
+ 2. Make the following changes to the constraints on TYPE-OF.
    
+
    
+ 2a. Change the first constraint on TYPE-OF to be
    
+
    
+   "For any object for which (TYPEP object type) is true when type is one of
    
+    the types for which there is a corresponding predefined class listed in
    
+    Figure { insert figure number here, currently 2-13 }, the result of
    
+    TYPE-OF is a type specifier for which (SUBTYPEP (TYPE-OF object) type)
    
+    returns T T, i.e., either the type or a subtype of it (a subtype that the
    
+    implementation's SUBTYPEP can recognize)."
    
+
    
+ 2b. Change the fifth constraint on TYPE-OF to also include condition types
    
+ defined with DEFINE-CONDITION and objects created with MAKE-CONDITION.
    
+
    
+ 3. Make the following additions to the set of predefined classes.
    
+
    
+ 3a. Add the following condition classes, with the specified class precedence
    
+ lists:
    
+
    
+  ARITHMETIC-ERROR (ARITHMENTIC-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  CELL-ERROR (CELL-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  CONDITION (CONDITION T)
    
+  CONTROL-ERROR (CONTROL-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  DIVISION-BY-ZERO (DIVISION-BY-ZERO ARITHMENTIC-ERROR ERROR SERIOUS-CONDITION
    
+                        CONDITION T)
    
+  END-OF-FILE (END-OF-FILE STREAM-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  ERROR (ERROR SERIOUS-CONDITION CONDITION T)
    
+  FILE-ERROR (FILE-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  FLOATING-POINT-INEXACT (FLOATING-POINT-INEXACT ARITHMENTIC-ERROR ERROR
    
+                        SERIOUS-CONDITION CONDITION T)
    
+  FLOATING-POINT-INVALID-OPERATION (FLOATING-POINT-INVALID-OPERATION
    
+                        ARITHMENTIC-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  FLOATING-POINT-OVERFLOW (FLOATING-POINT-OVERFLOW ARITHMENTIC-ERROR ERROR
    
+                        SERIOUS-CONDITION CONDITION T)
    
+  FLOATING-POINT-UNDERFLOW (FLOATING-POINT-UNDERFLOW ARITHMENTIC-ERROR ERROR
    
+                        SERIOUS-CONDITION CONDITION T)
    
+  PACKAGE-ERROR (PACKAGE-ERROR ERROR SERIOUS-CONDITION CONDITION T) 
    
+  PARSE-ERROR (PARSE-ERROR STREAM-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  PRINT-NOT-READABLE (PRINT-NOT-READABLE ERROR SERIOUS-CONDIITON CONDITION T)
    
+  PROGRAM-ERROR (PROGRAM-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  SERIOUS-CONDITION (SERIOUS-CONDITION CONDITION T)
    
+  SIMPLE-CONDITION (SIMPLE-CONDITION CONDITION T)
    
+  SIMPLE-ERROR (SIMPLE-ERROR SIMPLE-CONDITION ERROR SERIOUS-CONDITION
    
+                        CONDITION T)
    
+  SIMPLE-TYPE-ERROR (SIMPLE-TYPE-ERROR SIMPLE-CONDITION TYPE-ERROR ERROR
    
+                        SERIOUS-CONDITION CONDITION T)
    
+  SIMPLE-WARNING (SIMPLE-WARNING SIMPLE-CONDITION WARNING CONDITION T)
    
+  STORAGE-CONDITION (STORAGE-CONDITION SERIOUS-CONDITION CONDITION T)
    
+  STREAM-ERROR (STREAM-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  STYLE-WARNING (STYLE-WARNING WARNING CONDITION T)
    
+  TYPE-ERROR (TYPE-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  UNBOUND-SLOT (UNBOUND-SLOT CELL-ERROR ERROR SERIOUS-CONDITION CONDITION T)
    
+  UNBOUND-VARIABLE (UNBOUND-VARIABLE CELL-ERROR ERROR SERIOUS-CONDITION
    
+                        CONDITION T)
    
+  UNDEFINED-FUNCTION (UNDEFINED-FUNCTION CELL-ERROR ERROR SERIOUS-CONDITION
    
+                        CONDITION T)
    
+  WARNING (WARNING CONDITION T)
    
+
    
+ 3b. Add the class RESTART, with a class precedence list of (RESTART T).
    
+
    
+ 3c. Add the class LOGICAL-PATHNAME, with a class precedence list of
    
+ (LOGICAL-PATHNAME PATHNAME T).
    
+
    
+ 3d. Add the following classes with the specified class precedence lists:
    
+  BROADCAST-STREAM              (BROADCAST-STREAM STREAM T)
    
+  CONCATENATED-STREAM           (CONCATENATED-STREAM STREAM T)
    
+  ECHO-STREAM                   (ECHO-STREAM STREAM T)
    
+  FILE-STREAM                   (FILE-STREAM STREAM T)
    
+  STRING-STREAM                 (STRING-STREAM STREAM T)
    
+  SYNONYM-STREAM                (SYNONYM-STREAM STREAM T)
    
+  TWO-WAY-STREAM                (TWO-WAY-STREAM STREAM T)
    
+ Remove the 23rd bullet from Section 2.2, subsection Type Relationships,
    
+ which lists the above types as being disjoint subtypes of STREAM.
    
+
    
+ 3e. Add the following classes from the CLOS specification, with the specified
    
+ class precedence lists:
    
+  BUILT-IN-CLASS                (BUILT-IN-CLASS CLASS STANDARD-OBJECT T)
    
+  CLASS                         (CLASS STANDARD-OBJECT T)
    
+  GENERIC-FUNCTION              (GENERIC-FUNCTION FUNCTION T)
    
+  METHOD                        (METHOD T)
    
+  METHOD-COMBINATION            (METHOD-COMBINATION T)
    
+  STANDARD-CLASS                (STANDARD-CLASS CLASS STANDARD-OBJECT T)
    
+  STANDARD-GENERIC-FUNCTION     (STANDARD-GENERIC-FUNCTION GENERIC-FUNCTION
    
+                                        FUNCTION T)
    
+  STANDARD-METHOD               (STANDARD-METHOD METHOD STANDARD-OBJECT T)
    
+  STANDARD-OBJECT               (STANDARD-OBJECT T)
    
+  STRUCTURE-CLASS               (STRUCTURE-CLASS CLASS STANDARD-OBJECT T)
    
+  STRUCTURE-OBJECT              (STRUCTURE-OBJECT T)
    
+
    
+ 4. Allow implementations to modify the class precedence lists of classes
    
+ which are not specified to include either STANDARD-OBJECT or STRUCTURE-OBJECT
    
+ to include those classes, placed before the class T but after all of the
    
+ other specified classes.
    
+
    
+Proposal (TYPE-OF-AND-PREDEFINED-CLASSES:FLOAT-SUBCLASSES)
    
+
    
+ Add the following to TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND:
    
+
    
+ 3f. Add the following subclasses of FLOAT:  SHORT-FLOAT, SINGLE-FLOAT,
    
+ DOUBLE-FLOAT, LONG-FLOAT.  It is implementation-defined which among these
    
+ classes are pairwise disjoint.  If there are fewer than four internal
    
+ representations for floats, then some of these classes will not have proper
    
+ names.  Instead, the rules for handling fewer than four internal
    
+ representations (described in Section 2.2 subsection Data Type Definition) are
    
+ used to determine the principal type name, for which there will be a class
    
+ which has a proper name.  The other types which share the internal
    
+ representation will all share the principal class.  The class precedence list
    
+ for the properly named classes are 
    
+
    
+    (class-name FLOAT REAL NUMBER T)
    
+
    
+ where 'class-name' is the name of the class.  Thus we get the following rules
    
+ to handle a situation where there are fewer than four internal representations
    
+ of floats. 
    
+
    
+    1. If there is only one internal representation for floats, then there is
    
+    one class, named SINGLE-FLOAT.  (FIND-CLASS class-name) returns this class
    
+    for all four of the subclasses of FLOAT.  The class precedence list for
    
+    this class is (SINGLE-FLOAT FLOAT REAL NUMBER T).
    
+
    
+    2. If there are two internal representations for floats, then they can be
    
+    arranged in either of the following ways: 
    
+
    
+    * Two classes are provided, named SHORT-FLOAT and SINGLE-FLOAT.
    
+      (FIND-CLASS class-name) returns the class SINGLE-FLOAT for any of the
    
+      names SINGLE-FLOAT, DOUBLE-FLOAT, or LONG-FLOAT.  The class precedence
    
+      lists of these classes are:  
    
+
    
+        SHORT-FLOAT     (SHORT-FLOAT FLOAT REAL NUMBER T)
    
+        SINGLE-FLOAT    (SINGLE-FLOAT FLOAT REAL NUMBER T)
    
+
    
+    * Two classes are provided, names SINGLE-FLOAT and DOUBLE-FLOAT.
    
+      (FIND-CLASS class-name) returns the class SINGLE-FLOAT for either of the
    
+      names SHORT-FLOAT or SINGLE-FLOAT.  (FIND-CLASS class-name) returns the
    
+      class DOUBLE-FLOAT for either of the names DOUBLE-FLOAT or LONG-FLOAT.
    
+      The class precedence lists for these classes are: 
    
+
    
+        SINGLE-FLOAT    (SINGLE-FLOAT FLOAT REAL NUMBER T)
    
+        DOUBLE-FLOAT    (DOUBLE-FLOAT FLOAT REAL NUMBER T)
    
+
    
+    3. If there are three internal representations for floats, then they can be
    
+    arranged in either of the following ways:
    
+
    
+    * Three classes are provided, named SHORT-FLOAT, SINGLE-FLOAT, and
    
+      DOUBLE-FLOAT.  (FIND-CLASS class-name) returns the class DOUBLE-FLOAT for
    
+      either of the names DOUBLE-FLOAT or LONG-FLOAT.  The class precedence
    
+      lists for these classes are: 
    
+
    
+        SHORT-FLOAT     (SHORT-FLOAT FLOAT REAL NUMBER T)
    
+        SINGLE-FLOAT    (SINGLE-FLOAT FLOAT REAL NUMBER T)
    
+        DOUBLE-FLOAT    (DOUBLE-FLOAT FLOAT REAL NUMBER T)
    
+
    
+    * Three classes are provided, named SINGLE-FLOAT, DOUBLE-FLOAT, and
    
+      LONG-FLOAT.  (FIND-CLASS class-name) returns the class SINGLE-FLOAT for
    
+      either of the names SHORT-FLOAT or SINGLE-FLOAT.  The class precedence
    
+      lists for these classes are: 
    
+
    
+        SINGLE-FLOAT    (SINGLE-FLOAT FLOAT REAL NUMBER T)
    
+        DOUBLE-FLOAT    (DOUBLE-FLOAT FLOAT REAL NUMBER T)
    
+        LONG-FLOAT      (LONG-FLOAT FLOAT REAL NUMBER T)
    
+
    
+Proposal (TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS)
    
+
    
+ Add the following to TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND:
    
+
    
+ 2c. Add the following additional constraint on TYPE-OF.
    
+
    
+  "For any object for which (TYPEP object type) is true when type is one of
    
+   the types SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, or LONG-FLOAT, the
    
+   result of TYPE-OF is a type specifier for which (SUBTYPEP (TYPE-OF object)
    
+   type) returns T T, i.e, either the type or a subtype of it (a subtype that
    
+   the implementation's SUBTYPEP can recognize)."
    
+
    
+Rationale:
    
+
    
+ Changing the list of disjoint types and the first constraint on TYPE-OF to
    
+ reference the table of predefined classes merges three places with almost
    
+ identical information, resulting in simplification and improved cohesion.
    
+ Note that one effect of this is to remove the subtypes of FLOAT (SHORT-FLOAT,
    
+ SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT) from the list of type specifiers
    
+ mentioned in the first constraint on TYPE-OF (but see the subproposals
    
+ FLOAT-SUBCLASSES and TYPE-OF-HANDLES-FLOATS), and to add the types LIST
    
+ (which is not necessary, since CONS and NULL form an exhaustive partition of
    
+ LIST) and REAL (which is probably missing due to oversight).
    
+
    
+ Adding DEFINE-CONDITION to the third bullet brings it inline with the intent
    
+ of issue CLOS-CONDITIONS.
    
+
    
+ Adding DEFINE-CONDITION and MAKE-CONDITION to the fifth constraint brings it
    
+ inline with the intent of issue CLOS-CONDITIONS.
    
+
    
+ Adding classes for the predefined condition types matches up with the
    
+ disjointness requirements specified by the Condition System, and corresponds
    
+ to the intent of issue CLOS-CONDITIONS.  It could be argued that those two
    
+ places already mandate this addition, but this proposal ensures that we are
    
+ agreed on that.
    
+
    
+ Adding RESTART as a predefined class matches up with the disjointness
    
+ requirements specified by the Condition System.  It could be argued that
    
+ the Condition System already mandates the addition of this class, but this
    
+ proposal ensures that we are agreed on that.
    
+
    
+ Adding LOGICAL-PATHNAME as a predefined class seems inline with the
    
+ expressed intent for making it a type.  It is sufficiently new that it may
    
+ simply have not been propagated to all the places that should mention it.
    
+
    
+ Adding the stream subclasses seems reasonable, since we are already
    
+ requiring them to be disjoint subtypes of STREAM.
    
+
    
+ Adding the CLOS classes fixes an oversight.
    
+
    
+ Allowing implementations to add STANDARD-OBJECT or STRUCTURE-OBJECT to the
    
+ class precedence lists allows them to implement any of the predefined classes
    
+ using the standard metaclasses STANDARD-CLASS and STRUCTURE-CLASS.
    
+
    
+ The two subproposals, FLOAT-SUBCLASSES and TYPE-OF-HANDLES-FLOATS, are two
    
+ different ways we could undo the removal of the subtypes of FLOAT from the
    
+ list of types mentioned by the first constraint on TYPE-OF.
    
+
    
+Current Practice:
    
+
    
+ Up to some "bugs" because they haven't caught up with X3J13 on some of
    
+ these yet, IIM mostly implements this proposal.
    
+
    
+ Other implementations were not surveyed.
    
+
    
+Cost to Implementors:
    
+
    
+ Redirecting the disjointness requirements to reference the list of
    
+ predefined classes and modifying the constraints on TYPE-OF primarily
    
+ affects documentation, especially in the writing of the Standard.  The
    
+ requirements on implementors are largely unchanged.
    
+
    
+ The effect of adding the various classes are probably minimal.
    
+ Implementations which already have the STREAM subtypes as distinguished
    
+ types can probably easily support them as classes too, since they are
    
+ probably implemented using DEFSTRUCT, CLOS, FLAVORS, or some other similar
    
+ mechanism, and making TYPE-OF return the right type name in this case is
    
+ probably trivial.  Implementations which don't have these stream types
    
+ already have some work to do, and the necessary support for the types will
    
+ probably produce the necessary support for the other stuff.  Similarly for
    
+ CONDITION and its subtypes, LOGICAL-PATHNAME, RESTART, and the CLOS classes.
    
+
    
+Cost to Users:
    
+
    
+ Minimal.  Many of the types mentioned here are new.  The changes to TYPE-OF
    
+ would probably be an improvement for most users.
    
+
    
+Benifits:
    
+
    
+ Fewer distributed tables which need to be maintained while writing the
    
+ Standard.
    
+
    
+Discussion:
    
+
    
+ An alternative to the unification would be to fix TYPE-OF by adding REAL to
    
+ the list of built-in types referenced by the first constraint, to modify the
    
+ fifth constraint to mention DEFINE-CONDITION, and to modify the third bullet
    
+ of the type relationships to also mention DEFINE-CONDITION.
    
+
    
+ A consequence of this proposal is that the following type names do not have
    
+ associated classes.  Perhaps we should add a table to the standard which
    
+ lists these as specifically not required to have associated classes (though
    
+ they may be classes in some implementations).
    
+
    
+ Subtypes of INTEGER            Subtypes of CHARACTER
    
+   BIGNUM                         BASE-CHARACTER
    
+   BIT                            EXTENDED-CHARACTER
    
+   FIXNUM                         STANDARD-CHAR
    
+   SIGNED-BYTE
    
+   UNSIGNED-BYTE
    
+
    
+ Subtypes of ARRAY              Subtypes of FUNCTION            Other
    
+   BASE-STRING                    COMPILED-FUNCTION               ATOM
    
+   SIMPLE-ARRAY                                                   NIL
    
+   SIMPLE-BASE-STRING           Subtypes of SYMBOL
    
+   SIMPLE-BIT-VECTOR              KEYWORD
    
+   SIMPLE-STRING
    
+   SIMPLE-VECTOR
    
+
    
+ Subtypes of FLOAT (if FLOAT-SUBCLASSES is not adopted)
    
+   SHORT-FLOAT
    
+   SINGLE-FLOAT
    
+   DOUBLE-FLOAT
    
+   LONG-FLOAT
    
+
    
+ Barrett isn't entirely happy with the class precedence lists specified for
    
+ the CLOS classes.  He feels that they might be overly constrained in some
    
+ cases.  For example, it should be possible to have an implementation make
    
+ STRUCTURE-CLASS a trivial subclass of STANDARD-CLASS, define DEFSTRUCT
    
+ (without the :type option) in terms of DEFCLASS, and make STRUCTURE-OBJECT be
    
+ a subclass of STANDARD-OBJECT.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss351.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss351.htm new file mode 100644 index 00000000..02501a5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss351.htm @@ -0,0 +1,55 @@ + + + +CLHS: Issue TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352.htm new file mode 100644 index 00000000..d80eef35 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352_w.htm new file mode 100644 index 00000000..e51c7f47 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss352_w.htm @@ -0,0 +1,206 @@ + + + +CLHS: Issue TYPE-OF-UNDERCONSTRAINED Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TYPE-OF-UNDERCONSTRAINED Writeup

    + +
    Status:	passed, Jun 89 X3J13
    
+
    
+Forum:	Cleanup
    
+Issue:      TYPE-OF-UNDERCONSTRAINED
    
+
    
+References: TYPE-OF (CLtL)
    
+            88-002R (Class-of)
    
+            88-005, p 43f, Condition system types
    
+Related issues: SUBTYPEP-TOO-VAGUE
    
+                DATA-TYPE-HIERARCHY-UNDERSPECIFIED
    
+                FUNCTION-TYPE
    
+                ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
    
+                COERCE-INCOMPLETE
    
+			
    
+
    
+Category:       CLARIFICATION/CHANGE
    
+
    
+Edit history:   Version 1,  1-Dec-88, Masinter
    
+		    Version 2,  9-Dec-88, Masinter
    
+		    Version 3, 12-Dec-88, Masinter (fix "egregious bug")
    
+		Version 4, 3-14-89 Steele
    
+		Version 5, 16-Mar-89, Masinter (add other amendments)
    
+		Version 6, 22-Jun-89, Masinter (fix as per Moon)
    
+
    
+Problem description:
    
+
    
+The specification of TYPE-OF in CLtL is so weak as to leave it 
    
+nearly useless, if any implementor actually took the specification
    
+seriously.In particular, there are almost no constraints on the
    
+value that TYPE-OF might return for any of the built in
    
+types. The only constraint placed is that for objects created by the
    
+constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
    
+defstruct.
    
+
    
+This means that implementations could return T for all other objects.
    
+
    
+Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS): 
    
+
    
+Specify that the result of TYPE-OF satisfies the following:
    
+
    
+(a) For any object for which (typep object built-in-type) is true when
    
+built-in-type is one of 
    
+
    
+INTEGER, RATIO, FLOAT, COMPLEX, NUMBER, NULL, SYMBOL, 
    
+STRING, BIT-VECTOR, VECTOR, ARRAY, RANDOM-STATE, SEQUENCE,CONS, 
    
+STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
    
+CONDITION, RESTART,
    
+RATIONAL, SHORT-FLOAT, LONG-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT
    
+
    
+the result of TYPE-OF will be a type specifier for which
    
+(subtypep (type-of object) built-in-type) returns T T, i.e., either the
    
+build-in-type or a subtype of it (a subtype that the 
    
+implementation's SUBTYPEP can recognize.)
    
+
    
+
    
+(b)  For all objects, (TYPEP object (TYPE-OF object)) will be true.
    
+(this implies that it will not be NIL, since no
    
+object is of type NIL.)
    
+
    
+(c) will not be T, or use SATISFIES, AND, OR, NOT or VALUES.
    
+
    
+(d) The type returned by TYPE-OF is always a subtype of the class
    
+returned by CLASS-OF, and is a subtype that the implementation's
    
+SUBTYPEP can recognize.
    
+
    
+(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
    
+TYPE-OF returns the proper name of the class returned by CLASS-OF
    
+if it has a proper name, and otherwise returns the class itself.
    
+
    
+In particular, for objects created by the "constructor" function
    
+of a structure defined with DEFSTRUCT without a :TYPE option,
    
+TYPE-OF will return the structure name.
    
+
    
+This proposal is intended to be consistent with 88-002R, 
    
+and not to conflict with any of the definitions in that document.
    
+
    
+Examples:
    
+
    
+It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
    
+STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
    
+as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
    
+
    
+ Given:
    
+
    
+   (defvar *foo* (make-array 5 :element-type t))
    
+   (class-name (class-of *foo*))  =>  SIMPLE-VECTOR
    
+  It is legal for
    
+   (type-of *foo*)                =>  (SIMPLE-VECTOR 5)
    
+
    
+
    
+Rationale:
    
+
    
+The original specification for "TYPE-OF" was written to allow
    
+implementation freedom, but the wording is in fact more vague than was
    
+intended. 
    
+
    
+Current practice:
    
+
    
+Most Common Lisp implementations seem to implement the proposal, at least
    
+for the types we've tried them on.
    
+
    
+Cost to Implementors:
    
+
    
+Even if there are implementations that do not currently implement the
    
+proposal, the required changes for them are likely to be minimal. 
    
+
    
+Cost to Users:
    
+
    
+Apparently none.
    
+
    
+Cost of non-adoption:
    
+
    
+TYPE-OF would remain potentially inconsistent.
    
+
    
+Performance impact:
    
+
    
+Likely none.
    
+
    
+Benefits:
    
+
    
+Bring the specification of TYPE-OF in like with its common
    
+implementation, while requiring it to be generally useful.
    
+
    
+Esthetics:
    
+
    
+Little effect.
    
+
    
+Discussion:
    
+
    
+Originally, TYPE-OF was concieved as being useful for information display.
    
+CLOS specified CLASS-OF far more precisely, in that it must return exactly
    
+the class of an object. Unless TYPE-OF is removed from the language, it
    
+seems reasonable to require it to be at least as precise as CLASS-OF.
    
+
    
+The accepted CLOS specification does not define CLASS-OF
    
+in terms of TYPE-OF, but an earlier draft did. 
    
+
    
+This proposal presumes the (passed) proposals
    
+DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
    
+accomodates the Condition System (version 18) and CLOS.
    
+
    
+If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass, 
    
+and this proposal does pass, it may be that the only way an 
    
+implementation can satisfy (TYPEP array (TYPE-OF array))
    
+would be to have (TYPE-OF array) return VECTOR or ARRAY
    
+as appropriate, i.e., with no element type qualification.
    
+
    
+It is possible to constrain TYPE-OF further, e.g., to eliminate
    
+the possibility that it might return a non-portable 
    
+implementation-specific value. For example, 
    
+(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
    
+thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
    
+
    
+We would like to make this as an implementation recommendation,
    
+however, rather than as a constraint, at this point.
    
+
    
+About part (c): the restriction on T is meaningless, since the CLASS-OF
    
+restriction dominates it. The restriction on MEMBER is OK, just to keep
    
+TYPE-OF from being the silly definition that (type-of x) = `(member ,x).  I
    
+think we're running out of good reasons to leave out SATISFIES, AND, OR,
    
+NOT, and VALUES; they're probably no more useful, but we're probably
    
+overspecifying for no good reason.
    
+
    
+Some types are left out of the list in (a), including:
    
+
    
+BIGNUM and FIXNUM were left out because their division was implementation
    
+dependent.
    
+
    
+KEYWORD was left out because under odd circumstances it is possible to
    
+dynamically change the 'type' (e.g., by UNINTERN).
    
+
    
+STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
    
+aren't built-in classes.
    
+
    
+(These reasonas are not 100% compelling.)
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353.htm new file mode 100644 index 00000000..852003d0 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353.htm @@ -0,0 +1,43 @@ + + + +CLHS: Issue TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353_w.htm new file mode 100644 index 00000000..7ce5faf2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss353_w.htm @@ -0,0 +1,172 @@ + + + +CLHS: Issue TYPE-SPECIFIER-ABBREVIATION Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue TYPE-SPECIFIER-ABBREVIATION Writeup

    + +
    Date: Mon, 25 Feb 91 12:18:07 MST
    
+From: sandra%jensen@cs.utah.edu (Sandra Loosemore)
    
+
    
+This is a new version of an issue that was amended and approved at the 
    
+June 1990 meeting.  Because there was a lot of confusion about the 
    
+amendment and I am not sure that this revision accurately reflects
    
+its intent, I think we ought to vote again on proposal 
    
+X3J13-JUN90-GUESS.
    
+
    
+
    
+Issue:            TYPE-SPECIFIER-ABBREVIATION
    
+References:       CLtL chapter 4
    
+Related issues:
    
+Category:         CLARIFICATION, CHANGE
    
+Edit history:     V1, 10 May 90, Sandra Loosemore
    
+                  V2, 13 Feb 91, Sandra Loosemore (modified proposal)
    
+
    
+
    
+Problem description:
    
+
    
+Does it make sense for the type specifiers AND, MEMBER, MOD, NOT,
    
+OR, SATISFIES, and VALUES (which are documented as list form type
    
+specifiers in CLtL but omitted from table 4-1) to be abbreviated
    
+to their atomic form?  What about the EQL type specifier?
    
+
    
+Proposal (TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS):
    
+
    
+  Clarify that:
    
+
    
+  (1) (AND) is equivalent to type T, but the AND type specifier list 
    
+      may not be abbreviated to a type specifier symbol.
    
+      * is not permitted as an argument to the AND type specifier.
    
+
    
+  (2) The EQL type specifier list requires an argument and may not be 
    
+      abbreviated to a type specifier symbol.
    
+      * may appear as the argument to an EQL type specifier, but it
    
+      indicates the literal symbol *, and does not represent an
    
+      unspecified value.
    
+
    
+  (3) (MEMBER) is equivalent to type NIL, but the MEMBER type specifier list
    
+      may not be abbreviated to a type specifier symbol.
    
+      * may appear as an argument to a MEMBER type specifier, but it
    
+      indicates the literal symbol *, and does not represent an
    
+      unspecified value.
    
+
    
+  (4) The MOD type specifier list requires an argument and may not be
    
+      abbreviated to a type specifier symbol.
    
+      * is not permitted as an argument to the MOD type specifier.
    
+
    
+  (5) The NOT type specifier list requires an argument and may not be
    
+      abbreviated to a type specifier symbol.
    
+      * is not permitted as an argument to the NOT type specifier.
    
+
    
+  (6) (OR) is equivalent to type NIL, but the OR type specifier list
    
+      may not be abbreviated to a type specifier symbol.
    
+      * is not permitted as an argument to the OR type specifier.
    
+
    
+  (7) The SATISFIES type specifier list requires an argument and may not
    
+      be abbreviated to a type specifier symbol.
    
+      * may appear as the argument to a SATISFIES type specifier, but it
    
+      indicates the literal symbol *, and does not represent an
    
+      unspecified value.
    
+
    
+  (8) (VALUES) indicates that no values are returned, but the VALUES
    
+      type specifier list may not be abbreviated to a type specifier
    
+      symbol.
    
+      * is not permitted as an argument to the VALUES type specifier.
    
+
    
+   Rationale for proposal X3J13-JUN90-GUESS:
    
+
    
+     ???
    
+
    
+
    
+Proposal (TYPE-SPECIFIER-ABBREVIATION:NONE):
    
+
    
+  Clarify that the arguments to the AND, EQL, MEMBER, MOD, NOT, OR, 
    
+  SATISFIES, and VALUES type specifier lists may not be omitted 
    
+  or be given as *.  Clarify that these symbols are not standard 
    
+  type specifier symbols.
    
+
    
+   Rationale for proposal NONE:
    
+
    
+     It's not clear what the abbreviated forms of AND, EQL,
    
+     MEMBER, NOT, OR, SATISFIES, and VALUES would mean.
    
+
    
+     While MOD could be assigned a reasonable meaning, adding it
    
+     to the list of standard type specifier symbols is a
    
+     pointless change to the language.
    
+     
    
+Current Practice:
    
+
    
+  Unknown.
    
+
    
+Cost to Implementors:
    
+
    
+  Trivial.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  Part of the language specification will be vague and
    
+  confusing.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Part of the language specification will be made more precise.
    
+
    
+Esthetics:
    
+
    
+  Seems to be a matter of personal taste.
    
+
    
+Discussion:
    
+
    
+  Proposal NONE was accepted at the June 1990 meeting with the following
    
+  amendment, replacing the first paragraph of the proposal:
    
+
    
+     Clarify certain type specifiers as follows:
    
+      (AND)    is equivalent to T.
    
+      (MEMBER) is equivalent to NIL
    
+      (OR)     is equivalent to NIL.
    
+     AND, EQL, MEMBER, MOD, NOT, OR, SATISFIES, and VALUES type
    
+     specifiers may not be abbreviated to type specifiers that
    
+     are symbols.
    
+     AND, NOT, OR and VALUES type specifiers may not take * as
    
+     an argument (i.e., as an unspecified type)
    
+
    
+  Taken literally, this amendment leaves some questions unanswered,
    
+  such as whether (EQL) is meaningful or what (EQL *) might mean.
    
+  Proposal X3J13-JUN90-GUESS is my attempt at guessing what the amendment
    
+  was really trying to say.
    
+
    
+  Loosemore thinks that we ought to make MOD == (MOD) == (MOD *) ==
    
+  (integer 0 (*)) == UNSIGNED-BYTE, but everybody else seems to hate
    
+  the idea.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354.htm new file mode 100644 index 00000000..90a20957 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354_w.htm new file mode 100644 index 00000000..25ea4d84 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss354_w.htm @@ -0,0 +1,177 @@ + + + +CLHS: Issue UNDEFINED-VARIABLES-AND-FUNCTIONS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue UNDEFINED-VARIABLES-AND-FUNCTIONS Writeup

    + +
    Status: Passed, as amended, Jun89 X3J13
    
+Issue:        UNDEFINED-VARIABLES-AND-FUNCTIONS
    
+References:   5.1.2 Variables (CLtL pp55-56),
    
+	      Slots (88-002R, p1-10)
    
+Category:     CHANGE
    
+Edit history: 29-Nov-88, Version 1 by Pitman
    
+		3-Jul-89, Version 2 by Masinter (as per Jun89X3J13)
    
+Problem Description:
    
+
    
+  CLtL does not specify what happens if you attempt to call a named function
    
+  which is in fact undefined. In most implementations, it would be devastating to
    
+  actually jump to code which you had not verified to be a function, so this error
    
+  should be easily caught -- yet, CLtL does not guarantee that an error will be
    
+  signalled even in the safest, least fast OPTIMIZE settings.
    
+
    
+  CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
    
+
    
+  CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
    
+  SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
    
+  signals an error."
    
+
    
+  CLOS and CLtL are not in agreement on their treatment of unbound variables.
    
+
    
+  CLtL is very weak in that it guarantees no support for reliably detecting
    
+  and signalling an error when the error situation occurs, even in the safest,
    
+  least fast OPTIMIZE setting.
    
+
    
+  CLOS is very strong in that it forces detection of the error in all
    
+  situations -- even in the fastest, least safe OPTIMIZE setting.
    
+
    
+  The disparate positions for treatment of variables and slots should be
    
+  reconciled, either by finding a compromise or by justifying the apparent
    
+  inconsistency. The final story should explain function references as well.
    
+
    
+Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
    
+
    
+  Define that reading an undefined function or an unbound variable
    
+  must be detected in the highest safety setting,
    
+  but the effect is undefined in any other safety setting. That is,
    
+   - Reading an undefined function should signal an error.
    
+   - Reading an an unbound variable should signal an error.
    
+
    
+  By ``reading an undefined function'' in the above, we mean to 
    
+  include both references to the function using the FUNCTION 
    
+  special form, such as F in (FUNCTION F) and references to the
    
+  function in a call, such as F in (F X).
    
+
    
+  For the case of INLINE functions (in implementations where they are
    
+  supported), it is permissible to consider that performing the inlining
    
+  constitutes the read, so that an FBOUNDP check need not be done at
    
+  execution time. Put another way, the effect of FMAKUNBOUND of a function
    
+  on potentially inlined references to that function is undefined.
    
+
    
+  Specify that the type of error signalled when an undefined function
    
+  is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
    
+  UNDEFINED-FUNCTION condition is initialized to the name of the
    
+  offending function.
    
+
    
+  Specify that the type of error signalled when a unbound variable 
    
+  is detected is UNBOUND-VARIABLE, and that the NAME slot of the
    
+  UNBOUND-VARIABLE condition is initialized to the name of the
    
+  offending variable.
    
+
    
+  Introduce a new condition type, UNBOUND-SLOT, which inherits from
    
+  CELL-ERROR. This new type has an additional slot, INSTANCE, which
    
+  can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
    
+  Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
    
+
    
+  Specify that the type of error signalled by the default primary
    
+  method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
    
+  and that the NAME slot of the UNBOUND-SLOT condition is initialized
    
+  to the name of the offending variable, and that the INSTANCE slot
    
+  of the UNBOUND-SLOT condition is initialized to the offending instance.
    
+
    
+Test Case:
    
+
    
+  (PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
    
+  (DEFUN FOO () X)
    
+  (FOO)
    
+  >>Error: The variable X is not bound.
    
+  ...
    
+
    
+Rationale:
    
+
    
+  This makes it easier to treat slots like variables.
    
+
    
+  This makes it possible to better rely on an unbound variable error being
    
+  signalled when one has occurred.
    
+
    
+  This makes it possible to compile out useless error checking in CLOS
    
+  code where the code is debugged and the checking is redundant.
    
+
    
+  For the case of undefined functions, blindly jumping to an undefined
    
+  function is an incredibly dangerous thing to do. Every implementation
    
+  should guarantee at least some way to get error checking of undefined
    
+  functions.
    
+
    
+Current Practice:
    
+
    
+  Until recently, Symbolics Cloe did not ever signal an error on unbound
    
+  variable, even in the safest case. The excuse was that this was a CLtL
    
+  didn't require it, but it was sometimes an impediment to debugging.
    
+
    
+  Some benchmarks for Symbolics Cloe (which currently only claims to
    
+  implement New Flavors, not CLOS) could be faster if checking for unbound
    
+  instance variables could be optimized away.
    
+
    
+  Symbolics Genera doesn't care about safety issues in variable access
    
+  because the check can be done by microcode.
    
+
    
+Cost to Implementors:
    
+
    
+  This change does not force a change to any current implementation, except
    
+  those which do not yet signal unbound variable or undefined function errors
    
+  even in the safest setting.
    
+
    
+Cost to Users:
    
+
    
+  This checking might slow down some code which is written for the safest
    
+  setting yet does not need this check.
    
+
    
+  Any implementation-specific code which depended on these references not
    
+  signalling would be broken. Such code was not portable, of course.
    
+
    
+  Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
    
+  settings would be broken. The amount of such code at this point is likely
    
+  to be little or none. If such cases did exist, local or global changes to
    
+  safety settings would correct the problem (at some cost in speed).
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Some important error checking would not occur.
    
+  Some important optimizations could not be done.
    
+  The language would seem internally less consistent.
    
+
    
+Benefits:
    
+
    
+  The costs of non-adoption would be avoided.
    
+
    
+Aesthetics:
    
+
    
+  This would regularize things a little.
    
+
    
+Discussion:
    
+
    
+  Pitman thinks this would be a good idea.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355.htm new file mode 100644 index 00000000..48c445fa --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355.htm @@ -0,0 +1,38 @@ + + + +CLHS: Issue UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355_w.htm new file mode 100644 index 00000000..d4102fa2 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss355_w.htm @@ -0,0 +1,171 @@ + + + +CLHS: Issue UNINITIALIZED-ELEMENTS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue UNINITIALIZED-ELEMENTS Writeup

    + +
    Forum:		Public Review
    
+Issue:        UNINITIALIZED-ELEMENTS
    
+Forum:	      CLEANUP
    
+References:   DEFSTRUCT (p308), MAKE-ARRAY (pp287-288)
    
+	      Moon's public review comment #3 (X3J13/92-3203)
    
+	      Issue BOA-AUX-INITIALIZATION
    
+Category:     CLARIFICATION
    
+Edit history: 24-Jun-91, Version 1 by Hornig
    
+	      12-Aug-91, Version 2 by Pitman (flesh out Problem Description
    
+	        and Examples, light editing of other sections, add endorsement)
    
+	      20-Dec-92, Version 3 by Loosemore (update writeup to reflect
    
+		draft 12.24; proposal is unchanged)
    
+	      08-Jan-93, Version 4 by Loosemore (more comments from Moon)
    
+Status:	      Version 2 failed 4-5-1 at Dec 1991 meeting
    
+              Version 4 passed 9-0-0 at Mar 1993 meeting
    
+
    
+
    
+Problem Description:
    
+
    
+ CLtL says of ARRAY element initial values (p287):
    
+
    
+   If the :initial-element option is omitted, the initial 
    
+   values of the array elements are undefined (unless the
    
+   :initial-contents or :displaced-to option is used.)
    
+
    
+   [Similar remarks are made for :initial-contents and
    
+    :displaced-to.]
    
+
    
+ CLtL says of DEFSTRUCT slot initial values (p308):
    
+
    
+   If no default-init is specified, then the initial contents 
    
+   of the slot are undefined and implementation-dependent.
    
+
    
+ From this wording, the draft specification (12.24) has chosen to say that
    
+ uninitialized array elements have an "implementation-dependent value", 
    
+ but that "the consequences are undefined" if an attempt is made to read 
    
+ an uninitialized structure slot.  
    
+
    
+ Aside from the inconsistency being a source of confusion, the language
    
+ in the array section would seem to prevent implementations from
    
+ diagnosing references to uninitialized array slots in high-safety code,
    
+ something that would be very helpful in debugging.
    
+
    
+
    
+Proposal UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED:
    
+
    
+ Specify that the consequences of reading an uninitialized array
    
+ element or structure slot are undefined.
    
+
    
+Test Case:
    
+
    
+ #1: (LENGTH (LIST (AREF (MAKE-ARRAY 1) 0)))
    
+
    
+     returned 1 under CLtL and draft 12.24
    
+     but has undefined consequences under this proposal.
    
+     
    
+
    
+ #2: (DEFSTRUCT (KONS (:CONC-NAME "") (:CONSTRUCTOR KONS)) KAR KDR)
    
+     (LENGTH (LIST (KAR (KONS))))
    
+
    
+     returned 1 under CLtL 
    
+     but has undefined consequences under draft 12.24 and this proposal.
    
+
    
+Rationale:
    
+
    
+ This change will permit, but not require, an implementation to detect
    
+ reading of uninitialized values.  Reading an uninitialized value usually
    
+ indicates a programming error.  Implementations which wish to ease
    
+ debugging may detect this error and report it to the user.
    
+
    
+ Implementations are already required to detect references to
    
+ uninitialized symbol value and function cells in high safety mode,
    
+ and to uninitialized slots in objects of types STANDARD-OBJECT 
    
+ and CONDITION in all safety modes.
    
+
    
+Current Practice:
    
+
    
+ Symbolics currently initializes uninitialized array elements to a
    
+ type-dependent value.  Symbolics currently detects references to
    
+ uninitialized structure slots and calls the SLOT-UNBOUND generic
    
+ function.
    
+
    
+Cost to Implementors:
    
+
    
+ None.
    
+
    
+Cost to Users:
    
+
    
+ This change might affect user programs which read uninitialized slots
    
+ but then do absolutely nothing with the value (such as those in the
    
+ Examples section).  In pracitce, there probably aren't a lot of
    
+ programs with that property.
    
+
    
+Cost of Non-Adoption:
    
+
    
+ Users will not be able to detect this important class of programming
    
+ errors reliably.
    
+
    
+Benefits:
    
+
    
+ High-safety implementations may continue to detect these problems.
    
+
    
+Aesthetics:
    
+
    
+ Most people think it is unaesthetic to read a value which has not been
    
+ initialized.
    
+
    
+ Some people think it is unaesthetic to have the language initialize 
    
+ things to unspecified values.
    
+
    
+Editorial impact:
    
+
    
+ The sections of text affected by this proposal are already flagged
    
+ in the TeX sources for the draft.
    
+
    
+Discussion:
    
+
    
+ Hornig, Pitman, Moon, and Loosemore have expressed support for some
    
+ version of this proposal.
    
+
    
+ Version 2 of this proposal failed by a narrow margin at the December 
    
+ 1991 meeting, but the same issue was raised again by Moon's public review
    
+ comment #3.
    
+
    
+ According to Kent Pitman, the current inconsistency arose because some 
    
+ people were concerned that "implementations might have to blow out in
    
+ the printer when someone did (MAKE-ARRAY 4)".  But various people wanted 
    
+ reading uninitialized structure slots to have undefined consequences 
    
+ because "the presence of CLOS and STRUCTURE-CLASS and SLOT-UNBOUND
    
+ implies that it is reasonable for an implementation to call SLOT-UNBOUND
    
+ and for SLOT-UNBOUND to signal an error when such a slot is accessed".
    
+
    
+ Moon says:
    
+  I don't see anything in the standard that requires the printer to
    
+  "blow out" when printing an object for which there are applicable
    
+  functions that have undefined consequences.  After all, the printer is
    
+  not (required to be) a portable program and is not required to call
    
+  any particular functions (except for PRINT-OBJECT on instances of
    
+  user-defined classes).
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356.htm new file mode 100644 index 00000000..0581509a --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356_w.htm new file mode 100644 index 00000000..eff62d45 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss356_w.htm @@ -0,0 +1,127 @@ + + + +CLHS: Issue UNREAD-CHAR-AFTER-PEEK-CHAR Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue UNREAD-CHAR-AFTER-PEEK-CHAR Writeup

    + +
    Issue:         UNREAD-CHAR-AFTER-PEEK-CHAR
    
+
    
+References:    pp 379, 380 of CLtL
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
    
+               Version 2 by Masinter  2-Dec-88
    
+
    
+Problem description:
    
+
    
+PEEK-CHAR and UNREAD-CHAR are very similar mechanisms.  The description of
    
+PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
    
+then UNREAD-CHAR in succession."  But while CLtL prohibits calling UNREAD-CHAR
    
+twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
    
+The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
    
+will not work unless this prohibition is present.
    
+
    
+Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): 
    
+
    
+   Rewrite the specification so that it is clear that doing either a
    
+   PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
    
+   on any character preceding that which is seen by the PEEK-CHAR (including
    
+   those passed over by PEEK-CHAR when `seeking' with a non-NIL first
    
+   argument) is not specified.
    
+
    
+   In particular, the results of calling  UNREAD-CHAR after PEEK-CHAR
    
+   is unspecified.
    
+
    
+Example:
    
+
    
+   (defun test (&optional (stream *standard-input*))
    
+     (let* ((char1a (read-char stream))	
    
+	    (char2a (peek-char nil stream))
    
+	    (char1b (progn (unread-char char1a stream)
    
+			   (read-char stream)))
    
+	    (char2b (read-char stream)))
    
+       (list char1a char2a char1b char2b)))
    
+
    
+
    
+This is not legal, since the PEEK-CHAR for char2a "commits"
    
+the character read by char1a, and so the unread-char is not legal.
    
+
    
+Rationale:
    
+
    
+PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
    
+reasonable for an implementation to implement them in terms of the same
    
+mechanism.
    
+
    
+Current practice:
    
+
    
+In Xerox Common Lisp, different (non-random-access) stream types behave
    
+differently. One, (TCP/FTP) handled this correctly, while another did not.
    
+
    
+In Symbolics Genera, for the Example above:
    
+
    
+     (test)ab
    
+     => (#\a #\b #\a #\b)
    
+
    
+     (with-input-from-string (s "abc") (test s))
    
+     => (#\a #\b #\a #\b)
    
+
    
+     (progn (with-open-file (s "foo.output" :direction :output)
    
+	      (write-string "abc" s))
    
+            (with-open-file (s "foo.output" :direction :input) 
    
+	      (test s)))
    
+     Signals an error about unreading #\a when #\b was already unread.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Presumably none.  Implementations which allow this are still correct.
    
+
    
+Cost to Users:
    
+
    
+Small.  I suspect there is very little code which depends upon this working
    
+correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
    
+
    
+Cost of non-adoption:
    
+
    
+Implementations of sequential streams are forced to be unnecessarily complex in
    
+order to be correct.
    
+
    
+Benefits:
    
+
    
+Allows simple yet adequately powerful implementation of sequential streams.
    
+
    
+Esthetics:
    
+
    
+Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
    
+PEEK-CHAR work, rather than two separate one-char buffers.
    
+
    
+Discussion:
    
+
    
+<none>
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357.htm new file mode 100644 index 00000000..80d412e9 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357_w.htm new file mode 100644 index 00000000..37aa8a18 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss357_w.htm @@ -0,0 +1,95 @@ + + + +CLHS: Issue UNSOLICITED-MESSAGES Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue UNSOLICITED-MESSAGES Writeup

    + +
    Issue:        UNSOLICITED-MESSAGES
    
+References:   Chapter 1, Section 1.5, Working draft of standard
    
+Category:     Clarification
    
+Edit history: 8-JAN-89, Version 1 by Masinter
    
+	      6-FEB-89, Version 2 by Chapman
    
+	      10-MAR-89, Version 3 by Chapman (added discussion)
    
+	      21-MAR-89, Version 4 by Chapman 
    
+	      24-MAR-89, Version 5 by Chapman 
    
+	      6-APR-89, Version 6 by Chapman (added amendment from 3/89 mtg)
    
+ 
    
+ 
    
+ 
    
+Problem: Is it legal for an implementation to produce unsolicited output,
    
+e.g., GC notifications, autoload heralds, and progress messages from
    
+COMPILE-FILE or LOAD?
    
+ 
    
+Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
    
+ 
    
+No output may be produced
    
+by functions other than that specified in the standard or due to the
    
+signalling of conditions detected by the function.
    
+ 
    
+ 
    
+Unsolicited output, such as GC notifications and autoload heralds,
    
+should not go directly to the stream held by any
    
+Common Lisp stream variable but can go indirectly to
    
+*TERMINAL-IO* by using a synonym stream to that variable.
    
+ 
    
+Output such as progress reports from LOAD and COMPILE are "solicited",
    
+and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
    
+ 
    
+ 
    
+ 
    
+Rationale:
    
+ 
    
+The intent of the proposal is stated informally as follows:
    
+if a file is written to, no implementation-generated output should
    
+end up in the file except as stated above.
    
+ 
    
+The intent of paragraph 2 of the proposal is that 
    
+implementations are forced to make such streams possible to
    
+redirect without redirecting the Common Lisp stream itself.
    
+ 
    
+Current Practice:
    
+ 
    
+Adoption Cost:
    
+ 
    
+Small. Implementations and their documentation may have to change slightly.
    
+ 
    
+Benefits:
    
+ 
    
+Portability.
    
+This proposal has very little impact on implementations, but helps the
    
+user by explicitly stating the disposition of unsolicited output.
    
+ 
    
+Conversion Cost:
    
+ 
    
+See Adoption Cost.
    
+ 
    
+Aesthetics:
    
+ 
    
+None.
    
+ 
    
+Discussion:
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358.htm new file mode 100644 index 00000000..e9dc4e5f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue VARIABLE-LIST-ASYMMETRY:SYMMETRIZE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue VARIABLE-LIST-ASYMMETRY:SYMMETRIZE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue VARIABLE-LIST-ASYMMETRY:SYMMETRIZE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358_w.htm new file mode 100644 index 00000000..6c904046 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss358_w.htm @@ -0,0 +1,121 @@ + + + +CLHS: Issue VARIABLE-LIST-ASYMMETRY Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue VARIABLE-LIST-ASYMMETRY Writeup

    + +
    Issue:          VARIABLE-LIST-ASYMMETRY
    
+References:     CLtL pgs. 110, 122, 131
    
+Category:       ADDITION
    
+Edit history:   26-Jul-88, Version 1 by Skona Brittain
    
+                04-Aug-88, Version 2 by Skona Brittain
    
+                08-Oct-88, Version 3 by Pitman
    
+
    
+Problem Description:
    
+
    
+ The syntax of items in the variable-list for various control structues
    
+ (do, do*, let, let*, prog, prog*, and compiler-let) varies.  This
    
+ variation seems unnecessary.
    
+ 
    
+ The allowed variations are indicated in the following chart:
    
+ 
    
+ do & do*:             (var)    (var init)    (var init step)
    
+ prog & prog*:   var   (var)    (var init)       n.a.
    
+ let & let*:     var            (var val)        n.a.
    
+ compiler-let    var            (var value)
    
+ 
    
+ Note that just plain `` var '' is prohibited in do forms
    
+ and that the case of ``(var)'' is prohibited in let forms
    
+ and compiler-let forms.
    
+
    
+Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
    
+
    
+ Allow all the variations in all of the forms;
    
+ i.e. add the prohibited cases mentioned above.
    
+ 
    
+ I.e. change the variable-list in the syntax descriptions as follows:
    
+
    
+  do & do*:     ( { var | (var [init [step]] ) }* )
    
+  let & let*:   ( { var | (var [value]       ) }* )
    
+  compiler-let: ( { var | (var [value]       ) }* )
    
+
    
+Test Cases:
    
+
    
+ (let          (a (b) (c 3)) ... )  would be valid.
    
+ (let*         (a (b) (c 3)) ... )  would be valid.
    
+ (do           (a (b) (c 3)) ... )  would be valid.
    
+ (do*          (a (b) (c 3)) ... )  would be valid.
    
+ (compiler-let (a (b) (c 3)) ... )  would be valid.
    
+
    
+Rationale:
    
+
    
+ The asymmetry is unnecessary and impedes learning of CL.
    
+ 
    
+ Any other way to make these cases consistent, such as either
    
+ omitting just ``var'' from do & do* and prog & prog*, or
    
+ omitting ``(var)'' from let & let* and prog & prog*, 
    
+ would be an incompatible change to the language.  
    
+ This way just adds the flexibility found in some of the forms to all of them.
    
+
    
+Current Practice:
    
+
    
+ KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
    
+ 
    
+ Symbolics Genera allows all three cases in all the forms; i.e. it conforms
    
+ to this proposal.
    
+
    
+Cost to Implementors:
    
+
    
+ Extremely slight. (May involve subtracting code rather than adding it).
    
+
    
+Cost to Users:
    
+
    
+ None.
    
+
    
+Cost of Non-Adoption:
    
+
    
+ The variation in syntax makes them harder to learn.
    
+
    
+Benefits:
    
+
    
+ Ease of learning.
    
+
    
+Aesthetics:
    
+
    
+ Symmetry is more aesthetic than asymmetry, at least to some of us.
    
+
    
+Discussion: 
    
+
    
+ Pitman supports this proposal.
    
+
    
+ The issue about whether the atomic ``var'' should be allowed at all in the 
    
+ variable lists for let & let* is a separate issue.  (So is whether
    
+ it should mean that the var is initially bound to nil.)  Since it is allowed, 
    
+ this proposal merely says that the alternative syntax of an atom within a 
    
+ list with no initial value, ``(var)'', should also be allowed.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359.htm new file mode 100644 index 00000000..4a81d031 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359.htm @@ -0,0 +1,45 @@ + + + +CLHS: Issue WITH-ADDED-METHODS:DELETE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-ADDED-METHODS:DELETE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue WITH-ADDED-METHODS:DELETE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359_w.htm new file mode 100644 index 00000000..1977101b --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss359_w.htm @@ -0,0 +1,89 @@ + + + +CLHS: Issue WITH-ADDED-METHODS Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-ADDED-METHODS Writeup

    + +
    Issue:         WITH-ADDED-METHODS
    
+
    
+References:    88-002R p.2-90
    
+
    
+Category:      CHANGE
    
+
    
+Edit history:  29-Apr-90, Version 1 by Moon
    
+               4-May-90, Version 2 by Moon (update discussion)
    
+
    
+Problem description:
    
+
    
+  WITH-ADDED-METHODS has a strange definition that is hard to understand
    
+  and apparently is not what was intended by the person who originally
    
+  proposed the feature.  No CLOS implementation is known that supports it.
    
+
    
+  This is Symbolics issue #17.
    
+
    
+Proposal (WITH-ADDED-METHODS:DELETE):
    
+
    
+  Remove WITH-ADDED-METHODS from the language and remove that symbol from
    
+  the COMMON-LISP package.
    
+
    
+Rationale:
    
+
    
+  Why add something new that no one uses or wants?
    
+
    
+Current practice:
    
+
    
+  No CLOS implementation is known to support WITH-ADDED-METHODS.
    
+
    
+Cost to Implementors:
    
+
    
+  Trivial.
    
+
    
+Cost to Users:
    
+
    
+  None.
    
+
    
+Cost of non-adoption:
    
+
    
+  We would either have to get the implementors to implement it or explain
    
+  why we put this thing in the language that everyone refuses to implement.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Smaller language.
    
+
    
+Esthetics:
    
+
    
+  Smaller language.
    
+
    
+Discussion:
    
+
    
+  Gregor Kiczales says he supports WITH-ADDED-METHODS:DELETE.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360.htm new file mode 100644 index 00000000..7a8c5810 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue WITH-COMPILATION-UNIT:NEW-MACRO Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-COMPILATION-UNIT:NEW-MACRO Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue WITH-COMPILATION-UNIT:NEW-MACRO:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360_w.htm new file mode 100644 index 00000000..65da1e71 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss360_w.htm @@ -0,0 +1,177 @@ + + + +CLHS: Issue WITH-COMPILATION-UNIT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-COMPILATION-UNIT Writeup

    + +
    Forum:	      Compiler
    
+Issue:        WITH-COMPILATION-UNIT
    
+References:   COMPILE (p438), COMPILE-FILE (p439)
    
+Category:     ADDITION
    
+Edit history: 29-Sep-88, Version 1 by Pitman
    
+	      10-Mar-89, Version 2 by Pitman (merge comments)
    
+	      13-Mar-89, Version 3 by Loosemore (update discussion)
    
+	      10-Apr-89, Version 4 by Pitman (wording change per X3J13)
    
+Status:	      Ready for release
    
+
    
+Problem Description:
    
+
    
+  Some actions done by the compiler (and particularly the file compiler)
    
+  are typically deferred until the "very end" of compilation.  For example,
    
+  some compilers complain about "functions seen but not defined".
    
+
    
+  Unfortunately, since COMPILE-FILE is the largest unit of granularity,
    
+  and since systems often extend over more than one file, it often happens
    
+  that the compiler needlessly complains at the end of compiling one file
    
+  about the absence of functions defined in the next file. 
    
+
    
+Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):
    
+
    
+  Add the following new macro:
    
+
    
+   WITH-COMPILATION-UNIT options &BODY forms			[Macro]
    
+
    
+   Executes forms from left to right. Within the dynamic context
    
+   of this form, warnings deferred by the compiler until "the end of
    
+   compilation" will be deferred until the end of the outermost call
    
+   to WITH-COMPILATION-UNIT. The result(s) are the same as that of
    
+   the last of the FORMS (or NIL if FORMS is null).
    
+
    
+   OPTIONS is a keyword/value list, where only the values are
    
+   evaluated. The set of keywords permitted may be extended by the
    
+   implementation, but the only keyword defined by this standard is:
    
+
    
+     :OVERRIDE boolean
    
+
    
+       The default is NIL. If nested dynamically only the outer call
    
+       to WITH-COMPILATION-UNIT has any effect unless BOOLEAN is T,
    
+       in which case warnings are deferred only to the end of the
    
+       innermost call.
    
+
    
+  It follows that the functions COMPILE and COMPILE-FILE should
    
+  provide the effect of (WITH-COMPILATION-UNIT (:OVERRIDE NIL) ...)
    
+  around their code.
    
+
    
+  Any implementation-dependent extensions may only be provided
    
+  as the result of an explicit programmer request by use of 
    
+  an implementation-dependent keyword.  Implementations are forbidden
    
+  from attaching additional meaning to a conforming use of this
    
+  macro.
    
+
    
+  Note also that not all warnings are deferred. In some implementations,
    
+  it may be that none are deferred. This proposal only creates an
    
+  interface to the capability where it exists, it does not require the
    
+  creation of the capability. An implementation which does not do 
    
+  deferred warnings may correctly implement this as expanding into PROGN.
    
+
    
+Test Case:
    
+
    
+  (DEFUN COMPILE-FILES (&REST FILES)
    
+    (WITH-COMPILATION-UNIT ()
    
+      (MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))
    
+
    
+  (COMPILE-FILES "A" "B" "C")
    
+
    
+  processes deferred warnings only after compiling all of A, B, and C.
    
+
    
+Rationale:
    
+
    
+  This will make the development of portable system-construction tools
    
+  considerably more convenient. 
    
+
    
+Current Practice:
    
+
    
+  Lucid has a very similar facility, called WITH-DEFERRED-WARNINGS.
    
+
    
+  TI Explorer and Symbolics Genera have a similar facility, which they
    
+  call COMPILER-WARNING-CONTEXT-BIND.
    
+
    
+Cost to Implementors:
    
+
    
+  In implementations which have no deferred warnings, there is no cost.
    
+  
    
+  In implementations which have deferred warnings, the cost is probably
    
+  fairly small -- usually just a matter of writing interfacing the 
    
+  proposed macro to an existing one.
    
+
    
+Cost to Users:
    
+
    
+  None. This is a compatible addition.
    
+
    
+Cost of Non-Adoption:
    
+
    
+  Portable system-construction tools would continue to print lots of
    
+  spurious warnings because they would have no way to tell the system
    
+  that a set of files was working together.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Aesthetics:
    
+
    
+  The ability to create a compilation unit other than a file is important.
    
+
    
+Discussion:
    
+
    
+  Pitman and Benson support this addition.
    
+
    
+  One could imagine adding more options at a later date.
    
+
    
+  It was the opinion of the compiler committee that there was room for
    
+  expansion here to address issues like bounding the scope of global
    
+  proclamations, sharing compile-time environments across files, etc.
    
+  However, insufficient work was done on this to justify putting such
    
+  a thing into the standard. The only clear need we have at this time
    
+  was to defer warnings, but we chose a general name like 
    
+  WITH-COMPILATION-UNIT rather than a specific name like Lucid's
    
+  WITH-DEFERRED-WARNINGS in order to encourage implementations to 
    
+  experiment with other kinds of options under implementation-specific
    
+  keywords. Perhaps by the time of the next standard there will be
    
+  sufficient understanding of this area to warrant further elaboration
    
+  of this primitive.
    
+
    
+  Kim Barrett says:
    
+
    
+    I strongly oppose the behavior you proposed for compile and
    
+    compile-file.  It is my belief that whether to override or not must be
    
+    controlled through an argument to the compile functions, with the
    
+    default being to override.  Otherwise, all existing code which makes
    
+    use of the compile functions must be modified to protect itself by
    
+    wrapping a (with-compilation-unit (:override t) ...) around the calls
    
+    to the compiler.
    
+    
    
+    Consider a stream system built on an object system which will compose
    
+    and compile functions on the fly on an as needed basis.  It would be
    
+    very strange for the functions so generated while doing file io for
    
+    the user's compile-file to have any relationship with said
    
+    compile-file.
    
+    
    
+    I agree with your position that implementation-dependent extensions
    
+    must be explicitly requested.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361.htm new file mode 100644 index 00000000..24037a3f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361_w.htm new file mode 100644 index 00000000..32e57ca4 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss361_w.htm @@ -0,0 +1,125 @@ + + + +CLHS: Issue WITH-OPEN-FILE-DOES-NOT-EXIST Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-OPEN-FILE-DOES-NOT-EXIST Writeup

    + +
    Status: Proposal STREAM-IS-NIL passed, Jun 89 X3J13
    
+
    
+Issue:         WITH-OPEN-FILE-DOES-NOT-EXIST
    
+References:    CLtL page 422
    
+Category:      Clarify
    
+Edit history:  17-Mar-89, Version 1
    
+
    
+Problem description:
    
+The documentation for WITH-OPEN-FILE (p 422) says:
    
+  "WITH-OPEN-FILE evaluates the Forms of the body (an implict PROGN)
    
+with the variable Stream bound to a stream that reads or writes the
    
+file named by the value of Filename. The options are evaluated and
    
+used as keyword arguments to the function OPEN."
    
+
    
+  It is not clear what to do when there is no stream
    
+"that reads or writes the file" named by Filename.
    
+  Is the body evaluated? What is Stream bound to?
    
+
    
+Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:DONT-EVALUATE
    
+  If the result of OPEN does not return a stream (eg returns NIL)
    
+Then the body of WITH-OPEN-FILE is not evaluated, NIL is returned.
    
+
    
+Rationale:
    
+  The contract that "the body is evaluated with ... bound to a stream"
    
+is maintained in the sense of a vacuous evalation.
    
+  The alternatives are:
    
+    To let the stream variable be bound to NIL (unintuitive and dangerous).
    
+    If users want to Signal-An-Error in this case, they can use
    
+    :if-does-not-exist :error  
    
+  The test for (STREAMP Stream) is probably done anyway,
    
+    since the UNWIND-PROTECT cleanup form can't call CLOSE on NIL.
    
+
    
+Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL
    
+  Clarify the documentation to explain that:
    
+    Stream is bound to the value returned by OPEN.
    
+    Users of :if-does-not-exist NIL should check for a valid stream.
    
+
    
+Rationale:
    
+  This simple to implement, no extra testing is done.
    
+  Users who use :if-does-not-exist NIL  can wrap their body forms
    
+with (when (STREAMP Stream) ...)
    
+
    
+Examples:
    
+1. (WITH-OPEN-FILE (foo "no-such-file" :IF-DOES-NOT-EXIST nil)
    
+	(READ foo) t)
    
+   DONT-EVALUATE: => NIL, no I/O is done, do not read from *standard-input*
    
+   STREAM-IS-NIL: => T, reads from *standard-input*
    
+
    
+2. (WITH-OPEN-FILE (foo "/no-dir" :direction :output :IF-DOES-NOT-EXIST nil)
    
+	(format foo t) t)
    
+   DONT-EVALUATE: => NIL, no string is created.
    
+   STREAM-IS-NIL: => T, creates a string and writes to it.
    
+
    
+Current practice:
    
+    Symbolics and Lucid apparently implement STREAM-IS-NIL.
    
+
    
+Cost to Implementors:
    
+    STREAM-IS-NIL: no cost.
    
+    DONT-EVALUATE:
    
+        Trivial? to test for :if-does-not-exist NIL and supply a 
    
+        test for (STREAMP Stream) in that case [or in every case].
    
+
    
+Cost to Users:
    
+    DONT-EVALUATE: System tests for (STREAMP Stream), possibly extraneously.
    
+    STREAM-IS-NIL: User must write a test for (STREAMP Stream).
    
+  Probably no portable code uses :if-does-not-exist NIL without
    
+  testing explicitly for (STREAMP Stream).
    
+
    
+Cost of non-adoption:
    
+    The current situation is non-intuitive and/or confusing.
    
+
    
+Benefits:
    
+    Users would know if the STREAMP test has been done or whether 
    
+they must supply it.
    
+
    
+Esthetics:
    
+
    
+Discussion:
    
+
    
+
    
+ 
    
+GV-Info: CL-Cleanup-mailer@SAIL.Stanford.EDU at 21-Mar-89 16:03:29 from AG
    
+Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
    
+Redistributed: xerox-cl-cleanup^.pa
    
+Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 21 MAR 89 16:03:30 PST
    
+Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  16:01:17 PST
    
+Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562394; Tue 21-Mar-89 18:59:52 EST
    
+Date: Tue, 21 Mar 89 18:59 EST
    
+From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
+Message-ID: <19890321235935.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
    
+
    
+I think WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL is clearly correct,
    
+although I agree that CLtL doesn't really say.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362.htm new file mode 100644 index 00000000..6b8d8105 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362_w.htm new file mode 100644 index 00000000..61833587 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss362_w.htm @@ -0,0 +1,120 @@ + + + +CLHS: Issue WITH-OPEN-FILE-SETQ Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-OPEN-FILE-SETQ Writeup

    + +
    Issue:           WITH-OPEN-FILE-SETQ
    
+References:      WITH-OPEN-FILE
    
+                 WITH-OPEN-STREAM
    
+                 WITH-INPUT-FROM-STRING
    
+                 WITH-OUTPUT-TO-STRING
    
+Related issues:  WITH-OPEN-FILE-STREAM-EXTENT
    
+Category:        CLARIFICATION
    
+Edit history:    v1, 13 Feb 1991, Sandra Loosemore
    
+                 v2, 11 Mar 1991, Sandra Loosemore
    
+
    
+Problem description:
    
+
    
+  It isn't clear whether it is permissible for the variable bound to
    
+  a stream by WITH-OPEN-FILE, WITH-OPEN-STREAM, WITH-INPUT-FROM-STRING,
    
+  or WITH-OUTPUT-TO-STRING may be explicitly assigned to within the body.
    
+  The expansion of these macros must include some code to close the stream
    
+  after executing the body forms.  Can this code refer to the stream
    
+  using the user-supplied variable, or must it use another "hidden"
    
+  variable in case the user-supplied variable has been assigned to in
    
+  the body forms?
    
+
    
+Proposal (WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE):
    
+
    
+  Clarify that the consequences of altering the values of the variables 
    
+  bound to streams by WITH-OPEN-STREAM, WITH-INPUT-FROM-STREAM,
    
+  WITH-OUTPUT-TO-STREAM, and WITH-OPEN-FILE (by using SETQ, for example)
    
+  are undefined.  A Common Lisp compiler may choose to issue a warning
    
+  if such a variable appears in a SETQ.
    
+
    
+Rationale:
    
+
    
+  This is consistent with what CLtL says about altering the value of
    
+  the counter variable in a DOTIMES form.
    
+
    
+Current Practice:
    
+
    
+  Lucid CL, Allegro CL, the Chestnut Lisp-to-C translator, and Symbolics
    
+  Common Lisp all implement WITH-OPEN-FILE in such a way that the 
    
+  user-supplied variable is referenced to close the stream.
    
+
    
+Cost to Implementors:
    
+
    
+  None, since this permits implementations to continue to use the
    
+  "obvious" expansion.
    
+
    
+Cost to Users:
    
+
    
+  Probably none.  Any user programs that depend on it working the other
    
+  way are already clearly not portable.
    
+
    
+Cost of non-adoption:
    
+
    
+  The language specification will be vague.  Users may have portability
    
+  problems.
    
+
    
+Performance impact:
    
+
    
+  Negligible.
    
+
    
+Benefits:
    
+
    
+  Users will know what to expect and will avoid a portability pitfall.
    
+
    
+Esthetics:
    
+
    
+  Doesn't look too bad.
    
+
    
+Discussion:
    
+
    
+  Kent Pitman notes:
    
+
    
+    It probably is worth mentioning that the most common abuse of this
    
+    situation I've seen is that sometimes users will create broadcast
    
+    streams, echo streams, etc., or even implementation-dependent
    
+    encapsulations of the indicated stream to the opened file and then set
    
+    it back to the indicated variable.  (Whether the later call to CLOSE
    
+    is a good idea to do to the compound stream which results is something
    
+    that probably varies from implementation to implementation.  This
    
+    proposal certainly makes it more clear that users who do this are
    
+    living on the edge.)
    
+    
    
+    Anyway, I just wanted to emphasize that the only scenario was not
    
+    something bizarre like someone doing
    
+    
    
+     (WITH-OPEN-FILE (TEMP ...)
    
+       (PRINT X STREAM)
    
+       (SETQ X (+ 7 2)) ...)
    
+
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363.htm new file mode 100644 index 00000000..8f607e7f --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363.htm @@ -0,0 +1,39 @@ + + + +CLHS: Issue WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363_w.htm new file mode 100644 index 00000000..4f1b0127 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss363_w.htm @@ -0,0 +1,129 @@ + + + +CLHS: Issue WITH-OPEN-FILE-STREAM-EXTENT Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-OPEN-FILE-STREAM-EXTENT Writeup

    + +
    Issue:           WITH-OPEN-FILE-STREAM-EXTENT
    
+References:      WITH-OPEN-FILE
    
+                 WITH-OPEN-STREAM
    
+                 WITH-INPUT-FROM-STRING
    
+                 WITH-OUTPUT-TO-STRING
    
+Related issues:  WITH-OPEN-FILE-SETQ
    
+Category:        CLARIFICATION
    
+Edit history:    v1, 13 Feb 1991, Sandra Loosemore
    
+                 v2, 11 Mar 1991, Sandra Loosemore (two proposals)
    
+                 v3, 26 Mar 1991, Sandra Loosemore (fix typos)
    
+Status:          v3 (proposal DYNAMIC-EXTENT) accepted by X3J13, Mar 1991
    
+
    
+Problem description:
    
+
    
+  CLtL says that the streams created by WITH-OPEN-STREAM, 
    
+  WITH-INPUT-FROM-STRING, and WITH-OUTPUT-TO-STRING should be regarded
    
+  as having dynamic extent.  It is not clear whether "dynamic extent"
    
+  is being used here in a technical sense to mean that it is valid for
    
+  the expansion of these macros to include a DYNAMIC-EXTENT declaration
    
+  for the variable(s) bound to the stream.
    
+
    
+  The description of WITH-OPEN-FILE says nothing about whether the
    
+  stream it creates has dynamic extent.  It probably should inherit
    
+  whatever restrictions are placed on WITH-OPEN-STREAM, so you can 
    
+  implement it that way.
    
+
    
+  There are two proposals, DYNAMIC-EXTENT and INDEFINITE-EXTENT.
    
+
    
+Proposal (WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT):
    
+
    
+  Clarify that the streams created by WITH-OPEN-STREAM,
    
+  WITH-INPUT-FROM-STRING, WITH-OUTPUT-TO-STRING, and WITH-OPEN-FILE
    
+  have dynamic extent in the technical sense of the DYNAMIC-EXTENT
    
+  declaration.  The extent of the stream ends when the form is exited.
    
+
    
+  Rationale for proposal DYNAMIC-EXTENT:
    
+ 
    
+    If we don't mean the technical definition of DYNAMIC-EXTENT, we
    
+    might as well not say anything about dynamic extent.
    
+
    
+
    
+Proposal (WITH-OPEN-FILE-STREAM-EXTENT:INDEFINITE-EXTENT):
    
+
    
+  Specify that the streams created by WITH-OPEN-STREAM,
    
+  WITH-INPUT-FROM-STRING, WITH-OUTPUT-TO-STRING, and WITH-OPEN-FILE
    
+  have indefinite extent.
    
+
    
+  Rationale for proposal INDEFINITE-EXTENT:
    
+
    
+    It has been suggested that the mention of "dynamic extent" in CLtL
    
+    was really a sloppy way of saying that the stream would be closed
    
+    after the dynamic extent of the body was exited.
    
+
    
+    It is better for the language to take the conservative point of view
    
+    and make objects generally have indefinite extent, leaving it up to
    
+    users to declare which things they want to be more ephemeral.
    
+
    
+
    
+Current Practice:
    
+
    
+  I don't know.
    
+
    
+Cost to Implementors:
    
+
    
+  None (DYNAMIC-EXTENT declarations are optional).
    
+
    
+Cost to Users:
    
+
    
+  Probably small, for either proposal.  It's possible that some people
    
+  do things like:
    
+
    
+    (truename (with-open-file (stream ...) ... stream))
    
+
    
+  but it's not clear that these things are now portable anyway.
    
+
    
+Cost of non-adoption:
    
+
    
+  The language specification will be vague.  Implementations might 
    
+  be prevented from making a minor optimization.  Users may encounter
    
+  portability problems.
    
+
    
+Performance impact:
    
+
    
+  Adoption of proposal DYNAMIC-EXTENT will permit the stream objects 
    
+  to be stack-allocated by default.
    
+
    
+Benefits:
    
+
    
+  The cost of non-adoption is avoided.
    
+
    
+Esthetics:
    
+
    
+  Consistent use of "dynamic extent" terminology is a good thing.
    
+
    
+Discussion:
    
+
    
+  Loosemore thinks either of the two proposals would be an improvement
    
+  over the status quo.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364.htm new file mode 100644 index 00000000..9b6a343c --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364.htm @@ -0,0 +1,36 @@ + + + +CLHS: Issue WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND Summary

    + +This passage is relevant to or affected by X3J13 Cleanup Issue WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364_w.htm new file mode 100644 index 00000000..bbb04d58 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss364_w.htm @@ -0,0 +1,122 @@ + + + +CLHS: Issue WITH-OUTPUT-TO-STRING-APPEND-STYLE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-OUTPUT-TO-STRING-APPEND-STYLE Writeup

    + +
    Issue:         WITH-OUTPUT-TO-STRING-APPEND-STYLE
    
+
    
+References:    CLtL, pages 331, 386
    
+
    
+Category:      CLARIFICATION
    
+
    
+Edit history:  Version 1, 25-Mar-88 JonL
    
+	       Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
    
+	       Version 3, 23-May-88 JonL (fix nits raised by Masinter)
    
+	       Version 4, 23-May-88 JonL (change issue name -- only 1 proposal)
    
+	       Version 5,  7-Jun-88 Masinter (more nits)
    
+
    
+Problem description:
    
+
    
+CLtL p386 says that FORMATting to a fill-pointer'd string should add
    
+characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
    
+WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
    
+string is adjustable, and otherwise as if using VECTOR-PUSH".  It's very
    
+unlikely that the original authors of these parts intended differing
    
+semantics for these two cases.  Furthermore, the semantics for
    
+WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
    
+written to the string, since VECTOR-PUSH will just "drop on the floor"
    
+any characters that would go beyond the end.
    
+
    
+
    
+Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
    
+
    
+Change the documentation of WITH-OUTPUT-TO-STRING to be like that under 
    
+FORMAT.  That is, replace the first sentence of the next-to-last paragraph 
    
+on CLtL p331 by:
    
+  "If *string* is specified, it must be a string with a fill pointer; 
    
+   the output is incrementally appended to the string (as if by use of
    
+   VECTOR-PUSH-EXTEND)."
    
+
    
+
    
+Test Case: 
    
+    (let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
    
+      (with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
    
+      str)
    
+CLtL behaviour will return "You "; proposed behaviour will signal an error.
    
+
    
+
    
+Rationale:
    
+
    
+It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
    
+to suggest that characters could be quietly "dropped on the floor".  In
    
+any case, there is no practical or theoretical reason to make FORMAT and
    
+WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
    
+
    
+
    
+Current Practice:
    
+
    
+VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
    
+versions implement CLtL.  For WITH-OUTPUT-TO-STRING, Xerox Common Lisp 
    
+implements CLtL.  Symbolics Genera 7.2 implements the proposal.
    
+
    
+
    
+Cost to Implementors:
    
+
    
+Very small.
    
+
    
+Cost to Users:
    
+
    
+Virtually none.
    
+
    
+
    
+Benefits:
    
+
    
+Less special-casing in the semantics of "printing" to strings.
    
+More conformity with naive expectations about printing to strings.
    
+
    
+
    
+Aesthetics:
    
+
    
+Minor impact.
    
+
    
+Discussion:
    
+
    
+Implementations may want to actually call VECTOR-PUSH, rather than
    
+VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
    
+result -- nil means an overflow of the total length of the string; 
    
+thus they may signal an error more directly related to the problem,
    
+rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
    
+adjustable array.  But either way, the semantics is still that of
    
+VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable 
    
+strings are extended, and non-adjustable strings cause error signals.
    
+
    
+It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
    
+array.  It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
    
+to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
    
+
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365.htm new file mode 100644 index 00000000..d9513b31 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365.htm @@ -0,0 +1,37 @@ + + + +CLHS: Issue WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91 Summary + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + +

    Issue WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91 Summary

    + +These passages are relevant to or affected by X3J13 Cleanup Issue WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91:

    +

    + + +Note: It is possible that there are other passages affected by this cleanup issue. +This list is not part of the specification, +and has not been formally audited for completeness by X3J13.

    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365_w.htm b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365_w.htm new file mode 100644 index 00000000..31411f54 --- /dev/null +++ b/clones/lisp/HyperSpec-7-0/HyperSpec/Issues/iss365_w.htm @@ -0,0 +1,139 @@ + + + +CLHS: Issue WITH-STANDARD-IO-SYNTAX-READTABLE Writeup + + + + + + + + + + + +

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    + +
    + + + +

    Issue WITH-STANDARD-IO-SYNTAX-READTABLE Writeup

    + +
    Issue:          WITH-STANDARD-IO-SYNTAX-READTABLE
    
+References:     CLtL2 pp.565-6
    
+Related issues: DATA-IO
    
+Category:       CLARIFICATION
    
+Edit history:   Version 1, 29-Nov-90, by Haflich
    
+	        Version 2, 08-Apr-90, by Pitman 
    
+		  (add newly worded proposal from meeting)
    
+Status:   	X3J13 passed option X3J13-MAR-91 on vote of 11-1, March 1991.
    
+
    
+Problem description:
    
+
    
+  Proposal DATA-IO:ADD-SUPPORT passed in June 89 added the new macro
    
+  WITH-STANDARD-IO-SYNTAX which executes a body with all the read/print
    
+  special variables bound to known values.  All the prescribed binding
    
+  values are immutable objects except for *READTABLE*, which is required
    
+  to be bound to "the standard readtable."
    
+
    
+  Not addressed was the question what happens if someone modifies the
    
+  readtable inside the body, or captures the value and modifies it
    
+  later.
    
+
    
+  If "the standard readtable" were the implementation's special copy of
    
+  the initial readtable, modifying this readtable would have the
    
+  unfortunate effect of breaking the defined behaviour of COPY-READTABLE
    
+  as a way of obtaining a fresh copy of the standard readtable.
    
+
    
+  If "the standard readtable" provided by the macroexpansion were a
    
+  single reusable copy of the standard readtable, COPY-READTABLE would
    
+  be safe, but the readtable seen successive calls to expansions of the
    
+  macro would not necessarily be the standard readtable.
    
+
    
+  If "the standard readtable" were a fresh copy of the standard
    
+  readtable obtained from COPY-READTABLE, there would be no surprises,
    
+  but the cost of consing readtables would be a disincentive to using
    
+  WITH-STANDARD-IO-SYNTAX where performance was important.
    
+
    
+  Other implementation strategies could be considered -- for example, a
    
+  readtable could record whether they have ever been modified, and entry
    
+  to WITH-STANDARD-IO-SYNTAX would create a fresh copy only if the
    
+  previously copy had been modified.  But even this wouldn't be safe if
    
+  someone captured the readtable and modified it later after the
    
+  readtable had been reused for a later execution of a
    
+  WITH-STANDARD-IO-SYNTAX expansion.
    
+
    
+Proposal (WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91):
    
+
    
+  Specify that results are undefined if the standard readtable is modified.
    
+
    
+  Clarify that the `standard readtable' (the one copied by COPY-READTABLE
    
+  when it is given a NIL argument, or the one to which *READTABLE* is bound
    
+  by WITH-STANDARD-IO-SYNTAX) must not be the same as the `initial readtable'
    
+  (the one to which *READTABLE* is initially bound when Lisp starts).
    
+
    
+Proposal (WITH-STANDARD-IO-SYNTAX-READTABLE:DISALLOW-MODIFICATION):
    
+
    
+  Specify that results are undefined if the readtable object provided by
    
+  WITH-STANDARD-IO-SYNTAX is modified.
    
+
    
+Rationale:
    
+
    
+  This is ackowledgement of the status quo and makes explicit a
    
+  limitation of WITH-STANDARD-IO-SYNTAX which would not otherwise
    
+  be obvious to users.
    
+
    
+Current practice:
    
+
    
+  It's unclear anyone actually implements WITH-STANDARD-IO-SYNTAX.
    
+  It's even more unclear anyone actually uses it.
    
+  It's highly unlikely anyone has ever yet written code that modifies
    
+  a readtable inside the body.
    
+
    
+  Does Genera's WITH-STANDARD-IO-ENVIRONMENT deal with this issue?
    
+
    
+Cost to Implementors:
    
+
    
+  If ALLOW is adopted there will be some annoying changes required to
    
+  readtable implementation and readtable modifying functions if
    
+  implementors want to avoid ther overhead of copying a new readtable at
    
+  every entry to a WITH-STANDARD-IO-SYNTAX expansion.
    
+
    
+Cost to Users:
    
+
    
+  None, assuming no user has yet violated the restriction.  User code
    
+  that needs to modify a readtable is free to make an explicit copy,
    
+  but no other code needs pay the price.
    
+
    
+Cost of non-adoption:
    
+
    
+  This is only a clarification.  Modifying the readtable inside
    
+  WITH-STANDARD-IO-SYNTAX will continue to have undetermined effects
    
+  anyway.
    
+
    
+Performance impact:
    
+
    
+  None.
    
+
    
+Benefits:
    
+
    
+  Another X3J13-introduced crack in the language is caulked.
    
+
    
+Esthetics:
    
+
    
+  Bill Ackerman told me some twenty years ago: "Lisp would be the
    
+  perfect computer language, except that it has IO."
    
+
    
+Discussion:
    
+
    
+  Haflich recommends adoption.
    
+
    +
    + +[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    + +Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    + + diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Contents.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Contents.htm deleted file mode 100644 index 96b40311..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Contents.htm +++ /dev/null @@ -1,67 +0,0 @@ - - - -CLHS: Chapter Index - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - -

    Chapter Index

    - -
      -
    1. Introduction
      -
    2. Syntax
      -
    3. Evaluation and Compilation
      -
    4. Types and Classes
      -
    5. Data and Control Flow
      -
    6. Iteration
      -
    7. Objects
      -
    8. Structures
      -
    9. Conditions
      -
    10. Symbols
      -
    11. Packages
      -
    12. Numbers
      -
    13. Characters
      -
    14. Conses
      -
    15. Arrays
      -
    16. Strings
      -
    17. Sequences
      -
    18. Hash Tables
      -
    19. Filenames
      -
    20. Files
      -
    21. Streams
      -
    22. Printer
      -
    23. Reader
      -
    24. System Construction
      -
    25. Environment
      -
    26. Glossary
      -
    - - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Hilights.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Hilights.htm deleted file mode 100644 index 28c3e124..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/Hilights.htm +++ /dev/null @@ -1,124 +0,0 @@ - - - -CLHS: Selected Highlights - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -

    Selected Highlights

    - -Here are some selected points of interest within the document. -This is not a complete table of contents and in fact does not -even follow the chapter structuring; if you want to follow the normal chapter -arrangement, use the chapter index.

    - -

    - -In addition to the specification itself, this document is cross-referenced with the X3J13 design documents used to produce it. - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoNext.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoNext.htm deleted file mode 100644 index 282d2627..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoNext.htm +++ /dev/null @@ -1,32 +0,0 @@ - - - -CLHS: No Next Page - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - -

    What did you expect?

    - -You have fallen off the end.

    - -[No Next] This icon meant there was no next page.

    - - -

    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoPrev.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoPrev.htm deleted file mode 100644 index 8281bc78..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/NoPrev.htm +++ /dev/null @@ -1,31 +0,0 @@ - - - -CLHS: No Prev Page - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - -

    What did you expect?

    - -You have fallen off the end.

    - -[No Previous] This icon meant there was no previous page.

    - -

    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/StartPts.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/StartPts.htm deleted file mode 100644 index dcdcb31b..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/StartPts.htm +++ /dev/null @@ -1,37 +0,0 @@ - - - -CLHS: Starting Points - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - -
      -[Highlights] Selected Highlights
      -[Contents] Chapter Index
      -[Index] Master Index
      -[Symbols] Symbol Index
      -[Glossary] Glossary
      -[Issues] X3J13 Issue Index
      -[Help] Help, Legalese, Trivia, etc.
      -
    - - -
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm deleted file mode 100644 index fa3df16e..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm +++ /dev/null @@ -1,47 +0,0 @@ - - - -CLHS: X3J13 Issues - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - -

    X3J13 Issues

    - -X3J13 made several hundred of its decisions in modular fashion through -symbolically named ``issues,'' each composed of an abstract problem description -and one or more possible resolutions for vote.

    - -These issue writeups, while not part of the Common Lisp specification, -are nevertheless useful for understanding original intent. As such, they -are cross-referenced throughout this document. However, even in the case -of an erroneously transcribed or applied decision, text in the specification -always takes precedence over text of an issue writeup.

    - -Cross-referencing occurs in two ways: At the bottom of each affected page is a -pointer to any relevant issues. Further, associated with each issue is a -table of affected pages.

    - -

    - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_AllSym.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_AllSym.htm deleted file mode 100644 index 07d27a92..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_AllSym.htm +++ /dev/null @@ -1,1008 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (Full) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - - -

    Symbol Index

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_9.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_9.htm deleted file mode 100644 index 34a6bb8e..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_9.htm +++ /dev/null @@ -1,99 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (Non-Alphabetic) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (Non-Alphabetic)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_A.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_A.htm deleted file mode 100644 index b1b11efa..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_A.htm +++ /dev/null @@ -1,74 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (A) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (A)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_B.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_B.htm deleted file mode 100644 index 376aed24..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_B.htm +++ /dev/null @@ -1,75 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (B) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (B)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_C.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_C.htm deleted file mode 100644 index a73b7fc5..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_C.htm +++ /dev/null @@ -1,141 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (C) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (C)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_D.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_D.htm deleted file mode 100644 index 94b1ff4b..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_D.htm +++ /dev/null @@ -1,85 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (D) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (D)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_E.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_E.htm deleted file mode 100644 index 1077af18..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_E.htm +++ /dev/null @@ -1,56 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (E) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (E)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_F.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_F.htm deleted file mode 100644 index fd14c5f1..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_F.htm +++ /dev/null @@ -1,83 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (F) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (F)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_G.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_G.htm deleted file mode 100644 index 5853c7b5..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_G.htm +++ /dev/null @@ -1,47 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (G) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (G)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_H.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_H.htm deleted file mode 100644 index 94f2835e..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_H.htm +++ /dev/null @@ -1,39 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (H) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (H)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_I.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_I.htm deleted file mode 100644 index 0ca8fb00..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_I.htm +++ /dev/null @@ -1,55 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (I) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (I)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_K.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_K.htm deleted file mode 100644 index 3b2521ed..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_K.htm +++ /dev/null @@ -1,31 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (K) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (K)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_L.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_L.htm deleted file mode 100644 index ed6ae940..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_L.htm +++ /dev/null @@ -1,93 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (L) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (L)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_M.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_M.htm deleted file mode 100644 index 59250aec..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_M.htm +++ /dev/null @@ -1,101 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (M) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (M)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_N.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_N.htm deleted file mode 100644 index 4390f448..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_N.htm +++ /dev/null @@ -1,65 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (N) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (N)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_O.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_O.htm deleted file mode 100644 index 3b0016ff..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_O.htm +++ /dev/null @@ -1,36 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (O) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (O)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_P.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_P.htm deleted file mode 100644 index 23d11e50..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_P.htm +++ /dev/null @@ -1,93 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (P) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (P)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Q.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Q.htm deleted file mode 100644 index ba32c18d..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Q.htm +++ /dev/null @@ -1,30 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (Q) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (Q)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_R.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_R.htm deleted file mode 100644 index 6177a0ab..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_R.htm +++ /dev/null @@ -1,85 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (R) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (R)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_S.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_S.htm deleted file mode 100644 index 0a8f5cc6..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_S.htm +++ /dev/null @@ -1,159 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (S) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (S)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_T.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_T.htm deleted file mode 100644 index eb7aeb03..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_T.htm +++ /dev/null @@ -1,56 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (T) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (T)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_U.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_U.htm deleted file mode 100644 index 90720932..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_U.htm +++ /dev/null @@ -1,50 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (U) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (U)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_V.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_V.htm deleted file mode 100644 index 024ada4b..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_V.htm +++ /dev/null @@ -1,37 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (V) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (V)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_W.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_W.htm deleted file mode 100644 index 78d26b09..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_W.htm +++ /dev/null @@ -1,52 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (W) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (W)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Y.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Y.htm deleted file mode 100644 index c237af45..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Y.htm +++ /dev/null @@ -1,31 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (Y) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (Y)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Z.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Z.htm deleted file mode 100644 index 650b139d..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Alph_Z.htm +++ /dev/null @@ -1,30 +0,0 @@ - - - -CLHS: Alphabetical Symbol Index (Z) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Alphabetical Symbol Index (Z)

    - - -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_9.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_9.htm deleted file mode 100644 index 7976cf8c..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_9.htm +++ /dev/null @@ -1,1274 +0,0 @@ - - - -CLHS: Index - Non-Alphabetic - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - Non-Alphabetic

    - -
    -Newline (format directive)
-  Tilde Newline: Ignored Newline
-" (reader macro)
-  Double-Quote
-#
-  Sharpsign
-# (reader macro)
-  Sharpsign
-# (sharpsign reader macro)
-  Sharpsign Sharpsign
-## (reader macro)
-  Sharpsign Sharpsign
-  Local Macro PPRINT-POP
-#' (reader macro)
-  Sharpsign Single-Quote
-#( (reader macro)
-  Sharpsign Left-Parenthesis
-#* (reader macro)
-  Sharpsign Asterisk
-#+ (reader macro)
-  Sharpsign Plus
-#- (reader macro)
-  Sharpsign Minus
-#. (reader macro)
-  Sharpsign Dot
-#: (reader macro)
-  Sharpsign Colon
-#< (reader macro)
-  Sharpsign Less-Than-Sign
-#= (reader macro)
-  Sharpsign Equal-Sign
-#A (reader macro)
-  Sharpsign A
-#B (reader macro)
-  Sharpsign B
-#C (reader macro)
-  Sharpsign C
-#O (reader macro)
-  Sharpsign O
-#P (reader macro)
-  Sharpsign P
-#R (reader macro)
-  Sharpsign R
-#S (reader macro)
-  Sharpsign S
-#X (reader macro)
-  Sharpsign X
-#\ (reader macro)
-  Sharpsign Backslash
-#| (reader macro)
-  Sharpsign Vertical-Bar
-$ (format directive)
-  Tilde Dollarsign: Monetary Floating-Point
-% (format directive)
-  Tilde Percent: Newline
-& (format directive)
-  Tilde Ampersand: Fresh-Line
-&allow-other-keys
-  Ordinary Lambda Lists
-  Specifiers for keyword parameters
-  Suppressing Keyword Argument Checking
-  Examples of Ordinary Lambda Lists
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  System Class FUNCTION
-  Type Specifier VALUES
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Keyword Arguments in Generic Functions and Methods
-  Standard Generic Function FUNCTION-KEYWORDS
-  Macro DEFMETHOD
-  Macro DEFINE-METHOD-COMBINATION
-&aux
-  Ordinary Lambda Lists
-  Specifiers for &aux variables
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Glossary Section ``A''
-  Glossary Section ``D''
-&body
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Glossary Section ``B''
-&environment
-  Macro Lambda Lists
-  Destructuring Lambda Lists
-  Defsetf Lambda Lists
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Function ENSURE-GENERIC-FUNCTION
-  Accessor FIND-CLASS
-  Glossary Section ``C''
-  Glossary Section ``D''
-&key
-  Ordinary Lambda Lists
-  Specifiers for keyword parameters
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Too Many Arguments
-  System Class FUNCTION
-  Type Specifier VALUES
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Initialization Arguments
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Keyword Arguments in Generic Functions and Methods
-  Macro DEFINE-METHOD-COMBINATION
-&optional
-  Ordinary Lambda Lists
-  Specifiers for optional parameters
-  Specifiers for keyword parameters
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-modify-macro Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  System Class FUNCTION
-  Type Specifier VALUES
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Macro SETF, PSETF
-&rest
-  Ordinary Lambda Lists
-  A specifier for a rest parameter
-  Specifiers for keyword parameters
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-modify-macro Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Too Many Arguments
-  Macro DEFMACRO
-  System Class FUNCTION
-  Type Specifier VALUES
-  Function APPLY
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Macro SETF, PSETF
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Keyword Arguments in Generic Functions and Methods
-  Macro DEFINE-METHOD-COMBINATION
-  Glossary Section ``B''
-  Glossary Section ``R''
-&whole
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Macro DEFINE-COMPILER-MACRO
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Macro DEFINE-METHOD-COMBINATION
-'
-  Single-Quote
-' (reader macro)
-  Single-Quote
-' (sharpsign reader macro)
-  Sharpsign Single-Quote
-(
-  Left-Parenthesis
-( (format directive)
-  Tilde Left-Paren: Case Conversion
-( (reader macro)
-  Left-Parenthesis
-( (sharpsign reader macro)
-  Sharpsign Left-Parenthesis
-()
-  NIL
-  Glossary Section ``Non-alphabetic''
-(SETF CLASS-NAME)
-  Standard Generic Function (SETF CLASS-NAME)
-(SETF DOCUMENTATION)
-  Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)
-)
-  Right-Parenthesis
-) (format directive)
-  Tilde Right-Paren: End of Case Conversion
-) (reader macro)
-  Right-Parenthesis
-*
-  Function *
-  Variable *, **, ***
-* (format directive)
-  Tilde Asterisk: Go-To
-* (sharpsign reader macro)
-  Sharpsign Asterisk
-**
-  Variable *, **, ***
-***
-  Variable *, **, ***
-*BREAK-ON-SIGNALS*
-  Variable *BREAK-ON-SIGNALS*
-*break-on-warnings*
-  Removed Variables
-*COMPILE-FILE-PATHNAME*
-  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
-*COMPILE-FILE-TRUENAME*
-  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
-*COMPILE-PRINT*
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-*COMPILE-VERBOSE*
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-*DEBUG-IO*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-*DEBUGGER-HOOK*
-  Variable *DEBUGGER-HOOK*
-*DEFAULT-PATHNAME-DEFAULTS*
-  Variable *DEFAULT-PATHNAME-DEFAULTS*
-*ERROR-OUTPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-*FEATURES*
-  Variable *FEATURES*
-*features*
-  Use of Read-Time Conditionals
-  Sharpsign Plus
-  Sharpsign Minus
-*GENSYM-COUNTER*
-  Variable *GENSYM-COUNTER*
-*LOAD-PATHNAME*
-  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
-*LOAD-PRINT*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-*LOAD-TRUENAME*
-  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
-*LOAD-VERBOSE*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-*MACROEXPAND-HOOK*
-  Variable *MACROEXPAND-HOOK*
-*MODULES*
-  Variable *MODULES*
-*PACKAGE*
-  Variable *PACKAGE*
-*PRINT-ARRAY*
-  Variable *PRINT-ARRAY*
-*PRINT-BASE*
-  Variable *PRINT-BASE*, *PRINT-RADIX*
-*PRINT-CASE*
-  Variable *PRINT-CASE*
-*PRINT-CIRCLE*
-  Variable *PRINT-CIRCLE*
-*print-circle*
-  Sharpsign Equal-Sign
-  Sharpsign Sharpsign
-*PRINT-ESCAPE*
-  Variable *PRINT-ESCAPE*
-*PRINT-GENSYM*
-  Variable *PRINT-GENSYM*
-*PRINT-LENGTH*
-  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
-*PRINT-LEVEL*
-  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
-*PRINT-LINES*
-  Variable *PRINT-LINES*
-*PRINT-MISER-WIDTH*
-  Variable *PRINT-MISER-WIDTH*
-*PRINT-PPRINT-DISPATCH*
-  Variable *PRINT-PPRINT-DISPATCH*
-*PRINT-PRETTY*
-  Variable *PRINT-PRETTY*
-*PRINT-RADIX*
-  Variable *PRINT-BASE*, *PRINT-RADIX*
-*PRINT-READABLY*
-  Variable *PRINT-READABLY*
-*PRINT-RIGHT-MARGIN*
-  Variable *PRINT-RIGHT-MARGIN*
-*QUERY-IO*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-*RANDOM-STATE*
-  Variable *RANDOM-STATE*
-*READ-BASE*
-  Variable *READ-BASE*
-*read-base*
-  Sharpsign B
-  Sharpsign O
-  Sharpsign X
-  Sharpsign R
-*READ-DEFAULT-FLOAT-FORMAT*
-  Variable *READ-DEFAULT-FLOAT-FORMAT*
-*READ-EVAL*
-  Variable *READ-EVAL*
-*read-eval*
-  Sharpsign Dot
-*READ-SUPPRESS*
-  Variable *READ-SUPPRESS*
-*READTABLE*
-  Variable *READTABLE*
-*STANDARD-INPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-*STANDARD-OUTPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-*TERMINAL-IO*
-  Variable *TERMINAL-IO*
-*TRACE-OUTPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-+
-  Built-in Method Combination Types
-  Function +
-  Variable +, ++, +++
-+ (sharpsign reader macro)
-  Sharpsign Plus
-++
-  Variable +, ++, +++
-+++
-  Variable +, ++, +++
-,
-  Comma
-, (reader macro)
-  Comma
--
-  Function -
-  Variable -
-- (sharpsign reader macro)
-  Sharpsign Minus
-.
-  Left-Parenthesis
-. (sharpsign reader macro)
-  Sharpsign Dot
-..
-  Re-Reading Abbreviated Expressions
-  Variable *PRINT-LINES*
-...
-  Re-Reading Abbreviated Expressions
-  Local Macro PPRINT-POP
-/
-  Function /
-  Variable /, //, ///
-/ (format directive)
-  Tilde Slash: Call Function
-//
-  Variable /, //, ///
-///
-  Variable /, //, ///
-/=
-  Function =, /=, <, >, <=, >=
-1+
-  Function 1+, 1-
-1-
-  Function 1+, 1-
-: (sharpsign reader macro)
-  Sharpsign Colon
-:abort
-  Function CLOSE
-:absolute
-  Restrictions on Examining a Pathname Directory Component
-:accessor
-  Redefining Classes
-  Accessing Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:adjustable
-  Function MAKE-ARRAY
-:after
-  Introduction to Methods
-  Standard Method Combination
-  Macro DEFMETHOD
-  Glossary Section ``A''
-:allocation
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:allow-other-keys
-  Specifiers for keyword parameters
-  Suppressing Keyword Argument Checking
-  Examples of Ordinary Lambda Lists
-  Declaring the Validity of Initialization Arguments
-  Congruent Lambda-lists for all Methods of a Generic Function
-:ansi-cl
-  Variable *FEATURES*
-  Glossary Section ``F''
-:append
-  Function OPEN
-:argument-precedence-order
-  Sorting the Applicable Methods by Precedence Order
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-:arguments
-  Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Macro DEFINE-METHOD-COMBINATION
-  Glossary Section ``D''
-:around
-  Introduction to Methods
-  Standard Method Combination
-  Built-in Method Combination Types
-  Macro DEFMETHOD
-  Macro DEFINE-METHOD-COMBINATION
-  Glossary Section ``A''
-:array
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:back
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-  Function MERGE-PATHNAMES
-:base
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:before
-  Introduction to Methods
-  Standard Method Combination
-  Macro DEFMETHOD
-  Glossary Section ``B''
-:block
-  Function PPRINT-INDENT
-:capitalize
-  Variable *PRINT-CASE*
-:case
-  Case in Pathname Components
-  Local Case in Pathname Components
-  Common Case in Pathname Components
-  Function MAKE-PATHNAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:class
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:cltl1
-  Variable *FEATURES*
-:cltl2
-  Variable *FEATURES*
-:common
-  Common Case in Pathname Components
-  Function MAKE-PATHNAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-:common-lisp
-  Variable *FEATURES*
-:compile-toplevel
-  File Compilation
-  Processing of Top Level Forms
-  Special Operator EVAL-WHEN
-:conc-name
-  Macro DEFSTRUCT
-:constructor
-  Lambda Lists
-  Boa Lambda Lists
-  Macro DEFSTRUCT
-:copier
-  Macro DEFSTRUCT
-  Function COPY-STRUCTURE
-:count
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-:create
-  Function OPEN
-:current
-  Function PPRINT-INDENT
-:declare
-  Function ENSURE-GENERIC-FUNCTION
-:default
-  System Class BROADCAST-STREAM
-  Function OPEN
-  Function COMPILE-FILE
-  Function LOAD
-  Function ROOM
-  Glossary Section ``E''
-:default-initargs
-  Inheritance of Class Options
-  Object Creation and Initialization
-  Defaulting of Initialization Arguments
-  Rules for Initialization Arguments
-  Definitions of Make-Instance and Initialize-Instance
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:defaults
-  Function MAKE-PATHNAME
-:description
-  Macro DEFINE-METHOD-COMBINATION
-:device
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-:direction
-  Function OPEN
-  Glossary Section ``C''
-:directory
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-:displaced-index-offset
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function ARRAY-DISPLACEMENT
-:displaced-to
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function ARRAY-DISPLACEMENT
-:documentation
-  Inheritance of Slots and Slot Options
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFCLASS
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-  Macro DEFINE-CONDITION
-  Macro DEFPACKAGE
-:downcase
-  Effect of Readtable Case on the Lisp Printer
-  Variable *PRINT-CASE*
-  Effect of Readtable Case on the Lisp Reader
-  Glossary Section ``C''
-:draft-ansi-cl
-  Variable *FEATURES*
-:draft-ansi-cl-2
-  Variable *FEATURES*
-:element-type
-  Function TYPEP
-  Type SIMPLE-ARRAY
-  System Class VECTOR
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function MAKE-STRING
-  Function OPEN
-  Function MAKE-STRING-OUTPUT-STREAM
-  Macro WITH-OUTPUT-TO-STRING
-:end
-  Examples of Ordinary Lambda Lists
-  Function PARSE-INTEGER
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-  Function FILL
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-  Function PARSE-NAMESTRING
-  Function WRITE-STRING, WRITE-LINE
-  Function READ-SEQUENCE
-  Function WRITE-SEQUENCE
-  Macro WITH-INPUT-FROM-STRING
-  Function READ-FROM-STRING
-  Glossary Section ``F''
-:end1
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-:end2
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-:environment
-  Safe and Unsafe Calls
-  Function ENSURE-GENERIC-FUNCTION
-  Function MAKE-LOAD-FORM-SAVING-SLOTS
-:error
-  Function OPEN
-:escape
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:execute
-  File Compilation
-  Processing of Top Level Forms
-  Special Operator EVAL-WHEN
-  Function LOAD
-:expected-type
-  Condition Type TYPE-ERROR
-:export
-  Macro DEFPACKAGE
-:external
-  Function FIND-SYMBOL
-  Macro WITH-PACKAGE-ITERATOR
-  Function INTERN
-:external-format
-  Function OPEN
-  Function STREAM-EXTERNAL-FORMAT
-  Function COMPILE-FILE
-  Function LOAD
-:fill
-  Function PPRINT-NEWLINE
-:fill-pointer
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-:format-arguments
-  Condition Type SIMPLE-CONDITION
-:from-end
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-:generic-function
-  Macro DEFINE-METHOD-COMBINATION
-:generic-function-class
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-:gensym
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:host
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-:identity
-  Macro PRINT-UNREADABLE-OBJECT
-:identity-with-one-argument
-  Macro DEFINE-METHOD-COMBINATION
-:ieee-floating-point
-  Variable *FEATURES*
-:if-does-not-exist
-  Function OPEN
-  Function LOAD
-:if-exists
-  Function OPEN
-:import-from
-  Macro DEFPACKAGE
-:include
-  Type Relationships
-  Integrating Types and Classes
-  Macro DEFSTRUCT
-:index
-  Macro WITH-INPUT-FROM-STRING
-:inherited
-  Function FIND-SYMBOL
-  Macro WITH-PACKAGE-ITERATOR
-  Function INTERN
-:init-form
-  Macro DEFCLASS
-:initarg
-  Object Creation and Initialization
-  Declaring the Validity of Initialization Arguments
-  Rules for Initialization Arguments
-  Definitions of Make-Instance and Initialize-Instance
-  Inheritance of Slots and Slot Options
-  Standard Generic Function REINITIALIZE-INSTANCE
-  Standard Generic Function SHARED-INITIALIZE
-  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
-  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:initform
-  Object Creation and Initialization
-  Initialization Arguments
-  Defaulting of Initialization Arguments
-  Rules for Initialization Arguments
-  Shared-Initialize
-  Initialize-Instance
-  Definitions of Make-Instance and Initialize-Instance
-  Reinitializing an Instance
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Standard Generic Function SHARED-INITIALIZE
-  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
-  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
-  Standard Generic Function SLOT-UNBOUND
-  Macro DEFCLASS
-  Standard Generic Function INITIALIZE-INSTANCE
-  Macro DEFINE-CONDITION
-  Glossary Section ``I''
-:initial-contents
-  Sharpsign A
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Printing Other Arrays
-:initial-element
-  Function MAKE-LIST
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function MAKE-STRING
-  Function MAKE-SEQUENCE
-:initial-offset
-  Macro DEFSTRUCT
-:initial-value
-  Function REDUCE
-:input
-  Function OPEN
-:installed
-  Glossary Section ``V''
-:instance
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:interactive
-  Interactive Use of Restarts
-  Function INVOKE-RESTART-INTERACTIVELY
-  Macro RESTART-CASE
-:interactive-function
-  Interactive Use of Restarts
-  Function INVOKE-RESTART-INTERACTIVELY
-  Macro RESTART-BIND
-:intern
-  Macro DEFPACKAGE
-:internal
-  Function FIND-SYMBOL
-  Macro WITH-PACKAGE-ITERATOR
-  Function INTERN
-:invert
-  Effect of Readtable Case on the Lisp Printer
-  Effect of Readtable Case on the Lisp Reader
-  Glossary Section ``C''
-:io
-  Function OPEN
-:junk-allowed
-  Function PARSE-INTEGER
-  Function PARSE-NAMESTRING
-:key
-  Function SUBLIS, NSUBLIS
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-  Function INTERSECTION, NINTERSECTION
-  Function ADJOIN
-  Macro PUSHNEW
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-  Function SUBSETP
-  Function UNION, NUNION
-  Satisfying a Two-Argument Test
-  Satisfying a One-Argument Test
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function SORT, STABLE-SORT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function MERGE
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-:lambda-list
-  Function ENSURE-GENERIC-FUNCTION
-:length
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:level
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:line
-  Function PPRINT-TAB
-:line-relative
-  Function PPRINT-TAB
-:linear
-  Function PPRINT-NEWLINE
-:lines
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:load-toplevel
-  File Compilation
-  Processing of Top Level Forms
-  Special Operator EVAL-WHEN
-:local
-  Local Case in Pathname Components
-  Common Case in Pathname Components
-  Function MAKE-PATHNAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-:mandatory
-  Function PPRINT-NEWLINE
-:metaclass
-  Defining Classes
-  Macro DEFCLASS
-:method
-  Macro DEFGENERIC
-:method-class
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-:method-combination
-  Applying method combination to the sorted list of applicable methods
-  Built-in Method Combination Types
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-:miser
-  Function PPRINT-NEWLINE
-:miser-width
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:most-specific-first
-  Built-in Method Combination Types
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-:most-specific-last
-  Built-in Method Combination Types
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-:name
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-:named
-  Macro DEFSTRUCT
-:new-version
-  Function OPEN
-:newest
-  Pathnames as Filenames
-  The Pathname Version Component
-  Restrictions on Examining a Pathname Version Component
-  Restrictions on Constructing Pathnames
-  Function MERGE-PATHNAMES
-  Examples of Truenames
-  Function OPEN
-  Glossary Section ``V''
-:nicknames
-  Function MAKE-PACKAGE
-  Macro DEFPACKAGE
-:no-error
-  Macro HANDLER-CASE
-:off
-  Notes about The KEYWORD Package
-:oldest
-  Notes about the Pathname Version Component
-  Glossary Section ``V''
-:on
-  Notes about The KEYWORD Package
-:operands
-  Condition Type ARITHMETIC-ERROR
-:operator
-  Macro DEFINE-METHOD-COMBINATION
-:order
-  Macro DEFINE-METHOD-COMBINATION
-:output
-  Function OPEN
-:output-file
-  Function COMPILE-FILE
-  Function COMPILE-FILE-PATHNAME
-:override
-  Macro WITH-COMPILATION-UNIT
-:overwrite
-  Function OPEN
-:per-line-prefix
-  Tilde Less-Than-Sign: Logical Block
-  Macro PPRINT-LOGICAL-BLOCK
-:pixel-size
-  Examples of Keyword Arguments in Generic Functions and Methods
-:pprint-dispatch
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:pre-line-prefix
-  Macro PPRINT-LOGICAL-BLOCK
-:predicate
-  Macro DEFSTRUCT
-:prefix
-  Tilde Less-Than-Sign: Logical Block
-  Macro PPRINT-LOGICAL-BLOCK
-:preserve
-  Effect of Readtable Case on the Lisp Printer
-  Effect of Readtable Case on the Lisp Reader
-  Glossary Section ``C''
-:preserve-whitespace
-  Function READ-FROM-STRING
-:pretty
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:previous
-  Glossary Section ``V''
-:print
-  Function COMPILE-FILE
-  Function LOAD
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-:print-function
-  Macro DEFSTRUCT
-  Printing Structures
-:print-object
-  Macro DEFSTRUCT
-  Printing Structures
-:probe
-  Function OPEN
-:radix
-  Function PARSE-INTEGER
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:read-only
-  Macro DEFSTRUCT
-:readably
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:reader
-  Redefining Classes
-  Accessing Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:rehash-size
-  Function MAKE-HASH-TABLE
-:rehash-threshold
-  Function MAKE-HASH-TABLE
-:relative
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-  Function MERGE-PATHNAMES
-:rename
-  Function OPEN
-:rename-and-delete
-  Function OPEN
-:report
-  Printing Conditions
-  Interactive Use of Restarts
-  Condition Type CONDITION
-  Macro DEFINE-CONDITION
-  Macro RESTART-CASE
-:report-function
-  Interactive Use of Restarts
-  Macro RESTART-BIND
-:required
-  Macro DEFINE-METHOD-COMBINATION
-:right-margin
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-:section
-  Function PPRINT-TAB
-:section-relative
-  Function PPRINT-TAB
-:shadow
-  Macro DEFPACKAGE
-:shadowing-import-from
-  Macro DEFPACKAGE
-:size
-  Macro DEFPACKAGE
-  Function MAKE-HASH-TABLE
-:slot-names
-  Function MAKE-LOAD-FORM-SAVING-SLOTS
-:start
-  Examples of Ordinary Lambda Lists
-  Function PARSE-INTEGER
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-  Function FILL
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-  Function PARSE-NAMESTRING
-  Function WRITE-STRING, WRITE-LINE
-  Function READ-SEQUENCE
-  Function WRITE-SEQUENCE
-  Macro WITH-INPUT-FROM-STRING
-  Function READ-FROM-STRING
-  Glossary Section ``F''
-:start1
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-:start2
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-:stream
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-:suffix
-  Tilde Less-Than-Sign: Logical Block
-  Macro PPRINT-LOGICAL-BLOCK
-:supersede
-  Function OPEN
-:test
-  Function EQUALP
-  Function COMPLEMENT
-  Restart Tests
-  Macro RESTART-CASE
-  Function SUBLIS, NSUBLIS
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-  Function TREE-EQUAL
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-  Function INTERSECTION, NINTERSECTION
-  Function ADJOIN
-  Macro PUSHNEW
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-  Function SUBSETP
-  Function UNION, NUNION
-  Satisfying a Two-Argument Test
-  Satisfying a One-Argument Test
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-  Modifying Hash Table Keys
-  Visible Modifications by Language Extensions
-  Function MAKE-HASH-TABLE
-:test-function
-  Restart Tests
-  Macro RESTART-BIND
-:test-not
-  Deprecated Argument Conventions
-  Function COMPLEMENT
-  Function SUBLIS, NSUBLIS
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-  Function TREE-EQUAL
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-  Function INTERSECTION, NINTERSECTION
-  Function ADJOIN
-  Macro PUSHNEW
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-  Function SUBSETP
-  Function UNION, NUNION
-  Satisfying a Two-Argument Test
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-:type
-  Boa Lambda Lists
-  Type Specifiers
-  Integrating Types and Classes
-  Function TYPE-OF
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFSTRUCT
-  Macro DEFINE-CONDITION
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-  Macro PRINT-UNREADABLE-OBJECT
-  Glossary Section ``S''
-:unspecific
-  The Pathname Type Component
-  The Pathname Version Component
-  :UNSPECIFIC as a Component Value
-  Relation between component values NIL and :UNSPECIFIC
-  Restrictions on Examining a Pathname Device Component
-  Restrictions on Examining a Pathname Directory Component
-  Restrictions on Examining a Pathname Name Component
-  Restrictions on Examining a Pathname Type Component
-  Restrictions on Examining a Pathname Version Component
-  Merging Pathnames
-  Examples of Merging Pathnames
-  The Device part of a Logical Pathname Namestring
-  Unspecific Components of a Logical Pathname
-  Function MAKE-PATHNAME
-  Function USER-HOMEDIR-PATHNAME
-  Glossary Section ``V''
-:up
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-:upcase
-  The Standard Readtable
-  Symbols as Tokens
-  Valid Patterns for Tokens
-  Effect of Readtable Case on the Lisp Printer
-  Variable *PRINT-CASE*
-  Effect of Readtable Case on the Lisp Reader
-  Macro WITH-STANDARD-IO-SYNTAX
-  Glossary Section ``C''
-:use
-  Function MAKE-PACKAGE
-  Macro DEFPACKAGE
-:verbose
-  Function ENSURE-DIRECTORIES-EXIST
-  Function COMPILE-FILE
-  Function LOAD
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-:version
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-:wild
-  The Pathname Type Component
-  The Pathname Version Component
-  :WILD as a Component Value
-  Restrictions on Wildcard Pathnames
-  Restrictions on Examining a Pathname Device Component
-  Restrictions on Examining a Pathname Directory Component
-  Restrictions on Examining a Pathname Name Component
-  Restrictions on Examining a Pathname Type Component
-  Restrictions on Examining a Pathname Version Component
-  The Version part of a Logical Pathname Namestring
-  Wildcard Words in a Logical Pathname Namestring
-  Function MAKE-PATHNAME
-  Function PATHNAME-MATCH-P
-  Function TRANSLATE-PATHNAME
-  Function MERGE-PATHNAMES
-  Glossary Section ``V''
-  Glossary Section ``W''
-:wild-inferiors
-  :WILD as a Component Value
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-  The Directory part of a Logical Pathname Namestring
-  Function MAKE-PATHNAME
-:wild-inferors
-  Glossary Section ``W''
-:writer
-  Redefining Classes
-  Accessing Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:x3j13
-  Variable *FEATURES*
-;
-  Semicolon
-; (format directive)
-  Tilde Semicolon: Clause Separator
-; (reader macro)
-  Semicolon
-<
-  Function =, /=, <, >, <=, >=
-< (format directive)
-  Tilde Less-Than-Sign: Logical Block
-  Tilde Less-Than-Sign: Justification
-< (sharpsign reader macro)
-  Sharpsign Less-Than-Sign
-<=
-  Function =, /=, <, >, <=, >=
-=
-  Function =, /=, <, >, <=, >=
-= (sharpsign reader macro)
-  Sharpsign Equal-Sign
->
-  Function =, /=, <, >, <=, >=
-> (format directive)
-  Tilde Greater-Than-Sign: End of Justification
->=
-  Function =, /=, <, >, <=, >=
-? (format directive)
-  Tilde Question-Mark: Recursive Processing
-[ (format directive)
-  Tilde Left-Bracket: Conditional Expression
-\ (sharpsign reader macro)
-  Sharpsign Backslash
-] (format directive)
-  Tilde Right-Bracket: End of Conditional Expression
-^ (format directive)
-  Tilde Circumflex: Escape Upward
-_ (format directive)
-  Tilde Underscore: Conditional Newline
-`
-  Backquote
-` (reader macro)
-  Backquote
-{ (format directive)
-  Tilde Left-Brace: Iteration
-| (format directive)
-  Tilde Vertical-Bar: Page
-| (sharpsign reader macro)
-  Sharpsign Vertical-Bar
-} (format directive)
-  Tilde Right-Brace: End of Iteration
-~ (format directive)
-  Tilde Tilde: Tilde
-~$ (format directive)
-  Tilde Dollarsign: Monetary Floating-Point
-~% (format directive)
-  Tilde Percent: Newline
-~& (format directive)
-  Tilde Ampersand: Fresh-Line
-~( (format directive)
-  Tilde Left-Paren: Case Conversion
-~) (format directive)
-  Tilde Right-Paren: End of Case Conversion
-~* (format directive)
-  Tilde Asterisk: Go-To
-~/ (format directive)
-  Tilde Slash: Call Function
-~; (format directive)
-  Tilde Semicolon: Clause Separator
-~< (format directive)
-  Tilde Less-Than-Sign: Logical Block
-  Tilde Less-Than-Sign: Justification
-~> (format directive)
-  Tilde Greater-Than-Sign: End of Justification
-~? (format directive)
-  Tilde Question-Mark: Recursive Processing
-~A (format directive)
-  Tilde A: Aesthetic
-~B (format directive)
-  Tilde B: Binary
-~C (format directive)
-  Tilde C: Character
-~D (format directive)
-  Tilde D: Decimal
-~E (format directive)
-  Tilde E: Exponential Floating-Point
-~F (format directive)
-  Tilde F: Fixed-Format Floating-Point
-~G (format directive)
-  Tilde G: General Floating-Point
-~I (format directive)
-  Tilde I: Indent
-~Newline (format directive)
-  Tilde Newline: Ignored Newline
-~O (format directive)
-  Tilde O: Octal
-~P (format directive)
-  Tilde P: Plural
-~R (format directive)
-  Tilde R: Radix
-~S (format directive)
-  Tilde S: Standard
-~T (format directive)
-  Tilde T: Tabulate
-~W (format directive)
-  Tilde W: Write
-~X (format directive)
-  Tilde X: Hexadecimal
-~[ (format directive)
-  Tilde Left-Bracket: Conditional Expression
-~] (format directive)
-  Tilde Right-Bracket: End of Conditional Expression
-~^ (format directive)
-  Tilde Circumflex: Escape Upward
-~_ (format directive)
-  Tilde Underscore: Conditional Newline
-~{ (format directive)
-  Tilde Left-Brace: Iteration
-~| (format directive)
-  Tilde Vertical-Bar: Page
-~} (format directive)
-  Tilde Right-Brace: End of Iteration
-~~ (format directive)
-  Tilde Tilde: Tilde
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_A.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_A.htm deleted file mode 100644 index b8ede143..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_A.htm +++ /dev/null @@ -1,355 +0,0 @@ - - - -CLHS: Index - A - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - A

    - -
    -A (format directive)
-  Tilde A: Aesthetic
-A (sharpsign reader macro)
-  Sharpsign A
-abort
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-ABORT
-  Restart ABORT
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-:abort
-  Function CLOSE
-above (loop keyword)
-  The for-as-arithmetic subclause
-  Macro LOOP
-ABS
-  Function ABS
-absolute
-  Glossary Section ``A''
-:absolute
-  Restrictions on Examining a Pathname Directory Component
-access
-  Glossary Section ``A''
-accessibility
-  Glossary Section ``A''
-accessible
-  Glossary Section ``A''
-accessor
-  Glossary Section ``A''
-:accessor
-  Redefining Classes
-  Accessing Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-ACONS
-  Function ACONS
-ACOS
-  Function ASIN, ACOS, ATAN
-ACOSH
-  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
-across (loop keyword)
-  The for-as-across subclause
-  Macro LOOP
-active
-  Glossary Section ``A''
-actual adjustability
-  Glossary Section ``A''
-actual argument
-  Glossary Section ``A''
-actual array element type
-  Glossary Section ``A''
-actual complex part type
-  Glossary Section ``A''
-actual parameter
-  Glossary Section ``A''
-actually adjustable
-  Glossary Section ``A''
-ADD-METHOD
-  Standard Generic Function ADD-METHOD
-ADJOIN
-  Function ADJOIN
-ADJUST-ARRAY
-  Function ADJUST-ARRAY
-adjustability
-  Glossary Section ``A''
-adjustable
-  Glossary Section ``A''
-:adjustable
-  Function MAKE-ARRAY
-ADJUSTABLE-ARRAY-P
-  Function ADJUSTABLE-ARRAY-P
-:after
-  Introduction to Methods
-  Standard Method Combination
-  Macro DEFMETHOD
-  Glossary Section ``A''
-after method
-  Glossary Section ``A''
-alist
-  Glossary Section ``A''
-ALLOCATE-INSTANCE
-  Standard Generic Function ALLOCATE-INSTANCE
-:allocation
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-&allow-other-keys
-  Ordinary Lambda Lists
-  Specifiers for keyword parameters
-  Suppressing Keyword Argument Checking
-  Examples of Ordinary Lambda Lists
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  System Class FUNCTION
-  Type Specifier VALUES
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Keyword Arguments in Generic Functions and Methods
-  Standard Generic Function FUNCTION-KEYWORDS
-  Macro DEFMETHOD
-  Macro DEFINE-METHOD-COMBINATION
-:allow-other-keys
-  Specifiers for keyword parameters
-  Suppressing Keyword Argument Checking
-  Examples of Ordinary Lambda Lists
-  Declaring the Validity of Initialization Arguments
-  Congruent Lambda-lists for all Methods of a Generic Function
-ALPHA-CHAR-P
-  Function ALPHA-CHAR-P
-alphabetic
-  Glossary Section ``A''
-alphanumeric
-  Glossary Section ``A''
-ALPHANUMERICP
-  Function ALPHANUMERICP
-always (loop keyword)
-  Summary of Termination Test Clauses
-  Termination Test Clauses
-  Initial and Final Execution
-  Macro LOOP
-ampersand
-  Glossary Section ``A''
-Ampersand (format directive)
-  Tilde Ampersand: Fresh-Line
-and
-  Built-in Method Combination Types
-AND
-  Type Specifier AND
-  Macro AND
-and (loop keyword)
-  Summary of Variable Initialization and Stepping Clauses
-  Summary of Conditional Execution Clauses
-  Destructuring
-  Iteration Control
-  Local Variable Initializations
-  Conditional Execution Clauses
-  Macro LOOP
-anonymous
-  Glossary Section ``A''
-:ansi-cl
-  Variable *FEATURES*
-  Glossary Section ``F''
-apparently uninterned
-  Glossary Section ``A''
-APPEND
-  Function APPEND
-append
-  Built-in Method Combination Types
-:append
-  Function OPEN
-append (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-appending (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-applicable
-  Glossary Section ``A''
-applicable handler
-  Glossary Section ``A''
-applicable method
-  Glossary Section ``A''
-applicable restart
-  Glossary Section ``A''
-apply
-  Glossary Section ``A''
-APPLY
-  Function APPLY
-APROPOS
-  Function APROPOS, APROPOS-LIST
-APROPOS-LIST
-  Function APROPOS, APROPOS-LIST
-AREF
-  Accessor AREF
-argument
-  Glossary Section ``A''
-argument evaluation order
-  Glossary Section ``A''
-argument precedence order
-  Glossary Section ``A''
-:argument-precedence-order
-  Sorting the Applicable Methods by Precedence Order
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-:arguments
-  Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Macro DEFINE-METHOD-COMBINATION
-  Glossary Section ``D''
-ARITHMETIC-ERROR
-  Condition Type ARITHMETIC-ERROR
-ARITHMETIC-ERROR-OPERANDS
-  Function ARITHMETIC-ERROR-OPERANDS, ARITHMETIC-ERROR-OPERATION
-ARITHMETIC-ERROR-OPERATION
-  Function ARITHMETIC-ERROR-OPERANDS, ARITHMETIC-ERROR-OPERATION
-:around
-  Introduction to Methods
-  Standard Method Combination
-  Built-in Method Combination Types
-  Macro DEFMETHOD
-  Macro DEFINE-METHOD-COMBINATION
-  Glossary Section ``A''
-around method
-  Glossary Section ``A''
-ARRAY
-  System Class ARRAY
-array
-  Sharpsign A
-  Glossary Section ``A''
-:array
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-array element type
-  Glossary Section ``A''
-array total size
-  Glossary Section ``A''
-ARRAY-DIMENSION
-  Function ARRAY-DIMENSION
-ARRAY-DIMENSION-LIMIT
-  Constant Variable ARRAY-DIMENSION-LIMIT
-ARRAY-DIMENSIONS
-  Function ARRAY-DIMENSIONS
-ARRAY-DISPLACEMENT
-  Function ARRAY-DISPLACEMENT
-ARRAY-ELEMENT-TYPE
-  Function ARRAY-ELEMENT-TYPE
-ARRAY-HAS-FILL-POINTER-P
-  Function ARRAY-HAS-FILL-POINTER-P
-ARRAY-IN-BOUNDS-P
-  Function ARRAY-IN-BOUNDS-P
-ARRAY-RANK
-  Function ARRAY-RANK
-ARRAY-RANK-LIMIT
-  Constant Variable ARRAY-RANK-LIMIT
-ARRAY-ROW-MAJOR-INDEX
-  Function ARRAY-ROW-MAJOR-INDEX
-ARRAY-TOTAL-SIZE
-  Function ARRAY-TOTAL-SIZE
-ARRAY-TOTAL-SIZE-LIMIT
-  Constant Variable ARRAY-TOTAL-SIZE-LIMIT
-ARRAYP
-  Function ARRAYP
-as (loop keyword)
-  Summary of Variable Initialization and Stepping Clauses
-  Summary of Termination Test Clauses
-  Summary of Miscellaneous Clauses
-  Iteration Control
-  The for-as-arithmetic subclause
-  The for-as-in-list subclause
-  The for-as-on-list subclause
-  The for-as-equals-then subclause
-  The for-as-across subclause
-  The for-as-hash subclause
-  The for-as-package subclause
-  Initial and Final Execution
-  Macro LOOP
-ASH
-  Function ASH
-ASIN
-  Function ASIN, ACOS, ATAN
-ASINH
-  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
-ASSERT
-  Macro ASSERT
-assign
-  Glossary Section ``A''
-ASSOC
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-ASSOC-IF
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-ASSOC-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-association list
-  Glossary Section ``A''
-asterisk
-  Glossary Section ``A''
-Asterisk (format directive)
-  Tilde Asterisk: Go-To
-Asterisk (sharpsign reader macro)
-  Sharpsign Asterisk
-at-sign
-  Glossary Section ``A''
-ATAN
-  Function ASIN, ACOS, ATAN
-ATANH
-  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
-atom
-  Glossary Section ``A''
-ATOM
-  Type ATOM
-  Function ATOM
-atomic
-  Glossary Section ``A''
-atomic type specifier
-  Glossary Section ``A''
-attribute
-  Glossary Section ``A''
-&aux
-  Ordinary Lambda Lists
-  Specifiers for &aux variables
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Glossary Section ``A''
-  Glossary Section ``D''
-aux variable
-  Glossary Section ``A''
-auxiliary method
-  Glossary Section ``A''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_B.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_B.htm deleted file mode 100644 index e57911f3..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_B.htm +++ /dev/null @@ -1,236 +0,0 @@ - - - -CLHS: Index - B - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - B

    - -
    -B (format directive)
-  Tilde B: Binary
-B (sharpsign reader macro)
-  Sharpsign B
-:back
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-  Function MERGE-PATHNAMES
-backquote
-  Glossary Section ``B''
-Backquote (reader macro)
-  Backquote
-backslash
-  Glossary Section ``B''
-Backslash (sharpsign reader macro)
-  Sharpsign Backslash
-bar
-  Nonsense Words
-:base
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-base character
-  Glossary Section ``B''
-base string
-  Glossary Section ``B''
-BASE-CHAR
-  Type BASE-CHAR
-BASE-STRING
-  Type BASE-STRING
-baz
-  Nonsense Words
-:before
-  Introduction to Methods
-  Standard Method Combination
-  Macro DEFMETHOD
-  Glossary Section ``B''
-before method
-  Glossary Section ``B''
-being (loop keyword)
-  The for-as-hash subclause
-  The for-as-package subclause
-  Macro LOOP
-below (loop keyword)
-  The for-as-arithmetic subclause
-  Macro LOOP
-bidirectional
-  Glossary Section ``B''
-BIGNUM
-  Type BIGNUM
-binary
-  Glossary Section ``B''
-bind
-  Glossary Section ``B''
-binding
-  Glossary Section ``B''
-bit
-  Glossary Section ``B''
-BIT
-  Type BIT
-  Accessor BIT, SBIT
-bit array
-  Glossary Section ``B''
-bit vector
-  Required Kinds of Specialized Arrays
-  Glossary Section ``B''
-BIT-AND
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-ANDC1
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-ANDC2
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-EQV
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-IOR
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-NAND
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-NOR
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-NOT
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-ORC1
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-ORC2
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-BIT-VECTOR
-  System Class BIT-VECTOR
-bit-vector
-  Sharpsign Asterisk
-BIT-VECTOR-P
-  Function BIT-VECTOR-P
-bit-wise logical operation specifier
-  Glossary Section ``B''
-BIT-XOR
-  Function BIT-AND, BIT-ANDC1, BIT-ANDC2, BIT-EQV, BIT-IOR, BIT-NAND, BIT-NOR, BIT-NOT, BIT-ORC1, BIT-ORC2, BIT-XOR
-block
-  Glossary Section ``B''
-BLOCK
-  Special Operator BLOCK
-:block
-  Function PPRINT-INDENT
-block tag
-  Glossary Section ``B''
-bnf key
-  Modified BNF Syntax
-boa lambda list
-  Glossary Section ``B''
-&body
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Glossary Section ``B''
-body parameter
-  Glossary Section ``B''
-BOOLE
-  Function BOOLE
-BOOLE-1
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-2
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-AND
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-ANDC1
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-ANDC2
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-C1
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-C2
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-CLR
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-EQV
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-IOR
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-NAND
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-NOR
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-ORC1
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-ORC2
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-SET
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-BOOLE-XOR
-  Constant Variable BOOLE-1, BOOLE-2, BOOLE-AND, BOOLE-ANDC1, BOOLE-ANDC2, BOOLE-C1, BOOLE-C2, BOOLE-CLR, BOOLE-EQV, BOOLE-IOR, BOOLE-NAND, BOOLE-NOR, BOOLE-ORC1, BOOLE-ORC2, BOOLE-SET, BOOLE-XOR
-boolean
-  Glossary Section ``B''
-BOOLEAN
-  Type BOOLEAN
-boolean equivalent
-  Glossary Section ``B''
-BOTH-CASE-P
-  Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P
-bound
-  Glossary Section ``B''
-bound declaration
-  Glossary Section ``B''
-bounded
-  Glossary Section ``B''
-bounding index
-  Glossary Section ``B''
-bounding index designator
-  Glossary Section ``B''
-BOUNDP
-  Function BOUNDP
-BREAK
-  Function BREAK
-break loop
-  Glossary Section ``B''
-*BREAK-ON-SIGNALS*
-  Variable *BREAK-ON-SIGNALS*
-*break-on-warnings*
-  Removed Variables
-broadcast stream
-  Glossary Section ``B''
-BROADCAST-STREAM
-  System Class BROADCAST-STREAM
-BROADCAST-STREAM-STREAMS
-  Function BROADCAST-STREAM-STREAMS
-built-in class
-  Glossary Section ``B''
-built-in type
-  Glossary Section ``B''
-BUILT-IN-CLASS
-  System Class BUILT-IN-CLASS
-BUTLAST
-  Function BUTLAST, NBUTLAST
-by (loop keyword)
-  The for-as-arithmetic subclause
-  The for-as-in-list subclause
-  The for-as-on-list subclause
-  Macro LOOP
-byte
-  Glossary Section ``B''
-BYTE
-  Function BYTE, BYTE-SIZE, BYTE-POSITION
-byte specifier
-  Glossary Section ``B''
-BYTE-POSITION
-  Function BYTE, BYTE-SIZE, BYTE-POSITION
-BYTE-SIZE
-  Function BYTE, BYTE-SIZE, BYTE-POSITION
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_C.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_C.htm deleted file mode 100644 index bcc91e73..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_C.htm +++ /dev/null @@ -1,551 +0,0 @@ - - - -CLHS: Index - C - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - C

    - -
    -C (format directive)
-  Tilde C: Character
-C (sharpsign reader macro)
-  Sharpsign C
-CAAAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CAAADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CAAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CAADAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CAADDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CAADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CADAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CADADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CADAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CADDAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CADDDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CADDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-cadr
-  Glossary Section ``C''
-CADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-call
-  Glossary Section ``C''
-CALL-ARGUMENTS-LIMIT
-  Constant Variable CALL-ARGUMENTS-LIMIT
-CALL-METHOD
-  Local Macro CALL-METHOD, MAKE-METHOD
-CALL-NEXT-METHOD
-  Local Function CALL-NEXT-METHOD
-:capitalize
-  Variable *PRINT-CASE*
-captured initialization form
-  Glossary Section ``C''
-car
-  Glossary Section ``C''
-CAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-case
-  Glossary Section ``C''
-CASE
-  Macro CASE, CCASE, ECASE
-:case
-  Case in Pathname Components
-  Local Case in Pathname Components
-  Common Case in Pathname Components
-  Function MAKE-PATHNAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-case in symbol names
-  Case in Symbols
-case sensitivity mode
-  Glossary Section ``C''
-catch
-  Glossary Section ``C''
-CATCH
-  Special Operator CATCH
-catch tag
-  Glossary Section ``C''
-CCASE
-  Macro CASE, CCASE, ECASE
-CDAAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDAADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDADAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDADDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDDAAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDDADR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDDAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDDDAR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDDDDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CDDDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-cddr
-  Glossary Section ``C''
-CDDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-cdr
-  Glossary Section ``C''
-CDR
-  Accessor CAR, CDR, CAAR, CADR, CDAR, CDDR, CAAAR, CAADR, CADAR, CADDR, CDAAR, CDADR, CDDAR, CDDDR, CAAAAR, CAAADR, CAADAR, CAADDR, CADAAR, CADADR, CADDAR, CADDDR, CDAAAR, CDAADR, CDADAR, CDADDR, CDDAAR, CDDADR, CDDDAR, CDDDDR
-CEILING
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-cell
-  Glossary Section ``C''
-CELL-ERROR
-  Condition Type CELL-ERROR
-CELL-ERROR-NAME
-  Function CELL-ERROR-NAME
-CERROR
-  Function CERROR
-CHANGE-CLASS
-  Standard Generic Function CHANGE-CLASS
-CHAR
-  Accessor CHAR, SCHAR
-char-bit
-  Removed Operators
-char-bits
-  Removed Operators
-char-bits-limit
-  Removed Variables
-CHAR-CODE
-  Function CHAR-CODE
-CHAR-CODE-LIMIT
-  Constant Variable CHAR-CODE-LIMIT
-char-control-bit
-  Removed Variables
-CHAR-DOWNCASE
-  Function CHAR-UPCASE, CHAR-DOWNCASE
-CHAR-EQUAL
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-char-font
-  Removed Operators
-char-font-limit
-  Removed Variables
-CHAR-GREATERP
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-char-hyper-bit
-  Removed Variables
-CHAR-INT
-  Function CHAR-INT
-CHAR-LESSP
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-char-meta-bit
-  Removed Variables
-CHAR-NAME
-  Function CHAR-NAME
-CHAR-NOT-EQUAL
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR-NOT-GREATERP
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR-NOT-LESSP
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-char-super-bit
-  Removed Variables
-CHAR-UPCASE
-  Function CHAR-UPCASE, CHAR-DOWNCASE
-CHAR/=
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR<
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR<=
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR=
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR>
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHAR>=
-  Function CHAR=, CHAR/=, CHAR<, CHAR>, CHAR<=, CHAR>=, CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-GREATERP, CHAR-NOT-LESSP
-CHARACTER
-  System Class CHARACTER
-  Function CHARACTER
-character
-  Sharpsign Backslash
-  Glossary Section ``C''
-character code
-  Glossary Section ``C''
-character designator
-  Glossary Section ``C''
-CHARACTERP
-  Function CHARACTERP
-CHECK-TYPE
-  Macro CHECK-TYPE
-circular
-  Glossary Section ``C''
-circular list
-  Glossary Section ``C''
-Circumflex (format directive)
-  Tilde Circumflex: Escape Upward
-CIS
-  Function CIS
-CL
-  The COMMON-LISP Package
-CL-USER
-  The COMMON-LISP-USER Package
-class
-  Glossary Section ``C''
-CLASS
-  System Class CLASS
-:class
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-class designator
-  Glossary Section ``C''
-class precedence list
-  Glossary Section ``C''
-CLASS-NAME
-  Standard Generic Function CLASS-NAME
-CLASS-OF
-  Function CLASS-OF
-CLEAR-INPUT
-  Function CLEAR-INPUT
-CLEAR-OUTPUT
-  Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT
-close
-  Glossary Section ``C''
-CLOSE
-  Function CLOSE
-closed
-  Glossary Section ``C''
-closure
-  Glossary Section ``C''
-CLRHASH
-  Function CLRHASH
-:cltl1
-  Variable *FEATURES*
-:cltl2
-  Variable *FEATURES*
-coalesce
-  Glossary Section ``C''
-code
-  Glossary Section ``C''
-code-char
-  Removed Argument Conventions
-CODE-CHAR
-  Function CODE-CHAR
-coerce
-  Glossary Section ``C''
-COERCE
-  Function COERCE
-collect (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-collecting (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-colon
-  Glossary Section ``C''
-Colon (sharpsign reader macro)
-  Sharpsign Colon
-comma
-  Glossary Section ``C''
-Comma (reader macro)
-  Comma
-comment
-  Semicolon
-  Sharpsign Vertical-Bar
-:common
-  Common Case in Pathname Components
-  Function MAKE-PATHNAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-COMMON-LISP
-  Symbols in the COMMON-LISP Package
-  The COMMON-LISP Package
-COMMON-LISP-USER
-  The COMMON-LISP-USER Package
-:common-lisp
-  Variable *FEATURES*
-commonp
-  Removed Operators
-compilation
-  Glossary Section ``C''
-compilation environment
-  Glossary Section ``C''
-compilation unit
-  Glossary Section ``C''
-COMPILE
-  Function COMPILE
-compile
-  Minimal Compilation
-  Special Operator EVAL-WHEN
-  Glossary Section ``C''
-compile time
-  Glossary Section ``C''
-COMPILE-FILE
-  Function COMPILE-FILE
-compile-file
-  Minimal Compilation
-COMPILE-FILE-PATHNAME
-  Function COMPILE-FILE-PATHNAME
-compile-time definition
-  Glossary Section ``C''
-compiled code
-  Glossary Section ``C''
-compiled file
-  Glossary Section ``C''
-compiled function
-  Glossary Section ``C''
-COMPILED-FUNCTION
-  Type COMPILED-FUNCTION
-COMPILED-FUNCTION-P
-  Function COMPILED-FUNCTION-P
-*COMPILE-FILE-PATHNAME*
-  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
-*COMPILE-FILE-TRUENAME*
-  Variable *COMPILE-FILE-PATHNAME*, *COMPILE-FILE-TRUENAME*
-*COMPILE-PRINT*
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-compiler
-  Glossary Section ``C''
-compiler macro
-  Minimal Compilation
-  Glossary Section ``C''
-compiler macro expansion
-  Glossary Section ``C''
-compiler macro form
-  Glossary Section ``C''
-compiler macro function
-  Glossary Section ``C''
-COMPILER-MACRO-FUNCTION
-  Accessor COMPILER-MACRO-FUNCTION
-:compile-toplevel
-  File Compilation
-  Processing of Top Level Forms
-  Special Operator EVAL-WHEN
-*COMPILE-VERBOSE*
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-COMPLEMENT
-  Function COMPLEMENT
-COMPLEX
-  System Class COMPLEX
-  Function COMPLEX
-complex
-  Sharpsign C
-  Printing Complexes
-  Glossary Section ``C''
-complex float
-  Glossary Section ``C''
-complex part type
-  Glossary Section ``C''
-complex rational
-  Glossary Section ``C''
-complex single float
-  Glossary Section ``C''
-COMPLEXP
-  Function COMPLEXP
-composite stream
-  Glossary Section ``C''
-compound form
-  Glossary Section ``C''
-compound type specifier
-  Glossary Section ``C''
-COMPUTE-APPLICABLE-METHODS
-  Standard Generic Function COMPUTE-APPLICABLE-METHODS
-COMPUTE-RESTARTS
-  Function COMPUTE-RESTARTS
-CONCATENATE
-  Function CONCATENATE
-concatenated stream
-  Glossary Section ``C''
-CONCATENATED-STREAM
-  System Class CONCATENATED-STREAM
-CONCATENATED-STREAM-STREAMS
-  Function CONCATENATED-STREAM-STREAMS
-:conc-name
-  Macro DEFSTRUCT
-COND
-  Macro COND
-condition
-  Glossary Section ``C''
-CONDITION
-  Condition Type CONDITION
-condition designator
-  Condition Designators
-  Glossary Section ``C''
-condition handler
-  Glossary Section ``C''
-condition reporter
-  Glossary Section ``C''
-conditional newline
-  Glossary Section ``C''
-conformance
-  Glossary Section ``C''
-conforming code
-  Conforming Programs
-  Glossary Section ``C''
-conforming implementation
-  Glossary Section ``C''
-conforming processor
-  Glossary Section ``C''
-conforming program
-  Conforming Programs
-  Glossary Section ``C''
-congruent
-  Glossary Section ``C''
-CONJUGATE
-  Function CONJUGATE
-CONS
-  System Class CONS
-  Function CONS
-cons
-  Backquote
-  Comma
-  Glossary Section ``C''
-consequences
-  Error Terminology
-CONSP
-  Function CONSP
-constant
-  Glossary Section ``C''
-constant form
-  Glossary Section ``C''
-constant object
-  Glossary Section ``C''
-constant variable
-  Glossary Section ``C''
-CONSTANTLY
-  Function CONSTANTLY
-CONSTANTP
-  Function CONSTANTP
-constituent
-  Glossary Section ``C''
-constituent trait
-  Glossary Section ``C''
-constructed stream
-  Glossary Section ``C''
-:constructor
-  Lambda Lists
-  Boa Lambda Lists
-  Macro DEFSTRUCT
-contagion
-  Glossary Section ``C''
-continuable
-  Glossary Section ``C''
-continue
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-CONTINUE
-  Restart CONTINUE
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-control form
-  Glossary Section ``C''
-CONTROL-ERROR
-  Condition Type CONTROL-ERROR
-:copier
-  Macro DEFSTRUCT
-  Function COPY-STRUCTURE
-copy
-  Glossary Section ``C''
-COPY-ALIST
-  Function COPY-ALIST
-COPY-LIST
-  Function COPY-LIST
-COPY-PPRINT-DISPATCH
-  Function COPY-PPRINT-DISPATCH
-COPY-READTABLE
-  Function COPY-READTABLE
-COPY-SEQ
-  Function COPY-SEQ
-COPY-STRUCTURE
-  Function COPY-STRUCTURE
-COPY-SYMBOL
-  Function COPY-SYMBOL
-COPY-TREE
-  Function COPY-TREE
-correctable
-  Glossary Section ``C''
-COS
-  Function SIN, COS, TAN
-COSH
-  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
-COUNT
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-:count
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-count (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-COUNT-IF
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-COUNT-IF-NOT
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-counting (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-:create
-  Function OPEN
-CTYPECASE
-  Macro TYPECASE, CTYPECASE, ETYPECASE
-:current
-  Function PPRINT-INDENT
-current input base
-  Glossary Section ``C''
-current logical block
-  Glossary Section ``C''
-current output base
-  Glossary Section ``C''
-current package
-  Glossary Section ``C''
-current pprint dispatch table
-  Glossary Section ``C''
-current random state
-  Glossary Section ``C''
-current readtable
-  Glossary Section ``C''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_D.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_D.htm deleted file mode 100644 index 2797cb58..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_D.htm +++ /dev/null @@ -1,330 +0,0 @@ - - - -CLHS: Index - D - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - D

    - -
    -D (format directive)
-  Tilde D: Decimal
-data type
-  Glossary Section ``D''
-debug I/O
-  Glossary Section ``D''
-debugger
-  Glossary Section ``D''
-*DEBUGGER-HOOK*
-  Variable *DEBUGGER-HOOK*
-*DEBUG-IO*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-DECF
-  Macro INCF, DECF
-DECLAIM
-  Macro DECLAIM
-DECLARATION
-  Declaration DECLARATION
-declaration
-  Declarations
-  Minimal Declaration Processing Requirements
-  Glossary Section ``D''
-declaration identifier
-  Declaration Identifiers
-  Glossary Section ``D''
-declaration specifier
-  Glossary Section ``D''
-declare
-  Glossary Section ``D''
-DECLARE
-  Symbol DECLARE
-:declare
-  Function ENSURE-GENERIC-FUNCTION
-decline
-  Glossary Section ``D''
-DECODE-FLOAT
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-DECODE-UNIVERSAL-TIME
-  Function DECODE-UNIVERSAL-TIME
-decoded time
-  Glossary Section ``D''
-:default
-  System Class BROADCAST-STREAM
-  Function OPEN
-  Function COMPILE-FILE
-  Function LOAD
-  Function ROOM
-  Glossary Section ``E''
-default method
-  Glossary Section ``D''
-defaulted initialization argument list
-  Glossary Section ``D''
-:default-initargs
-  Inheritance of Class Options
-  Object Creation and Initialization
-  Defaulting of Initialization Arguments
-  Rules for Initialization Arguments
-  Definitions of Make-Instance and Initialize-Instance
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-*DEFAULT-PATHNAME-DEFAULTS*
-  Variable *DEFAULT-PATHNAME-DEFAULTS*
-:defaults
-  Function MAKE-PATHNAME
-DEFCLASS
-  Macro DEFCLASS
-DEFCONSTANT
-  Macro DEFCONSTANT
-DEFGENERIC
-  Macro DEFGENERIC
-DEFINE-COMPILER-MACRO
-  Macro DEFINE-COMPILER-MACRO
-DEFINE-CONDITION
-  Macro DEFINE-CONDITION
-DEFINE-METHOD-COMBINATION
-  Macro DEFINE-METHOD-COMBINATION
-define-method-combination arguments lambda list
-  Glossary Section ``D''
-DEFINE-MODIFY-MACRO
-  Macro DEFINE-MODIFY-MACRO
-define-modify-macro lambda list
-  Glossary Section ``D''
-DEFINE-SETF-EXPANDER
-  Macro DEFINE-SETF-EXPANDER
-DEFINE-SYMBOL-MACRO
-  Macro DEFINE-SYMBOL-MACRO
-defined name
-  Glossary Section ``D''
-defining form
-  Glossary Section ``D''
-DEFMACRO
-  Macro DEFMACRO
-DEFMETHOD
-  Macro DEFMETHOD
-DEFPACKAGE
-  Macro DEFPACKAGE
-DEFPARAMETER
-  Macro DEFPARAMETER, DEFVAR
-DEFSETF
-  Macro DEFSETF
-defsetf lambda list
-  Glossary Section ``D''
-DEFSTRUCT
-  Macro DEFSTRUCT
-DEFTYPE
-  Macro DEFTYPE
-deftype lambda list
-  Glossary Section ``D''
-DEFUN
-  Macro DEFUN
-DEFVAR
-  Macro DEFPARAMETER, DEFVAR
-DELETE
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-DELETE-DUPLICATES
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-DELETE-FILE
-  Function DELETE-FILE
-DELETE-IF
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-DELETE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-DELETE-PACKAGE
-  Function DELETE-PACKAGE
-DENOMINATOR
-  Function NUMERATOR, DENOMINATOR
-denormalized
-  Glossary Section ``D''
-DEPOSIT-FIELD
-  Function DEPOSIT-FIELD
-derived type
-  Glossary Section ``D''
-derived type specifier
-  Type Specifiers
-  Glossary Section ``D''
-DESCRIBE
-  Function DESCRIBE
-DESCRIBE-OBJECT
-  Standard Generic Function DESCRIBE-OBJECT
-:description
-  Macro DEFINE-METHOD-COMBINATION
-designator
-  Glossary Section ``D''
-destructive
-  Glossary Section ``D''
-destructuring lambda list
-  Glossary Section ``D''
-DESTRUCTURING-BIND
-  Macro DESTRUCTURING-BIND
-:device
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-different
-  Glossary Section ``D''
-digit
-  Glossary Section ``D''
-digit-char
-  Removed Argument Conventions
-DIGIT-CHAR
-  Function DIGIT-CHAR
-DIGIT-CHAR-P
-  Function DIGIT-CHAR-P
-dimension
-  Glossary Section ``D''
-direct instance
-  Glossary Section ``D''
-direct subclass
-  Glossary Section ``D''
-direct superclass
-  Glossary Section ``D''
-:direction
-  Function OPEN
-  Glossary Section ``C''
-DIRECTORY
-  Function DIRECTORY
-:directory
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-DIRECTORY-NAMESTRING
-  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
-DISASSEMBLE
-  Function DISASSEMBLE
-disestablish
-  Glossary Section ``D''
-disjoint
-  Glossary Section ``D''
-dispatching macro character
-  Glossary Section ``D''
-displaced array
-  Glossary Section ``D''
-:displaced-index-offset
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function ARRAY-DISPLACEMENT
-:displaced-to
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function ARRAY-DISPLACEMENT
-distinct
-  Glossary Section ``D''
-DIVISION-BY-ZERO
-  Condition Type DIVISION-BY-ZERO
-DO
-  Macro DO, DO*
-do (loop keyword)
-  Parsing Loop Clauses
-  Summary of Unconditional Execution Clauses
-  Unconditional Execution Clauses
-  Macro LOOP
-DO*
-  Macro DO, DO*
-DO-ALL-SYMBOLS
-  Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
-DO-EXTERNAL-SYMBOLS
-  Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
-DO-SYMBOLS
-  Macro DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS
-DOCUMENTATION
-  Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)
-:documentation
-  Inheritance of Slots and Slot Options
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFCLASS
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-  Macro DEFINE-CONDITION
-  Macro DEFPACKAGE
-documentation string
-  Glossary Section ``D''
-doing (loop keyword)
-  Parsing Loop Clauses
-  Summary of Unconditional Execution Clauses
-  Unconditional Execution Clauses
-  Macro LOOP
-DOLIST
-  Macro DOLIST
-Dollarsign (format directive)
-  Tilde Dollarsign: Monetary Floating-Point
-dot
-  Left-Parenthesis
-  Local Macro PPRINT-POP
-  Glossary Section ``D''
-Dot (sharpsign reader macro)
-  Sharpsign Dot
-Dot Dot
-  Re-Reading Abbreviated Expressions
-  Variable *PRINT-LINES*
-Dot Dot Dot
-  Re-Reading Abbreviated Expressions
-  Local Macro PPRINT-POP
-DOTIMES
-  Macro DOTIMES
-dotted list
-  Glossary Section ``D''
-dotted pair
-  Glossary Section ``D''
-double float
-  Glossary Section ``D''
-DOUBLE-FLOAT
-  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
-DOUBLE-FLOAT-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-DOUBLE-FLOAT-NEGATIVE-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-double-quote
-  Glossary Section ``D''
-Double-Quote (reader macro)
-  Double-Quote
-:downcase
-  Effect of Readtable Case on the Lisp Printer
-  Variable *PRINT-CASE*
-  Effect of Readtable Case on the Lisp Reader
-  Glossary Section ``C''
-downfrom (loop keyword)
-  The for-as-arithmetic subclause
-  Macro LOOP
-downto (loop keyword)
-  The for-as-arithmetic subclause
-  Macro LOOP
-DPB
-  Function DPB
-:draft-ansi-cl
-  Variable *FEATURES*
-:draft-ansi-cl-2
-  Variable *FEATURES*
-DRIBBLE
-  Function DRIBBLE
-dynamic binding
-  Glossary Section ``D''
-dynamic environment
-  Glossary Section ``D''
-dynamic extent
-  Glossary Section ``D''
-dynamic scope
-  Glossary Section ``D''
-dynamic variable
-  Glossary Section ``D''
-DYNAMIC-EXTENT
-  Declaration DYNAMIC-EXTENT
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_E.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_E.htm deleted file mode 100644 index 35adbc60..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_E.htm +++ /dev/null @@ -1,292 +0,0 @@ - - - -CLHS: Index - E - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - E

    - -
    -E (format directive)
-  Tilde E: Exponential Floating-Point
-each (loop keyword)
-  The for-as-hash subclause
-  The for-as-package subclause
-  Macro LOOP
-ECASE
-  Macro CASE, CCASE, ECASE
-echo stream
-  Glossary Section ``E''
-ECHO-STREAM
-  System Class ECHO-STREAM
-ECHO-STREAM-INPUT-STREAM
-  Function ECHO-STREAM-INPUT-STREAM, ECHO-STREAM-OUTPUT-STREAM
-ECHO-STREAM-OUTPUT-STREAM
-  Function ECHO-STREAM-INPUT-STREAM, ECHO-STREAM-OUTPUT-STREAM
-ED
-  Function ED
-effective method
-  Glossary Section ``E''
-EIGHTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-element
-  Glossary Section ``E''
-element type
-  Glossary Section ``E''
-:element-type
-  Function TYPEP
-  Type SIMPLE-ARRAY
-  System Class VECTOR
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function MAKE-STRING
-  Function OPEN
-  Function MAKE-STRING-OUTPUT-STREAM
-  Macro WITH-OUTPUT-TO-STRING
-else (loop keyword)
-  Summary of Conditional Execution Clauses
-  Conditional Execution Clauses
-  Macro LOOP
-ELT
-  Accessor ELT
-em
-  Glossary Section ``E''
-empty list
-  Glossary Section ``E''
-empty type
-  Glossary Section ``E''
-ENCODE-UNIVERSAL-TIME
-  function ENCODE-UNIVERSAL-TIME
-:end
-  Examples of Ordinary Lambda Lists
-  Function PARSE-INTEGER
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-  Function FILL
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-  Function PARSE-NAMESTRING
-  Function WRITE-STRING, WRITE-LINE
-  Function READ-SEQUENCE
-  Function WRITE-SEQUENCE
-  Macro WITH-INPUT-FROM-STRING
-  Function READ-FROM-STRING
-  Glossary Section ``F''
-:end1
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-:end2
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-end (loop keyword)
-  Summary of Conditional Execution Clauses
-  Conditional Execution Clauses
-  Macro LOOP
-end of file
-  Glossary Section ``E''
-END-OF-FILE
-  Condition Type END-OF-FILE
-ENDP
-  Function ENDP
-ENOUGH-NAMESTRING
-  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
-ENSURE-DIRECTORIES-EXIST
-  Function ENSURE-DIRECTORIES-EXIST
-ENSURE-GENERIC-FUNCTION
-  Function ENSURE-GENERIC-FUNCTION
-environment
-  Glossary Section ``E''
-&environment
-  Macro Lambda Lists
-  Destructuring Lambda Lists
-  Defsetf Lambda Lists
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Function ENSURE-GENERIC-FUNCTION
-  Accessor FIND-CLASS
-  Glossary Section ``C''
-  Glossary Section ``D''
-:environment
-  Safe and Unsafe Calls
-  Function ENSURE-GENERIC-FUNCTION
-  Function MAKE-LOAD-FORM-SAVING-SLOTS
-environment object
-  Glossary Section ``E''
-environment parameter
-  Glossary Section ``E''
-EQ
-  Function EQ
-EQL
-  Type Specifier EQL
-  Function EQL
-EQUAL
-  Function EQUAL
-Equal-Sign (sharpsign reader macro)
-  Sharpsign Equal-Sign
-EQUALP
-  Function EQUALP
-error
-  Glossary Section ``E''
-ERROR
-  Condition Type ERROR
-  Function ERROR
-:error
-  Function OPEN
-error output
-  Glossary Section ``E''
-error terminology
-  Error Terminology
-*ERROR-OUTPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-escape
-  Glossary Section ``E''
-:escape
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-establish
-  Glossary Section ``E''
-ETYPECASE
-  Macro TYPECASE, CTYPECASE, ETYPECASE
-EVAL
-  Function EVAL
-eval
-  Sharpsign Dot
-  Special Operator EVAL-WHEN
-EVAL-WHEN
-  Special Operator EVAL-WHEN
-eval-when
-  Processing of Top Level Forms
-evaluate
-  Glossary Section ``E''
-evaluation
-  Evaluation
-  Glossary Section ``E''
-evaluation environment
-  Glossary Section ``E''
-evaluation order
-  Special Operator LOAD-TIME-VALUE
-  Evaluation of Subforms to Places
-  Special Operator CATCH
-  Macro MULTIPLE-VALUE-SETQ
-  Order of Execution
-  The for-as-arithmetic subclause
-  Defaulting of Initialization Arguments
-  Macro ASSERT
-  Accessor LDB
-EVENP
-  Function EVENP, ODDP
-EVERY
-  Function EVERY, SOME, NOTEVERY, NOTANY
-execute
-  Glossary Section ``E''
-:execute
-  File Compilation
-  Processing of Top Level Forms
-  Special Operator EVAL-WHEN
-  Function LOAD
-execution time
-  Glossary Section ``E''
-exhaustive partition
-  Glossary Section ``E''
-exhaustive union
-  Glossary Section ``E''
-exit point
-  Glossary Section ``E''
-EXP
-  Function EXP, EXPT
-:expected-type
-  Condition Type TYPE-ERROR
-explicit return
-  Glossary Section ``E''
-explicit use
-  Glossary Section ``E''
-exponent marker
-  Glossary Section ``E''
-export
-  Glossary Section ``E''
-EXPORT
-  Function EXPORT
-:export
-  Macro DEFPACKAGE
-exported
-  Glossary Section ``E''
-expressed adjustability
-  Glossary Section ``E''
-expressed array element type
-  Glossary Section ``E''
-expressed complex part type
-  Glossary Section ``E''
-expression
-  Glossary Section ``E''
-expressly adjustable
-  Glossary Section ``E''
-EXPT
-  Function EXP, EXPT
-extended character
-  Glossary Section ``E''
-extended function designator
-  Glossary Section ``E''
-extended lambda list
-  Glossary Section ``E''
-EXTENDED-CHAR
-  Type EXTENDED-CHAR
-extension
-  Glossary Section ``E''
-extensions
-  Error Terminology
-extent
-  Glossary Section ``E''
-:external
-  Function FIND-SYMBOL
-  Macro WITH-PACKAGE-ITERATOR
-  Function INTERN
-external file format
-  Glossary Section ``E''
-external file format designator
-  Glossary Section ``E''
-external symbol
-  Internal and External Symbols
-  Glossary Section ``E''
-external-symbol (loop keyword)
-  The for-as-package subclause
-  Macro LOOP
-external-symbols (loop keyword)
-  The for-as-package subclause
-  Macro LOOP
-:external-format
-  Function OPEN
-  Function STREAM-EXTERNAL-FORMAT
-  Function COMPILE-FILE
-  Function LOAD
-externalizable object
-  Externalizable Objects
-  Glossary Section ``E''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_F.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_F.htm deleted file mode 100644 index 26d3884c..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_F.htm +++ /dev/null @@ -1,285 +0,0 @@ - - - -CLHS: Index - F - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - F

    - -
    -F (format directive)
-  Tilde F: Fixed-Format Floating-Point
-false
-  Glossary Section ``F''
-fbound
-  Glossary Section ``F''
-FBOUNDP
-  Function FBOUNDP
-FCEILING
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-FDEFINITION
-  Accessor FDEFINITION
-feature
-  Glossary Section ``F''
-feature expression
-  Feature Expressions
-  Glossary Section ``F''
-*FEATURES*
-  Variable *FEATURES*
-*features*
-  Use of Read-Time Conditionals
-  Sharpsign Plus
-  Sharpsign Minus
-features list
-  Glossary Section ``F''
-FFLOOR
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-FIFTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-file
-  File System Concepts
-  Glossary Section ``F''
-file compiler
-  Glossary Section ``F''
-file position
-  Glossary Section ``F''
-file position designator
-  Glossary Section ``F''
-file stream
-  File Streams
-  Glossary Section ``F''
-file system
-  Glossary Section ``F''
-FILE-AUTHOR
-  Function FILE-AUTHOR
-FILE-ERROR
-  Condition Type FILE-ERROR
-FILE-ERROR-PATHNAME
-  Function FILE-ERROR-PATHNAME
-FILE-LENGTH
-  Function FILE-LENGTH
-FILE-NAMESTRING
-  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
-FILE-POSITION
-  Function FILE-POSITION
-FILE-STREAM
-  System Class FILE-STREAM
-FILE-STRING-LENGTH
-  Function FILE-STRING-LENGTH
-FILE-WRITE-DATE
-  Function FILE-WRITE-DATE
-filename
-  File System Concepts
-  Glossary Section ``F''
-FILL
-  Function FILL
-:fill
-  Function PPRINT-NEWLINE
-fill pointer
-  Glossary Section ``F''
-FILL-POINTER
-  Accessor FILL-POINTER
-fill-style conditional newline
-  Examples of using the Pretty Printer
-  Function PPRINT-NEWLINE
-:fill-pointer
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-finally (loop keyword)
-  Parsing Loop Clauses
-  Expanding Loop Forms
-  Summary of Miscellaneous Clauses
-  Order of Execution
-  Value Accumulation Clauses
-  Termination Test Clauses
-  Control Transfer Clauses
-  Initial and Final Execution
-  Macro LOOP
-FIND
-  Function FIND, FIND-IF, FIND-IF-NOT
-FIND-ALL-SYMBOLS
-  Function FIND-ALL-SYMBOLS
-FIND-CLASS
-  Accessor FIND-CLASS
-FIND-IF
-  Function FIND, FIND-IF, FIND-IF-NOT
-FIND-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-FIND-METHOD
-  Standard Generic Function FIND-METHOD
-FIND-PACKAGE
-  Function FIND-PACKAGE
-FIND-RESTART
-  Function FIND-RESTART
-FIND-SYMBOL
-  Function FIND-SYMBOL
-FINISH-OUTPUT
-  Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT
-finite
-  Glossary Section ``F''
-FIRST
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-fixnum
-  Glossary Section ``F''
-FIXNUM
-  Type FIXNUM
-FLET
-  Special Operator FLET, LABELS, MACROLET
-float
-  Printing Floats
-  Glossary Section ``F''
-FLOAT
-  System Class FLOAT
-  Function FLOAT
-FLOAT-DIGITS
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-FLOAT-PRECISION
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-FLOAT-RADIX
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-FLOAT-SIGN
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-FLOATING-POINT-INEXACT
-  Condition Type FLOATING-POINT-INEXACT
-FLOATING-POINT-INVALID-OPERATION
-  Condition Type FLOATING-POINT-INVALID-OPERATION
-FLOATING-POINT-OVERFLOW
-  Condition Type FLOATING-POINT-OVERFLOW
-FLOATING-POINT-UNDERFLOW
-  Condition Type FLOATING-POINT-UNDERFLOW
-FLOATP
-  Function FLOATP
-FLOOR
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-FMAKUNBOUND
-  Function FMAKUNBOUND
-font key
-  Font Key
-foo
-  Nonsense Words
-for (loop keyword)
-  Summary of Variable Initialization and Stepping Clauses
-  Summary of Termination Test Clauses
-  Summary of Miscellaneous Clauses
-  Destructuring
-  Iteration Control
-  The for-as-arithmetic subclause
-  The for-as-in-list subclause
-  The for-as-on-list subclause
-  The for-as-equals-then subclause
-  The for-as-across subclause
-  The for-as-hash subclause
-  The for-as-package subclause
-  Initial and Final Execution
-  Macro LOOP
-for-value
-  Glossary Section ``F''
-FORCE-OUTPUT
-  Function FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT
-form
-  Glossary Section ``F''
-formal argument
-  Glossary Section ``F''
-formal parameter
-  Glossary Section ``F''
-format
-  Glossary Section ``F''
-FORMAT
-  Function FORMAT
-format argument
-  Glossary Section ``F''
-format control
-  Glossary Section ``F''
-format directive
-  Glossary Section ``F''
-format string
-  Glossary Section ``F''
-:format-arguments
-  Condition Type SIMPLE-CONDITION
-FORMATTER
-  Macro FORMATTER
-FOURTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-free declaration
-  Declaration Scope
-  Glossary Section ``F''
-fresh
-  Glossary Section ``F''
-FRESH-LINE
-  Function TERPRI, FRESH-LINE
-freshline
-  Glossary Section ``F''
-from (loop keyword)
-  Parsing Loop Clauses
-  The for-as-arithmetic subclause
-  Macro LOOP
-:from-end
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-FROUND
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-FTRUNCATE
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-FTYPE
-  Declaration FTYPE
-funbound
-  Glossary Section ``F''
-FUNCALL
-  Function FUNCALL
-FUNCTION
-  System Class FUNCTION
-  Special Operator FUNCTION
-function
-  Sharpsign Single-Quote
-  Glossary Section ``F''
-function block name
-  Glossary Section ``F''
-function cell
-  Glossary Section ``F''
-function designator
-  Glossary Section ``F''
-function form
-  Glossary Section ``F''
-function name
-  Glossary Section ``F''
-FUNCTION-KEYWORDS
-  Standard Generic Function FUNCTION-KEYWORDS
-FUNCTION-LAMBDA-EXPRESSION
-  Function FUNCTION-LAMBDA-EXPRESSION
-functional evaluation
-  Glossary Section ``F''
-functional value
-  Glossary Section ``F''
-FUNCTIONP
-  Function FUNCTIONP
-further compilation
-  Glossary Section ``F''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_G.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_G.htm deleted file mode 100644 index 5c72ea72..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_G.htm +++ /dev/null @@ -1,114 +0,0 @@ - - - -CLHS: Index - G - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - G

    - -
    -G (format directive)
-  Tilde G: General Floating-Point
-GCD
-  Function GCD
-general
-  Glossary Section ``G''
-generalized boolean
-  Glossary Section ``G''
-generalized instance
-  Glossary Section ``G''
-generalized reference
-  Glossary Section ``G''
-generalized synonym stream
-  Glossary Section ``G''
-generic function
-  Glossary Section ``G''
-generic function lambda list
-  Glossary Section ``G''
-GENERIC-FUNCTION
-  System Class GENERIC-FUNCTION
-:generic-function
-  Macro DEFINE-METHOD-COMBINATION
-:generic-function-class
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-gensym
-  Glossary Section ``G''
-GENSYM
-  Function GENSYM
-:gensym
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-*GENSYM-COUNTER*
-  Variable *GENSYM-COUNTER*
-GENTEMP
-  Function GENTEMP
-GET
-  Accessor GET
-GET-DECODED-TIME
-  Function GET-UNIVERSAL-TIME, GET-DECODED-TIME
-GET-DISPATCH-MACRO-CHARACTER
-  Function SET-DISPATCH-MACRO-CHARACTER, GET-DISPATCH-MACRO-CHARACTER
-GET-INTERNAL-REAL-TIME
-  Function GET-INTERNAL-REAL-TIME
-GET-INTERNAL-RUN-TIME
-  Function GET-INTERNAL-RUN-TIME
-GET-MACRO-CHARACTER
-  Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER
-GET-OUTPUT-STREAM-STRING
-  Function GET-OUTPUT-STREAM-STRING
-GET-PROPERTIES
-  Function GET-PROPERTIES
-GET-SETF-EXPANSION
-  Function GET-SETF-EXPANSION
-GET-UNIVERSAL-TIME
-  Function GET-UNIVERSAL-TIME, GET-DECODED-TIME
-GETF
-  Accessor GETF
-GETHASH
-  Accessor GETHASH
-global declaration
-  Declarations
-  Glossary Section ``G''
-global environment
-  Glossary Section ``G''
-global variable
-  Glossary Section ``G''
-glyph
-  Glossary Section ``G''
-go
-  Glossary Section ``G''
-GO
-  Special Operator GO
-go point
-  Glossary Section ``G''
-go tag
-  Glossary Section ``G''
-graphic
-  Glossary Section ``G''
-GRAPHIC-CHAR-P
-  Function GRAPHIC-CHAR-P
-Greater-Than-Sign (format directive)
-  Tilde Greater-Than-Sign: End of Justification
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_H.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_H.htm deleted file mode 100644 index 489a286d..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_H.htm +++ /dev/null @@ -1,74 +0,0 @@ - - - -CLHS: Index - H - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - H

    - -
    -handle
-  Glossary Section ``H''
-handler
-  Glossary Section ``H''
-HANDLER-BIND
-  Macro HANDLER-BIND
-HANDLER-CASE
-  Macro HANDLER-CASE
-hash table
-  Glossary Section ``H''
-hash-key (loop keyword)
-  The for-as-hash subclause
-  Macro LOOP
-hash-keys (loop keyword)
-  The for-as-hash subclause
-  Macro LOOP
-HASH-TABLE
-  System Class HASH-TABLE
-HASH-TABLE-COUNT
-  Function HASH-TABLE-COUNT
-HASH-TABLE-P
-  Function HASH-TABLE-P
-HASH-TABLE-REHASH-SIZE
-  Function HASH-TABLE-REHASH-SIZE
-HASH-TABLE-REHASH-THRESHOLD
-  Function HASH-TABLE-REHASH-THRESHOLD
-HASH-TABLE-SIZE
-  Function HASH-TABLE-SIZE
-HASH-TABLE-TEST
-  Function HASH-TABLE-TEST
-hash-value (loop keyword)
-  The for-as-hash subclause
-  Macro LOOP
-hash-values (loop keyword)
-  The for-as-hash subclause
-  Macro LOOP
-home package
-  Glossary Section ``H''
-:host
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-HOST-NAMESTRING
-  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_I.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_I.htm deleted file mode 100644 index 7b1a4cb8..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_I.htm +++ /dev/null @@ -1,298 +0,0 @@ - - - -CLHS: Index - I - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - I

    - -
    -I (format directive)
-  Tilde I: Indent
-I/O customization variable
-  Glossary Section ``I''
-identical
-  Glossary Section ``I''
-identifier
-  Glossary Section ``I''
-IDENTITY
-  Function IDENTITY
-:identity
-  Macro PRINT-UNREADABLE-OBJECT
-:identity-with-one-argument
-  Macro DEFINE-METHOD-COMBINATION
-:ieee-floating-point
-  Variable *FEATURES*
-IF
-  Special Operator IF
-if (loop keyword)
-  Summary of Conditional Execution Clauses
-  Conditional Execution Clauses
-  Macro LOOP
-:if-does-not-exist
-  Function OPEN
-  Function LOAD
-:if-exists
-  Function OPEN
-IGNORABLE
-  Declaration IGNORE, IGNORABLE
-IGNORE
-  Declaration IGNORE, IGNORABLE
-IGNORE-ERRORS
-  Macro IGNORE-ERRORS
-IMAGPART
-  Function REALPART, IMAGPART
-immutable
-  Glossary Section ``I''
-implementation
-  Glossary Section ``I''
-implementation limit
-  Glossary Section ``I''
-implementation-defined
-  Glossary Section ``I''
-implementation-dependent
-  Glossary Section ``I''
-implementation-independent
-  Glossary Section ``I''
-implicit block
-  Glossary Section ``I''
-implicit compilation
-  Glossary Section ``I''
-implicit progn
-  Glossary Section ``I''
-implicit tagbody
-  Glossary Section ``I''
-import
-  Glossary Section ``I''
-IMPORT
-  Function IMPORT
-:import-from
-  Macro DEFPACKAGE
-improper list
-  Glossary Section ``I''
-in (loop keyword)
-  The for-as-in-list subclause
-  The for-as-hash subclause
-  The for-as-package subclause
-  Macro LOOP
-IN-PACKAGE
-  Macro IN-PACKAGE
-inaccessible
-  Glossary Section ``I''
-INCF
-  Macro INCF, DECF
-:include
-  Type Relationships
-  Integrating Types and Classes
-  Macro DEFSTRUCT
-indefinite extent
-  Glossary Section ``I''
-indefinite scope
-  Glossary Section ``I''
-:index
-  Macro WITH-INPUT-FROM-STRING
-indicator
-  Glossary Section ``I''
-indirect instance
-  Glossary Section ``I''
-inherit
-  Glossary Section ``I''
-:inherited
-  Function FIND-SYMBOL
-  Macro WITH-PACKAGE-ITERATOR
-  Function INTERN
-:initarg
-  Object Creation and Initialization
-  Declaring the Validity of Initialization Arguments
-  Rules for Initialization Arguments
-  Definitions of Make-Instance and Initialize-Instance
-  Inheritance of Slots and Slot Options
-  Standard Generic Function REINITIALIZE-INSTANCE
-  Standard Generic Function SHARED-INITIALIZE
-  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
-  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-:init-form
-  Macro DEFCLASS
-:initform
-  Object Creation and Initialization
-  Initialization Arguments
-  Defaulting of Initialization Arguments
-  Rules for Initialization Arguments
-  Shared-Initialize
-  Initialize-Instance
-  Definitions of Make-Instance and Initialize-Instance
-  Reinitializing an Instance
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Standard Generic Function SHARED-INITIALIZE
-  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
-  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
-  Standard Generic Function SLOT-UNBOUND
-  Macro DEFCLASS
-  Standard Generic Function INITIALIZE-INSTANCE
-  Macro DEFINE-CONDITION
-  Glossary Section ``I''
-initial pprint dispatch table
-  Glossary Section ``I''
-initial readtable
-  Glossary Section ``I''
-:initial-contents
-  Sharpsign A
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Printing Other Arrays
-:initial-element
-  Function MAKE-LIST
-  Function MAKE-ARRAY
-  Function ADJUST-ARRAY
-  Function MAKE-STRING
-  Function MAKE-SEQUENCE
-initialization argument list
-  Glossary Section ``I''
-initialization form
-  Glossary Section ``I''
-INITIALIZE-INSTANCE
-  Standard Generic Function INITIALIZE-INSTANCE
-initially (loop keyword)
-  Parsing Loop Clauses
-  Expanding Loop Forms
-  Summary of Miscellaneous Clauses
-  Order of Execution
-  Iteration Control
-  Initial and Final Execution
-  Macro LOOP
-:initial-offset
-  Macro DEFSTRUCT
-:initial-value
-  Function REDUCE
-INLINE
-  Declaration INLINE, NOTINLINE
-input
-  Glossary Section ``I''
-:input
-  Function OPEN
-INPUT-STREAM-P
-  Function INPUT-STREAM-P, OUTPUT-STREAM-P
-INSPECT
-  Function INSPECT
-:installed
-  Glossary Section ``V''
-instance
-  Introduction to Classes
-  Glossary Section ``I''
-:instance
-  Introduction to Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-int-char
-  Removed Operators
-integer
-  Glossary Section ``I''
-INTEGER
-  System Class INTEGER
-INTEGER-DECODE-FLOAT
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-INTEGER-LENGTH
-  Function INTEGER-LENGTH
-INTEGERP
-  Function INTEGERP
-:interactive
-  Interactive Use of Restarts
-  Function INVOKE-RESTART-INTERACTIVELY
-  Macro RESTART-CASE
-interactive stream
-  Glossary Section ``I''
-INTERACTIVE-STREAM-P
-  Function INTERACTIVE-STREAM-P
-:interactive-function
-  Interactive Use of Restarts
-  Function INVOKE-RESTART-INTERACTIVELY
-  Macro RESTART-BIND
-intern
-  Glossary Section ``I''
-INTERN
-  Function INTERN
-:intern
-  Macro DEFPACKAGE
-:internal
-  Function FIND-SYMBOL
-  Macro WITH-PACKAGE-ITERATOR
-  Function INTERN
-internal symbol
-  Internal and External Symbols
-  Glossary Section ``I''
-internal time
-  Internal Time
-  Glossary Section ``I''
-internal time unit
-  Glossary Section ``I''
-INTERNAL-TIME-UNITS-PER-SECOND
-  Constant Variable INTERNAL-TIME-UNITS-PER-SECOND
-interned
-  Glossary Section ``I''
-interpreted function
-  Glossary Section ``I''
-interpreted implementation
-  Glossary Section ``I''
-INTERSECTION
-  Function INTERSECTION, NINTERSECTION
-interval designator
-  Glossary Section ``I''
-into (loop keyword)
-  Local Variable Initializations
-  Value Accumulation Clauses
-  Termination Test Clauses
-  Macro LOOP
-invalid
-  Glossary Section ``I''
-INVALID-METHOD-ERROR
-  Function INVALID-METHOD-ERROR
-:invert
-  Effect of Readtable Case on the Lisp Printer
-  Effect of Readtable Case on the Lisp Reader
-  Glossary Section ``C''
-INVOKE-DEBUGGER
-  Function INVOKE-DEBUGGER
-INVOKE-RESTART
-  Function INVOKE-RESTART
-INVOKE-RESTART-INTERACTIVELY
-  Function INVOKE-RESTART-INTERACTIVELY
-:io
-  Function OPEN
-is signaled
-  Error Terminology
-ISQRT
-  Function SQRT, ISQRT
-it (loop keyword)
-  Conditional Execution Clauses
-  Notes about Loop
-  Macro LOOP
-iteration form
-  Glossary Section ``I''
-iteration variable
-  Glossary Section ``I''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_J.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_J.htm deleted file mode 100644 index ec0a9539..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_J.htm +++ /dev/null @@ -1,34 +0,0 @@ - - - -CLHS: Index - J - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - J

    - -
    -:junk-allowed
-  Function PARSE-INTEGER
-  Function PARSE-NAMESTRING
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_K.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_K.htm deleted file mode 100644 index e0e726b4..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_K.htm +++ /dev/null @@ -1,88 +0,0 @@ - - - -CLHS: Index - K - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - K

    - -
    -key
-  Glossary Section ``K''
-&key
-  Ordinary Lambda Lists
-  Specifiers for keyword parameters
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Too Many Arguments
-  System Class FUNCTION
-  Type Specifier VALUES
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Initialization Arguments
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Keyword Arguments in Generic Functions and Methods
-  Macro DEFINE-METHOD-COMBINATION
-:key
-  Function SUBLIS, NSUBLIS
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-  Function INTERSECTION, NINTERSECTION
-  Function ADJOIN
-  Macro PUSHNEW
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-  Function SUBSETP
-  Function UNION, NUNION
-  Satisfying a Two-Argument Test
-  Satisfying a One-Argument Test
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function SORT, STABLE-SORT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function MERGE
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-keyword
-  Glossary Section ``K''
-KEYWORD
-  Type KEYWORD
-  The KEYWORD Package
-keyword parameter
-  Glossary Section ``K''
-keyword/value pair
-  Glossary Section ``K''
-KEYWORDP
-  Function KEYWORDP
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_L.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_L.htm deleted file mode 100644 index 251fcf52..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_L.htm +++ /dev/null @@ -1,298 +0,0 @@ - - - -CLHS: Index - L - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - L

    - -
    -LABELS
-  Special Operator FLET, LABELS, MACROLET
-LAMBDA
-  Symbol LAMBDA
-  Macro LAMBDA
-lambda combination
-  Glossary Section ``L''
-lambda expression
-  Glossary Section ``L''
-lambda form
-  Glossary Section ``L''
-lambda list
-  Glossary Section ``L''
-lambda list keyword
-  Glossary Section ``L''
-lambda variable
-  Glossary Section ``L''
-LAMBDA-LIST-KEYWORDS
-  Constant Variable LAMBDA-LIST-KEYWORDS
-LAMBDA-PARAMETERS-LIMIT
-  Constant Variable LAMBDA-PARAMETERS-LIMIT
-:lambda-list
-  Function ENSURE-GENERIC-FUNCTION
-LAST
-  Function LAST
-LCM
-  Function LCM
-LDB
-  Accessor LDB
-LDB-TEST
-  Function LDB-TEST
-LDIFF
-  Function LDIFF, TAILP
-leaf
-  Glossary Section ``L''
-leap seconds
-  Glossary Section ``L''
-LEAST-NEGATIVE-DOUBLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-LONG-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-SHORT-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-NEGATIVE-SINGLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-DOUBLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-LONG-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-NORMALIZED-LONG-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-SHORT-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-LEAST-POSITIVE-SINGLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-Left-Brace (format directive)
-  Tilde Left-Brace: Iteration
-Left-Bracket (format directive)
-  Tilde Left-Bracket: Conditional Expression
-Left-Paren (format directive)
-  Tilde Left-Paren: Case Conversion
-left-parenthesis
-  Glossary Section ``L''
-Left-Parenthesis (reader macro)
-  Left-Parenthesis
-Left-Parenthesis (sharpsign reader macro)
-  Sharpsign Left-Parenthesis
-length
-  Glossary Section ``L''
-LENGTH
-  Function LENGTH
-:length
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-Less-Than-Sign (format directive)
-  Tilde Less-Than-Sign: Logical Block
-  Tilde Less-Than-Sign: Justification
-Less-Than-Sign (sharpsign reader macro)
-  Sharpsign Less-Than-Sign
-LET
-  Special Operator LET, LET*
-LET*
-  Special Operator LET, LET*
-:level
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-lexical binding
-  Glossary Section ``L''
-lexical closure
-  Glossary Section ``L''
-lexical environment
-  Glossary Section ``L''
-lexical scope
-  Glossary Section ``L''
-lexical variable
-  Glossary Section ``L''
-:line
-  Function PPRINT-TAB
-:linear
-  Function PPRINT-NEWLINE
-linear-style conditional newline
-  Examples of using the Pretty Printer
-  Function PPRINT-NEWLINE
-:line-relative
-  Function PPRINT-TAB
-:lines
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-LISP
-  Packages No Longer Required
-Lisp image
-  Glossary Section ``L''
-Lisp printer
-  Glossary Section ``L''
-Lisp read-eval-print loop
-  Glossary Section ``L''
-Lisp reader
-  Glossary Section ``L''
-LISP-IMPLEMENTATION-TYPE
-  Function LISP-IMPLEMENTATION-TYPE, LISP-IMPLEMENTATION-VERSION
-LISP-IMPLEMENTATION-VERSION
-  Function LISP-IMPLEMENTATION-TYPE, LISP-IMPLEMENTATION-VERSION
-LIST
-  System Class LIST
-  Function LIST, LIST*
-list
-  Left-Parenthesis
-  Backquote
-  Comma
-  Built-in Method Combination Types
-  Glossary Section ``L''
-list designator
-  Glossary Section ``L''
-list structure
-  Glossary Section ``L''
-LIST*
-  Function LIST, LIST*
-LIST-ALL-PACKAGES
-  Function LIST-ALL-PACKAGES
-LIST-LENGTH
-  Function LIST-LENGTH
-LISTEN
-  Function LISTEN
-LISTP
-  Function LISTP
-literal
-  Glossary Section ``L''
-LOAD
-  Function LOAD
-load
-  Special Operator EVAL-WHEN
-  Glossary Section ``L''
-load time
-  Glossary Section ``L''
-load time value
-  Glossary Section ``L''
-LOAD-LOGICAL-PATHNAME-TRANSLATIONS
-  Function LOAD-LOGICAL-PATHNAME-TRANSLATIONS
-LOAD-TIME-VALUE
-  Special Operator LOAD-TIME-VALUE
-load-time-value
-  Minimal Compilation
-loader
-  Glossary Section ``L''
-*LOAD-PATHNAME*
-  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
-*LOAD-PRINT*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-:load-toplevel
-  File Compilation
-  Processing of Top Level Forms
-  Special Operator EVAL-WHEN
-*LOAD-TRUENAME*
-  Variable *LOAD-PATHNAME*, *LOAD-TRUENAME*
-*LOAD-VERBOSE*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-:local
-  Local Case in Pathname Components
-  Common Case in Pathname Components
-  Function MAKE-PATHNAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-local declaration
-  Declarations
-  Glossary Section ``L''
-local precedence order
-  Glossary Section ``L''
-local slot
-  Glossary Section ``L''
-LOCALLY
-  Special Operator LOCALLY
-LOG
-  Function LOG
-LOGAND
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGANDC1
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGANDC2
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGBITP
-  Function LOGBITP
-LOGCOUNT
-  Function LOGCOUNT
-LOGEQV
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-logical block
-  Glossary Section ``L''
-logical host
-  Glossary Section ``L''
-logical host designator
-  Glossary Section ``L''
-logical pathname
-  Glossary Section ``L''
-LOGICAL-PATHNAME
-  System Class LOGICAL-PATHNAME
-  Function LOGICAL-PATHNAME
-LOGICAL-PATHNAME-TRANSLATIONS
-  Accessor LOGICAL-PATHNAME-TRANSLATIONS
-LOGIOR
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGNAND
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGNOR
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGNOT
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGORC1
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGORC2
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-LOGTEST
-  Function LOGTEST
-LOGXOR
-  Function LOGAND, LOGANDC1, LOGANDC2, LOGEQV, LOGIOR, LOGNAND, LOGNOR, LOGNOT, LOGORC1, LOGORC2, LOGXOR
-long float
-  Glossary Section ``L''
-LONG-FLOAT
-  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
-LONG-FLOAT-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-LONG-FLOAT-NEGATIVE-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-LONG-SITE-NAME
-  Function SHORT-SITE-NAME, LONG-SITE-NAME
-LOOP
-  Macro LOOP
-loop keyword
-  Glossary Section ``L''
-LOOP-FINISH
-  Local Macro LOOP-FINISH
-LOWER-CASE-P
-  Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P
-lowercase
-  Glossary Section ``L''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_M.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_M.htm deleted file mode 100644 index 8715ac67..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_M.htm +++ /dev/null @@ -1,292 +0,0 @@ - - - -CLHS: Index - M - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - M

    - -
    -MACHINE-INSTANCE
-  Function MACHINE-INSTANCE
-MACHINE-TYPE
-  Function MACHINE-TYPE
-MACHINE-VERSION
-  Function MACHINE-VERSION
-macro
-  Minimal Compilation
-  Glossary Section ``M''
-macro character
-  Glossary Section ``M''
-macro expansion
-  Glossary Section ``M''
-macro form
-  Glossary Section ``M''
-macro function
-  Glossary Section ``M''
-macro lambda list
-  Glossary Section ``M''
-macro name
-  Glossary Section ``M''
-MACRO-FUNCTION
-  Accessor MACRO-FUNCTION
-MACROEXPAND
-  Function MACROEXPAND, MACROEXPAND-1
-macroexpand hook
-  Glossary Section ``M''
-MACROEXPAND-1
-  Function MACROEXPAND, MACROEXPAND-1
-*MACROEXPAND-HOOK*
-  Variable *MACROEXPAND-HOOK*
-MACROLET
-  Special Operator FLET, LABELS, MACROLET
-macrolet
-  Minimal Compilation
-MAKE-ARRAY
-  Function MAKE-ARRAY
-MAKE-BROADCAST-STREAM
-  Function MAKE-BROADCAST-STREAM
-make-char
-  Removed Operators
-MAKE-CONCATENATED-STREAM
-  Function MAKE-CONCATENATED-STREAM
-MAKE-CONDITION
-  Function MAKE-CONDITION
-MAKE-DISPATCH-MACRO-CHARACTER
-  Function MAKE-DISPATCH-MACRO-CHARACTER
-MAKE-ECHO-STREAM
-  Function MAKE-ECHO-STREAM
-MAKE-HASH-TABLE
-  Function MAKE-HASH-TABLE
-MAKE-INSTANCE
-  Standard Generic Function MAKE-INSTANCE
-MAKE-INSTANCES-OBSOLETE
-  Standard Generic Function MAKE-INSTANCES-OBSOLETE
-MAKE-LIST
-  Function MAKE-LIST
-MAKE-LOAD-FORM
-  Standard Generic Function MAKE-LOAD-FORM
-MAKE-LOAD-FORM-SAVING-SLOTS
-  Function MAKE-LOAD-FORM-SAVING-SLOTS
-MAKE-METHOD
-  Local Macro CALL-METHOD, MAKE-METHOD
-MAKE-PACKAGE
-  Function MAKE-PACKAGE
-MAKE-PATHNAME
-  Function MAKE-PATHNAME
-MAKE-RANDOM-STATE
-  Function MAKE-RANDOM-STATE
-MAKE-SEQUENCE
-  Function MAKE-SEQUENCE
-MAKE-STRING
-  Function MAKE-STRING
-MAKE-STRING-INPUT-STREAM
-  Function MAKE-STRING-INPUT-STREAM
-MAKE-STRING-OUTPUT-STREAM
-  Function MAKE-STRING-OUTPUT-STREAM
-MAKE-SYMBOL
-  Function MAKE-SYMBOL
-MAKE-SYNONYM-STREAM
-  Function MAKE-SYNONYM-STREAM
-MAKE-TWO-WAY-STREAM
-  Function MAKE-TWO-WAY-STREAM
-MAKUNBOUND
-  Function MAKUNBOUND
-:mandatory
-  Function PPRINT-NEWLINE
-mandatory-style conditional newline
-  Function PPRINT-NEWLINE
-MAP
-  Function MAP
-MAP-INTO
-  Function MAP-INTO
-MAPC
-  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
-MAPCAN
-  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
-MAPCAR
-  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
-MAPCON
-  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
-MAPHASH
-  Function MAPHASH
-MAPL
-  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
-MAPLIST
-  Function MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON
-mapping
-  Glossary Section ``M''
-MASK-FIELD
-  Accessor MASK-FIELD
-MAX
-  Function MAX, MIN
-max
-  Built-in Method Combination Types
-maximize (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-maximizing (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-MEMBER
-  Type Specifier MEMBER
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-MEMBER-IF
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-MEMBER-IF-NOT
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-MERGE
-  Function MERGE
-MERGE-PATHNAMES
-  Function MERGE-PATHNAMES
-metaclass
-  Glossary Section ``M''
-:metaclass
-  Defining Classes
-  Macro DEFCLASS
-Metaobject Protocol
-  Glossary Section ``M''
-method
-  Glossary Section ``M''
-METHOD
-  System Class METHOD
-:method
-  Macro DEFGENERIC
-method combination
-  Glossary Section ``M''
-METHOD-COMBINATION
-  System Class METHOD-COMBINATION
-METHOD-COMBINATION-ERROR
-  Function METHOD-COMBINATION-ERROR
-method-defining form
-  Glossary Section ``M''
-method-defining operator
-  Introduction to Generic Functions
-  Glossary Section ``M''
-METHOD-QUALIFIERS
-  Standard Generic Function METHOD-QUALIFIERS
-:method-class
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-:method-combination
-  Applying method combination to the sorted list of applicable methods
-  Built-in Method Combination Types
-  Function ENSURE-GENERIC-FUNCTION
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-might signal
-  Error Terminology
-MIN
-  Function MAX, MIN
-min
-  Built-in Method Combination Types
-minimal compilation
-  Glossary Section ``M''
-minimize (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-minimizing (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-Minus (sharpsign reader macro)
-  Sharpsign Minus
-MINUSP
-  Function MINUSP, PLUSP
-:miser
-  Function PPRINT-NEWLINE
-miser-style conditional newline
-  Examples of using the Pretty Printer
-  Function PPRINT-NEWLINE
-:miser-width
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-MISMATCH
-  Function MISMATCH
-MOD
-  Type Specifier MOD
-  Function MOD, REM
-modified lambda list
-  Glossary Section ``M''
-*MODULES*
-  Variable *MODULES*
-most recent
-  Glossary Section ``M''
-MOST-NEGATIVE-DOUBLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-NEGATIVE-FIXNUM
-  Constant Variable MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM
-MOST-NEGATIVE-LONG-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-NEGATIVE-SHORT-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-NEGATIVE-SINGLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-POSITIVE-DOUBLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-POSITIVE-FIXNUM
-  Constant Variable MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM
-MOST-POSITIVE-LONG-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-POSITIVE-SHORT-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-MOST-POSITIVE-SINGLE-FLOAT
-  Constant Variable MOST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-SHORT-FLOAT, LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT, MOST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-DOUBLE-FLOAT, LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT, MOST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-LONG-FLOAT, LEAST-POSITIVE-NORMALIZED-LONG-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-SINGLE-FLOAT, LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT, LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT, MOST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT, MOST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-DOUBLE-FLOAT, LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, MOST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-LONG-FLOAT, LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
-:most-specific-first
-  Built-in Method Combination Types
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-:most-specific-last
-  Built-in Method Combination Types
-  Macro DEFGENERIC
-  Macro DEFINE-METHOD-COMBINATION
-muffle-warning
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-MUFFLE-WARNING
-  Restart MUFFLE-WARNING
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-multiple escape
-  Glossary Section ``M''
-multiple values
-  Glossary Section ``M''
-MULTIPLE-VALUE-BIND
-  Macro MULTIPLE-VALUE-BIND
-MULTIPLE-VALUE-CALL
-  Special Operator MULTIPLE-VALUE-CALL
-MULTIPLE-VALUE-LIST
-  Macro MULTIPLE-VALUE-LIST
-MULTIPLE-VALUE-PROG1
-  Special Operator MULTIPLE-VALUE-PROG1
-MULTIPLE-VALUE-SETQ
-  Macro MULTIPLE-VALUE-SETQ
-MULTIPLE-VALUES-LIMIT
-  Constant Variable MULTIPLE-VALUES-LIMIT
-must signal
-  Error Terminology
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_N.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_N.htm deleted file mode 100644 index 376a74e7..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_N.htm +++ /dev/null @@ -1,214 +0,0 @@ - - - -CLHS: Index - N - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - N

    - -
    -name
-  Glossary Section ``N''
-:name
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-NAME-CHAR
-  Function NAME-CHAR
-:named
-  Macro DEFSTRUCT
-named (loop keyword)
-  Expanding Loop Forms
-  Summary of Unconditional Execution Clauses
-  Summary of Miscellaneous Clauses
-  Iteration Control
-  Unconditional Execution Clauses
-  Control Transfer Clauses
-  Initial and Final Execution
-  Macro LOOP
-named constant
-  Glossary Section ``N''
-namespace
-  Introduction to Environments
-  Glossary Section ``N''
-namestring
-  Glossary Section ``N''
-NAMESTRING
-  Function NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING
-NBUTLAST
-  Function BUTLAST, NBUTLAST
-NCONC
-  Function NCONC
-nconc
-  Built-in Method Combination Types
-nconc (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-nconcing (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-never (loop keyword)
-  Summary of Termination Test Clauses
-  Termination Test Clauses
-  Initial and Final Execution
-  Macro LOOP
-:newest
-  Pathnames as Filenames
-  The Pathname Version Component
-  Restrictions on Examining a Pathname Version Component
-  Restrictions on Constructing Pathnames
-  Function MERGE-PATHNAMES
-  Examples of Truenames
-  Function OPEN
-  Glossary Section ``V''
-newline
-  Glossary Section ``N''
-Newline (format directive)
-  Tilde Newline: Ignored Newline
-:new-version
-  Function OPEN
-next method
-  Glossary Section ``N''
-NEXT-METHOD-P
-  Local Function NEXT-METHOD-P
-nickname
-  Glossary Section ``N''
-:nicknames
-  Function MAKE-PACKAGE
-  Macro DEFPACKAGE
-NIL
-  Type NIL
-  Constant Variable NIL
-nil
-  NIL
-  Glossary Section ``N''
-NINTERSECTION
-  Function INTERSECTION, NINTERSECTION
-NINTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-NO-APPLICABLE-METHOD
-  Standard Generic Function NO-APPLICABLE-METHOD
-NO-NEXT-METHOD
-  Standard Generic Function NO-NEXT-METHOD
-:no-error
-  Macro HANDLER-CASE
-non-atomic
-  Glossary Section ``N''
-non-constant variable
-  Glossary Section ``N''
-non-correctable
-  Glossary Section ``N''
-non-empty
-  Glossary Section ``N''
-non-generic function
-  Glossary Section ``N''
-non-graphic
-  Glossary Section ``N''
-non-list
-  Glossary Section ``N''
-non-local exit
-  Glossary Section ``N''
-non-nil
-  Glossary Section ``N''
-non-null lexical environment
-  Glossary Section ``N''
-non-simple
-  Glossary Section ``N''
-non-terminating
-  Glossary Section ``N''
-non-top-level form
-  Glossary Section ``N''
-normal return
-  Glossary Section ``N''
-normalized
-  Glossary Section ``N''
-NOT
-  Type Specifier NOT
-  Function NOT
-NOTANY
-  Function EVERY, SOME, NOTEVERY, NOTANY
-notation
-  Notational Conventions
-NOTEVERY
-  Function EVERY, SOME, NOTEVERY, NOTANY
-NOTINLINE
-  Declaration INLINE, NOTINLINE
-notinline
-  Minimal Declaration Processing Requirements
-NRECONC
-  Function REVAPPEND, NRECONC
-NREVERSE
-  Function REVERSE, NREVERSE
-NSET-DIFFERENCE
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-NSET-EXCLUSIVE-OR
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-NSTRING-CAPITALIZE
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-NSTRING-DOWNCASE
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-NSTRING-UPCASE
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-NSUBLIS
-  Function SUBLIS, NSUBLIS
-NSUBST
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-NSUBST-IF
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-NSUBST-IF-NOT
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-NSUBSTITUTE
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-NSUBSTITUTE-IF
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-NSUBSTITUTE-IF-NOT
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-NTH
-  Accessor NTH
-NTH-VALUE
-  Macro NTH-VALUE
-NTHCDR
-  Function NTHCDR
-null
-  Glossary Section ``N''
-NULL
-  System Class NULL
-  Function NULL
-null lexical environment
-  Glossary Section ``N''
-number
-  Glossary Section ``N''
-NUMBER
-  System Class NUMBER
-NUMBERP
-  Function NUMBERP
-NUMERATOR
-  Function NUMERATOR, DENOMINATOR
-numeric
-  Glossary Section ``N''
-NUNION
-  Function UNION, NUNION
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_O.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_O.htm deleted file mode 100644 index 1a296e66..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_O.htm +++ /dev/null @@ -1,131 +0,0 @@ - - - -CLHS: Index - O - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - O

    - -
    -O (format directive)
-  Tilde O: Octal
-O (sharpsign reader macro)
-  Sharpsign O
-object
-  Glossary Section ``O''
-object-traversing
-  Glossary Section ``O''
-ODDP
-  Function EVENP, ODDP
-of (loop keyword)
-  The for-as-hash subclause
-  The for-as-package subclause
-  Macro LOOP
-of-type (loop keyword)
-  Destructuring
-  Macro LOOP
-:off
-  Notes about The KEYWORD Package
-:oldest
-  Notes about the Pathname Version Component
-  Glossary Section ``V''
-:on
-  Notes about The KEYWORD Package
-on (loop keyword)
-  The for-as-on-list subclause
-  Macro LOOP
-open
-  Glossary Section ``O''
-OPEN
-  Function OPEN
-OPEN-STREAM-P
-  Function OPEN-STREAM-P
-:operands
-  Condition Type ARITHMETIC-ERROR
-operator
-  Glossary Section ``O''
-:operator
-  Macro DEFINE-METHOD-COMBINATION
-OPTIMIZE
-  Declaration OPTIMIZE
-optimize quality
-  Glossary Section ``O''
-&optional
-  Ordinary Lambda Lists
-  Specifiers for optional parameters
-  Specifiers for keyword parameters
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-modify-macro Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  System Class FUNCTION
-  Type Specifier VALUES
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Macro SETF, PSETF
-optional parameter
-  Glossary Section ``O''
-or
-  Built-in Method Combination Types
-OR
-  Type Specifier OR
-  Macro OR
-:order
-  Macro DEFINE-METHOD-COMBINATION
-order of evaluation
-  Special Operator LOAD-TIME-VALUE
-  Evaluation of Subforms to Places
-  Special Operator CATCH
-  Macro MULTIPLE-VALUE-SETQ
-  Order of Execution
-  The for-as-arithmetic subclause
-  Defaulting of Initialization Arguments
-  Macro ASSERT
-  Accessor LDB
-ordinary function
-  Glossary Section ``O''
-ordinary lambda list
-  Glossary Section ``O''
-otherwise
-  Macro CASE, CCASE, ECASE
-  Macro TYPECASE, CTYPECASE, ETYPECASE
-otherwise inaccessible part
-  Glossary Section ``O''
-output
-  Glossary Section ``O''
-:output
-  Function OPEN
-OUTPUT-STREAM-P
-  Function INPUT-STREAM-P, OUTPUT-STREAM-P
-:output-file
-  Function COMPILE-FILE
-  Function COMPILE-FILE-PATHNAME
-:override
-  Macro WITH-COMPILATION-UNIT
-:overwrite
-  Function OPEN
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_P.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_P.htm deleted file mode 100644 index 00e32b84..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_P.htm +++ /dev/null @@ -1,354 +0,0 @@ - - - -CLHS: Index - P - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - P

    - -
    -P (format directive)
-  Tilde P: Plural
-P (sharpsign reader macro)
-  Sharpsign P
-package
-  Glossary Section ``P''
-PACKAGE
-  System Class PACKAGE
-*PACKAGE*
-  Variable *PACKAGE*
-package cell
-  Glossary Section ``P''
-package designator
-  Glossary Section ``P''
-package marker
-  Glossary Section ``P''
-package prefix
-  Glossary Section ``P''
-package registry
-  Glossary Section ``P''
-PACKAGE-ERROR
-  Condition Type PACKAGE-ERROR
-PACKAGE-ERROR-PACKAGE
-  Function PACKAGE-ERROR-PACKAGE
-PACKAGE-NAME
-  Function PACKAGE-NAME
-PACKAGE-NICKNAMES
-  Function PACKAGE-NICKNAMES
-PACKAGE-SHADOWING-SYMBOLS
-  Function PACKAGE-SHADOWING-SYMBOLS
-PACKAGE-USE-LIST
-  Function PACKAGE-USE-LIST
-PACKAGE-USED-BY-LIST
-  Function PACKAGE-USED-BY-LIST
-PACKAGEP
-  Function PACKAGEP
-PAIRLIS
-  Function PAIRLIS
-pairwise
-  Glossary Section ``P''
-parallel
-  Glossary Section ``P''
-parameter
-  Glossary Section ``P''
-parameter specializer
-  Glossary Section ``P''
-parameter specializer name
-  Glossary Section ``P''
-PARSE-ERROR
-  Condition Type PARSE-ERROR
-PARSE-INTEGER
-  Function PARSE-INTEGER
-PARSE-NAMESTRING
-  Function PARSE-NAMESTRING
-PATHNAME
-  System Class PATHNAME
-  Function PATHNAME
-pathname
-  Sharpsign P
-  Pathnames as Filenames
-  Glossary Section ``P''
-pathname designator
-  Glossary Section ``P''
-PATHNAME-DEVICE
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-PATHNAME-DIRECTORY
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-PATHNAME-HOST
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-PATHNAME-MATCH-P
-  Function PATHNAME-MATCH-P
-PATHNAME-NAME
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-PATHNAME-TYPE
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-PATHNAME-VERSION
-  Function PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION
-PATHNAMEP
-  Function PATHNAMEP
-PEEK-CHAR
-  Function PEEK-CHAR
-Percent (format directive)
-  Tilde Percent: Newline
-:per-line-prefix
-  Tilde Less-Than-Sign: Logical Block
-  Macro PPRINT-LOGICAL-BLOCK
-PHASE
-  Function PHASE
-physical pathname
-  Glossary Section ``P''
-PI
-  Constant Variable PI
-:pixel-size
-  Examples of Keyword Arguments in Generic Functions and Methods
-place
-  Glossary Section ``P''
-plist
-  Glossary Section ``P''
-Plus (sharpsign reader macro)
-  Sharpsign Plus
-PLUSP
-  Function MINUSP, PLUSP
-POP
-  Macro POP
-portable
-  Glossary Section ``P''
-POSITION
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-POSITION-IF
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-POSITION-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-potential copy
-  Glossary Section ``P''
-potential number
-  Glossary Section ``P''
-PPRINT
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-pprint dispatch table
-  Glossary Section ``P''
-PPRINT-DISPATCH
-  Function PPRINT-DISPATCH
-PPRINT-EXIT-IF-LIST-EXHAUSTED
-  Local Macro PPRINT-EXIT-IF-LIST-EXHAUSTED
-PPRINT-FILL
-  Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR
-PPRINT-INDENT
-  Function PPRINT-INDENT
-PPRINT-LINEAR
-  Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR
-PPRINT-LOGICAL-BLOCK
-  Macro PPRINT-LOGICAL-BLOCK
-PPRINT-NEWLINE
-  Function PPRINT-NEWLINE
-PPRINT-POP
-  Local Macro PPRINT-POP
-PPRINT-TAB
-  Function PPRINT-TAB
-PPRINT-TABULAR
-  Function PPRINT-FILL, PPRINT-LINEAR, PPRINT-TABULAR
-:pprint-dispatch
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-predicate
-  Glossary Section ``P''
-:predicate
-  Macro DEFSTRUCT
-:prefix
-  Tilde Less-Than-Sign: Logical Block
-  Macro PPRINT-LOGICAL-BLOCK
-:pre-line-prefix
-  Macro PPRINT-LOGICAL-BLOCK
-prepared to signal
-  Error Terminology
-present
-  Glossary Section ``P''
-present-symbol (loop keyword)
-  The for-as-package subclause
-  Macro LOOP
-present-symbols (loop keyword)
-  The for-as-package subclause
-  Macro LOOP
-:preserve
-  Effect of Readtable Case on the Lisp Printer
-  Effect of Readtable Case on the Lisp Reader
-  Glossary Section ``C''
-:preserve-whitespace
-  Function READ-FROM-STRING
-:pretty
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-pretty print
-  Glossary Section ``P''
-pretty printer
-  Glossary Section ``P''
-pretty printing stream
-  Glossary Section ``P''
-:previous
-  Glossary Section ``V''
-primary method
-  Glossary Section ``P''
-primary value
-  Glossary Section ``P''
-PRIN1
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-PRIN1-TO-STRING
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-PRINC
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-PRINC-TO-STRING
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-principal
-  Glossary Section ``P''
-PRINT
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-:print
-  Function COMPILE-FILE
-  Function LOAD
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-print name
-  Glossary Section ``P''
-PRINT-NOT-READABLE
-  Condition Type PRINT-NOT-READABLE
-PRINT-NOT-READABLE-OBJECT
-  Function PRINT-NOT-READABLE-OBJECT
-PRINT-OBJECT
-  Standard Generic Function PRINT-OBJECT
-PRINT-UNREADABLE-OBJECT
-  Macro PRINT-UNREADABLE-OBJECT
-*PRINT-ARRAY*
-  Variable *PRINT-ARRAY*
-*PRINT-BASE*
-  Variable *PRINT-BASE*, *PRINT-RADIX*
-*PRINT-CASE*
-  Variable *PRINT-CASE*
-*PRINT-CIRCLE*
-  Variable *PRINT-CIRCLE*
-*print-circle*
-  Sharpsign Equal-Sign
-  Sharpsign Sharpsign
-printer control variable
-  Multiple Possible Textual Representations
-  Glossary Section ``P''
-printer escaping
-  Glossary Section ``P''
-*PRINT-ESCAPE*
-  Variable *PRINT-ESCAPE*
-:print-function
-  Macro DEFSTRUCT
-  Printing Structures
-*PRINT-GENSYM*
-  Variable *PRINT-GENSYM*
-printing
-  Glossary Section ``P''
-*PRINT-LENGTH*
-  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
-*PRINT-LEVEL*
-  Variable *PRINT-LEVEL*, *PRINT-LENGTH*
-*PRINT-LINES*
-  Variable *PRINT-LINES*
-*PRINT-MISER-WIDTH*
-  Variable *PRINT-MISER-WIDTH*
-:print-object
-  Macro DEFSTRUCT
-  Printing Structures
-*PRINT-PPRINT-DISPATCH*
-  Variable *PRINT-PPRINT-DISPATCH*
-*PRINT-PRETTY*
-  Variable *PRINT-PRETTY*
-*PRINT-RADIX*
-  Variable *PRINT-BASE*, *PRINT-RADIX*
-*PRINT-READABLY*
-  Variable *PRINT-READABLY*
-*PRINT-RIGHT-MARGIN*
-  Variable *PRINT-RIGHT-MARGIN*
-:probe
-  Function OPEN
-PROBE-FILE
-  Function PROBE-FILE
-process
-  Glossary Section ``P''
-processor
-  Glossary Section ``P''
-proclaim
-  Glossary Section ``P''
-PROCLAIM
-  Function PROCLAIM
-proclamation
-  Declarations
-  Glossary Section ``P''
-PROG
-  Macro PROG, PROG*
-prog tag
-  Glossary Section ``P''
-PROG*
-  Macro PROG, PROG*
-PROG1
-  Macro PROG1, PROG2
-PROG2
-  Macro PROG1, PROG2
-progn
-  Built-in Method Combination Types
-PROGN
-  Special Operator PROGN
-program
-  Glossary Section ``P''
-PROGRAM-ERROR
-  Condition Type PROGRAM-ERROR
-programmer
-  Glossary Section ``P''
-programmer code
-  Glossary Section ``P''
-PROGV
-  Special Operator PROGV
-proper list
-  Glossary Section ``P''
-proper name
-  Glossary Section ``P''
-proper sequence
-  Glossary Section ``P''
-proper subtype
-  Glossary Section ``P''
-property
-  Glossary Section ``P''
-property indicator
-  Glossary Section ``P''
-property list
-  Glossary Section ``P''
-property value
-  Glossary Section ``P''
-PROVIDE
-  Function PROVIDE, REQUIRE
-PSETF
-  Macro SETF, PSETF
-PSETQ
-  Macro PSETQ
-purports to conform
-  Glossary Section ``P''
-PUSH
-  Macro PUSH
-PUSHNEW
-  Macro PUSHNEW
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Q.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Q.htm deleted file mode 100644 index 773158d7..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Q.htm +++ /dev/null @@ -1,57 +0,0 @@ - - - -CLHS: Index - Q - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - Q

    - -
    -qualified method
-  Glossary Section ``Q''
-qualifier
-  Glossary Section ``Q''
-query I/O
-  Glossary Section ``Q''
-*QUERY-IO*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-Question-Mark (format directive)
-  Tilde Question-Mark: Recursive Processing
-quotation (of forms)
-  Single-Quote
-  Backquote
-  Comma
-quotation (of strings)
-  Double-Quote
-QUOTE
-  Special Operator QUOTE
-quote
-  Single-Quote
-  Backquote
-  Comma
-quoted object
-  Glossary Section ``Q''
-quux
-  Nonsense Words
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_R.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_R.htm deleted file mode 100644 index 7f02946e..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_R.htm +++ /dev/null @@ -1,324 +0,0 @@ - - - -CLHS: Index - R - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - R

    - -
    -R (format directive)
-  Tilde R: Radix
-R (sharpsign reader macro)
-  Sharpsign R
-radix
-  Glossary Section ``R''
-:radix
-  Function PARSE-INTEGER
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-RANDOM
-  Function RANDOM
-random state
-  Glossary Section ``R''
-RANDOM-STATE
-  System Class RANDOM-STATE
-RANDOM-STATE-P
-  Function RANDOM-STATE-P
-*RANDOM-STATE*
-  Variable *RANDOM-STATE*
-rank
-  Glossary Section ``R''
-RASSOC
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-RASSOC-IF
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-RASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-ratio
-  Printing Ratios
-  Glossary Section ``R''
-RATIO
-  System Class RATIO
-ratio marker
-  Glossary Section ``R''
-rational
-  Glossary Section ``R''
-RATIONAL
-  System Class RATIONAL
-  Function RATIONAL, RATIONALIZE
-RATIONALIZE
-  Function RATIONAL, RATIONALIZE
-RATIONALP
-  Function RATIONALP
-read
-  Glossary Section ``R''
-READ
-  Function READ, READ-PRESERVING-WHITESPACE
-READ-BYTE
-  Function READ-BYTE
-READ-CHAR
-  Function READ-CHAR
-READ-CHAR-NO-HANG
-  Function READ-CHAR-NO-HANG
-READ-DELIMITED-LIST
-  Function READ-DELIMITED-LIST
-READ-FROM-STRING
-  Function READ-FROM-STRING
-READ-LINE
-  Function READ-LINE
-READ-PRESERVING-WHITESPACE
-  Function READ, READ-PRESERVING-WHITESPACE
-READ-SEQUENCE
-  Function READ-SEQUENCE
-readably
-  Glossary Section ``R''
-:readably
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-*READ-BASE*
-  Variable *READ-BASE*
-*read-base*
-  Sharpsign B
-  Sharpsign O
-  Sharpsign X
-  Sharpsign R
-*READ-DEFAULT-FLOAT-FORMAT*
-  Variable *READ-DEFAULT-FLOAT-FORMAT*
-reader
-  Glossary Section ``R''
-:reader
-  Redefining Classes
-  Accessing Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-reader macro
-  Glossary Section ``R''
-reader macro function
-  Glossary Section ``R''
-READER-ERROR
-  Condition Type READER-ERROR
-*READ-EVAL*
-  Variable *READ-EVAL*
-*read-eval*
-  Sharpsign Dot
-:read-only
-  Macro DEFSTRUCT
-*READ-SUPPRESS*
-  Variable *READ-SUPPRESS*
-readtable
-  Glossary Section ``R''
-READTABLE
-  System Class READTABLE
-*READTABLE*
-  Variable *READTABLE*
-readtable case
-  Glossary Section ``R''
-readtable designator
-  Glossary Section ``R''
-READTABLE-CASE
-  Accessor READTABLE-CASE
-READTABLEP
-  Function READTABLEP
-REAL
-  System Class REAL
-REALP
-  Function REALP
-REALPART
-  Function REALPART, IMAGPART
-recognizable subtype
-  Glossary Section ``R''
-redefinition
-  Constraints on the COMMON-LISP Package for Conforming Programs
-REDUCE
-  Function REDUCE
-reference
-  Glossary Section ``R''
-registered package
-  Glossary Section ``R''
-:rehash-size
-  Function MAKE-HASH-TABLE
-:rehash-threshold
-  Function MAKE-HASH-TABLE
-REINITIALIZE-INSTANCE
-  Standard Generic Function REINITIALIZE-INSTANCE
-relative
-  Glossary Section ``R''
-:relative
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-  Function MERGE-PATHNAMES
-REM
-  Function MOD, REM
-REMF
-  Macro REMF
-REMHASH
-  Function REMHASH
-REMOVE
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-REMOVE-DUPLICATES
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-REMOVE-IF
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-REMOVE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-REMOVE-METHOD
-  Standard Generic Function REMOVE-METHOD
-REMPROP
-  Function REMPROP
-:rename
-  Function OPEN
-RENAME-FILE
-  Function RENAME-FILE
-RENAME-PACKAGE
-  Function RENAME-PACKAGE
-:rename-and-delete
-  Function OPEN
-repeat (loop keyword)
-  Summary of Termination Test Clauses
-  Iteration Control
-  Termination Test Clauses
-  Notes about Loop
-  Macro LOOP
-repertoire
-  Glossary Section ``R''
-REPLACE
-  Function REPLACE
-report
-  Glossary Section ``R''
-:report
-  Printing Conditions
-  Interactive Use of Restarts
-  Condition Type CONDITION
-  Macro DEFINE-CONDITION
-  Macro RESTART-CASE
-report message
-  Glossary Section ``R''
-:report-function
-  Interactive Use of Restarts
-  Macro RESTART-BIND
-REQUIRE
-  Function PROVIDE, REQUIRE
-:required
-  Macro DEFINE-METHOD-COMBINATION
-required parameter
-  Glossary Section ``R''
-REST
-  Accessor REST
-&rest
-  Ordinary Lambda Lists
-  A specifier for a rest parameter
-  Specifiers for keyword parameters
-  Generic Function Lambda Lists
-  Specialized Lambda Lists
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Boa Lambda Lists
-  Defsetf Lambda Lists
-  Define-modify-macro Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Too Many Arguments
-  Macro DEFMACRO
-  System Class FUNCTION
-  Type Specifier VALUES
-  Function APPLY
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Macro SETF, PSETF
-  Congruent Lambda-lists for all Methods of a Generic Function
-  Keyword Arguments in Generic Functions and Methods
-  Macro DEFINE-METHOD-COMBINATION
-  Glossary Section ``B''
-  Glossary Section ``R''
-rest list
-  Glossary Section ``R''
-rest parameter
-  Glossary Section ``R''
-restart
-  Glossary Section ``R''
-RESTART
-  System Class RESTART
-restart designator
-  Glossary Section ``R''
-restart function
-  Glossary Section ``R''
-RESTART-BIND
-  Macro RESTART-BIND
-RESTART-CASE
-  Macro RESTART-CASE
-RESTART-NAME
-  Function RESTART-NAME
-return
-  Glossary Section ``R''
-RETURN
-  Macro RETURN
-return (loop keyword)
-  Summary of Unconditional Execution Clauses
-  Unconditional Execution Clauses
-  Conditional Execution Clauses
-  Control Transfer Clauses
-  Initial and Final Execution
-  Macro LOOP
-return value
-  Glossary Section ``R''
-RETURN-FROM
-  Special Operator RETURN-FROM
-REVAPPEND
-  Function REVAPPEND, NRECONC
-REVERSE
-  Function REVERSE, NREVERSE
-Right-Brace (format directive)
-  Tilde Right-Brace: End of Iteration
-Right-Bracket (format directive)
-  Tilde Right-Bracket: End of Conditional Expression
-Right-Paren (format directive)
-  Tilde Right-Paren: End of Case Conversion
-right-parenthesis
-  Glossary Section ``R''
-Right-Parenthesis (reader macro)
-  Right-Parenthesis
-:right-margin
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-ROOM
-  Function ROOM
-ROTATEF
-  Macro ROTATEF
-ROUND
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-ROW-MAJOR-AREF
-  Accessor ROW-MAJOR-AREF
-RPLACA
-  Function RPLACA, RPLACD
-RPLACD
-  Function RPLACA, RPLACD
-run time
-  Glossary Section ``R''
-run-time compiler
-  Glossary Section ``R''
-run-time definition
-  Glossary Section ``R''
-run-time environment
-  Glossary Section ``R''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_S.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_S.htm deleted file mode 100644 index b618a605..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_S.htm +++ /dev/null @@ -1,662 +0,0 @@ - - - -CLHS: Index - S - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - S

    - -
    -S (format directive)
-  Tilde S: Standard
-S (sharpsign reader macro)
-  Sharpsign S
-safe
-  Error Terminology
-  Glossary Section ``S''
-safe call
-  Glossary Section ``S''
-safety
-  Minimal Declaration Processing Requirements
-same
-  Glossary Section ``S''
-SATISFIES
-  Type Specifier SATISFIES
-satisfy the test
-  Glossary Section ``S''
-SBIT
-  Accessor BIT, SBIT
-SCALE-FLOAT
-  Function DECODE-FLOAT, SCALE-FLOAT, FLOAT-RADIX, FLOAT-SIGN, FLOAT-DIGITS, FLOAT-PRECISION, INTEGER-DECODE-FLOAT
-SCHAR
-  Accessor CHAR, SCHAR
-scope
-  Glossary Section ``S''
-script
-  Glossary Section ``S''
-SEARCH
-  Function SEARCH
-SECOND
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-secondary value
-  Glossary Section ``S''
-section
-  Glossary Section ``S''
-:section
-  Function PPRINT-TAB
-:section-relative
-  Function PPRINT-TAB
-self-evaluating object
-  Glossary Section ``S''
-semi-standard
-  Glossary Section ``S''
-semicolon
-  Glossary Section ``S''
-Semicolon (format directive)
-  Tilde Semicolon: Clause Separator
-Semicolon (reader macro)
-  Semicolon
-sequence
-  Glossary Section ``S''
-SEQUENCE
-  System Class SEQUENCE
-sequence function
-  Glossary Section ``S''
-sequential
-  Glossary Section ``S''
-sequentially
-  Glossary Section ``S''
-serious condition
-  Glossary Section ``S''
-SERIOUS-CONDITION
-  Condition Type SERIOUS-CONDITION
-session
-  Glossary Section ``S''
-set
-  Glossary Section ``S''
-SET
-  Function SET
-set-char-bit
-  Removed Operators
-SET-DIFFERENCE
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-SET-DISPATCH-MACRO-CHARACTER
-  Function SET-DISPATCH-MACRO-CHARACTER, GET-DISPATCH-MACRO-CHARACTER
-SET-EXCLUSIVE-OR
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-SET-MACRO-CHARACTER
-  Function SET-MACRO-CHARACTER, GET-MACRO-CHARACTER
-SET-PPRINT-DISPATCH
-  Function SET-PPRINT-DISPATCH
-SET-SYNTAX-FROM-CHAR
-  Function SET-SYNTAX-FROM-CHAR
-SETF
-  Macro SETF, PSETF
-setf expander
-  Glossary Section ``S''
-setf expansion
-  Glossary Section ``S''
-setf function
-  Glossary Section ``S''
-setf function name
-  Glossary Section ``S''
-(SETF CLASS-NAME)
-  Standard Generic Function (SETF CLASS-NAME)
-(SETF DOCUMENTATION)
-  Standard Generic Function DOCUMENTATION, (SETF DOCUMENTATION)
-SETQ
-  Special Form SETQ
-SEVENTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-SHADOW
-  Function SHADOW
-shadow
-  Shadowing
-  Glossary Section ``S''
-:shadow
-  Macro DEFPACKAGE
-shadowing symbol
-  Prevention of Name Conflicts in Packages
-  Glossary Section ``S''
-shadowing symbols list
-  Glossary Section ``S''
-SHADOWING-IMPORT
-  Function SHADOWING-IMPORT
-:shadowing-import-from
-  Macro DEFPACKAGE
-shared slot
-  Glossary Section ``S''
-SHARED-INITIALIZE
-  Standard Generic Function SHARED-INITIALIZE
-sharpsign
-  Glossary Section ``S''
-Sharpsign (reader macro)
-  Sharpsign
-Sharpsign (sharpsign reader macro)
-  Sharpsign Sharpsign
-Sharpsign A (reader macro)
-  Sharpsign A
-Sharpsign Asterisk (reader macro)
-  Sharpsign Asterisk
-Sharpsign B (reader macro)
-  Sharpsign B
-Sharpsign Backslash (reader macro)
-  Sharpsign Backslash
-Sharpsign C (reader macro)
-  Sharpsign C
-Sharpsign Colon (reader macro)
-  Sharpsign Colon
-Sharpsign Dot (reader macro)
-  Sharpsign Dot
-Sharpsign Equal-Sign (reader macro)
-  Sharpsign Equal-Sign
-Sharpsign Left-Parenthesis (reader macro)
-  Sharpsign Left-Parenthesis
-Sharpsign Less-Than-Sign (reader macro)
-  Sharpsign Less-Than-Sign
-Sharpsign Minus (reader macro)
-  Sharpsign Minus
-Sharpsign O (reader macro)
-  Sharpsign O
-Sharpsign P (reader macro)
-  Sharpsign P
-Sharpsign Plus (reader macro)
-  Sharpsign Plus
-Sharpsign R (reader macro)
-  Sharpsign R
-Sharpsign Right-Parenthesis
-  Sharpsign Right-Parenthesis
-  Re-Reading Abbreviated Expressions
-Sharpsign S (reader macro)
-  Sharpsign S
-Sharpsign Sharpsign (reader macro)
-  Sharpsign Sharpsign
-  Local Macro PPRINT-POP
-Sharpsign Single-Quote (reader macro)
-  Sharpsign Single-Quote
-Sharpsign Vertical-Bar (reader macro)
-  Sharpsign Vertical-Bar
-Sharpsign Whitespace
-  Sharpsign Whitespace
-  Re-Reading Abbreviated Expressions
-Sharpsign X (reader macro)
-  Sharpsign X
-SHIFTF
-  Macro SHIFTF
-short float
-  Glossary Section ``S''
-SHORT-FLOAT
-  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
-SHORT-FLOAT-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-SHORT-FLOAT-NEGATIVE-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-SHORT-SITE-NAME
-  Function SHORT-SITE-NAME, LONG-SITE-NAME
-should signal
-  Error Terminology
-sign
-  Glossary Section ``S''
-SIGNAL
-  Function SIGNAL
-signal
-  Error Terminology
-  Glossary Section ``S''
-signature
-  Glossary Section ``S''
-SIGNED-BYTE
-  Type SIGNED-BYTE
-SIGNUM
-  Function SIGNUM
-similar
-  Glossary Section ``S''
-similarity
-  Glossary Section ``S''
-simple
-  Glossary Section ``S''
-simple array
-  Glossary Section ``S''
-simple bit array
-  Glossary Section ``S''
-simple bit vector
-  Glossary Section ``S''
-simple condition
-  Glossary Section ``S''
-simple general vector
-  Glossary Section ``S''
-simple string
-  Glossary Section ``S''
-simple vector
-  Glossary Section ``S''
-SIMPLE-ARRAY
-  Type SIMPLE-ARRAY
-SIMPLE-BASE-STRING
-  Type SIMPLE-BASE-STRING
-SIMPLE-BIT-VECTOR
-  Type SIMPLE-BIT-VECTOR
-simple-bit-vector
-  Sharpsign Asterisk
-SIMPLE-BIT-VECTOR-P
-  Function SIMPLE-BIT-VECTOR-P
-SIMPLE-CONDITION
-  Condition Type SIMPLE-CONDITION
-SIMPLE-CONDITION-FORMAT-ARGUMENTS
-  Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS
-SIMPLE-CONDITION-FORMAT-CONTROL
-  Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS
-SIMPLE-ERROR
-  Condition Type SIMPLE-ERROR
-SIMPLE-STRING
-  Type SIMPLE-STRING
-SIMPLE-STRING-P
-  Function SIMPLE-STRING-P
-SIMPLE-TYPE-ERROR
-  Condition Type SIMPLE-TYPE-ERROR
-SIMPLE-VECTOR
-  Type SIMPLE-VECTOR
-simple-vector
-  Sharpsign Left-Parenthesis
-SIMPLE-VECTOR-P
-  Function SIMPLE-VECTOR-P
-SIMPLE-WARNING
-  Condition Type SIMPLE-WARNING
-SIN
-  Function SIN, COS, TAN
-single escape
-  Glossary Section ``S''
-single float
-  Glossary Section ``S''
-SINGLE-FLOAT
-  Type SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT
-SINGLE-FLOAT-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-SINGLE-FLOAT-NEGATIVE-EPSILON
-  Constant Variable SHORT-FLOAT-EPSILON, SHORT-FLOAT-NEGATIVE-EPSILON, SINGLE-FLOAT-EPSILON, SINGLE-FLOAT-NEGATIVE-EPSILON, DOUBLE-FLOAT-EPSILON, DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON
-single-quote
-  Glossary Section ``S''
-Single-Quote (reader macro)
-  Single-Quote
-Single-Quote (sharpsign reader macro)
-  Sharpsign Single-Quote
-singleton
-  Glossary Section ``S''
-SINH
-  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
-situation
-  Glossary Section ``S''
-SIXTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-:size
-  Macro DEFPACKAGE
-  Function MAKE-HASH-TABLE
-slash
-  Glossary Section ``S''
-Slash (format directive)
-  Tilde Slash: Call Function
-SLEEP
-  Function SLEEP
-slot
-  Glossary Section ``S''
-slot specifier
-  Defining Classes
-  Glossary Section ``S''
-SLOT-BOUNDP
-  Function SLOT-BOUNDP
-SLOT-EXISTS-P
-  Function SLOT-EXISTS-P
-SLOT-MAKUNBOUND
-  Function SLOT-MAKUNBOUND
-SLOT-MISSING
-  Standard Generic Function SLOT-MISSING
-SLOT-UNBOUND
-  Standard Generic Function SLOT-UNBOUND
-SLOT-VALUE
-  Function SLOT-VALUE
-:slot-names
-  Function MAKE-LOAD-FORM-SAVING-SLOTS
-SOFTWARE-TYPE
-  Function SOFTWARE-TYPE, SOFTWARE-VERSION
-SOFTWARE-VERSION
-  Function SOFTWARE-TYPE, SOFTWARE-VERSION
-SOME
-  Function EVERY, SOME, NOTEVERY, NOTANY
-SORT
-  Function SORT, STABLE-SORT
-source code
-  Glossary Section ``S''
-source file
-  Glossary Section ``S''
-space
-  Glossary Section ``S''
-SPECIAL
-  Declaration SPECIAL
-special
-  Minimal Declaration Processing Requirements
-special form
-  Glossary Section ``S''
-special operator
-  Glossary Section ``S''
-special variable
-  Glossary Section ``S''
-SPECIAL-OPERATOR-P
-  Function SPECIAL-OPERATOR-P
-specialize
-  Glossary Section ``S''
-specialized
-  Glossary Section ``S''
-specialized lambda list
-  Glossary Section ``S''
-spreadable argument list designator
-  Glossary Section ``S''
-SQRT
-  Function SQRT, ISQRT
-STABLE-SORT
-  Function SORT, STABLE-SORT
-stack allocate
-  Glossary Section ``S''
-stack-allocated
-  Glossary Section ``S''
-standard
-  Built-in Method Combination Types
-standard character
-  Standard Characters
-  Glossary Section ``S''
-standard class
-  Glossary Section ``S''
-standard generic function
-  Glossary Section ``S''
-standard input
-  Glossary Section ``S''
-standard method combination
-  Glossary Section ``S''
-standard object
-  Glossary Section ``S''
-standard output
-  Glossary Section ``S''
-standard pprint dispatch table
-  Glossary Section ``S''
-standard readtable
-  Glossary Section ``S''
-standard syntax
-  Glossary Section ``S''
-STANDARD-CHAR
-  Type STANDARD-CHAR
-STANDARD-CHAR-P
-  Function STANDARD-CHAR-P
-STANDARD-CLASS
-  System Class STANDARD-CLASS
-STANDARD-GENERIC-FUNCTION
-  System Class STANDARD-GENERIC-FUNCTION
-STANDARD-METHOD
-  System Class STANDARD-METHOD
-STANDARD-OBJECT
-  Class STANDARD-OBJECT
-*STANDARD-INPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-standardized
-  Glossary Section ``S''
-*STANDARD-OUTPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-:start
-  Examples of Ordinary Lambda Lists
-  Function PARSE-INTEGER
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-  Function FILL
-  Function REDUCE
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-  Function PARSE-NAMESTRING
-  Function WRITE-STRING, WRITE-LINE
-  Function READ-SEQUENCE
-  Function WRITE-SEQUENCE
-  Macro WITH-INPUT-FROM-STRING
-  Function READ-FROM-STRING
-  Glossary Section ``F''
-:start1
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-:start2
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-  Function SEARCH
-  Function MISMATCH
-  Function REPLACE
-startup environment
-  Glossary Section ``S''
-step
-  Glossary Section ``S''
-STEP
-  Macro STEP
-STORAGE-CONDITION
-  Condition Type STORAGE-CONDITION
-store-value
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-STORE-VALUE
-  Restart STORE-VALUE
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-stream
-  Glossary Section ``S''
-STREAM
-  System Class STREAM
-:stream
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-stream associated with a file
-  Glossary Section ``S''
-stream designator
-  Glossary Section ``S''
-stream element type
-  Glossary Section ``S''
-stream variable
-  Stream Variables
-  Glossary Section ``S''
-stream variable designator
-  Glossary Section ``S''
-STREAM-ELEMENT-TYPE
-  Function STREAM-ELEMENT-TYPE
-STREAM-ERROR
-  Condition Type STREAM-ERROR
-STREAM-ERROR-STREAM
-  Function STREAM-ERROR-STREAM
-STREAM-EXTERNAL-FORMAT
-  Function STREAM-EXTERNAL-FORMAT
-STREAMP
-  Function STREAMP
-STRING
-  System Class STRING
-  Function STRING
-string
-  Double-Quote
-  Required Kinds of Specialized Arrays
-  Glossary Section ``S''
-string designator
-  Glossary Section ``S''
-string equal
-  Glossary Section ``S''
-string stream
-  Glossary Section ``S''
-STRING-CAPITALIZE
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-string-char
-  Removed Types
-string-char-p
-  Removed Operators
-STRING-DOWNCASE
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-STRING-EQUAL
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING-GREATERP
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING-LEFT-TRIM
-  Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
-STRING-LESSP
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING-NOT-EQUAL
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING-NOT-GREATERP
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING-NOT-LESSP
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING-RIGHT-TRIM
-  Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
-STRING-STREAM
-  System Class STRING-STREAM
-STRING-TRIM
-  Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
-STRING-UPCASE
-  Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
-STRING/=
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING<
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING<=
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING=
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING>
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRING>=
-  Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
-STRINGP
-  Function STRINGP
-structure
-  Sharpsign S
-  Glossary Section ``S''
-structure class
-  Glossary Section ``S''
-structure name
-  Glossary Section ``S''
-STRUCTURE-CLASS
-  System Class STRUCTURE-CLASS
-STRUCTURE-OBJECT
-  Class STRUCTURE-OBJECT
-style warning
-  Glossary Section ``S''
-STYLE-WARNING
-  Condition Type STYLE-WARNING
-subclass
-  Glossary Section ``S''
-subexpression
-  Glossary Section ``S''
-subform
-  Glossary Section ``S''
-SUBLIS
-  Function SUBLIS, NSUBLIS
-subrepertoire
-  Glossary Section ``S''
-SUBSEQ
-  Accessor SUBSEQ
-SUBSETP
-  Function SUBSETP
-SUBST
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-SUBST-IF
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-SUBST-IF-NOT
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-SUBSTITUTE
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-SUBSTITUTE-IF
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-SUBSTITUTE-IF-NOT
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-subtype
-  Glossary Section ``S''
-SUBTYPEP
-  Function SUBTYPEP
-:suffix
-  Tilde Less-Than-Sign: Logical Block
-  Macro PPRINT-LOGICAL-BLOCK
-sum (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-summing (loop keyword)
-  Summary of Value Accumulation Clauses
-  Value Accumulation Clauses
-  Macro LOOP
-superclass
-  Glossary Section ``S''
-:supersede
-  Function OPEN
-supertype
-  Glossary Section ``S''
-supplied-p parameter
-  Glossary Section ``S''
-SVREF
-  Accessor SVREF
-SXHASH
-  Function SXHASH
-SYMBOL
-  System Class SYMBOL
-symbol
-  Sharpsign Colon
-  Glossary Section ``S''
-symbol (loop keyword)
-  The for-as-package subclause
-  Macro LOOP
-symbol macro
-  Minimal Compilation
-  Glossary Section ``S''
-SYMBOL-FUNCTION
-  Accessor SYMBOL-FUNCTION
-SYMBOL-MACROLET
-  Special Operator SYMBOL-MACROLET
-symbol-macrolet
-  Minimal Compilation
-SYMBOL-NAME
-  Function SYMBOL-NAME
-SYMBOL-PACKAGE
-  Function SYMBOL-PACKAGE
-SYMBOL-PLIST
-  Accessor SYMBOL-PLIST
-SYMBOL-VALUE
-  Accessor SYMBOL-VALUE
-SYMBOLP
-  Function SYMBOLP
-symbols (loop keyword)
-  The for-as-package subclause
-  Macro LOOP
-synonym stream
-  Glossary Section ``S''
-synonym stream symbol
-  Glossary Section ``S''
-SYNONYM-STREAM
-  System Class SYNONYM-STREAM
-SYNONYM-STREAM-SYMBOL
-  Function SYNONYM-STREAM-SYMBOL
-syntax type
-  Glossary Section ``S''
-SYSTEM
-  Packages No Longer Required
-system class
-  Glossary Section ``S''
-system code
-  Glossary Section ``S''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_T.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_T.htm deleted file mode 100644 index 7f398e98..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_T.htm +++ /dev/null @@ -1,303 +0,0 @@ - - - -CLHS: Index - T - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - T

    - -
    -t
-  Macro CASE, CCASE, ECASE
-  Macro TYPECASE, CTYPECASE, ETYPECASE
-  Glossary Section ``T''
-T
-  System Class T
-  Constant Variable T
-T (format directive)
-  Tilde T: Tabulate
-tag
-  Glossary Section ``T''
-TAGBODY
-  Special Operator TAGBODY
-tail
-  Glossary Section ``T''
-TAILP
-  Function LDIFF, TAILP
-TAN
-  Function SIN, COS, TAN
-TANH
-  Function SINH, COSH, TANH, ASINH, ACOSH, ATANH
-target
-  Glossary Section ``T''
-TENTH
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-terminal I/O
-  Glossary Section ``T''
-*TERMINAL-IO*
-  Variable *TERMINAL-IO*
-terminating
-  Glossary Section ``T''
-TERPRI
-  Function TERPRI, FRESH-LINE
-tertiary value
-  Glossary Section ``T''
-:test
-  Function EQUALP
-  Function COMPLEMENT
-  Restart Tests
-  Macro RESTART-CASE
-  Function SUBLIS, NSUBLIS
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-  Function TREE-EQUAL
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-  Function INTERSECTION, NINTERSECTION
-  Function ADJOIN
-  Macro PUSHNEW
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-  Function SUBSETP
-  Function UNION, NUNION
-  Satisfying a Two-Argument Test
-  Satisfying a One-Argument Test
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-  Modifying Hash Table Keys
-  Visible Modifications by Language Extensions
-  Function MAKE-HASH-TABLE
-:test-function
-  Restart Tests
-  Macro RESTART-BIND
-:test-not
-  Deprecated Argument Conventions
-  Function COMPLEMENT
-  Function SUBLIS, NSUBLIS
-  Function SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT
-  Function TREE-EQUAL
-  Function MEMBER, MEMBER-IF, MEMBER-IF-NOT
-  Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
-  Function RASSOC, RASSOC-IF, RASSOC-IF-NOT
-  Function INTERSECTION, NINTERSECTION
-  Function ADJOIN
-  Macro PUSHNEW
-  Function SET-DIFFERENCE, NSET-DIFFERENCE
-  Function SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
-  Function SUBSETP
-  Function UNION, NUNION
-  Satisfying a Two-Argument Test
-  Function COUNT, COUNT-IF, COUNT-IF-NOT
-  Function FIND, FIND-IF, FIND-IF-NOT
-  Function POSITION, POSITION-IF, POSITION-IF-NOT
-  Function SEARCH
-  Function MISMATCH
-  Function SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT
-  Function REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT
-  Function REMOVE-DUPLICATES, DELETE-DUPLICATES
-THE
-  Special Operator THE
-the (loop keyword)
-  The for-as-hash subclause
-  The for-as-package subclause
-  Macro LOOP
-then (loop keyword)
-  The for-as-equals-then subclause
-  Macro LOOP
-thereis (loop keyword)
-  Summary of Termination Test Clauses
-  Termination Test Clauses
-  Initial and Final Execution
-  Macro LOOP
-THIRD
-  Accessor FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH, NINTH, TENTH
-throw
-  Glossary Section ``T''
-THROW
-  Special Operator THROW
-tilde
-  Glossary Section ``T''
-Tilde (format directive)
-  Tilde Tilde: Tilde
-Tilde A (format directive)
-  Tilde A: Aesthetic
-Tilde Ampersand (format directive)
-  Tilde Ampersand: Fresh-Line
-Tilde Asterisk (format directive)
-  Tilde Asterisk: Go-To
-Tilde B (format directive)
-  Tilde B: Binary
-Tilde C (format directive)
-  Tilde C: Character
-Tilde Circumflex (format directive)
-  Tilde Circumflex: Escape Upward
-Tilde D (format directive)
-  Tilde D: Decimal
-Tilde Dollarsign (format directive)
-  Tilde Dollarsign: Monetary Floating-Point
-Tilde E (format directive)
-  Tilde E: Exponential Floating-Point
-Tilde F (format directive)
-  Tilde F: Fixed-Format Floating-Point
-Tilde G (format directive)
-  Tilde G: General Floating-Point
-Tilde Greater-Than-Sign (format directive)
-  Tilde Greater-Than-Sign: End of Justification
-Tilde I (format directive)
-  Tilde I: Indent
-Tilde Left-Brace (format directive)
-  Tilde Left-Brace: Iteration
-Tilde Left-Bracket (format directive)
-  Tilde Left-Bracket: Conditional Expression
-Tilde Left-Paren (format directive)
-  Tilde Left-Paren: Case Conversion
-Tilde Less-Than-Sign (format directive)
-  Tilde Less-Than-Sign: Logical Block
-  Tilde Less-Than-Sign: Justification
-Tilde Newline (format directive)
-  Tilde Newline: Ignored Newline
-Tilde O (format directive)
-  Tilde O: Octal
-Tilde P (format directive)
-  Tilde P: Plural
-Tilde Percent (format directive)
-  Tilde Percent: Newline
-Tilde Question-Mark (format directive)
-  Tilde Question-Mark: Recursive Processing
-Tilde R (format directive)
-  Tilde R: Radix
-Tilde Right-Brace (format directive)
-  Tilde Right-Brace: End of Iteration
-Tilde Right-Bracket (format directive)
-  Tilde Right-Bracket: End of Conditional Expression
-Tilde Right-Paren (format directive)
-  Tilde Right-Paren: End of Case Conversion
-Tilde S (format directive)
-  Tilde S: Standard
-Tilde Semicolon (format directive)
-  Tilde Semicolon: Clause Separator
-Tilde Slash (format directive)
-  Tilde Slash: Call Function
-Tilde T (format directive)
-  Tilde T: Tabulate
-Tilde Tilde (format directive)
-  Tilde Tilde: Tilde
-Tilde Underscore (format directive)
-  Tilde Underscore: Conditional Newline
-Tilde Vertical-Bar (format directive)
-  Tilde Vertical-Bar: Page
-Tilde W (format directive)
-  Tilde W: Write
-Tilde X (format directive)
-  Tilde X: Hexadecimal
-time
-  Glossary Section ``T''
-TIME
-  Macro TIME
-time zone
-  Glossary Section ``T''
-to (loop keyword)
-  Parsing Loop Clauses
-  The for-as-arithmetic subclause
-  Macro LOOP
-token
-  Glossary Section ``T''
-top level form
-  Glossary Section ``T''
-TRACE
-  Macro TRACE, UNTRACE
-trace output
-  Glossary Section ``T''
-*TRACE-OUTPUT*
-  Variable *DEBUG-IO*, *ERROR-OUTPUT*, *QUERY-IO*, *STANDARD-INPUT*, *STANDARD-OUTPUT*, *TRACE-OUTPUT*
-TRANSLATE-LOGICAL-PATHNAME
-  Function TRANSLATE-LOGICAL-PATHNAME
-TRANSLATE-PATHNAME
-  Function TRANSLATE-PATHNAME
-tree
-  Glossary Section ``T''
-tree structure
-  Glossary Section ``T''
-TREE-EQUAL
-  Function TREE-EQUAL
-true
-  Glossary Section ``T''
-truename
-  Glossary Section ``T''
-TRUENAME
-  Function TRUENAME
-TRUNCATE
-  Function FLOOR, FFLOOR, CEILING, FCEILING, TRUNCATE, FTRUNCATE, ROUND, FROUND
-two-way stream
-  Glossary Section ``T''
-TWO-WAY-STREAM
-  System Class TWO-WAY-STREAM
-TWO-WAY-STREAM-INPUT-STREAM
-  Function TWO-WAY-STREAM-INPUT-STREAM, TWO-WAY-STREAM-OUTPUT-STREAM
-TWO-WAY-STREAM-OUTPUT-STREAM
-  Function TWO-WAY-STREAM-INPUT-STREAM, TWO-WAY-STREAM-OUTPUT-STREAM
-type
-  Glossary Section ``T''
-TYPE
-  Declaration TYPE
-:type
-  Boa Lambda Lists
-  Type Specifiers
-  Integrating Types and Classes
-  Function TYPE-OF
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFSTRUCT
-  Macro DEFINE-CONDITION
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-  Macro PRINT-UNREADABLE-OBJECT
-  Glossary Section ``S''
-type declaration
-  Glossary Section ``T''
-type equivalent
-  Glossary Section ``T''
-type expand
-  Glossary Section ``T''
-type specifier
-  Glossary Section ``T''
-TYPE-ERROR
-  Condition Type TYPE-ERROR
-TYPE-ERROR-DATUM
-  Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE
-TYPE-ERROR-EXPECTED-TYPE
-  Function TYPE-ERROR-DATUM, TYPE-ERROR-EXPECTED-TYPE
-TYPE-OF
-  Function TYPE-OF
-TYPECASE
-  Macro TYPECASE, CTYPECASE, ETYPECASE
-TYPEP
-  Function TYPEP
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_U.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_U.htm deleted file mode 100644 index c5d41550..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_U.htm +++ /dev/null @@ -1,171 +0,0 @@ - - - -CLHS: Index - U - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - U

    - -
    -unbound
-  Glossary Section ``U''
-unbound variable
-  Glossary Section ``U''
-UNBOUND-SLOT
-  Condition Type UNBOUND-SLOT
-UNBOUND-SLOT-INSTANCE
-  Function UNBOUND-SLOT-INSTANCE
-UNBOUND-VARIABLE
-  Condition Type UNBOUND-VARIABLE
-undefined consequences
-  Error Terminology
-undefined function
-  Glossary Section ``U''
-UNDEFINED-FUNCTION
-  Condition Type UNDEFINED-FUNCTION
-Underscore (format directive)
-  Tilde Underscore: Conditional Newline
-UNEXPORT
-  Function UNEXPORT
-unintern
-  Glossary Section ``U''
-UNINTERN
-  Function UNINTERN
-uninterned
-  Glossary Section ``U''
-UNION
-  Function UNION, NUNION
-universal time
-  Universal Time
-  Glossary Section ``U''
-UNLESS
-  Macro WHEN, UNLESS
-unless (loop keyword)
-  Summary of Conditional Execution Clauses
-  Conditional Execution Clauses
-  Macro LOOP
-unqualified method
-  Glossary Section ``U''
-UNREAD-CHAR
-  Function UNREAD-CHAR
-unregistered package
-  Glossary Section ``U''
-unsafe
-  Error Terminology
-  Glossary Section ``U''
-unsafe call
-  Glossary Section ``U''
-UNSIGNED-BYTE
-  Type UNSIGNED-BYTE
-:unspecific
-  The Pathname Type Component
-  The Pathname Version Component
-  :UNSPECIFIC as a Component Value
-  Relation between component values NIL and :UNSPECIFIC
-  Restrictions on Examining a Pathname Device Component
-  Restrictions on Examining a Pathname Directory Component
-  Restrictions on Examining a Pathname Name Component
-  Restrictions on Examining a Pathname Type Component
-  Restrictions on Examining a Pathname Version Component
-  Merging Pathnames
-  Examples of Merging Pathnames
-  The Device part of a Logical Pathname Namestring
-  Unspecific Components of a Logical Pathname
-  Function MAKE-PATHNAME
-  Function USER-HOMEDIR-PATHNAME
-  Glossary Section ``V''
-unspecified consequences
-  Error Terminology
-unspecified values
-  Error Terminology
-until (loop keyword)
-  Summary of Termination Test Clauses
-  Termination Test Clauses
-  Macro LOOP
-UNTRACE
-  Macro TRACE, UNTRACE
-UNUSE-PACKAGE
-  Function UNUSE-PACKAGE
-UNWIND-PROTECT
-  Special Operator UNWIND-PROTECT
-:up
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-:upcase
-  The Standard Readtable
-  Symbols as Tokens
-  Valid Patterns for Tokens
-  Effect of Readtable Case on the Lisp Printer
-  Variable *PRINT-CASE*
-  Effect of Readtable Case on the Lisp Reader
-  Macro WITH-STANDARD-IO-SYNTAX
-  Glossary Section ``C''
-UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
-  Standard Generic Function UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
-UPDATE-INSTANCE-FOR-REDEFINED-CLASS
-  Standard Generic Function UPDATE-INSTANCE-FOR-REDEFINED-CLASS
-upfrom (loop keyword)
-  The for-as-arithmetic subclause
-  Macro LOOP
-upgrade
-  Glossary Section ``U''
-upgraded array element type
-  Glossary Section ``U''
-upgraded complex part type
-  Glossary Section ``U''
-UPGRADED-ARRAY-ELEMENT-TYPE
-  Function UPGRADED-ARRAY-ELEMENT-TYPE
-UPGRADED-COMPLEX-PART-TYPE
-  Function UPGRADED-COMPLEX-PART-TYPE
-UPPER-CASE-P
-  Function UPPER-CASE-P, LOWER-CASE-P, BOTH-CASE-P
-uppercase
-  Glossary Section ``U''
-upto (loop keyword)
-  The for-as-arithmetic subclause
-  Macro LOOP
-use
-  Glossary Section ``U''
-:use
-  Function MAKE-PACKAGE
-  Macro DEFPACKAGE
-use list
-  Glossary Section ``U''
-USE-PACKAGE
-  Function USE-PACKAGE
-use-value
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-USE-VALUE
-  Restart USE-VALUE
-  Function ABORT, CONTINUE, MUFFLE-WARNING, STORE-VALUE, USE-VALUE
-USER
-  Packages No Longer Required
-user
-  Glossary Section ``U''
-USER-HOMEDIR-PATHNAME
-  Function USER-HOMEDIR-PATHNAME
-using (loop keyword)
-  The for-as-hash subclause
-  Macro LOOP
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_V.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_V.htm deleted file mode 100644 index e0594c2b..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_V.htm +++ /dev/null @@ -1,97 +0,0 @@ - - - -CLHS: Index - V - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - V

    - -
    -valid array dimension
-  Glossary Section ``V''
-valid array index
-  Glossary Section ``V''
-valid array row-major index
-  Glossary Section ``V''
-valid fill pointer
-  Glossary Section ``V''
-valid logical pathname host
-  Glossary Section ``V''
-valid pathname device
-  Glossary Section ``V''
-valid pathname directory
-  Glossary Section ``V''
-valid pathname host
-  Glossary Section ``V''
-valid pathname name
-  Glossary Section ``V''
-valid pathname type
-  Glossary Section ``V''
-valid pathname version
-  Glossary Section ``V''
-valid physical pathname host
-  Glossary Section ``V''
-valid sequence index
-  Glossary Section ``V''
-value
-  Glossary Section ``V''
-value cell
-  Glossary Section ``V''
-VALUES
-  Type Specifier VALUES
-  Accessor VALUES
-VALUES-LIST
-  Function VALUES-LIST
-variable
-  Glossary Section ``V''
-VECTOR
-  System Class VECTOR
-  Function VECTOR
-vector
-  Sharpsign Left-Parenthesis
-  Glossary Section ``V''
-VECTOR-POP
-  Function VECTOR-POP
-VECTOR-PUSH
-  Function VECTOR-PUSH, VECTOR-PUSH-EXTEND
-VECTOR-PUSH-EXTEND
-  Function VECTOR-PUSH, VECTOR-PUSH-EXTEND
-VECTORP
-  Function VECTORP
-:verbose
-  Function ENSURE-DIRECTORIES-EXIST
-  Function COMPILE-FILE
-  Function LOAD
-  Variable *COMPILE-PRINT*, *COMPILE-VERBOSE*
-  Variable *LOAD-PRINT*, *LOAD-VERBOSE*
-:version
-  Function MAKE-PATHNAME
-  Function WILD-PATHNAME-P
-vertical-bar
-  Glossary Section ``V''
-Vertical-Bar (format directive)
-  Tilde Vertical-Bar: Page
-Vertical-Bar (sharpsign reader macro)
-  Sharpsign Vertical-Bar
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_W.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_W.htm deleted file mode 100644 index bc86c420..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_W.htm +++ /dev/null @@ -1,145 +0,0 @@ - - - -CLHS: Index - W - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - W

    - -
    -W (format directive)
-  Tilde W: Write
-WARN
-  Function WARN
-WARNING
-  Condition Type WARNING
-warning
-  Error Terminology
-WHEN
-  Macro WHEN, UNLESS
-when (loop keyword)
-  Summary of Conditional Execution Clauses
-  Conditional Execution Clauses
-  Macro LOOP
-while (loop keyword)
-  Summary of Termination Test Clauses
-  Termination Test Clauses
-  Macro LOOP
-whitespace
-  Glossary Section ``W''
-&whole
-  Macro Lambda Lists
-  Lambda-list-directed Destructuring by Lambda Lists
-  Define-method-combination Arguments Lambda Lists
-  Macro DEFINE-COMPILER-MACRO
-  Constant Variable LAMBDA-LIST-KEYWORDS
-  Macro DEFINE-METHOD-COMBINATION
-wild
-  Glossary Section ``W''
-:wild
-  The Pathname Type Component
-  The Pathname Version Component
-  :WILD as a Component Value
-  Restrictions on Wildcard Pathnames
-  Restrictions on Examining a Pathname Device Component
-  Restrictions on Examining a Pathname Directory Component
-  Restrictions on Examining a Pathname Name Component
-  Restrictions on Examining a Pathname Type Component
-  Restrictions on Examining a Pathname Version Component
-  The Version part of a Logical Pathname Namestring
-  Wildcard Words in a Logical Pathname Namestring
-  Function MAKE-PATHNAME
-  Function PATHNAME-MATCH-P
-  Function TRANSLATE-PATHNAME
-  Function MERGE-PATHNAMES
-  Glossary Section ``V''
-  Glossary Section ``W''
-WILD-PATHNAME-P
-  Function WILD-PATHNAME-P
-:wild-inferiors
-  :WILD as a Component Value
-  Restrictions on Examining a Pathname Directory Component
-  Directory Components in Non-Hierarchical File Systems
-  The Directory part of a Logical Pathname Namestring
-  Function MAKE-PATHNAME
-:wild-inferors
-  Glossary Section ``W''
-with (loop keyword)
-  Summary of Variable Initialization and Stepping Clauses
-  Summary of Miscellaneous Clauses
-  Order of Execution
-  Iteration Control
-  Local Variable Initializations
-  Value Accumulation Clauses
-  Initial and Final Execution
-  Macro LOOP
-WITH-ACCESSORS
-  Macro WITH-ACCESSORS
-WITH-COMPILATION-UNIT
-  Macro WITH-COMPILATION-UNIT
-WITH-CONDITION-RESTARTS
-  Macro WITH-CONDITION-RESTARTS
-WITH-HASH-TABLE-ITERATOR
-  Macro WITH-HASH-TABLE-ITERATOR
-WITH-INPUT-FROM-STRING
-  Macro WITH-INPUT-FROM-STRING
-WITH-OPEN-FILE
-  macro WITH-OPEN-FILE
-WITH-OPEN-STREAM
-  Macro WITH-OPEN-STREAM
-WITH-OUTPUT-TO-STRING
-  Macro WITH-OUTPUT-TO-STRING
-WITH-PACKAGE-ITERATOR
-  Macro WITH-PACKAGE-ITERATOR
-WITH-SIMPLE-RESTART
-  Macro WITH-SIMPLE-RESTART
-WITH-SLOTS
-  Macro WITH-SLOTS
-WITH-STANDARD-IO-SYNTAX
-  Macro WITH-STANDARD-IO-SYNTAX
-write
-  Glossary Section ``W''
-WRITE
-  Function WRITE, PRIN1, PRINT, PPRINT, PRINC
-WRITE-BYTE
-  Function WRITE-BYTE
-WRITE-CHAR
-  Function WRITE-CHAR
-WRITE-LINE
-  Function WRITE-STRING, WRITE-LINE
-WRITE-SEQUENCE
-  Function WRITE-SEQUENCE
-WRITE-STRING
-  Function WRITE-STRING, WRITE-LINE
-WRITE-TO-STRING
-  Function WRITE-TO-STRING, PRIN1-TO-STRING, PRINC-TO-STRING
-writer
-  Glossary Section ``W''
-:writer
-  Redefining Classes
-  Accessing Slots
-  Inheritance of Slots and Slot Options
-  Macro DEFCLASS
-  Macro DEFINE-CONDITION
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_X.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_X.htm deleted file mode 100644 index f25863a1..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_X.htm +++ /dev/null @@ -1,37 +0,0 @@ - - - -CLHS: Index - X - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - X

    - -
    -X (format directive)
-  Tilde X: Hexadecimal
-X (sharpsign reader macro)
-  Sharpsign X
-:x3j13
-  Variable *FEATURES*
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Y.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Y.htm deleted file mode 100644 index 6fcdc0b1..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Y.htm +++ /dev/null @@ -1,37 +0,0 @@ - - - -CLHS: Index - Y - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - Y

    - -
    -Y-OR-N-P
-  Function Y-OR-N-P, YES-OR-NO-P
-YES-OR-NO-P
-  Function Y-OR-N-P, YES-OR-NO-P
-yield
-  Glossary Section ``Y''
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Z.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Z.htm deleted file mode 100644 index 839c3056..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Mast_Z.htm +++ /dev/null @@ -1,33 +0,0 @@ - - - -CLHS: Index - Z - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index - Z

    - -
    -ZEROP
-  Function ZEROP
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Master.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Master.htm deleted file mode 100644 index a409ea11..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Master.htm +++ /dev/null @@ -1,29 +0,0 @@ - - - -CLHS: Index - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

    - -
    - - -

    Index

    - -Index entries are partitioned by their initial character.

    A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | Non-Alphabetic

    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_9.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_9.htm deleted file mode 100644 index cc098593..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_9.htm +++ /dev/null @@ -1,148 +0,0 @@ - - - -CLHS: Permuted Symbol Index (Non-Alphabetic) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (Non-Alphabetic)

    - -
    -                   &allow-other-keys
-                   &aux
-                   &body
-                   &environment
-                   &key
-                   &optional
-                   &rest
-                   &whole
-                   *
-                 do*
-                let*
-               list*
-               prog*
-                   **
-                   ***
-                   *break-on-signals*
-                   *compile-file-pathname*
-                   *compile-file-truename*
-                   *compile-print*
-                   *compile-verbose*
-                   *debug-io*
-                   *debugger-hook*
-                   *default-pathname-defaults*
-                   *error-output*
-                   *features*
-                   *gensym-counter*
-                   *load-pathname*
-                   *load-print*
-                   *load-truename*
-                   *load-verbose*
-                   *macroexpand-hook*
-                   *modules*
-                   *package*
-                   *print-array*
-                   *print-base*
-                   *print-case*
-                   *print-circle*
-                   *print-escape*
-                   *print-gensym*
-                   *print-length*
-                   *print-level*
-                   *print-lines*
-                   *print-miser-width*
-                   *print-pprint-dispatch*
-                   *print-pretty*
-                   *print-radix*
-                   *print-readably*
-                   *print-right-margin*
-                   *query-io*
-                   *random-state*
-                   *read-base*
-                   *read-default-float-format*
-                   *read-eval*
-                   *read-suppress*
-                   *readtable*
-                   *standard-input*
-                   *standard-output*
-                   *terminal-io*
-                   *trace-output*
-                   +
-                  1+
-                   ++
-                   +++
-                   -
-                   /
-                   //
-                   ///
-                   /=
-               char/=
-             string/=
-           bit-andc1
-            bit-orc1
-             boole-1
-         boole-andc1
-            boole-c1
-          boole-orc1
-            logandc1
-             logorc1
-       macroexpand-1
-multiple-value-prog1
-               prin1
-               prog1
-                   1+
-                   1-
-               prin1-to-string
-           bit-andc2
-            bit-orc2
-             boole-2
-         boole-andc2
-            boole-c2
-          boole-orc2
-            logandc2
-             logorc2
-               prog2
-                   <
-               char<
-             string<
-                   <=
-               char<=
-             string<=
-                  /=
-                  <=
-                   =
-                  >=
-              char/=
-              char<=
-               char=
-              char>=
-            string/=
-            string<=
-             string=
-            string>=
-                   >
-               char>
-             string>
-                   >=
-               char>=
-             string>=
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_A.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_A.htm deleted file mode 100644 index cfd9358f..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_A.htm +++ /dev/null @@ -1,100 +0,0 @@ - - - -CLHS: Permuted Symbol Index (A) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (A)

    - -
    -                        abort
-                        abs
-                   with-accessors
-                        acons
-                        acos
-                        acosh
-                        add-method
-                        adjoin
-                        adjust-array
-                        adjustable-array-p
-                   copy-alist
-                   list-all-packages
-                     do-all-symbols
-                   find-all-symbols
-                        allocate-instance
-                       &allow-other-keys
-                        alpha-char-p
-                        alphanumericp
-                        and
-                    bit-and
-                  boole-and
-                    bit-andc1
-                  boole-andc1
-                    bit-andc2
-                  boole-andc2
-                        append
-                     no-applicable-method
-                compute-applicable-methods
-                        apply
-                        apropos
-                        apropos-list
-                        aref
-              row-major-aref
-simple-condition-format-arguments
-                   call-arguments-limit
-                        arithmetic-error
-                        arithmetic-error-operands
-                        arithmetic-error-operation
-                 adjust-array
-                        array
-                   make-array
-                 simple-array
-                 *print-array*
-                        array-dimension
-                        array-dimension-limit
-                        array-dimensions
-                        array-displacement
-                        array-element-type
-               upgraded-array-element-type
-                        array-has-fill-pointer-p
-                        array-in-bounds-p
-             adjustable-array-p
-                        array-rank
-                        array-rank-limit
-                        array-row-major-index
-                        array-total-size
-                        array-total-size-limit
-                        arrayp
-                        ash
-                        asin
-                        asinh
-                        assert
-                        assoc
-                        assoc-if
-                        assoc-if-not
-                        atan
-                        atanh
-                        atom
-                   file-author
-                       &aux
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_B.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_B.htm deleted file mode 100644 index 434fd5ea..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_B.htm +++ /dev/null @@ -1,97 +0,0 @@ - - - -CLHS: Permuted Symbol Index (B) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (B)

    - -
    -        *print-base*
-         *read-base*
-               base-char
-               base-string
-        simple-base-string
-               bignum
- destructuring-bind
-       handler-bind
-multiple-value-bind
-       restart-bind
-               bit
-               bit-and
-               bit-andc1
-               bit-andc2
-               bit-eqv
-               bit-ior
-               bit-nand
-               bit-nor
-               bit-not
-               bit-orc1
-               bit-orc2
-               bit-vector
-        simple-bit-vector
-               bit-vector-p
-        simple-bit-vector-p
-               bit-xor
-               block
-pprint-logical-block
-              &body
-               boole
-               boole-1
-               boole-2
-               boole-and
-               boole-andc1
-               boole-andc2
-               boole-c1
-               boole-c2
-               boole-clr
-               boole-eqv
-               boole-ior
-               boole-nand
-               boole-nor
-               boole-orc1
-               boole-orc2
-               boole-set
-               boole-xor
-               boolean
-               both-case-p
-               boundp
-          slot-boundp
-      array-in-bounds-p
-               break
-              *break-on-signals*
-               broadcast-stream
-          make-broadcast-stream
-               broadcast-stream-streams
-               built-in-class
-               butlast
-  package-used-by-list
-      division-by-zero
-               byte
-          read-byte
-        signed-byte
-      unsigned-byte
-         write-byte
-               byte-position
-               byte-size
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_C.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_C.htm deleted file mode 100644 index c86316d7..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_C.htm +++ /dev/null @@ -1,208 +0,0 @@ - - - -CLHS: Permuted Symbol Index (C) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (C)

    - -
    -                        boole-c1
-                        boole-c2
-                              caaaar
-                              caaadr
-                              caaar
-                              caadar
-                              caaddr
-                              caadr
-                              caar
-                              cadaar
-                              cadadr
-                              cadar
-                              caddar
-                              cadddr
-                              caddr
-                              cadr
-               multiple-value-call
-                              call-arguments-limit
-                              call-method
-                              call-next-method
-                      nstring-capitalize
-                       string-capitalize
-                              car
-                              case
-                      handler-case
-                    readtable-case
-                      restart-case
-                       *print-case*
-                         both-case-p
-                        lower-case-p
-                        upper-case-p
-                              catch
-                              ccase
-                              cdaaar
-                              cdaadr
-                              cdaar
-                              cdadar
-                              cdaddr
-                              cdadr
-                              cdar
-                              cddaar
-                              cddadr
-                              cddar
-                              cdddar
-                              cddddr
-                              cdddr
-                              cddr
-                              cdr
-                              ceiling
-                              cell-error
-                              cell-error-name
-                              cerror
-                              change-class
-                         base-char
-                              char
-                         code-char
-                        digit-char
-                     extended-char
-                         name-char
-                         peek-char
-                         read-char
-              set-syntax-from-char
-                     standard-char
-                       unread-char
-                        write-char
-                              char-code
-                              char-code-limit
-                              char-downcase
-                              char-equal
-                              char-greaterp
-                              char-int
-                              char-lessp
-                              char-name
-                         read-char-no-hang
-                              char-not-equal
-                              char-not-greaterp
-                              char-not-lessp
-                        alpha-char-p
-                        digit-char-p
-                      graphic-char-p
-                     standard-char-p
-                              char-upcase
-                              char/=
-                              char<
-                              char<=
-                              char=
-                              char>
-                              char>=
-                              character
-           get-dispatch-macro-character
-                    get-macro-character
-          make-dispatch-macro-character
-           set-dispatch-macro-character
-                    set-macro-character
-                              characterp
-                              check-type
-                       *print-circle*
-                              cis
-                     built-in-class
-                       change-class
-                              class
-                         find-class
-                     standard-class
-                    structure-class
-update-instance-for-different-class
-update-instance-for-redefined-class
-                              class-name
-                              class-of
-                              clear-input
-                              clear-output
-                              close
-                        boole-clr
-                              clrhash
-                         char-code
-                              code-char
-                         char-code-limit
-                              coerce
-                define-method-combination
-                       method-combination
-                       method-combination-error
-                              compilation-speed
-                         with-compilation-unit
-                              compile
-                              compile-file
-                              compile-file-pathname
-                             *compile-file-pathname*
-                             *compile-file-truename*
-                             *compile-print*
-                             *compile-verbose*
-                              compiled-function
-                              compiled-function-p
-                              compiler-macro
-                       define-compiler-macro
-                              compiler-macro-function
-                              complement
-                              complex
-                     upgraded-complex-part-type
-                              complexp
-                              compute-applicable-methods
-                              compute-restarts
-                              concatenate
-                              concatenated-stream
-                         make-concatenated-stream
-                              concatenated-stream-streams
-                              cond
-                              condition
-                       define-condition
-                         make-condition
-                      serious-condition
-                       simple-condition
-                      storage-condition
-                       simple-condition-format-arguments
-                       simple-condition-format-control
-                         with-condition-restarts
-                              conjugate
-                              cons
-                              consp
-                              constantly
-                              constantp
-                              continue
-      simple-condition-format-control
-                              control-error
-                              copy-alist
-                              copy-list
-                              copy-pprint-dispatch
-                              copy-readtable
-                              copy-seq
-                              copy-structure
-                              copy-symbol
-                              copy-tree
-                              cos
-                              cosh
-                              count
-                   hash-table-count
-                              count-if
-                              count-if-not
-                      *gensym-counter*
-                              ctypecase
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_D.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_D.htm deleted file mode 100644 index a868a481..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_D.htm +++ /dev/null @@ -1,126 +0,0 @@ - - - -CLHS: Permuted Symbol Index (D) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (D)

    - -
    -               file-write-date
-               type-error-datum
-                          debug
-                         *debug-io*
-                   invoke-debugger
-                         *debugger-hook*
-                          decf
-                          declaim
-                          declaration
-                          declare
-                          decode-float
-                  integer-decode-float
-                          decode-universal-time
-                      get-decoded-time
-                    *read-default-float-format*
-                         *default-pathname-defaults*
-        *default-pathname-defaults*
-                          defclass
-                          defconstant
-                          defgeneric
-                          define-compiler-macro
-                          define-condition
-                          define-method-combination
-                          define-modify-macro
-                          define-setf-expander
-                          define-symbol-macro
-                          defmacro
-                          defmethod
-                          defpackage
-                          defparameter
-                          defsetf
-                          defstruct
-                          deftype
-                          defun
-                          defvar
-                          delete
-                          delete-duplicates
-                          delete-file
-                          delete-if
-                          delete-if-not
-                          delete-package
-                     read-delimited-list
-                          denominator
-                          deposit-field
-                          describe
-                          describe-object
-                          destructuring-bind
-                 pathname-device
-                     nset-difference
-                      set-difference
-      update-instance-for-different-class
-                          digit-char
-                          digit-char-p
-                    float-digits
-                    array-dimension
-                    array-dimension-limit
-                    array-dimensions
-                   ensure-directories-exist
-                          directory
-                 pathname-directory
-                          directory-namestring
-                          disassemble
-              copy-pprint-dispatch
-                   pprint-dispatch
-               set-pprint-dispatch
-            *print-pprint-dispatch*
-                      get-dispatch-macro-character
-                     make-dispatch-macro-character
-                      set-dispatch-macro-character
-                    array-displacement
-                          division-by-zero
-                          do
-                          do*
-                          do-all-symbols
-                          do-external-symbols
-                          do-symbols
-                          documentation
-                          dolist
-                          dotimes
-                          double-float
-           least-negative-double-float
-least-negative-normalized-double-float
-           least-positive-double-float
-least-positive-normalized-double-float
-            most-negative-double-float
-            most-positive-double-float
-                          double-float-epsilon
-                          double-float-negative-epsilon
-                     char-downcase
-                  nstring-downcase
-                   string-downcase
-                          dpb
-                          dribble
-                   delete-duplicates
-                   remove-duplicates
-                          dynamic-extent
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_E.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_E.htm deleted file mode 100644 index 3f29f6d0..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_E.htm +++ /dev/null @@ -1,117 +0,0 @@ - - - -CLHS: Permuted Symbol Index (E) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (E)

    - -
    -                      ecase
-                      echo-stream
-                 make-echo-stream
-                      echo-stream-input-stream
-                      echo-stream-output-stream
-                      ed
-                      eighth
-                array-element-type
-               stream-element-type
-       upgraded-array-element-type
-                      elt
-                      encode-universal-time
-                      end-of-file
-                      endp
-                      enough-namestring
-                      ensure-directories-exist
-                      ensure-generic-function
-                     &environment
-         double-float-epsilon
-double-float-negative-epsilon
-           long-float-epsilon
-  long-float-negative-epsilon
-          short-float-epsilon
- short-float-negative-epsilon
-         single-float-epsilon
-single-float-negative-epsilon
-                      eq
-                      eql
-                 char-equal
-             char-not-equal
-                      equal
-               string-equal
-           string-not-equal
-                 tree-equal
-                      equalp
-                  bit-eqv
-                boole-eqv
-           arithmetic-error
-                 cell-error
-              control-error
-                      error
-                 file-error
-       invalid-method-error
-   method-combination-error
-              package-error
-                parse-error
-              program-error
-               reader-error
-               simple-error
-          simple-type-error
-               stream-error
-                 type-error
-                 type-error-datum
-                 type-error-expected-type
-                 cell-error-name
-           arithmetic-error-operands
-           arithmetic-error-operation
-                     *error-output*
-              package-error-package
-                 file-error-pathname
-               stream-error-stream
-               ignore-errors
-               *print-escape*
-                      etypecase
-                      eval
-                *read-eval*
-                      eval-when
-                      evenp
-                      every
-                 nset-exclusive-or
-                  set-exclusive-or
-  pprint-exit-if-list-exhausted
-   ensure-directories-exist
-                 slot-exists-p
-               pprint-exit-if-list-exhausted
-                      exp
-          define-setf-expander
-             get-setf-expansion
-           type-error-expected-type
-                      export
-      function-lambda-expression
-                      expt
-          vector-push-extend
-                      extended-char
-              dynamic-extent
-               stream-external-format
-                   do-external-symbols
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_F.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_F.htm deleted file mode 100644 index d78a4180..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_F.htm +++ /dev/null @@ -1,162 +0,0 @@ - - - -CLHS: Permuted Symbol Index (F) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (F)

    - -
    -                                 fboundp
-                                 fceiling
-                                 fdefinition
-                                *features*
-                                 ffloor
-                         deposit-field
-                            mask-field
-                                 fifth
-                         compile-file
-                          delete-file
-                          end-of-file
-                           probe-file
-                          rename-file
-                       with-open-file
-                                 file-author
-                                 file-error
-                                 file-error-pathname
-                                 file-length
-                                 file-namestring
-                         compile-file-pathname
-                        *compile-file-pathname*
-                                 file-position
-                                 file-stream
-                                 file-string-length
-                        *compile-file-truename*
-                                 file-write-date
-                                 fill
-                          pprint-fill
-                                 fill-pointer
-                       array-has-fill-pointer-p
-                                 find
-                                 find-all-symbols
-                                 find-class
-                                 find-if
-                                 find-if-not
-                                 find-method
-                                 find-package
-                                 find-restart
-                                 find-symbol
-                            loop-finish
-                                 finish-output
-                                 first
-                                 fixnum
-                   most-negative-fixnum
-                   most-positive-fixnum
-                                 flet
-                          decode-float
-                          double-float
-                                 float
-                  integer-decode-float
-           least-negative-double-float
-             least-negative-long-float
-least-negative-normalized-double-float
-  least-negative-normalized-long-float
- least-negative-normalized-short-float
-least-negative-normalized-single-float
-            least-negative-short-float
-           least-negative-single-float
-           least-positive-double-float
-             least-positive-long-float
-least-positive-normalized-double-float
-  least-positive-normalized-long-float
- least-positive-normalized-short-float
-least-positive-normalized-single-float
-            least-positive-short-float
-           least-positive-single-float
-                            long-float
-            most-negative-double-float
-              most-negative-long-float
-             most-negative-short-float
-            most-negative-single-float
-            most-positive-double-float
-              most-positive-long-float
-             most-positive-short-float
-            most-positive-single-float
-                           scale-float
-                           short-float
-                          single-float
-                                 float-digits
-                          double-float-epsilon
-                            long-float-epsilon
-                           short-float-epsilon
-                          single-float-epsilon
-                   *read-default-float-format*
-                          double-float-negative-epsilon
-                            long-float-negative-epsilon
-                           short-float-negative-epsilon
-                          single-float-negative-epsilon
-                                 float-precision
-                                 float-radix
-                                 float-sign
-                                 floating-point-inexact
-                                 floating-point-invalid-operation
-                                 floating-point-overflow
-                                 floating-point-underflow
-                                 floatp
-                                 floor
-                                 fmakunbound
-                 update-instance-for-different-class
-                 update-instance-for-redefined-class
-                                 force-output
-                       make-load-form
-                       make-load-form-saving-slots
-                                 format
-                 stream-external-format
-             *read-default-float-format*
-                simple-condition-format-arguments
-                simple-condition-format-control
-                                 formatter
-                                 fourth
-                                 fresh-line
-                          return-from
-                      set-syntax-from-char
-                            read-from-string
-                      with-input-from-string
-                                 fround
-                                 ftruncate
-                                 ftype
-                                 funcall
-                        compiled-function
-                  compiler-macro-function
-                  ensure-generic-function
-                                 function
-                         generic-function
-                           macro-function
-                standard-generic-function
-                          symbol-function
-                       undefined-function
-                                 function-keywords
-                                 function-lambda-expression
-                        compiled-function-p
-                                 functionp
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_G.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_G.htm deleted file mode 100644 index 875a2952..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_G.htm +++ /dev/null @@ -1,56 +0,0 @@ - - - -CLHS: Permuted Symbol Index (G) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (G)

    - -
    -           gcd
-    ensure-generic-function
-           generic-function
-  standard-generic-function
-           gensym
-    *print-gensym*
-          *gensym-counter*
-           gentemp
-           get
-           get-decoded-time
-           get-dispatch-macro-character
-           get-internal-real-time
-           get-internal-run-time
-           get-macro-character
-           get-output-stream-string
-           get-properties
-           get-setf-expansion
-           get-universal-time
-           getf
-           gethash
-           go
-           graphic-char-p
-      char-greaterp
-  char-not-greaterp
-    string-greaterp
-string-not-greaterp
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_H.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_H.htm deleted file mode 100644 index 84bc8e6a..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_H.htm +++ /dev/null @@ -1,48 +0,0 @@ - - - -CLHS: Permuted Symbol Index (H) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (H)

    - -
    -             handler-bind
-             handler-case
-read-char-no-hang
-       array-has-fill-pointer-p
-             hash-table
-        make-hash-table
-             hash-table-count
-        with-hash-table-iterator
-             hash-table-p
-             hash-table-rehash-size
-             hash-table-rehash-threshold
-             hash-table-size
-             hash-table-test
-        user-homedir-pathname
-   *debugger-hook*
-*macroexpand-hook*
-    pathname-host
-             host-namestring
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_I.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_I.htm deleted file mode 100644 index 817fbb60..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_I.htm +++ /dev/null @@ -1,120 +0,0 @@ - - - -CLHS: Permuted Symbol Index (I) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (I)

    - -
    -                identity
-          assoc-if
-          count-if
-         delete-if
-           find-if
-                if
-         member-if
-         nsubst-if
-    nsubstitute-if
-       position-if
-         rassoc-if
-         remove-if
-          subst-if
-     substitute-if
-    pprint-exit-if-list-exhausted
-          assoc-if-not
-          count-if-not
-         delete-if-not
-           find-if-not
-         member-if-not
-         nsubst-if-not
-    nsubstitute-if-not
-       position-if-not
-         rassoc-if-not
-         remove-if-not
-          subst-if-not
-     substitute-if-not
-                ignorable
-                ignore
-                ignore-errors
-                imagpart
-           lisp-implementation-type
-           lisp-implementation-version
-                import
-      shadowing-import
-          array-in-bounds-p
-          built-in-class
-                in-package
-                incf
-         pprint-indent
-array-row-major-index
- floating-point-inexact
-         shared-initialize
-                initialize-instance
-                inline
-          clear-input
-      *standard-input*
-           with-input-from-string
-    echo-stream-input-stream
-    make-string-input-stream
- two-way-stream-input-stream
-                input-stream-p
-                inspect
-       allocate-instance
-     initialize-instance
-        machine-instance
-           make-instance
-   reinitialize-instance
-   unbound-slot-instance
-         update-instance-for-different-class
-         update-instance-for-redefined-class
-           make-instances-obsolete
-           char-int
-                integer
-          parse-integer
-                integer-decode-float
-                integer-length
-                integerp
-                interactive-stream-p
- invoke-restart-interactively
-                intern
-            get-internal-real-time
-            get-internal-run-time
-                internal-time-units-per-second
-                intersection
-            map-into
-                invalid-method-error
- floating-point-invalid-operation
-                invoke-debugger
-                invoke-restart
-                invoke-restart-interactively
-         *debug-io*
-         *query-io*
-      *terminal-io*
-  with-standard-io-syntax
-            bit-ior
-          boole-ior
-                isqrt
-with-hash-table-iterator
-   with-package-iterator
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_K.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_K.htm deleted file mode 100644 index 08f6b94b..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_K.htm +++ /dev/null @@ -1,36 +0,0 @@ - - - -CLHS: Permuted Symbol Index (K) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (K)

    - -
    -            &key
-&allow-other-keys
-             keyword
-             keywordp
-    function-keywords
- lambda-list-keywords
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_L.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_L.htm deleted file mode 100644 index ac3af2aa..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_L.htm +++ /dev/null @@ -1,143 +0,0 @@ - - - -CLHS: Permuted Symbol Index (L) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (L)

    - -
    -                          labels
-                          lambda
-                 function-lambda-expression
-                          lambda-list-keywords
-                          lambda-parameters-limit
-                          last
-                          lcm
-                          ldb
-                          ldb-test
-                          ldiff
-                          least-negative-double-float
-                          least-negative-long-float
-                          least-negative-normalized-double-float
-                          least-negative-normalized-long-float
-                          least-negative-normalized-short-float
-                          least-negative-normalized-single-float
-                          least-negative-short-float
-                          least-negative-single-float
-                          least-positive-double-float
-                          least-positive-long-float
-                          least-positive-normalized-double-float
-                          least-positive-normalized-long-float
-                          least-positive-normalized-short-float
-                          least-positive-normalized-single-float
-                          least-positive-short-float
-                          least-positive-single-float
-                   string-left-trim
-                     file-length
-              file-string-length
-                  integer-length
-                          length
-                     list-length
-                   *print-length*
-                     char-lessp
-                 char-not-lessp
-                   string-lessp
-               string-not-lessp
-                          let
-                          let*
-                   *print-level*
-          array-dimension-limit
-               array-rank-limit
-         array-total-size-limit
-           call-arguments-limit
-                char-code-limit
-        lambda-parameters-limit
-          multiple-values-limit
-                    fresh-line
-                     read-line
-                    write-line
-                   pprint-linear
-                   *print-lines*
-                          lisp-implementation-type
-                          lisp-implementation-version
-                  apropos-list
-                     copy-list
-                          list
-                     make-list
-           multiple-value-list
-              package-use-list
-          package-used-by-list
-           read-delimited-list
-                   values-list
-                          list*
-                          list-all-packages
-           pprint-exit-if-list-exhausted
-                   lambda-list-keywords
-                          list-length
-                          listen
-                          listp
-                          load
-                     make-load-form
-                     make-load-form-saving-slots
-                          load-logical-pathname-translations
-                         *load-pathname*
-                         *load-print*
-                          load-time-value
-                         *load-truename*
-                         *load-verbose*
-                          locally
-                          log
-                          logand
-                          logandc1
-                          logandc2
-                          logbitp
-                          logcount
-                          logeqv
-                   pprint-logical-block
-                          logical-pathname
-                translate-logical-pathname
-                     load-logical-pathname-translations
-                          logical-pathname-translations
-                          logior
-                          lognand
-                          lognor
-                          lognot
-                          logorc1
-                          logorc2
-                          logtest
-                          logxor
-           least-negative-long-float
-least-negative-normalized-long-float
-           least-positive-long-float
-least-positive-normalized-long-float
-                          long-float
-            most-negative-long-float
-            most-positive-long-float
-                          long-float-epsilon
-                          long-float-negative-epsilon
-                          long-site-name
-                          loop
-                          loop-finish
-                          lower-case-p
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_M.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_M.htm deleted file mode 100644 index 784ab3e3..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_M.htm +++ /dev/null @@ -1,136 +0,0 @@ - - - -CLHS: Permuted Symbol Index (M) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (M)

    - -
    -                   machine-instance
-                   machine-type
-                   machine-version
-          compiler-macro
-   define-compiler-macro
-     define-modify-macro
-     define-symbol-macro
-      get-dispatch-macro-character
-               get-macro-character
-     make-dispatch-macro-character
-      set-dispatch-macro-character
-               set-macro-character
-          compiler-macro-function
-                   macro-function
-                   macroexpand
-                   macroexpand-1
-                  *macroexpand-hook*
-                   macrolet
-            symbol-macrolet
-               row-major-aref
-         array-row-major-index
-                   make-array
-                   make-broadcast-stream
-                   make-concatenated-stream
-                   make-condition
-                   make-dispatch-macro-character
-                   make-echo-stream
-                   make-hash-table
-                   make-instance
-                   make-instances-obsolete
-                   make-list
-                   make-load-form
-                   make-load-form-saving-slots
-                   make-method
-                   make-package
-                   make-pathname
-                   make-random-state
-                   make-sequence
-                   make-string
-                   make-string-input-stream
-                   make-string-output-stream
-                   make-symbol
-                   make-synonym-stream
-                   make-two-way-stream
-                   makunbound
-              slot-makunbound
-                   map
-                   map-into
-                   mapc
-                   mapcan
-                   mapcar
-                   mapcon
-                   maphash
-                   mapl
-                   maplist
-      *print-right-margin*
-                   mask-field
-          pathname-match-p
-                   max
-                   member
-                   member-if
-                   member-if-not
-                   merge
-                   merge-pathnames
-               add-method
-              call-method
-         call-next-method
-              find-method
-              make-method
-                   method
-     no-applicable-method
-           no-next-method
-            remove-method
-          standard-method
-            define-method-combination
-                   method-combination
-                   method-combination-error
-           invalid-method-error
-              next-method-p
-                   method-qualifiers
-compute-applicable-methods
-                   min
-                   minusp
-            *print-miser-width*
-                   mismatch
-              slot-missing
-                   mod
-            define-modify-macro
-                  *modules*
-                   most-negative-double-float
-                   most-negative-fixnum
-                   most-negative-long-float
-                   most-negative-short-float
-                   most-negative-single-float
-                   most-positive-double-float
-                   most-positive-fixnum
-                   most-positive-long-float
-                   most-positive-short-float
-                   most-positive-single-float
-                   muffle-warning
-                   multiple-value-bind
-                   multiple-value-call
-                   multiple-value-list
-                   multiple-value-prog1
-                   multiple-value-setq
-                   multiple-values-limit
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_N.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_N.htm deleted file mode 100644 index b1c7534a..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_N.htm +++ /dev/null @@ -1,137 +0,0 @@ - - - -CLHS: Permuted Symbol Index (N) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (N)

    - -
    -          y-or-n-p
-    cell-error-name
-          char-name
-         class-name
-     long-site-name
-       package-name
-       restart-name
-    short-site-name
-        symbol-name
-               name-char
-           pathname-name
-     directory-namestring
-        enough-namestring
-          file-namestring
-          host-namestring
-               namestring
-         parse-namestring
-           bit-nand
-         boole-nand
-               nbutlast
-               nconc
-         least-negative-double-float
-          most-negative-double-float
-  double-float-negative-epsilon
-    long-float-negative-epsilon
-   short-float-negative-epsilon
-  single-float-negative-epsilon
-          most-negative-fixnum
-         least-negative-long-float
-          most-negative-long-float
-         least-negative-normalized-double-float
-         least-negative-normalized-long-float
-         least-negative-normalized-short-float
-         least-negative-normalized-single-float
-         least-negative-short-float
-          most-negative-short-float
-         least-negative-single-float
-          most-negative-single-float
-        pprint-newline
-          call-next-method
-            no-next-method
-               next-method-p
-       package-nicknames
-               nil
-               nintersection
-               ninth
-               no-applicable-method
-     read-char-no-hang
-               no-next-method
-        yes-or-no-p
-           bit-nor
-         boole-nor
-least-negative-normalized-double-float
-least-positive-normalized-double-float
-least-negative-normalized-long-float
-least-positive-normalized-long-float
-least-negative-normalized-short-float
-least-positive-normalized-short-float
-least-negative-normalized-single-float
-least-positive-normalized-single-float
-      assoc-if-not
-           bit-not
-      count-if-not
-     delete-if-not
-       find-if-not
-     member-if-not
-               not
-     nsubst-if-not
-nsubstitute-if-not
-   position-if-not
-     rassoc-if-not
-     remove-if-not
-      subst-if-not
- substitute-if-not
-          char-not-equal
-        string-not-equal
-          char-not-greaterp
-        string-not-greaterp
-          char-not-lessp
-        string-not-lessp
-         print-not-readable
-         print-not-readable-object
-               notany
-               notevery
-               notinline
-               nreconc
-               nreverse
-               nset-difference
-               nset-exclusive-or
-               nstring-capitalize
-               nstring-downcase
-               nstring-upcase
-               nsublis
-               nsubst
-               nsubst-if
-               nsubst-if-not
-               nsubstitute
-               nsubstitute-if
-               nsubstitute-if-not
-               nth
-               nth-value
-               nthcdr
-               null
-               number
-               numberp
-               numerator
-               nunion
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_O.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_O.htm deleted file mode 100644 index 443fff34..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_O.htm +++ /dev/null @@ -1,76 +0,0 @@ - - - -CLHS: Permuted Symbol Index (O) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (O)

    - -
    -              describe-object
-    print-not-readable-object
-                 print-object
-      print-unreadable-object
-              standard-object
-             structure-object
-        make-instances-obsolete
-                       oddp
-                 class-of
-                  type-of
-                   end-of-file
-                *break-on-signals*
-                       open
-                  with-open-file
-                  with-open-stream
-                       open-stream-p
-      arithmetic-error-operands
-      arithmetic-error-operation
-floating-point-invalid-operation
-               special-operator-p
-                       optimize
-                      &optional
-        nset-exclusive-or
-                       or
-         set-exclusive-or
-                     y-or-n-p
-                   yes-or-no-p
-                   bit-orc1
-                 boole-orc1
-                   bit-orc2
-                 boole-orc2
-                &allow-other-keys
-                       otherwise
-                 clear-output
-                finish-output
-                 force-output
-                *error-output*
-             *standard-output*
-                *trace-output*
-           echo-stream-output-stream
-           make-string-output-stream
-        two-way-stream-output-stream
-                       output-stream-p
-                   get-output-stream-string
-                  with-output-to-string
-        floating-point-overflow
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_P.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_P.htm deleted file mode 100644 index b11df44d..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_P.htm +++ /dev/null @@ -1,219 +0,0 @@ - - - -CLHS: Permuted Symbol Index (P) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (P)

    - -
    -      adjustable-array-p
-            alpha-char-p
-array-has-fill-pointer-p
-       array-in-bounds-p
-            bit-vector-p
-             both-case-p
-     compiled-function-p
-            digit-char-p
-          graphic-char-p
-            hash-table-p
-          input-stream-p
-    interactive-stream-p
-            lower-case-p
-           next-method-p
-           open-stream-p
-         output-stream-p
-                packagep
-        pathname-match-p
-               pathnamep
-                   plusp
-                     pop
-              pprint-pop
-          random-state-p
-     simple-bit-vector-p
-         simple-string-p
-         simple-vector-p
-           slot-exists-p
-      special-operator-p
-         standard-char-p
-            upper-case-p
-         wild-pathname-p
-                y-or-n-p
-             yes-or-no-p
-                delete-package
-                  find-package
-                    in-package
-                  make-package
-                       package
-         package-error-package
-                rename-package
-                symbol-package
-                 unuse-package
-                   use-package
-                      *package*
-                       package-error
-                       package-error-package
-                  with-package-iterator
-                       package-name
-                       package-nicknames
-                       package-shadowing-symbols
-                       package-use-list
-                       package-used-by-list
-                       packagep
-              list-all-packages
-                       pairlis
-                lambda-parameters-limit
-                       parse-error
-                       parse-integer
-                       parse-namestring
-      upgraded-complex-part-type
-             pprint-dispatch
-          compile-file-pathname
-            file-error-pathname
-               logical-pathname
-                  make-pathname
-                       pathname
-     translate-logical-pathname
-             translate-pathname
-          user-homedir-pathname
-         *compile-file-pathname*
-                 *load-pathname*
-              *default-pathname-defaults*
-                       pathname-device
-                       pathname-directory
-                       pathname-host
-                       pathname-match-p
-                       pathname-name
-                  wild-pathname-p
-          load-logical-pathname-translations
-               logical-pathname-translations
-                       pathname-type
-                       pathname-version
-                       pathnamep
-                 merge-pathnames
-            pathname-type
-                       peek-char
-   internal-time-units-per-second
-                       phase
-                       pi
-                symbol-plist
-                       plusp
-              floating-point-inexact
-              floating-point-invalid-operation
-              floating-point-overflow
-              floating-point-underflow
-                  fill-pointer
-        array-has-fill-pointer-p
-                       pop
-                pprint-pop
-                vector-pop
-                  byte-position
-                  file-position
-                       position
-                       position-if
-                       position-if-not
-                 least-positive-double-float
-                  most-positive-double-float
-                  most-positive-fixnum
-                 least-positive-long-float
-                  most-positive-long-float
-                 least-positive-normalized-double-float
-                 least-positive-normalized-long-float
-                 least-positive-normalized-short-float
-                 least-positive-normalized-single-float
-                 least-positive-short-float
-                  most-positive-short-float
-                 least-positive-single-float
-                  most-positive-single-float
-                       pprint
-                  copy-pprint-dispatch
-                       pprint-dispatch
-                   set-pprint-dispatch
-                *print-pprint-dispatch*
-                       pprint-exit-if-list-exhausted
-                       pprint-fill
-                       pprint-indent
-                       pprint-linear
-                       pprint-logical-block
-                       pprint-newline
-                       pprint-pop
-                       pprint-tab
-                       pprint-tabular
-                 float-precision
-                  read-preserving-whitespace
-                *print-pretty*
-                       prin1
-                       prin1-to-string
-                       princ
-                       princ-to-string
-                      pprint
-                       print
-              *compile-print*
-                 *load-print*
-                      *print-array*
-                      *print-base*
-                      *print-case*
-                      *print-circle*
-                      *print-escape*
-                      pprint-exit-if-list-exhausted
-                      pprint-fill
-                      *print-gensym*
-                      pprint-indent
-                      *print-length*
-                      *print-level*
-                      pprint-linear
-                      *print-lines*
-                      pprint-logical-block
-                      *print-miser-width*
-                      pprint-newline
-                       print-not-readable
-                       print-not-readable-object
-                       print-object
-                      *print-pprint-dispatch*
-                      *print-pretty*
-                      *print-radix*
-                      *print-readably*
-                      *print-right-margin*
-                      pprint-tab
-                      pprint-tabular
-                       print-unreadable-object
-                       probe-file
-                       proclaim
-                       prog
-                       prog*
-        multiple-value-prog1
-                       prog1
-                       prog2
-                       progn
-                       program-error
-                       progv
-                   get-properties
-                unwind-protect
-                       provide
-                       psetf
-                       psetq
-                       push
-                vector-push
-                vector-push-extend
-                       pushnew
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Q.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Q.htm deleted file mode 100644 index aa62a765..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Q.htm +++ /dev/null @@ -1,33 +0,0 @@ - - - -CLHS: Permuted Symbol Index (Q) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (Q)

    - -
    -method-qualifiers
-      *query-io*
-       quote
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_R.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_R.htm deleted file mode 100644 index 0e609123..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_R.htm +++ /dev/null @@ -1,116 +0,0 @@ - - - -CLHS: Permuted Symbol Index (R) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (R)

    - -
    -              float-radix
-             *print-radix*
-                    random
-               make-random-state
-                    random-state
-                   *random-state*
-                    random-state-p
-              array-rank
-              array-rank-limit
-                    rassoc
-                    rassoc-if
-                    rassoc-if-not
-                    ratio
-                    rational
-                    rationalize
-                    rationalp
-                    read
-                   *read-base*
-                    read-byte
-                    read-char
-                    read-char-no-hang
-                   *read-default-float-format*
-                    read-delimited-list
-                   *read-eval*
-                    read-from-string
-                    read-line
-                    read-preserving-whitespace
-                    read-sequence
-                   *read-suppress*
-          print-not-readable
-          print-not-readable-object
-             *print-readably*
-                    reader-error
-               copy-readtable
-                    readtable
-                   *readtable*
-                    readtable-case
-                    readtablep
-                    real
-       get-internal-real-time
-                    realp
-                    realpart
-update-instance-for-redefined-class
-                    reduce
-         hash-table-rehash-size
-         hash-table-rehash-threshold
-                    reinitialize-instance
-                    rem
-                    remf
-                    remhash
-                    remove
-                    remove-duplicates
-                    remove-if
-                    remove-if-not
-                    remove-method
-                    remprop
-                    rename-file
-                    rename-package
-                    replace
-                    require
-                   &rest
-                    rest
-               find-restart
-             invoke-restart
-                    restart
-        with-simple-restart
-                    restart-bind
-                    restart-case
-             invoke-restart-interactively
-                    restart-name
-            compute-restarts
-     with-condition-restarts
-                    return
-                    return-from
-                    revappend
-                    reverse
-             *print-right-margin*
-             string-right-trim
-                    room
-                    rotatef
-                    round
-                    row-major-aref
-              array-row-major-index
-                    rplaca
-                    rplacd
-       get-internal-run-time
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_S.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_S.htm deleted file mode 100644 index 596fac8d..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_S.htm +++ /dev/null @@ -1,266 +0,0 @@ - - - -CLHS: Permuted Symbol Index (S) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (S)

    - -
    -                          safety
-                          satisfies
-           make-load-form-saving-slots
-                          sbit
-                          scale-float
-                          schar
-                          search
-  internal-time-units-per-second
-                          second
-                     copy-seq
-                     make-sequence
-                     read-sequence
-                          sequence
-                    write-sequence
-                          serious-condition
-                    boole-set
-                          set
-                          set-difference
-                          set-dispatch-macro-character
-                          set-exclusive-or
-                          set-macro-character
-                          set-pprint-dispatch
-                          set-syntax-from-char
-                          setf
-                   define-setf-expander
-                      get-setf-expansion
-           multiple-value-setq
-                          setq
-                          seventh
-                          shadow
-                          shadowing-import
-                  package-shadowing-symbols
-                          shared-initialize
-                          shiftf
-least-negative-normalized-short-float
-           least-negative-short-float
-least-positive-normalized-short-float
-           least-positive-short-float
-            most-negative-short-float
-            most-positive-short-float
-                          short-float
-                          short-float-epsilon
-                          short-float-negative-epsilon
-                          short-site-name
-                    float-sign
-                          signal
-                *break-on-signals*
-                          signed-byte
-                          signum
-                          simple-array
-                          simple-base-string
-                          simple-bit-vector
-                          simple-bit-vector-p
-                          simple-condition
-                          simple-condition-format-arguments
-                          simple-condition-format-control
-                          simple-error
-                     with-simple-restart
-                          simple-string
-                          simple-string-p
-                          simple-type-error
-                          simple-vector
-                          simple-vector-p
-                          simple-warning
-                          sin
-least-negative-normalized-single-float
-           least-negative-single-float
-least-positive-normalized-single-float
-           least-positive-single-float
-            most-negative-single-float
-            most-positive-single-float
-                          single-float
-                          single-float-epsilon
-                          single-float-negative-epsilon
-                          sinh
-                     long-site-name
-                    short-site-name
-                          sixth
-              array-total-size
-                     byte-size
-        hash-table-rehash-size
-               hash-table-size
-              array-total-size-limit
-                          sleep
-                  unbound-slot
-                          slot-boundp
-                          slot-exists-p
-                  unbound-slot-instance
-                          slot-makunbound
-                          slot-missing
-                          slot-unbound
-                          slot-value
-    make-load-form-saving-slots
-                     with-slots
-                          software-type
-                          software-version
-                          some
-                          sort
-                   stable-sort
-                          space
-                          special
-                          special-operator-p
-              compilation-speed
-                          speed
-                          sqrt
-                          stable-sort
-                          standard
-                          standard-char
-                          standard-char-p
-                          standard-class
-                          standard-generic-function
-                         *standard-input*
-                     with-standard-io-syntax
-                          standard-method
-                          standard-object
-                         *standard-output*
-              make-random-state
-                   random-state
-                  *random-state*
-                   random-state-p
-                          step
-                          storage-condition
-                          store-value
-                broadcast-stream
-             concatenated-stream
-                     echo-stream
-                     file-stream
-           make-broadcast-stream
-        make-concatenated-stream
-                make-echo-stream
-        make-string-input-stream
-       make-string-output-stream
-             make-synonym-stream
-             make-two-way-stream
-                          stream
-                   string-stream
-                  synonym-stream
-                  two-way-stream
-                with-open-stream
-                          stream-element-type
-                          stream-error
-                          stream-error-stream
-                          stream-external-format
-                     echo-stream-input-stream
-                  two-way-stream-input-stream
-                     echo-stream-output-stream
-                  two-way-stream-output-stream
-                    input-stream-p
-              interactive-stream-p
-                     open-stream-p
-                   output-stream-p
-                broadcast-stream-streams
-             concatenated-stream-streams
-               get-output-stream-string
-                  synonym-stream-symbol
-                          streamp
-         broadcast-stream-streams
-      concatenated-stream-streams
-                     base-string
-        get-output-stream-string
-                     make-string
-                 prin1-to-string
-                 princ-to-string
-                read-from-string
-              simple-base-string
-                   simple-string
-                          string
-          with-input-from-string
-           with-output-to-string
-                    write-string
-                 write-to-string
-                          string-capitalize
-                          string-downcase
-                          string-equal
-                          string-greaterp
-                     make-string-input-stream
-                          string-left-trim
-                     file-string-length
-                          string-lessp
-                          string-not-equal
-                          string-not-greaterp
-                          string-not-lessp
-                     make-string-output-stream
-                   simple-string-p
-                          string-right-trim
-                          string-stream
-                          string-trim
-                          string-upcase
-                          string/=
-                          string<
-                          string<=
-                          string=
-                          string>
-                          string>=
-                          stringp
-                     copy-structure
-                          structure
-                          structure-class
-                          structure-object
-                          style-warning
-                          sublis
-                          subseq
-                          subsetp
-                          subst
-                          subst-if
-                          subst-if-not
-                          substitute
-                          substitute-if
-                          substitute-if-not
-                          subtypep
-                    *read-suppress*
-                          svref
-                          sxhash
-                     copy-symbol
-                     find-symbol
-                     make-symbol
-                          symbol
-           synonym-stream-symbol
-                          symbol-function
-                   define-symbol-macro
-                          symbol-macrolet
-                          symbol-name
-                          symbol-package
-                          symbol-plist
-                          symbol-value
-                          symbolp
-                   do-all-symbols
-              do-external-symbols
-                       do-symbols
-                 find-all-symbols
-        package-shadowing-symbols
-                     make-synonym-stream
-                          synonym-stream
-                          synonym-stream-symbol
-         with-standard-io-syntax
-                      set-syntax-from-char
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_T.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_T.htm deleted file mode 100644 index e9181b4c..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_T.htm +++ /dev/null @@ -1,106 +0,0 @@ - - - -CLHS: Permuted Symbol Index (T) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (T)

    - -
    -                       t
-                pprint-tab
-                  hash-table
-             make-hash-table
-                  hash-table-count
-             with-hash-table-iterator
-                  hash-table-p
-                  hash-table-rehash-size
-                  hash-table-rehash-threshold
-                  hash-table-size
-                  hash-table-test
-                pprint-tabular
-                       tagbody
-                       tailp
-                       tan
-                       tanh
-                       tenth
-                      *terminal-io*
-                       terpri
-            hash-table-test
-                   ldb-test
-                       the
-                       third
-     hash-table-rehash-threshold
-                       throw
-      decode-universal-time
-      encode-universal-time
-           get-decoded-time
-     get-internal-real-time
-      get-internal-run-time
-         get-universal-time
-                       time
-              internal-time-units-per-second
-                  load-time-value
-                 prin1-to-string
-                 princ-to-string
-           with-output-to-string
-                 write-to-string
-                 array-total-size
-                 array-total-size-limit
-                       trace
-                      *trace-output*
-                       translate-logical-pathname
-                       translate-pathname
- load-logical-pathname-translations
-      logical-pathname-translations
-                  copy-tree
-                       tree-equal
-           string-left-trim
-          string-right-trim
-                string-trim
-                       truename
-         *compile-file-truename*
-                 *load-truename*
-                       truncate
-                  make-two-way-stream
-                       two-way-stream
-                       two-way-stream-input-stream
-                       two-way-stream-output-stream
-         array-element-type
-                 check-type
-   lisp-implementation-type
-               machine-type
-              pathname-type
-              software-type
-        stream-element-type
-                       type
-upgraded-array-element-type
- upgraded-complex-part-type
-                simple-type-error
-                       type-error
-                       type-error-datum
-                       type-error-expected-type
-                       type-of
-                       typecase
-                       typep
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_U.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_U.htm deleted file mode 100644 index 53069e6b..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_U.htm +++ /dev/null @@ -1,64 +0,0 @@ - - - -CLHS: Permuted Symbol Index (U) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (U)

    - -
    -            slot-unbound
-                 unbound-slot
-                 unbound-slot-instance
-                 unbound-variable
-                 undefined-function
-  floating-point-underflow
-                 unexport
-                 unintern
-                 union
-with-compilation-unit
-   internal-time-units-per-second
-          decode-universal-time
-          encode-universal-time
-             get-universal-time
-                 unless
-                 unread-char
-           print-unreadable-object
-                 unsigned-byte
-                 untrace
-                 unuse-package
-                 unwind-protect
-            char-upcase
-         nstring-upcase
-          string-upcase
-                 update-instance-for-different-class
-                 update-instance-for-redefined-class
-                 upgraded-array-element-type
-                 upgraded-complex-part-type
-                 upper-case-p
-         package-use-list
-                 use-package
-                 use-value
-         package-used-by-list
-                 user-homedir-pathname
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_V.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_V.htm deleted file mode 100644 index 1dcd400e..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_V.htm +++ /dev/null @@ -1,63 +0,0 @@ - - - -CLHS: Permuted Symbol Index (V) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (V)

    - -
    -          load-time-value
-                nth-value
-               slot-value
-              store-value
-             symbol-value
-                use-value
-           multiple-value-bind
-           multiple-value-call
-           multiple-value-list
-           multiple-value-prog1
-           multiple-value-setq
-                    values
-           multiple-values-limit
-                    values-list
-            unbound-variable
-                    variable
-                bit-vector
-         simple-bit-vector
-             simple-vector
-                    vector
-                bit-vector-p
-         simple-bit-vector-p
-             simple-vector-p
-                    vector-pop
-                    vector-push
-                    vector-push-extend
-                    vectorp
-           *compile-verbose*
-              *load-verbose*
-lisp-implementation-version
-            machine-version
-           pathname-version
-           software-version
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_W.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_W.htm deleted file mode 100644 index a6e67c33..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_W.htm +++ /dev/null @@ -1,65 +0,0 @@ - - - -CLHS: Permuted Symbol Index (W) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (W)

    - -
    -                warn
-         muffle-warning
-         simple-warning
-          style-warning
-                warning
-       make-two-way-stream
-            two-way-stream
-            two-way-stream-input-stream
-            two-way-stream-output-stream
-           eval-when
-                when
-read-preserving-whitespace
-               &whole
-   *print-miser-width*
-                wild-pathname-p
-                with-accessors
-                with-compilation-unit
-                with-condition-restarts
-                with-hash-table-iterator
-                with-input-from-string
-                with-open-file
-                with-open-stream
-                with-output-to-string
-                with-package-iterator
-                with-simple-restart
-                with-slots
-                with-standard-io-syntax
-                write
-                write-byte
-                write-char
-           file-write-date
-                write-line
-                write-sequence
-                write-string
-                write-to-string
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_X.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_X.htm deleted file mode 100644 index 2d103227..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_X.htm +++ /dev/null @@ -1,32 +0,0 @@ - - - -CLHS: Permuted Symbol Index (X) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (X)

    - -
    -  bit-xor
-boole-xor
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Y.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Y.htm deleted file mode 100644 index 5fa6d0b3..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Y.htm +++ /dev/null @@ -1,32 +0,0 @@ - - - -CLHS: Permuted Symbol Index (Y) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (Y)

    - -
    -y-or-n-p
-yes-or-no-p
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Z.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Z.htm deleted file mode 100644 index 6592bdf8..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/X_Perm_Z.htm +++ /dev/null @@ -1,32 +0,0 @@ - - - -CLHS: Permuted Symbol Index (Z) - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)] [No Previous][Up][No Next]

    - -
    - - -

    Permuted Symbol Index (Z)

    - -
    -division-by-zero
-            zerop
-
-
    -
    - -[Starting Points][Contents][Index][Symbols][Glossary][Issues]
    - -Copyright 1996-2005, LispWorks Ltd. All rights reserved.

    - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index.htm deleted file mode 100644 index 85bacced..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index.htm +++ /dev/null @@ -1,58 +0,0 @@ - - - -Common Lisp HyperSpec (TM) - - - - - - - - - - - - - - - - -

    [LISPWORKS][Common Lisp HyperSpec (TM)]

    - -
    - -
    -Welcome to the Common Lisp HyperSpec.
    -I hope it serves your need.

    ---Kent Pitman, X3J13 Project Editor -

    - -
    - -[Starting Points] -Here are some useful starting points:

    - - [Highlights][Contents][Index][Symbols][Glossary][Issues] - -

    - -[Help] A text-only version of this cover sheet -is available. - - -

    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index_tx.htm b/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index_tx.htm deleted file mode 100644 index 13551ef6..00000000 --- a/clones/lisp/www.lispworks.com/documentation/HyperSpec/Front/index_tx.htm +++ /dev/null @@ -1,46 +0,0 @@ - - - -Common Lisp HyperSpec (TM) - text only - - - - - - - - - -

    [LISPWORKS] Common Lisp HyperSpec (TM)

    - -
    - -
    -Welcome to the Common Lisp HyperSpec.
    -I hope it serves your need.

    ---Kent Pitman, X3J13 Project Editor -

    - -
    - -Here are some useful starting points:

    - -

    - -A flashier version of this cover sheet -is available. - -
    - -Copyright 1996-2005, LispWorks Ltd. All Rights Reserved.

    - - - diff --git a/clones/www.sbcl.org/manual/index.html b/clones/www.sbcl.org/manual/index.html new file mode 100644 index 00000000..fd28d84b --- /dev/null +++ b/clones/www.sbcl.org/manual/index.html @@ -0,0 +1,16503 @@ + + + + + + +SBCL 2.3.0 User Manual + + + + + + + + + + + + + + + +

    SBCL 2.3.0 User Manual

    + + + + + +

    Table of Contents

    + +
    + + +
    + + + + + +
    +

    +Next:   [Contents][Index]

    +
    +

    sbcl

    + +
    +

    This manual is part of the SBCL software system. See +the README file for more information. +

    +

    This manual is largely derived from the manual for the CMUCL system, +which was produced at Carnegie Mellon University and later released +into the public domain. This manual is in the public domain and is +provided with absolutely no warranty. See the COPYING and +CREDITS files for more information. +

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    • Getting Support and Reporting Bugs   +
    • Introduction   +
    • Starting and Stopping   +
    • Compiler   +
    • Debugger   +
    • Efficiency   +
    • Beyond the ANSI Standard   +
    • External Formats   +
    • Foreign Function Interface   +
    • Pathnames   +
    • Streams   +
    • Package Locks   +
    • Threading   +
    • Timers   +
    • Networking   +
    • Profiling   +
    • Contributed Modules   +
    • Deprecation   +
    • Concept Index   +
    • Function Index   +
    • Variable Index   +
    • Type Index   +
    • Colophon   +
    + + +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    1 Getting Support and Reporting Bugs

    + + + + + +
    • Volunteer Support   +
    • Commercial Support   +
    • Reporting Bugs   +
    + +
    +
    +

    +Next: , Up: Getting Support and Reporting Bugs   [Contents][Index]

    +
    +

    1.1 Volunteer Support

    + +

    Your primary source of SBCL support should probably be the mailing +list sbcl-help: in addition to other users SBCL developers +monitor this list and are available for advice. As an anti-spam +measure subscription is required for posting: +

    +

        https://lists.sourceforge.net/lists/listinfo/sbcl-help +

    +

    Remember that the people answering your question are volunteers, so +you stand a much better chance of getting a good answer if you ask a +good question. +

    +

    Before sending mail, check the list archives at either +

    +

        http://sourceforge.net/mailarchive/forum.php?forum_name=sbcl-help +

    +

    or +

    +

        http://news.gmane.org/gmane.lisp.steel-bank.general +

    +

    to see if your question has been answered already. Checking the bug +database is also worth it See Reporting Bugs, to see if the issue +is already known. +

    +

    For general advice on asking good questions, see +

    +

        http://www.catb.org/~esr/faqs/smart-questions.html. +

    +
    +
    +

    +Next: , Previous: , Up: Getting Support and Reporting Bugs   [Contents][Index]

    +
    +

    1.2 Commercial Support

    + +

    There is no formal organization developing SBCL, but if you need a +paid support arrangement or custom SBCL development, we maintain the +list of companies and consultants below. Use it to identify service +providers with appropriate skills and interests, and contact them +directly. +

    +

    The SBCL project cannot verify the accuracy of the information or the +competence of the people listed, and they have provided their own +blurbs below: you must make your own judgement of suitability from the +available information - refer to the links they provide, the CREDITS +file, mailing list archives, CVS commit messages, and so on. Please +feel free to ask for advice on the sbcl-help list. +

    +

    (At present, no companies or consultants wish to advertise paid support +or custom SBCL development in this manual). +

    +
    +
    +

    +Previous: , Up: Getting Support and Reporting Bugs   [Contents][Index]

    +
    +

    1.3 Reporting Bugs

    + +

    SBCL uses Launchpad to track bugs. The bug database is available at +

    +

        https://bugs.launchpad.net/sbcl +

    +

    Reporting bugs there requires registering at Launchpad. However, bugs +can also be reported on the mailing list sbcl-bugs, which is +moderated but does not require subscribing. +

    +

    Simply send email to sbcl-bugs@lists.sourceforge.net and the +bug will be checked and added to Launchpad by SBCL maintainers. +

    +

    1.3.1 How to Report Bugs Effectively

    + +

    Please include enough information in a bug report that someone reading +it can reproduce the problem, i.e. don’t write +

    +
    +
    Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
+PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
+
    + +

    but instead +

    +
    +
    Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
+In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
+I compile and load the file
+   (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
+                                    (LET ((*PRINT-LENGTH* 4))
+                                      (PRINT X Y)))))
+     X Y)
+then at the command line type
+   (MAKE-FOO)
+the program loops endlessly instead of printing the object.
+
    + +

    A more in-depth discussion on reporting bugs effectively can be found +at +

    +

        http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. +

    +

    1.3.2 Signal Related Bugs

    + +

    If you run into a signal related bug, you are getting fatal errors +such as signal N is [un]blocked or just hangs, and you want to +send a useful bug report then: +

    +
      +
    1. +Compile SBCL with ldb enabled (feature :sb-ldb, see +base-target-features.lisp-expr). + +
    2. Isolate a smallish test case, run it. + +
    3. If it just hangs kill it with sigabrt: kill -ABRT <pidof sbcl>. + +
    4. Print the backtrace from ldb by typing ba. + +
    5. Attach gdb: gdb -p <pidof sbcl> and get backtraces for all threads: +thread apply all ba. + +
    6. If multiple threads are in play then still in gdb, try to get Lisp +backtrace for all threads: thread apply all call +backtrace_from_fp($ebp, 100). Substitute $ebp with $rbp +on x86-64. The backtraces will appear in the stdout of the SBCL +process. + +
    7. Send a report with the backtraces and the output (both stdout and +stderr) produced by SBCL. + +
    8. Don’t forget to include OS and SBCL version. + +
    9. If available, include information on outcome of the same test with +other versions of SBCL, OS, ... +
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    2 Introduction

    + +

    SBCL is a mostly-conforming implementation of the ANSI Common Lisp +standard. This manual focuses on behavior which is specific to SBCL, +not on behavior which is common to all implementations of ANSI Common +Lisp. +

    + + + + + + + + +
    • ANSI Conformance   +
    • Extensions   +
    • Idiosyncrasies   +
    • Development Tools   +
    • More SBCL Information   +
    • More Common Lisp Information   +
    • History and Implementation of SBCL   +
    + + + +
    +
    +

    +Next: , Up: Introduction   [Contents][Index]

    +
    +

    2.1 ANSI Conformance

    + +

    Essentially every type of non-conformance is considered a bug. (The +exceptions involve internal inconsistencies in the standard.) +See Reporting Bugs. +

    + + +
    • Exceptions   +
    + +
    +
    +

    +Up: ANSI Conformance   [Contents][Index]

    +
    +

    2.1.1 Exceptions

    + +
      +
    • +prog2 returns the primary value of its second form, as +specified in the Arguments and Values section of the +specification for that operator, not that of its first form, as +specified in the Description. + +
    • + + +The string type is considered to be the union of all types +(array c (size)) for all non-nil subtypes c of +character, excluding arrays specialized to the empty type. + +
    + +
    +
    +

    +Next: , Previous: , Up: Introduction   [Contents][Index]

    +
    +

    2.2 Extensions

    + +

    SBCL comes with numerous extensions, some in core and some in modules +loadable with require. Unfortunately, not all of these +extensions have proper documentation yet. +

    + +
    +
    System Definition Tool
    +

    asdf is a flexible and popular protocol-oriented system +definition tool by Daniel Barlow. See (asdf)the asdf manual, for +more information. +

    +
    +
    Foreign Function Interface
    +

    sb-alien package allows interfacing with C-code, loading shared +object files, etc. See Foreign Function Interface. +

    +

    sb-grovel can be used to partially automate generation of +foreign function interface definitions. See sb-grovel. +

    +
    +
    Recursive Event Loop
    +

    SBCL provides a recursive event loop (serve-event) for doing +non-blocking IO on multiple streams without using threads. +

    +
    +
    Timeouts and Deadlines
    +

    SBCL allows restricting the execution time of individual operations or +parts of a computation using :timeout arguments to certain +blocking operations, synchronous timeouts and asynchronous timeouts. The +latter two affect operations without explicit timeout support (such as +standard functions and macros). See Timeouts and Deadlines. +

    +
    +
    Metaobject Protocol
    +

    sb-mop package provides a metaobject protocol for the Common +Lisp Object System as described in Art of Metaobject Protocol. +

    +
    +
    Extensible Sequences
    +

    SBCL allows users to define subclasses of the sequence +class. See Extensible Sequences. +

    +
    +
    Native Threads
    +

    SBCL has native threads on x86/Linux, capable of taking advantage +of SMP on multiprocessor machines. See Threading. +

    +
    +
    Network Interface
    +

    sb-bsd-sockets is a low-level networking interface, providing +both TCP and UDP sockets. See Networking. +

    +
    +
    Introspective Facilities
    +

    sb-introspect module offers numerous introspective extensions, +including access to function lambda-lists and a cross referencing +facility. +

    +
    +
    Operating System Interface
    +

    sb-ext contains a number of functions for running external +processes, accessing environment variables, etc. +

    +

    sb-posix module provides a lispy interface to standard POSIX +facilities. +

    +
    +
    Extensible Streams
    +

    sb-gray is an implementation of Gray Streams. See Gray Streams. +

    +

    sb-simple-streams is an implementation of the simple +streams API proposed by Franz Inc. See Simple Streams. +

    +
    +
    Profiling
    +

    sb-profile is a exact per-function profiler. See Deterministic Profiler. +

    +

    sb-sprof is a statistical profiler, capable of call-graph +generation and instruction level profiling, which also supports +allocation profiling. See Statistical Profiler. +

    +
    +
    Customization Hooks
    +

    SBCL contains a number of extra-standard customization hooks that +can be used to tweak the behaviour of the system. See Customization Hooks for Users. +

    +

    sb-aclrepl provides an Allegro CL -style toplevel for SBCL, +as an alternative to the classic CMUCL-style one. See sb-aclrepl. +

    +
    +
    CLTL2 Compatibility Layer
    +

    sb-cltl2 module provides compiler-let and environment +access functionality described in Common Lisp The Language, 2nd +Edition which were removed from the language during the ANSI +standardization process. +

    +
    +
    Executable Delivery
    +

    The :executable argument to Function sb-ext save-lisp-and-die can produce a ‘standalone’ executable +containing both an image of the current Lisp session and an SBCL +runtime. +

    +
    +
    Bitwise Rotation
    +

    sb-rotate-byte provides an efficient primitive for bitwise +rotation of integers, an operation required by e.g. numerous +cryptographic algorithms, but not available as a primitive in ANSI +Common Lisp. See sb-rotate-byte. +

    +
    +
    Test Harness
    +

    sb-rt module is a simple yet attractive regression and +unit-test framework. +

    +
    +
    MD5 Sums
    +

    sb-md5 is an implementation of the MD5 message digest algorithm +for Common Lisp, using the modular arithmetic optimizations provided +by SBCL. See sb-md5. +

    +
    +
    + + + + +
    +
    +

    +Next: , Previous: , Up: Introduction   [Contents][Index]

    +
    +

    2.3 Idiosyncrasies

    + +

    The information in this section describes some of the ways that SBCL +deals with choices that the ANSI standard leaves to the +implementation. +

    + + + + + + +
    • Declarations   +
    • FASL Format   +
    • Compiler-only Implementation   +
    • Defining Constants   +
    • Style Warnings   +
    + +
    +
    +

    +Next: , Up: Idiosyncrasies   [Contents][Index]

    +
    +

    2.3.1 Declarations

    + +

    Declarations are generally treated as assertions. This general +principle, and its implications, and the bugs which still keep the +compiler from quite satisfying this principle, are discussed in +Declarations as Assertions. +

    + +
    +
    +

    +Next: , Previous: , Up: Idiosyncrasies   [Contents][Index]

    +
    +

    2.3.2 FASL Format

    + +

    SBCL fasl-format is binary compatible only with the exact SBCL version +it was generated with. While this is obviously suboptimal, it has +proven more robust than trying to maintain fasl compatibility across +versions: accidentally breaking things is far too easy, and can lead +to hard to diagnose bugs. +

    +

    The following snippet handles fasl recompilation automatically for +ASDF-based systems, and makes a good candidate for inclusion in +the user or system initialization file (see Initialization Files.) +

    +
    +
    (require :asdf)
+
+;;; If a fasl was stale, try to recompile and load (once).
+(defmethod asdf:perform :around ((o asdf:load-op)
+                                 (c asdf:cl-source-file))
+   (handler-case (call-next-method o c)
+      ;; If a fasl was stale, try to recompile and load (once).
+      (sb-ext:invalid-fasl ()
+         (asdf:perform (make-instance 'asdf:compile-op) c)
+         (call-next-method))))
+
    + + +
    +
    +

    +Next: , Previous: , Up: Idiosyncrasies   [Contents][Index]

    +
    +

    2.3.3 Compiler-only Implementation

    + +

    SBCL is essentially a compiler-only implementation of Common Lisp. +That is, for all but a few special cases, eval creates a lambda +expression, calls compile on the lambda expression to create a +compiled function, and then calls funcall on the resulting +function object. A more traditional interpreter is also available on +default builds; it is usually only called internally. This is +explicitly allowed by the ANSI standard, but leads to some oddities; +e.g. at default settings, functionp and +compiled-function-p are equivalent, and they collapse into the +same function when SBCL is built without the interpreter. +

    +
    +
    +

    +Next: , Previous: , Up: Idiosyncrasies   [Contents][Index]

    +
    +

    2.3.4 Defining Constants

    + + +

    SBCL is quite strict about ANSI’s definition of defconstant. +ANSI says that doing defconstant of the same symbol more than +once is undefined unless the new value is eql to the old value. +Conforming to this specification is a nuisance when the “constant” +value is only constant under some weaker test like string= or +equal. +

    +

    It’s especially annoying because, in SBCL, defconstant takes +effect not only at load time but also at compile time, so that just +compiling and loading reasonable code like +

    +
    (defconstant +foobyte+ '(1 4))
+
    +

    runs into this undefined behavior. Many implementations of Common Lisp +try to help the programmer around this annoyance by silently accepting +the undefined code and trying to do what the programmer probably +meant. +

    +

    SBCL instead treats the undefined behavior as an error. Often such +code can be rewritten in portable ANSI Common Lisp which has the +desired behavior. E.g., the code above can be given an exactly defined +meaning by replacing defconstant either with +defparameter or with a customized macro which does the right +thing, e.g. +

    +
    (defmacro define-constant (name value &optional doc)
+  `(defconstant ,name (if (boundp ',name) (symbol-value ',name) ,value)
+                      ,@(when doc (list doc))))
+
    +

    or possibly along the lines of the defconstant-eqx macro used +internally in the implementation of SBCL itself. In circumstances +where this is not appropriate, the programmer can handle the condition +type sb-ext:defconstant-uneql, and choose either the +continue or abort restart as appropriate. +

    +
    +
    +

    +Previous: , Up: Idiosyncrasies   [Contents][Index]

    +
    +

    2.3.5 Style Warnings

    + +

    SBCL gives style warnings about various kinds of perfectly legal code, +e.g. +

    +
      +
    • multiple defuns of the same symbol in different units; + +
    • special variables not named in the conventional *foo* style, +and lexical variables unconventionally named in the *foo* style + +
    + +

    This causes friction with people who point out that other ways of +organizing code (especially avoiding the use of defgeneric) are +just as aesthetically stylish. However, these warnings should be read +not as “warning, bad aesthetics detected, you have no style” but +“warning, this style keeps the compiler from understanding the code +as well as you might like.” That is, unless the compiler warns about +such conditions, there’s no way for the compiler to warn about some +programming errors which would otherwise be easy to overlook. (Related +bug: The warning about multiple defuns is pointlessly annoying +when you compile and then load a function containing defun +wrapped in eval-when, and ideally should be suppressed in that +case, but still isn’t as of SBCL 0.7.6.) +

    + + + +
    +
    +

    +Next: , Previous: , Up: Introduction   [Contents][Index]

    +
    +

    2.4 Development Tools

    + + + + + +
    • Editor Integration   +
    • Language Reference   +
    • Generating Executables   +
    + +
    +
    +

    +Next: , Up: Development Tools   [Contents][Index]

    +
    +

    2.4.1 Editor Integration

    + +

    Though SBCL can be used running “bare”, the recommended mode of +development is with an editor connected to SBCL, supporting not +only basic lisp editing (paren-matching, etc), but providing among +other features an integrated debugger, interactive compilation, and +automated documentation lookup. +

    +

    Currently SLIME1 (Superior Lisp Interaction +Mode for Emacs) together with Emacs is recommended for use with +SBCL, though other options exist as well. +

    +

    SLIME can be downloaded from +http://www.common-lisp.net/project/slime/. +

    +
    +
    +

    +Next: , Previous: , Up: Development Tools   [Contents][Index]

    +
    +

    2.4.2 Language Reference

    + +

    CLHS (Common Lisp Hyperspec) is a hypertext version of the ANSI +standard, made freely available by LispWorks – an invaluable +reference. +

    +

    See: http://www.lispworks.com/reference/HyperSpec/index.html +

    +
    +
    +

    +Previous: , Up: Development Tools   [Contents][Index]

    +
    +

    2.4.3 Generating Executables

    + +

    SBCL can generate stand-alone executables. The generated executables +include the SBCL runtime itself, so no restrictions are placed on +program functionality. For example, a deployed program can call +compile and load, which requires the compiler to be present +in the executable. For further information, See Function sb-ext save-lisp-and-die. +

    + +
    +
    +

    +Next: , Previous: , Up: Introduction   [Contents][Index]

    +
    +

    2.5 More SBCL Information

    + + + + + + +
    • SBCL Homepage   +
    • Online Documentation   +
    • Additional Documentation Files   +
    • Internals Documentation   +
    + +
    +
    +

    +Next: , Up: More SBCL Information   [Contents][Index]

    +
    +

    2.5.1 SBCL Homepage

    + +

    The SBCL website at http://www.sbcl.org/ has some general +information, plus links to mailing lists devoted to SBCL, and to +archives of these mailing lists. Subscribing to the mailing lists +sbcl-help and sbcl-announce is recommended: both are +fairly low-volume, and help you keep abreast with SBCL development. +

    +
    +
    +

    +Next: , Previous: , Up: More SBCL Information   [Contents][Index]

    +
    +

    2.5.2 Online Documentation

    + +

    Documentation for non-ANSI extensions for various commands is +available online from the SBCL executable itself. The extensions +for functions which have their own command prompts (e.g. the debugger, +and inspect) are documented in text available by typing +help at their command prompts. The extensions for functions +which don’t have their own command prompt (such as trace) are +described in their documentation strings, unless your SBCL was +compiled with an option not to include documentation strings, in which +case the documentation strings are only readable in the source code. +

    +
    +
    +

    +Next: , Previous: , Up: More SBCL Information   [Contents][Index]

    +
    +

    2.5.3 Additional Documentation Files

    + +

    Besides this user manual both SBCL source and binary distributions +include some other SBCL-specific documentation files, which should be +installed along with this manual on your system, e.g. in +/usr/local/share/doc/sbcl/. +

    +
    +
    COPYING
    +

    Licence and copyright summary. +

    +
    +
    CREDITS
    +

    Authorship information on various parts of SBCL. +

    +
    +
    INSTALL
    +

    Covers installing SBCL from both source and binary distributions on +your system, and also has some installation related troubleshooting +information. +

    +
    +
    NEWS
    +

    Summarizes changes between various SBCL versions. +

    +
    +
    + +
    +
    +

    +Previous: , Up: More SBCL Information   [Contents][Index]

    +
    +

    2.5.4 Internals Documentation

    + +

    If you’re interested in the development of the SBCL system itself, +then subscribing to sbcl-devel is a good idea. +

    +

    SBCL internals documentation – besides comments in the source – is +currently maintained as a wiki-like website: +http://sbcl-internals.cliki.net/. +

    +

    Some low-level information describing the programming details of the +conversion from CMUCL to SBCL is available in the +doc/FOR-CMUCL-DEVELOPERS file in the SBCL distribution, though +it is not installed by default. +

    +
    +
    +

    +Next: , Previous: , Up: Introduction   [Contents][Index]

    +
    +

    2.6 More Common Lisp Information

    + + + + + +
    • Internet Community   +
    • Third-party Libraries   +
    • Common Lisp Books   +
    + +
    +
    +

    +Next: , Up: More Common Lisp Information   [Contents][Index]

    +
    +

    2.6.1 Internet Community

    + + +

    The Common Lisp internet community is fairly diverse: +news://comp.lang.lisp is fairly high volume newsgroup, but has +a rather poor signal/noise ratio. Various special interest mailing +lists and IRC tend to provide more content and less flames. +http://www.lisp.org and http://www.cliki.net contain +numerous pointers places in the net where lispers talks shop. +

    +
    +
    +

    +Next: , Previous: , Up: More Common Lisp Information   [Contents][Index]

    +
    +

    2.6.2 Third-party Libraries

    + +

    For a wealth of information about free Common Lisp libraries and tools +we recommend checking out CLiki: http://www.cliki.net/. +

    +
    +
    +

    +Previous: , Up: More Common Lisp Information   [Contents][Index]

    +
    +

    2.6.3 Common Lisp Books

    + +

    If you’re not a programmer and you’re trying to learn, many +introductory Lisp books are available. However, we don’t have any +standout favorites. If you can’t decide, try checking the Usenet +news://comp.lang.lisp FAQ for recent recommendations. +

    + +

    If you are an experienced programmer in other languages but need to +learn about Common Lisp, some books stand out: +

    +
    +
    Practical Common Lisp, by Peter Seibel
    +

    An excellent introduction to the language, covering both the basics +and “advanced topics” like macros, CLOS, and packages. Available +both in print format and on the web: http://www.gigamonkeys.com/book/. +

    +
    +
    Paradigms Of Artificial Intelligence Programming, by Peter Norvig
    +

    Good information on general Common Lisp programming, and many +nontrivial examples. Whether or not your work is AI, it’s a very good +book to look at. +

    +
    +
    On Lisp, by Paul Graham
    +

    An in-depth treatment of macros, but not recommended as a first Common +Lisp book, since it is slightly pre-ANSI so you need to be on your +guard against non-standard usages, and since it doesn’t really even +try to cover the language as a whole, focusing solely on macros. +Downloadable from http://www.paulgraham.com/onlisp.html. +

    +
    +
    Object-Oriented Programming In Common Lisp, by Sonya Keene
    +

    With the exception of Practical Common Lisp most introductory +books don’t emphasize CLOS. This one does. Even if you’re very +knowledgeable about object oriented programming in the abstract, it’s +worth looking at this book if you want to do any OO in Common Lisp. +Some abstractions in CLOS (especially multiple dispatch) go beyond +anything you’ll see in most OO systems, and there are a number of +lesser differences as well. This book tends to help with the culture +shock. +

    +
    +
    Art Of Metaobject Programming, by Gregor Kiczales et al.
    +

    Currently the prime source of information on the Common Lisp Metaobject +Protocol, which is supported by SBCL. Section 2 (Chapters 5 and 6) are +freely available at http://mop.lisp.se/www.alu.org/mop/. +

    +
    +
    + + + + +
    +
    +

    +Previous: , Up: Introduction   [Contents][Index]

    +
    +

    2.7 History and Implementation of SBCL

    + +

    You can work productively with SBCL without knowing or +understanding anything about where it came from, how it is +implemented, or how it extends the ANSI Common Lisp standard. However, +a little knowledge can be helpful in order to understand error +messages, to troubleshoot problems, to understand why some parts of +the system are better debugged than others, and to anticipate which +known bugs, known performance problems, and missing extensions are +likely to be fixed, tuned, or added. +

    +

    SBCL is descended from CMUCL, which is itself descended from Spice +Lisp, including early implementations for the Mach operating system on +the IBM RT, back in the 1980s. Some design decisions from that time are +still reflected in the current implementation: +

    +
      +
    • The system expects to be loaded into a fixed-at-compile-time location +in virtual memory, and also expects the location of all of its heap +storage to be specified at compile time. + +
    • The system overcommits memory, allocating large amounts of address +space from the system (often more than the amount of virtual memory +available) and then failing if ends up using too much of the allocated +storage. + +
    • The system is implemented as a C program which is responsible for +supplying low-level services and loading a Lisp .core +file. + +
    + + +

    SBCL also inherited some newer architectural features from CMUCL. The +most important is that on some architectures it has a generational +garbage collector (“GC”), which has various implications (mostly +good) for performance. These are discussed in another chapter, +Efficiency. +

    +

    SBCL has diverged from CMUCL in that SBCL is now essentially a +“compiler-only implementation” of Common Lisp. This is a change in +implementation strategy, taking advantage of the freedom “any of these +facilities might share the same execution strategy” guaranteed in the +ANSI specification section 3.1 (“Evaluation”). It does not mean SBCL +can’t be used interactively, and in fact the change is largely invisible +to the casual user, since SBCL still can and does execute code +interactively by compiling it on the fly. (It is visible if you know how +to look, like using compiled-function-p; and it is visible in the +way that SBCL doesn’t have many bugs which behave differently in +interpreted code than in compiled code.) What it means is that in SBCL, +the eval function only truly “interprets” a few easy kinds of +forms, such as symbols which are boundp. More complicated forms +are evaluated by calling compile and then calling funcall +on the returned result. +

    +

    The direct ancestor of SBCL is the x86 port of CMUCL. This port was in +some ways the most cobbled-together of all the CMUCL ports, since a +number of strange changes had to be made to support the register-poor +x86 architecture. Some things (like tracing and debugging) do not work +particularly well there. SBCL should be able to improve in these areas +(and has already improved in some other areas), but it takes a while. +

    + +

    On the x86 SBCL – like the x86 port of CMUCL – uses a +conservative GC. This means that it doesn’t maintain a strict +separation between tagged and untagged data, instead treating some +untagged data (e.g. raw floating point numbers) as possibly-tagged +data and so not collecting any Lisp objects that they point to. This +has some negative consequences for average time efficiency (though +possibly no worse than the negative consequences of trying to +implement an exact GC on a processor architecture as register-poor as +the X86) and also has potentially unlimited consequences for +worst-case memory efficiency. In practice, conservative garbage +collectors work reasonably well, not getting anywhere near the worst +case. But they can occasionally cause odd patterns of memory usage. +

    +

    The fork from CMUCL was based on a major rewrite of the system +bootstrap process. CMUCL has for many years tolerated a very unusual +“build” procedure which doesn’t actually build the complete system +from scratch, but instead progressively overwrites parts of a running +system with new versions. This quasi-build procedure can cause various +bizarre bootstrapping hangups, especially when a major change is made +to the system. It also makes the connection between the current source +code and the current executable more tenuous than in other software +systems – it’s easy to accidentally “build” a CMUCL system +containing characteristics not reflected in the current version of the +source code. +

    +

    Other major changes since the fork from CMUCL include +

    +
      +
    • SBCL has removed many CMUCL extensions, (e.g. IP networking, +remote procedure call, Unix system interface, and X11 interface) from +the core system. Most of these are available as contributed modules +(distributed with SBCL) or third-party modules instead. + +
    • SBCL has deleted or deprecated some nonstandard features and code +complexity which helped efficiency at the price of +maintainability. For example, the SBCL compiler no longer implements +memory pooling internally (and so is simpler and more maintainable, +but generates more garbage and runs more slowly), and various +block-compilation efficiency-increasing extensions to the language +have been deleted or are no longer used in the implementation of SBCL +itself. + +
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    3 Starting and Stopping

    + + + + + + + +
    • Starting SBCL   +
    • Stopping SBCL   +
    • Command Line Options   +
    • Initialization Files   +
    • Initialization and Exit Hooks   +
    + +
    +
    +

    +Next: , Up: Starting and Stopping   [Contents][Index]

    +
    +

    3.1 Starting SBCL

    + + + + + +
    • Running from Shell   +
    • Running from Emacs   +
    • Shebang Scripts   +
    + +
    +
    +

    +Next: , Up: Starting SBCL   [Contents][Index]

    +
    +

    3.1.1 From Shell to Lisp

    + +

    To run SBCL type sbcl at the command line. +

    +

    You should end up in the toplevel REPL (read, eval, print +-loop), where you can interact with SBCL by typing expressions. +

    +
    +
    $ sbcl
+This is SBCL 0.8.13.60, an implementation of ANSI Common Lisp.
+More information about SBCL is available at <http://www.sbcl.org/>.
+
+SBCL is free software, provided as is, with absolutely no warranty.
+It is mostly in the public domain; some portions are provided under
+BSD-style licenses.  See the CREDITS and COPYING files in the
+distribution for more information.
+* (+ 2 2)
+
+4
+* (exit)
+$
+
    + +

    See also Command Line Options and Stopping SBCL. +

    +
    +
    +

    +Next: , Previous: , Up: Starting SBCL   [Contents][Index]

    +
    +

    3.1.2 Running from Emacs

    + +

    To run SBCL as an inferior-lisp from Emacs in your .emacs do +something like: +

    +
    +
    ;;; The SBCL binary and command-line arguments
+(setq inferior-lisp-program "/usr/local/bin/sbcl --noinform")
+
    + +

    For more information on using SBCL with Emacs, see Editor Integration. +

    + +
    +
    +

    +Previous: , Up: Starting SBCL   [Contents][Index]

    +
    +

    3.1.3 Shebang Scripts

    + + +

    Standard Unix tools that are interpreters follow a common command line +protocol that is necessary to work with “shebang scripts”. SBCL supports +this via the --script command line option. +

    +

    Example file (hello.lisp): +

    +
    +
    #!/usr/local/bin/sbcl --script
+(write-line "Hello, World!")
+
    + +

    Usage examples: +

    +
    +
    $ ./hello.lisp
+Hello, World!
+
    + +
    +
    $ sbcl --script hello.lisp
+Hello, World!
+
    + +
    +
    +

    +Next: , Previous: , Up: Starting and Stopping   [Contents][Index]

    +
    +

    3.2 Stopping SBCL

    + + + + + + +
    • Exit   +
    • End of File   +
    • Saving a Core Image   +
    • Exit on Errors   +
    + +
    +
    +

    +Next: , Up: Stopping SBCL   [Contents][Index]

    +
    +

    3.2.1 Exit

    + +

    SBCL can be stopped at any time by calling sb-ext:exit, +optionally returning a specified numeric value to the calling process. +See Threading for information about terminating individual threads. +

    +
    +
    Function: exit [sb-ext] &key code abort timeout
    +

    Terminates the process, causing sbcl to exit with code. code +defaults to 0 when abort is false, and 1 when it is true. +

    +

    When abort is false (the default), current thread is first unwound, +*exit-hooks* are run, other threads are terminated, and standard +output streams are flushed before sbcl calls exit(3) -- at which point +atexit(3) functions will run. If multiple threads call exit with abort +being false, the first one to call it will complete the protocol. +

    +

    When abort is true, sbcl exits immediately by calling _exit(2) without +unwinding stack, or calling exit hooks. Note that _exit(2) does not +call atexit(3) functions unlike exit(3). +

    +

    Recursive calls to exit cause exit to behave as if abort was true. +

    +

    timeout controls waiting for other threads to terminate when abort is +nil. Once current thread has been unwound and *exit-hooks* have been +run, spawning new threads is prevented and all other threads are +terminated by calling terminate-thread on them. The system then waits +for them to finish using join-thread, waiting at most a total timeout +seconds for all threads to join. Those threads that do not finish +in time are simply ignored while the exit protocol continues. timeout +defaults to *exit-timeout*, which in turn defaults to 60. timeout nil +means to wait indefinitely. +

    +

    Note that timeout applies only to join-thread, not *exit-hooks*. Since +terminate-thread is asynchronous, getting multithreaded application +termination with complex cleanups right using it can be tricky. To +perform an orderly synchronous shutdown use an exit hook instead of +relying on implicit thread termination. +

    +

    Consequences are unspecified if serious conditions occur during exit +excepting errors from *exit-hooks*, which cause warnings and stop +execution of the hook that signaled, but otherwise allow the exit +process to continue normally. +

    + +
    +
    +

    +Next: , Previous: , Up: Stopping SBCL   [Contents][Index]

    +
    +

    3.2.2 End of File

    + +

    By default SBCL also exits on end of input, caused either by user +pressing Control-D on an attached terminal, or end of input when +using SBCL as part of a shell pipeline. +

    +
    +
    +

    +Next: , Previous: , Up: Stopping SBCL   [Contents][Index]

    +
    +

    3.2.3 Saving a Core Image

    + +

    SBCL has the ability to save its state as a file for later +execution. This functionality is important for its bootstrapping +process, and is also provided as an extension to the user. +

    +
    +
    Function: save-lisp-and-die [sb-ext] core-file-name &key toplevel executable save-runtime-options callable-exports purify root-structures environment-name compression
    +

    Save a "core image", i.e. enough information to restart a Lisp +process later in the same state, in the file of the specified name. +Only global state is preserved: the stack is unwound in the process. +

    +

    The following &key arguments are defined: +

    + +
    +
    :toplevel
    +

    The function to run when the created core file is resumed. The + default function handles command line toplevel option processing + and runs the top level read-eval-print loop. This function returning + is equivalent to (sb-ext:exit :code 0) being called. +

    +

    toplevel functions should always provide an abort restart: otherwise + code they call will run without one. +

    + +
    +
    :executable
    +

    If true, arrange to combine the sbcl runtime and the core image + to create a standalone executable. If false (the default), the + core image will not be executable on its own. Executable images + always behave as if they were passed the –noinform runtime option. +

    + +
    +
    :save-runtime-options
    +

    If true, values of runtime options –dynamic-space-size and + –control-stack-size that were used to start sbcl are stored in + the standalone executable, and restored when the executable is + run. This also inhibits normal runtime option processing, causing + all command line arguments to be passed to the toplevel. + Meaningless if :executable is nil. +

    + +
    +
    :callable-exports
    +

    This should be a list of symbols to be initialized to the + appropriate alien callables on startup. All exported symbols should + be present as global symbols in the symbol table of the runtime + before the saved core is loaded. When this list is non-empty, the + :toplevel argument cannot be supplied. +

    + +
    +
    :purify
    +

    If true (the default), then some objects in the restarted core will + be memory-mapped as read-only. Among those objects are numeric vectors + that were determined to be compile-time constants, and any immutable + values according to the language specification such as symbol names. +

    + +
    +
    :root-structures
    +

    This should be a list of the main entry points in any newly loaded + systems. This need not be supplied, but locality and/or gc performance + may be better if they are. This has two different but related meanings: + If :purify is true - and only for cheneygc - the root structures + are those which anchor the set of objects moved into static space. + On gencgc - and only on platforms supporting immobile code - these are + the functions and/or function-names which commence a depth-first scan + of code when reordering based on the statically observable call chain. + The complete set of reachable objects is not affected per se. + This argument is meaningless if neither enabling precondition holds. +

    + +
    +
    :environment-name
    +

    This has no purpose; it is accepted only for legacy compatibility. +

    + +
    +
    :compression
    +

    This is only meaningful if the runtime was built with the :sb-core-compression + feature enabled. If nil (the default), saves to uncompressed core files. If + :sb-core-compression was enabled at build-time, the argument may also be + an integer from -7 to 22, corresponding to zstd compression levels, or t + (which is equivalent to the default compression level, 9). +

    + +
    +
    :application-type
    +

    Present only on Windows and is meaningful only with :executable t. + Specifies the subsystem of the executable, :console or :gui. + The notable difference is that :gui doesn’t automatically create a console + window. The default is :console. +

    +
    +
    + +

    The save/load process changes the values of some global variables: +

    + +
    +
    *standard-output*, *debug-io*, etc.
    +

    Everything related to open streams is necessarily changed, since + the os won’t let us preserve a stream across save and load. +

    + +
    +
    *default-pathname-defaults*
    +

    This is reinitialized to reflect the working directory where the + saved core is loaded. +

    +
    +
    + +

    save-lisp-and-die interacts with sb-alien:load-shared-object: see its +documentation for details. +

    +

    On threaded platforms only a single thread may remain running after +sb-ext:*save-hooks* have run. Applications using multiple threads can +be save-lisp-and-die friendly by registering a save-hook that quits +any additional threads, and an init-hook that restarts them. +

    +

    This implementation is not as polished and painless as you might like: +

      +
    • It corrupts the current Lisp image enough that the current process + needs to be killed afterwards. This can be worked around by forking + another process that saves the core. +
    • There is absolutely no binary compatibility of core images between + different runtime support programs. Even runtimes built from the same + sources at different times are treated as incompatible for this + purpose. +
    +

    This isn’t because we like it this way, but just because there don’t +seem to be good quick fixes for either limitation and no one has been +sufficiently motivated to do lengthy fixes. +

    +
    +
    Variable: *save-hooks* [sb-ext]
    +

    A list of function designators which are called in an unspecified +order before creating a saved core image. +

    +

    Unused by sbcl itself: reserved for user and applications. +

    + +

    In cases where the standard initialization files have already been loaded +into the saved core, and alternative ones should be used (or none at all), +SBCL allows customizing the initfile pathname computation. +

    +
    +
    Variable: *sysinit-pathname-function* [sb-ext]
    +

    Designator for a function of zero arguments called to obtain a +pathname designator for the default sysinit file, or nil. If the +function returns nil, no sysinit file is used unless one has been +specified on the command-line. +

    +
    +
    Variable: *userinit-pathname-function* [sb-ext]
    +

    Designator for a function of zero arguments called to obtain a +pathname designator or a stream for the default userinit file, or nil. +If the function returns nil, no userinit file is used unless one has +been specified on the command-line. +

    + +

    To facilitate distribution of SBCL applications using external +resources, the filesystem location of the SBCL core file being used is +available from Lisp. +

    +
    +
    Variable: *core-pathname* [sb-ext]
    +

    The absolute pathname of the running sbcl core. +

    + +
    +
    +

    +Previous: , Up: Stopping SBCL   [Contents][Index]

    +
    +

    3.2.4 Exit on Errors

    + +

    SBCL can also be configured to exit if an unhandled error occurs, +which is mainly useful for acting as part of a shell pipeline; doing +so under most other circumstances would mean giving up large parts of +the flexibility and robustness of Common Lisp. See Debugger Entry. +

    +
    +
    +

    +Next: , Previous: , Up: Starting and Stopping   [Contents][Index]

    +
    +

    3.3 Command Line Options

    + + +

    Command line options can be considered an advanced topic; for ordinary +interactive use, no command line arguments should be necessary. +

    +

    In order to understand the command line argument syntax for SBCL, it +is helpful to understand that the SBCL system is implemented as two +components, a low-level runtime environment written in C and a +higher-level system written in Common Lisp itself. Some command line +arguments are processed during the initialization of the low-level +runtime environment, some command line arguments are processed during +the initialization of the Common Lisp system, and any remaining +command line arguments are passed on to user code. +

    +

    The full, unambiguous syntax for invoking SBCL at the command line is: +

    +

    sbcl runtime-option* --end-runtime-options toplevel-option* --end-toplevel-options user-options* +

    +

    For convenience, the --end-runtime-options and +--end-toplevel-options elements can be omitted. Omitting these +elements can be convenient when you are running the program +interactively, and you can see that no ambiguities are possible with +the option values you are using. Omitting these elements is probably a +bad idea for any batch file where any of the options are under user +control, since it makes it impossible for SBCL to detect erroneous +command line input, so that erroneous command line arguments will be +passed on to the user program even if they was intended for the +runtime system or the Lisp system. +

    + + + +
    • Runtime Options   +
    • Toplevel Options   +
    + +
    +
    +

    +Next: , Up: Command Line Options   [Contents][Index]

    +
    +

    3.3.1 Runtime Options

    + +
    +
    --core corefilename
    +

    Run the specified Lisp core file instead of the default. Note that if +the Lisp core file is a user-created core file, it may run a +nonstandard toplevel which does not recognize the standard toplevel +options. +

    +
    +
    --dynamic-space-size megabytes
    +

    Size of the dynamic space reserved on startup in megabytes. Default +value is platform dependent. +

    +
    +
    --control-stack-size megabytes
    +

    Size of control stack reserved for each thread in megabytes. Default +value is 2. +

    +
    +
    --noinform
    +

    Suppress the printing of any banner or other informational message at +startup. This makes it easier to write Lisp programs which work +cleanly in Unix pipelines. See also the --noprint and +--disable-debugger options. +

    +
    +
    --disable-ldb
    +
    + + +

    Disable the low-level debugger. Only effective if SBCL is compiled +with LDB. +

    +
    +
    --lose-on-corruption
    +
    +

    There are some dangerous low level errors (for instance, control stack +exhausted, memory fault) that (or whose handlers) can corrupt the +image. By default SBCL prints a warning, then tries to continue and +handle the error in Lisp, but this will not always work and SBCL may +malfunction or even hang. With this option, upon encountering such an +error SBCL will invoke ldb (if present and enabled) or else exit. +

    + +
    +
    --script filename
    +

    As a runtime option this is equivalent to --noinform +--disable-ldb --lose-on-corruption +--end-runtime-options --script filename. See the +description of --script as a toplevel option below. If there +are no other command line arguments following --script, the +filename argument can be omitted. +

    + +
    +
    --merge-core-pages
    +

    When platform support is present, provide hints to the operating system +that identical pages may be shared between processes until they are +written to. This can be useful to reduce the memory usage on systems +with multiple SBCL processes started from similar but differently-named +core files, or from compressed cores. Without platform support, do +nothing. By default only compressed cores trigger hinting. +

    +
    +
    --no-merge-core-pages
    +

    Ensures that no sharing hint is provided to the operating system. +

    +
    +
    --help
    +

    Print some basic information about SBCL, then exit. +

    +
    +
    --version
    +

    Print SBCL’s version information, then exit. +

    +
    +
    + +

    In the future, runtime options may be added to control behaviour such +as lazy allocation of memory. +

    +

    Runtime options, including any –end-runtime-options option, are +stripped out of the command line before the Lisp toplevel logic gets a +chance to see it. +

    +
    +
    +

    +Previous: , Up: Command Line Options   [Contents][Index]

    +
    +

    3.3.2 Toplevel Options

    + +
    +
    --sysinit filename
    +

    Load filename instead of the default system initialization file +(see Initialization Files.) +

    +
    +
    --no-sysinit
    +

    Don’t load a system-wide initialization file. If this option is given, +the --sysinit option is ignored. +

    +
    +
    --userinit filename
    +

    Load filename instead of the default user initialization file +(see Initialization Files.) +

    +
    +
    --no-userinit
    +

    Don’t load a user initialization file. If this option is given, +the --userinit option is ignored. +

    +
    +
    --eval command
    +

    After executing any initialization file, but before starting the +read-eval-print loop on standard input, read and evaluate the command +given. More than one --eval option can be used, and all will be +read and executed, in the order they appear on the command line. +

    +
    +
    --load filename
    +

    This is equivalent to --eval '(load "filename")'. The +special syntax is intended to reduce quoting headaches when invoking +SBCL from shell scripts. +

    +
    +
    --noprint
    +

    When ordinarily the toplevel "read-eval-print loop" would be executed, +execute a "read-eval loop" instead, i.e. don’t print a prompt and +don’t echo results. Combined with the --noinform runtime +option, this makes it easier to write Lisp "scripts" which work +cleanly in Unix pipelines. +

    +
    +
    --disable-debugger
    +

    By default when SBCL encounters an error, it enters the builtin +debugger, allowing interactive diagnosis and possible intercession. +This option disables the debugger, causing errors to print a backtrace +and exit with status 1 instead. When given, this option takes effect +before loading of initialization files or processing --eval and +--load options. See sb-ext:disable-debugger for details. +See Debugger Entry. +

    +
    +
    --script filename
    +

    Implies --no-userinit --no-sysinit +--disable-debugger --end-toplevel-options. +

    +

    Causes the system to load the specified file instead of entering the +read-eval-print-loop, and exit afterwards. If the file begins with a +shebang line, it is ignored. +

    +

    If there are no other command line arguments following, the filename +can be omitted: this causes the script to be loaded from standard +input instead. Shebang lines in standard input script are currently +not ignored. +

    +

    In either case, if there is an unhandled error (e.g. end of file, or a +broken pipe) on either standard input, standard output, or standard +error, the script silently exits with code 0. This allows e.g. safely +piping output from SBCL to head -n1 or similar. +

    +
    +
    + +
    +
    +

    +Next: , Previous: , Up: Starting and Stopping   [Contents][Index]

    +
    +

    3.4 Initialization Files

    + +

    SBCL processes initialization files with read and eval, +not load; hence initialization files can be used to set startup +*package* and *readtable*, and for proclaiming a global +optimization policy. +

    +
    +
    System Initialization File
    +

    Defaults to $SBCL_HOME/sbclrc, or if that doesn’t exist to +/etc/sbclrc. Can be overridden with the command line option +--sysinit or --no-sysinit (see Toplevel Options). +

    +

    The system initialization file is intended for system administrators +and software packagers to configure locations of installed third party +modules, etc. +

    +
    +
    User Initialization File
    +

    Defaults to $HOME/.sbclrc. Can be overridden with the +command line option --userinit or --no-userinit +(see Toplevel Options). +

    +

    The user initialization file is intended for personal customizations, +such as loading certain modules at startup, defining convenience +functions to use in the REPL, handling automatic recompilation +of FASLs (see FASL Format), etc. +

    +
    +
    + +

    Neither initialization file is required. +

    +
    +
    +

    +Previous: , Up: Starting and Stopping   [Contents][Index]

    +
    +

    3.5 Initialization and Exit Hooks

    + +

    SBCL provides hooks into the system initialization and exit. +

    +
    +
    Variable: *init-hooks* [sb-ext]
    +

    A list of function designators which are called in an unspecified +order when a saved core image starts up, after the system itself has +been initialized, but before non-user threads such as the finalizer +thread have been started. +

    +

    Unused by sbcl itself: reserved for user and applications. +

    +
    +
    Variable: *exit-hooks* [sb-ext]
    +

    A list of function designators which are called in an unspecified +order when sbcl process exits. +

    +

    Unused by sbcl itself: reserved for user and applications. +

    +

    Using (sb-ext:exit :abort t), or calling exit(3) directly circumvents +these hooks. +

    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    4 Compiler

    + +

    This chapter will discuss most compiler issues other than efficiency, +including compiler error messages, the SBCL compiler’s unusual +approach to type safety in the presence of type declarations, the +effects of various compiler optimization policies, and the way that +inlining and open coding may cause optimized code to differ from a +naive translation. Efficiency issues are sufficiently varied and +separate that they have their own chapter, Efficiency. +

    + + + + + + + + +
    • Diagnostic Messages   +
    • Handling of Types   +
    • Compiler Policy   +
    • Compiler Errors   +
    • Open Coding and Inline Expansion   +
    • Interpreter   +
    • Advanced Compiler Use and Efficiency Hints   +
    + +
    +
    +

    +Next: , Up: Compiler   [Contents][Index]

    +
    +

    4.1 Diagnostic Messages

    + + + + + + + +
    • Controlling Verbosity   +
    • Diagnostic Severity   +
    • Understanding Compiler Diagnostics   +
    + +
    +
    +

    +Next: , Up: Diagnostic Messages   [Contents][Index]

    +
    +

    4.1.1 Controlling Verbosity

    + +

    The compiler can be quite verbose in its diagnostic reporting, rather +more then some users would prefer – the amount of noise emitted can +be controlled, however. +

    +

    To control emission of compiler diagnostics (of any severity other +than error: see Diagnostic Severity) use the +sb-ext:muffle-conditions and sb-ext:unmuffle-conditions +declarations, specifying the type of condition that is to be muffled +(the muffling is done using an associated muffle-warning restart). +

    +

    Global control: +

    +
    ;;; Muffle compiler-notes globally
+(declaim (sb-ext:muffle-conditions sb-ext:compiler-note))
+
    + +

    Local control: +

    +
    ;;; Muffle compiler-notes based on lexical scope
+(defun foo (x)
+  (declare (optimize speed) (fixnum x)
+           (sb-ext:muffle-conditions sb-ext:compiler-note))
+  (values (* x 5) ; no compiler note from this
+    (locally
+      (declare (sb-ext:unmuffle-conditions sb-ext:compiler-note))
+      ;; this one gives a compiler note
+      (* x -5))))
+
    + +
    +
    Declaration: muffle-conditions [sb-ext]
    +

    Syntax: type* +

    +

    Muffles the diagnostic messages that would be caused by compile-time +signals of given types. +

    + +
    +
    Declaration: unmuffle-conditions [sb-ext]
    +

    Syntax: type* +

    +

    Cancels the effect of a previous sb-ext:muffle-conditions +declaration. +

    + +

    Various details of how the compiler messages are printed can be +controlled via the alist +sb-ext:*compiler-print-variable-alist*. +

    +
    +
    Variable: *compiler-print-variable-alist* [sb-ext]
    +

    an association list describing new bindings for special variables +to be used by the compiler for error-reporting, etc. Eg. +

    +
    +
     ((*PRINT-LENGTH* . 10) (*PRINT-LEVEL* . 6) (*PRINT-PRETTY* . NIL))
+
    + +

    The variables in the car positions are bound to the values in the cdr +during the execution of some debug commands. When evaluating arbitrary +expressions in the debugger, the normal values of the printer control +variables are in effect. +

    +

    Initially empty, *compiler-print-variable-alist* is Typically used to +specify bindings for printer control variables. +

    + +

    For information about muffling warnings signaled outside of the +compiler, see Customization Hooks for Users. +

    + +
    +
    +

    +Next: , Previous: , Up: Diagnostic Messages   [Contents][Index]

    +
    +

    4.1.2 Diagnostic Severity

    + + + + + + + + +

    There are four levels of compiler diagnostic severity: +

    +
      +
    1. error +
    2. warning +
    3. style warning +
    4. note +
    + +

    The first three levels correspond to condition classes which are +defined in the ANSI standard for Common Lisp and which have special +significance to the compile and compile-file functions. +These levels of compiler error severity occur when the compiler +handles conditions of these classes. +

    +

    The fourth level of compiler error severity, note, corresponds +to the sb-ext:compiler-note, and is used for problems which are +too mild for the standard condition classes, typically hints about how +efficiency might be improved. The sb-ext:code-deletion-note, a +subtype of compiler-note, is signalled when the compiler +deletes user-supplied code after proving that the code in question is +unreachable. +

    +

    Future work for SBCL includes expanding this hierarchy of types to +allow more fine-grained control over emission of diagnostic messages. +

    +
    +
    Condition: compiler-note [sb-ext]
    +

    Class precedence list: compiler-note, condition, t +

    +

    Root of the hierarchy of conditions representing information discovered +by the compiler that the user might wish to know, but which does not merit +a style-warning (or any more serious condition). +

    +
    +
    Condition: code-deletion-note [sb-ext]
    +

    Class precedence list: code-deletion-note, compiler-note, condition, t +

    +

    A condition type signalled when the compiler deletes code that the user +has written, having proved that it is unreachable. +

    + + +
    +
    +

    +Previous: , Up: Diagnostic Messages   [Contents][Index]

    +
    +

    4.1.3 Understanding Compile Diagnostics

    + +

    The messages emitted by the compiler contain a lot of detail in a +terse format, so they may be confusing at first. The messages will be +illustrated using this example program: +

    +
    +
    (defmacro zoq (x)
+  `(roq (ploq (+ ,x 3))))
+
+(defun foo (y)
+  (declare (symbol y))
+  (zoq y))
+
    + +

    The main problem with this program is that it is trying to add +3 to a symbol. Note also that the functions roq and +ploq aren’t defined anywhere. +

    + + + + +
    • The Parts of a Compiler Diagnostic   +
    • The Original and Actual Source   +
    • The Processing Path   +
    + +
    +
    +

    +Next: , Up: Understanding Compiler Diagnostics   [Contents][Index]

    +
    +

    4.1.3.1 The Parts of a Compiler Diagnostic

    + +

    When processing this program, the compiler will produce this warning: +

    +
    +
    ; file: /tmp/foo.lisp
+; in: DEFUN FOO
+;     (ZOQ Y)
+; --> ROQ PLOQ
+; ==>
+;   (+ Y 3)
+;
+; caught WARNING:
+;   Asserted type NUMBER conflicts with derived type (VALUES SYMBOL &OPTIONAL).
+
    + +

    In this example we see each of the six possible parts of a compiler +diagnostic: +

    +
      +
    1. +‘file: /tmp/foo.lisp’ This is the name of the file that the +compiler read the relevant code from. The file name is displayed +because it may not be immediately obvious when there is an error +during compilation of a large system, especially when +with-compilation-unit is used to delay undefined warnings. + +
    2. ‘in: DEFUN FOO’ This is the definition top level form responsible +for the diagnostic. It is obtained by taking the first two elements of +the enclosing form whose first element is a symbol beginning with +“‘def’”. If there is no such enclosing “‘def’” form, +then the outermost form is used. If there are multiple ‘def’ +forms, then they are all printed from the outside in, separated by +‘=>’’s. In this example, the problem was in the defun for +foo. + +
    3. +‘(ZOQ Y)’ This is the original source form responsible for +the diagnostic. Original source means that the form directly appeared +in the original input to the compiler, i.e. in the lambda passed to +compile or in the top level form read from the source file. In +this example, the expansion of the zoq macro was responsible +for the message. + +
    4. +‘--> ROQ PLOQ’ This is the processing path that the +compiler used to produce the code that caused the message to be +emitted. The processing path is a representation of the evaluated +forms enclosing the actual source that the compiler encountered when +processing the original source. The path is the first element of each +form, or the form itself if the form is not a list. These forms result +from the expansion of macros or source-to-source transformation done +by the compiler. In this example, the enclosing evaluated forms are +the calls to roq and ploq. These calls resulted from the +expansion of the zoq macro. + +
    5. +‘==> (+ Y 3)’ This is the actual source responsible for the +diagnostic. If the actual source appears in the explanation, then we +print the next enclosing evaluated form, instead of printing the +actual source twice. (This is the form that would otherwise have been +the last form of the processing path.) In this example, the problem is +with the evaluation of the reference to the variable y. + +
    6. ‘caught WARNING: Asserted type NUMBER conflicts with derived type +(VALUES SYMBOL &OPTIONAL).’ This is the explanation of the +problem. In this example, the problem is that, while the call to ++ requires that its arguments are all of type number, +the compiler has derived that y will evaluate to a +symbol. Note that ‘(VALUES SYMBOL &OPTIONAL)’ expresses +that y evaluates to precisely one value. + +
    + +

    Note that each part of the message is distinctively marked: +

    +
      +
    • ‘file:’ and ‘in:’ mark the file and definition, +respectively. + +
    • The original source is an indented form with no prefix. + +
    • Each line of the processing path is prefixed with ‘-->’ + +
    • The actual source form is indented like the original source, but is +marked by a preceding ‘==>’ line. + +
    • The explanation is prefixed with the diagnostic severity, which can be +‘caught ERROR:’, ‘caught WARNING:’, ‘caught +STYLE-WARNING:’, or ‘note:’. + +
    + +

    Each part of the message is more specific than the preceding one. If +consecutive messages are for nearby locations, then the front part of +the messages would be the same. In this case, the compiler omits as +much of the second message as in common with the first. For example: +

    +
    +
    ; file: /tmp/foo.lisp
+; in: DEFUN FOO
+;     (ZOQ Y)
+; --> ROQ
+; ==>
+;   (PLOQ (+ Y 3))
+;
+; caught STYLE-WARNING:
+;   undefined function: PLOQ
+
+; ==>
+;   (ROQ (PLOQ (+ Y 3)))
+;
+; caught STYLE-WARNING:
+;   undefined function: ROQ
+
    + +

    In this example, the file, definition and original source are +identical for the two messages, so the compiler omits them in the +second message. If consecutive messages are entirely identical, then +the compiler prints only the first message, followed by: ‘[Last +message occurs repeats times]’ where repeats is the number +of times the message was given. +

    +

    If the source was not from a file, then no file line is printed. If +the actual source is the same as the original source, then the +processing path and actual source will be omitted. If no forms +intervene between the original source and the actual source, then the +processing path will also be omitted. +

    + +
    +
    +

    +Next: , Previous: , Up: Understanding Compiler Diagnostics   [Contents][Index]

    +
    +

    4.1.3.2 The Original and Actual Source

    + + + +

    The original source displayed will almost always be a list. If +the actual source for an message is a symbol, the original source will +be the immediately enclosing evaluated list form. So even if the +offending symbol does appear in the original source, the compiler will +print the enclosing list and then print the symbol as the actual +source (as though the symbol were introduced by a macro.) +

    +

    When the actual source is displayed (and is not a symbol), it +will always be code that resulted from the expansion of a macro or a +source-to-source compiler optimization. This is code that did not +appear in the original source program; it was introduced by the +compiler. +

    +

    Keep in mind that when the compiler displays a source form in an +diagnostic message, it always displays the most specific (innermost) +responsible form. For example, compiling this function +

    +
    +
    (defun bar (x)
+  (let (a)
+    (declare (fixnum a))
+    (setq a (foo x))
+    a))
+
    + +

    gives this error message +

    +
    +
    ; file: /tmp/foo.lisp
+; in: DEFUN BAR
+;     (LET (A)
+;     (DECLARE (FIXNUM A))
+;     (SETQ A (FOO X))
+;     A)
+;
+; caught WARNING:
+;   Asserted type FIXNUM conflicts with derived type (VALUES NULL &OPTIONAL).
+
    + +

    This message is not saying “there is a problem somewhere in this +let” – it is saying that there is a problem with the +let itself. In this example, the problem is that a’s +nil initial value is not a fixnum. +

    +
    +
    +

    +Previous: , Up: Understanding Compiler Diagnostics   [Contents][Index]

    +
    +

    4.1.3.3 The Processing Path

    + + + + +

    The processing path is mainly useful for debugging macros, so if you +don’t write macros, you can probably ignore it. Consider this example: +

    +
    +
    (defun foo (n)
+  (dotimes (i n *undefined*)))
+
    + +

    Compiling results in this error message: +

    +
    +
    ; in: DEFUN FOO
+;     (DOTIMES (I N *UNDEFINED*))
+; --> DO BLOCK LET TAGBODY RETURN-FROM
+; ==>
+;   (PROGN *UNDEFINED*)
+;
+; caught WARNING:
+;   undefined variable: *UNDEFINED*
+
    + +

    Note that do appears in the processing path. This is because +dotimes expands into: +

    +
    +
    (do ((i 0 (1+ i)) (#:g1 n))
+    ((>= i #:g1) *undefined*)
+  (declare (type unsigned-byte i)))
+
    + +

    The rest of the processing path results from the expansion of +do: +

    +
    +
    (block nil
+  (let ((i 0) (#:g1 n))
+    (declare (type unsigned-byte i))
+    (tagbody (go #:g3)
+      #:g2    (psetq i (1+ i))
+      #:g3    (unless (>= i #:g1) (go #:g2))
+      (return-from nil (progn *undefined*)))))
+
    + +

    In this example, the compiler descended into the block, +let, tagbody and return-from to reach the +progn printed as the actual source. This is a place where the +“actual source appears in explanation” rule was applied. The +innermost actual source form was the symbol *undefined* itself, +but that also appeared in the explanation, so the compiler backed out +one level. +

    + + + + +
    +
    +

    +Next: , Previous: , Up: Compiler   [Contents][Index]

    +
    +

    4.2 Handling of Types

    + +

    One of the most important features of the SBCL compiler (similar to +the original CMUCL compiler, also known as Python) is its fairly +sophisticated understanding of the Common Lisp type system and its +conservative approach to the implementation of type declarations. +

    +

    These two features reward the use of type declarations throughout +development, even when high performance is not a concern. Also, as +discussed in the chapter on performance (see Efficiency), the use +of appropriate type declarations can be very important for performance +as well. +

    + +

    The SBCL compiler also has a greater knowledge of the Common Lisp +type system than other compilers. Support is incomplete only for types +involving the satisfies type specifier. +

    + + + + + + +
    • Declarations as Assertions   +
    • Precise Type Checking   +
    • Getting Existing Programs to Run   +
    • Implementation Limitations   +
    + +
    +
    +

    +Next: , Up: Handling of Types   [Contents][Index]

    +
    +

    4.2.1 Declarations as Assertions

    + + +

    The SBCL compiler treats type declarations differently from most other +Lisp compilers. Under default compilation policy the compiler doesn’t +blindly believe type declarations, but considers them assertions about +the program that should be checked: all type declarations that have +not been proven to always hold are asserted at runtime. +

    +
    +

    Remaining bugs in the compiler’s handling of types unfortunately +provide some exceptions to this rule, see Implementation Limitations. +

    + +

    CLOS slot types form a notable exception. Types declared using the +:type slot option in defclass are asserted if and only +if the class was defined in safe code and the slot access +location is in safe code as well. This laxness does not pose +any internal consistency issues, as the CLOS slot types are not +available for the type inferencer, nor do CLOS slot types provide any +efficiency benefits. +

    +

    There are three type checking policies available in SBCL, selectable +via optimize declarations. +

    +
    +
    Full Type Checks
    +

    All declarations are considered assertions to be checked at runtime, +and all type checks are precise. The default compilation policy +provides full type checks. +

    +

    Used when (or (>= safety 2) (>= safety speed 1)). +

    +
    +
    Weak Type Checks
    +

    Declared types may be simplified into faster to check supertypes: for +example, (or (integer -17 -7) (integer 7 17)) is simplified +into (integer -17 17). +

    +

    Note: it is relatively easy to corrupt the heap when weak +type checks are used if the program contains type-errors. +

    +

    Used when (and (< safety 2) (< safety speed)) +

    +
    +
    No Type Checks
    +

    All declarations are believed without assertions. Also disables +argument count and array bounds checking. +

    +

    Note: any type errors in code where type checks are not +performed are liable to corrupt the heap. +

    +

    Used when (= safety 0). +

    +
    +
    + +
    +
    +

    +Next: , Previous: , Up: Handling of Types   [Contents][Index]

    +
    +

    4.2.2 Precise Type Checking

    + + + +

    Precise checking means that the check is done as though typep +had been called with the exact type specifier that appeared in the +declaration. +

    +

    If a variable is declared to be (integer 3 17) then its value +must always be an integer between 3 and 17. If multiple +type declarations apply to a single variable, then all the +declarations must be correct; it is as though all the types were +intersected producing a single and type specifier. +

    +

    To gain maximum benefit from the compiler’s type checking, you should +always declare the types of function arguments and structure slots as +precisely as possible. This often involves the use of or, +member, and other list-style type specifiers. +

    + +
    +
    +

    +Next: , Previous: , Up: Handling of Types   [Contents][Index]

    +
    +

    4.2.3 Getting Existing Programs to Run

    + + + + +

    Since SBCL’s compiler does much more comprehensive type checking than +most Lisp compilers, SBCL may detect type errors in programs that have +been debugged using other compilers. These errors are mostly incorrect +declarations, although compile-time type errors can find actual bugs +if parts of the program have never been tested. +

    +

    Some incorrect declarations can only be detected by run-time type +checking. It is very important to initially compile a program with +full type checks (high safety optimization) and then test this +safe version. After the checking version has been tested, then you can +consider weakening or eliminating type checks. This applies +even to previously debugged programs, because the SBCL compiler does +much more type inference than other Common Lisp compilers, so an +incorrect declaration can do more damage. +

    +

    The most common problem is with variables whose constant initial value +doesn’t match the type declaration. Incorrect constant initial values +will always be flagged by a compile-time type error, and they are +simple to fix once located. Consider this code fragment: +

    +
    +
    (prog (foo)
+  (declare (fixnum foo))
+  (setq foo ...)
+  ...)
+
    + +

    Here foo is given an initial value of nil, but is +declared to be a fixnum. Even if it is never read, the initial +value of a variable must match the declared type. There are two ways +to fix this problem. Change the declaration +

    +
    +
    (prog (foo)
+  (declare (type (or fixnum null) foo))
+  (setq foo ...)
+  ...)
+
    + +

    or change the initial value +

    +
    +
    (prog ((foo 0))
+  (declare (fixnum foo))
+  (setq foo ...)
+  ...)
+
    + +

    It is generally preferable to change to a legal initial value rather +than to weaken the declaration, but sometimes it is simpler to weaken +the declaration than to try to make an initial value of the +appropriate type. +

    +

    Another declaration problem occasionally encountered is incorrect +declarations on defmacro arguments. This can happen when a +function is converted into a macro. Consider this macro: +

    +
    +
    (defmacro my-1+ (x)
+  (declare (fixnum x))
+  `(the fixnum (1+ ,x)))
+
    + +

    Although legal and well-defined Common Lisp code, this meaning of this +definition is almost certainly not what the writer intended. For +example, this call is illegal: +

    +
    +
    (my-1+ (+ 4 5))
+
    + +

    This call is illegal because the argument to the macro is (+ 4 +5), which is a list, not a fixnum. Because of macro +semantics, it is hardly ever useful to declare the types of macro +arguments. If you really want to assert something about the type of +the result of evaluating a macro argument, then put a the in +the expansion: +

    +
    +
    (defmacro my-1+ (x)
+  `(the fixnum (1+ (the fixnum ,x))))
+
    + +

    In this case, it would be stylistically preferable to change this +macro back to a function and declare it inline. +

    +

    Some more subtle problems are caused by incorrect declarations that +can’t be detected at compile time. Consider this code: +

    +
    +
    (do ((pos 0 (position #\a string :start (1+ pos))))
+  ((null pos))
+  (declare (fixnum pos))
+  ...)
+
    + +

    Although pos is almost always a fixnum, it is nil +at the end of the loop. If this example is compiled with full type +checks (the default), then running it will signal a type error at the +end of the loop. If compiled without type checks, the program will go +into an infinite loop (or perhaps position will complain +because (1+ nil) isn’t a sensible start.) Why? Because if you +compile without type checks, the compiler just quietly believes the +type declaration. Since the compiler believes that pos is +always a fixnum, it believes that pos is never +nil, so (null pos) is never true, and the loop exit test +is optimized away. Such errors are sometimes flagged by unreachable +code notes, but it is still important to initially compile and test +any system with full type checks, even if the system works fine when +compiled using other compilers. +

    +

    In this case, the fix is to weaken the type declaration to (or +fixnum null) 2. +

    +

    Note that there is usually little performance penalty for weakening a +declaration in this way. Any numeric operations in the body can still +assume that the variable is a fixnum, since nil is not a +legal numeric argument. Another possible fix would be to say: +

    +
    +
    (do ((pos 0 (position #\a string :start (1+ pos))))
+    ((null pos))
+  (let ((pos pos))
+    (declare (fixnum pos))
+    ...))
+
    + +

    This would be preferable in some circumstances, since it would allow a +non-standard representation to be used for the local pos +variable in the loop body. +

    +
    +
    +

    +Previous: , Up: Handling of Types   [Contents][Index]

    +
    +

    4.2.4 Implementation Limitations

    + +

    Ideally, the compiler would consider all type declarations to +be assertions, so that adding type declarations to a program, no +matter how incorrect they might be, would never cause undefined +behavior. However, the compiler is known to fall short of this goal in +two areas: +

    +
      +
    • Proclaimed constraints on argument and result types of a +function are supposed to be checked by the function. If the function +type is proclaimed before function definition, type checks are +inserted by the compiler, but the standard allows the reversed order, +in which case the compiler will trust the declaration. + +
    • The compiler cannot check types of an unknown number of values; if the +number of generated values is unknown, but the number of consumed is +known, only consumed values are checked. + +

      For example, +

      +
      +
      (defun foo (x)
+  (the integer (bar x)))
+
      + +

      causes the following compiler diagnostic to be emitted: +

      +
      +
      ; note: type assertion too complex to check:
+;  (VALUES INTEGER &REST T).
+
      + +

      A partial workaround is instead write: +

      +
      +
      (defun foo (x)
+  (the (values integer &optional) (bar x)))
+
      + +
    + +

    These are important issues, but are not necessarily easy to fix, so +they may, alas, remain in the system for a while. +

    +
    +
    +

    +Next: , Previous: , Up: Compiler   [Contents][Index]

    +
    +

    4.3 Compiler Policy

    + +

    Compiler policy is controlled by the optimize declaration, +supporting all ANSI optimization qualities (debug, +safety, space, and speed).3 +

    +

    For effects of various optimization qualities on type-safety and +debuggability see Declarations as Assertions and Debugger Policy Control. +

    +

    Ordinarily, when the speed quality is high, the compiler emits +notes to notify the programmer about its inability to apply various +optimizations. For selective muffling of these notes See Controlling Verbosity. +

    +

    The value of space mostly influences the compiler’s decision +whether to inline operations, which tend to increase the size of +programs. Use the value 0 with caution, since it can cause the +compiler to inline operations so indiscriminately that the net effect +is to slow the program by causing cache misses or even swapping. +

    + +
    +
    Function: describe-compiler-policy [sb-ext] &optional spec
    +

    Print all global optimization settings, augmented by spec. +

    +
    +
    Function: restrict-compiler-policy [sb-ext] &optional quality min max
    +

    Assign a minimum value to an optimization quality. quality is the name of +the optimization quality to restrict, min (defaulting to zero) is the +minimum allowed value, and max (defaults to 3) is the maximum. +

    +

    Returns the alist describing the current policy restrictions. +

    +

    If quality is nil or not given, nothing is done. +

    +

    Otherwise, if min is zero or max is 3 or neither are given, any +existing restrictions of quality are removed. +

    +

    See also :policy option in with-compilation-unit. +

    +
    +
    Macro: with-compilation-unit [cl] options &body body
    +

    Affects compilations that take place within its dynamic extent. It is +intended to be eg. wrapped around the compilation of all files in the same system. +

    +

    Following options are defined: +

    + +
    +
    :override Boolean-Form
    +

    One of the effects of this form is to delay undefined warnings until the + end of the form, instead of giving them at the end of each compilation. + If override is nil (the default), then the outermost + with-compilation-unit form grabs the undefined warnings. Specifying + override true causes that form to grab any enclosed warnings, even if it + is enclosed by another with-compilation-unit. +

    + +
    +
    :policy Optimize-Declaration-Form
    +

    Provides dynamic scoping for global compiler optimization qualities and + restrictions, limiting effects of subsequent optimize proclamations and + calls to sb-ext:restrict-compiler-policy to the dynamic scope of body. +

    +

    If override is false, specified policy is merged with current global + policy. If override is true, current global policy, including any + restrictions, is discarded in favor of the specified policy. +

    +

    Supplying policy nil is equivalent to the option not being supplied at + all, ie. dynamic scoping of policy does not take place. +

    +

    This option is an SBCL-specific experimental extension: Interface + subject to change. +

    + +
    +
    :source-namestring Namestring-Form
    +

    Attaches the value returned by the Namestring-Form to the internal + debug-source information as the namestring of the source file. Normally + the namestring of the input-file for compile-file is used: this option + can be used to provide source-file information for functions compiled + using compile, or to override the input-file of compile-file. +

    +

    If both an outer and an inner with-compilation-unit provide a + source-namestring, the inner one takes precedence. Unaffected + by :override. +

    +

    This is an SBCL-specific extension. +

    + +
    +
    :source-plist Plist-Form
    +

    Attaches the value returned by the Plist-Form to internal debug-source + information of functions compiled in within the dynamic extent of body. +

    +

    Primarily for use by development environments, in order to eg. associate + function definitions with editor-buffers. Can be accessed using + sb-introspect:definition-source-plist. +

    +

    If an outer with-compilation-unit form also provide a source-plist, it + is appended to the end of the provided source-plist. Unaffected + by :override. +

    +

    This is an SBCL-specific extension. +

    +
    +
    + +

    Examples: +

    +
    +
      ;; Prevent proclamations from the file leaking, and restrict
+  ;; SAFETY to 3 -- otherwise uses the current global policy.
+  (with-compilation-unit (:policy '(optimize))
+    (restrict-compiler-policy 'safety 3)
+    (load "foo.lisp"))
+
+  ;; Using default policy instead of the current global one,
+  ;; except for DEBUG 3.
+  (with-compilation-unit (:policy '(optimize debug)
+                          :override t)
+    (load "foo.lisp"))
+
+  ;; Same as if :POLICY had not been specified at all: SAFETY 3
+  ;; proclamation leaks out from WITH-COMPILATION-UNIT.
+  (with-compilation-unit (:policy nil)
+    (declaim (optimize safety))
+    (load "foo.lisp"))
+
    +
    + +
    +
    +

    +Next: , Previous: , Up: Compiler   [Contents][Index]

    +
    +

    4.4 Compiler Errors

    + + + + + +
    • Type Errors at Compile Time   +
    • Errors During Macroexpansion   +
    • Read Errors   +
    + +
    +
    +

    +Next: , Up: Compiler Errors   [Contents][Index]

    +
    +

    4.4.1 Type Errors at Compile Time

    + + + +

    If the compiler can prove at compile time that some portion of the +program cannot be executed without a type error, then it will give a +warning at compile time. +

    +

    It is possible that the offending code would never actually be +executed at run-time due to some higher level consistency constraint +unknown to the compiler, so a type warning doesn’t always indicate an +incorrect program. +

    +

    For example, consider this code fragment: +

    +
    +
    (defun raz (foo)
+  (let ((x (case foo
+              (:this 13)
+              (:that 9)
+              (:the-other 42))))
+    (declare (fixnum x))
+    (foo x)))
+
    + +

    Compilation produces this warning: +

    +
    +
    ; in: DEFUN RAZ
+;     (CASE FOO (:THIS 13) (:THAT 9) (:THE-OTHER 42))
+; --> LET COND IF COND IF COND IF
+; ==>
+;   (COND)
+;
+; caught WARNING:
+;   This is not a FIXNUM:
+;   NIL
+
    + +

    In this case, the warning means that if foo isn’t any of +:this, :that or :the-other, then x will be +initialized to nil, which the fixnum declaration makes +illegal. The warning will go away if ecase is used instead of +case, or if :the-other is changed to t. +

    +

    This sort of spurious type warning happens moderately often in the +expansion of complex macros and in inline functions. In such cases, +there may be dead code that is impossible to correctly execute. The +compiler can’t always prove this code is dead (could never be +executed), so it compiles the erroneous code (which will always signal +an error if it is executed) and gives a warning. +

    +
    +
    +

    +Next: , Previous: , Up: Compiler Errors   [Contents][Index]

    +
    +

    4.4.2 Errors During Macroexpansion

    + + +

    The compiler handles errors that happen during macroexpansion, turning +them into compiler errors. If you want to debug the error (to debug a +macro), you can set *break-on-signals* to error. For +example, this definition: +

    +
    +
    (defun foo (e l)
+  (do ((current l (cdr current))
+       ((atom current) nil))
+      (when (eq (car current) e) (return current))))
+
    + +

    gives this error: +

    +
    +
    ; in: DEFUN FOO
+;     (DO ((CURRENT L (CDR CURRENT))
+;        ((ATOM CURRENT) NIL))
+;       (WHEN (EQ (CAR CURRENT) E) (RETURN CURRENT)))
+;
+; caught ERROR:
+;   (in macroexpansion of (DO # #))
+;   (hint: For more precise location, try *BREAK-ON-SIGNALS*.)
+;   DO step variable is not a symbol: (ATOM CURRENT)
+
    + + +
    +
    +

    +Previous: , Up: Compiler Errors   [Contents][Index]

    +
    +

    4.4.3 Read Errors

    + + +

    SBCL’s compiler does not attempt to recover from read errors when +reading a source file, but instead just reports the offending +character position and gives up on the entire source file. +

    +
    +
    +

    +Next: , Previous: , Up: Compiler   [Contents][Index]

    +
    +

    4.5 Open Coding and Inline Expansion

    + + + + +

    Since Common Lisp forbids the redefinition of standard functions, the +compiler can have special knowledge of these standard functions +embedded in it. This special knowledge is used in various ways (open +coding, inline expansion, source transformation), but the implications +to the user are basically the same: +

    +
      +
    • Attempts to redefine standard functions may be frustrated, since the +function may never be called. Although it is technically illegal to +redefine standard functions, users sometimes want to implicitly +redefine these functions when they are debugging using the +trace macro. Special-casing of standard functions can be +inhibited using the notinline declaration, but even then some +phases of analysis such as type inferencing are applied by the +compiler. + +
    • The compiler can have multiple alternate implementations of standard +functions that implement different trade-offs of speed, space and +safety. This selection is based on the compiler policy, Compiler Policy. + +
    + +

    When a function call is open coded, inline code whose effect is +equivalent to the function call is substituted for that function +call. When a function call is closed coded, it is usually left +as is, although it might be turned into a call to a different function +with different arguments. As an example, if nthcdr were to be +open coded, then +

    +
    +
    (nthcdr 4 foobar)
+
    + +

    might turn into +

    +
    +
    (cdr (cdr (cdr (cdr foobar))))
+
    + +

    or even +

    +
    +
    (do ((i 0 (1+ i))
+  (list foobar (cdr foobar)))
+  ((= i 4) list))
+
    + +

    If nth is closed coded, then +

    +
    +
    (nth x l)
+
    + +

    might stay the same, or turn into something like +

    +
    +
    (car (nthcdr x l))
+
    + +

    In general, open coding sacrifices space for speed, but some functions +(such as car) are so simple that they are always +open-coded. Even when not open-coded, a call to a standard function +may be transformed into a different function call (as in the last +example) or compiled as static call. Static function call uses +a more efficient calling convention that forbids redefinition. +

    +
    +
    +

    +Next: , Previous: , Up: Compiler   [Contents][Index]

    +
    +

    4.6 Interpreter

    + + + + +

    By default SBCL implements eval by calling the native code +compiler. +

    +

    SBCL also includes an interpreter for use in special cases where using +the compiler is undesirable, for example due to compilation overhead. +Unlike in some other Lisp implementations, in SBCL interpreted code is +not safer or more debuggable than compiled code. +

    +
    +
    Variable: *evaluator-mode* [sb-ext]
    +

    Toggle between different evaluator implementations. If set to :compile, +an implementation of eval that calls the compiler will be used. If set +to :interpret, an interpreter will be used. +

    + +
    +
    +

    +Previous: , Up: Compiler   [Contents][Index]

    +
    +

    4.7 Advanced Compiler Use and Efficiency Hints

    +

    For more advanced usages of the compiler, please see the chapter of the +same name in the CMUCL manual. Many aspects of the compiler have stayed +exactly the same, and there is a much more detailed explanation of the +compiler’s behavior and how to maximally optimize code in their +manual. In particular, while SBCL no longer supports byte-code +compilation, it does support CMUCL’s block compilation facility allowing +whole program optimization and increased use of the local call +convention. +

    +

    Unlike CMUCL, SBCL is able to open-code forward-referenced type tests +while block compiling. This helps for mutually referential +defstructs in particular. +

    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    5 Debugger

    + + +

    This chapter documents the debugging facilities of SBCL, including +the debugger, single-stepper and trace, and the effect of +(optimize debug) declarations. +

    + + + + + + + + + + + + +
    • Debugger Entry   +
    • Debugger Command Loop   +
    • Stack Frames   +
    • Variable Access   +
    • Source Location Printing   +
    • Debugger Policy Control   +
    • Exiting Commands   +
    • Information Commands   +
    • Function Tracing   +
    • Single Stepping   +
    • Enabling and Disabling the Debugger   +
    + +
    +
    +

    +Next: , Up: Debugger   [Contents][Index]

    +
    +

    5.1 Debugger Entry

    + + + + +
    • Debugger Banner   +
    • Debugger Invocation   +
    + +
    +
    +

    +Next: , Up: Debugger Entry   [Contents][Index]

    +
    +

    5.1.1 Debugger Banner

    + +

    When you enter the debugger, it looks something like this: +

    +
    +
    debugger invoked on a TYPE-ERROR in thread 11184:
+  The value 3 is not of type LIST.
+
+You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
+
+restarts (invokable by number or by possibly-abbreviated name):
+  0: [ABORT   ] Reduce debugger level (leaving debugger, returning to toplevel).
+  1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
+(CAR 1 3)
+0]
+
    + +

    The first group of lines describe what the error was that put us in +the debugger. In this case car was called on 3, causing +a type-error. +

    +

    This is followed by the “beginner help line”, which appears only if +sb-debug:*debug-beginner-help-p* is true (default). +

    +

    Next comes a listing of the active restart names, along with their +descriptions – the ways we can restart execution after this error. In +this case, both options return to top-level. Restarts can be selected +by entering the corresponding number or name. +

    +

    The current frame appears right underneath the restarts, immediately +followed by the debugger prompt. +

    +
    +
    +

    +Previous: , Up: Debugger Entry   [Contents][Index]

    +
    +

    5.1.2 Debugger Invocation

    + +

    The debugger is invoked when: +

    +
      +
    • error is called, and the condition it signals is not handled. + +
    • break is called, or signal is called with a condition +that matches the current *break-on-signals*. + +
    • the debugger is explicitly entered with the invoke-debugger +function. + +
    + +

    When the debugger is invoked by a condition, ANSI mandates that the +value of *debugger-hook*, if any, be called with two arguments: +the condition that caused the debugger to be invoked and the previous +value of *debugger-hook*. When this happens, +*debugger-hook* is bound to NIL to prevent recursive errors. +However, ANSI also mandates that *debugger-hook* not be invoked +when the debugger is to be entered by the break function. For +users who wish to provide an alternate debugger interface (and thus +catch break entries into the debugger), SBCL provides +sb-ext:*invoke-debugger-hook*, which is invoked during any +entry into the debugger. +

    +
    +
    Variable: *invoke-debugger-hook* [sb-ext]
    +

    This is either nil or a designator for a function of two arguments, + to be run when the debugger is about to be entered. The function is + run with *invoke-debugger-hook* bound to nil to minimize recursive + errors, and receives as arguments the condition that triggered + debugger entry and the previous value of *invoke-debugger-hook* +

    +

    This mechanism is an sbcl extension similar to the standard *debugger-hook*. + In contrast to *debugger-hook*, it is observed by invoke-debugger even when + called by break. +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.2 Debugger Command Loop

    + +

    The debugger is an interactive read-eval-print loop much like the +normal top level, but some symbols are interpreted as debugger +commands instead of being evaluated. A debugger command starts with +the symbol name of the command, possibly followed by some arguments on +the same line. Some commands prompt for additional input. Debugger +commands can be abbreviated by any unambiguous prefix: help +can be typed as ‘h’, ‘he’, etc. +

    +

    The package is not significant in debugger commands; any symbol with +the name of a debugger command will work. If you want to show the +value of a variable that happens also to be the name of a debugger +command you can wrap the variable in a progn to hide it from +the command loop. +

    +

    The debugger prompt is “frame]”, where frame is +the number of the current frame. Frames are numbered starting from +zero at the top (most recent call), increasing down to the bottom. +The current frame is the frame that commands refer to. +

    +

    It is possible to override the normal printing behaviour in the +debugger by using the sb-ext:*debug-print-variable-alist*. +

    +
    +
    Variable: *debug-print-variable-alist* [sb-ext]
    +

    an association list describing new bindings for special variables +to be used within the debugger. Eg. +

    +
    +
     ((*PRINT-LENGTH* . 10) (*PRINT-LEVEL* . 6) (*PRINT-PRETTY* . NIL))
+
    + +

    The variables in the car positions are bound to the values in the cdr +during the execution of some debug commands. When evaluating arbitrary +expressions in the debugger, the normal values of the printer control +variables are in effect. +

    +

    Initially empty, *debug-print-variable-alist* is typically used to +provide bindings for printer control variables. +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.3 Stack Frames

    + + +

    A stack frame is the run-time representation of a call to a +function; the frame stores the state that a function needs to remember +what it is doing. Frames have: +

    +
      +
    • variables (see Variable Access), which are the values being operated +on. + +
    • arguments to the call (which are really just particularly +interesting variables). + +
    • a current source location (see Source Location Printing), which is +the place in the program where the function was running when it +stopped to call another function, or because of an interrupt or error. + +
    + + + + + + + +
    • Stack Motion   +
    • How Arguments are Printed   +
    • Function Names   +
    • Debug Tail Recursion   +
    • Unknown Locations and Interrupts   +
    + +
    +
    +

    +Next: , Up: Stack Frames   [Contents][Index]

    +
    +

    5.3.1 Stack Motion

    + +

    These commands move to a new stack frame and print the name of the +function and the values of its arguments in the style of a Lisp +function call: +

    +
    +
    Debugger Command: up
    +

    Move up to the next higher frame. More recent function calls are +considered to be higher on the stack. +

    + +
    +
    Debugger Command: down
    +

    Move down to the next lower frame. +

    + +
    +
    Debugger Command: top
    +

    Move to the highest frame, that is, the frame where the debugger was +entered. +

    + +
    +
    Debugger Command: bottom
    +

    Move to the lowest frame. +

    + +
    +
    Debugger Command: frame [n]
    +

    Move to the frame with the specified number. Prompts for the number if not +supplied. The frame with number 0 is the frame where the debugger +was entered. +

    + + +
    +
    +

    +Next: , Previous: , Up: Stack Frames   [Contents][Index]

    +
    +

    5.3.2 How Arguments are Printed

    + +

    A frame is printed to look like a function call, but with the actual +argument values in the argument positions. So the frame for this call +in the source: +

    +
    +
    (myfun (+ 3 4) 'a)
+
    + +

    would look like this: +

    +
    +
    (MYFUN 7 A)
+
    + +

    All keyword and optional arguments are displayed with their actual +values; if the corresponding argument was not supplied, the value will +be the default. So this call: +

    +
    +
    (subseq "foo" 1)
+
    + +

    would look like this: +

    +
    +
    (SUBSEQ "foo" 1 3)
+
    + +

    And this call: +

    +
    +
    (string-upcase "test case")
+
    + +

    would look like this: +

    +
    +
    (STRING-UPCASE "test case" :START 0 :END NIL)
+
    + +

    The arguments to a function call are displayed by accessing the +argument variables. Although those variables are initialized to the +actual argument values, they can be set inside the function; in this +case the new value will be displayed. +

    +

    &rest arguments are handled somewhat differently. The value of +the rest argument variable is displayed as the spread-out arguments to +the call, so: +

    +
    +
    (format t "~A is a ~A." "This" 'test)
+
    + +

    would look like this: +

    +
    +
    (FORMAT T "~A is a ~A." "This" 'TEST)
+
    + +

    Rest arguments cause an exception to the normal display of keyword +arguments in functions that have both &rest and &key +arguments. In this case, the keyword argument variables are not +displayed at all; the rest arg is displayed instead. So for these +functions, only the keywords actually supplied will be shown, and the +values displayed will be the argument values, not values of the +(possibly modified) variables. +

    +

    If the variable for an argument is never referenced by the function, +it will be deleted. The variable value is then unavailable, so the +debugger prints ‘#<unused-arg>’ instead of the value. Similarly, +if for any of a number of reasons the value of the variable is +unavailable or not known to be available (see Variable Access), +then ‘#<unavailable-arg>’ will be printed instead of the argument +value. +

    +

    Note that inline expansion and open-coding affect what frames +are present in the debugger, see Debugger Policy Control. +

    + +
    +
    +

    +Next: , Previous: , Up: Stack Frames   [Contents][Index]

    +
    +

    5.3.3 Function Names

    + +

    If a function is defined by defun it will appear in backtrace +by that name. Functions defined by labels and flet will +appear as (FLET name) and (LABELS name) respectively. +Anonymous lambdas will appear as (LAMBDA lambda-list). +

    + + +
    • Entry Point Details   +
    + +
    +
    +

    +Up: Function Names   [Contents][Index]

    +
    +

    5.3.3.1 Entry Point Details

    + + + + + + + +

    Sometimes the compiler introduces new functions that are used to +implement a user function, but are not directly specified in the +source. This is mostly done for argument type and count checking. +

    +

    With recursive or block compiled functions, an additional +external frame may appear before the frame representing the first +call to the recursive function or entry to the compiled block. This is a +consequence of the way the compiler works: there is nothing odd with +your program. You may also see cleanup frames during the +execution of unwind-protect cleanup code, and optional for +variable argument entry points. +

    +
    +
    +

    +Next: , Previous: , Up: Stack Frames   [Contents][Index]

    +
    +

    5.3.4 Debug Tail Recursion

    + + + +

    The compiler is “properly tail recursive.” If a function call is in +a tail-recursive position, the stack frame will be deallocated +at the time of the call, rather than after the call returns. +Consider this backtrace: +

    +
    +
    (BAR ...)
+(FOO ...)
+
    + +

    Because of tail recursion, it is not necessarily the case that +FOO directly called BAR. It may be that FOO +called some other function FOO2 which then called BAR +tail-recursively, as in this example: +

    +
    +
    (defun foo ()
+  ...
+  (foo2 ...)
+  ...)
+
+(defun foo2 (...)
+  ...
+  (bar ...))
+
+(defun bar (...)
+  ...)
+
    + +

    Usually the elimination of tail-recursive frames makes debugging more +pleasant, since these frames are mostly uninformative. If there is any +doubt about how one function called another, it can usually be +eliminated by finding the source location in the calling frame. +See Source Location Printing. +

    +

    The elimination of tail-recursive frames can be prevented by disabling +tail-recursion optimization, which happens when the debug +optimization quality is greater than 2. +See Debugger Policy Control. +

    + +
    +
    +

    +Previous: , Up: Stack Frames   [Contents][Index]

    +
    +

    5.3.5 Unknown Locations and Interrupts

    + + + + + +

    The debugger operates using special debugging information attached to +the compiled code. This debug information tells the debugger what it +needs to know about the locations in the code where the debugger can +be invoked. If the debugger somehow encounters a location not +described in the debug information, then it is said to be +unknown. If the code location for a frame is unknown, then some +variables may be inaccessible, and the source location cannot be +precisely displayed. +

    +

    There are three reasons why a code location could be unknown: +

    +
      +
    • There is inadequate debug information due to the value of the debug +optimization quality. See Debugger Policy Control. + +
    • The debugger was entered because of an interrupt such as C-c. + +
    • A hardware error such as “‘bus error’” occurred in code that was +compiled unsafely due to the value of the safety optimization +quality. + +
    + +

    In the last two cases, the values of argument variables are +accessible, but may be incorrect. For more details on when variable +values are accessible, see Variable Value Availability. +

    +

    It is possible for an interrupt to happen when a function call or +return is in progress. The debugger may then flame out with some +obscure error or insist that the bottom of the stack has been reached, +when the real problem is that the current stack frame can’t be +located. If this happens, return from the interrupt and try again. +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.4 Variable Access

    + + + +

    There are two ways to access the current frame’s local variables in +the debugger: list-locals and sb-debug:var. +

    +

    The debugger doesn’t really understand lexical scoping; it has just +one namespace for all the variables in the current stack frame. If a +symbol is the name of multiple variables in the same function, then +the reference appears ambiguous, even though lexical scoping specifies +which value is visible at any given source location. If the scopes of +the two variables are not nested, then the debugger can resolve the +ambiguity by observing that only one variable is accessible. +

    +

    When there are ambiguous variables, the evaluator assigns each one a +small integer identifier. The sb-debug:var function uses this +identifier to distinguish between ambiguous variables. The +list-locals command prints the identifier. In the +following example, there are two variables named X. The first +one has identifier 0 (which is not printed), the second one has +identifier 1. +

    +
    +
    X  =  1
+X#1  =  2
+
    + +
    +
    Debugger Command: list-locals [prefix]
    +

    This command prints the name and value of all variables in the current +frame whose name has the specified prefix. prefix may be +a string or a symbol. If no prefix is given, then all available +variables are printed. If a variable has a potentially ambiguous +name, then the name is printed with a “#identifier” +suffix, where identifier is the small integer used to make the +name unique. +

    + +
    +
    Function: var [sb-debug] name &optional identifier
    +

    This function returns the value of the variable in the current frame +with the specified name. If supplied, identifier +determines which value to return when there are ambiguous variables. +

    +

    When name is a symbol, it is interpreted as the symbol name of +the variable, i.e. the package is significant. If name is an +uninterned symbol (gensym), then return the value of the uninterned +variable with the same name. If name is a string, +sb-debug:var interprets it as the prefix of a variable name +that must unambiguously complete to the name of a valid variable. +

    +

    identifier is used to disambiguate the variable name; use +list-locals to find out the identifiers. +

    + + + + + +
    • Variable Value Availability   +
    • Note On Lexical Variable Access   +
    + +
    +
    +

    +Next: , Up: Variable Access   [Contents][Index]

    +
    +

    5.4.1 Variable Value Availability

    + + + + +

    The value of a variable may be unavailable to the debugger in portions +of the program where Lisp says that the variable is defined. If a +variable value is not available, the debugger will not let you read or +write that variable. With one exception, the debugger will never +display an incorrect value for a variable. Rather than displaying +incorrect values, the debugger tells you the value is unavailable. +

    +

    The one exception is this: if you interrupt (e.g., with C-c) or +if there is an unexpected hardware error such as “‘bus error’” +(which should only happen in unsafe code), then the values displayed +for arguments to the interrupted frame might be +incorrect.4 This exception applies only to the +interrupted frame: any frame farther down the stack will be fine. +

    +

    The value of a variable may be unavailable for these reasons: +

    +
      +
    • The value of the debug optimization quality may have omitted debug +information needed to determine whether the variable is available. +Unless a variable is an argument, its value will only be available when +debug is at least 2. + +
    • The compiler did lifetime analysis and determined that the value was no longer +needed, even though its scope had not been exited. Lifetime analysis is +inhibited when the debug optimization quality is 3. + +
    • The variable’s name is an uninterned symbol (gensym). To save space, the +compiler only dumps debug information about uninterned variables when the +debug optimization quality is 3. + +
    • The frame’s location is unknown (see Unknown Locations and Interrupts) because the debugger was entered due to an interrupt or +unexpected hardware error. Under these conditions the values of +arguments will be available, but might be incorrect. This is the +exception mentioned above. + +
    • The variable (or the code referencing it) was optimized out +of existence. Variables with no reads are always optimized away. The +degree to which the compiler deletes variables will depend on the +value of the compilation-speed optimization quality, but most +source-level optimizations are done under all compilation policies. + +
    • The variable is never set and its definition looks like +
      +
      (LET ((var1 var2))
+   ...)
+
      +

      In this case, var1 is substituted with var2. +

      +
    • The variable is never set and is referenced exactly once. In this +case, the reference is substituted with the variable initial value. + +
    + +

    Since it is especially useful to be able to get the arguments to a +function, argument variables are treated specially when the +speed optimization quality is less than 3 and the +debug quality is at least 1. With this compilation +policy, the values of argument variables are almost always available +everywhere in the function, even at unknown locations. For +non-argument variables, debug must be at least 2 for +values to be available, and even then, values are only available at +known locations. +

    + +
    +
    +

    +Previous: , Up: Variable Access   [Contents][Index]

    +
    +

    5.4.2 Note On Lexical Variable Access

    + +

    When the debugger command loop establishes variable bindings for +available variables, these variable bindings have lexical scope and +dynamic extent.5 You can close +over them, but such closures can’t be used as upward function arguments. +

    +

    You can also set local variables using setq, but if the +variable was closed over in the original source and never set, then +setting the variable in the debugger may not change the value in all +the functions the variable is defined in. Another risk of setting +variables is that you may assign a value of a type that the compiler +proved the variable could never take on. This may result in bad +things happening. +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.5 Source Location Printing

    + + +

    One of the debugger’s capabilities is source level debugging of +compiled code. These commands display the source location for the +current frame: +

    +
    +
    Debugger Command: source [context]
    +

    This command displays the file that the current frame’s function was +defined from (if it was defined from a file), and then the source form +responsible for generating the code that the current frame was +executing. If context is specified, then it is an integer +specifying the number of enclosing levels of list structure to print. +

    + +

    The source form for a location in the code is the innermost list present +in the original source that encloses the form responsible for generating +that code. If the actual source form is not a list, then some enclosing +list will be printed. For example, if the source form was a reference +to the variable *some-random-special*, then the innermost +enclosing evaluated form will be printed. Here are some possible +enclosing forms: +

    +
    +
    (let ((a *some-random-special*))
+  ...)
+
+(+ *some-random-special* ...)
+
    + +

    If the code at a location was generated from the expansion of a macro +or a source-level compiler optimization, then the form in the original +source that expanded into that code will be printed. Suppose the file +/usr/me/mystuff.lisp looked like this: +

    +
    +
    (defmacro mymac ()
+  '(myfun))
+
+(defun foo ()
+  (mymac)
+  ...)
+
    + +

    If foo has called myfun, and is waiting for it to +return, then the source command would print: +

    +
    +
    ; File: /usr/me/mystuff.lisp
+
+(MYMAC)
+
    + +

    Note that the macro use was printed, not the actual function call form, +(myfun). +

    +

    If enclosing source is printed by giving an argument to +source or vsource, then the actual source form is +marked by wrapping it in a list whose first element is +‘#:***HERE***’. In the previous example, source 1 would +print: +

    +
    +
    ; File: /usr/me/mystuff.lisp
+
+(DEFUN FOO ()
+  (#:***HERE***
+   (MYMAC))
+  ...)
+
    + + + + + +
    • How the Source is Found   +
    • Source Location Availability   +
    + +
    +
    +

    +Next: , Up: Source Location Printing   [Contents][Index]

    +
    +

    5.5.1 How the Source is Found

    + +

    If the code was defined from Lisp by compile or +eval, then the source can always be reliably located. If the +code was defined from a fasl file created by +compile-file, then the debugger gets the source forms it +prints by reading them from the original source file. This is a +potential problem, since the source file might have moved or changed +since the time it was compiled. +

    +

    The source file is opened using the truename of the source file +pathname originally given to the compiler. This is an absolute pathname +with all logical names and symbolic links expanded. If the file can’t +be located using this name, then the debugger gives up and signals an +error. +

    +

    If the source file can be found, but has been modified since the time it was +compiled, the debugger prints this warning: +

    +
    +
    ; File has been modified since compilation:
+;   filename
+; Using form offset instead of character position.
+
    + +

    where filename is the name of the source file. It then proceeds +using a robust but not foolproof heuristic for locating the source. +This heuristic works if: +

    +
      +
    • No top-level forms before the top-level form containing the source +have been added or deleted, and + +
    • The top-level form containing the source has not been modified much. +(More precisely, none of the list forms beginning before the source +form have been added or deleted.) + +
    + +

    If the heuristic doesn’t work, the displayed source will be wrong, but will +probably be near the actual source. If the “shape” of the top-level form in +the source file is too different from the original form, then an error will be +signaled. When the heuristic is used, the source location commands are +noticeably slowed. +

    +

    Source location printing can also be confused if (after the source was +compiled) a read-macro you used in the code was redefined to expand +into something different, or if a read-macro ever returns the same +eq list twice. If you don’t define read macros and don’t use +## in perverted ways, you don’t need to worry about this. +

    + +
    +
    +

    +Previous: , Up: Source Location Printing   [Contents][Index]

    +
    +

    5.5.2 Source Location Availability

    + + + + +

    Source location information is only available when the debug +optimization quality is at least 2. If source location +information is unavailable, the source commands will give an error +message. +

    +

    If source location information is available, but the source location +is unknown because of an interrupt or unexpected hardware error +(see Unknown Locations and Interrupts), then the command will +print: +

    +
    +
    Unknown location: using block start.
+
    + +

    and then proceed to print the source location for the start of the +basic block enclosing the code location. It’s a bit +complicated to explain exactly what a basic block is, but here are +some properties of the block start location: +

    +
      +
    • The block start location may be the same as the true location. + +
    • The block start location will never be later in the +program’s flow of control than the true location. + +
    • No conditional control structures (such as if, +cond, or) will intervene between the block start and the +true location (but note that some conditionals present in the original +source could be optimized away.) Function calls do not end +basic blocks. + +
    • The head of a loop will be the start of a block. + +
    • The programming language concept of “block structure” and the +Lisp block special form are totally unrelated to the compiler’s +basic block. + +
    + +

    In other words, the true location lies between the printed location and the +next conditional (but watch out because the compiler may have changed the +program on you.) +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.6 Debugger Policy Control

    + + + + + + +

    The compilation policy specified by optimize declarations +affects the behavior seen in the debugger. The debug quality +directly affects the debugger by controlling the amount of debugger +information dumped. Other optimization qualities have indirect but +observable effects due to changes in the way compilation is done. +

    +

    Unlike the other optimization qualities (which are compared in relative value +to evaluate tradeoffs), the debug optimization quality is directly +translated to a level of debug information. This absolute interpretation +allows the user to count on a particular amount of debug information being +available even when the values of the other qualities are changed during +compilation. These are the levels of debug information that correspond to the +values of the debug quality: +

    +
    +
    0
    +

    Only the function name and enough information to allow the stack to +be parsed. +

    +
    +
    > 0
    +

    Any level greater than 0 gives level 0 plus all argument +variables. Values will only be accessible if the argument variable is +never set and speed is not 3. SBCL allows any real +value for optimization qualities. It may be useful to specify +0.5 to get backtrace argument display without argument +documentation. +

    +
    +
    1
    +

    Level 1 provides argument documentation (printed argument lists) and +derived argument/result type information. This makes describe +more informative, and allows the compiler to do compile-time argument +count and type checking for any calls compiled at run-time. This is +the default. +

    +
    +
    2
    +

    Level 1 plus all interned local variables, source location +information, and lifetime information that tells the debugger when +arguments are available (even when speed is 3 or the +argument is set). +

    +
    +
    > 2
    +

    Any level greater than 2 gives level 2 and in addition +disables tail-call optimization, so that the backtrace will contain +frames for all invoked functions, even those in tail positions. +

    +
    +
    3
    +

    Level 2 plus all uninterned variables. In addition, lifetime +analysis is disabled (even when speed is 3), ensuring +that all variable values are available at any known location within +the scope of the binding. This has a speed penalty in addition to the +obvious space penalty. +

    +

    Inlining of local functions is inhibited so that they may be +traced. +

    +
    +
    > (max speed space)
    +

    If debug is greater than both speed and space, +the command return can be used to continue execution by +returning a value from the current stack frame. +

    +
    +
    > (max speed space compilation-speed)
    +

    If debug is greater than all of speed, space and +compilation-speed the code will be steppable (see Single Stepping). +

    +
    +
    + +

    As you can see, if the speed quality is 3, debugger performance is +degraded. This effect comes from the elimination of argument variable +special-casing (see Variable Value Availability). Some degree of +speed/debuggability tradeoff is unavoidable, but the effect is not too drastic +when debug is at least 2. +

    +

    In addition to inline and notinline declarations, the +relative values of the speed and space qualities also +change whether functions are inline expanded. +If a function is inline expanded, then +there will be no frame to represent the call, and the arguments will +be treated like any other local variable. Functions may also be +“semi-inline”, in which case there is a frame to represent the call, +but the call is to an optimized local version of the function, not to +the original function. +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.7 Exiting Commands

    + +

    These commands get you out of the debugger. +

    +
    +
    Debugger Command: toplevel
    +

    Throw to top level. +

    + +
    +
    Debugger Command: restart [n]
    +

    Invokes the nth restart case as displayed by the error +command. If n is not specified, the available restart cases are +reported. +

    + +
    +
    Debugger Command: continue
    +

    Calls continue on the condition given to debug. If there is no +restart case named continue, then an error is signaled. +

    + +
    +
    Debugger Command: abort
    +

    Calls abort on the condition given to debug. This is +useful for popping debug command loop levels or aborting to top level, +as the case may be. +

    + +
    +
    Debugger Command: return value
    +

    Returns value from the current stack frame. This command is +available when the debug optimization quality is greater than +both speed and space. Care must be taken that the value +is of the same type as SBCL expects the stack frame to return. +

    + +
    +
    Debugger Command: restart-frame
    +

    Restarts execution of the current stack frame. This command is +available when the debug optimization quality is greater than +both speed and space and when the frame is for a global +function. If the function is redefined in the debugger before the frame +is restarted, the new function will be used. +

    + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.8 Information Commands

    + +

    Most of these commands print information about the current frame or +function, but a few show general information. +

    +
    +
    Debugger Command: help
    +
    Debugger Command: ?
    +

    Displays a synopsis of debugger commands. +

    + +
    +
    Debugger Command: describe
    +

    Calls describe on the current function and displays the number of +local variables. +

    + +
    +
    Debugger Command: print
    +

    Displays the current function call as it would be displayed by moving to +this frame. +

    + +
    +
    Debugger Command: error
    +

    Prints the condition given to invoke-debugger and the active +proceed cases. +

    + +
    +
    Debugger Command: backtrace [n]
    +

    Displays all the frames from the current to the bottom. Only shows +n frames if specified. The printing is controlled by +*debug-print-variable-alist*. +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.9 Function Tracing

    + + + +

    The tracer causes selected functions to print their arguments and +their results whenever they are called. Options allow conditional +printing of the trace information and conditional breakpoints on +function entry or exit. +

    +
    +
    Macro: trace [cl] &rest specs
    +

    trace {Option Global-Value}* {Name {Option Value}*}* +

    +

    trace is a debugging tool that provides information when specified +functions are called. In its simplest form: +

    +
    +
           (TRACE NAME-1 NAME-2 ...)
+
    + +

    The NAMEs are not evaluated. Each may be one of the following: +

      +
    • symbol, denoting a function or macro. +
    • fname, a valid function name, denoting a function. +
    • (method fname qualifiers* (specializers*)) denoting a method. +
    • (compiler-macro symbol) denoting a compiler macro. +
    • (labels fname :in outer-name) or (flet fname :in outer-name) + denoting a local function where outer-name may be any of the + previous names for functions, macros, methods or compiler macros. + Tracing local functions may require debug policy 3 to inhibit + inlining. +
    • string denoting all functions fbound to symbols whose home package + is the package with the given name. + +
    +

    Options allow modification of the default behavior. Each option is a +pair of an option keyword and a value form. Global options are +specified before the first name, and affect all functions traced by a +given use of trace. Options may also be interspersed with function +names, in which case they act as local options, only affecting tracing +of the immediately preceding function name. Local options override +global options. +

    +

    By default, trace causes a printout on *trace-output* each time that +one of the named functions is entered or returns. (This is the basic, +ansi Common Lisp behavior of trace.) +

    +

    The following options are defined: +

    + +
    +
    :report Report-Type
    +

    If Report-Type is trace (the default) then information is + reported by printing immediately. If Report-Type is nil, then + the only effect of the trace is to execute other + options (e.g. print or break). Otherwise, Report-Type is + treated as a function designator and, for each trace event, + funcalled with 5 arguments: trace depth (a non-negative + integer), a function name or a function object, a + keyword (:enter, :exit or :non-local-exit), a stack frame, and + a list of values (arguments or return values). +

    + +
    +
    :condition Form
    +
    :condition-after Form
    +
    :condition-all Form
    +

    If :condition is specified, then trace does nothing unless Form + evaluates to true at the time of the call. :condition-after is + similar, but suppresses the initial printout, and is tested when the + function returns. :condition-all tries both before and after. +

    + +
    +
    :break Form
    +
    :break-after Form
    +
    :break-all Form
    +

    If specified, and Form evaluates to true, then the debugger is invoked + at the start of the function, at the end of the function, or both, + according to the respective option. +

    + +
    +
    :print Form
    +
    :print-after Form
    +
    :print-all Form
    +

    In addition to the usual printout, the result of evaluating Form is + printed at the start of the function, at the end of the function, or + both, according to the respective option. Multiple print options cause + multiple values to be printed. +

    + +
    +
    :wherein Names
    +

    If specified, Names is a function name or list of names. trace does + nothing unless a call to one of those functions encloses the call to + this function (i.e. it would appear in a backtrace.) Anonymous + functions have string names like "DEFUN FOO". +

    + +
    +
    :encapsulate {:DEFAULT | t | NIL}
    +

    If t, the default, tracing is done via encapsulation (redefining the + function name) rather than by modifying the function. :default is + not the default, but means to use encapsulation for interpreted + functions and funcallable instances, breakpoints otherwise. When + encapsulation is used, forms are *not* evaluated in the function’s + lexical environment, but sb-debug:arg can still be used. +

    + +
    +
    :methods {T | NIL}
    +

    If t, any function argument naming a generic function will have its + methods traced in addition to the generic function itself. +

    + +
    +
    :function Function-Form
    +

    This is a not really an option, but rather another way of specifying + what function to trace. The Function-Form is evaluated immediately, + and the resulting function is traced. +

    +
    +
    + +

    :condition, :break and :print forms are evaluated in a context which +mocks up the lexical environment of the called function, so that +sb-debug:var and sb-debug:arg can be used. +The -after and -all forms can use also use sb-debug:arg. In forms +which are evaluated after the function call, (sb-debug:arg n) returns +the N-th value returned by the function. +

    + +
    +
    Macro: untrace [cl] &rest specs
    +

    Remove tracing from the specified functions. Untraces all +functions when called with no arguments. +

    + +
    +
    Variable: *trace-indentation-step* [sb-debug]
    +

    the increase in trace indentation at each call level +

    + +
    +
    Variable: *max-trace-indentation* [sb-debug]
    +

    If the trace indentation exceeds this value, then indentation restarts at + 0. +

    + +
    +
    Variable: *trace-encapsulate-default* [sb-debug]
    +

    the default value for the :encapsulate option to trace +

    + +
    +
    Variable: *trace-report-default* [sb-debug]
    +

    the default value for the :report option to trace +

    + + +
    +
    +

    +Next: , Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.10 Single Stepping

    + + + +

    SBCL includes an instrumentation based single-stepper for compiled +code, that can be invoked via the step macro, or from within +the debugger. See Debugger Policy Control, for details on enabling +stepping for compiled code. +

    +

    The following debugger commands are used for controlling single stepping. +

    +
    +
    Debugger Command: start
    +

    Selects the continue restart if one exists and starts single stepping. +None of the other single stepping commands can be used before stepping has +been started either by using start or by using the standard +step macro. +

    + +
    +
    Debugger Command: step
    +

    Steps into the current form. Stepping will be resumed when the next +form that has been compiled with stepper instrumentation is evaluated. +

    + +
    +
    Debugger Command: next
    +

    Steps over the current form. Stepping will be disabled until evaluation of +the form is complete. +

    + +
    +
    Debugger Command: out
    +

    Steps out of the current frame. Stepping will be disabled until the +topmost stack frame that had been stepped into returns. +

    + +
    +
    Debugger Command: stop
    +

    Stops the single stepper and resumes normal execution. +

    + +
    +
    Macro: step [cl] form
    +

    The form is evaluated with single stepping enabled. Function calls +outside the lexical scope of the form can be stepped into only if the +functions in question have been compiled with sufficient debug policy +to be at least partially steppable. +

    + +
    +
    +

    +Previous: , Up: Debugger   [Contents][Index]

    +
    +

    5.11 Enabling and Disabling the Debugger

    + + + + + + + + +

    In certain contexts (e.g., non-interactive applications), it may be +desirable to turn off the SBCL debugger (and possibly re-enable it). +The functions here control the debugger. +

    +
    +
    Function: disable-debugger [sb-ext]
    +

    When invoked, this function will turn off both the sbcl debugger +and ldb (the low-level debugger). See also enable-debugger. +

    + +
    +
    Function: enable-debugger [sb-ext]
    +

    Restore the debugger if it has been turned off by disable-debugger. +

    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    6 Efficiency

    + + + + + + + + +
    • Slot access   +
    • Dynamic-extent allocation   +
    • Modular arithmetic   +
    • Global and Always-Bound variables   +
    • Miscellaneous Efficiency Issues   +
    + +
    +
    +

    +Next: , Up: Efficiency   [Contents][Index]

    +
    +

    6.1 Slot access

    + + +

    6.1.1 Structure object slot access

    + +

    Structure slot accessors are efficient only if the compiler is able to +open code them: compiling a call to a structure slot accessor before +the structure is defined, declaring one notinline, or passing +it as a functional argument to another function causes severe +performance degradation. +

    +

    6.1.2 Standard object slot access

    + +

    The most efficient way to access a slot of a standard-object is +by using slot-value with a constant slot name argument inside a +defmethod body, where the variable holding the instance is a +specializer parameter of the method and is never assigned to. The cost +is roughly 1.6 times that of an open coded structure slot accessor. +

    +

    Second most efficient way is to use a CLOS slot accessor, or +slot-value with a constant slot name argument, but in +circumstances other than specified above. This may be up to 3 times as +slow as the method described above. +

    +

    Example: +

    +
    +
    (defclass foo () ((bar)))
+
+;; Fast: specializer and never assigned to
+(defmethod quux ((foo foo) new)
+  (let ((old (slot-value foo 'bar)))
+    (setf (slot-value foo 'bar) new)
+    old))
+
+;; Slow: not a specializer
+(defmethod quux ((foo foo) new)
+  (let* ((temp foo)
+         (old (slot-value temp 'bar)))
+    (setf (slot-value temp 'bar) new)
+    old))
+
+;; Slow: assignment to FOO
+(defmethod quux ((foo foo) new)
+  (let ((old (slot-value foo 'bar)))
+    (setf (slot-value foo 'bar) new)
+    (setf foo new)
+    old))
+
    + +

    Note that when profiling code such as this, the first few calls to the +generic function are not representative, as the dispatch mechanism is +lazily set up during those calls. +

    +
    +
    +

    +Next: , Previous: , Up: Efficiency   [Contents][Index]

    +
    +

    6.2 Dynamic-extent allocation

    + + + +

    SBCL has fairly extensive support for performing allocation on the +stack when a variable is declared dynamic-extent. The +dynamic-extent declarations are not verified, but are simply +trusted as long as sb-ext:*stack-allocate-dynamic-extent* is +true. +

    +
    +
    Variable: *stack-allocate-dynamic-extent* [sb-ext]
    +

    If true (the default), the compiler respects dynamic-extent declarations +and stack allocates otherwise inaccessible parts of the object whenever +possible. Potentially long (over one page in size) vectors are, however, not +stack allocated except in zero safety code, as such a vector could overflow +the stack without triggering overflow protection. +

    + +

    If dynamic extent constraints specified in the Common Lisp standard +are violated, the best that can happen is for the program to have +garbage in variables and return values; more commonly, the system will +crash. +

    +

    In particular, it is important to realize that dynamic extend is +contagious: +

    +
    +
    (let* ((a (list 1 2 3))
+       (b (cons a a)))
+   (declare (dynamic-extent b))
+   ;; Unless A is accessed elsewhere as well, SBCL will consider
+   ;; it to be otherwise inaccessible -- it can only be accessed
+   ;; through B, after all -- and stack allocate it as well.
+   ;;
+   ;; Hence returning (CAR B) here is unsafe.
+   ...)
+
    + +

    This allows stack allocation of complex structures. As a notable +exception to this, SBCL does not as of 1.0.48.21 propagate +dynamic-extentness through &rest arguments – but another +conforming implementation might, so portable code should not rely on +this. +

    +
    +
    (declaim (inline foo))
+(defun foo (fun &rest arguments)
+  (declare (dynamic-extent arguments))
+  (apply fun arguments))
+
+(defun bar (a)
+  ;; SBCL will heap allocate the result of (LIST A), and stack allocate
+  ;; only the spine of the &rest list -- so this is safe, but unportable.
+  ;;
+  ;; Another implementation, including earlier versions of SBCL might consider
+  ;; (LIST A) to be otherwise inaccessible and stack-allocate it as well!
+  (foo #'car (list a)))
+
    + +

    There are many cases when dynamic-extent declarations could be +useful. At present, SBCL implements stack allocation for +

    +
      +
    • &rest lists, when these are declared dynamic-extent. + +
    • + + + +cons, list, list*, and vector when the +result is bound to a variable declared dynamic-extent. + +
    • +simple forms of make-array, whose result is bound to a variable +declared dynamic-extent: stack allocation is possible only if +the resulting array is known to be both simple and one-dimensional, +and has a constant :element-type. + + +

      Note: stack space is limited, so allocation of a large vector +may cause stack overflow. For this reason potentially large vectors, +which might circumvent stack overflow detection, are stack allocated +only in zero safety policies. +

      +
    • + + + +closures defined with flet or labels, with a bound +dynamic-extent declaration. Blocks and tags are also allocated +on the heap, unless all non-local control transfers to them are +compiled with zero safety. + +
    • user-defined structures when the structure constructor defined using +defstruct has been declared inline and the result of the +call to the constructor is bound to a variable declared +dynamic-extent. + +

      Note: structures with “raw” slots can currently be +stack-allocated only on x86 and x86-64. A “raw” slot is one whose +declared type is a subtype of exactly one of: double-float, +single-float, (complex double-float), (complex single-float), +or sb-ext:word; but as an exception to the preceding, any subtype +of fixnum is not stored as raw despite also being a subtype +of sb-ext:word. +

      +
    • all of the above when they appear as initial parts of another +stack-allocated object. + +
    + +

    Examples: +

    +
    +
    ;;; Declaiming a structure constructor inline before definition makes
+;;; stack allocation possible.
+(declaim (inline make-thing))
+(defstruct thing obj next)
+
+;;; Stack allocation of various objects bound to DYNAMIC-EXTENT
+;;; variables.
+(let* ((list (list 1 2 3))
+       (nested (cons (list 1 2) (list* 3 4 (list 5))))
+       (vector (make-array 3 :element-type 'single-float))
+       (thing (make-thing :obj list
+                          :next (make-thing :obj (make-array 3)))))
+  (declare (dynamic-extent list nested vector thing))
+  ...)
+
+;;; Stack allocation of arguments to a local function is equivalent
+;;; to stack allocation of local variable values.
+(flet ((f (x)
+         (declare (dynamic-extent x))
+         ...))
+  ...
+  (f (list 1 2 3))
+  (f (cons (cons 1 2) (cons 3 4)))
+  ...)
+
+;;; Stack allocation of &REST lists
+(defun foo (&rest args)
+  (declare (dynamic-extent args))
+  ...)
+
    + +

    Future plans include +

    +
      +
    • Automatic detection of the common idiom of calling quantifiers with a +closure, even when the closure is not declared dynamic-extent. + +
    + +
    +
    +

    +Next: , Previous: , Up: Efficiency   [Contents][Index]

    +
    +

    6.3 Modular arithmetic

    + + + + +

    Some numeric functions have a property: N lower bits of the +result depend only on N lower bits of (all or some) +arguments. If the compiler sees an expression of form (logand +exp mask), where exp is a tree of such “good” +functions and mask is known to be of type (unsigned-byte +w), where w is a “good” width, all intermediate results +will be cut to w bits (but it is not done for variables and +constants!). This often results in an ability to use simple machine +instructions for the functions. +

    +

    Consider an example. +

    +
    +
    (defun i (x y)
+  (declare (type (unsigned-byte 32) x y))
+  (ldb (byte 32 0) (logxor x (lognot y))))
+
    + +

    The result of (lognot y) will be negative and of type +(signed-byte 33), so a naive implementation on a 32-bit +platform is unable to use 32-bit arithmetic here. But modular +arithmetic optimizer is able to do it: because the result is cut down +to 32 bits, the compiler will replace logxor and lognot +with versions cutting results to 32 bits, and because terminals +(here—expressions x and y) are also of type +(unsigned-byte 32), 32-bit machine arithmetic can be used. +

    +

    As of SBCL 0.8.5 “good” functions are +, -; +logand, logior, logxor, lognot and their +combinations; and ash with the positive second +argument. “Good” widths are 32 on 32-bit CPUs and 64 on 64-bit CPUs. +While it is possible to support smaller widths as well, +currently this is not implemented. +

    +
    +
    +

    +Next: , Previous: , Up: Efficiency   [Contents][Index]

    +
    +

    6.4 Global and Always-Bound variables

    + +
    +
    Macro: defglobal [sb-ext] name value &optional doc
    +

    Defines name as a global variable that is always bound. value is evaluated +and assigned to name both at compile- and load-time, but only if name is not +already bound. +

    +

    Global variables share their values between all threads, and cannot be +locally bound, declared special, defined as constants, and neither bound +nor defined as symbol macros. +

    +

    See also the declarations sb-ext:global and sb-ext:always-bound. +

    + +
    +
    Declaration: global [sb-ext]
    +
    +

    Syntax: (sb-ext:global symbol*) +

    +

    Only valid as a global proclamation. +

    +

    Specifies that the named symbols cannot be proclaimed or locally +declared special. Proclaiming an already special or constant +variable name as global signal an error. Allows more efficient +value lookup in threaded environments in addition to expressing +programmer intention. +

    + +
    +
    Declaration: always-bound [sb-ext]
    +
    +

    Syntax: (sb-ext:always-bound symbol*) +

    +

    Only valid as a global proclamation. +

    +

    Specifies that the named symbols are always bound. Inhibits +makunbound of the named symbols. Proclaiming an unbound symbol +as always-bound signals an error. Allows the compiler to elide +boundness checks from value lookups. +

    + +
    +
    +

    +Previous: , Up: Efficiency   [Contents][Index]

    +
    +

    6.5 Miscellaneous Efficiency Issues

    + +

    FIXME: The material in the CMUCL manual about getting good +performance from the compiler should be reviewed, reformatted in +Texinfo, lightly edited for SBCL, and substituted into this +manual. In the meantime, the original CMUCL manual is still 95+% +correct for the SBCL version of the Python compiler. See the +sections +

    +
      +
    • Advanced Compiler Use and Efficiency Hints +
    • Advanced Compiler Introduction +
    • More About Types in Python +
    • Type Inference +
    • Source Optimization +
    • Tail Recursion +
    • Local Call +
    • Block Compilation +
    • Inline Expansion +
    • Object Representation +
    • Numbers +
    • General Efficiency Hints +
    • Efficiency Notes +
    + +

    Besides this information from the CMUCL manual, there are a few other +points to keep in mind. +

    +
      +
    • + + + +The CMUCL manual doesn’t seem to state it explicitly, but Python has a +mental block about type inference when assignment is involved. Python +is very aggressive and clever about inferring the types of values +bound with let, let*, inline function call, and so +forth. However, it’s much more passive and dumb about inferring the +types of values assigned with setq, setf, and +friends. It would be nice to fix this, but in the meantime don’t +expect that just because it’s very smart about types in most respects +it will be smart about types involved in assignments. (This doesn’t +affect its ability to benefit from explicit type declarations +involving the assigned variables, only its ability to get by without +explicit type declarations.) + + +
    • Since the time the CMUCL manual was written, CMUCL (and thus SBCL) has +gotten a generational garbage collector. This means that there are +some efficiency implications of various patterns of memory usage which +aren’t discussed in the CMUCL manual. (Some new material should be +written about this.) + +
    • SBCL has some important known efficiency problems. Perhaps the most +important are + +
        +
      • - The garbage collector is not particularly efficient, at least on +platforms without the generational collector (as of SBCL 0.8.9, all +except x86). + +
      • - Various aspects of the PCL implementation of CLOS are more inefficient +than necessary. + +
      + +
    + +

    Finally, note that Common Lisp defines many constructs which, in +the infamous phrase, “could be compiled efficiently by a +sufficiently smart compiler”. The phrase is infamous because +making a compiler which actually is sufficiently smart to find all +these optimizations systematically is well beyond the state of the art +of current compiler technology. Instead, they’re optimized on a +case-by-case basis by hand-written code, or not optimized at all if +the appropriate case hasn’t been hand-coded. Some cases where no such +hand-coding has been done as of SBCL version 0.6.3 include +

    +
      +
    • (reduce #'f x) where the type of x is known at compile +time + +
    • various bit vector operations, e.g. (position 0 +some-bit-vector) + +
    • specialized sequence idioms, e.g. (remove item list :count 1) + +
    • cases where local compilation policy does not require excessive type +checking, e.g. (locally (declare (safety 1)) (assoc item +list)) (which currently performs safe endp checking internal +to assoc). + +
    + +

    If your system’s performance is suffering because of some construct +which could in principle be compiled efficiently, but which the SBCL +compiler can’t in practice compile efficiently, consider writing a +patch to the compiler and submitting it for inclusion in the main +sources. Such code is often reasonably straightforward to write; +search the sources for the string “deftransform” to find many +examples (some straightforward, some less so). +

    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    7 Beyond the ANSI Standard

    + +

    SBCL is derived from CMUCL, which implements many extensions to the +ANSI standard. SBCL doesn’t support as many extensions as CMUCL, but +it still has quite a few. See Contributed Modules. +

    + + + + + + + + + + + + + + + + + + + +
    • Reader Extensions   +
    • Package-Local Nicknames   +
    • Package Variance   +
    • Garbage Collection   +
    • Slot Access   +
    • Metaobject Protocol   +
    • Extensible Sequences   +
    • Support For Unix   +
    • Unicode Support   +
    • Customization Hooks for Users   +
    • Tools To Help Developers   +
    • Resolution of Name Conflicts   +
    • Hash Table Extensions   +
    • Random Number Generation   +
    • Timeouts and Deadlines   +
    • Miscellaneous Extensions   +
    • Stale Extensions   +
    • Efficiency Hacks   +
    + +
    +
    +

    +Next: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.1 Reader Extensions

    + + +

    7.1.1 Extended Package Prefix Syntax

    + + + + + + + +

    SBCL supports extended package prefix syntax, which allows specifying +an alternate package instead of *package* for the reader to use +as the default package for interning symbols: +

    +
    +
    package-name::form-with-interning-into-package
+
    + +

    Example: +

    +
    +
      'foo::(bar quux zot) == '(foo::bar foo::quux foo::zot)
+
    + + + +

    *package* is not rebound during the course of reading a form +with extended package prefix syntax; if foo::bar would cause a +read-time package lock violation, so does foo::(bar). +

    +

    7.1.2 Symbol Name Normalization

    + + + + + +

    SBCL also extends the reader to normalize all symbols to Normalization +Form KC in builds with Unicode enabled. Whether symbols are normalized +is controlled by +

    +
    +
    Function: readtable-normalization [sb-ext] readtable
    +

    Returns t if readtable normalizes symbols to nfkc, and nil otherwise. +The readtable-normalization of the standard readtable is t. +

    + +

    Symbols created by + +intern and similar functions are not affected by this setting. If +sb-ext:readtable-normalization is t, symbols that are not +normalized are escaped during printing. +

    +

    7.1.3 Decimal Syntax for Rationals

    + + + + +

    SBCL supports a decimal syntax for rationals, modelled after the +standard syntax for floating-point numbers. If a number with +floating-point syntax has an exponent marker of r or R +(rather than one of the standard exponent markers), it is read as the +rational with the exact value of the decimal number expressed as a +float. +

    + + + + +

    In addition, setting or binding the value of +*read-default-float-format* to rational around a call to +read or read-from-string has the effect that +floating-point numbers without exponent markers are read as rational +numbers, as if there had been an explicit r or R marker. +

    + + +

    Floating point numbers of all types are printed with an exponent +marker while the value of *read-default-float-format* is +rational; however, rational numbers are printed in their +standard syntax, irrespective of the value of +*read-default-float-format*. +

    +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.2 Package-Local Nicknames

    + + + +

    SBCL allows giving packages local nicknames: they allow short and +easy-to-use names to be used without fear of name conflict associated +with normal nicknames. +

    +

    A local nickname is valid only when inside the package for which it +has been specified. Different packages can use same local nickname for +different global names, or different local nickname for same global +name. +

    + +

    Symbol :package-local-nicknames in *features* denotes +the support for this feature. +

    + +
    +
    Macro: defpackage [cl] name [[option]]* ⇒ package
    +
    +

    Options are extended to include +

    +
      +
    • :local-nicknames (local-nickname actual-package-name)* + +

      The package has the specified local nicknames for the corresponding +actual packages. +

    + +

    Example: +

    + + + +
    +
    (defpackage :bar (:intern "X"))
+(defpackage :foo (:intern "X"))
+(defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar)))
+(find-symbol "X" :foo) ; => FOO::X
+(find-symbol "X" :bar) ; => BAR::X
+(let ((*package* (find-package :quux)))
+  (find-symbol "X" :foo))               ; => BAR::X
+(let ((*package* (find-package :quux)))
+  (find-symbol "X" :bar))               ; => FOO::X
+
    +
    + +
    +
    Function: package-local-nicknames [sb-ext] package-designator
    +

    Returns an alist of (local-nickname . actual-package) describing the +nicknames local to the designated package. +

    +

    When in the designated package, calls to find-package with the any of the +local-nicknames will return the corresponding actual-package instead. This +also affects all implied calls to find-package, including those performed by +the reader. +

    +

    When printing a package prefix for a symbol with a package local nickname, the +local nickname is used instead of the real name in order to preserve +print-read consistency. +

    +

    See also: add-package-local-nickname, package-locally-nicknamed-by-list, +remove-package-local-nickname, and the defpackage option :local-nicknames. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: package-locally-nicknamed-by-list [sb-ext] package-designator
    +

    Returns a list of packages which have a local nickname for the designated +package. +

    +

    See also: add-package-local-nickname, package-local-nicknames, +remove-package-local-nickname, and the defpackage option :local-nicknames. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: add-package-local-nickname [sb-ext] local-nickname actual-package &optional package-designator
    +

    Adds local-nickname for actual-package in the designated package, defaulting +to current package. local-nickname must be a string designator, and +actual-package must be a package designator. +

    +

    Returns the designated package. +

    +

    Signals a continuable error if local-nickname is already a package local +nickname for a different package, or if local-nickname is one of "CL", +"COMMON-LISP", or, "KEYWORD", or if local-nickname is a global name or +nickname for the package to which the nickname would be added. +

    +

    When in the designated package, calls to find-package with the local-nickname +will return the package the designated actual-package instead. This also +affects all implied calls to find-package, including those performed by the +reader. +

    +

    When printing a package prefix for a symbol with a package local nickname, +local nickname is used instead of the real name in order to preserve +print-read consistency. +

    +

    See also: package-local-nicknames, package-locally-nicknamed-by-list, +remove-package-local-nickname, and the defpackage option :local-nicknames. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: remove-package-local-nickname [sb-ext] old-nickname &optional package-designator
    +

    If the designated package had old-nickname as a local nickname for +another package, it is removed. Returns true if the nickname existed and was +removed, and nil otherwise. +

    +

    See also: add-package-local-nickname, package-local-nicknames, +package-locally-nicknamed-by-list, and the defpackage option :local-nicknames. +

    +

    Experimental: interface subject to change. +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.3 Package Variance

    + +

    Common Lisp standard specifies that “If the new definition is at +variance with the current state of that package, the consequences are +undefined;” SBCL by default signals a full warning and retains as +much of the package state as possible. +

    +

    This can be adjusted using sb-ext:*on-package-variance*: +

    +
    +
    Variable: *on-package-variance* [sb-ext]
    +

    Specifies behavior when redefining a package using defpackage and the +definition is in variance with the current state of the package. +

    +

    The value should be of the form: +

    +
    +
      (:WARN [T | packages-names] :ERROR [T | package-names])
+
    + +

    specifying which packages get which behaviour -- with t signifying the default unless +otherwise specified. If default is not specified, :warn is used. +

    +

    :warn keeps as much state as possible and causes sbcl to signal a full warning. +

    +

    :error causes sbcl to signal an error when the variant defpackage form is executed, +with restarts provided for user to specify what action should be taken. +

    +

    Example: +

    +
    +
      (setf *on-package-variance* '(:warn (:swank :swank-backend) :error t))
+
    + +

    specifies to signal a warning if swank package is in variance, and an error otherwise. +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.4 Garbage Collection

    + + +

    SBCL provides additional garbage collection functionality not +specified by ANSI. +

    +
    +
    Variable: *after-gc-hooks* [sb-ext]
    +

    Called after each garbage collection, except for garbage collections +triggered during thread exits. In a multithreaded environment these hooks may +run in any thread. +

    +
    +
    Function: gc [sb-ext] &key full gen &allow-other-keys
    +

    Initiate a garbage collection. +

    +

    The default is to initiate a nursery collection, which may in turn +trigger a collection of one or more older generations as well. If full +is true, all generations are collected. If gen is provided, it can be +used to specify the oldest generation guaranteed to be collected. +

    +

    On CheneyGC platforms arguments full and gen take no effect: a full +collection is always performed. +

    + +

    7.4.1 Finalization

    + + +

    Finalization allows code to be executed after an object has been +garbage collected. This is useful for example for releasing foreign +memory associated with a Lisp object. +

    +
    +
    Function: finalize [sb-ext] object function &key dont-save
    +

    Arrange for the designated function to be called when there +are no more references to object, including references in +function itself. +

    +

    If dont-save is true, the finalizer will be cancelled when +save-lisp-and-die is called: this is useful for finalizers +deallocating system memory, which might otherwise be called +with addresses from the old image. +

    +

    In a multithreaded environment function may be called in any +thread. In both single and multithreaded environments function +may be called in any dynamic scope: consequences are unspecified +if function is not fully re-entrant. +

    +

    Errors from function are handled and cause a warning to be +signalled in whichever thread the function was called in. +

    +

    Examples: +

    +
    +
      ;;; GOOD, assuming RELEASE-HANDLE is re-entrant.
+  (let* ((handle (get-handle))
+         (object (make-object handle)))
+   (finalize object (lambda () (release-handle handle)))
+   object)
+
+  ;;; BAD, finalizer refers to object being finalized, causing
+  ;;; it to be retained indefinitely!
+  (let* ((handle (get-handle))
+         (object (make-object handle)))
+    (finalize object
+              (lambda ()
+                (release-handle (object-handle object)))))
+
+  ;;; BAD, not re-entrant!
+  (defvar *rec* nil)
+
+  (defun oops ()
+   (when *rec*
+     (error "recursive OOPS"))
+   (let ((*rec* t))
+     (gc))) ; or just cons enough to cause one
+
+  (progn
+    (finalize "oops" #'oops)
+    (oops)) ; GC causes re-entry to #'oops due to the finalizer
+            ; -> ERROR, caught, WARNING signalled
+
    +
    +
    +
    Function: cancel-finalization [sb-ext] object
    +

    Cancel all finalizations for object. +

    + +

    7.4.2 Weak Pointers

    + + +

    Weak pointers allow references to objects to be maintained without +keeping them from being garbage collected: useful for building caches +among other things. +

    +

    Hash tables can also have weak keys and values: see Hash Table Extensions. +

    +
    +
    Function: make-weak-pointer [sb-ext] object
    +

    Allocate and return a weak pointer which points to object. +

    +
    +
    Function: weak-pointer-value [sb-ext] weak-pointer
    +

    If weak-pointer is valid, return the value of weak-pointer and t. +If the referent of weak-pointer has been garbage collected, +returns the values nil and nil. +

    + +

    7.4.3 Introspection and Tuning

    + +
    +
    Variable: *gc-run-time* [sb-ext]
    +

    Total cpu time spent doing garbage collection (as reported by +get-internal-run-time.) Initialized to zero on startup. It is safe to bind +this to zero in order to measure gc time inside a certain section of code, but +doing so may interfere with results reported by eg. time. +

    +
    +
    Function: bytes-consed-between-gcs [sb-ext]
    +

    The amount of memory that will be allocated before the next garbage +collection is initiated. This can be set with setf. +

    +

    On gencgc platforms this is the nursery size, and defaults to 5% of dynamic +space size. +

    +

    Note: currently changes to this value are lost when saving core. +

    +
    +
    Function: dynamic-space-size [sb-ext]
    +

    Size of the dynamic space in bytes. +

    +
    +
    Function: get-bytes-consed [sb-ext]
    +

    Return the number of bytes consed since the program began. Typically +this result will be a consed bignum, so if you have an application (e.g. +profiling) which can’t tolerate the overhead of consing bignums, you’ll +probably want either to hack in at a lower level (as the code in the +sb-profile package does), or to design a more microefficient interface +and submit it as a patch. +

    +
    +
    Function: gc-logfile [sb-ext]
    +

    Return the pathname used to log garbage collections. Can be setf. +Default is nil, meaning collections are not logged. If non-null, the +designated file is opened before and after each collection, and generation +statistics are appended to it. +

    +
    +
    Function: generation-average-age [sb-ext] generation
    +

    Average age of memory allocated to generation: average number of times +objects allocated to the generation have seen younger objects promoted to it. +Available on gencgc platforms only. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: generation-bytes-allocated [sb-ext] generation
    +

    Number of bytes allocated to generation currently. Available on gencgc +platforms only. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: generation-bytes-consed-between-gcs [sb-ext] generation
    +

    Number of bytes that can be allocated to generation before that +generation is considered for garbage collection. This value is meaningless for +generation 0 (the nursery): see bytes-consed-between-gcs instead. Default is +5% of the dynamic space size divided by the number of non-nursery generations. +Can be assigned to using setf. Available on gencgc platforms only. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: generation-minimum-age-before-gc [sb-ext] generation
    +

    Minimum average age of objects allocated to generation before that +generation is may be garbage collected. Default is 0.75. See also +generation-average-age. Can be assigned to using setf. Available on gencgc +platforms only. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: generation-number-of-gcs-before-promotion [sb-ext] generation
    +

    Number of times garbage collection is done on generation before +automatic promotion to the next generation is triggered. Default is 1. Can be +assigned to using setf. Available on gencgc platforms only. +

    +

    Experimental: interface subject to change. +

    +
    +
    Function: generation-number-of-gcs [sb-ext] generation
    +

    Number of times garbage collection has been done on generation without +promotion. Available on gencgc platforms only. +

    +

    Experimental: interface subject to change. +

    + +

    7.4.4 Tracing Live Objects Back to Roots

    + +
    +

    note: This feature is intended to help expert users diagnose rare low-level +issues and should not be needed during normal usage. On top of that, +the interface and implementation are experimental and may change at any +time without further notice. +

    + +

    It is sometimes important to understand why a given object is retained +in the Lisp image instead of being garbage collected. To help with this +problem, SBCL provides a mechanism that searches through the different +memory spaces, builds a path of references from a root to the object in +question and finally reports this paths: +

    +
    +
    Function: search-roots [sb-ext] weak-pointers &key criterion gc ignore print
    +

    Find roots keeping the targets of weak-pointers alive. +

    +

    weak-pointers must be a single sb-ext:weak-pointer or a list of those, +pointing to objects for which roots should be searched. +

    +

    gc controls whether the search is performed in the context of a +garbage collection, that is with all Lisp threads stopped. Possible +values are: +

    + +
    +
    t
    +

    This is the more accurate of the object liveness proof generators, + as there is no chance for other code to execute in between the + garbage collection and production of the chain of referencing + objects. +

    + +
    +
    nil
    +

    This works well enough, but might be adversely affected by actions + of concurrent threads. +

    +
    +
    + +

    criterion determines just how rooty (how deep) a root must be in order +to be considered. Possible values are: +

    + +
    +
    :oldest
    +

    This says we can stop upon seeing an object in the oldest gen to + gc, or older. This is the easiest test to satisfy. +

    + +
    +
    :pseudo-static
    +

    This is usually the same as :oldest, unless the oldest gen to gc + has been decreased. +

    + +
    +
    :static
    +

    To find a root of an image-backed object, you want to stop only at + a truly :static object. +

    +
    +
    + +

    ignore is a list of objects to treat as if nonexistent in the heap. +It can often be useful for finding a path to an interned symbol other than +through its package by specifying the package as an ignored object. +

    +

    print controls whether discovered paths should be returned or +printed. Possible values are +

    + +
    +
    :verbose
    +

    Return no values. Print discovered paths using a verbose format + with each node of each path on a separate line. +

    + +
    +
    true (other than :verbose)
    +

    Return no values. Print discovered paths using a compact format + with all nodes of each path on a single line. +

    + +
    +
    nil
    +

    Do not print any output. Instead return the discovered paths as a + list of lists. Each list has the form +

    +

    (target . (root node*)) +

    +

    where target is one of the target of one of the weak-pointers. +

    +

    root is a description of the root at which the path starts and has + one of the following forms: +

    +

    :static + If the root of the path is a non-collectible heap object. +

    +

    :pinned + If an unknown thread stack pins the root of the path. +

    +

    ((thread-name | thread-object) symbol currentp) + If the path begins at a special binding of symbol in a + thread. currentp is a boolean indicating whether the value is + current or shadowed by another binding. +

    +

    ((thread-name | thread-object) guessed-pc) + If the path begins at a lexical variable in the function whose + code contains guessed-pc. +

    +

    Each node in the remainder of the path is a cons (object . slot) + indicating that the slot at index slot in object references the + next path node. +

    +
    +
    + +

    Experimental: subject to change without prior notice. +

    + +

    An example of using this could look like this: +

    +
    +
    * (defvar *my-string* (list 1 2 "my string"))
+*MY-STRING*
+
+* (sb-ext:search-roots (sb-ext:make-weak-pointer (third *my-string*)))
+ -> ((SIMPLE-VECTOR 3)) #x10004E9EAF[2] -> (SYMBOL) #x5044100F[1] -> (CONS) #x100181FAE7[1] -> (CONS) #x100181FAF7[1] -> (CONS) #x100181FB07[0] -> #x100181F9AF
+
    + +

    The single line of output on cl:*standard-output* shows the path +from a root to "my string": the path starts with SBCL’s internal +package system data structures followed by the symbol +(cl-user:*my-string*) followed the three cons cells of the list. +

    +

    The :print :verbose argument produces similar behavior but +describe the path elements in more detail: +

    +
    +
    * (sb-ext:search-roots (sb-ext:make-weak-pointer (third *my-string*)) :print :verbose)
+Path to "my string":
+ 6       10004E9EAF [   2] a (simple-vector 3)
+ 0         5044100F [   1] COMMON-LISP-USER::*MY-STRING*
+ 0       100181FAE7 [   1] a cons
+ 0       100181FAF7 [   1] a cons
+ 0       100181FB07 [   0] a cons
+
    + +

    The :print nil argument is a bit different: +

    +
    +
    * (sb-ext:search-roots (sb-ext:make-weak-pointer (third *my-string*)) :print nil)
+(("my string" :STATIC (#(*MY-STRING* 0 0) . 2) (*MY-STRING* . 1)
+  ((1 2 "my string") . 1) ((2 "my string") . 1) (("my string") . 0)))
+
    + +

    There is no output on cl:*standard-output* and the return value +is a single path for the target object "my string". As before, the +path shows the symbol and the three cons cells. +

    +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.5 Slot Access

    + + + + + +

    The slot access functions slot-value, (setf slot-value), +slot-boundp and slot-makunbound are defined to function +as expected on conditions (of metaclass condition-class) and, +with some limitations, on structures (of metaclass +structure-class). +

    +

    For structures: +

    +
      +
    • +The name of a slot for the purposes of the slot access functions is +the symbol used as the slot-name in the slot-description in the +defstruct form; + +
    • + + + +slot-value and slot-boundp function as expected, +including (for slot-value) calling and respecting the return +value of slot-unbound if the slot is unbound; + +
    • +(setf slot-value) functions as expected, including performing +type checks to verify that the new value is of an appropriate type for +the slot; + +
    • + +slot-makunbound makes the slot be unbound only when the slot +corresponds to an &aux argument with no default in a +by-order-of-arguments (BOA) constructor. In all other cases calling +slot-makunbound on a structure signals an error. + +
    • +If any of the slot access functions is called with a structure +instance which does not have a slot of the given name, +slot-missing is called and the return value of the effective +method, if any, is respected. + +
    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.6 Metaobject Protocol

    + +

    7.6.1 AMOP Compatibility of Metaobject Protocol

    + +

    SBCL supports a metaobject protocol which is intended to be compatible +with AMOP; present exceptions to this (as distinct from current bugs) +are: +

    +
      +
    • +compute-effective-method only returns one value, not two. + +

      There is no record of what the second return value was meant to +indicate, and apparently no clients for it. +

      +
    • + + + + +The direct superclasses of funcallable-standard-object are +(function standard-object), not (standard-object function). + +

      This is to ensure that the standard-object class is the last of +the standardized classes before t appearing in the class +precedence list of generic-function and +standard-generic-function, as required by section 1.4.4.5 of the +ANSI specification. +

      +
    • + +the arguments :declare and :declarations to +ensure-generic-function are both accepted, with the leftmost +argument defining the declarations to be stored and returned by +generic-function-declarations. + +

      Where AMOP specifies :declarations as the keyword argument to +ensure-generic-function, the Common Lisp standard specifies +:declare. Portable code should use :declare. +

      +
    • + + + + + +although SBCL obeys the requirement in AMOP that +validate-superclass should treat standard-class and +funcallable-standard-class as compatible metaclasses, we +impose an additional requirement at class finalization time: a class +of metaclass funcallable-standard-class must have +function in its superclasses, and a class of metaclass +standard-class must not. + + + + +

      After a class has been finalized, it is associated with a class +prototype which is accessible by a standard mop function +class-prototype. The user can then ask whether this object is a +function or not in several different ways: whether it is a +function according to typep; whether its class-of is +subtypep function, or whether function appears in +the superclasses of the class. The additional consistency requirement +comes from the desire to make all of these answers the same. +

      +

      The following class definitions are bad, and will lead to errors +either immediately or if an instance is created: +

      +
      (defclass bad-object (funcallable-standard-object)
+  ()
+  (:metaclass standard-class))
+
      +
      +
      (defclass bad-funcallable-object (standard-object)
+  ()
+  (:metaclass funcallable-standard-class))
+
      +

      The following definition is acceptable: +

      +
      (defclass mixin ()
+  ((slot :initarg slot)))
+(defclass funcallable-object (funcallable-standard-object mixin)
+  ()
+  (:metaclass funcallable-standard-class))
+
      +

      and leads to a class whose instances are funcallable and have one slot. +

      + +

      Note that this requirement also applies to the class +funcallable-standard-object, which has metaclass +funcallable-standard-class rather than +standard-class as AMOP specifies. +

      +
    • the requirement that “No portable class C_p may inherit, by +virtue of being a direct or indirect subclass of a specified class, any +slot for which the name is a symbol accessible in the +common-lisp-user package or exported by any package defined in +the ANSI Common Lisp standard.” is interpreted to mean that the +standardized classes themselves should not have slots named by external +symbols of public packages. + +

      The rationale behind the restriction is likely to be similar to the ANSI +Common Lisp restriction on defining functions, variables and types named +by symbols in the Common Lisp package: preventing two independent pieces +of software from colliding with each other. +

      +
    • + + +specializations of the new-value argument to (setf +slot-value-using-class) are not allowed: all user-defined methods must +have a specializer of the class t. + +

      This prohibition is motivated by a separation of layers: the +slot-value-using-class family of functions is intended for use in +implementing different and new slot allocation strategies, rather than +in performing application-level dispatching. Additionally, with this +requirement, there is a one-to-one mapping between metaclass, class and +slot-definition-class tuples and effective methods of (setf +slot-value-using-class), which permits optimization of (setf +slot-value-using-class)’s discriminating function in the same manner as +for slot-value-using-class and slot-boundp-using-class. +

      +

      Note that application code may specialize on the new-value +argument of slot accessors. +

      +
    • + + + + +the class named by the name argument to ensure-class, if +any, is only redefined if it is the proper name of that class; +otherwise, a new class is created. + +

      This is consistent with the description of ensure-class in AMOP +as the functional version of defclass, which has this behaviour; +however, it is not consistent with the weaker requirement in AMOP, which +states that any class found by find-class, no matter what its +class-name, is redefined. +

      +
    • + + +an error is not signaled in the case of the :name initialization +argument for slot-definition objects being a constant, when the +slot definition is of type structure-slot-definition (i.e. it is +associated with a class of type structure-class). + +

      This allows code which uses constant names for structure slots to +continue working as specified in ANSI, while enforcing the constraint +for all other types of slot. +

      +
    • + + + +the class named t is not an instance of the built-in-class +metaclass. + +

      AMOP specifies, in the “Inheritance Structure of Metaobject Classes” +section, that the class named t should be an instance of +built-in-class. However, it also specifies that +validate-superclass should return true (indicating that a direct +superclass relationship is permissible) if the second argument is the +class named t. Also, ANSI specifies that classes with metaclass +built-in-class may not be subclassed using defclass, and +also that the class named t is the universal superclass, +inconsistent with it being a built-in-class. +

      +
    • + + + + + + + +uses of change-class and redefinitions of classes with +defclass (or the functional interfaces ensure-class or +ensure-class-using-class) must ensure that for each slot with +allocation :instance or :class, the set of applicable +methods on the slot-value-using-class family of generic +functions is the same before and after the change. + +

      This is required for correct operation of the protocol to update +instances for the new or redefined class, and can be seen as part of +the contract of the :instance or :class allocations. +

      +
    + +

    7.6.2 Metaobject Protocol Extensions

    + +

    In addition, SBCL supports extensions to the Metaobject protocol from +AMOP; at present, they are: +

    +
      +
    • + + + + +compile-time support for generating specializer metaobjects from +specializer names in defmethod forms is provided by the +make-method-specializers-form function, which returns a form +which, when evaluated in the lexical environment of the +defmethod, returns a list of specializer metaobjects. This +operator suffers from similar restrictions to those affecting +make-method-lambda, namely that the generic function must be +defined when the defmethod form is expanded, so that the +correct method of make-method-specializers-form is invoked. +The system-provided method on make-method-specializers-form +generates a call to find-class for each symbol specializer +name, and a call to intern-eql-specializer for each (eql +x) specializer name. + +
    • + + +run-time support for converting between specializer names and +specializer metaobjects, mostly for the purposes of +find-method, is provided by +parse-specializer-using-class and +unparse-specializer-using-class, which dispatch on their first +argument, the generic function associated with a method with the given +specializer. The system-provided methods on those methods convert +between classes and proper names and between lists of the form +(eql x) and interned eql specializer objects. + +
    • + + + +distinguishing unbound instance allocated slots from bound ones when +using standard-instance-access and +funcallable-standard-instance-access is possible by comparison +to the symbol-macro +slot-unbound+. + +
    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.7 Extensible Sequences

    + + + + +
    • Iterator Protocol   +
    • Simple Iterator Protocol   +
    + + + + + +

    ANSI Common Lisp has a class sequence with subclasses list and +vector on which the “sequence functions” like find, +subseq, etc. operate. As an extension to the ANSI specification, +SBCL allows additional subclasses of sequence to be defined +6. +

    + + + + +

    Users of this extension just make instances of sequence subclasses +and transparently operate on them using sequence functions: +

    +
    (coerce (subseq (make-instance 'my-sequence) 5 10) 'list)
+
    +

    From this perspective, no distinction between builtin and user-defined +sequence subclasses should be necessary. +

    +

    Providers of the extension, that is of user-defined sequence +subclasses, have to adhere to a “sequence protocol” which consists of +a set of generic functions in the sequence package. +

    + + +

    A minimal sequence subclass has to specify standard-object and +sequence as its superclasses and has to be the specializer of the +sequence parameter of methods on at least the following generic +functions: +

    +
    +
    Generic Function: length [sb-sequence] sequence
    +

    Returns the length of sequence or signals a protocol-unimplemented + error if the sequence protocol is not implemented for the class of + sequence. +

    +
    +
    Generic Function: elt [sb-sequence] sequence index
    +

    Returns the element at position index of sequence or signals a + protocol-unimplemented error if the sequence protocol is not + implemented for the class of sequence. +

    +
    +
    Generic Function: (setf elt [sb-sequence])
    +

    Replaces the element at position index of sequence with new-value + and returns new-value or signals a protocol-unimplemented error if + the sequence protocol is not implemented for the class of + sequence. +

    +
    +
    Generic Function: adjust-sequence [sb-sequence] sequence length &key initial-element initial-contents
    +

    Return destructively modified sequence or a freshly allocated + sequence of the same class as sequence of length length. Elements + of the returned sequence are initialized to initial-element, if + supplied, initialized to initial-contents if supplied, or identical + to the elements of sequence if neither is supplied. Signals a + protocol-unimplemented error if the sequence protocol is not + implemented for the class of sequence. +

    +
    +
    Generic Function: make-sequence-like [sb-sequence] sequence length &key initial-element initial-contents
    +

    Returns a freshly allocated sequence of length length and of the + same class as sequence. Elements of the new sequence are + initialized to initial-element, if supplied, initialized to + initial-contents if supplied, or identical to the elements of + sequence if neither is supplied. Signals a protocol-unimplemented + error if the sequence protocol is not implemented for the class of + sequence. +

    + + + + + + +

    make-sequence-like is needed for functions returning +freshly-allocated sequences such as subseq or +copy-seq. adjust-sequence is needed for functions which +destructively modify their arguments such as delete. In fact, all +other sequence functions can be implemented in terms of the above +functions and actually are, if no additional methods are +defined. However, relying on these generic implementations, in +particular not implementing the iterator protocol can incur a high +performance penalty See Iterator Protocol. +

    +

    When the sequence protocol is only partially implemented for a given +sequence subclass, an attempt to apply one of the missing +operations to instances of that class signals the following condition: +

    +
    +
    Condition: protocol-unimplemented [sb-sequence]
    +

    Class precedence list: protocol-unimplemented, type-error, error, serious-condition, condition, t +

    +

    This error is signaled if a sequence operation is applied to an + instance of a sequence class that does not support the + operation. +

    + +

    In addition to the mandatory functions above, methods on the sequence +functions listed below can be defined. +

    +

    There are two noteworthy irregularities: +

      +
    • The function sb-sequence:emptyp does not have a counterpart in +the cl package. It is intended to be used instead of +length when working with lazy or infinite sequences. + +
    • The functions map, concatenate and merge receive a +type designator specifying the type of the constructed sequence as their +first argument. However, the corresponding generic functions +sb-sequence:map, sb-sequence:concatenate and +sb-sequence:merge receive a prototype instance of the requested +sequence subclass instead. +
    + +
    +
    Generic Function: emptyp [sb-sequence] sequence
    +

    Returns t if sequence is an empty sequence and nil + otherwise. Signals an error if sequence is not a sequence. +

    + +
      +
    • sb-sequence:count, sb-sequence:count-if, sb-sequence:count-if-not + +
    • sb-sequence:find, sb-sequence:find-if, sb-sequence:find-if-not + +
    • sb-sequence:position, sb-sequence:position-if, sb-sequence:position-if-not + +
    • sb-sequence:subseq + +
    • sb-sequence:copy-seq + +
    • sb-sequence:fill + +
    • +
      Generic Function: map [sb-sequence] result-prototype function sequence &rest sequences
      +

      Implements cl:map for extended sequences. +

      +

      result-prototype corresponds to the result-type of cl:map but + receives a prototype instance of an extended sequence class + instead of a type specifier. By dispatching on result-prototype, + methods on this generic function specify how extended sequence + classes act when they are specified as the result type in a cl:map + call. result-prototype may not be fully initialized and thus + should only be used for dispatch and to determine its class. +

      +

      Another difference to cl:map is that function is a function, not a + function designator. +

      + +
    • sb-sequence:nsubstitute, sb-sequence:nsubstitute-if, +sb-sequence:nsubstitute-if-not, sb-sequence:substitute, +sb-sequence:substitute-if, sb-sequence:substitute-if-not + +
    • sb-sequence:replace + +
    • sb-sequence:nreverse, sb-sequence:reverse + +
    • +
      Generic Function: concatenate [sb-sequence] result-prototype &rest sequences
      +

      Implements cl:concatenate for extended sequences. +

      +

      result-prototype corresponds to the result-type of cl:concatenate + but receives a prototype instance of an extended sequence class + instead of a type specifier. By dispatching on result-prototype, + methods on this generic function specify how extended sequence + classes act when they are specified as the result type in a + cl:concatenate call. result-prototype may not be fully initialized + and thus should only be used for dispatch and to determine its + class. +

      + +
    • sb-sequence:reduce + +
    • sb-sequence:mismatch + +
    • sb-sequence:search + +
    • sb-sequence:delete, sb-sequence:delete-if, sb-sequence:delete-if-not, +sb-sequence:remove, sb-sequence:remove-if, sb-sequence:remove-if-not, + +
    • sb-sequence:delete-duplicates, sb-sequence:remove-duplicates + +
    • sb-sequence:sort, sb-sequence:stable-sort + +
    • +
      Generic Function: merge [sb-sequence] result-prototype sequence1 sequence2 predicate &key key
      +

      Implements cl:merge for extended sequences. +

      +

      result-prototype corresponds to the result-type of cl:merge but + receives a prototype instance of an extended sequence class + instead of a type specifier. By dispatching on result-prototype, + methods on this generic function specify how extended sequence + classes act when they are specified as the result type in a + cl:merge call. result-prototype may not be fully initialized and + thus should only be used for dispatch and to determine its class. +

      +

      Another difference to cl:merge is that predicate is a function, + not a function designator. +

      +
    + + +

    In the spirit of dolist, generic sequences can be traversed using +the macro +

    +
    +
    Macro: dosequence [sb-sequence] (element sequence &optional return) &body body
    +

    Executes body with element subsequently bound to each element of + sequence, then returns return. +

    + +
    +
    +

    +Next: , Up: Extensible Sequences   [Contents][Index]

    +
    +

    7.7.1 Iterator Protocol

    + +

    The iterator protocol allows subsequently accessing some or all elements +of a sequence in forward or reverse direction. Users first call +make-sequence-iterator to create an iteration state and +receive functions to query and mutate it. These functions allow, among +other things, moving to, retrieving or modifying elements of the +sequence. An iteration state consists of a state object, a limit object, +a from-end indicator and the following six functions to query or mutate +this state: + +

    +
    Function: step function sequence iterator from-end
    +

    Moves the iterator one position forward or backward in the associated +sequence depending on the iteration direction. +

    +
    +
    Function: endp function sequence iterator limit from-end
    +

    Returns non-nil when the iterator has reached the end of the +associated sequence with respect to the iteration direction. +

    +
    +
    Function: element function sequence iterator
    +

    Returns the sequence element associated to the current position of the +iteration. +

    +
    +
    Function: setf element function new-value sequence iterator
    +

    Destructively modifies the associates sequence by replacing the sequence +element associated to the current iteration position with a new value. +

    +
    +
    Function: index function sequence iterator
    +

    Returns the position of the iteration in the associated sequence. +

    +
    +
    Function: copy function sequence iterator
    +

    Returns a copy of the iteration state which can be mutated independently +of the copied iteration state. +

    + +

    An iterator is created by calling: +

    +
    +
    Generic Function: make-sequence-iterator [sb-sequence] sequence &key from-end start end
    +

    Returns a sequence iterator for sequence or, if start and/or end + are supplied, the subsequence bounded by start and end as nine + values: +

    +

    1. iterator state + 2. limit + 3. from-end + 4. step function + 5. endp function + 6. element function + 7. setf element function + 8. index function + 9. copy state function +

    +

    If from-end is nil, the constructed iterator visits the specified + elements in the order in which they appear in sequence. Otherwise, + the elements are visited in the opposite order. +

    + + + + +

    Note that make-sequence-iterator calls +make-simple-sequence-iterator when there is no specialized +method for a particular sequence subclass. See Simple Iterator Protocol. +

    +

    The following convenience macros simplify traversing sequences using +iterators: +

    +
    +
    Macro: with-sequence-iterator [sb-sequence] (&optional iterator limit from-end-p step endp element set-element index copy) (sequence &key from-end start end) &body body
    +

    Executes body with the elements of vars bound to the iteration + state returned by make-sequence-iterator for sequence and + args. Elements of vars may be nil in which case the corresponding + value returned by make-sequence-iterator is ignored. +

    +
    +
    Macro: with-sequence-iterator-functions [sb-sequence] (step endp elt setf index copy) (sequence &rest args &key from-end start end) &body body
    +

    Executes body with the names step, endp, elt, setf, index and copy + bound to local functions which execute the iteration state query and + mutation functions returned by make-sequence-iterator for sequence + and args. step, endp, elt, setf, index and copy have dynamic + extent. +

    + +
    +
    +

    +Previous: , Up: Extensible Sequences   [Contents][Index]

    +
    +

    7.7.2 Simple Iterator Protocol

    + +

    For cases in which the full flexibility and performance of the general +sequence iterator protocol is not required, there is a simplified +sequence iterator protocol consisting of a few generic functions which +can be specialized for iterator classes: +

    +
    +
    Generic Function: iterator-step [sb-sequence] sequence iterator from-end
    +

    Moves iterator one position forward or backward in sequence + depending on the iteration direction encoded in from-end. +

    +
    +
    Generic Function: iterator-endp [sb-sequence] sequence iterator limit from-end
    +

    Returns non-NIL when iterator has reached limit (which may + correspond to the end of sequence) with respect to the iteration + direction encoded in from-end. +

    +
    +
    Generic Function: iterator-element [sb-sequence] sequence iterator
    +

    Returns the element of sequence associated to the position of + iterator. +

    +
    +
    Generic Function: (setf iterator-element [sb-sequence])
    +

    Destructively modifies sequence by replacing the sequence element + associated to position of iterator with new-value. +

    +
    +
    Generic Function: iterator-index [sb-sequence] sequence iterator
    +

    Returns the position of iterator in sequence. +

    +
    +
    Generic Function: iterator-copy [sb-sequence] sequence iterator
    +

    Returns a copy of iterator which also traverses sequence but can + be mutated independently of iterator. +

    + +

    Iterator objects implementing the above simple iteration protocol are +created by calling the following generic function: +

    +
    +
    Generic Function: make-simple-sequence-iterator [sb-sequence] sequence &key from-end start end
    +

    Returns a sequence iterator for sequence, start, end and from-end + as three values: +

    +

    1. iterator state + 2. limit + 3. from-end +

    +

    The returned iterator can be used with the generic iterator + functions iterator-step, iterator-endp, iterator-element, (setf + iterator-element), iterator-index and iterator-copy. +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.8 Support For Unix

    + + + + + +
    • Command-line arguments   +
    • Querying the process environment   +
    • Running external programs   +
    + +
    +
    +

    +Next: , Up: Support For Unix   [Contents][Index]

    +
    +

    7.8.1 Command-line arguments

    + + +

    The UNIX command line can be read from the variable +sb-ext:*posix-argv*. +

    +
    +
    +

    +Next: , Previous: , Up: Support For Unix   [Contents][Index]

    +
    +

    7.8.2 Querying the process environment

    + +

    The UNIX environment can be queried with the +sb-ext:posix-getenv function. +

    +
    +
    Function: posix-getenv [sb-ext] name
    +

    Return the "value" part of the environment string "name=value" which +corresponds to name, or nil if there is none. +

    + +
    +
    +

    +Previous: , Up: Support For Unix   [Contents][Index]

    +
    +

    7.8.3 Running external programs

    + +

    External programs can be run with sb-ext:run-program. +7 +

    +
    +
    Function: run-program [sb-ext] program args &key env environment wait search pty input if-input-does-not-exist output if-output-exists error if-error-exists status-hook external-format directory preserve-fds
    +

    run-program creates a new process specified by program. +args is a list of strings to be passed literally to the new program. +In posix environments, this list becomes the array supplied as the second +parameter to the execv() or execvp() system call, each list element becoming +one array element. The strings should not contain shell escaping, as there is +no shell involvement. Further note that while conventionally the process +receives its own pathname in argv[0], that is automatic, and the 0th string +should not be present in args. +

    +

    The program arguments and the environment are encoded using the +default external format for streams. +

    +

    run-program will return a process structure. See the cmu Common Lisp +Users Manual for details about the process structure. +

    +

    Notes about Unix environments (as in the :environment and :env args): +

    +
      +
    • The sbcl implementation of run-program, like Perl and many other + programs, but unlike the original cmu cl implementation, copies + the Unix environment by default. +
    • Running Unix programs from a setuid process, or in any other + situation where the Unix environment is under the control of someone + else, is a mother lode of security problems. If you are contemplating + doing this, read about it first. (The Perl community has a lot of good + documentation about this and other security issues in script-like + programs.) + +
    + +
    +
    The &key arguments have the following meanings:
    +
    :environment
    +

    a list of STRINGs describing the new Unix environment + (as in "man environ"). The default is to copy the environment of + the current process. +

    +
    +
    :env
    +

    an alternative lossy representation of the new Unix environment, + for compatibility with cmu cl +

    +
    +
    :search
    +

    Look for program in each of the directories in the child’s $PATH + environment variable. Otherwise an absolute pathname is required. +

    +
    +
    :wait
    +

    If non-NIL (default), wait until the created process finishes. If + nil, continue running Lisp until the program finishes. +

    +
    +
    :pty (not supported on win32)
    +

    Either t, nil, or a stream. Unless nil, the subprocess is established + under a pty. If :pty is a stream, all output to this pty is sent to + this stream, otherwise the process-pty slot is filled in with a stream + connected to pty that can read output and write input. +

    +
    +
    :input
    +

    Either t, nil, a pathname, a stream, or :stream. + t: the standard input for the current process is inherited. + nil: /dev/null (nul on win32) is used. + pathname: the specified file is used. + stream: all the input is read from that stream and sent to the + subprocess. + :stream: the process-input slot is filled in with a stream that sends + its output to the process. + Defaults to nil. +

    +
    +
    :if-input-does-not-exist (when :input is the name of a file)
    +

    can be one of: + :error to generate an error + :create to create an empty file + nil (the default) to return nil from run-program +

    +
    +
    :output
    +

    Either t, nil, a pathname, a stream, or :stream. + t: the standard output for the current process is inherited. + nil: /dev/null (nul on win32) is used. + pathname: the specified file is used. + stream: all the output from the process is written to this stream. + :stream: the process-output slot is filled in with a stream that can be + read to get the output. + Defaults to nil. +

    +
    +
    :error
    +

    Same as :output, additionally accepts :output, making all error + output routed to the same place as normal output. + Defaults to :output. +

    +
    +
    :if-output-exists (when :output is the name of a file)
    +

    can be one of: + :error (the default) to generate an error + :supersede to supersede the file with output from the program + :append to append output from the program to the file + nil to return nil from run-program, without doing anything +

    +
    +
    :if-error-exists
    +

    Same as :if-output-exists, controlling :error output to files. + Ignored when :error :output. + Defaults to :error. +

    +
    +
    :status-hook
    +

    This is a function the system calls whenever the status of the + process changes. The function takes the process as an argument. +

    +
    +
    :external-format
    +

    The external-format to use for :input, :output, and :error :STREAMs. +

    +
    +
    :directory
    +

    Specifies the directory in which the program should be run. + nil (the default) means the directory is unchanged. +

    + +
    +
    :preserve-fds
    +

    A sequence of file descriptors which should remain open in the child + process. +

    + +
    +
    Windows specific options:
    +
    :escape-arguments (default t)
    +

    Controls escaping of the arguments passed to CreateProcess. +

    +
    +
    :window (default nil)
    +

    When nil, the subprocess decides how it will display its window. The + following options control how the subprocess window should be displayed: + :hide, :show-normal, :show-maximized, :show-minimized, :show-no-activate, + :show-min-no-active, :show-na. + Note: console application subprocesses may or may not display a console + window depending on whether the sbcl runtime is itself a console or gui + application. Invoke cmd /C start to consistently display a console window + or use the :window :hide option to consistently hide the console window. +

    +
    + +
    + +

    When sb-ext:run-program is called with wait equal to +NIL, an instance of class sb-ext:process is returned. The +following functions are available for use with processes: +

    +
    +
    Function: process-p [sb-ext] object
    +

    t if object is a process, nil otherwise. +

    + +
    +
    Function: process-input [sb-ext] instance
    +

    The input stream of the process or nil. +

    + +
    +
    Function: process-output [sb-ext] instance
    +

    The output stream of the process or nil. +

    + +
    +
    Function: process-error [sb-ext] instance
    +

    The error stream of the process or nil. +

    + +
    +
    Function: process-alive-p [sb-ext] process
    +

    Return t if process is still alive, nil otherwise. +

    + +
    +
    Function: process-status [sb-ext] process
    +

    Return the current status of process. The result is one of :running, + :stopped, :exited, or :signaled. +

    + +
    +
    Function: process-wait [sb-ext] process &optional check-for-stopped
    +

    Wait for process to quit running for some reason. When +check-for-stopped is t, also returns when process is stopped. Returns +process. +

    + +
    +
    Function: process-exit-code [sb-ext] process
    +

    The exit code or the signal of a stopped process. +

    + +
    +
    Function: process-core-dumped [sb-ext] instance
    +

    t if a core image was dumped by the process. +

    + +
    +
    Function: process-close [sb-ext] process
    +

    Close all streams connected to process and stop maintaining the +status slot. +

    + +
    +
    Function: process-kill [sb-ext] process signal &optional whom
    +

    Hand signal to process. If whom is :pid, use the kill Unix system call. If + whom is :process-group, use the killpg Unix system call. If whom is + :pty-process-group deliver the signal to whichever process group is + currently in the foreground. + Returns t if successful, otherwise returns nil and error number (two values). +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.9 Unicode Support

    + + +

    SBCL provides support for working with Unicode text and querying the +standard Unicode database for information about individual codepoints. +Unicode-related functions are located in the sb-unicode package. +

    + + + + +

    SBCL also extends ANSI character literal syntax to support Unicode +codepoints. You can either specify a character by its Unicode name, with +spaces replaced by underscores, if a unique name exists 8 or +by giving its hexadecimal codepoint preceded by a “U”, an optional +“+”, and an arbitrary number of leading zeros. You may also input the +character directly into your source code if it can be encoded in your +file. If a character had an assigned name in Unicode 1.0 that was +distinct from its current name, you may also use that name (with spaces +replaced by underscores) to specify the character, unless the name is +already associated with a codepoint in the latest Unicode standard (such +as “BELL”). +

    +

    For example, you can specify the codepoint U+00E1 (“Latin +Small Letter A With Acute”) as +

      +
    • #\LATIN_SMALL_LETTER_A_WITH_ACUTE +
    • #\LATIN_SMALL_LETTER_A_ACUTE +
    • #\á assuming a Unicode source file +
    • #\U00E1 +
    • #\UE1 +
    • #\U+00E1 +
    + +

    7.9.1 Unicode property access

    + +

    The following functions can be used to find information about a Unicode +codepoint. +

    +
    +
    Function: general-category [sb-unicode] character
    +

    Returns the general category of character as it appears in UnicodeData.txt +

    + +
    +
    Function: bidi-class [sb-unicode] character
    +

    Returns the bidirectional class of character +

    + +
    +
    Function: combining-class [sb-unicode] character
    +

    Returns the canonical combining class (ccc) of character +

    + +
    +
    Function: decimal-value [sb-unicode] character
    +

    Returns the decimal digit value associated with character or nil if +there is no such value. +

    +

    The only characters in Unicode with a decimal digit value are those +that are part of a range of characters that encode the digits 0-9. +Because of this, ‘(decimal-digit c) <=> (digit-char-p c 10)‘ in +#+sb-unicode builds +

    + +
    +
    Function: digit-value [sb-unicode] character
    +

    Returns the Unicode digit value of character or nil if it doesn’t exist. +

    +

    Digit values are guaranteed to be integers between 0 and 9 inclusive. +All characters with decimal digit values have the same digit value, +but there are characters (such as digits of number systems without a 0 value) +that have a digit value but no decimal digit value +

    + +
    +
    Function: numeric-value [sb-unicode] character
    +

    Returns the numeric value of character or nil if there is no such value. +Numeric value is the most general of the Unicode numeric properties. +The only constraint on the numeric value is that it be a rational number. +

    + +
    +
    Function: mirrored-p [sb-unicode] character
    +

    Returns t if character needs to be mirrored in bidirectional text. +Otherwise, returns nil. +

    + +
    +
    Function: bidi-mirroring-glyph [sb-unicode] character
    +

    Returns the mirror image of character if it exists. +Otherwise, returns nil. +

    + +
    +
    Function: age [sb-unicode] character
    +

    Returns the version of Unicode in which character was assigned as a pair +of values, both integers, representing the major and minor version respectively. +If character is not assigned in Unicode, returns nil for both values. +

    + +
    +
    Function: hangul-syllable-type [sb-unicode] character
    +

    Returns the Hangul syllable type of character. +The syllable type can be one of :l, :v, :t, :lv, or :lvt. +If the character is not a Hangul syllable or Jamo, returns nil +

    + +
    +
    Function: east-asian-width [sb-unicode] character
    +

    Returns the East Asian Width property of character as +one of the keywords :n (Narrow), :a (Ambiguous), :h (Halfwidth), +:w (Wide), :f (Fullwidth), or :na (Not applicable) +

    + +
    +
    Function: script [sb-unicode] character
    +

    Returns the Script property of character as a keyword. +If character does not have a known script, returns :unknown +

    + +
    +
    Function: char-block [sb-unicode] character
    +

    Returns the Unicode block in which character resides as a keyword. +If character does not have a known block, returns :no-block +

    + +
    +
    Function: unicode-1-name [sb-unicode] character
    +

    Returns the name assigned to character in Unicode 1.0 if it is distinct +from the name currently assigned to character. Otherwise, returns nil. +This property has been officially obsoleted by the Unicode standard, and +is only included for backwards compatibility. +

    + +
    +
    Function: proplist-p [sb-unicode] character property
    +

    Returns t if character has the specified property. +property is a keyword representing one of the properties from PropList.txt, +with underscores replaced by dashes. +

    + +
    +
    Function: uppercase-p [sb-unicode] character
    +

    Returns t if character has the Unicode property Uppercase and nil otherwise +

    + +
    +
    Function: lowercase-p [sb-unicode] character
    +

    Returns t if character has the Unicode property Lowercase and nil otherwise +

    + +
    +
    Function: cased-p [sb-unicode] character
    +

    Returns t if character has a (Unicode) case, and nil otherwise +

    + +
    +
    Function: case-ignorable-p [sb-unicode] character
    +

    Returns t if character is Case Ignorable as defined in Unicode 6.3, Chapter +3 +

    + +
    +
    Function: alphabetic-p [sb-unicode] character
    +

    Returns t if character is Alphabetic according to the Unicode standard +and nil otherwise +

    + +
    +
    Function: ideographic-p [sb-unicode] character
    +

    Returns t if character has the Unicode property Ideographic, +which loosely corresponds to the set of "Chinese characters" +

    + +
    +
    Function: math-p [sb-unicode] character
    +

    Returns t if character is a mathematical symbol according to Unicode and +nil otherwise +

    + +
    +
    Function: whitespace-p [sb-unicode] character
    +

    Returns t if character is whitespace according to Unicode +and nil otherwise +

    + +
    +
    Function: soft-dotted-p [sb-unicode] character
    +

    Returns t if character has a soft dot (such as the dots on i and j) which +disappears when accents are placed on top of it. and nil otherwise +

    + +
    +
    Function: hex-digit-p [sb-unicode] character &key ascii
    +

    Returns t if character is a hexadecimal digit and nil otherwise. +If :ascii is non-NIL, fullwidth equivalents of the Latin letters A through f +are excluded. +

    + +
    +
    Function: default-ignorable-p [sb-unicode] character
    +

    Returns t if character is a Default_Ignorable_Code_Point +

    + +
    +
    Function: grapheme-break-class [sb-unicode] char
    +

    Returns the grapheme breaking class of character, as specified in uax #29. +

    + +
    +
    Function: word-break-class [sb-unicode] char
    +

    Returns the word breaking class of character, as specified in uax #29. +

    + +
    +
    Function: sentence-break-class [sb-unicode] char
    +

    Returns the sentence breaking class of character, as specified in uax #29. +

    + +
    +
    Function: line-break-class [sb-unicode] character &key resolve
    +

    Returns the line breaking class of character, as specified in uax #14. +If :resolve is nil, returns the character class found in the property file. +If :resolve is non-NIL, certain line-breaking classes will be mapped to other +classes as specified in the applicable standards. Additionally, if :resolve +is :east-asian, Ambigious (class :ai) characters will be mapped to the +Ideographic (:id) class instead of Alphabetic (:al). +

    + +

    7.9.2 String operations

    + + +

    SBCL can normalize strings using: +

    +
    +
    Function: normalize-string [sb-unicode] string &optional form filter
    +

    Normalize string to the Unicode normalization form form. +Acceptable values for form are :nfd, :nfc, :nfkd, and :nfkc. +If filter is a function it is called on each decomposed character and +only characters for which it returns t are collected. +

    + +
    +
    Function: normalized-p [sb-unicode] string &optional form
    +

    Tests if string is normalized to form +

    + +

    SBCL implements the full range of Unicode case operations with the +functions +

    +
    +
    Function: uppercase [sb-unicode] string &key locale
    +

    Returns the full uppercase of string according to the Unicode standard. +The result is not guaranteed to have the same length as the input. If :locale +is nil, no language-specific case transformations are applied. If :locale is a +keyword representing a two-letter iso country code, the case transforms of that +locale are used. If :locale is t, the user’s current locale is used (Unix and +Win32 only). +

    + +
    +
    Function: lowercase [sb-unicode] string &key locale
    +

    Returns the full lowercase of string according to the Unicode standard. +The result is not guaranteed to have the same length as the input. +:locale has the same semantics as the :locale argument to uppercase. +

    + +
    +
    Function: titlecase [sb-unicode] string &key locale
    +

    Returns the titlecase of string. The resulting string can +be longer than the input. +:locale has the same semantics as the :locale argument to uppercase. +

    + +
    +
    Function: casefold [sb-unicode] string
    +

    Returns the full casefolding of string according to the Unicode standard. +Casefolding removes case information in a way that allows the results to be used +for case-insensitive comparisons. +The result is not guaranteed to have the same length as the input. +

    + + + + +

    It also extends standard Common Lisp case functions such as +string-upcase and string-downcase to support a subset of +Unicode’s casing behavior. Specifically, a character is +both-case-p if its case mapping in Unicode is one-to-one and +invertable. +

    +

    The sb-unicode package also provides functions for +collating/sorting strings according to the Unicode Collation Algorithm. +

    +
    +
    Function: unicode< [sb-unicode] string1 string2 &key start1 end1 start2 end2
    +

    Determines whether STRING1 sorts before STRING2 using the Unicode Collation +Algorithm. The function uses an untailored Default Unicode Collation Element Table +to produce the sort keys. The function uses the Shifted method for dealing +with variable-weight characters, as described in uts #10 +

    + +
    +
    Function: unicode= [sb-unicode] string1 string2 &key start1 end1 start2 end2 strict
    +

    Determines whether STRING1 and STRING2 are canonically equivalent according +to Unicode. The start and end arguments behave like the arguments to STRING=. +If :strict is nil, UNICODE= tests compatibility equavalence instead. +

    + +
    +
    Function: unicode-equal [sb-unicode] string1 string2 &key start1 end1 start2 end2 strict
    +

    Determines whether STRING1 and STRING2 are canonically equivalent after +casefolding (that is, ignoring case differences) according to Unicode. The +start and end arguments behave like the arguments to STRING=. If :strict is +nil, UNICODE= tests compatibility equavalence instead. +

    + +
    +
    Function: unicode<= [sb-unicode] string1 string2 &key start1 end1 start2 end2
    +

    Tests if STRING1 and STRING2 are either UNICODE< or UNICODE= +

    + +
    +
    Function: unicode> [sb-unicode] string1 string2 &key start1 end1 start2 end2
    +

    Tests if STRING2 is UNICODE< STRING1. +

    + +
    +
    Function: unicode>= [sb-unicode] string1 string2 &key start1 end1 start2 end2
    +

    Tests if STRING1 and STRING2 are either UNICODE= or UNICODE> +

    + +

    The following functions are provided for detecting visually confusable strings: +

    +
    +
    Function: confusable-p [sb-unicode] string1 string2 &key start1 end1 start2 end2
    +

    Determines whether STRING1 and STRING2 could be visually confusable +according to the idna confusableSummary.txt table +

    + +

    7.9.3 Breaking strings

    + +

    The sb-unicode package includes several functions for breaking a +Unicode string into useful parts. +

    +
    +
    Function: graphemes [sb-unicode] string
    +

    Breaks string into graphemes according to the default +grapheme breaking rules specified in uax #29, returning a list of strings. +

    + +
    +
    Function: words [sb-unicode] string
    +

    Breaks string into words according to the default +word breaking rules specified in uax #29. Returns a list of strings +

    + +
    +
    Function: sentences [sb-unicode] string
    +

    Breaks string into sentences according to the default +sentence breaking rules specified in uax #29 +

    + +
    +
    Function: lines [sb-unicode] string &key margin
    +

    Breaks string into lines that are no wider than :margin according to the +line breaking rules outlined in uax #14. Combining marks will always be kept +together with their base characters, and spaces (but not other types of +whitespace) will be removed from the end of lines. If :margin is unspecified, +it defaults to 80 characters +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.10 Customization Hooks for Users

    + +

    The toplevel repl prompt may be customized, and the function +that reads user input may be replaced completely. +

    +

    The behaviour of require when called with only one argument is +implementation-defined. In SBCL, require behaves in the +following way: +

    +
    +
    Function: require [cl] module-name &optional pathnames
    +

    Loads a module, unless it already has been loaded. pathnames, if supplied, + is a designator for a list of pathnames to be loaded if the module + needs to be. If pathnames is not supplied, functions from the list + *module-provider-functions* are called in order with module-name + as an argument, until one of them returns non-NIL. User code is + responsible for calling provide to indicate a successful load of the + module. +

    +
    +
    Variable: *module-provider-functions* [sb-ext]
    +

    See function documentation for require. +

    + +

    Although SBCL does not provide a resident editor, the ed +function can be customized to hook into user-provided editing +mechanisms as follows: +

    +
    +
    Function: ed [cl] &optional x
    +

    Starts the editor (on a file or a function if named). Functions +from the list *ed-functions* are called in order with x as an argument +until one of them returns non-NIL; these functions are responsible for +signalling a file-error to indicate failure to perform an operation on +the file system. +

    +
    +
    Variable: *ed-functions* [sb-ext]
    +

    See function documentation for ed. +

    + +

    Conditions of type warning and style-warning are +sometimes signaled at runtime, especially during execution of Common +Lisp defining forms such as defun, defmethod, etc. To +muffle these warnings at runtime, SBCL provides a variable +sb-ext:*muffled-warnings*: +

    +
    +
    Variable: *muffled-warnings* [sb-ext]
    +

    A type that ought to specify a subtype of warning. Whenever a +warning is signaled, if the warning is of this type and is not +handled by any other handler, it will be muffled. +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.11 Tools To Help Developers

    + + + +

    SBCL provides a profiler and other extensions to the ANSI trace +facility. For more information, see Macro common-lisp trace. +

    +

    The debugger supports a number of options. Its documentation is +accessed by typing help at the debugger prompt. See Debugger. +

    +

    Documentation for inspect is accessed by typing help at +the inspect prompt. +

    +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.12 Resolution of Name Conflicts

    + + + +

    The ANSI standard (section 11.1.1.2.5) requires that name conflicts in +packages be resolvable in favour of any of the conflicting symbols. In +the interactive debugger, this is achieved by prompting for the symbol +in whose favour the conflict should be resolved; for programmatic use, +the sb-ext:resolve-conflict restart should be invoked with one +argument, which should be a member of the list returned by the condition +accessor sb-ext:name-conflict-symbols. +

    +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.13 Hash Table Extensions

    + + +

    Hash table extensions supported by SBCL are all controlled by keyword +arguments to make-hash-table. +

    +
    +
    Function: make-hash-table [cl] &key test size rehash-size rehash-threshold hash-function weakness synchronized
    +

    Create and return a new hash table. The keywords are as follows: +

    + +
    +
    :test
    +

    Determines how keys are compared. Must a designator for one of the + standard hash table tests, or a hash table test defined using + sb-ext:define-hash-table-test. Additionally, when an explicit + hash-function is provided (see below), any two argument equivalence + predicate can be used as the test. +

    + +
    +
    :size
    +

    A hint as to how many elements will be put in this hash table. +

    + +
    +
    :rehash-size
    +

    Indicates how to expand the table when it fills up. If an integer, add + space for that many elements. If a floating point number (which must be + greater than 1.0), multiply the size by that amount. +

    + +
    +
    :rehash-threshold
    +

    Indicates how dense the table can become before forcing a rehash. Can be + any positive number <=1, with density approaching zero as the threshold + approaches 0. Density 1 means an average of one entry per bucket. +

    + +
    +
    :hash-function
    +

    If unsupplied, a hash function based on the test argument is used, + which then must be one of the standardized hash table test functions, or + one for which a default hash function has been defined using + sb-ext:define-hash-table-test. If hash-function is specified, the test + argument can be any two argument predicate consistent with it. The + hash-function is expected to return a non-negative fixnum hash code. + If test is neither standard nor defined by define-hash-table-test, + then the hash-function must be specified. +

    + +
    +
    :weakness
    +

    When :weakness is not nil, garbage collection may remove entries from the + hash table. The value of :weakness specifies how the presence of a key or + value in the hash table preserves their entries from garbage collection. +

    +

    Valid values are: +

    +

    :key means that the key of an entry must be live to guarantee that the + entry is preserved. +

    +

    :value means that the value of an entry must be live to guarantee that + the entry is preserved. +

    +

    :key-and-value means that both the key and the value must be live to + guarantee that the entry is preserved. +

    +

    :key-or-value means that either the key or the value must be live to + guarantee that the entry is preserved. +

    +

    nil (the default) means that entries are always preserved. +

    + +
    +
    :synchronized
    +

    If nil (the default), the hash-table may have multiple concurrent readers, + but results are undefined if a thread writes to the hash-table + concurrently with another reader or writer. If t, all concurrent accesses + are safe, but note that clhs 3.6 (Traversal Rules and Side Effects) + remains in force. See also: sb-ext:with-locked-hash-table. +

    +
    + +
    + +
    +
    Macro: define-hash-table-test [sb-ext] name hash-function
    +

    Defines name as a new kind of hash table test for use with the :test +argument to make-hash-table, and associates a default hash-function with it. +

    +

    name must be a symbol naming a global two argument equivalence predicate. +Afterwards both 'name and #'name can be used with :test argument. In both +cases hash-table-test will return the symbol name. +

    +

    hash-function must be a symbol naming a global hash function consistent with +the predicate, or be a lambda form implementing one in the current lexical +environment. The hash function must compute the same hash code for any two +objects for which name returns true, and subsequent calls with already hashed +objects must always return the same hash code. +

    +

    Note: The :hash-function keyword argument to make-hash-table can be used to +override the specified default hash-function. +

    +

    Attempting to define name in a locked package as hash-table test causes a +package lock violation. +

    +

    Examples: +

    +
    +
      ;;; 1.
+
+  ;; We want to use objects of type FOO as keys (by their
+  ;; names.) EQUALP would work, but would make the names
+  ;; case-insensitive -- which we don't want.
+  (defstruct foo (name nil :type (or null string)))
+
+  ;; Define an equivalence test function and a hash function.
+  (defun foo-name= (f1 f2) (equal (foo-name f1) (foo-name f2)))
+  (defun sxhash-foo-name (f) (sxhash (foo-name f)))
+
+  (define-hash-table-test foo-name= sxhash-foo-name)
+
+  ;; #'foo-name would work too.
+  (defun make-foo-table () (make-hash-table :test 'foo-name=))
+
+  ;;; 2.
+
+  (defun == (x y) (= x y))
+
+  (define-hash-table-test ==
+    (lambda (x)
+      ;; Hash codes must be consistent with test, so
+      ;; not (SXHASH X), since
+      ;;   (= 1 1.0)                   => T
+      ;;   (= (SXHASH 1) (SXHASH 1.0)) => NIL
+      ;; Note: this doesn't deal with complex numbers or
+      ;; bignums too large to represent as double floats.
+      (sxhash (coerce x 'double-float))))
+
+  ;; #'== would work too
+  (defun make-number-table () (make-hash-table :test '==))
+
    +
    + +
    +
    Macro: with-locked-hash-table [sb-ext] (hash-table) &body body
    +

    Limits concurrent accesses to hash-table for the duration of body. +If hash-table is synchronized, body will execute with exclusive +ownership of the table. If hash-table is not synchronized, body will +execute with other with-locked-hash-table bodies excluded -- exclusion +of hash-table accesses not surrounded by with-locked-hash-table is +unspecified. +

    + +
    +
    Function: hash-table-synchronized-p [sb-ext] ht
    +

    Returns t if hash-table is synchronized. +

    + +
    +
    Function: hash-table-weakness [sb-ext] ht
    +

    Return the weakness of hash-table which is one of nil, :key, +:value, :key-and-value, :key-or-value. +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.14 Random Number Generation

    + + + + +

    The initial value of *random-state* is the same each time SBCL +is started. This makes it possible for user code to obtain repeatable +pseudo random numbers using only standard-provided functionality. See +seed-random-state below for an SBCL extension that allows to +seed the random number generator from given data for an additional +possibility to achieve this. Non-repeatable random numbers can always +be obtained using (make-random-state t). +

    + +

    The sequence of numbers produced by repeated calls to random +starting with the same random state and using the same sequence of +limit arguments is guaranteed to be reproducible only in the +same version of SBCL on the same platform, using the same code under +the same evaluator mode and compiler optimization qualities. Just two +examples of differences that may occur otherwise: calls to +random can be compiled differently depending on how much is +known about the limit argument at compile time, yielding +different results even if called with the same argument at run time, +and the results can differ depending on the machine’s word size, for +example for limits that are fixnums under 64-bit word size but bignums +under 32-bit word size. +

    +
    +
    Function: seed-random-state [sb-ext] &optional state
    +

    Make a random state object. The optional state argument specifies a seed +for deterministic pseudo-random number generation. +

    +

    As per the Common Lisp standard for make-random-state, +

      +
    • If state is nil or not supplied, return a copy of the default + *random-state*. +
    • If state is a random state, return a copy of it. +
    • If state is t, return a randomly initialized state (using operating-system + provided randomness where available, otherwise a poor substitute based on + internal time and pid). + +
    +

    As a supported sbcl extension, we also support receiving as a seed an object +of the following types: +

      +
    • (simple-array (unsigned-byte 8) (*)) +
    • unsigned-byte +
    +

    While we support arguments of any size and will mix the provided bits into +the random state, it is probably overkill to provide more than 256 bits worth +of actual information. +

    +

    This particular sbcl version also accepts an argument of the following type: +(simple-array (unsigned-byte 32) (*)) +

    +

    This particular sbcl version uses the popular MT19937 prng algorithm, and its +internal state only effectively contains about 19937 bits of information. +http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html +

    + + +

    Some notes on random floats: The standard doesn’t prescribe a specific +method of generating random floats. The following paragraph describes +SBCL’s current implementation and should be taken as purely +informational, that is, user code should not depend on any of its +specific properties. The method used has been chosen because it is +common, conceptually simple and fast. +

    + + +

    To generate random floats, SBCL evaluates code that has an equivalent +effect as +

    +
    (* limit
+   (float (/ (random (expt 2 23)) (expt 2 23)) 1.0f0))
+
    +

    (for single-floats) and correspondingly (with 52 and +1.0d0 instead of 23 and 1.0f0) for double-floats. +Note especially that this means that zero is a possible return value +occurring with probability (expt 2 -23) respectively +(expt 2 -52). Also note that there exist twice as many +equidistant floats between 0 and 1 as are generated. For example, the +largest number that (random 1.0f0) ever returns is +(float (/ (1- (expt 2 23)) (expt 2 23)) 1.0f0) while +(float (/ (1- (expt 2 24)) (expt 2 24)) 1.0f0) is the +largest single-float less than 1. This is a side effect of the fact +that the implementation uses the fastest possible conversion from bits +to floats. +

    +

    SBCL currently uses the Mersenne Twister as its random number +generator, specifically the 32-bit version under both 32- and 64-bit +word size. The seeding algorithm has been improved several times by +the authors of the Mersenne Twister; SBCL uses the third version +(from 2002) which is still the most recent as of June 2012. The +implementation has been tested to provide output identical to the +recommended C implementation. +

    +

    While the Mersenne Twister generates random numbers of much better +statistical quality than other widely used generators, it uses only +linear operations modulo 2 and thus fails some statistical +tests9. +For example, the distribution of ranks of (sufficiently large) random +binary matrices is much distorted compared to the theoretically +expected one when the matrices are generated by the Mersenne Twister. +Thus, applications that are sensitive to this aspect should use a +different type of generator. +

    +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.15 Timeouts and Deadlines

    + +

    SBCL supports three different ways of restricting the execution time +available to individual operations or parts of computations: +

    +
    +
    Timeout Parameters
    +

    Some operations such as thread synchronization primitives accept a +:timeout parameter. See Timeout Parameters. +

    +
    +
    Synchronous Timeouts (Deadlines)
    +
    +

    Certain operations that may suspend execution for extended periods of +time such as cl:sleep, thread synchronization primitives, IO and +waiting for external processes respect deadlines established for a part +of a computation. See Synchronous Timeouts (Deadlines). +

    +
    +
    Asynchronous Timeouts
    +

    Asynchronous timeouts can interrupt most computations at (almost) any +point. Thus, this kind of timeouts is the most versatile but it is also +somewhat unsafe. See Asynchronous Timeouts. +

    +
    +
    + + + + + + +
    • Timeout Parameters   +
    • Synchronous Timeouts (Deadlines)   +
    • Asynchronous Timeouts   +
    • Operations Supporting Timeouts and Deadlines   +
    + +
    +
    +

    +Next: , Up: Timeouts and Deadlines   [Contents][Index]

    +
    +

    7.15.1 Timeout Parameters

    + + + +

    Certain operations accept :timeout keyword arguments. These +only affect the specific operation and must be specified at each call +site by passing a :timeout keyword argument and a corresponding +timeout value to the respective operation. Expiration of the timeout +before the operation completes results in either a normal return with +a return value indicating the timeout or in the signaling of a +specialized condition such as sb-thread:join-thread-error. +

    +

    Example: +

    +
    +
    (defun join-thread-within-5-seconds (thread)
+  (multiple-value-bind (value result)
+      (sb-thread:join-thread thread :default nil :timeout 5)
+    (when (eq result :timeout)
+      (error "Could not join ~A within 5 seconds" thread))
+    value))
+
    + + +

    The above code attempts to join the specified thread for up to five +seconds, returning its value in case of success. If the thread is +still running after the five seconds have elapsed, +sb-thread:join-thread indicates the timeout in its second +return value. If a :default value was not provided, +sb-thread:join-thread would signal a +sb-thread:join-thread-error instead. +

    +

    To wait for an arbitrary condition, optionally with a timeout, the +sb-ext:wait-for macro can be used: +

    +
    +
    Macro: wait-for [sb-ext] test-form &key timeout
    +

    Wait until test-form evaluates to true, then return its primary value. +If timeout is provided, waits at most approximately timeout seconds before +returning nil. +

    +

    If with-deadline has been used to provide a global deadline, signals a +deadline-timeout if test-form doesn’t evaluate to true before the +deadline. +

    +

    Experimental: subject to change without prior notice. +

    + + +
    +
    +

    +Next: , Previous: , Up: Timeouts and Deadlines   [Contents][Index]

    +
    +

    7.15.2 Synchronous Timeouts (Deadlines)

    + + + + +

    Deadlines, in contrast to timeout parameters, are established for a +dynamic scope using the sb-sys:with-deadline macro and indirectly +affect operations within that scope. In case of nested uses, the +effective deadline is the one that expires first unless an inner use +explicitly overrides outer deadlines. +

    +
    +
    Macro: with-deadline [sb-sys] (&key seconds override) &body body
    +

    Arranges for a timeout condition to be signalled if an operation +respecting deadlines occurs either after the deadline has passed, or +would take longer than the time left to complete. +

    +

    Currently only sleep, blocking io operations, get-mutex, and +condition-wait respect deadlines, but this includes their implicit +uses inside sbcl itself. +

    +

    Unless override is true, existing deadlines can only be restricted, +not extended. Deadlines are per thread: children are unaffected by +their parent’s deadlines. +

    +

    Experimental. +

    + +

    Expiration of deadlines set up this way only has an effect when it +happens before or during the execution of a deadline-aware operation +(see Operations Supporting Timeouts and Deadlines). In this case, a +sb-sys:deadline-timeout is signaled. A handler for this condition +type may use the sb-sys:defer-deadline or +sb-sys:cancel-deadline restarts to defer or cancel the deadline +respectively and resume execution of the interrupted operation. +

    +
    +
    Condition: deadline-timeout [sb-sys]
    +

    Class precedence list: deadline-timeout, timeout, serious-condition, condition, t +

    +

    Signaled when an operation in the context of a deadline takes +longer than permitted by the deadline. +

    + +

    When a thread is executing the debugger, signaling of +sb-sys:deadline-timeout conditions for that thread is deferred +until it exits the debugger. +

    +

    Example: +

    +
    +
    (defun read-input ()
+  (list (read-line) (read-line)))
+
+(defun do-it ()
+  (sb-sys:with-deadline (:seconds 5))
+    (read-input)
+    (sleep 2)
+    (sb-ext:run-program "my-program"))
+
    + + + + +

    The above code establishes a deadline of five seconds within which the +body of the do-it function should execute. All calls of +deadline-aware functions in the dynamic scope, in this case two +read-line calls, a sleep call and a +sb-ext:run-program call, are affected by the deadline. If, for +example, the first read-line call completes in one second and the +second read-line call completes in three seconds, a +sb-sys:deadline-timeout condition will be signaled after the +sleep call has been executing for one second. +

    +
    +
    +

    +Next: , Previous: , Up: Timeouts and Deadlines   [Contents][Index]

    +
    +

    7.15.3 Asynchronous Timeouts

    + + + +

    Asynchronous timeouts are established for a dynamic scope using the +sb-sys:with-timeout macro: +

    +
    +
    Macro: with-timeout [sb-ext] expires &body body
    +

    Execute the body, asynchronously interrupting it and signalling a timeout +condition after at least expires seconds have passed. +

    +

    Note that it is never safe to unwind from an asynchronous condition. Consider: +

    +
    +
      (defun call-with-foo (function)
+    (let (foo)
+      (unwind-protect
+         (progn
+           (setf foo (get-foo))
+           (funcall function foo))
+       (when foo
+         (release-foo foo)))))
+
    + +

    If timeout occurs after get-foo has executed, but before the assignment, then +release-foo will be missed. While individual sites like this can be made proof +against asynchronous unwinds, this doesn’t solve the fundamental issue, as all +the frames potentially unwound through need to be proofed, which includes both +system and application code -- and in essence proofing everything will make +the system uninterruptible. +

    + +

    Expiration of the timeout will cause the operation being executed at +that moment to be interrupted by an asynchronously signaled +sb-ext:timeout condition, (almost) irregardless of the operation +and its context. +

    +
    +
    Condition: timeout [sb-ext]
    +

    Class precedence list: timeout, serious-condition, condition, t +

    +

    Signaled when an operation does not complete within an allotted time budget. +

    + +
    +
    +

    +Previous: , Up: Timeouts and Deadlines   [Contents][Index]

    +
    +

    7.15.4 Operations Supporting Timeouts and Deadlines

    + + + + + + + + + + + + + + + +
    OperationTimeout ParameterAffected by Deadlines
    cl:sleep-since SBCL 1.4.3
    cl:read-line, etc.noyes
    wait-foryesyes
    process-waitnoyes
    grab-mutexyesyes
    condition-waityesyes
    wait-on-semaphoreyesyes
    join-threadyesyes
    receive-messageyesyes?
    wait-on-gateyesyes?
    frlock-writeyesyes?
    grab-frlock-write-lockyesyes?
    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.16 Miscellaneous Extensions

    + +
    +
    Function: array-storage-vector [sb-ext] array
    +

    Returns the underlying storage vector of array, which must be a non-displaced array. +

    +

    In sbcl, if array is a of type (simple-array * (*)), it is its own storage +vector. Multidimensional arrays, arrays with fill pointers, and adjustable +arrays have an underlying storage vector with the same array-element-type as +array, which this function returns. +

    +

    Important note: the underlying vector is an implementation detail. Even though +this function exposes it, changes in the implementation may cause this +function to be removed without further warning. +

    +
    +
    Function: delete-directory [sb-ext] pathspec &key recursive
    +

    Deletes the directory designated by pathspec (a pathname designator). +Returns the truename of the directory deleted. +

    +

    If recursive is false (the default), signals an error unless the directory is +empty. If recursive is true, first deletes all files and subdirectories. If +recursive is true and the directory contains symbolic links, the links are +deleted, not the files and directories they point to. +

    +

    Signals an error if pathspec designates a file or a symbolic link instead of a +directory, or if the directory could not be deleted for any reason. +

    +

    Both +

    +
    +
       (DELETE-DIRECTORY "/tmp/foo")
+   (DELETE-DIRECTORY "/tmp/foo/")
+
    + +

    delete the "foo" subdirectory of "/tmp", or signal an error if it does not +exist or if is a file or a symbolic link. +

    +
    +
    Function: get-time-of-day [sb-ext]
    +

    Return the number of seconds and microseconds since the beginning of +the unix epoch (January 1st 1970.) +

    +
    +
    Function: assert-version->= [sb-ext] &rest subversions
    +

    Asserts that the current sbcl is of version equal to or greater than +the version specified in the arguments. A continuable error is signaled +otherwise. +

    +

    The arguments specify a sequence of subversion numbers in big endian order. +They are compared lexicographically with the runtime version, and versions +are treated as though trailed by an unbounded number of 0s. +

    +

    For example, (assert-version->= 1 1 4) asserts that the current sbcl is +version 1.1.4[.0.0...] or greater, and (assert-version->= 1) that it is +version 1[.0.0...] or greater. +

    + +
    +
    +

    +Next: , Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.17 Stale Extensions

    + +

    SBCL has inherited from CMUCL various hooks to allow the user to +tweak and monitor the garbage collection process. These are somewhat +stale code, and their interface might need to be cleaned up. If you +have urgent need of them, look at the code in src/code/gc.lisp +and bring it up on the developers’ mailing list. +

    + +

    SBCL has various hooks inherited from CMUCL, like +sb-ext:float-denormalized-p, to allow a program to take +advantage of IEEE floating point arithmetic properties which aren’t +conveniently or efficiently expressible using the ANSI standard. These +look good, and their interface looks good, but IEEE support is +slightly broken due to a stupid decision to remove some support for +infinities (because it wasn’t in the ANSI spec and it didn’t occur to +me that it was in the IEEE spec). If you need this stuff, take a look +at the code and bring it up on the developers’ mailing +list. +

    + +
    +
    +

    +Previous: , Up: Beyond the ANSI Standard   [Contents][Index]

    +
    +

    7.18 Efficiency Hacks

    + + +

    The sb-ext:purify function causes SBCL first to collect all +garbage, then to mark all uncollected objects as permanent, never again +attempting to collect them as garbage. This can cause a large increase +in efficiency when using a primitive garbage collector, or a more +moderate increase in efficiency when using a more sophisticated garbage +collector which is well suited to the program’s memory usage pattern. It +also allows permanent code to be frozen at fixed addresses, a +precondition for using copy-on-write to share code between multiple Lisp +processes. This is less important with modern generational garbage +collectors, but not all SBCL platforms use such a garbage collector. +

    + +

    The sb-ext:truly-the special form declares the type of the +result of the operations, producing its argument; the declaration is +not checked. In short: don’t use it. +

    +
    +
    Special Operator: truly-the [sb-ext] value-type form
    +

    Specifies that the values returned by form conform to the +value-type, and causes the compiler to trust this information +unconditionally. +

    +

    Consequences are undefined if any result is not of the declared type +-- typical symptoms including memory corruptions. Use with great +care. +

    + + + +

    The sb-ext:freeze-type declaration declares that a +type will never change, which can make type testing +(typep, etc.) more efficient for structure types. +

    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    8 External Formats

    + +

    External formats determine the coding of characters from/to sequences of +octets when exchanging data with the outside world. Examples of such +exchanges are: +

    +
      +
    1. Character streams associated with files, sockets and process +input/output (See Stream External Formats and Running external programs) + +
    2. Names of files + +
    3. Foreign strings (See Foreign Types and Lisp Types) + +
    4. Posix interface (See sb-posix) + +
    5. Hostname- and protocol-related functions of the BSD-socket interface +(See Networking) + +
    + +

    Technically, external formats in SBCL are named objects describing +coding of characters as well as policies in case de- or encoding is not +possible. Each external format has a canonical name and zero or more +aliases. User code mostly interacts with external formats by supplying +external format designators to functions that use external formats +internally. +

    + + + + + + +
    • The Default External Format   +
    • External Format Designators   +
    • Character Coding Conditions   +
    • Converting between Strings and Octet Vectors   +
    • Supported External Formats   +
    + +
    +
    +

    +Next: , Up: External Formats   [Contents][Index]

    +
    +

    8.1 The Default External Format

    + + +

    Most functions interacting with external formats use a default external +format if none is explicitly specified. In some cases, the default +external format is used unconditionally. +

    +

    The default external format is UTF-8. It can be changed via +

    +

    sb-ext:*default-external-format* +and +sb-ext:*default-c-string-external-format* +

    +
    +
    +

    +Next: , Previous: , Up: External Formats   [Contents][Index]

    +
    +

    8.2 External Format Designators

    + + + + +

    In situations where an external format designator is required, such as +the :external-format argument in calls to open or +with-open-file, users may supply the name of an encoding to +denote the external format which is applying that encoding to Lisp +characters. +

    +

    In addition to the basic encoding for an external format, options +controlling various special cases may be passed, by using a list (whose +first element must be an encoding name and whose rest is a plist) as an +external file format designator. +

    +

    More specifically, external format designators can take the following +forms: +

    +
    +
    :default
    +

    Designates the current default external format (See The Default External Format). +

    +
    +
    keyword
    +

    Designates the supported external format that has keyword as one +of its names. (See Supported External Formats). +

    +
    +
    (keyword :replacement replacement)
    +

    Designates an external format that is like the one designated by +keyword but does not signal an error in case a character or octet +sequence cannot be en- or decoded. Instead, it inserts replacement +at the position in question. replacement has to be a string +designator, that is a character or string. +

    +

    For example: +

    +
    (with-open-file (stream pathname :external-format '(:utf-8 :replacement #\?))
+  (read-line stream))
+
    +

    will read the first line of pathname, replacing any octet sequence +that is not valid in the UTF-8 external format with a question mark +character. +

    +
    +
    + +
    +
    +

    +Next: , Previous: , Up: External Formats   [Contents][Index]

    +
    +

    8.3 Character Coding Conditions

    + + +

    De- or encoding characters using a given external format is not always +possible: +

    +
      +
    • Decoding an octet vector using a given external format can fail if it +contains an octet or sequence of octets that does not have an +interpretation as a character according to the external format. + +
    • Conversely, a string may contain characters that a given external format +cannot encode. For example, the ASCII external format cannot encode the +character #\ö. + +
    + +

    Unless the external format governing the coding uses the +:replacement keyword, SBCL will signal (continuable) errors under +the above circumstances. The types of the condition signaled are not +currently exported or documented but will be in future SBCL versions. +

    +
    +
    +

    +Next: , Previous: , Up: External Formats   [Contents][Index]

    +
    +

    8.4 Converting between Strings and Octet Vectors

    + + +

    To encode Lisp strings as octet vectors and decode octet vectors as Lisp +strings, the following SBCL-specific functions can be used: +

    +
    +
    Function: string-to-octets [sb-ext] string &key external-format start end null-terminate
    +

    Return an octet vector that is string encoded according to external-format. +

    +

    If external-format is given, it must designate an external format. +

    +

    If given, start and end must be bounding index designators and +designate a subsequence of string that should be encoded. +

    +

    If null-terminate is true, the returned octet vector ends with an +additional 0 element that does not correspond to any part of string. +

    +

    If some of the characters of string (or the subsequence bounded by +start and end) cannot be encoded by external-format an error of a +subtype of sb-int:character-encoding-error is signaled. +

    +

    Note that for some values of external-format and null-terminate the +length of the returned vector may be different from the length of +string (or the subsequence bounded by start and end). +

    +
    +
    Function: octets-to-string [sb-ext] vector &key external-format start end
    +

    Return a string obtained by decoding vector according to external-format. +

    +

    If external-format is given, it must designate an external format. +

    +

    If given, start and end must be bounding index designators and +designate a subsequence of vector that should be decoded. +

    +

    If some of the octets of vector (or the subsequence bounded by start +and end) cannot be decoded by external-format an error of a subtype of +sb-int:character-decoding-error is signaled. +

    +

    Note that for some values of external-format the length of the +returned string may be different from the length of vector (or the +subsequence bounded by start and end). +

    + +
    +
    +

    +Previous: , Up: External Formats   [Contents][Index]

    +
    +

    8.5 Supported External Formats

    + + +

    The following table lists the external formats supported by SBCL in the +form of the respective canonical name followed by the list of aliases: +

    +
    +
    :ASCII
    +

    :US-ASCII, :ANSI_X3.4-1968, :ISO-646, :ISO-646-US, :|646| +

    +
    +
    :CP1250
    +

    :|cp1250|, :WINDOWS-1250, :|windows-1250| +

    +
    +
    :CP1251
    +

    :|cp1251|, :WINDOWS-1251, :|windows-1251| +

    +
    +
    :CP1252
    +

    :|cp1252|, :WINDOWS-1252, :|windows-1252| +

    +
    +
    :CP1253
    +

    :|cp1253|, :WINDOWS-1253, :|windows-1253| +

    +
    +
    :CP1254
    +

    :|cp1254| +

    +
    +
    :CP1255
    +

    :|cp1255|, :WINDOWS-1255, :|windows-1255| +

    +
    +
    :CP1256
    +

    :|cp1256|, :WINDOWS-1256, :|windows-1256| +

    +
    +
    :CP1257
    +

    :|cp1257|, :WINDOWS-1257, :|windows-1257| +

    +
    +
    :CP1258
    +

    :|cp1258|, :WINDOWS-1258, :|windows-1258| +

    +
    +
    :CP437
    +

    :|cp437| +

    +
    +
    :CP850
    +

    :|cp850| +

    +
    +
    :CP852
    +

    :|cp852| +

    +
    +
    :CP855
    +

    :|cp855| +

    +
    +
    :CP857
    +

    :|cp857| +

    +
    +
    :CP860
    +

    :|cp860| +

    +
    +
    :CP861
    +

    :|cp861| +

    +
    +
    :CP862
    +

    :|cp862| +

    +
    +
    :CP863
    +

    :|cp863| +

    +
    +
    :CP864
    +

    :|cp864| +

    +
    +
    :CP865
    +

    :|cp865| +

    +
    +
    :CP866
    +

    :|cp866| +

    +
    +
    :CP869
    +

    :|cp869| +

    +
    +
    :CP874
    +

    :|cp874| +

    +
    +
    :EBCDIC-US
    +

    :CP037, :|cp037|, :IBM-037, :IBM037 +

    +
    +
    :EUC-JP
    +

    :EUCJP, :|eucJP| +

    +
    +
    :GBK
    +

    :CP936 +

    +
    +
    :ISO-8859-10
    +

    :|iso-8859-10|, :LATIN-6, :|latin-6| +

    +
    +
    :ISO-8859-11
    +

    :|iso-8859-11| +

    +
    +
    :ISO-8859-13
    +

    :|iso-8859-13|, :LATIN-7, :|latin-7| +

    +
    +
    :ISO-8859-14
    +

    :|iso-8859-14|, :LATIN-8, :|latin-8| +

    +
    +
    :ISO-8859-2
    +

    :|iso-8859-2|, :LATIN-2, :|latin-2| +

    +
    +
    :ISO-8859-3
    +

    :|iso-8859-3|, :LATIN-3, :|latin-3| +

    +
    +
    :ISO-8859-4
    +

    :|iso-8859-4|, :LATIN-4, :|latin-4| +

    +
    +
    :ISO-8859-5
    +

    :|iso-8859-5| +

    +
    +
    :ISO-8859-6
    +

    :|iso-8859-6| +

    +
    +
    :ISO-8859-7
    +

    :|iso-8859-7| +

    +
    +
    :ISO-8859-8
    +

    :|iso-8859-8| +

    +
    +
    :ISO-8859-9
    +

    :|iso-8859-9|, :LATIN-5, :|latin-5| +

    +
    +
    :KOI8-R
    +

    :|koi8-r| +

    +
    +
    :KOI8-U
    +

    :|koi8-u| +

    +
    +
    :LATIN-1
    +

    :LATIN1, :ISO-8859-1, :ISO8859-1 +

    +
    +
    :LATIN-9
    +

    :LATIN9, :ISO-8859-15, :ISO8859-15 +

    +
    +
    :MAC-ROMAN
    +

    :|mac-roman|, :|MacRoman|, :MAC, :|mac|, :MACINTOSH, :|macintosh| +

    +
    +
    :SHIFT_JIS
    +

    :SJIS, :|Shift_JIS|, :CP932 +

    +
    +
    :UCS-2BE
    +

    :UCS2BE +

    +
    +
    :UCS-2LE
    +

    :UCS2LE +

    +
    +
    :UCS-4BE
    +

    :UCS4BE +

    +
    +
    :UCS-4LE
    +

    :UCS4LE +

    +
    +
    :UTF-16BE
    +

    :UTF16BE +

    +
    +
    :UTF-16LE
    +

    :UTF16LE +

    +
    +
    :UTF-32BE
    +

    :UTF32BE +

    +
    +
    :UTF-32LE
    +

    :UTF32LE +

    +
    +
    :X-MAC-CYRILLIC
    +

    :|x-mac-cyrillic| +

    +
    +
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    9 Foreign Function Interface

    + +

    This chapter describes SBCL’s interface to C programs and +libraries (and, since C interfaces are a sort of lingua +franca of the Unix world, to other programs and libraries in +general.) +

    +
    +

    Note: In the modern Lisp world, the usual term for this functionality +is Foreign Function Interface, or FFI, where despite the +mention of “function” in this term, FFI also +refers to direct manipulation of C data structures as well as +functions. The traditional CMUCL terminology is Alien Interface, and +while that older terminology is no longer used much in the system +documentation, it still reflected in names in the implementation, +notably in the name of the SB-ALIEN package. +

    + + + + + + + + + + + +
    • Introduction to the Foreign Function Interface   +
    • Foreign Types   +
    • Operations On Foreign Values   +
    • Foreign Variables   +
    • Foreign Data Structure Examples   +
    • Loading Shared Object Files   +
    • Foreign Function Calls   +
    • Calling Lisp From C   +
    • Step-By-Step Example of the Foreign Function Interface   +
    + +
    +
    +

    +Next: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.1 Introduction to the Foreign Function Interface

    + +

    Because of Lisp’s emphasis on dynamic memory allocation and garbage +collection, Lisp implementations use non-C-like memory representations +for objects. This representation mismatch creates friction when a Lisp +program must share objects with programs which expect C data. There +are three common approaches to establishing communication: +

    +
      +
    • The burden can be placed on the foreign program (and programmer) by +requiring the knowledge and use of the representations used internally +by the Lisp implementation. This can require a considerable amount of +“glue” code on the C side, and that code tends to be sensitively +dependent on the internal implementation details of the Lisp system. + +
    • The Lisp system can automatically convert objects back and forth between +the Lisp and foreign representations. This is convenient, but +translation becomes prohibitively slow when large or complex data +structures must be shared. This approach is supported by the SBCL +FFI, and used automatically when passing integers and strings. + +
    • The Lisp program can directly manipulate foreign objects through the +use of extensions to the Lisp language. + +
    + +

    SBCL, like CMUCL before it, relies primarily on the automatic +conversion and direct manipulation approaches. The SB-ALIEN +package provides a facility wherein foreign values of simple scalar +types are automatically converted and complex types are directly +manipulated in their foreign representation. Additionally the +lower-level System Area Pointers (or SAPs) can be used where +necessary to provide untyped access to foreign memory. +

    +

    Any foreign objects that can’t automatically be converted into Lisp +values are represented by objects of type alien-value. Since +Lisp is a dynamically typed language, even foreign objects must have a +run-time type; this type information is provided by encapsulating the +raw pointer to the foreign data within an alien-value object. +

    +

    The type language and operations on foreign types are +intentionally similar to those of the C language. +

    +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.2 Foreign Types

    + +

    Alien types have a description language based on nested list +structure. For example the C type +

    +
    +
    struct foo {
+    int a;
+    struct foo *b[100];
+};
+
    + +

    has the corresponding SBCL FFI type +

    +
    +
    (struct foo
+  (a int)
+  (b (array (* (struct foo)) 100)))
+
    + + + + + + +
    • Defining Foreign Types   +
    • Foreign Types and Lisp Types   +
    • Foreign Type Specifiers   +
    + +
    +
    +

    +Next: , Up: Foreign Types   [Contents][Index]

    +
    +

    9.2.1 Defining Foreign Types

    + +

    Types may be either named or anonymous. With structure and union +types, the name is part of the type specifier, allowing recursively +defined types such as: +

    +
    +
    (struct foo (a (* (struct foo))))
+
    + +

    An anonymous structure or union type is specified by using the name +nil. The with-alien macro defines a local scope which +“captures” any named type definitions. Other types are not +inherently named, but can be given named abbreviations using the +define-alien-type macro. +

    +
    +
    +

    +Next: , Previous: , Up: Foreign Types   [Contents][Index]

    +
    +

    9.2.2 Foreign Types and Lisp Types

    + +

    The foreign types form a subsystem of the SBCL type system. An +alien type specifier provides a way to use any foreign type as a +Lisp type specifier. For example, +

    +
    +
    (typep foo '(alien (* int)))
+
    + +

    can be used to determine whether foo is a pointer to a foreign +int. alien type specifiers can be used in the same ways +as ordinary Lisp type specifiers (like string.) Alien type +declarations are subject to the same precise type checking as any +other declaration. See Precise Type Checking. +

    +

    Note that the type identifiers used in the foreign type system overlap +with native Lisp type specifiers in some cases. For example, the type +specifier (alien single-float) is identical to +single-float, since foreign floats are automatically converted +to Lisp floats. When type-of is called on an alien value that +is not automatically converted to a Lisp value, then it will return an +alien type specifier. +

    +
    +
    +

    +Previous: , Up: Foreign Types   [Contents][Index]

    +
    +

    9.2.3 Foreign Type Specifiers

    + +

    Note: All foreign type names are exported from the sb-alien +package. Some foreign type names are also symbols in +the common-lisp package, in which case they are +reexported from the sb-alien package, so that +e.g. it is legal to refer to sb-alien:single-float. +

    +

    These are the basic foreign type specifiers: +

    +
      +
    • The foreign type specifier (* foo) describes a pointer to +an object of type foo. A pointed-to type foo of t +indicates a pointer to anything, similar to void * in +ANSI C. A null alien pointer can be detected with the +sb-alien:null-alien function. + +
    • The foreign type specifier (array foo &rest +dimensions) describes array of the specified dimensions, +holding elements of type foo. Note that (unlike in C) (* +foo) and (array foo) are considered to be +different types when type checking is done. If equivalence of pointer +and array types is desired, it may be explicitly coerced using +sb-alien:cast. + +

      Arrays are accessed using sb-alien:deref, passing the indices +as additional arguments. Elements are stored in column-major order +(as in C), so the first dimension determines only the size of the +memory block, and not the layout of the higher dimensions. An array +whose first dimension is variable may be specified by using nil +as the first dimension. Fixed-size arrays can be allocated as array +elements, structure slots or sb-alien:with-alien +variables. Dynamic arrays can only be allocated using +sb-alien:make-alien. +

      +
    • The foreign type specifier (sb-alien:struct name &rest +fields) describes a structure type with the specified +name and fields. Fields are allocated at the same offsets +used by the implementation’s C compiler, as guessed by the SBCL +internals. An optional :alignment keyword argument can be +specified for each field to explicitly control the alignment of a +field. If name is nil then the structure is anonymous. + +

      If a named foreign struct specifier is passed to +define-alien-type or with-alien, then this defines, +respectively, a new global or local foreign structure type. If no +fields are specified, then the fields are taken +from the current (local or global) alien structure type definition of +name. +

      +
    • The foreign type specifier (sb-alien:union name &rest +fields) is similar to sb-alien:struct, but describes a +union type. All fields are allocated at the same offset, and the size +of the union is the size of the largest field. The programmer must +determine which field is active from context. + +
    • The foreign type specifier (sb-alien:enum name &rest +specs) describes an enumeration type that maps between integer +values and symbols. If name is nil, then the type is +anonymous. Each element of the specs list is either a Lisp +symbol, or a list (symbol value). value is +an integer. If value is not supplied, then it defaults to one +greater than the value for the preceding spec (or to zero if it is the +first spec). + +
    • The foreign type specifier (sb-alien:signed &optional +bits) specifies a signed integer with the specified number of +bits precision. The upper limit on integer +precision is determined by the machine’s word size. If +bits is not specified, the maximum size will be +used. + +
    • The foreign type specifier (integer &optional bits) +is equivalent to the corresponding type specifier using +sb-alien:signed instead of integer. + +
    • The foreign type specifier (sb-alien:unsigned &optional +bits) is like corresponding type specifier using +sb-alien:signed except that the variable is treated as an +unsigned integer. + +
    • The foreign type specifier (boolean &optional bits) is +similar to an enumeration type, but maps from Lisp nil and +t to C 0 and 1 respectively. bits +determines the amount of storage allocated to hold the truth value. + +
    • The foreign type specifier single-float describes a +floating-point number in IEEE single-precision format. + +
    • The foreign type specifier double-float describes a +floating-point number in IEEE double-precision format. + +
    • The foreign type specifier (function result-type &rest +arg-types) describes a foreign function that takes arguments of +the specified arg-types and returns a result of type +result-type. Note that the only context where a foreign +function type is directly specified is in the argument to +sb-alien:alien-funcall. In all other contexts, foreign +functions are represented by foreign function pointer types: (* +(function …)). + +
    • The foreign type specifier sb-alien:system-area-pointer +describes a pointer which is represented in Lisp as a +system-area-pointer object. SBCL exports this type from +sb-alien because CMUCL did, but tentatively (as of the first +draft of this section of the manual, SBCL 0.7.6) it is deprecated, +since it doesn’t seem to be required by user code. + +
    • The foreign type specifier sb-alien:void is used in function +types to declare that no useful value is returned. Using +alien-funcall to call a void foreign function will +return zero values. + +
    • +The foreign type specifier (sb-alien:c-string &key +external-format element-type not-null) is similar to +(* char), but is interpreted as a null-terminated string, and +is automatically converted into a Lisp string when accessed; or if the +pointer is C NULL or 0, then accessing it gives Lisp +nil unless not-null is true, in which case a type-error +is signalled. + +

      External format conversion is automatically done when Lisp strings are +passed to foreign code, or when foreign strings are passed to Lisp code. +If the type specifier has an explicit external-format, that +external format will be used. Otherwise a default external format that +has been determined at SBCL startup time based on the current locale +settings will be used. For example, when the following alien routine is +called, the Lisp string given as argument is converted to an +ebcdic octet representation. +

      +
      +
      (define-alien-routine test int (str (c-string :external-format :ebcdic-us)))
+
      + +

      Lisp strings of type base-string are stored with a trailing NUL +termination, so no copying (either by the user or the implementation) is +necessary when passing them to foreign code, assuming that the +external-format and element-type of the c-string +type are compatible with the internal representation of the string. For +an SBCL built with Unicode support that means an external-format +of :ascii and an element-type of base-char. Without +Unicode support the external-format can also be +:iso-8859-1, and the element-type can also be +character. If the external-format or element-type +is not compatible, or the string is a (simple-array character +(*)), this data is copied by the implementation as required. +

      +

      Assigning a Lisp string to a c-string structure field or +variable stores the contents of the string to the memory already +pointed to by that variable. When a foreign object of type (* +char) is assigned to a c-string, then the +c-string pointer is assigned to. This allows +c-string pointers to be initialized. For example: +

      +
      +
      (cl:in-package "CL-USER") ; which USEs package "SB-ALIEN"
+
+(define-alien-type nil (struct foo (str c-string)))
+
+(defun make-foo (str)
+  (let ((my-foo (make-alien (struct foo))))
+    (setf (slot my-foo 'str) (make-alien char (length str))
+          (slot my-foo 'str) str)
+    my-foo))
+
      + +

      Storing Lisp NIL in a c-string writes C NULL to +the variable. +

      +
    • sb-alien also exports translations of these C type +specifiers as foreign type specifiers: +char, +short, +int, +long, +unsigned-char, +unsigned-short, +unsigned-int, +unsigned-long, +float, double, +size-t, and off-t. + +
    + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.3 Operations On Foreign Values

    + +

    This section describes how to read foreign values as Lisp values, how +to coerce foreign values to different kinds of foreign values, and how +to dynamically allocate and free foreign variables. +

    + + + + +
    • Accessing Foreign Values   +
    • Coercing Foreign Values   +
    • Foreign Dynamic Allocation   +
    + +
    +
    +

    +Next: , Up: Operations On Foreign Values   [Contents][Index]

    +
    +

    9.3.1 Accessing Foreign Values

    + +
    +
    Function: deref [sb-alien] pointer-or-array &rest indices
    +
    +

    The sb-alien:deref function returns the value pointed to by a +foreign pointer, or the value of a foreign array element. When +dereferencing a pointer, an optional single index can be specified to +give the equivalent of C pointer arithmetic; this index is scaled by +the size of the type pointed to. When dereferencing an array, the +number of indices must be the same as the number of dimensions in the +array type. deref can be set with setf to assign a new +value. +

    + +
    +
    Function: slot [sb-alien] struct-or-union slot-name
    +
    +

    The sb-alien:slot function extracts the value of the slot named +slot-name from a foreign struct or union. If +struct-or-union is a pointer to a structure or union, then it is +automatically dereferenced. sb-alien:slot can be set with +setf to assign a new value. Note that slot-name is +evaluated, and need not be a compile-time constant (but only constant +slot accesses are efficiently compiled). +

    + + +

    9.3.1.1 Untyped memory

    + +

    As noted at the beginning of the chapter, the System Area Pointer +facilities allow untyped access to foreign memory. SAPs can +be converted to and from the usual typed foreign values using +sap-alien and alien-sap (described elsewhere), and also +to and from integers - raw machine addresses. They should thus be +used with caution; corrupting the Lisp heap or other memory with +SAPs is trivial. +

    +
    +
    Function: int-sap [sb-sys] machine-address
    +
    +

    Creates a SAP pointing at the virtual address +machine-address. +

    + +
    +
    Function: sap-ref-32 [sb-sys] sap offset
    +
    +

    Access the value of the memory location at offset bytes from +sap. This form may also be used with setf to alter the +memory at that location. +

    + +
    +
    Function: sap= [sb-sys] sap1 sap2
    +
    +

    Compare sap1 and sap2 for equality. +

    + +

    Similarly named functions exist for accessing other sizes of word, +other comparisons, and other conversions. The reader is invited to +use apropos and describe for more details +

    +
    +
    (apropos "sap" :sb-sys)
+
    + + +
    +
    +

    +Next: , Previous: , Up: Operations On Foreign Values   [Contents][Index]

    +
    +

    9.3.2 Coercing Foreign Values

    + +
    +
    Macro: addr [sb-alien] alien-expr
    +
    +

    The sb-alien:addr macro returns a pointer to the location +specified by alien-expr, which must be either a foreign +variable, a use of sb-alien:deref, a use of +sb-alien:slot, or a use of sb-alien:extern-alien. +

    + +
    +
    Macro: cast [sb-alien] foreign-value new-type
    +
    +

    The sb-alien:cast macro converts foreign-value to a new +foreign value with the specified new-type. Both types, old and +new, must be foreign pointer, array or function types. Note that the +resulting Lisp foreign variable object is not eq to the +argument, but it does refer to the same foreign data bits. +

    + +
    +
    Macro: sap-alien [sb-alien] sap type
    +
    +

    The sb-alien:sap-alien macro converts sap (a system +area pointer) to a foreign value with the specified +type. type is not evaluated. +

    +

    The type must be some foreign pointer, array, or record type. +

    + +
    +
    Function: alien-sap [sb-alien] foreign-value
    +
    +

    The sb-alien:alien-sap function returns the SAP which +points to alien-value’s data. +

    +

    The foreign-value must be of some foreign pointer, array, or +record type. +

    + + +
    +
    +

    +Previous: , Up: Operations On Foreign Values   [Contents][Index]

    +
    +

    9.3.3 Foreign Dynamic Allocation

    + +

    Lisp code can call the C standard library functions malloc and +free to dynamically allocate and deallocate foreign variables. +The Lisp code shares the same allocator with foreign C code, so it’s +OK for foreign code to call free on the result of Lisp +sb-alien:make-alien, or for Lisp code to call +sb-alien:free-alien on foreign objects allocated by C code. +

    +
    +
    Macro: make-alien [sb-alien] type &optional size
    +

    Allocate an alien of type type in foreign heap, and return an alien +pointer to it. The allocated memory is not initialized, and may +contain garbage. The memory is allocated using malloc(3), so it can be +passed to foreign functions which use free(3), or released using +free-alien. +

    +

    For alien stack allocation, see macro with-alien. +

    +

    The type argument is not evaluated. If size is supplied, how it is +interpreted depends on type: +

    +
      +
    • When type is a foreign array type, an array of that type is + allocated, and a pointer to it is returned. Note that you + must use deref to first access the array through the pointer. + +

      If supplied, size is used as the first dimension for the array. +

      +
    • When type is any other foreign type, then an object for that + type is allocated, and a pointer to it is returned. So + (make-alien int) returns a (* int). + +

      If size is specified, then a block of that many objects is + allocated, with the result pointing to the first one. +

      +
    +

    Examples: +

    +
    +
      (defvar *foo* (make-alien (array char 10)))
+  (type-of *foo*)                   ; => (alien (* (array (signed 8) 10)))
+  (setf (deref (deref *foo*) 0) 10) ; => 10
+
+  (make-alien char 12)              ; => (alien (* (signed 8)))
+
    +
    +
    +
    Function: make-alien-string [sb-alien] string &rest rest &key start end external-format null-terminate
    +

    Copy part of string delimited by start and end into freshly +allocated foreign memory, freeable using free(3) or free-alien. +Returns the allocated string as a (* char) alien, and the number of +bytes allocated as secondary value. +

    +

    The string is encoded using external-format. If null-terminate is +true (the default), the alien string is terminated by an additional +null byte. +

    +
    +
    Function: free-alien [sb-alien] alien
    +

    Dispose of the storage pointed to by alien. The alien must have been +allocated by make-alien, make-alien-string or malloc(3). +

    + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.4 Foreign Variables

    + +

    Both local (stack allocated) and external (C global) foreign variables +are supported. +

    + + + +
    • Local Foreign Variables   +
    • External Foreign Variables   +
    + +
    +
    +

    +Next: , Up: Foreign Variables   [Contents][Index]

    +
    +

    9.4.1 Local Foreign Variables

    + +
    +
    Macro: with-alien [sb-alien] var-definitions &body body
    +
    +

    The with-alien macro establishes local foreign variables with +the specified alien types and names. This form is analogous to +defining a local variable in C: additional storage is allocated, and +the initial value is copied. This form is less analogous to +LET-allocated Lisp variables, since the variables can’t be +captured in closures: they live only for the dynamic extent of the +body, and referring to them outside is a gruesome error. +

    +

    The var-definitions argument is a list of +variable definitions, each of the form +

    +
    (name type &optional initial-value)
+
    + +

    The names of the variables are established as symbol-macros; the +bindings have lexical scope, and may be assigned with setq or +setf. +

    +

    The with-alien macro also establishes a new scope for named +structures and unions. Any type specified for a variable may +contain named structure or union types with the slots specified. +Within the lexical scope of the binding specifiers and body, a locally +defined foreign structure type foo can be referenced by its name +using (struct foo). +

    + +
    +
    +

    +Previous: , Up: Foreign Variables   [Contents][Index]

    +
    +

    9.4.2 External Foreign Variables

    + +

    External foreign names are strings, and Lisp names are symbols. When +an external foreign value is represented using a Lisp variable, there +must be a way to convert from one name syntax into the other. The +macros extern-alien, define-alien-variable and +define-alien-routine use this conversion heuristic: +

    +
      +
    • Alien names are converted to Lisp names by uppercasing and replacing +underscores with hyphens. + +
    • Conversely, Lisp names are converted to alien names by lowercasing and +replacing hyphens with underscores. + +
    • Both the Lisp symbol and alien string names may be separately +specified by using a list of the form + +
      +
      (alien-string lisp-symbol)
+
      + +
    + +
    +
    Macro: define-alien-variable [sb-alien] name type
    +
    +

    The define-alien-variable macro defines name as an +external foreign variable of the specified foreign type. +name and type are not evaluated. The Lisp name of the +variable (see above) becomes a global alien variable. Global alien +variables are effectively “global symbol macros”; a reference to the +variable fetches the contents of the external variable. Similarly, +setting the variable stores new contents – the new contents must be +of the declared type. Someday, they may well be implemented +using the ANSI define-symbol-macro mechanism, but as +of SBCL 0.7.5, they are still implemented using an older more-or-less +parallel mechanism inherited from CMUCL. +

    +

    For example, to access a C-level counter foo, one could write +

    +
    +
    (define-alien-variable "foo" int)
+;; Now it is possible to get the value of the C variable foo simply by
+;; referencing that Lisp variable:
+(print foo)
+(setf foo 14)
+(incf foo)
+
    +
    + +
    +
    Function: get-errno [sb-alien]
    +
    +

    Since in modern C libraries, the errno “variable” is typically +no longer a variable, but some bizarre artificial construct +which behaves superficially like a variable within a given thread, +it can no longer reliably be accessed through the ordinary +define-alien-variable mechanism. Instead, SBCL provides +the operator sb-alien:get-errno to allow Lisp code to read it. +

    + +
    +
    Macro: extern-alien [sb-alien] name type
    +
    +

    The extern-alien macro returns an alien with the specified +type which points to an externally defined value. name is +not evaluated, and may be either a string or a symbol. type is +an unevaluated alien type specifier. +

    + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.5 Foreign Data Structure Examples

    + +

    Now that we have alien types, operations and variables, we can +manipulate foreign data structures. This C declaration +

    +
    +
    struct foo {
+    int a;
+    struct foo *b[100];
+};
+
    + +

    can be translated into the following alien type: +

    +
    +
    (define-alien-type nil
+  (struct foo
+    (a int)
+    (b (array (* (struct foo)) 100))))
+
    + +

    Once the foo alien type has been defined as above, the C +expression +

    +
    +
    struct foo f;
+f.b[7].a;
+
    + +

    can be translated in this way: +

    +
    +
    (with-alien ((f (struct foo)))
+  (slot (deref (slot f 'b) 7) 'a)
+  ;;
+  ;; Do something with f...
+  )
+
    + +

    Or consider this example of an external C variable and some accesses: +

    +
    +
    struct c_struct {
+        short x, y;
+        char a, b;
+        int z;
+        c_struct *n;
+};
+extern struct c_struct *my_struct;
+my_struct->x++;
+my_struct->a = 5;
+my_struct = my_struct->n;
+
    + +

    which can be manipulated in Lisp like this: +

    +
    +
    (define-alien-type nil
+  (struct c-struct
+          (x short)
+          (y short)
+          (a char)
+          (b char)
+          (z int)
+          (n (* c-struct))))
+(define-alien-variable "my_struct" (* c-struct))
+(incf (slot my-struct 'x))
+(setf (slot my-struct 'a) 5)
+(setq my-struct (slot my-struct 'n))
+
    + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.6 Loading Shared Object Files

    + +

    Foreign object files can be loaded into the running Lisp process by +calling load-shared-object. +

    +
    +
    Function: load-shared-object [sb-alien] pathname &key dont-save
    +

    Load a shared library / dynamic shared object file / similar foreign +container specified by designated pathname, such as a .so on an elf platform. +

    +

    Locating the shared object follows standard rules of the platform, consult the +manual page for dlopen(3) for details. Typically paths specified by +environment variables such as LD_LIBRARY_PATH are searched if the pathname has +no directory, but on some systems (eg. Mac os x) search may happen even if +pathname is absolute. (On Windows LoadLibrary is used instead of dlopen(3).) +

    +

    On non-Windows platforms calling load-shared-object again with a pathname +equal to the designated pathname of a previous call will replace the old +definitions; if a symbol was previously referenced through the object and +is not present in the reloaded version an error will be signalled. Reloading +may not work as expected if user or library-code has called dlopen(3) on the +same shared object or running on a system where dlclose(3) is a noop. +

    +

    load-shared-object interacts with sb-ext:save-lisp-and-die: +

    +

    1. If dont-save is true (default is nil), the shared object will be dropped +when save-lisp-and-die is called -- otherwise shared objects are reloaded +automatically when a saved core starts up. Specifying dont-save can be useful +when the location of the shared object on startup is uncertain. +

    +

    2. On most platforms references in compiled code to foreign symbols in shared +objects (such as those generated by define-alien-routine) remain valid across +save-lisp-and-die. On those platforms where this is not supported, a warning +will be signalled when the core is saved -- this is orthogonal from dont-save. +

    + +
    +
    Function: unload-shared-object [sb-alien] pathname
    +

    Unloads the shared object loaded earlier using the designated pathname with +load-shared-object, to the degree supported on the platform. +

    +

    Experimental. +

    + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.7 Foreign Function Calls

    + +

    The foreign function call interface allows a Lisp program to call +many functions written in languages that use the C calling convention. +

    +

    Lisp sets up various signal handling routines and other environment +information when it first starts up, and expects these to be in place +at all times. The C functions called by Lisp should not change the +environment, especially the signal handlers: the signal handlers +installed by Lisp typically have interesting flags set (e.g to request +machine context information, or for signal delivery on an alternate +stack) which the Lisp runtime relies on for correct operation. +Precise details of how this works may change without notice between +versions; the source, or the brain of a friendly SBCL developer, is +the only documentation. Users of a Lisp built with the +:sb-thread feature should also read the section about threads, +Threading. +

    + + + + +
    • The alien-funcall Primitive   +
    • The define-alien-routine Macro   +
    • define-alien-routine Example   +
    + +
    +
    +

    +Next: , Up: Foreign Function Calls   [Contents][Index]

    +
    +

    9.7.1 The alien-funcall Primitive

    + +
    +
    Function: alien-funcall [sb-alien] alien-function &rest arguments
    +
    +

    The alien-funcall function is the foreign function call +primitive: alien-function is called with the supplied +arguments and its C return value is returned as a Lisp value. +The alien-function is an arbitrary run-time expression; to refer +to a constant function, use extern-alien or a value defined by +define-alien-routine. +

    +

    The type of alien-function must be (alien (function +...)) or (alien (* (function ...))). The function type is +used to determine how to call the function (as though it was declared +with a prototype.) The type need not be known at compile time, but +only known-type calls are efficiently compiled. Limitations: +

    +
      +
    • Structure type return values are not implemented. + +
    • Passing of structures by value is not implemented. + +
    + +
    + +

    Here is an example which allocates a (struct foo), calls a +foreign function to initialize it, then returns a Lisp vector of all +the (* (struct foo)) objects filled in by the foreign call: +

    +
    +
    ;; Allocate a foo on the stack.
+(with-alien ((f (struct foo)))
+  ;; Call some C function to fill in foo fields.
+  (alien-funcall (extern-alien "mangle_foo" (function void (* foo)))
+                 (addr f))
+  ;; Find how many foos to use by getting the A field.
+  (let* ((num (slot f 'a))
+         (result (make-array num)))
+    ;; Get a pointer to the array so that we don't have to keep extracting it:
+    (with-alien ((a (* (array (* (struct foo)) 100)) (addr (slot f 'b))))
+      ;; Loop over the first N elements and stash them in the result vector.
+      (dotimes (i num)
+        (setf (svref result i) (deref (deref a) i)))
+      ;; Voila.
+      result)))
+
    + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Calls   [Contents][Index]

    +
    +

    9.7.2 The define-alien-routine Macro

    + +
    +
    Macro: define-alien-routine [sb-alien] name result-type &rest arg-specifiers
    +
    +

    The define-alien-routine macro is a convenience for +automatically generating Lisp interfaces to simple foreign functions. +The primary feature is the parameter style specification, which +translates the C pass-by-reference idiom into additional return +values. +

    +

    name is usually a string external symbol, but may also be a +symbol Lisp name or a list of the foreign name and the Lisp name. If +only one name is specified, the other is automatically derived as for +extern-alien. result-type is the alien type of the +return value. +

    +

    Each element of the arg-specifiers list +specifies an argument to the foreign function, and is +of the form +

    +
    (aname atype &amp;optional style)
+
    + +

    aname is the symbol name of the argument to the constructed +function (for documentation). atype is the alien type of +corresponding foreign argument. The semantics of the actual call are +the same as for alien-funcall. style specifies how this +argument should be handled at call and return time, and should be one +of the following: +

    +
      +
    • :in specifies that the argument is passed by value. This is the +default. :in arguments have no corresponding return value from +the Lisp function. + +
    • :copy is similar to :in, but the argument is copied to a +pre-allocated object and a pointer to this object is passed to the +foreign routine. + +
    • :out specifies a pass-by-reference output value. The type of +the argument must be a pointer to a fixed-sized object (such as an +integer or pointer). :out and :in-out style cannot be +used with pointers to arrays, records or functions. An object of the +correct size is allocated on the stack, and its address is passed to +the foreign function. When the function returns, the contents of this +location are returned as one of the values of the Lisp function (and +the location is automatically deallocated). + +
    • :in-out is a combination of :copy and :out. The +argument is copied to a pre-allocated object and a pointer to this +object is passed to the foreign routine. On return, the contents of +this location is returned as an additional value. + +
    + +
    +

    Note: Any efficiency-critical foreign interface function should be inline +expanded, which can be done by preceding the +define-alien-routine call with: +

    +
    +
    (declaim (inline lisp-name))
+
    + +

    In addition to avoiding the Lisp call overhead, this allows +pointers, word-integers and floats to be passed using non-descriptor +representations, avoiding consing.) +

    + +
    + +
    +
    +

    +Previous: , Up: Foreign Function Calls   [Contents][Index]

    +
    +

    9.7.3 define-alien-routine Example

    + +

    Consider the C function cfoo with the following calling +convention: +

    +
    +
    void
+cfoo (str, a, i)
+    char *str;
+    char *a; /* update */
+    int *i; /* out */
+{
+  /* body of cfoo(...) */
+}
+
    + +

    This can be described by the following call to +define-alien-routine: +

    +
    +
    (define-alien-routine "cfoo" void
+  (str c-string)
+  (a char :in-out)
+  (i int :out))
+
    + +

    The Lisp function cfoo will have two arguments (str and +a) and two return values (a and i). +

    + + + + +
    +
    +

    +Next: , Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.8 Calling Lisp From C

    + +

    SBCL supports the calling of Lisp functions using the C calling +convention. This is useful for both defining callbacks and for creating +an interface for calling into Lisp as a shared library directly from C. +

    +

    The define-alien-callable macro wraps Lisp code and creates a C +foreign function which can be called with the C calling convention. +

    +
    +
    Macro: define-alien-callable [sb-alien] name result-type typed-lambda-list &body body
    +

    Define an alien callable function in the alien callable namespace with result +type result-type and with lambda list specifying the alien types of the +arguments. +

    + +

    The alien-callable-function function returns the foreign callable +value associated with any name defined by define-alien-callable, +so that we can, for example, pass the callable value to C as a callback. +

    +
    +
    Function: alien-callable-function [sb-alien] name
    +

    Return the alien callable function associated with name. +

    + +

    Note that the garbage collector moves objects, and won’t be able to fix +up any references in C variables. There are three mechanisms for coping +with this: +

    +
      +
    1. The sb-ext:purify moves all live Lisp data into static or +read-only areas such that it will never be moved (or freed) again in the +life of the Lisp session + +
    2. sb-sys:with-pinned-objects is a macro which arranges for some set +of objects to be pinned in memory for the dynamic extent of its body +forms. On ports which use the generational garbage collector (most, as +of this writing) this affects exactly the specified objects. On other +ports it is implemented by turning off GC for the duration (so could be +said to have a whole-world granularity). + +
    3. Disable GC, using the without-gcing macro. +
    + + + +
    • Lisp as a Shared Library   +
    + +
    +
    +

    +Up: Calling Lisp From C   [Contents][Index]

    +
    +

    9.8.1 Lisp as a Shared Library

    +

    SBCL supports the use of Lisp as a shared library that can be used by C +programs using the define-alien-callable interface. See the +:callable-exports keyword to save-lisp-and-die for how to +save the Lisp image in a way that allows a C program to initialize the +Lisp runtime and the exported symbols. When SBCL is built as a library, +it exposes the symbol initialize_lisp which can be used in +conjunction with a core initializing global symbols to foreign callables +as function pointers and with object code allocating those symbols to +initialize the runtime properly. The arguments to initialize_lisp +are the same as the arguments to the main sbcl +program. +

    +

    Note: There is currently no way to run exit hooks or otherwise undo +Lisp initialization gracefully from C. +

    +
    +
    +

    +Previous: , Up: Foreign Function Interface   [Contents][Index]

    +
    +

    9.9 Step-By-Step Example of the Foreign Function Interface

    + +

    This section presents a complete example of an interface to a somewhat +complicated C function. +

    +

    Suppose you have the following C function which you want to be able to +call from Lisp in the file test.c +

    +
    +
    struct c_struct
+{
+  int x;
+  char *s;
+};
+
+struct c_struct *c_function (i, s, r, a)
+    int i;
+    char *s;
+    struct c_struct *r;
+    int a[10];
+{
+  int j;
+  struct c_struct *r2;
+
+  printf("i = %d\n", i);
+  printf("s = %s\n", s);
+  printf("r->x = %d\n", r->x);
+  printf("r->s = %s\n", r->s);
+  for (j = 0; j < 10; j++) printf("a[%d] = %d.\n", j, a[j]);
+  r2 = (struct c_struct *) malloc (sizeof(struct c_struct));
+  r2->x = i + 5;
+  r2->s = "a C string";
+  return(r2);
+};
+
    + +

    It is possible to call this C function from Lisp using the file +test.lisp containing +

    +
    +
    (cl:defpackage "TEST-C-CALL" (:use "CL" "SB-ALIEN" "SB-C-CALL"))
+(cl:in-package "TEST-C-CALL")
+
+;;; Define the record C-STRUCT in Lisp.
+(define-alien-type nil
+    (struct c-struct
+            (x int)
+            (s c-string)))
+
+;;; Define the Lisp function interface to the C routine.  It returns a
+;;; pointer to a record of type C-STRUCT.  It accepts four parameters:
+;;; I, an int; S, a pointer to a string; R, a pointer to a C-STRUCT
+;;; record; and A, a pointer to the array of 10 ints.
+;;;
+;;; The INLINE declaration eliminates some efficiency notes about heap
+;;; allocation of alien values.
+(declaim (inline c-function))
+(define-alien-routine c-function
+    (* (struct c-struct))
+  (i int)
+  (s c-string)
+  (r (* (struct c-struct)))
+  (a (array int 10)))
+
+;;; a function which sets up the parameters to the C function and
+;;; actually calls it
+(defun call-cfun ()
+  (with-alien ((ar (array int 10))
+               (c-struct (struct c-struct)))
+    (dotimes (i 10)                     ; Fill array.
+      (setf (deref ar i) i))
+    (setf (slot c-struct 'x) 20)
+    (setf (slot c-struct 's) "a Lisp string")
+
+    (with-alien ((res (* (struct c-struct))
+                      (c-function 5 "another Lisp string" (addr c-struct) ar)))
+      (format t "~&amp;back from C function~%")
+      (multiple-value-prog1
+          (values (slot res 'x)
+                  (slot res 's))
+
+        ;; Deallocate result. (after we are done referring to it:
+        ;; "Pillage, *then* burn.")
+        (free-alien res)))))
+
    + +

    To execute the above example, it is necessary to compile the C +routine, e.g.: ‘cc -c test.c && ld -shared -o test.so test.o’ (In +order to enable incremental loading with some linkers, you may need to +say ‘cc -G 0 -c test.c’) +

    +

    Once the C code has been compiled, you can start up Lisp and load it in: +‘sbcl’. Lisp should start up with its normal prompt. +

    +

    Within Lisp, compile the Lisp file. (This step can be done +separately. You don’t have to recompile every time.) +‘(compile-file "test.lisp")’ +

    +

    Within Lisp, load the foreign object file to define the necessary +symbols: ‘(load-shared-object "test.so")’. +

    +

    Now you can load the compiled Lisp (“fasl”) file into Lisp: +‘(load "test.fasl")’ +And once the Lisp file is loaded, you can call the +Lisp routine that sets up the parameters and calls the C +function: +‘(test-c-call::call-cfun)’ +

    +

    The C routine should print the following information to standard output: +

    +
    +
    i = 5
+s = another Lisp string
+r->x = 20
+r->s = a Lisp string
+a[0] = 0.
+a[1] = 1.
+a[2] = 2.
+a[3] = 3.
+a[4] = 4.
+a[5] = 5.
+a[6] = 6.
+a[7] = 7.
+a[8] = 8.
+a[9] = 9.
+
    + +

    After return from the C function, +the Lisp wrapper function should print the following output: +

    +
    +
    back from C function
+
    + +

    And upon return from the Lisp wrapper function, +before the next prompt is printed, the +Lisp read-eval-print loop should print the following return values: +

    +
    +
    10
+"a C string"
+
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    10 Pathnames

    + + + + + + +
    • Lisp Pathnames   +
    • Native Filenames   +
    + +
    +
    +

    +Next: , Up: Pathnames   [Contents][Index]

    +
    +

    10.1 Lisp Pathnames

    + +

    There are many aspects of ANSI Common Lisp’s pathname support which are +implementation-defined and so need documentation. +

    + +

    10.1.1 Home Directory Specifiers

    + +

    SBCL accepts the keyword :home and a list of the form +(:home "username") as a directory component immediately +following :absolute. +

    +

    :home is represented in namestrings by ~/ and +(:home "username" by ~username/ at the start of the +namestring. Tilde-characters elsewhere in namestrings represent +themselves. +

    +

    Home directory specifiers are resolved to home directory of the +current or specified user by native-namestring, which is used +by the implementation to translate pathnames before passing them on to +operating system specific routines. +

    +

    Using (:home "user") form on Windows signals an error. +

    +

    10.1.2 The SYS Logical Pathname Host

    + + + + + + + +

    The logical pathname host named by "SYS" exists in SBCL. Its +logical-pathname-translations may be set by the site or the user +applicable to point to the locations of the system’s sources; in +particular, the core system’s source files match the logical pathname +"SYS:SRC;**;*.*.*", and the contributed modules’ source files +match "SYS:CONTRIB;**;*.*.*". +

    +
    +
    Function: set-sbcl-source-location [sb-ext] pathname
    +

    Initialize the sys logical host based on pathname, which should be +the top-level directory of the sbcl sources. This will replace any +existing translations for "SYS:SRC;", "SYS:CONTRIB;", and +"SYS:OUTPUT;". Other "SYS:" translations are preserved. +

    + +
    +
    +

    +Previous: , Up: Pathnames   [Contents][Index]

    +
    +

    10.2 Native Filenames

    + +

    In some circumstances, what is wanted is a Lisp pathname object which +corresponds to a string produced by the Operating System. In this case, +some of the default parsing rules are inappropriate: most filesystems do +not have a native understanding of wild pathnames; such functionality is +often provided by shells above the OS, often in mutually-incompatible +ways. +

    +

    To allow the user to deal with this, the following functions are +provided: parse-native-namestring and native-pathname +return the closest equivalent Lisp pathname to a given string +(appropriate for the Operating System), while native-namestring +converts a non-wild pathname designator to the equivalent native +namestring, if possible. Some Lisp pathname concepts (such as the +:back directory component) have no direct equivalents in most +Operating Systems; the behaviour of native-namestring is +unspecified if an inappropriate pathname designator is passed to it. +Additionally, note that conversion from pathname to native filename +and back to pathname should not be expected to preserve equivalence +under equal. +

    +
    +
    Function: parse-native-namestring [sb-ext] thing &optional host defaults &key start end junk-allowed as-directory
    +

    Convert thing into a pathname, using the native conventions +appropriate for the pathname host host, or if not specified the +host of defaults. If thing is a string, the parse is bounded by +start and end, and error behaviour is controlled by junk-allowed, +as with parse-namestring. For file systems whose native +conventions allow directories to be indicated as files, if +as-directory is true, return a pathname denoting thing as a +directory. +

    +
    +
    Function: native-pathname [sb-ext] pathspec
    +

    Convert pathspec (a pathname designator) into a pathname, assuming +the operating system native pathname conventions. +

    +
    +
    Function: native-namestring [sb-ext] pathname &key as-file
    +

    Construct the full native (name)string form of pathname. For +file systems whose native conventions allow directories to be +indicated as files, if as-file is true and the name, type, and +version components of pathname are all nil or :unspecific, +construct a string that names the directory according to the file +system’s syntax for files. +

    + +

    Because some file systems permit the names of directories to be +expressed in multiple ways, it is occasionally necessary to parse a +native file name “as a directory name” or to produce a native file +name that names a directory “as a file”. For these cases, +parse-native-namestring accepts the keyword argument +as-directory to force a filename to parse as a directory, and +native-namestring accepts the keyword argument as-file +to force a pathname to unparse as a file. For example, +

    +
    +
    ; On Unix, the directory "/tmp/" can be denoted by "/tmp/" or "/tmp".
+; Under the default rules for native filenames, these parse and
+; unparse differently.
+(defvar *p*)
+(setf *p* (parse-native-namestring "/tmp/")) ⇒ #P"/tmp/"
+(pathname-name *p*) ⇒ NIL
+(pathname-directory *p*) ⇒ (:ABSOLUTE "tmp")
+(native-namestring *p*) ⇒ "/tmp/"
+
+(setf *p* (parse-native-namestring "/tmp")) ⇒ #P"/tmp"
+(pathname-name *p*) ⇒ "tmp"
+(pathname-directory *p*) ⇒ (:ABSOLUTE)
+(native-namestring *p*) ⇒ "/tmp"
+
+; A non-NIL AS-DIRECTORY argument to PARSE-NATIVE-NAMESTRING forces
+; both the second string to parse the way the first does.
+(setf *p* (parse-native-namestring "/tmp"
+                                   nil *default-pathname-defaults*
+                                   :as-directory t)) ⇒ #P"/tmp/"
+(pathname-name *p*) ⇒ NIL
+(pathname-directory *p*) ⇒ (:ABSOLUTE "tmp")
+
+; A non-NIL AS-FILE argument to NATIVE-NAMESTRING forces the pathname
+; parsed from the first string to unparse as the second string.
+(setf *p* (parse-native-namestring "/tmp/")) ⇒ #P"/tmp/"
+(native-namestring *p* :as-file t) ⇒ "/tmp"
+
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    11 Streams

    + +

    Streams which read or write Lisp character data from or to the outside +world – files, sockets or other external entities – require the +specification of a conversion between the external, binary data and the +Lisp characters. In ANSI Common Lisp, this is done by specifying the +:external-format argument when the stream is created. The major +information required is an encoding, specified by a keyword +naming that encoding; however, it is also possible to specify +refinements to that encoding as additional options to the external +format designator. +

    +

    In addition, SBCL supports various extensions of ANSI Common Lisp +streams: +

    +
    +
    Bivalent Streams
    +

    A type of stream that can read and write both character and +(unsigned-byte 8) values. +

    +
    +
    Gray Streams
    +

    User-overloadable CLOS classes whose instances can be used as Lisp +streams (e.g. passed as the first argument to format). +

    +
    +
    Simple Streams
    +

    The bundled contrib module sb-simple-streams implements a subset +of the Franz Allegro simple-streams proposal. +

    +
    +
    + + + + + + +
    • Stream External Formats   +
    • Bivalent Streams   +
    • Gray Streams   +
    • Simple Streams   +
    + +
    +
    +

    +Next: , Up: Streams   [Contents][Index]

    +
    +

    11.1 Stream External Formats

    + + + +

    The function stream-external-format returns the canonical name of +the external format (See External Formats) used by the stream for +character-based input and/or output. +

    + + +

    When constructing file streams, for example using open or +with-open-file, the external format to use is specified via the +:external-format argument which accepts an external format +designator (See External Format Designators). +

    +
    +
    +

    +Next: , Previous: , Up: Streams   [Contents][Index]

    +
    +

    11.2 Bivalent Streams

    + +

    A bivalent stream can be used to read and write both +character and (unsigned-byte 8) values. A bivalent +stream is created by calling open with the argument :element-type +:default. On such a stream, both binary and character data can be +read and written with the usual input and output functions. +

    +
    +

    Streams are not created bivalent by default for performance +reasons. Bivalent streams are incompatible with +fast-read-char, an internal optimization in SBCL’s stream +machinery that bulk-converts octets to characters and implements a +fast path through read-char. +

    + +
    +
    +

    +Next: , Previous: , Up: Streams   [Contents][Index]

    +
    +

    11.3 Gray Streams

    + + +

    The Gray Streams interface is a widely supported extension that +provides for definition of CLOS-extensible stream classes. Gray +stream classes are implemented by adding methods to generic functions +analogous to Common Lisp’s standard I/O functions. Instances of Gray +stream classes may be used with any I/O operation where a non-Gray +stream can, provided that all required methods have been implemented +suitably. +

    + + + + + + + + + +
    • Gray Streams classes   +
    • Methods common to all streams   +
    • Input stream methods   +
    • Character input stream methods   +
    • Output stream methods   +
    • Character output stream methods   +
    • Binary stream methods   +
    • Gray Streams examples   +
    + +
    +
    +

    +Next: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.1 Gray Streams classes

    + +

    The defined Gray Stream classes are these: +

    +
    +
    Class: fundamental-stream [sb-gray]
    +

    Class precedence list: fundamental-stream, standard-object, stream, t +

    +

    Base class for all Gray streams. +

    +
    +
    Class: fundamental-input-stream [sb-gray]
    +

    Class precedence list: fundamental-input-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray input streams. +

    + +

    The function input-stream-p will return true of any generalized +instance of fundamental-input-stream. +

    +
    +
    Class: fundamental-output-stream [sb-gray]
    +

    Class precedence list: fundamental-output-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray output streams. +

    + +

    The function output-stream-p will return true of any generalized +instance of fundamental-output-stream. +

    +
    +
    Class: fundamental-binary-stream [sb-gray]
    +

    Class precedence list: fundamental-binary-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray streams whose element-type +is a subtype of unsigned-byte or signed-byte. +

    + +

    Note that instantiable subclasses of fundamental-binary-stream should +provide (or inherit) an applicable method for the generic function +stream-element-type. +

    +
    +
    Class: fundamental-character-stream [sb-gray]
    +

    Class precedence list: fundamental-character-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray streams whose element-type is a subtype of character. +

    +
    +
    Class: fundamental-binary-input-stream [sb-gray]
    +

    Class precedence list: fundamental-binary-input-stream, fundamental-input-stream, fundamental-binary-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray input streams whose element-type +is a subtype of unsigned-byte or signed-byte. +

    +
    +
    Class: fundamental-binary-output-stream [sb-gray]
    +

    Class precedence list: fundamental-binary-output-stream, fundamental-output-stream, fundamental-binary-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray output streams whose element-type +is a subtype of unsigned-byte or signed-byte. +

    +
    +
    Class: fundamental-character-input-stream [sb-gray]
    +

    Class precedence list: fundamental-character-input-stream, fundamental-input-stream, fundamental-character-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray input streams whose element-type +is a subtype of character. +

    +
    +
    Class: fundamental-character-output-stream [sb-gray]
    +

    Class precedence list: fundamental-character-output-stream, fundamental-output-stream, fundamental-character-stream, fundamental-stream, standard-object, stream, t +

    +

    Superclass of all Gray output streams whose element-type +is a subtype of character. +

    + +
    +
    +

    +Next: , Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.2 Methods common to all streams

    + +

    These generic functions can be specialized on any generalized instance +of fundamental-stream. +

    +
    +
    Generic Function: stream-element-type [cl] stream
    +

    Return a type specifier for the kind of object returned by the + stream. The class fundamental-character-stream provides a default method + which returns character. +

    +
    +
    Generic Function: close [cl] stream &key abort
    +

    Close the given stream. No more I/O may be performed, but + inquiries may still be made. If :abort is true, an attempt is made + to clean up the side effects of having created the stream. +

    +
    +
    Generic Function: stream-file-position [sb-gray] stream &optional position-spec
    +

    Used by file-position. Returns or changes the current position within stream. +

    + + + +
    +
    +

    +Next: , Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.3 Input stream methods

    + +

    These generic functions may be specialized on any generalized instance +of fundamental-input-stream. +

    +
    +
    Generic Function: stream-clear-input [sb-gray] stream
    +

    This is like cl:clear-input, but for Gray streams, returning nil. + The default method does nothing. +

    +
    +
    Generic Function: stream-read-sequence [sb-gray] stream seq &optional start end
    +

    This is like cl:read-sequence, but for Gray streams. +

    + +
    +
    +

    +Next: , Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.4 Character input stream methods

    + +

    These generic functions are used to implement subclasses of +fundamental-input-stream: +

    +
    +
    Generic Function: stream-peek-char [sb-gray] stream
    +

    This is used to implement peek-char; this corresponds to peek-type of nil. + It returns either a character or :eof. The default method calls + stream-read-char and stream-unread-char. +

    +
    +
    Generic Function: stream-read-char-no-hang [sb-gray] stream
    +

    This is used to implement read-char-no-hang. It returns either a + character, or nil if no input is currently available, or :eof if + end-of-file is reached. The default method provided by + fundamental-character-input-stream simply calls stream-read-char; this + is sufficient for file streams, but interactive streams should define + their own method. +

    +
    +
    Generic Function: stream-read-char [sb-gray] stream
    +

    Read one character from the stream. Return either a + character object, or the symbol :eof if the stream is at end-of-file. + Every subclass of fundamental-character-input-stream must define a + method for this function. +

    +
    +
    Generic Function: stream-read-line [sb-gray] stream
    +

    This is used by read-line. A string is returned as the first value. The + second value is true if the string was terminated by end-of-file + instead of the end of a line. The default method uses repeated + calls to stream-read-char. +

    +
    +
    Generic Function: stream-listen [sb-gray] stream
    +

    This is used by listen. It returns true or false. The default method uses + stream-read-char-no-hang and stream-unread-char. Most streams should + define their own method since it will usually be trivial and will + always be more efficient than the default method. +

    +
    +
    Generic Function: stream-unread-char [sb-gray] stream character
    +

    Undo the last call to stream-read-char, as in unread-char. + Return nil. Every subclass of fundamental-character-input-stream + must define a method for this function. +

    + +
    +
    +

    +Next: , Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.5 Output stream methods

    + +

    These generic functions are used to implement subclasses of +fundamental-output-stream: +

    +
    +
    Generic Function: stream-clear-output [sb-gray] stream
    +

    This is like cl:clear-output, but for Gray streams: clear the given + output stream. The default method does nothing. +

    +
    +
    Generic Function: stream-finish-output [sb-gray] stream
    +

    Attempts to ensure that all output sent to the Stream has reached + its destination, and only then returns false. Implements + finish-output. The default method does nothing. +

    +
    +
    Generic Function: stream-force-output [sb-gray] stream
    +

    Attempts to force any buffered output to be sent. Implements + force-output. The default method does nothing. +

    +
    +
    Generic Function: stream-write-sequence [sb-gray] stream seq &optional start end
    +

    This is like cl:write-sequence, but for Gray streams. +

    + +
    +
    +

    +Next: , Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.6 Character output stream methods

    + +

    These generic functions are used to implement subclasses of +fundamental-character-output-stream: +

    +
    +
    Generic Function: stream-advance-to-column [sb-gray] stream column
    +

    Write enough blank space so that the next character will be + written at the specified column. Returns true if the operation is + successful, or nil if it is not supported for this stream. This is + intended for use by by pprint and format ~T. The default method uses + stream-line-column and repeated calls to stream-write-char with a + #space character; it returns nil if stream-line-column returns nil. +

    +
    +
    Generic Function: stream-fresh-line [sb-gray] stream
    +

    Outputs a new line to the Stream if it is not positioned at the + beginning of a line. Returns t if it output a new line, nil + otherwise. Used by fresh-line. The default method uses + stream-start-line-p and stream-terpri. +

    +
    +
    Generic Function: stream-line-column [sb-gray] stream
    +

    Return the column number where the next character + will be written, or nil if that is not meaningful for this stream. + The first column on a line is numbered 0. This function is used in + the implementation of pprint and the format ~T directive. For every + character output stream class that is defined, a method must be + defined for this function, although it is permissible for it to + always return nil. +

    +
    +
    Generic Function: stream-line-length [sb-gray] stream
    +

    Return the stream line length or nil. +

    +
    +
    Generic Function: stream-start-line-p [sb-gray] stream
    +

    Is stream known to be positioned at the beginning of a line? + It is permissible for an implementation to always return + nil. This is used in the implementation of fresh-line. Note that + while a value of 0 from stream-line-column also indicates the + beginning of a line, there are cases where stream-start-line-p can be + meaningfully implemented although stream-line-column can’t be. For + example, for a window using variable-width characters, the column + number isn’t very meaningful, but the beginning of the line does have + a clear meaning. The default method for stream-start-line-p on class + fundamental-character-output-stream uses stream-line-column, so if + that is defined to return nil, then a method should be provided for + either stream-start-line-p or stream-fresh-line. +

    +
    +
    Generic Function: stream-terpri [sb-gray] stream
    +

    Writes an end of line, as for terpri. Returns nil. The default + method does (stream-write-char stream #newline). +

    +
    +
    Generic Function: stream-write-char [sb-gray] stream character
    +

    Write character to stream and return character. Every + subclass of fundamental-character-output-stream must have a method + defined for this function. +

    +
    +
    Generic Function: stream-write-string [sb-gray] stream string &optional start end
    +

    This is used by write-string. It writes the string to the stream, + optionally delimited by start and end, which default to 0 and nil. + The string argument is returned. The default method provided by + fundamental-character-output-stream uses repeated calls to + stream-write-char. +

    + +
    +
    +

    +Next: , Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.7 Binary stream methods

    + +

    The following generic functions are available for subclasses of +fundamental-binary-stream: +

    +
    +
    Generic Function: stream-read-byte [sb-gray] stream
    +

    Used by read-byte; returns either an integer, or the symbol :eof + if the stream is at end-of-file. +

    +
    +
    Generic Function: stream-write-byte [sb-gray] stream integer
    +

    Implements write-byte; writes the integer to the stream and + returns the integer as the result. +

    + +
    +
    +

    +Previous: , Up: Gray Streams   [Contents][Index]

    +
    +

    11.3.8 Gray Streams examples

    + + +

    Below are two classes of stream that can be conveniently defined as +wrappers for Common Lisp streams. These are meant to serve as +examples of minimal implementations of the protocols that must be +followed when defining Gray streams. Realistic uses of the Gray +Streams API would implement the various methods that can do I/O in +batches, such as stream-read-line, stream-write-string, +stream-read-sequence, and stream-write-sequence. +

    + + + + +
    • Character counting input stream   +
    • Output prefixing character stream   +
    + +
    +
    +

    +Next: , Up: Gray Streams examples   [Contents][Index]

    +
    +

    11.3.8.1 Character counting input stream

    + +

    It is occasionally handy for programs that process input files to +count the number of characters and lines seen so far, and the number +of characters seen on the current line, so that useful messages may be +reported in case of parsing errors, etc. Here is a character input +stream class that keeps track of these counts. Note that all +character input streams must implement stream-read-char and +stream-unread-char. +

    +
    +
    (defclass wrapped-stream (fundamental-stream)
+  ((stream :initarg :stream :reader stream-of)))
+
    (defmethod stream-element-type ((stream wrapped-stream))
+  (stream-element-type (stream-of stream)))
+
    (defmethod close ((stream wrapped-stream) &key abort)
+  (close (stream-of stream) :abort abort))
+
    (defclass wrapped-character-input-stream
+    (wrapped-stream fundamental-character-input-stream)
+  ())
+
    (defmethod stream-read-char ((stream wrapped-character-input-stream))
+  (read-char (stream-of stream) nil :eof))
+
    (defmethod stream-unread-char ((stream wrapped-character-input-stream)
+                               char)
+  (unread-char char (stream-of stream)))
+
    (defclass counting-character-input-stream
+    (wrapped-character-input-stream)
+  ((char-count :initform 1 :accessor char-count-of)
+   (line-count :initform 1 :accessor line-count-of)
+   (col-count :initform 1 :accessor col-count-of)
+   (prev-col-count :initform 1 :accessor prev-col-count-of)))
+
    (defmethod stream-read-char ((stream counting-character-input-stream))
+  (with-accessors ((inner-stream stream-of) (chars char-count-of)
+                   (lines line-count-of) (cols col-count-of)
+                   (prev prev-col-count-of)) stream
+      (let ((char (call-next-method)))
+        (cond ((eql char :eof)
+               :eof)
+              ((char= char #\Newline)
+               (incf lines)
+               (incf chars)
+               (setf prev cols)
+               (setf cols 1)
+               char)
+              (t
+               (incf chars)
+               (incf cols)
+               char)))))
+
    (defmethod stream-unread-char ((stream counting-character-input-stream)
+                               char)
+  (with-accessors ((inner-stream stream-of) (chars char-count-of)
+                   (lines line-count-of) (cols col-count-of)
+                   (prev prev-col-count-of)) stream
+      (cond ((char= char #\Newline)
+             (decf lines)
+             (decf chars)
+             (setf cols prev))
+            (t
+             (decf chars)
+             (decf cols)
+             char))
+      (call-next-method)))
+
    + +

    The default methods for stream-read-char-no-hang, +stream-peek-char, stream-listen, +stream-clear-input, stream-read-line, and +stream-read-sequence should be sufficient (though the last two +will probably be slower than methods that forwarded directly). +

    +

    Here’s a sample use of this class: +

    +
    +
    (with-input-from-string (input "1 2
+ 3 :foo  ")
+  (let ((counted-stream (make-instance 'counting-character-input-stream
+                         :stream input)))
+    (loop for thing = (read counted-stream) while thing
+       unless (numberp thing) do
+         (error "Non-number ~S (line ~D, column ~D)" thing
+                (line-count-of counted-stream)
+                (- (col-count-of counted-stream)
+                   (length (format nil "~S" thing))))
+       end
+       do (print thing))))
+
    1
+2
+3
+Non-number :FOO (line 2, column 5)
+  [Condition of type SIMPLE-ERROR]
+
    + +
    +
    +

    +Previous: , Up: Gray Streams examples   [Contents][Index]

    +
    +

    11.3.8.2 Output prefixing character stream

    + +

    One use for a wrapped output stream might be to prefix each line of +text with a timestamp, e.g., for a logging stream. Here’s a simple +stream that does this, though without any fancy line-wrapping. Note +that all character output stream classes must implement +stream-write-char and stream-line-column. +

    +
    +
    (defclass wrapped-stream (fundamental-stream)
+  ((stream :initarg :stream :reader stream-of)))
+
    (defmethod stream-element-type ((stream wrapped-stream))
+  (stream-element-type (stream-of stream)))
+
    (defmethod close ((stream wrapped-stream) &key abort)
+  (close (stream-of stream) :abort abort))
+
    (defclass wrapped-character-output-stream
+    (wrapped-stream fundamental-character-output-stream)
+  ((col-index :initform 0 :accessor col-index-of)))
+
    (defmethod stream-line-column ((stream wrapped-character-output-stream))
+  (col-index-of stream))
+
    (defmethod stream-write-char ((stream wrapped-character-output-stream)
+                              char)
+  (with-accessors ((inner-stream stream-of) (cols col-index-of)) stream
+    (write-char char inner-stream)
+    (if (char= char #\Newline)
+        (setf cols 0)
+        (incf cols))))
+
    (defclass prefixed-character-output-stream
+    (wrapped-character-output-stream)
+  ((prefix :initarg :prefix :reader prefix-of)))
+
    (defgeneric write-prefix (prefix stream)
+  (:method ((prefix string) stream) (write-string prefix stream))
+  (:method ((prefix function) stream) (funcall prefix stream)))
+
    (defmethod stream-write-char ((stream prefixed-character-output-stream)
+                              char)
+  (with-accessors ((inner-stream stream-of) (cols col-index-of)
+                   (prefix prefix-of)) stream
+    (when (zerop cols)
+      (write-prefix prefix inner-stream))
+    (call-next-method)))
+
    + +

    As with the example input stream, this implements only the minimal +protocol. A production implementation should also provide methods for +at least stream-write-line, stream-write-sequence. +

    +

    And here’s a sample use of this class: +

    +
    +
    (flet ((format-timestamp (stream)
+         (apply #'format stream "[~2@*~2,' D:~1@*~2,'0D:~0@*~2,'0D] "
+                (multiple-value-list (get-decoded-time)))))
+  (let ((output (make-instance 'prefixed-character-output-stream
+                               :stream *standard-output*
+                               :prefix #'format-timestamp)))
+    (loop for string in '("abc" "def" "ghi") do
+         (write-line string output)
+         (sleep 1))))
+
    [ 0:30:05] abc
+[ 0:30:06] def
+[ 0:30:07] ghi
+NIL
+
    + +
    +
    +

    +Previous: , Up: Streams   [Contents][Index]

    +
    +

    11.4 Simple Streams

    +

    Simple streams are an extensible streams protocol that avoids some +problems with Gray streams. +

    +

    Documentation about simple streams is available at: +

    +

    http://www.franz.com/support/documentation/6.2/doc/streams.htm +

    +

    The implementation should be considered Alpha-quality; the basic +framework is there, but many classes are just stubs at the moment. +

    +

    See SYS:CONTRIB;SB-SIMPLE-STREAMS;SIMPLE-STREAM-TEST.LISP for +things that should work. +

    +

    Known differences to the ACL behaviour: +

    +
      +
    • open not return a simple-stream by default. This can be +adjusted; see default-open-class in the file cl.lisp + +
    • write-vector is unimplemented. + +
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    12 Package Locks

    + + +

    None of the following sections apply to SBCL built without package +locking support. +

    +
    +

    warning: The interface described here is experimental: incompatible changes in +future SBCL releases are possible, even expected: the concept of +“implementation packages” and the associated operators may be renamed; +more operations (such as naming restarts or catch tags) may be added to +the list of operations violating package locks. +

    + + + + +
    • Package Lock Concepts   +
    • Package Lock Dictionary   +
    + +
    +
    +

    +Next: , Up: Package Locks   [Contents][Index]

    +
    +

    12.1 Package Lock Concepts

    + + + + + + + +
    • Package Lock Overview   +
    • Implementation Packages   +
    • Package Lock Violations   +
    • Package Locks in Compiled Code   +
    • Operations Violating Package Locks   +
    + +
    +
    +

    +Next: , Up: Package Lock Concepts   [Contents][Index]

    +
    +

    12.1.1 Package Locking Overview

    + +

    Package locks protect against unintentional modifications of a package: +they provide similar protection to user packages as is mandated to +common-lisp package by the ANSI specification. They are not, and +should not be used as, a security measure. +

    +

    Newly created packages are by default unlocked (see the :lock +option to defpackage). +

    +

    The package common-lisp and SBCL internal implementation +packages are locked by default, including sb-ext. +

    +

    It may be beneficial to lock common-lisp-user as well, to +ensure that various libraries don’t pollute it without asking, +but this is not currently done by default. +

    +
    +
    +

    +Next: , Previous: , Up: Package Lock Concepts   [Contents][Index]

    +
    +

    12.1.2 Implementation Packages

    + + + +

    Each package has a list of associated implementation packages. A +locked package, and the symbols whose home package it is, can be +modified without violating package locks only when *package* is +bound to one of the implementation packages of the locked package. +

    +

    Unless explicitly altered by defpackage, +sb-ext:add-implementation-package, or +sb-ext:remove-implementation-package each package is its own +(only) implementation package. +

    +
    +
    +

    +Next: , Previous: , Up: Package Lock Concepts   [Contents][Index]

    +
    +

    12.1.3 Package Lock Violations

    + + + + + +

    12.1.3.1 Lexical Bindings and Declarations

    + + + + + + + + + + + +

    Lexical bindings or declarations that violate package locks cause a +compile-time warning, and a runtime program-error when the form +that violates package locks would be executed. +

    +

    A complete listing of operators affect by this is: let, +let*, flet, labels, macrolet, and +symbol-macrolet, declare. +

    +

    Package locks affecting both lexical bindings and declarations can be +disabled locally with sb-ext:disable-package-locks declaration, +and re-enabled with sb-ext:enable-package-locks declaration. +

    +

    Example: +

    +
    +
    (in-package :locked)
+
+(defun foo () ...)
+
+(defmacro with-foo (&body body)
+  `(locally (declare (disable-package-locks locked:foo))
+     (flet ((foo () ...))
+       (declare (enable-package-locks locked:foo)) ; re-enable for body
+       ,@body)))
+
    + +

    12.1.3.2 Other Operations

    + +

    If an non-lexical operation violates a package lock, a continuable +error that is of a subtype of sb-ext:package-lock-violation +(subtype of package-error) is signalled when the operation is +attempted. +

    +

    Additional restarts may be established for continuable package lock +violations for interactive use. +

    +

    The actual type of the error depends on circumstances that caused the +violation: operations on packages signal errors of type +sb-ext:package-locked-error, and operations on symbols signal +errors of type sb-ext:symbol-package-locked-error. +

    + +
    +
    +

    +Next: , Previous: , Up: Package Lock Concepts   [Contents][Index]

    +
    +

    12.1.4 Package Locks in Compiled Code

    + +

    12.1.4.1 Interned Symbols

    + +

    If file-compiled code contains interned symbols, then loading that code +into an image without the said symbols will not cause a package lock +violation, even if the packages in question are locked. +

    +

    12.1.4.2 Other Limitations on Compiled Code

    + +

    With the exception of interned symbols, behaviour is unspecified if +package locks affecting compiled code are not the same during loading +of the code or execution. +

    +

    Specifically, code compiled with packages unlocked may or may not fail +to signal package-lock-violations even if the packages are locked at +runtime, and code compiled with packages locked may or may not signal +spurious package-lock-violations at runtime even if the packages are +unlocked. +

    +

    In practice all this means that package-locks have a negligible +performance penalty in compiled code as long as they are not violated. +

    +
    +
    +

    +Previous: , Up: Package Lock Concepts   [Contents][Index]

    +
    +

    12.1.5 Operations Violating Package Locks

    + +

    12.1.5.1 Operations on Packages

    + +

    The following actions cause a package lock violation if the package +operated on is locked, and *package* is not an implementation +package of that package, and the action would cause a change in the +state of the package (so e.g. exporting already external symbols is +never a violation). Package lock violations caused by these operations +signal errors of type sb-ext:package-locked-error. +

    +
      +
    1. Shadowing a symbol in a package. + +
    2. Importing a symbol to a package. + +
    3. Uninterning a symbol from a package. + +
    4. Exporting a symbol from a package. + +
    5. Unexporting a symbol from a package. + +
    6. Changing the packages used by a package. + +
    7. Renaming a package. + +
    8. Deleting a package. + +
    9. Adding a new package local nickname to a package. + +
    10. Removing an existing package local nickname to a package. + +
    + +

    12.1.5.2 Operations on Symbols

    + +

    Following actions cause a package lock violation if the home package +of the symbol operated on is locked, and *package* is not an +implementation package of that package. Package lock violations caused +by these action signal errors of type +sb-ext:symbol-package-locked-error. +

    +

    These actions cause only one package lock violation per lexically +apparent violated package. +

    +

    Example: +

    +
    +
    ;;; Packages FOO and BAR are locked.
+;;;
+;;; Two lexically apparent violated packages: exactly two
+;;; package-locked-errors will be signalled.
+
+(defclass foo:point ()
+  ((x :accessor bar:x)
+   (y :accessor bar:y)))
+
    + +
      +
    1. Binding or altering its value lexically or dynamically, or +establishing it as a symbol-macro. + +

      Exceptions: +

      +
        +
      • - If the symbol is not defined as a constant, global symbol-macro or a +global dynamic variable, it may be lexically bound or established as a +local symbol macro. + +
      • - If the symbol is defined as a global dynamic variable, it may be +assigned or bound. + +
      + +
    2. Defining, undefining, or binding it, or its setf name as a function. + +

      Exceptions: +

      +
        +
      • - If the symbol is not defined as a function, macro, or special operator +it and its setf name may be lexically bound as a function. + +
      + +
    3. Defining, undefining, or binding it as a macro or compiler macro. + +

      Exceptions: +

      +
        +
      • - If the symbol is not defined as a function, macro, or special operator +it may be lexically bound as a macro. + +
      + +
    4. Defining it as a type specifier or structure. + +
    5. Defining it as a declaration with a declaration proclamation. + +
    6. Declaring or proclaiming it special. + +
    7. Declaring or proclaiming its type or ftype. + +

      Exceptions: +

      +
        +
      • - If the symbol may be lexically bound, the type of that binding may be +declared. + +
      • - If the symbol may be lexically bound as a function, the ftype of that +binding may be declared. + +
      + +
    8. Defining a setf expander for it. + +
    9. Defining it as a method combination type. + +
    10. Using it as the class-name argument to setf of find-class. + +
    11. Defining it as a hash table test using sb-ext:define-hash-table-test. + +
    + +
    +
    +

    +Previous: , Up: Package Locks   [Contents][Index]

    +
    +

    12.2 Package Lock Dictionary

    + +
    +
    Declaration: disable-package-locks [sb-ext]
    +
    +

    Syntax: (sb-ext:disable-package-locks symbol*) +

    +

    Disables package locks affecting the named symbols during compilation +in the lexical scope of the declaration. Disabling locks on symbols +whose home package is unlocked, or disabling an already disabled lock, +has no effect. +

    + +
    +
    Declaration: enable-package-locks [sb-ext]
    +
    +

    Syntax: (sb-ext:enable-package-locks symbol*) +

    +

    Re-enables package locks affecting the named symbols during compilation +in the lexical scope of the declaration. Enabling locks that were not +first disabled with sb-ext:disable-package-locks declaration, or +enabling locks that are already enabled has no effect. +

    + +
    +
    Condition: package-lock-violation [sb-ext]
    +

    Class precedence list: package-lock-violation, package-error, error, serious-condition, condition, t +

    +

    Subtype of cl:package-error. A subtype of this error is signalled +when a package-lock is violated. +

    +
    +
    Condition: package-locked-error [sb-ext]
    +

    Class precedence list: package-locked-error, package-lock-violation, package-error, error, serious-condition, condition, t +

    +

    Subtype of sb-ext:package-lock-violation. An error of this type is +signalled when an operation on a package violates a package lock. +

    +
    +
    Condition: symbol-package-locked-error [sb-ext]
    +

    Class precedence list: symbol-package-locked-error, package-lock-violation, package-error, error, serious-condition, condition, t +

    +

    Subtype of sb-ext:package-lock-violation. An error of this type is +signalled when an operation on a symbol violates a package lock. The +symbol that caused the violation is accessed by the function +sb-ext:package-locked-error-symbol. +

    + +
    +
    Function: package-locked-error-symbol [sb-ext] symbol-package-locked-error
    +
    +

    Returns the symbol that caused the symbol-package-locked-error +condition. +

    + +
    +
    Function: package-locked-p [sb-ext] package
    +

    Returns t when package is locked, nil otherwise. Signals an error +if package doesn’t designate a valid package. +

    +
    +
    Function: lock-package [sb-ext] package
    +

    Locks package and returns t. Has no effect if package was already +locked. Signals an error if package is not a valid package designator +

    +
    +
    Function: unlock-package [sb-ext] package
    +

    Unlocks package and returns t. Has no effect if package was already +unlocked. Signals an error if package is not a valid package designator. +

    +
    +
    Function: package-implemented-by-list [sb-ext] package
    +

    Returns a list containing the implementation packages of +package. Signals an error if package is not a valid package designator. +

    +
    +
    Function: package-implements-list [sb-ext] package
    +

    Returns the packages that package is an implementation package +of. Signals an error if package is not a valid package designator. +

    +
    +
    Function: add-implementation-package [sb-ext] packages-to-add &optional package
    +

    Adds packages-to-add as implementation packages of package. Signals +an error if package or any of the packages-to-add is not a valid +package designator. +

    +
    +
    Function: remove-implementation-package [sb-ext] packages-to-remove &optional package
    +

    Removes packages-to-remove from the implementation packages of +package. Signals an error if package or any of the packages-to-remove +is not a valid package designator. +

    +
    +
    Macro: without-package-locks [sb-ext] &body body
    +

    Ignores all runtime package lock violations during the execution of +body. Body can begin with declarations. +

    +
    +
    Macro: with-unlocked-packages [sb-ext] (&rest packages) &body forms
    +

    Unlocks packages for the dynamic scope of the body. Signals an +error if any of packages is not a valid package designator. +

    + +
    +
    Macro: defpackage [cl] name [[option]]* ⇒ package
    +
    +

    Options are extended to include the following: +

    +
      +
    • :lock boolean + +

      If the argument to :lock is t, the package is initially +locked. If :lock is not provided it defaults to nil. +

      +
    • :implement package-designator* + +

      The package is added as an implementation package to the packages +named. If :implement is not provided, it defaults to the +package itself. +

    + +

    Example: +

    +
    +
    (defpackage "FOO" (:export "BAR") (:lock t) (:implement))
+(defpackage "FOO-INT" (:use "FOO") (:implement "FOO" "FOO-INT"))
+
+;;; is equivalent to
+
+(defpackage "FOO") (:export "BAR"))
+(lock-package "FOO")
+(remove-implementation-package "FOO" "FOO")
+(defpackage "FOO-INT" (:use "BAR"))
+(add-implementation-package "FOO-INT" "FOO")
+
    +
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    13 Threading

    + +

    SBCL supports a fairly low-level threading interface that maps onto +the host operating system’s concept of threads or lightweight +processes. This means that threads may take advantage of hardware +multiprocessing on machines that have more than one CPU, but it does +not allow Lisp control of the scheduler. This is found in the +SB-THREAD package. +

    +

    Threads are part of the default build on x86[-64]/ARM64 Linux and Windows. +

    +

    They are also supported on: x86[-64] Darwin (Mac OS X), x86[-64] +FreeBSD, x86 SunOS (Solaris), PPC Linux, ARM64 Linux, RISC-V Linux. On +these platforms threads must be explicitly enabled at build-time, see +INSTALL for directions. +

    + + + + + + + + + + + +
    • Threading basics   +
    • Special Variables   +
    • Atomic Operations   +
    • Mutex Support   +
    • Semaphores   +
    • Waitqueue/condition variables   +
    • Barriers   +
    • Sessions/Debugging   +
    • Foreign threads   +
    • Implementation (Linux x86/x86-64)   +
    + +
    +
    +

    +Next: , Up: Threading   [Contents][Index]

    +
    +

    13.1 Threading basics

    + +
    +
    (make-thread (lambda () (write-line "Hello, world")))
+
    + +

    13.1.1 Thread Objects

    + +
    +
    Structure: thread [sb-thread]
    +

    Class precedence list: thread, structure-object, t +

    +

    Thread type. Do not rely on threads being structs as it may change +in future versions. +

    +
    +
    Variable: *current-thread* [sb-thread]
    +

    Bound in each thread to the thread itself. +

    +
    +
    Function: list-all-threads [sb-thread]
    +

    Return a list of the live threads. Note that the return value is +potentially stale even before the function returns, as new threads may be +created and old ones may exit at any time. +

    +
    +
    Function: thread-alive-p [sb-thread] thread
    +

    Return t if thread is still alive. Note that the return value is +potentially stale even before the function returns, as the thread may exit at +any time. +

    +
    +
    Function: thread-name [sb-thread] instance
    +

    Name of the thread. Can be assigned to using setf. A thread name must be +a simple-string (not necessarily unique) or nil. +

    +
    +
    Function: main-thread-p [sb-thread] &optional thread
    +

    True if thread, defaulting to current thread, is the main thread of the process. +

    +
    +
    Function: main-thread [sb-thread]
    +

    Returns the main thread of the process. +

    + +

    13.1.2 Making, Returning From, Joining, and Yielding Threads

    + +
    +
    Function: make-thread [sb-thread] function &key name arguments
    +

    Create a new thread of name that runs function with the argument +list designator provided (defaults to no argument). Thread exits when +the function returns. The return values of function are kept around +and can be retrieved by join-thread. +

    +

    Invoking the initial abort restart established by make-thread +terminates the thread. +

    +

    See also: return-from-thread, abort-thread. +

    +
    +
    Macro: return-from-thread [sb-thread] values-form &key allow-exit
    +

    Unwinds from and terminates the current thread, with values from +values-form as the results visible to join-thread. +

    +

    If current thread is the main thread of the process (see +main-thread-p), signals an error unless allow-exit is true, as +terminating the main thread would terminate the entire process. If +allow-exit is true, returning from the main thread is equivalent to +calling sb-ext:exit with :code 0 and :abort nil. +

    +

    See also: abort-thread and sb-ext:exit. +

    +
    +
    Function: abort-thread [sb-thread] &key allow-exit
    +

    Unwinds from and terminates the current thread abnormally, causing +join-thread on current thread to signal an error unless a +default-value is provided. +

    +

    If current thread is the main thread of the process (see +main-thread-p), signals an error unless allow-exit is true, as +terminating the main thread would terminate the entire process. If +allow-exit is true, aborting the main thread is equivalent to calling +sb-ext:exit code 1 and :abort nil. +

    +

    Invoking the initial abort restart established by make-thread is +equivalent to calling abort-thread in other than main threads. +However, whereas abort restart may be rebound, abort-thread always +unwinds the entire thread. (Behaviour of the initial abort restart for +main thread depends on the :toplevel argument to +sb-ext:save-lisp-and-die.) +

    +

    See also: return-from-thread and sb-ext:exit. +

    +
    +
    Function: join-thread [sb-thread] thread &key default timeout
    +

    Suspend current thread until thread exits. Return the result values +of the thread function. +

    +

    If thread does not exit within timeout seconds and default is +supplied, return two values: 1) default 2) :timeout. If default is not +supplied, signal a join-thread-error with join-thread-problem equal +to :timeout. +

    +

    If thread does not exit normally (i.e. aborted) and default is +supplied, return two values: 1) default 2) :abort. If default is not +supplied, signal a join-thread-error with join-thread-problem equal +to :abort. +

    +

    If thread is the current thread, signal a join-thread-error with +join-thread-problem equal to :self-join. +

    +

    Trying to join the main thread causes join-thread to block until +timeout occurs or the process exits: when the main thread exits, the +entire process exits. +

    +

    Users should not rely on the ability to join a chosen thread from more +than one other thread simultaneously. Future changes to join-thread may +directly call the underlying thread library, and not all threading +implementations consider such usage to be well-defined. +

    +

    note: Return convention in case of a timeout is experimental and +subject to change. +

    +
    +
    Function: thread-yield [sb-thread]
    +

    Yield the processor to other threads. +

    + +

    13.1.3 Asynchronous Operations

    + +
    +
    Function: interrupt-thread [sb-thread] thread function
    +

    Interrupt thread and make it run function. +

    +

    The interrupt is asynchronous, and can occur anywhere with the exception of +sections protected using sb-sys:without-interrupts. +

    +

    function is called with interrupts disabled, under +sb-sys:allow-with-interrupts. Since functions such as grab-mutex may try to +enable interrupts internally, in most cases function should either enter +sb-sys:with-interrupts to allow nested interrupts, or +sb-sys:without-interrupts to prevent them completely. +

    +

    When a thread receives multiple interrupts, they are executed in the order +they were sent -- first in, first out. +

    +

    This means that a great degree of care is required to use interrupt-thread +safely and sanely in a production environment. The general recommendation is +to limit uses of interrupt-thread for interactive debugging, banning it +entirely from production environments -- it is simply exceedingly hard to use +correctly. +

    +

    With those caveats in mind, what you need to know when using it: +

    +
      +
    • If calling function causes a non-local transfer of control (ie. an + unwind), all normal cleanup forms will be executed. + +

      However, if the interrupt occurs during cleanup forms of an unwind-protect, + it is just as if that had happened due to a regular go, throw, or + return-from: the interrupted cleanup form and those following it in the + same unwind-protect do not get executed. +

      +

      sbcl tries to keep its own internals asynch-unwind-safe, but this is + frankly an unreasonable expectation for third party libraries, especially + given that asynch-unwind-safety does not compose: a function calling + only asynch-unwind-safe function isn’t automatically asynch-unwind-safe. +

      +

      This means that in order for an asynch unwind to be safe, the entire + callstack at the point of interruption needs to be asynch-unwind-safe. +

      +
    • In addition to asynch-unwind-safety you must consider the issue of + reentrancy. interrupt-thread can cause function that are never normally + called recursively to be re-entered during their dynamic contour, + which may cause them to misbehave. (Consider binding of special variables, + values of global variables, etc.) + +
    +

    Taken together, these two restrict the "safe" things to do using +interrupt-thread to a fairly minimal set. One useful one -- exclusively for +interactive development use is using it to force entry to debugger to inspect +the state of a thread: +

    +
    +
      (interrupt-thread thread #'break)
+
    + +

    Short version: be careful out there. +

    +
    +
    Function: terminate-thread [sb-thread] thread
    +

    Terminate the thread identified by thread, by interrupting it and +causing it to call sb-ext:abort-thread with :allow-exit t. +

    +

    The unwind caused by terminate-thread is asynchronous, meaning that +eg. thread executing +

    +
    +
      (let (foo)
+     (unwind-protect
+         (progn
+            (setf foo (get-foo))
+            (work-on-foo foo))
+       (when foo
+         ;; An interrupt occurring inside the cleanup clause
+         ;; will cause cleanups from the current UNWIND-PROTECT
+         ;; to be dropped.
+         (release-foo foo))))
+
    + +

    might miss calling release-foo despite get-foo having returned true if +the interrupt occurs inside the cleanup clause, eg. during execution +of release-foo. +

    +

    Thus, in order to write an asynch unwind safe unwind-protect you need +to use without-interrupts: +

    +
    +
      (let (foo)
+    (sb-sys:without-interrupts
+      (unwind-protect
+          (progn
+            (setf foo (sb-sys:allow-with-interrupts
+                        (get-foo)))
+            (sb-sys:with-local-interrupts
+              (work-on-foo foo)))
+       (when foo
+         (release-foo foo)))))
+
    + +

    Since most libraries using unwind-protect do not do this, you should never +assume that unknown code can safely be terminated using terminate-thread. +

    + +

    13.1.4 Miscellaneous Operations

    + +
    +
    Function: symbol-value-in-thread [sb-thread] symbol thread &optional errorp
    +

    Return the local value of symbol in thread, and a secondary value of t +on success. +

    +

    If the value cannot be retrieved (because the thread has exited or because it +has no local binding for name) and errorp is true signals an error of type +symbol-value-in-thread-error; if errorp is false returns a primary value of +nil, and a secondary value of nil. +

    +

    Can also be used with setf to change the thread-local value of symbol. +

    +

    symbol-value-in-thread is primarily intended as a debugging tool, and not as a +mechanism for inter-thread communication. +

    + +

    13.1.5 Error Conditions

    + +
    +
    Condition: thread-error [sb-thread]
    +

    Class precedence list: thread-error, error, serious-condition, condition, t +

    +

    Conditions of type thread-error are signalled when thread operations fail. +The offending thread is initialized by the :thread initialization argument and +read by the function thread-error-thread. +

    +
    +
    Function: thread-error-thread [sb-thread] condition
    +

    Return the offending thread that the thread-error pertains to. +

    + +
    +
    Condition: interrupt-thread-error [sb-thread]
    +

    Class precedence list: interrupt-thread-error, thread-error, error, serious-condition, condition, t +

    +

    Signalled when interrupting a thread fails because the thread has already +exited. The offending thread can be accessed using thread-error-thread. +

    +
    +
    Condition: join-thread-error [sb-thread]
    +

    Class precedence list: join-thread-error, thread-error, error, serious-condition, condition, t +

    +

    Signalled when joining a thread fails due to abnormal exit of the thread +to be joined. The offending thread can be accessed using +thread-error-thread. +

    + +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.2 Special Variables

    + +

    The interaction of special variables with multiple threads is mostly +as one would expect, with behaviour very similar to other +implementations. +

    +
      +
    • global special values are visible across all threads; +
    • bindings (e.g. using LET) are local to the thread; +
    • threads do not inherit dynamic bindings from the parent thread +
    + +

    The last point means that +

    +
    +
    (defparameter *x* 0)
+(let ((*x* 1))
+  (sb-thread:make-thread (lambda () (print *x*))))
+
    + +

    prints 0 and not 1 as of 0.9.6. +

    +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.3 Atomic Operations

    + +

    Following atomic operations are particularly useful for implementing +lockless algorithms. +

    +
    +
    Macro: atomic-decf [sb-ext] place &optional diff
    +

    Atomically decrements place by diff, and returns the value of place before +the decrement. +

    +

    place must access one of the following: +

      +
    • a defstruct slot with declared type (unsigned-byte 64) + or aref of a (simple-array (unsigned-byte 64) (*)) + The type sb-ext:word can be used for these purposes. +
    • car or cdr (respectively first or rest) of a cons. +
    • a variable defined using defglobal with a proclaimed type of fixnum. +
    +

    Macroexpansion is performed on place before expanding atomic-decf. +

    +

    Decrementing is done using modular arithmetic, +which is well-defined over two different domains: +

      +
    • For structures and arrays, the operation accepts and produces + an (unsigned-byte 64), and diff must be of type (signed-byte 64). + atomic-decf of #x0 by one results in #xFFFFFFFFFFFFFFFF being stored in place. +
    • For other places, the domain is fixnum, and diff must be a fixnum. + atomic-decf of #x-4000000000000000 by one results in #x3FFFFFFFFFFFFFFF + being stored in place. + +
    +

    diff defaults to 1. +

    +

    experimental: Interface subject to change. +

    +
    +
    Macro: atomic-incf [sb-ext] place &optional diff
    +

    Atomically increments place by diff, and returns the value of place before +the increment. +

    +

    place must access one of the following: +

      +
    • a defstruct slot with declared type (unsigned-byte 64) + or aref of a (simple-array (unsigned-byte 64) (*)) + The type sb-ext:word can be used for these purposes. +
    • car or cdr (respectively first or rest) of a cons. +
    • a variable defined using defglobal with a proclaimed type of fixnum. +
    +

    Macroexpansion is performed on place before expanding atomic-incf. +

    +

    Incrementing is done using modular arithmetic, +which is well-defined over two different domains: +

      +
    • For structures and arrays, the operation accepts and produces + an (unsigned-byte 64), and diff must be of type (signed-byte 64). + atomic-incf of #xFFFFFFFFFFFFFFFF by one results in #x0 being stored in place. +
    • For other places, the domain is fixnum, and diff must be a fixnum. + atomic-incf of #x3FFFFFFFFFFFFFFF by one results in #x-4000000000000000 + being stored in place. + +
    +

    diff defaults to 1. +

    +

    experimental: Interface subject to change. +

    +
    +
    Macro: atomic-pop [sb-ext] place
    +

    Like pop, but atomic. place may be read multiple times before +the operation completes -- the write does not occur until such time +that no other thread modified place between the read and the write. +

    +

    Works on all CASable places. +

    +
    +
    Macro: atomic-push [sb-ext] obj place
    +

    Like push, but atomic. place may be read multiple times before +the operation completes -- the write does not occur until such time +that no other thread modified place between the read and the write. +

    +

    Works on all CASable places. +

    +
    +
    Macro: atomic-update [sb-ext] place update-fn &rest arguments
    +

    Updates place atomically to the value returned by calling function +designated by update-fn with arguments and the previous value of place. +

    +

    place may be read and update-fn evaluated and called multiple times before the +update succeeds: atomicity in this context means that the value of place did +not change between the time it was read, and the time it was replaced with the +computed value. +

    +

    place can be any place supported by sb-ext:compare-and-swap. +

    +

    Examples: +

    +
    +
      ;;; Conses T to the head of FOO-LIST.
+  (defstruct foo list)
+  (defvar *foo* (make-foo))
+  (atomic-update (foo-list *foo*) #'cons t)
+
+  (let ((x (cons :count 0)))
+     (mapc #'sb-thread:join-thread
+           (loop repeat 1000
+                 collect (sb-thread:make-thread
+                          (lambda ()
+                            (loop repeat 1000
+                                  do (atomic-update (cdr x) #'1+)
+                                     (sleep 0.00001))))))
+     ;; Guaranteed to be (:COUNT . 1000000) -- if you replace
+     ;; atomic update with (INCF (CDR X)) above, the result becomes
+     ;; unpredictable.
+     x)
+
    +
    +
    +
    Macro: compare-and-swap [sb-ext] place old new
    +

    Atomically stores new in place if old matches the current value of place. +Two values are considered to match if they are eq. Returns the previous value +of place: if the returned value is eq to old, the swap was carried out. +

    +

    place must be an CAS-able place. Built-in CAS-able places are accessor forms +whose car is one of the following: +

    +

    car, cdr, first, rest, svref, symbol-plist, symbol-value, svref, slot-value + sb-mop:standard-instance-access, sb-mop:funcallable-standard-instance-access, +

    +

    or the name of a defstruct created accessor for a slot whose storage type +is not raw. (Refer to the the "Efficiency" chapter of the manual +for the list of raw slot types. Future extensions to this macro may allow +it to work on some raw slot types.) +

    +

    In case of slot-value, if the slot is unbound, slot-unbound is called unless +old is eq to sb-pcl:+slot-unbound+ in which case sb-pcl:+slot-unbound+ is +returned and new is assigned to the slot. Additionally, the results are +unspecified if there is an applicable method on either +sb-mop:slot-value-using-class, (setf sb-mop:slot-value-using-class), or +sb-mop:slot-boundp-using-class. +

    +

    Additionally, the place can be a anything for which a CAS-function has +been defined. (See sb-ext:cas for more information.) +

    + +

    CAS Protocol

    + +

    Our compare-and-swap is user-extensible by defining functions +named (CAS place), allowing users to add CAS support to new +places. +

    +
    +
    Macro: cas [sb-ext] place old new
    +

    Synonym for compare-and-swap. +

    +

    Additionally defun, defgeneric, defmethod, flet, and labels can be also used to +define CAS-functions analogously to SETF-functions: +

    +
    +
      (defvar *foo* nil)
+
+  (defun (cas foo) (old new)
+    (cas (symbol-value '*foo*) old new))
+
    + +

    First argument of a cas function is the expected old value, and the second +argument of is the new value. Note that the system provides no automatic +atomicity for cas functions, nor can it verify that they are atomic: it is up +to the implementor of a cas function to ensure its atomicity. +

    +

    experimental: Interface subject to change. +

    + +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.4 Mutex Support

    + +

    Mutexes are used for controlling access to a shared resource. One +thread is allowed to hold the mutex, others which attempt to take it +will be made to wait until it’s free. Threads are woken in the order +that they go to sleep. +

    +
    +
    (defpackage :demo (:use "CL" "SB-THREAD" "SB-EXT"))
+
+(in-package :demo)
+
+(defvar *a-mutex* (make-mutex :name "my lock"))
+
+(defun thread-fn ()
+  (format t "Thread ~A running ~%" *current-thread*)
+  (with-mutex (*a-mutex*)
+    (format t "Thread ~A got the lock~%" *current-thread*)
+    (sleep (random 5)))
+  (format t "Thread ~A dropped lock, dying now~%" *current-thread*))
+
+(make-thread #'thread-fn)
+(make-thread #'thread-fn)
+
    + +
    +
    Structure: mutex [sb-thread]
    +

    Class precedence list: mutex, structure-object, t +

    +

    Mutex type. +

    + +
    +
    Macro: with-mutex [sb-thread] (mutex &key wait-p timeout value) &body body
    +

    Acquire mutex for the dynamic scope of body. If wait-p is true (the default), +and the mutex is not immediately available, sleep until it is available. +

    +

    If timeout is given, it specifies a relative timeout, in seconds, on how long +the system should try to acquire the lock in the contested case. +

    +

    If the mutex isn’t acquired successfully due to either wait-p or timeout, the +body is not executed, and with-mutex returns nil. +

    +

    Otherwise body is executed with the mutex held by current thread, and +with-mutex returns the values of body. +

    +

    Historically with-mutex also accepted a value argument, which when provided +was used as the new owner of the mutex instead of the current thread. This is +no longer supported: if value is provided, it must be either nil or the +current thread. +

    +
    +
    Macro: with-recursive-lock [sb-thread] (mutex &key wait-p timeout) &body body
    +

    Acquire mutex for the dynamic scope of body. +

    +

    If wait-p is true (the default), and the mutex is not immediately available or +held by the current thread, sleep until it is available. +

    +

    If timeout is given, it specifies a relative timeout, in seconds, on how long +the system should try to acquire the lock in the contested case. +

    +

    If the mutex isn’t acquired successfully due to either wait-p or timeout, the +body is not executed, and with-recursive-lock returns nil. +

    +

    Otherwise body is executed with the mutex held by current thread, and +with-recursive-lock returns the values of body. +

    +

    Unlike with-mutex, which signals an error on attempt to re-acquire an already +held mutex, with-recursive-lock allows recursive lock attempts to succeed. +

    + +
    +
    Function: make-mutex [sb-thread] &key name
    +

    Create a mutex. +

    +
    +
    Function: mutex-name [sb-thread] instance
    +

    The name of the mutex. Setfable. +

    +
    +
    Function: mutex-owner [sb-thread] mutex
    +

    Current owner of the mutex, nil if the mutex is free. Naturally, +this is racy by design (another thread may acquire the mutex after +this function returns), it is intended for informative purposes. For +testing whether the current thread is holding a mutex see +holding-mutex-p. +

    +
    +
    Function: mutex-value [sb-thread] mutex
    +

    Current owner of the mutex, nil if the mutex is free. May return a +stale value, use mutex-owner instead. +

    +
    +
    Function: grab-mutex [sb-thread] mutex &key waitp timeout
    +

    Acquire mutex for the current thread. If waitp is true (the default) and +the mutex is not immediately available, sleep until it is available. +

    +

    If timeout is given, it specifies a relative timeout, in seconds, on how long +grab-mutex should try to acquire the lock in the contested case. +

    +

    If grab-mutex returns t, the lock acquisition was successful. In case of waitp +being nil, or an expired timeout, grab-mutex may also return nil which denotes +that grab-mutex did -not- acquire the lock. +

    +

    Notes: +

    +
      +
    • grab-mutex is not interrupt safe. The correct way to call it is: + +

      (without-interrupts + ... + (allow-with-interrupts (grab-mutex ...)) + ...) +

      +

      without-interrupts is necessary to avoid an interrupt unwinding the call + while the mutex is in an inconsistent state while allow-with-interrupts + allows the call to be interrupted from sleep. +

      +
    • (grab-mutex <mutex> :timeout 0.0) differs from + (grab-mutex <mutex> :waitp nil) in that the former may signal a + deadline-timeout if the global deadline was due already on entering + grab-mutex. + +

      The exact interplay of grab-mutex and deadlines are reserved to change in + future versions. +

      +
    • It is recommended that you use with-mutex instead of calling grab-mutex + directly. +
    +
    +
    +
    Function: release-mutex [sb-thread] mutex &key if-not-owner
    +

    Release mutex by setting it to nil. Wake up threads waiting for +this mutex. +

    +

    release-mutex is not interrupt safe: interrupts should be disabled +around calls to it. +

    +

    If the current thread is not the owner of the mutex then it silently +returns without doing anything (if if-not-owner is :punt), signals a +warning (if if-not-owner is :warn), or releases the mutex anyway (if +if-not-owner is :force). +

    + +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.5 Semaphores

    + +

    Semaphores are among other things useful for keeping track of a +countable resource, e.g. messages in a queue, and sleep when the +resource is exhausted. +

    +
    +
    Structure: semaphore [sb-thread]
    +

    Class precedence list: semaphore, structure-object, t +

    +

    Semaphore type. The fact that a semaphore is a structure-object +should be considered an implementation detail, and may change in the +future. +

    +
    +
    Function: make-semaphore [sb-thread] &key name count
    +

    Create a semaphore with the supplied count and name. +

    +
    +
    Function: signal-semaphore [sb-thread] semaphore &optional n
    +

    Increment the count of semaphore by n. If there are threads waiting +on this semaphore, then n of them is woken up. +

    +
    +
    Function: wait-on-semaphore [sb-thread] semaphore &key n timeout notification
    +

    Decrement the count of semaphore by n if the count would not be negative. +

    +

    Else blocks until the semaphore can be decremented. Returns the new count of +semaphore on success. +

    +

    If timeout is given, it is the maximum number of seconds to wait. If the count +cannot be decremented in that time, returns nil without decrementing the +count. +

    +

    If notification is given, it must be a semaphore-notification object whose +semaphore-notification-status is nil. If wait-on-semaphore succeeds and +decrements the count, the status is set to t. +

    +
    +
    Function: try-semaphore [sb-thread] semaphore &optional n notification
    +

    Try to decrement the count of semaphore by n. If the count were to +become negative, punt and return nil, otherwise return the new count of +semaphore. +

    +

    If notification is given it must be a semaphore notification object +with semaphore-notification-status of nil. If the count is decremented, +the status is set to t. +

    +
    +
    Function: semaphore-count [sb-thread] instance
    +

    Returns the current count of the semaphore instance. +

    +
    +
    Function: semaphore-name [sb-thread] semaphore
    +

    The name of the semaphore instance. Setfable. +

    + +
    +
    Structure: semaphore-notification [sb-thread]
    +

    Class precedence list: semaphore-notification, structure-object, t +

    +

    Semaphore notification object. Can be passed to wait-on-semaphore and +try-semaphore as the :notification argument. Consequences are undefined if +multiple threads are using the same notification object in parallel. +

    +
    +
    Function: make-semaphore-notification [sb-thread]
    +

    Constructor for semaphore-notification objects. semaphore-notification-status +is initially nil. +

    +
    +
    Function: semaphore-notification-status [sb-thread] semaphore-notification
    +

    Returns t if a wait-on-semaphore or try-semaphore using +semaphore-notification has succeeded since the notification object was created +or cleared. +

    +
    +
    Function: clear-semaphore-notification [sb-thread] semaphore-notification
    +

    Resets the semaphore-notification object for use with another call to +wait-on-semaphore or try-semaphore. +

    + +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.6 Waitqueue/condition variables

    + +

    These are based on the POSIX condition variable design, hence the +annoyingly CL-conflicting name. For use when you want to check a +condition and sleep until it’s true. For example: you have a shared +queue, a writer process checking “queue is empty” and one or more +readers that need to know when “queue is not empty”. It sounds +simple, but is astonishingly easy to deadlock if another process runs +when you weren’t expecting it to. +

    +

    There are three components: +

    +
      +
    • the condition itself (not represented in code) + +
    • the condition variable (a.k.a. waitqueue) which proxies for it + +
    • a lock to hold while testing the condition +
    + +

    Important stuff to be aware of: +

    +
      +
    • when calling condition-wait, you must hold the mutex. condition-wait +will drop the mutex while it waits, and obtain it again before +returning for whatever reason; + +
    • likewise, you must be holding the mutex around calls to +condition-notify; + +
    • a process may return from condition-wait in several circumstances: it +is not guaranteed that the underlying condition has become true. You +must check that the resource is ready for whatever you want to do to +it. + +
    + +
    +
    (defvar *buffer-queue* (make-waitqueue))
+(defvar *buffer-lock* (make-mutex :name "buffer lock"))
+
+(defvar *buffer* (list nil))
+
+(defun reader ()
+  (with-mutex (*buffer-lock*)
+    (loop
+     (condition-wait *buffer-queue* *buffer-lock*)
+     (loop
+      (unless *buffer* (return))
+      (let ((head (car *buffer*)))
+        (setf *buffer* (cdr *buffer*))
+        (format t "reader ~A woke, read ~A~%"
+                *current-thread* head))))))
+
+(defun writer ()
+  (loop
+   (sleep (random 5))
+   (with-mutex (*buffer-lock*)
+     (let ((el (intern
+                (string (code-char
+                         (+ (char-code #\A) (random 26)))))))
+       (setf *buffer* (cons el *buffer*)))
+     (condition-notify *buffer-queue*))))
+
+(make-thread #'writer)
+(make-thread #'reader)
+(make-thread #'reader)
+
    + +
    +
    Structure: waitqueue [sb-thread]
    +

    Class precedence list: waitqueue, structure-object, t +

    +

    Waitqueue type. +

    +
    +
    Function: make-waitqueue [sb-thread] &key name
    +

    Create a waitqueue. +

    +
    +
    Function: waitqueue-name [sb-thread] instance
    +

    The name of the waitqueue. Setfable. +

    +
    +
    Function: condition-wait [sb-thread] queue mutex &key timeout
    +

    Atomically release mutex and start waiting on queue until another thread +wakes us up using either condition-notify or condition-broadcast on +queue, at which point we re-acquire mutex and return t. +

    +

    Spurious wakeups are possible. +

    +

    If timeout is given, it is the maximum number of seconds to wait, +including both waiting for the wakeup and the time to re-acquire +mutex. When neither a wakeup nor a re-acquisition occurs within the +given time, returns nil without re-acquiring mutex. +

    +

    If condition-wait unwinds, it may do so with or without mutex being +held. +

    +

    Important: Since condition-wait may return without condition-notify or +condition-broadcast having occurred, the correct way to write code +that uses condition-wait is to loop around the call, checking the +associated data: +

    +
    +
      (defvar *data* nil)
+  (defvar *queue* (make-waitqueue))
+  (defvar *lock* (make-mutex))
+
+  ;; Consumer
+  (defun pop-data (&optional timeout)
+    (with-mutex (*lock*)
+      (loop until *data*
+            do (or (condition-wait *queue* *lock* :timeout timeout)
+                   ;; Lock not held, must unwind without touching *data*.
+                   (return-from pop-data nil)))
+      (pop *data*)))
+
+  ;; Producer
+  (defun push-data (data)
+    (with-mutex (*lock*)
+      (push data *data*)
+      (condition-notify *queue*)))
+
    +
    +
    +
    Function: condition-notify [sb-thread] queue &optional n
    +

    Notify n threads waiting on queue. +

    +

    important: The same mutex that is used in the corresponding condition-wait +must be held by this thread during this call. +

    +
    +
    Function: condition-broadcast [sb-thread] queue
    +

    Notify all threads waiting on queue. +

    +

    important: The same mutex that is used in the corresponding condition-wait +must be held by this thread during this call. +

    + +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.7 Barriers

    + +

    These are based on the Linux kernel barrier design, which is in turn +based on the Alpha CPU memory model. They are presently implemented for +x86, x86-64, PPC, ARM64, and RISC-V systems, and behave as compiler +barriers on all other CPUs. +

    +

    In addition to explicit use of the sb-thread:barrier macro, the +following functions and macros also serve as :memory barriers: +

    +
      +
    • sb-ext:atomic-decf, sb-ext:atomic-incf, sb-ext:atomic-push, +and sb-ext:atomic-pop. +
    • sb-ext:compare-and-swap. +
    • sb-thread:grab-mutex, sb-thread:release-mutex, +sb-thread:with-mutex and sb-thread:with-recursive-lock. +
    • sb-thread:signal-semaphore, sb-thread:try-semaphore and +sb-thread:wait-on-semaphore. +
    • sb-thread:condition-wait, sb-thread:condition-notify and +sb-thread:condition-broadcast. +
    + +
    +
    Macro: barrier [sb-thread] (kind) &body forms
    +

    Insert a barrier in the code stream, preventing some sort of +reordering. +

    +

    kind should be one of: +

    + +
    +
    :compiler
    +

    Prevent the compiler from reordering memory access across the + barrier. +

    +
    +
    :memory
    +

    Prevent the cpu from reordering any memory access across the + barrier. +

    +
    +
    :read
    +

    Prevent the cpu from reordering any read access across the + barrier. +

    +
    +
    :write
    +

    Prevent the cpu from reordering any write access across the + barrier. +

    +
    +
    :data-dependency
    +

    Prevent the cpu from reordering dependent memory reads across the + barrier (requiring reads before the barrier to complete before any + reads after the barrier that depend on them). This is a weaker + form of the :read barrier. +

    +
    +
    + +

    forms is an implicit progn, evaluated before the barrier. barrier +returns the values of the last form in forms. +

    +

    The file "memory-barriers.txt" in the Linux kernel documentation is +highly recommended reading for anyone programming at this level. +

    + +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.8 Sessions/Debugging

    + +

    If the user has multiple views onto the same Lisp image (for example, +using multiple terminals, or a windowing system, or network access) +they are typically set up as multiple sessions such that each +view has its own collection of foreground/background/stopped threads. +A thread which wishes to create a new session can use +sb-thread:with-new-session to remove itself from the current +session (which it shares with its parent and siblings) and create a +fresh one. +# See also sb-thread:make-listener-thread. +

    +

    Within a single session, threads arbitrate between themselves for the +user’s attention. A thread may be in one of three notional states: +foreground, background, or stopped. When a background process +attempts to print a repl prompt or to enter the debugger, it will stop +and print a message saying that it has stopped. The user at his +leisure may switch to that thread to find out what it needs. If a +background thread enters the debugger, selecting any restart will put +it back into the background before it resumes. Arbitration for the +input stream is managed by calls to sb-thread:get-foreground +(which may block) and sb-thread:release-foreground. +

    +
    +
    +

    +Next: , Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.9 Foreign threads

    + +

    Direct calls to pthread_create (instead of MAKE-THREAD) +create threads that SBCL is not aware of, these are called foreign +threads. Currently, it is not possible to run Lisp code in such +threads. This means that the Lisp side signal handlers cannot work. +The best solution is to start foreign threads with signals blocked, +but since third party libraries may create threads, it is not always +feasible to do so. As a workaround, upon receiving a signal in a +foreign thread, SBCL changes the thread’s sigmask to block all signals +that it wants to handle and resends the signal to the current process +which should land in a thread that does not block it, that is, a Lisp +thread. +

    +

    The resignalling trick cannot work for synchronously triggered signals +(SIGSEGV and co), take care not to trigger any. Resignalling for +synchronously triggered signals in foreign threads is subject to +--lose-on-corruption, see Runtime Options. +

    +
    +
    +

    +Previous: , Up: Threading   [Contents][Index]

    +
    +

    13.10 Implementation (Linux x86/x86-64)

    + +

    Threading is implemented using pthreads and some Linux specific bits +like futexes. +

    +

    On x86 the per-thread local bindings for special variables is achieved +using the %fs segment register to point to a per-thread storage area. +This may cause interesting results if you link to foreign code that +expects threading or creates new threads, and the thread library in +question uses %fs in an incompatible way. On x86-64 the r12 register +has a similar role. +

    +

    Queues require the sys_futex() system call to be available: +this is the reason for the NPTL requirement. We test at runtime that +this system call exists. +

    +

    Garbage collection is done with the existing Conservative Generational +GC. Allocation is done in small (typically 8k) regions: each thread +has its own region so this involves no stopping. However, when a +region fills, a lock must be obtained while another is allocated, and +when a collection is required, all processes are stopped. This is +achieved by sending them signals, which may make for interesting +behaviour if they are interrupted in system calls. The streams +interface is believed to handle the required system call restarting +correctly, but this may be a consideration when making other blocking +calls e.g. from foreign library code. +

    +

    Large amounts of the SBCL library have not been inspected for +thread-safety. Some of the obviously unsafe areas have large locks +around them, so compilation and fasl loading, for example, cannot be +parallelized. Work is ongoing in this area. +

    +

    A new thread by default is created in the same POSIX process group and +session as the thread it was created by. This has an impact on +keyboard interrupt handling: pressing your terminal’s intr key +(typically Control-C) will interrupt all processes in the +foreground process group, including Lisp threads that SBCL considers +to be notionally ‘background’. This is undesirable, so background +threads are set to ignore the SIGINT signal. +

    +

    sb-thread:make-listener-thread in addition to creating a new +Lisp session makes a new POSIX session, so that pressing +Control-C in one window will not interrupt another listener - +this has been found to be embarrassing. +

    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    14 Timers

    + +

    SBCL supports a system-wide event scheduler implemented on top of +setitimer that also works with threads but does not require a +separate scheduler thread. +

    +

    The following example schedules a timer that writes “Hello, world” after +two seconds. +

    +
    +
    (schedule-timer (make-timer (lambda ()
+                              (write-line "Hello, world")
+                              (force-output)))
+                2)
+
    + +

    It should be noted that writing timer functions requires special care, +as the dynamic environment in which they run is unpredictable: dynamic +variable bindings, locks held, etc, all depend on whatever code was +running when the timer fired. The following example should serve as +a cautionary tale: +

    +
    +
    (defvar *foo* nil)
+
+(defun show-foo ()
+  (format t "~&foo=~S~%" *foo*)
+  (force-output t))
+
+(defun demo ()
+  (schedule-timer (make-timer #'show-foo) 0.5)
+  (schedule-timer (make-timer #'show-foo) 1.5)
+  (let ((*foo* t))
+    (sleep 1.0))
+  (let ((*foo* :surprise!))
+    (sleep 2.0)))
+
    + +

    14.1 Timer Dictionary

    + +
    +
    Structure: timer [sb-ext]
    +

    Class precedence list: timer, structure-object, t +

    +

    Timer type. Do not rely on timers being structs as it may change in +future versions. +

    +
    +
    Function: make-timer [sb-ext] function &key name thread
    +

    Create a timer that runs function when triggered. +

    +

    If a thread is supplied, function is run in that thread. If thread is +t, a new thread is created for function each time the timer is +triggered. If thread is nil, function is run in an unspecified thread. +

    +

    When thread is not t, interrupt-thread is used to run function and the +ordering guarantees of interrupt-thread apply. In that case, function +runs with interrupts disabled but with-interrupts is allowed. +

    +
    +
    Function: timer-name [sb-ext] timer
    +

    Return the name of timer. +

    +
    +
    Function: timer-scheduled-p [sb-ext] timer &key delta
    +

    See if timer will still need to be triggered after delta seconds +from now. For timers with a repeat interval it returns true. +

    +
    +
    Function: schedule-timer [sb-ext] timer time &key repeat-interval absolute-p catch-up
    +

    Schedule timer to be triggered at time. If absolute-p then time is +universal time, but non-integral values are also allowed, else time is +measured as the number of seconds from the current time. +

    +

    If repeat-interval is given, timer is automatically rescheduled upon +expiry. +

    +

    If repeat-interval is non-NIL, the Boolean catch-up controls whether +timer will "catch up" by repeatedly calling its function without +delay in case calls are missed because of a clock discontinuity such +as a suspend and resume cycle of the computer. The default is nil, +i.e. do not catch up. +

    +
    +
    Function: unschedule-timer [sb-ext] timer
    +

    Cancel timer. Once this function returns it is guaranteed that +timer shall not be triggered again and there are no unfinished +triggers. +

    +
    +
    Function: list-all-timers [sb-ext]
    +

    Return a list of all timers in the system. +

    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    15 Networking

    + + +

    The sb-bsd-sockets module provides a thinly disguised BSD +socket API for SBCL. Ideas have been stolen from the BSD socket API +for C and Graham Barr’s IO::Socket classes for Perl. +

    +

    Sockets are represented as CLOS objects, and the API naming +conventions attempt to balance between the BSD names and good lisp style. +

    + + + + + + + +
    • Sockets Overview   +
    • General Sockets  Methods applicable to all sockets +
    • Socket Options   +
    • INET Domain Sockets   +
    • Local (Unix) Domain Sockets   +
    • Name Service   +
    + +
    +
    +

    +Next: , Up: Networking   [Contents][Index]

    +
    +

    15.1 Sockets Overview

    + +

    Most of the functions are modelled on the BSD socket API. BSD sockets +are widely supported, portably (“portable” by Unix standards, at least) +available on a variety of systems, and documented. There are some +differences in approach where we have taken advantage of some of the +more useful features of Common Lisp - briefly: +

    +
      +
    • Where the C API would typically return -1 and set errno, +sb-bsd-sockets signals an error. All the errors are subclasses +of sb-bsd-sockets:socket-condition and generally correspond one +for one with possible errno values. + +
    • We use multiple return values in many places where the C API would use +pass-by-reference values. + +
    • We can often avoid supplying an explicit length argument to +functions because we already know how long the argument is. + +
    • IP addresses and ports are represented in slightly friendlier fashion +than "network-endian integers". + +
    + +
    +
    +

    +Next: , Previous: , Up: Networking   [Contents][Index]

    +
    +

    15.2 General Sockets

    + +
    +
    Class: socket [sb-bsd-sockets]
    +

    Class precedence list: socket, standard-object, t +

    +

    Slots: +

      +
    • protocol — initarg: :protocol; reader: sb-bsd-sockets:socket-protocol + +

      Protocol used by the socket. If a +keyword, the symbol-name of the keyword will be passed to +get-protocol-by-name downcased, and the returned value used as +protocol. Other values are used as-is. +

    • type — initarg: :type; reader: sb-bsd-sockets:socket-type + +

      Type of the socket: :stream or :datagram. +

    + +

    Common superclass of all sockets, not meant to be +directly instantiated. +

    + +
    +
    Generic Function: socket-bind [sb-bsd-sockets] socket &rest address
    +

    Bind socket to address, which may vary according to socket family. +For the inet family, pass address and port as two arguments; for file +address family sockets, pass the filename string. See also bind(2) +

    + +
    +
    Generic Function: socket-accept [sb-bsd-sockets] socket
    +

    Perform the accept(2) call, returning a newly-created connected +socket and the peer address as multiple values +

    + +
    +
    Generic Function: socket-connect [sb-bsd-sockets] socket &rest address
    +

    Perform the connect(2) call to connect socket to a remote peer. +No useful return value. +

    + +
    +
    Generic Function: socket-peername [sb-bsd-sockets] socket
    +

    Return SOCKET’s peer; depending on the address family this may +return multiple values +

    + +
    +
    Generic Function: socket-name [sb-bsd-sockets] socket
    +

    Return the address (as vector of bytes) and port that socket is +bound to, as multiple values. +

    + +
    +
    Generic Function: socket-receive [sb-bsd-sockets] socket buffer length &key oob peek waitall dontwait element-type
    +

    Read length octets from socket into buffer (or a freshly-consed +buffer if nil), using recvfrom(2). If length is nil, the length of +buffer is used, so at least one of these two arguments must be +non-NIL. If buffer is supplied, it had better be of an element type +one octet wide. Returns the buffer, its length, and the address of the +peer that sent it, as multiple values. On datagram sockets, sets +MSG_TRUNC so that the actual packet length is returned even if the +buffer was too small. +

    + +
    +
    Generic Function: socket-send [sb-bsd-sockets] socket buffer length &key address external-format oob eor dontroute dontwait nosignal confirm more
    +

    Send length octets from buffer into socket, using sendto(2). If +buffer is a string, it will converted to octets according to +external-format. If length is nil, the length of the octet buffer is +used. The format of address depends on the socket type (for example +for inet domain sockets it would be a list of an ip address and a +port). If no socket address is provided, send(2) will be called +instead. Returns the number of octets written. +

    + +
    +
    Generic Function: socket-listen [sb-bsd-sockets] socket backlog
    +

    Mark socket as willing to accept incoming connections. The +integer backlog defines the maximum length that the queue of pending +connections may grow to before new connection attempts are refused. +See also listen(2) +

    + +
    +
    Generic Function: socket-open-p [sb-bsd-sockets] socket
    +

    Return true if socket is open; otherwise, return false. +

    + +
    +
    Generic Function: socket-close [sb-bsd-sockets] socket &key abort
    +

    Close socket, unless it was already closed. +

    +

    If socket-make-stream has been called, calls close using abort on that +stream. Otherwise closes the socket file descriptor using +close(2). +

    + +
    +
    Generic Function: socket-shutdown [sb-bsd-sockets] socket &key direction
    +

    Indicate that no communication in direction will be performed on +socket. +

    +

    direction has to be one of :input, :output or :io. +

    +

    After a shutdown, no input and/or output of the indicated direction +can be performed on socket. +

    + +
    +
    Generic Function: socket-make-stream [sb-bsd-sockets] socket &key input output element-type external-format buffering timeout auto-close serve-events
    +

    Find or create a stream that can be used for io on socket (which +must be connected). Specify whether the stream is for input, output, +or both (it is an error to specify neither). +

    +

    element-type and external-format are as per open. +

    +

    timeout specifies a read timeout for the stream. +

    +
    +
    Method: socket-make-stream [sb-bsd-sockets] (socket socket) &key input output (element-type (quote character)) (buffering full) (external-format default) timeout auto-close serve-events
    +

    Default method for socket objects. +

    +

    element-type defaults to character, to construct a bivalent stream, +capable of both binary and character io use :default. +

    +

    Acceptable values for buffering are :full, :line and :none, default +is :full, ie. output is buffered till it is explicitly flushed using +close or finish-output. (force-output forces some output to be +flushed: to ensure all buffered output is flused use finish-output.) +

    +

    Streams have no timeout by default. If one is provided, it is the +number of seconds the system will at most wait for input to appear on +the socket stream when trying to read from it. +

    +

    If auto-close is true, the underlying os socket is automatically +closed after the stream and the socket have been garbage collected. +Default is false. +

    +

    If serve-events is true, blocking io on the socket will dispatch to +the recursive event loop. Default is false. +

    +

    The stream for socket will be cached, and a second invocation of this +method will return the same stream. This may lead to oddities if this +function is invoked with inconsistent arguments (e.g., one might +request an input stream and get an output stream in response). +

    + +
    +
    Function: socket-error [sb-bsd-sockets] where &optional errno
    +

    Signal an appropriate error for syscall where and errno. +

    +

    where should be a string naming the failed function. +

    +

    When supplied, errno should be the unix error number associated to the +failed call. The default behavior is to use the current value of the +errno variable. +

    + +
    +
    Generic Function: non-blocking-mode [sb-bsd-sockets] socket
    +

    Is socket in non-blocking mode? +

    + +
    +
    +

    +Next: , Previous: , Up: Networking   [Contents][Index]

    +
    +

    15.3 Socket Options

    + +

    A subset of socket options are supported, using a fairly general +framework which should make it simple to add more as required - see +SYS:CONTRIB;SB-BSD-SOCKETS:SOCKOPT.LISP for details. The name +mapping from C is fairly straightforward: SO_RCVLOWAT becomes +sockopt-receive-low-water and (setf +sockopt-receive-low-water). +

    +
    +
    Function: sockopt-reuse-address [sb-bsd-sockets] socket
    +

    Return the value of the so-reuseaddr socket option for socket. This can also be +updated with setf. +

    + +
    +
    Function: sockopt-keep-alive [sb-bsd-sockets] socket
    +

    Return the value of the so-keepalive socket option for socket. This can also be +updated with setf. +

    + +
    +
    Function: sockopt-oob-inline [sb-bsd-sockets] socket
    +

    Return the value of the so-oobinline socket option for socket. This can also be +updated with setf. +

    + +
    +
    Function: sockopt-bsd-compatible [sb-bsd-sockets] socket
    +

    Return the value of the so-bsdcompat socket option for socket. This can also be +updated with setf. Available only on Linux. +

    + +
    +
    Function: sockopt-pass-credentials [sb-bsd-sockets] socket
    +

    Return the value of the so-passcred socket option for socket. This can also be +updated with setf. Available only on Linux. +

    + +
    +
    Function: sockopt-debug [sb-bsd-sockets] socket
    +

    Return the value of the so-debug socket option for socket. This can also be +updated with setf. +

    + +
    +
    Function: sockopt-dont-route [sb-bsd-sockets] socket
    +

    Return the value of the so-dontroute socket option for socket. This can also be +updated with setf. +

    + +
    +
    Function: sockopt-broadcast [sb-bsd-sockets] socket
    +

    Return the value of the so-broadcast socket option for socket. This can also be +updated with setf. +

    + +
    +
    Function: sockopt-tcp-nodelay [sb-bsd-sockets] socket
    +

    Return the value of the tcp-nodelay socket option for socket. This can also be +updated with setf. +

    + +
    +
    +

    +Next: , Previous: , Up: Networking   [Contents][Index]

    +
    +

    15.4 INET Domain Sockets

    + +

    The TCP and UDP sockets that you know and love. Some representation +issues: +

    +
      +
    • IPv4 Internet addresses are represented by vectors of +(unsigned-byte 8) - viz. #(127 0 0 1). Ports are just +integers: 6010. No conversion between network- and host-order data is +needed from the user of this package. + +
    • IPv6 Internet addresses are represented by vectors of 16 +(unsigned-byte 8) - viz. #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 +1). Ports are just integers. As for IPv4 addresses, no conversion +between network- and host-order data is needed from the user of this +package. + +
    • Socket addresses are represented by the two values for address and port, +so for example, (socket-connect socket #(192 168 1 1) 80) for +IPv4 and (socket-connect socket #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) +80) for IPv6. + +
    + +
    +
    Class: inet-socket [sb-bsd-sockets]
    +

    Class precedence list: inet-socket, socket, standard-object, t +

    +

    Class representing tcp and udp over IPv4 sockets. +

    +

    Examples: +

    +
    +
     (make-instance 'sb-bsd-sockets:inet-socket :type :stream :protocol :tcp)
+
+ (make-instance 'sb-bsd-sockets:inet-socket :type :datagram :protocol :udp)
+
    +
    + +
    +
    Class: inet6-socket [sb-bsd-sockets]
    +

    Class precedence list: inet6-socket, socket, standard-object, t +

    +

    Class representing tcp and udp over IPv6 sockets. +

    +

    Examples: +

    +
    +
     (make-instance 'sb-bsd-sockets:inet6-socket :type :stream :protocol :tcp)
+
+ (make-instance 'sb-bsd-sockets:inet6-socket :type :datagram :protocol :udp)
+
    +
    + +
    +
    Function: make-inet-address [sb-bsd-sockets] dotted-quads
    +

    Return a vector of octets given a string dotted-quads in the format +"127.0.0.1". Signals an error if the string is malformed. +

    + +
    +
    Function: make-inet6-address [sb-bsd-sockets] colon-separated-integers
    +

    Return a vector of octets given a string representation of an IPv6 +address colon-separated-integers. Signal an error if the string is +malformed. +

    + +
    +
    Function: get-protocol-by-name [sb-bsd-sockets] name
    +

    Given a protocol name, return the protocol number, the protocol name, and +a list of protocol aliases +

    + +
    +
    +

    +Next: , Previous: , Up: Networking   [Contents][Index]

    +
    +

    15.5 Local (Unix) Domain Sockets

    + +

    Local domain (AF_LOCAL) sockets are also known as Unix-domain +sockets, but were renamed by POSIX presumably on the basis that they +may be available on other systems too. +

    +

    A local socket address is a string, which is used to create a node in +the local filesystem. This means of course that they cannot be used +across a network. +

    +
    +
    Class: local-socket [sb-bsd-sockets]
    +

    Class precedence list: local-socket, socket, standard-object, t +

    +

    Class representing local domain (AF_LOCAL) sockets, +also known as unix-domain sockets. +

    + +

    A local abstract socket address is also a string the scope of which is +the local machine. However, in contrast to a local socket address, there +is no corresponding filesystem node. +

    +
    +
    Class: local-abstract-socket [sb-bsd-sockets]
    +

    Class precedence list: local-abstract-socket, local-socket, socket, standard-object, t +

    +

    Class representing local domain (AF_LOCAL) sockets with addresses +in the abstract namespace. +

    + +
    +
    +

    +Previous: , Up: Networking   [Contents][Index]

    +
    +

    15.6 Name Service

    + +

    Presently name service is implemented by calling out to the +getaddrinfo(3) and gethostinfo(3), or to +gethostbyname(3) gethostbyaddr(3) on platforms where +the preferred functions are not available. The exact details of +the name resolving process (for example the choice of whether +DNS or a hosts file is used for lookup) are platform dependent. +

    + +
    +
    Class: host-ent [sb-bsd-sockets]
    +

    Class precedence list: host-ent, standard-object, t +

    +

    Slots: +

      +
    • name — initarg: :name; reader: sb-bsd-sockets:host-ent-name + +

      The name of the host +

    • addresses — initarg: :addresses; reader: sb-bsd-sockets:host-ent-addresses + +

      A list of addresses for this host. +

    + +

    This class represents the results of an address lookup. +

    + +
    +
    Function: get-host-by-name [sb-bsd-sockets] node
    +

    Returns a host-ent instance for node or signals a name-service-error. +

    +

    Another host-ent instance containing zero, one or more IPv6 addresses +may be returned as a second return value. +

    +

    node may also be an ip address in dotted quad notation or some other +weird stuff - see getaddrinfo(3) for the details. +

    + +
    +
    Function: get-host-by-address [sb-bsd-sockets] address
    +

    Returns a host-ent instance for address, which should be a vector of +(integer 0 255) with 4 elements in case of an IPv4 address and 16 +elements in case of an IPv6 address, or signals a name-service-error. +See gethostbyaddr(3) for details. +

    + +
    +
    Generic Function: host-ent-address [sb-bsd-sockets] host-ent
    +

    Return some valid address for host-ent. +

    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    16 Profiling

    + + +

    SBCL includes both a deterministic profiler, that can collect statistics +on individual functions, and a more “modern” statistical profiler. +

    +

    Inlined functions do not appear in the results reported by either. +

    + + + +
    • Deterministic Profiler   +
    • Statistical Profiler   +
    + +
    +
    +

    +Next: , Up: Profiling   [Contents][Index]

    +
    +

    16.1 Deterministic Profiler

    + + +

    The package sb-profile provides a classic, per-function-call +profiler. +

    +
    +

    note: When profiling code executed by multiple threads in parallel, the +consing attributed to each function is inaccurate. +

    + +
    +
    Macro: profile [sb-profile] &rest names
    +

    profile Name* +

    +

    If no names are supplied, return the list of profiled functions. +

    +

    If names are supplied, wrap profiling code around the named functions. + As in trace, the names are not evaluated. A symbol names a function. + A string names all the functions named by symbols in the named + package. If a function is already profiled, then unprofile and + reprofile (useful to notice function redefinition.) If a name is + undefined, then we give a warning and ignore it. See also + unprofile, report and reset. +

    +
    +
    Macro: unprofile [sb-profile] &rest names
    +

    Unwrap any profiling code around the named functions, or if no names + are given, unprofile all profiled functions. A symbol names + a function. A string names all the functions named by symbols in the + named package. names defaults to the list of names of all currently + profiled functions. +

    +
    +
    Function: report [sb-profile] &key limit print-no-call-list
    +

    Report results from profiling. The results are approximately +adjusted for profiling overhead. The compensation may be rather +inaccurate when bignums are involved in runtime calculation, as in a +very-long-running Lisp process. +

    +

    If limit is set to an integer, only the top limit results are +reported. If print-no-call-list is t (the default) then a list of +uncalled profiled functions are listed. +

    +
    +
    Function: reset [sb-profile]
    +

    Reset the counters for all profiled functions. +

    + +
    +
    +

    +Previous: , Up: Profiling   [Contents][Index]

    +
    +

    16.2 Statistical Profiler

    + + +

    The sb-sprof module, loadable by +

    +
    (require :sb-sprof)
+
    +

    provides an alternate profiler which works by taking samples of the +program execution at regular intervals, instead of instrumenting +functions like sb-profile:profile does. You might find +sb-sprof more useful than the deterministic profiler when profiling +functions in the common-lisp-package, SBCL internals, or code +where the instrumenting overhead is excessive. +

    +

    Additionally sb-sprof includes a limited deterministic profiler +which can be used for reporting the amounts of calls to some functions +during +

    +

    16.2.1 Example Usage

    + +
    +
    (in-package :cl-user)
+
+(require :sb-sprof)
+
+(declaim (optimize speed))
+
+(defun cpu-test-inner (a i)
+  (logxor a
+          (* i 5)
+          (+ a i)))
+
+(defun cpu-test (n)
+  (let ((a 0))
+    (dotimes (i (expt 2 n) a)
+      (setf a (cpu-test-inner a i)))))
+
+;;;; CPU profiling
+
+;;; Take up to 1000 samples of running (CPU-TEST 26), and give a flat
+;;; table report at the end. Profiling will end one the body has been
+;;; evaluated once, whether or not 1000 samples have been taken.
+(sb-sprof:with-profiling (:max-samples 1000
+                          :report :flat
+                          :loop nil)
+  (cpu-test 26))
+
+;;; Record call counts for functions defined on symbols in the CL-USER
+;;; package.
+(sb-sprof:profile-call-counts "CL-USER")
+
+;;; Take 1000 samples of running (CPU-TEST 24), and give a flat
+;;; table report at the end. The body will be re-evaluated in a loop
+;;; until 1000 samples have been taken. A sample count will be printed
+;;; after each iteration.
+(sb-sprof:with-profiling (:max-samples 1000
+                          :report :flat
+                          :loop t
+                          :show-progress t)
+  (cpu-test 24))
+
+;;;; Allocation profiling
+
+(defun foo (&rest args)
+  (mapcar (lambda (x) (float x 1d0)) args))
+
+(defun bar (n)
+  (declare (fixnum n))
+  (apply #'foo (loop repeat n collect n)))
+
+(sb-sprof:with-profiling (:max-samples 10000
+                          :mode :alloc
+                          :report :flat)
+  (bar 1000))
+
    + +

    16.2.2 Output

    + +

    The flat report format will show a table of all functions that the +profiler encountered on the call stack during sampling, ordered by the +number of samples taken while executing that function. +

    +
    +
               Self        Total        Cumul
+  Nr  Count     %  Count     %  Count     %    Calls  Function
+------------------------------------------------------------------------
+   1     69  24.4     97  34.3     69  24.4 67108864  CPU-TEST-INNER
+   2     64  22.6     64  22.6    133  47.0        -  SB-VM::GENERIC-+
+   3     39  13.8    256  90.5    172  60.8        1  CPU-TEST
+   4     31  11.0     31  11.0    203  71.7        -  SB-KERNEL:TWO-ARG-XOR
+
    + +

    For each function, the table will show three absolute and relative +sample counts. The Self column shows samples taken while directly +executing that function. The Total column shows samples taken while +executing that function or functions called from it (sampled to a +platform-specific depth). The Cumul column shows the sum of all +Self columns up to and including that line in the table. +

    +

    Additionally the Calls column will record the amount of calls that were +made to the function during the profiling run. This value will only +be reported for functions that have been explicitly marked for call counting +with profile-call-counts. +

    +

    The profiler also hooks into the disassembler such that instructions which +have been sampled are annotated with their relative frequency of +sampling. This information is not stored across different sampling +runs. +

    +
    +
    ;      6CF:       702E             JO L4              ; 6/242 samples
+;      6D1:       D1E3             SHL EBX, 1
+;      6D3:       702A             JO L4
+;      6D5: L2:   F6C303           TEST BL, 3         ; 2/242 samples
+;      6D8:       756D             JNE L8
+;      6DA:       8BC3             MOV EAX, EBX       ; 5/242 samples
+;      6DC: L3:   83F900           CMP ECX, 0         ; 4/242 samples
+
    + +

    16.2.3 Platform support

    + +

    Allocation profiling is only supported on SBCL builds that use +the generational garbage collector. Tracking of call stacks at a +depth of more than two levels is only supported on x86 and x86-64. +

    +

    16.2.4 Macros

    + +
    +
    Macro: with-profiling [sb-sprof] (&key sample-interval alloc-interval max-samples reset mode loop max-depth show-progress threads report) &body body
    +

    Evaluate body with statistical profiling turned on. If loop is true, +loop around the body until a sufficient number of samples has been collected. +Returns the values from the last evaluation of body. +

    +

    The following keyword args are recognized: +

    + +
    +
    :sample-interval <n>
    +

    Take a sample every <n> seconds. Default is *sample-interval*. +

    + +
    +
    :mode <mode>
    +

    If :cpu, run the profiler in cpu profiling mode. If :alloc, run the + profiler in allocation profiling mode. If :time, run the profiler + in wallclock profiling mode. +

    + +
    +
    :max-samples <max>
    +

    If :loop is nil (the default), collect no more than <max> samples. + If :loop is t, repeat evaluating body until <max> samples are taken. + Default is *max-samples*. +

    + +
    +
    :report <type>
    +

    If specified, call report with :type <type> at the end. +

    + +
    +
    :reset <bool>
    +

    If true, call reset at the beginning. +

    + +
    +
    :threads <list-form>
    +

    Form that evaluates to the list threads to profile, or :all to indicate + that all threads should be profiled. Defaults to all threads. +

    +

    :threads has no effect on call-counting at the moment. +

    +

    On some platforms (eg. Darwin) the signals used by the profiler are + not properly delivered to threads in proportion to their cpu usage + when doing :cpu profiling. If you see empty call graphs, or are obviously + missing several samples from certain threads, you may be falling afoul + of this. In this case using :mode :time is likely to work better. +

    + +
    +
    :loop <bool>
    +

    If false (the default), evaluate body only once. If true repeatedly + evaluate body. +

    +
    + +
    +
    +
    Macro: with-sampling [sb-sprof] (&optional on) &body body
    +

    Evaluate body with statistical sampling turned on or off in the current thread. +

    + +

    16.2.5 Functions

    + +
    +
    Function: map-traces [sb-sprof] function samples
    +

    Call function on each trace in samples +

    +

    The signature of function must be compatible with (thread trace). +

    +

    function is called once for each trace where thread is the sb-thread:tread +instance which was sampled to produce trace, and trace is an opaque object +to be passed to map-trace-pc-locs. +

    +

    experimental: Interface subject to change. +

    + +
    +
    Function: sample-pc [sb-sprof] info pc-or-offset
    +

    Extract and return program counter from info and pc-or-offset. +

    +

    Can be applied to the arguments passed by map-trace-pc-locs and +map-all-pc-locs. +

    +

    experimental: Interface subject to change. +

    + +
    +
    Function: report [sb-sprof] &key type max min-percent call-graph sort-by sort-order stream show-progress
    +

    Report statistical profiling results. The following keyword + args are recognized: +

    + +
    +
    :type <type>
    +

    Specifies the type of report to generate. If :flat, show + flat report, if :graph show a call graph and a flat report. + If nil, don’t print out a report. +

    + +
    +
    :stream <stream>
    +

    Specify a stream to print the report on. Default is + *standard-output*. +

    + +
    +
    :max <max>
    +

    Don’t show more than <max> entries in the flat report. +

    + +
    +
    :min-percent <min-percent>
    +

    Don’t show functions taking less than <min-percent> of the + total time in the flat report. +

    + +
    +
    :sort-by <column>
    +

    If :samples, sort flat report by number of samples taken. + If :cumulative-samples, sort flat report by cumulative number of samples + taken (shows how much time each function spent on stack.) Default + is *report-sort-by*. +

    + +
    +
    :sort-order <order>
    +

    If :descending, sort flat report in descending order. If :ascending, + sort flat report in ascending order. Default is *report-sort-order*. +

    + +
    +
    :show-progress <bool>
    +

    If true, print progress messages while generating the call graph. +

    + +
    +
    :call-graph <graph>
    +

    Print a report from <graph> instead of the latest profiling + results. +

    +
    +
    + +

    Value of this function is a call-graph object representing the +resulting call-graph, or nil if there are no samples (eg. right after +calling reset.) +

    +

    Profiling is stopped before the call graph is generated. +

    + +
    +
    Function: reset [sb-sprof]
    +

    Reset the profiler. +

    + +
    +
    Function: start-profiling [sb-sprof] &key max-samples mode sample-interval alloc-interval max-depth threads
    +

    Start profiling statistically in the current thread if not already profiling. +The following keyword args are recognized: +

    + +
    +
    :sample-interval <n>
    +

    Take a sample every <n> seconds. Default is *sample-interval*. +

    + +
    +
    :mode <mode>
    +

    If :cpu, run the profiler in cpu profiling mode. If :alloc, run + the profiler in allocation profiling mode. If :time, run the profiler + in wallclock profiling mode. +

    + +
    +
    :max-samples <max>
    +

    Maximum number of stack traces to collect. Default is *max-samples*. +

    + +
    +
    :threads <list>
    +

    List threads to profile, or :all to indicate that all threads should be + profiled. Defaults to :all. +

    +

    :threads has no effect on call-counting at the moment. +

    +

    On some platforms (eg. Darwin) the signals used by the profiler are + not properly delivered to threads in proportion to their cpu usage + when doing :cpu profiling. If you see empty call graphs, or are obviously + missing several samples from certain threads, you may be falling afoul + of this. +

    +
    + +
    + +
    +
    Function: stop-profiling [sb-sprof]
    +

    Stop profiling if profiling. +

    + +
    +
    Function: profile-call-counts [sb-sprof] &rest names
    +

    Mark the functions named by names as being subject to call counting +during statistical profiling. If a string is used as a name, it will +be interpreted as a package name. In this case call counting will be +done for all functions with names like x or (setf x), where x is a symbol +with the package as its home package. +

    + +
    +
    Function: unprofile-call-counts [sb-sprof]
    +

    Clear all call counting information. Call counting will be done for no +functions during statistical profiling. +

    + +

    16.2.6 Variables

    + +
    +
    Variable: *max-samples* [sb-sprof]
    +

    Default maximum number of stack traces collected. +

    + +
    +
    Variable: *sample-interval* [sb-sprof]
    +

    Default number of seconds between samples. +

    + +

    16.2.7 Credits

    + +

    sb-sprof is an SBCL port, with enhancements, of Gerd +Moellmann’s statistical profiler for CMUCL. +

    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    17 Contributed Modules

    + +

    SBCL comes with a number of modules that are not part of the core +system. These are loaded via (require :modulename) +(see Customization Hooks for Users). This section contains +documentation (or pointers to documentation) for some of the +contributed modules. +

    + + + + + + + + + + +
    • sb-aclrepl   +
    • sb-concurrency   +
    • sb-cover   +
    • sb-grovel   +
    • sb-md5   +
    • sb-posix   +
    • sb-queue   +
    • sb-rotate-byte   +
    • sb-simd   +
    + +
    +
    +

    +Next: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.1 sb-aclrepl

    + + + +

    The sb-aclrepl module offers an Allegro CL-style +Read-Eval-Print Loop for SBCL, with integrated inspector. Adding a +debugger interface is planned. +

    +

    17.1.1 Usage

    + +

    To start sb-aclrepl as your read-eval-print loop, put the form +

    +
    (require 'sb-aclrepl)
+
    + +

    in your ~/.sbclrc initialization file. +

    +

    17.1.2 Customization

    + +

    The following customization variables are available: +

    +
    +
    Variable: *command-char* [sb-aclrepl]
    +

    Prefix character for a top-level command +

    +
    +
    Variable: *prompt* [sb-aclrepl]
    +

    The current prompt string or formatter function. +

    +
    +
    Variable: *exit-on-eof* [sb-aclrepl]
    +

    If t, then exit when the eof character is entered. +

    +
    +
    Variable: *use-short-package-name* [sb-aclrepl]
    +

    when t, use the shortnest package nickname in a prompt +

    +
    +
    Variable: *max-history* [sb-aclrepl]
    +

    Maximum number of history commands to remember +

    + +

    17.1.3 Example Initialization

    + +

    Here’s a longer example of a ~/.sbclrc file that shows off +some of the features of sb-aclrepl: +

    +
    +
    (ignore-errors (require 'sb-aclrepl))
+
+(when (find-package 'sb-aclrepl)
+  (push :aclrepl cl:*features*))
+#+aclrepl
+(progn
+  (setq sb-aclrepl:*max-history* 100)
+  (setf (sb-aclrepl:alias "asdc")
+       #'(lambda (sys) (asdf:operate 'asdf:compile-op sys)))
+  (sb-aclrepl:alias "l" (sys) (asdf:operate 'asdf:load-op sys))
+  (sb-aclrepl:alias "t" (sys) (asdf:operate 'asdf:test-op sys))
+  ;; The 1 below means that two characaters ("up") are required
+  (sb-aclrepl:alias ("up" 1 "Use package") (package) (use-package package))
+  ;; The 0 below means only the first letter ("r") is required,
+  ;; such as ":r base64"
+  (sb-aclrepl:alias ("require" 0 "Require module") (sys) (require sys))
+  (setq cl:*features* (delete :aclrepl cl:*features*)))
+
    + +

    Questions, comments, or bug reports should be sent to Kevin Rosenberg +(kevin@rosenberg.net). +

    +

    17.1.4 Credits

    + +

    Allegro CL is a registered trademark of Franz Inc. +

    +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.2 sb-concurrency

    + + + +

    Additional data structures, synchronization primitives and tools for +concurrent programming. Similiar to Java’s java.util.concurrent +package. +

    +

    17.2.1 Queue

    + + +

    sb-concurrency:queue is a lock-free, thread-safe FIFO queue +datatype. +

    +The implementation is based on An Optimistic Approach to +Lock-Free FIFO Queues by Edya Ladan-Mozes and Nir Shavit. +

    +Before SBCL 1.0.38, this implementation resided in its own contrib +(see sb-queue) which is still provided for backwards-compatibility +but which has since been deprecated. +

    +
    +
    Structure: queue [sb-concurrency]
    +

    Class precedence list: queue, structure-object, t +

    +

    Lock-free thread safe fifo queue. +

    +

    Use enqueue to add objects to the queue, and dequeue to remove them. +

    + +
    +
    Function: dequeue [sb-concurrency] queue
    +

    Retrieves the oldest value in queue and returns it as the primary value, +and t as secondary value. If the queue is empty, returns nil as both primary +and secondary value. +

    +
    +
    Function: enqueue [sb-concurrency] value queue
    +

    Adds value to the end of queue. Returns value. +

    +
    +
    Function: list-queue-contents [sb-concurrency] queue
    +

    Returns the contents of queue as a list without removing them from the +queue. Mainly useful for manual examination of queue state, as the list may be +out of date by the time it is returned, and concurrent dequeue operations may +in the worse case force the queue-traversal to be restarted several times. +

    +
    +
    Function: make-queue [sb-concurrency] &key name initial-contents
    +

    Returns a new queue with name and contents of the initial-contents +sequence enqueued. +

    +
    +
    Function: queue-count [sb-concurrency] queue
    +

    Returns the number of objects in queue. Mainly useful for manual +examination of queue state, and in print-object methods: inefficient as it +must walk the entire queue. +

    +
    +
    Function: queue-empty-p [sb-concurrency] queue
    +

    Returns t if queue is empty, nil otherwise. +

    +
    +
    Function: queue-name [sb-concurrency] instance
    +

    Name of a queue. Can be assigned to using setf. Queue names +can be arbitrary printable objects, and need not be unique. +

    +
    +
    Function: queuep [sb-concurrency] object
    +

    Returns true if argument is a queue, nil otherwise. +

    + +

    17.2.2 Mailbox (lock-free)

    + + +

    sb-concurrency:mailbox is a lock-free message queue where one +or multiple ends can send messages to one or multiple receivers. The +difference to queues is that the receiving +end may block until a message arrives. +

    +Built on top of the queue implementation. +

    +
    +
    Structure: mailbox [sb-concurrency]
    +

    Class precedence list: mailbox, structure-object, t +

    +

    Mailbox aka message queue. +

    +

    send-message adds a message to the mailbox, receive-message waits till +a message becomes available, whereas receive-message-no-hang is a non-blocking +variant, and receive-pending-messages empties the entire mailbox in one go. +

    +

    Messages can be arbitrary objects +

    + +
    +
    Function: list-mailbox-messages [sb-concurrency] mailbox
    +

    Returns a fresh list containing all the messages in the +mailbox. Does not remove messages from the mailbox. +

    +
    +
    Function: mailbox-count [sb-concurrency] mailbox
    +

    Returns the number of messages currently in the mailbox. +

    +
    +
    Function: mailbox-empty-p [sb-concurrency] mailbox
    +

    Returns true if mailbox is currently empty, nil otherwise. +

    +
    +
    Function: mailbox-name [sb-concurrency] instance
    +

    Name of a mailbox. SETFable. +

    +
    +
    Function: mailboxp [sb-concurrency] object
    +

    Returns true if argument is a mailbox, nil otherwise. +

    +
    +
    Function: make-mailbox [sb-concurrency] &key name initial-contents
    +

    Returns a new mailbox with messages in initial-contents enqueued. +

    +
    +
    Function: receive-message [sb-concurrency] mailbox &key timeout
    +

    Removes the oldest message from mailbox and returns it as the primary +value, and a secondary value of t. If mailbox is empty waits until a message +arrives. +

    +

    If timeout is provided, and no message arrives within the specified interval, +returns primary and secondary value of nil. +

    +
    +
    Function: receive-message-no-hang [sb-concurrency] mailbox
    +

    The non-blocking variant of receive-message. Returns two values, +the message removed from mailbox, and a flag specifying whether a +message could be received. +

    +
    +
    Function: receive-pending-messages [sb-concurrency] mailbox &optional n
    +

    Removes and returns all (or at most n) currently pending messages +from mailbox, or returns nil if no messages are pending. +

    +

    Note: Concurrent threads may be snarfing messages during the run of +this function, so even though x,y appear right next to each other in +the result, does not necessarily mean that y was the message sent +right after x. +

    +
    +
    Function: send-message [sb-concurrency] mailbox message
    +

    Adds a message to mailbox. Message can be any object. +

    + +

    17.2.3 Gates

    + + +

    sb-concurrency:gate is a synchronization object suitable for when +multiple threads must wait for a single event before proceeding. +

    +
    +
    Structure: gate [sb-concurrency]
    +

    Class precedence list: gate, structure-object, t +

    +

    gate type. Gates are synchronization constructs suitable for making +multiple threads wait for single event before proceeding. +

    +

    Use wait-on-gate to wait for a gate to open, open-gate to open one, +and close-gate to close an open gate. gate-open-p can be used to test +the state of a gate without blocking. +

    + +
    +
    Function: close-gate [sb-concurrency] gate
    +

    Closes gate. Returns t if the gate was previously open, and nil +if the gate was already closed. +

    +
    +
    Function: gate-name [sb-concurrency] instance
    +

    Name of a gate. SETFable. +

    +
    +
    Function: gate-open-p [sb-concurrency] gate
    +

    Returns true if gate is open. +

    +
    +
    Function: gatep [sb-concurrency] object
    +

    Returns true if the argument is a gate. +

    +
    +
    Function: make-gate [sb-concurrency] &key name open
    +

    Makes a new gate. Gate will be initially open if open is true, and closed if open +is nil (the default.) name, if provided, is the name of the gate, used when printing +the gate. +

    +
    +
    Function: open-gate [sb-concurrency] gate
    +

    Opens gate. Returns t if the gate was previously closed, and nil +if the gate was already open. +

    +
    +
    Function: wait-on-gate [sb-concurrency] gate &key timeout
    +

    Waits for gate to open, or timeout seconds to pass. Returns t +if the gate was opened in time, and nil otherwise. +

    + +

    17.2.4 Frlocks, aka Fast Read Locks

    + + + +
    +
    Structure: frlock [sb-concurrency]
    +

    Class precedence list: frlock, structure-object, t +

    +

    FRlock, aka Fast Read Lock. +

    +

    Fast Read Locks allow multiple readers and one potential writer to operate in +parallel while providing for consistency for readers and mutual exclusion for +writers. +

    +

    Readers gain entry to protected regions without waiting, but need to retry if +a writer operated inside the region while they were reading. This makes frlocks +very efficient when readers are much more common than writers. +

    +

    FRlocks are not suitable when it is not safe at all for readers and writers to +operate on the same data in parallel: they provide consistency, not exclusion +between readers and writers. Hence using an frlock to eg. protect an sbcl +hash-table is unsafe. If multiple readers operating in parallel with a writer +would be safe but inconsistent without a lock, frlocks are suitable. +

    +

    The recommended interface to use is frlock-read and frlock-write, but those +needing it can also use a lower-level interface. +

    +

    Example: +

    +
    +
      ;; Values returned by FOO are always consistent so that
+  ;; the third value is the sum of the two first ones.
+  (let ((a 0)
+        (b 0)
+        (c 0)
+        (lk (make-frlock)))
+    (defun foo ()
+       (frlock-read (lk) a b c))
+    (defun bar (x y)
+       (frlock-write (lk)
+         (setf a x
+               b y
+               c (+ x y)))))
+
    +
    + +
    +
    Macro: frlock-read [sb-concurrency] (frlock) &body value-forms
    +

    Evaluates value-forms under frlock till it obtains a consistent +set, and returns that as multiple values. +

    +
    +
    Macro: frlock-write [sb-concurrency] (frlock &key wait-p timeout) &body body
    +

    Executes body while holding frlock for writing. +

    + +
    +
    Function: make-frlock [sb-concurrency] &key name
    +

    Returns a new frlock with name. +

    +
    +
    Function: frlock-name [sb-concurrency] instance
    +

    Name of an frlock. SETFable. +

    + +
    +
    Function: frlock-read-begin [sb-concurrency] frlock
    +

    Start a read sequence on frlock. Returns a read-token and an epoch to be +validated later. +

    +

    Using frlock-read instead is recommended. +

    +
    +
    Function: frlock-read-end [sb-concurrency] frlock
    +

    Ends a read sequence on frlock. Returns a token and an epoch. If the token +and epoch are eql to the read-token and epoch returned by frlock-read-begin, +the values read under the frlock are consistent and can be used: if the values +differ, the values are inconsistent and the read must be restated. +

    +

    Using frlock-read instead is recommended. +

    +

    Example: +

    +
    +
      (multiple-value-bind (t0 e0) (frlock-read-begin *fr*)
+    (let ((a (get-a))
+          (b (get-b)))
+      (multiple-value-bind (t1 e1) (frlock-read-end *fr*)
+        (if (and (eql t0 t1) (eql e0 e1))
+            (list :a a :b b)
+            :aborted))))
+
    +
    +
    +
    Function: grab-frlock-write-lock [sb-concurrency] frlock &key wait-p timeout
    +

    Acquires frlock for writing, invalidating existing and future read-tokens +for the duration. Returns t on success, and nil if the lock wasn’t acquired +due to eg. a timeout. Using frlock-write instead is recommended. +

    +
    +
    Function: release-frlock-write-lock [sb-concurrency] frlock
    +

    Releases frlock after writing, allowing valid read-tokens to be acquired again. +Signals an error if the current thread doesn’t hold frlock for writing. Using frlock-write +instead is recommended. +

    + +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.3 sb-cover

    + + +

    The sb-cover module provides a code coverage tool for SBCL. The +tool has support for expression coverage, and for some branch coverage. +Coverage reports are only generated for code compiled using +compile-file with the value of the +sb-cover:store-coverage-data optimization quality set to 3. +

    +

    As of SBCL 1.0.6 sb-cover is still experimental, and the +interfaces documented here might change in later versions. +

    +

    17.3.1 Example Usage

    + +
    +
    ;;; Load SB-COVER
+(require :sb-cover)
+
+;;; Turn on generation of code coverage instrumentation in the compiler
+(declaim (optimize sb-cover:store-coverage-data))
+
+;;; Load some code, ensuring that it's recompiled with the new optimization
+;;; policy.
+(asdf:oos 'asdf:load-op :cl-ppcre-test :force t)
+
+;;; Run the test suite.
+(cl-ppcre-test:test)
+
+;;; Produce a coverage report
+(sb-cover:report "/tmp/report/")
+
+;;; Turn off instrumentation
+(declaim (optimize (sb-cover:store-coverage-data 0)))
+
    + + +

    17.3.2 Functions

    + +
    +
    Function: report [sb-cover] directory &key form-mode if-matches external-format
    +

    Print a code coverage report of all instrumented files into directory. +If directory does not exist, it will be created. The main report will be +printed to the file cover-index.html. The external format of the source +files can be specified with the external-format parameter. +

    +

    If the keyword argument form-mode has the value :car, the annotations in +the coverage report will be placed on the CARs of any cons-forms, while if +it has the value :whole the whole form will be annotated (the default). +The former mode shows explicitly which forms were instrumented, while the +latter mode is generally easier to read. +

    +

    The keyword argument if-matches should be a designator for a function +of one argument, called for the namestring of each file with code +coverage info. If it returns true, the file’s info is included in the +report, otherwise ignored. The default value is cl:identity. +

    + +
    +
    Function: reset-coverage [sb-cover] &optional object
    +

    Reset all coverage data back to the ‘Not executed‘ state. +

    + +
    +
    Function: clear-coverage [sb-cover]
    +

    Clear all files from the coverage database. The files will be re-entered +into the database when the fasl files (produced by compiling +store-coverage-data optimization policy set to 3) are loaded again into the +image. +

    + +
    +
    Function: save-coverage [sb-cover]
    +

    Returns an opaque representation of the current code coverage state. +The only operation that may be done on the state is passing it to +restore-coverage. The representation is guaranteed to be readably printable. +A representation that has been printed and read back will work identically +in restore-coverage. +

    + +
    +
    Function: save-coverage-in-file [sb-cover] pathname
    +

    Call save-coverage and write the results of that operation into the +file designated by pathname. +

    + +
    +
    Function: restore-coverage [sb-cover] coverage-state
    +

    Restore the code coverage data back to an earlier state produced by +save-coverage. +

    + +
    +
    Function: restore-coverage-from-file [sb-cover] pathname
    +

    read the contents of the file designated by pathname and pass the +result to restore-coverage. +

    + + +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.4 sb-grovel

    + + +

    The sb-grovel module helps in generation of foreign function +interfaces. It aids in extracting constants’ values from the C +compiler and in generating SB-ALIEN structure and union types, +see Defining Foreign Types. +

    +

    The ASDF(http://www.cliki.net/ASDF) component type +GROVEL-CONSTANTS-FILE has its PERFORM +operation defined to write out a C source file, compile it, and run +it. The output from this program is Lisp, which is then itself +compiled and loaded. +

    +

    sb-grovel is used in a few contributed modules, and it is currently +compatible only to SBCL. However, if you want to use it, here are a +few directions. +

    +

    17.4.1 Using sb-grovel in your own ASDF system

    + +
      +
    1. Create a Lisp package for the foreign constants/functions to go into. + +
    2. Make your system depend on the ’sb-grovel system. + +
    3. Create a grovel-constants data file - for an example, see +example-constants.lisp in the contrib/sb-grovel/ directory in the SBCL +source distribution. + +
    4. Add it as a component in your system. e.g. + +
      +
      (eval-when (:compile-toplevel :load-toplevel :execute)
+  (require :sb-grovel))
+
+(defpackage :example-package.system
+            (:use :cl :asdf :sb-grovel :sb-alien))
+
+(in-package :example-package.system)
+
+(defsystem example-system
+    :depends-on (sb-grovel)
+    :components
+    ((:module "sbcl"
+              :components
+              ((:file "defpackage")
+               (grovel-constants-file "example-constants"
+                                      :package :example-package)))))
+
      + +

      Make sure to specify the package you chose in step 1 +

      +
    5. Build stuff. + +
    + +

    17.4.2 Contents of a grovel-constants-file

    + +

    The grovel-constants-file, typically named constants.lisp, +comprises lisp expressions describing the foreign things that you want +to grovel for. A constants.lisp file contains two sections: +

    +
      +
    • a list of headers to include in the C program, for example: +
      +
      ("sys/types.h" "sys/socket.h" "sys/stat.h" "unistd.h" "sys/un.h"
+ "netinet/in.h" "netinet/in_systm.h" "netinet/ip.h" "net/if.h"
+ "netdb.h" "errno.h" "netinet/tcp.h" "fcntl.h" "signal.h" )
+
      + +
    • A list of sb-grovel clauses describing the things you want to grovel +from the C compiler, for example: +
      +
      ((:integer af-local
+           #+(or sunos solaris) "AF_UNIX"
+           #-(or sunos solaris) "AF_LOCAL"
+           "Local to host (pipes and file-domain).")
+ (:structure stat ("struct stat"
+                   (integer dev "dev_t" "st_dev")
+                   (integer atime "time_t" "st_atime")))
+ (:function getpid ("getpid" int )))
+
      +
    + +

    There are two types of things that sb-grovel can sensibly extract from +the C compiler: constant integers and structure layouts. It is also +possible to define foreign functions in the constants.lisp file, but +these definitions don’t use any information from the C program; they +expand directly to sb-alien:define-alien-routine +(see The define-alien-routine Macro) forms. +

    +

    Here’s how to use the grovel clauses: +

    +
      +
    • :integer - constant expressions in C. Used in this form: +
      +
       (:integer lisp-variable-name "C expression" &optional doc export)
+
      + +

      "C expression" will be typically be the name of a constant. But +other forms are possible. +

      +
    • :enum +
      +
       (:enum lisp-type-name ((lisp-enumerated-name c-enumerated-name) ...)))
+
      + +

      An sb-alien:enum type with name lisp-type-name will be defined. +The symbols are the lisp-enumerated-names, and the values +are grovelled from the c-enumerated-names. +

      +
    • :structure - alien structure definitions look like this: +
      +
       (:structure lisp-struct-name ("struct c_structure"
+                               (type-designator lisp-element-name
+                                "c_element_type" "c_element_name"
+                                :distrust-length nil)
+                               ; ...
+                               ))
+
      + +

      type-designator is a reference to a type whose size (and type +constraints) will be groveled for. sb-grovel accepts a form of type +designator that doesn’t quite conform to either lisp nor sb-alien’s +type specifiers. Here’s a list of type designators that sb-grovel +currently accepts: +

        +
      • integer - a C integral type; sb-grovel will infer the exact +type from size information extracted from the C program. All common C +integer types can be grovelled for with this type designator, but it +is not possible to grovel for bit fields yet. + +
      • (unsigned n) - an unsigned integer variable that is n +bytes long. No size information from the C program will be used. +
      • (signed n) - an signed integer variable that is n bytes +long. No size information from the C program will be used. + +
      • c-string - an array of char in the structure. sb-grovel +will use the array’s length from the C program, unless you pass it the +:distrust-length keyword argument with non-nil value +(this might be required for structures such as solaris’s struct +dirent). + +
      • c-string-pointer - a pointer to a C string, corresponding to +the sb-alien:c-string type (see Foreign Type Specifiers). +
      • (array alien-type) - An array of the previously-declared alien +type. The array’s size will be determined from the output of the C +program and the alien type’s size. +
      • (array alien-type n) - An array of the previously-declared alien +type. The array’s size will be assumed as being n. +
      + + +

      Note that c-string and c-string-pointer do not have the +same meaning. If you declare that an element is of type +c-string, it will be treated as if the string is a part of the +structure, whereas if you declare that the element is of type +c-string-pointer, a pointer to a string will be the +structure member. +

      +
    • :function - alien function definitions are similar to +define-alien-routine definitions, because they expand to such +forms when the lisp program is loaded. See Foreign Function Calls. + +
      +
      (:function lisp-function-name ("alien_function_name" alien-return-type
+                                                     (argument alien-type)
+                                                     (argument2 alien-type)))
+
      +
    + + +

    17.4.3 Programming with sb-grovel’s structure types

    + +

    Let us assume that you have a grovelled structure definition: +

    +
     (:structure mystruct ("struct my_structure"
+                       (integer myint "int" "st_int")
+                       (c-string mystring "char[]" "st_str")))
+
    + +

    What can you do with it? Here’s a short interface document: +

    +
      +
    • Creating and destroying objects: +
        +
      • Function (allocate-mystruct) - allocates an object of type mystructand +returns a system area pointer to it. +
      • Function (free-mystruct var) - frees the alien object pointed to by +var. +
      • Macro (with-mystruct var ((member init) [...]) &body body) - +allocates an object of type mystruct that is valid in +body. If body terminates or control unwinds out of +body, the object pointed to by var will be deallocated. +
      + +
    • Accessing structure members: +
        +
      • (mystruct-myint var) and (mystruct-mystring var) return +the value of the respective fields in mystruct. +
      • (setf (mystruct-myint var) new-val) and +(setf (mystruct-mystring var) new-val) sets the value of the respective +structure member to the value of new-val. Notice that in +(setf (mystruct-mystring var) new-val)’s case, new-val is a lisp +string. +
      +
    + +

    17.4.3.1 Traps and Pitfalls

    +

    Basically, you can treat functions and data structure definitions that +sb-grovel spits out as if they were alien routines and types. This has +a few implications that might not be immediately obvious (especially +if you have programmed in a previous version of sb-grovel that didn’t +use alien types): +

    +
      +
    • You must take care of grovel-allocated structures yourself. They are +alien types, so the garbage collector will not collect them when you +drop the last reference. + +
    • If you use the with-mystruct macro, be sure that no references +to the variable thus allocated leaks out. It will be deallocated when +the block exits. +
    + +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.5 sb-md5

    + + +

    The sb-md5 module implements the RFC1321 MD5 Message Digest +Algorithm. [FIXME cite] +

    +
    +
    Function: md5sum-file [sb-md5] pathname
    +

    Calculate the MD5 message-digest of the file specified by ‘pathname’. +

    + +
    +
    Function: md5sum-sequence [sb-md5] sequence &key start end
    +

    Calculate the MD5 message-digest of data in ‘sequence’, which should +be a 1d simple-array with element type (unsigned-byte 8). On cmu cl +and sbcl non-simple and non-1d arrays with this element-type are also +supported. +

    + +
    +
    Function: md5sum-stream [sb-md5] stream
    +

    Calculate an MD5 message-digest of the contents of ‘stream’. Its +element-type has to be (unsigned-byte 8). Use on character streams is +deprecated, as this will not work correctly on implementations with +‘char-code-limit’ > 256 and ignores character coding issues. +

    + +
    +
    Function: md5sum-string [sb-md5] string &key external-format start end
    +

    Calculate the MD5 message-digest of the binary representation of +‘string’ (as octets) in the external format specified by +‘external-format’. The boundaries ‘start’ and ‘end’ refer to character +positions in the string, not to octets in the resulting binary +representation. The permissible external format specifiers are +determined by the underlying implementation. +

    + +

    17.5.1 Credits

    + +

    The implementation for CMUCL was largely done by Pierre Mai, with help +from members of the cmucl-help mailing list. Since CMUCL and +SBCL are similar in many respects, it was not too difficult to extend +the low-level implementation optimizations for CMUCL to SBCL. +Following this, SBCL’s compiler was extended to implement efficient +compilation of modular arithmetic (see Modular arithmetic), which +enabled the implementation to be expressed in portable arithmetical +terms, apart from the use of rotate-byte for bitwise rotation. + +

    + +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.6 sb-posix

    + + + + +

    Sb-posix is the supported interface for calling out to the operating +system.10 +

    +

    The scope of this interface is “operating system calls on a typical +Unixlike platform”. This is section 2 of the Unix manual, plus section +3 calls that are (a) typically found in libc, but (b) not part of the C +standard. For example, we intend to provide support for +opendir() and readdir(), but not for printf(). +That said, if your favourite system call is not included yet, you are +encouraged to submit a patch to the SBCL mailing list. +

    +

    Some facilities are omitted where they offer absolutely no additional +use over some portable function, or would be actively dangerous to the +consistency of Lisp. Not all functions are available on all +platforms. +

    + + + + + + + +
    • Lisp names for C names   +
    • Types   +
    • Function Parameters   +
    • Function Return Values   +
    • Lisp objects and C structures   +
    • Functions with idiosyncratic bindings   +
    + + +
    +
    +

    +Next: , Up: sb-posix   [Contents][Index]

    +
    +

    17.6.1 Lisp names for C names

    + +

    All symbols are in the SB-POSIX package. This package contains a +Lisp function for each supported Unix system call or function, a +variable or constant for each supported Unix constant, an object type +for each supported Unix structure type, and a slot name for each +supported Unix structure member. A symbol name is derived from the C +binding’s name, by (a) uppercasing, then (b) removing leading +underscores (#\_) then replacing remaining underscore characters +with the hyphen (#\-). The requirement to uppercase is so that in +a standard upcasing reader the user may write sb-posix:creat +instead of sb-posix:|creat| as would otherise be required. +

    +

    No other changes to “Lispify” symbol names are made, so creat() +becomes CREAT, not CREATE. +

    +

    The user is encouraged not to (USE-PACKAGE :SB-POSIX) but instead +to use the SB-POSIX: prefix on all references, as some of the +symbols symbols contained in the SB-POSIX package have the same name as +CL symbols (OPEN, CLOSE, SIGNAL etc). +

    +
    +
    +

    +Next: , Previous: , Up: sb-posix   [Contents][Index]

    +
    +

    17.6.2 Types

    + +

    Generally, marshalling between Lisp and C data types is done using +SBCL’s FFI. See Foreign Function Interface. +

    +

    Some functions accept objects such as filenames or file descriptors. In +the C binding to POSIX these are represented as strings and small +integers respectively. For the Lisp programmer’s convenience we +introduce designators such that CL pathnames or open streams can be +passed to these functions. For example, rename accepts both +pathnames and strings as its arguments. +

    + + + +
    • File-descriptors   +
    • Filenames   +
    + +
    +
    +

    +Next: , Up: Types   [Contents][Index]

    +
    +

    17.6.2.1 File-descriptors

    + +
    +
    Type: file-descriptor [sb-posix]
    +

    A fixnum designating a native file descriptor. +

    +

    sb-sys:make-fd-stream can be used to construct a file-stream associated with a +native file descriptor. +

    +

    Note that mixing I/O operations on a file-stream with operations directly on its +descriptor may produce unexpected results if the stream is buffered. +

    +
    +
    Type: file-descriptor-designator [sb-posix]
    +

    Designator for a file-descriptor: either a fixnum designating itself, or +a file-stream designating the underlying file-descriptor. +

    +
    +
    Function: file-descriptor [sb-posix] file-descriptor
    +

    Converts file-descriptor-designator into a file-descriptor. +

    + +
    +
    +

    +Previous: , Up: Types   [Contents][Index]

    +
    +

    17.6.2.2 Filenames

    + +
    +
    Type: filename [sb-posix]
    +

    A string designating a filename in native namestring syntax. +

    +

    Note that native namestring syntax is distinct from Lisp namestring syntax: +

    +
    +
      (pathname "/foo*/bar")
+
    + +

    is a wild pathname with a pattern-matching directory component. +sb-ext:parse-native-namestring may be used to construct Lisp pathnames that +denote posix filenames as understood by system calls, and +sb-ext:native-namestring can be used to coerce them into strings in the native +namestring syntax. +

    +

    Note also that posix filename syntax does not distinguish the names of files +from the names of directories: in order to parse the name of a directory in +posix filename syntax into a pathname my-defaults for which +

    +
    +
      (merge-pathnames (make-pathname :name "FOO" :case :common)
+                    my-defaults)
+
    + +

    returns a pathname that denotes a file in the directory, supply a true +:as-directory argument to sb-ext:parse-native-namestring. Likewise, to supply +the name of a directory to a posix function in non-directory syntax, supply a +true :as-file argument to sb-ext:native-namestring. +

    +
    +
    Type: filename-designator [sb-posix]
    +

    Designator for a filename: a string designating itself, or a +designator for a pathname designating the corresponding native namestring. +

    +
    +
    Function: filename [sb-posix] filename
    +

    Converts filename-designator into a filename. +

    + +
    +
    +

    +Next: , Previous: , Up: sb-posix   [Contents][Index]

    +
    +

    17.6.3 Function Parameters

    + +

    The calling convention is modelled after that of CMUCL’s UNIX +package: in particular, it’s like the C interface except that: +

    +
      +
    1. Length arguments are omitted or optional where the sensible value +is obvious. For example, read would be defined this way: + +
      +
      (read fd buffer &optional (length (length buffer))) => bytes-read
+
      + +
    2. Where C simulates “out” parameters using pointers (for instance, in +pipe() or socketpair()) these may be optional or omitted +in the Lisp interface: if not provided, appropriate objects will be +allocated and returned (using multiple return values if necessary). + +
    3. Some functions accept objects such as filenames or file descriptors. +Wherever these are specified as such in the C bindings, the Lisp +interface accepts designators for them as specified in the ’Types’ +section above. + +
    4. A few functions have been included in sb-posix that do not correspond +exactly with their C counterparts. These are described in +See Functions with idiosyncratic bindings. + +
    + +
    +
    +

    +Next: , Previous: , Up: sb-posix   [Contents][Index]

    +
    +

    17.6.4 Function Return Values

    + +

    The return value is usually the same as for the C binding, except in +error cases: where the C function is defined as returning some sentinel +value and setting errno on error, we instead signal an error of +type SYSCALL-ERROR. The actual error value (errno) is +stored in this condition and can be accessed with SYSCALL-ERRNO. +

    +

    We do not automatically translate the returned value into “Lispy” +objects – for example, SB-POSIX:OPEN returns a small integer, +not a stream. Exception: boolean-returning functions (or, more +commonly, macros) do not return a C integer, but instead a Lisp +boolean. +

    +
    +
    +

    +Next: , Previous: , Up: sb-posix   [Contents][Index]

    +
    +

    17.6.5 Lisp objects and C structures

    + +

    Sb-posix provides various Lisp object types to stand in for C +structures in the POSIX library. Lisp bindings to C functions that +accept, manipulate, or return C structures accept, manipulate, or +return instances of these Lisp types instead of instances of alien +types. +

    +

    The names of the Lisp types are chosen according to the general rules +described above. For example Lisp objects of type STAT stand +in for C structures of type struct stat. +

    +

    Accessors are provided for each standard field in the structure. These +are named structure-name-field-name where the two +components are chosen according to the general name conversion rules, +with the exception that in cases where all fields in a given structure +have a common prefix, that prefix is omitted. For example, +stat.st_dev in C becomes STAT-DEV in Lisp. +

    + + +

    Because sb-posix might not support all semi-standard or +implementation-dependent members of all structure types on your system +(patches welcome), here is an enumeration of all supported Lisp +objects corresponding to supported POSIX structures, and the supported +slots for those structures. +

    +
      +
    • flock +
      +
      Class: flock [sb-posix]
      +

      Class precedence list: flock, standard-object, t +

      +

      Slots: +

        +
      • type — initarg: :type; reader: sb-posix:flock-type; writer: (setf sb-posix:flock-type) + +

        Type of lock; F_RDLCK, F_WRLCK, F_UNLCK. +

      • whence — initarg: :whence; reader: sb-posix:flock-whence; writer: (setf sb-posix:flock-whence) + +

        Flag for starting offset. +

      • start — initarg: :start; reader: sb-posix:flock-start; writer: (setf sb-posix:flock-start) + +

        Relative offset in bytes. +

      • len — initarg: :len; reader: sb-posix:flock-len; writer: (setf sb-posix:flock-len) + +

        Size; if 0 then until eof. +

      • pid — reader: sb-posix:flock-pid + +

        Process id of the process holding the lock; returned with F_GETLK. +

      + +

      Class representing locks used in fcntl(2). +

      + +
    • passwd +
      +
      Class: passwd [sb-posix]
      +

      Class precedence list: passwd, standard-object, t +

      +

      Slots: +

        +
      • name — initarg: :name; reader: sb-posix:passwd-name; writer: (setf sb-posix:passwd-name) + +

        User’s login name. +

      • passwd — initarg: :passwd; reader: sb-posix:passwd-passwd; writer: (setf sb-posix:passwd-passwd) + +

        The account’s encrypted password. +

      • uid — initarg: :uid; reader: sb-posix:passwd-uid; writer: (setf sb-posix:passwd-uid) + +

        Numerical user id. +

      • gid — initarg: :gid; reader: sb-posix:passwd-gid; writer: (setf sb-posix:passwd-gid) + +

        Numerical group id. +

      • gecos — initarg: :gecos; reader: sb-posix:passwd-gecos; writer: (setf sb-posix:passwd-gecos) + +

        User’s name or comment field. +

      • dir — initarg: :dir; reader: sb-posix:passwd-dir; writer: (setf sb-posix:passwd-dir) + +

        Initial working directory. +

      • shell — initarg: :shell; reader: sb-posix:passwd-shell; writer: (setf sb-posix:passwd-shell) + +

        Program to use as shell. +

      + +

      Instances of this class represent entries in the system’s user database. +

      + +
    • stat +
      +
      Class: stat [sb-posix]
      +

      Class precedence list: stat, standard-object, t +

      +

      Slots: +

        +
      • mode — initarg: :mode; reader: sb-posix:stat-mode + +

        Mode of file. +

      • ino — initarg: :ino; reader: sb-posix:stat-ino + +

        File serial number. +

      • dev — initarg: :dev; reader: sb-posix:stat-dev + +

        Device id of device containing file. +

      • nlink — initarg: :nlink; reader: sb-posix:stat-nlink + +

        Number of hard links to the file. +

      • uid — initarg: :uid; reader: sb-posix:stat-uid + +

        User id of file. +

      • gid — initarg: :gid; reader: sb-posix:stat-gid + +

        Group id of file. +

      • size — initarg: :size; reader: sb-posix:stat-size + +

        For regular files, the file size in + bytes. For symbolic links, the length + in bytes of the filename contained in + the symbolic link. +

      • rdev — initarg: :rdev; reader: sb-posix:stat-rdev + +

        For devices the device number. +

      • atime — initarg: :atime; reader: sb-posix:stat-atime + +

        Time of last access. +

      • mtime — initarg: :mtime; reader: sb-posix:stat-mtime + +

        Time of last data modification. +

      • ctime — initarg: :ctime; reader: sb-posix:stat-ctime + +

        Time of last status change. +

      + +

      Instances of this class represent posix file metadata. +

      + +
    • termios +
      +
      Class: termios [sb-posix]
      +

      Class precedence list: termios, standard-object, t +

      +

      Slots: +

        +
      • iflag — initarg: :iflag; reader: sb-posix:termios-iflag; writer: (setf sb-posix:termios-iflag) + +

        Input modes. +

      • oflag — initarg: :oflag; reader: sb-posix:termios-oflag; writer: (setf sb-posix:termios-oflag) + +

        Output modes. +

      • cflag — initarg: :cflag; reader: sb-posix:termios-cflag; writer: (setf sb-posix:termios-cflag) + +

        Control modes. +

      • lflag — initarg: :lflag; reader: sb-posix:termios-lflag; writer: (setf sb-posix:termios-lflag) + +

        Local modes. +

      • cc — initarg: :cc; reader: sb-posix:termios-cc; writer: (setf sb-posix:termios-cc) + +

        Control characters. +

      + +

      Instances of this class represent I/O characteristics of the terminal. +

      + +
    • timeval +
      +
      Class: timeval [sb-posix]
      +

      Class precedence list: timeval, standard-object, t +

      +

      Slots: +

        +
      • sec — initarg: :tv-sec; reader: sb-posix:timeval-sec; writer: (setf sb-posix:timeval-sec) + +

        Seconds. +

      • usec — initarg: :tv-usec; reader: sb-posix:timeval-usec; writer: (setf sb-posix:timeval-usec) + +

        Microseconds. +

      + +

      Instances of this class represent time values. +

      +
    + +
    +
    +

    +Previous: , Up: sb-posix   [Contents][Index]

    +
    +

    17.6.6 Functions with idiosyncratic bindings

    + +

    A few functions in sb-posix don’t correspond directly to their C +counterparts. +

    +
      +
    • getcwd +
      +
      Function: getcwd [sb-posix]
      +

      Returns the process’s current working directory as a string. +

      +
    • readlink +
      + +

      Returns the resolved target of a symbolic link as a string. +

      +
    • syslog +
      +
      Function: syslog [sb-posix] priority format &rest args
      +

      Send a message to the syslog facility, with severity level +priority. The message will be formatted as by cl:format (rather +than C’s printf) with format string format and arguments args. +

      +
    + +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.7 sb-queue

    + + +

    Since SBCL 1.0.38, the sb-queue module has been merged into the +sb-concurrency module (see sb-concurrency.) +

    +
    +
    +

    +Next: , Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.8 sb-rotate-byte

    + + + + +

    The sb-rotate-byte module offers an interface to bitwise +rotation, with an efficient implementation for operations which can be +performed directly using the platform’s arithmetic routines. It +implements the specification at +http://www.cliki.net/ROTATE-BYTE. +

    +

    Bitwise rotation is a component of various cryptographic or hashing +algorithms: MD5, SHA-1, etc.; often these algorithms are specified on +32-bit rings. [FIXME cite cite cite]. +

    +
    +
    Function: rotate-byte [sb-rotate-byte] count bytespec integer
    +

    Rotates a field of bits within integer; specifically, returns an +integer that contains the bits of integer rotated count times +leftwards within the byte specified by bytespec, and elsewhere +contains the bits of integer. +

    + +
    +
    +

    +Previous: , Up: Contributed Modules   [Contents][Index]

    +
    +

    17.9 sb-simd

    + + +

    The sb-simd module provides a convenient interface for SIMD +programming in SBCL. It provides one package per SIMD instruction set, +plus functions and macros for querying whether an instruction set is +available and what functions and data types it exports. +

    +

    17.9.1 Data Types

    + +

    The central data type in sb-simd is the SIMD pack. A SIMD pack +is very similar to a specialized vector, except that its length must be +a particular power of two that depends on its element type and the +underlying hardware. The set of element types that are supported for +SIMD packs is similar to that of SBCL’s specialized array element types, +except that there is currently no support for SIMD packs of complex +numbers or characters. +

    +

    The supported scalar types are f32, f64, sN, and +uN, where N is either 8, 16, 32, or 64. These scalar +types are abbreviations for the Common Lisp types single-float, +double-float, signed-byte, and unsigned-byte, +respectively. For each scalar data type X, there exists one or +more SIMD data type X.Y with Y elements. For example, in +AVX there are two supported SIMD data types with element type +f64, namely f64.2 (128 bit) and f64.4 (256 bit). +

    +

    SIMD packs are regular Common Lisp objects that have a type, a class, +and can be passed as function arguments. The price for this is that +SIMD packs have both a boxed and an unboxed representation. The unboxed +representation of a SIMD pack has zero overhead and fits into a CPU +register, but can only be used within a function and when the compiler +can statically determine the SIMD pack’s type. Otherwise, the SIMD pack +is boxed, i.e., spilled to the heap together with its type information. +In practice, boxing of SIMD packs can usually be avoided via inlining, +or by loading and storing them to specialized arrays instead of passing +them around as function arguments. +

    +

    17.9.2 Casts

    + +

    For each scalar data type X, there is a function named X +that is equivalent to (lambda (v) (coerce v 'X)). For each SIMD +data type X.Y, there is a function named X.Y that ensures +that its argument is of type X.Y, or, if the argument is a number, +calls the cast function of X and broadcasts the result. +

    +

    All functions provided by sb-simd (apart from the casts +themselves) implicitly cast each argument to its expected type. So to +add the number five to each single float in a SIMD pack x of type +f32.8, it is sufficient to write (f32.8+ x 5). We don’t +mention this implicit conversion explicitly in the following sections, +so if any function description states that an argument must be of type +X.Y, the argument can actually be of any type that is a suitable +argument of the cast function named X.Y. +

    +

    17.9.3 Constructors

    + +

    For each SIMD data type X.Y, there is a constructor named +make-X.Y that takes Y arguments of type X and +returns a SIMD pack whose elements are the supplied values. +

    +

    17.9.4 Unpackers

    + +

    For each SIMD data type X.Y, there is a function named +X.Y-values that returns, as Y multiple values, the +elements of the supplied SIMD pack of type X.Y. +

    +

    17.9.5 Reinterpret Casts

    + +

    For each SIMD data type X.Y, there is a function named +X.Y! that takes any SIMD pack or scalar datum and interprets its +bits as a SIMD pack of type X.Y. If the supplied datum has more +bits than the resulting value, the excess bits are discarded. If the +supplied datum has less bits than the resulting value, the missing bits are +assumed to be zero. +

    +

    17.9.6 Associatives

    + +

    For each associative binary function, e.g., two-arg-X.Y-OP, there +is a function X.Y-OP that takes any number of arguments and +combines them with this binary function in a tree-like fashion. If the +binary function has an identity element, it is possible to call the +function with zero arguments, in which case the identity element is +returned. If there is no identity element, the function must receive at +least one argument. +

    +

    Examples of associative functions are f32.8+, for summing any +number of 256 bit packs of single floats, and u8.32-max, for +computing the element-wise maximum of one or more 256 bit packs of 8 bit +integers. +

    +

    17.9.7 Reducers

    + +

    For binary functions two-arg-X.Y-OP that are not associative, but +that have a neutral element, there are functions X.Y-OP that take +any positive number of arguments and return the reduction of all +arguments with the binary function. In the special case of a single +supplied argument, the binary function is invoked on the neutral element +and that argument. Reducers have been introduced to generate Lisp-style +subtraction and division functions. +

    +

    Examples of reducers are f32.8/, for successively dividing a pack +of 32 bit single floats by all further supplied packs of 32 bit single +floats, or u32.8- for subtracting any number of supplied packs of +32 bit unsigned integers from the first supplied one, except in the case +of a single argument, where u32.8- simply negates all values in +the pack. +

    +

    17.9.8 Rounding

    + +

    For each floating-point SIMD data type X.Y there are several +functions that round the values of a supplied SIMD pack to nearby +floating-point values whose fractional digits are all zero. Those +functions are X.Y-round, X.Y-floor, X.Y-ceiling, +and X.Y-truncate, and they have the same semantics as the one +argument versions of cl:round, cl:floor, +cl:ceiling, and cl:truncate, respectively. +

    +

    17.9.9 Comparisons

    + +

    For each SIMD data type X.Y, there exist conversion functions +X.Y<, X.Y<=, X.Y>, X.Y>=, and +X.Y= that check whether the supplied arguments are strictly +monotonically increasing, monotonically increasing, strictly monotonically +decreasing, monotonically decreasing, equal, or nowhere equal, +respectively. In contrast to the Common Lisp functions <, +<=, >, >=, =, and /= the SIMD +comparison functions don’t return a generalized boolean, but a SIMD pack of +unsigned integers with Y elements. The bits of each unsigned +integer are either all one, if the values of the arguments at that position +satisfy the test, or all zero, if they don’t. We call a SIMD packs of such +unsigned integers a mask. +

    +

    17.9.10 Conditionals

    + +

    The SIMD paradigm is inherently incompatible with fine-grained control +flow. A piece of code containing an if special form cannot be +vectorized in a straightforward way, because doing so would require as +many instruction pointers and processor states as there are values in +the desired SIMD data type. Instead, most SIMD instruction sets provide +an operator for selecting values from one of two supplied SIMD packs +based on a mask. The mask is a SIMD pack with as many elements as the +other two arguments, but whose elements are unsigned integers whose bits +must be either all zeros or all ones. This selection mechanism can be +used to emulate the effect of an if special form, at the price +that both operands have to be computed each time. +

    +

    In sb-simd, all conditional operations and comparisons emit +suitable mask fields, and there is a X.Y-if function for each +SIMD data type with element type X and number of elements +Y whose first arguments must be a suitable mask, whose second and +third argument must be objects that can be converted to the SIMD data +type X.Y, and that returns a value of type X.Y where each +element is from the second operand if the corresponding mask bits are +set, and from the third operand if the corresponding mask bits are not +set. +

    +

    17.9.11 Loads and Stores

    + +

    In practice, a SIMD pack X.Y is usually not constructed by +calling its constructor, but by loading Y consecutive elements +from a specialized array with element type X. The functions for +doing so are called X.Y-aref and X.Y-row-major-aref, and +have similar semantics as Common Lisp’s aref and +row-major-aref. In addition to that, some instruction sets +provide the functions X.Y-non-temporal-aref and +X.Y-non-temporal-row-major-aref, for accessing a memory location +without loading the referenced values into the CPU’s cache. +

    +

    For each function X.Y-foo for loading SIMD packs from an array, +there also exists a corresponding function (setf X.Y-foo) for +storing a SIMD pack in the specified memory location. An exception to +this rule is that some instruction sets (e.g., SSE) only provide +functions for non-temporal stores, but not for the corresponding +non-temporal loads. +

    +

    One difficulty when treating the data of a Common Lisp array as a SIMD +pack is that some hardware instructions require a particular alignment +of the address being referenced. Luckily, most architectures provide +instructions for unaligned loads and stores that are, at least on modern +CPUs, not slower than their aligned equivalents. So by default we +translate all array references as unaligned loads and stores. An +exception are the instructions for non-temporal loads and stores, that +always require a certain alignment. We do not handle this case +specially, so without special handling by the user, non-temporal loads +and stores will only work on certain array indices that depend on the +actual placement of that array in memory. +

    +

    17.9.12 Specialized Scalar Operations

    + +

    Finally, for each SIMD function X.Y-OP that applies a certain +operation OP element-wise to the Y elements of type +X, there exists also a functions X-OP for applying that +operation only to a single element. For example, the SIMD function +f64.4+ has a corresponding function f64+ that differs from +cl:+ in that it only accepts arguments of type double float, and +that it adds its supplied arguments in a fixed order that is the same as +the one used by f64.4. +

    +

    There are good reasons for exporting scalar functions from a SIMD +library, too. The most obvious one is that they obey the same naming +convention and hence make it easier to locate the correct functions. +Another benefit is that the semantics of each scalar operation is +precisely the same as that of the corresponding SIMD function, so they +can be used to write reference implementations for testing. A final +reason is that these scalar functions can be used to simplify the life +of tools for automatic vectorization. +

    +

    17.9.13 Instruction Set Dispatch

    + +

    One challenge that is unique to image-based programming systems such as +Lisp is that a program can run on one machine, be dumped as an image, +and then resumed on another machine. While nobody expects this feature +to work across machines with different architectures, it is quite likely +that the machine where the image is dumped and the one where execution +is resumed provide different instruction set extensions. +

    +

    As a practical example, consider a game developer that develops software +on an x86-64 machine with all SIMD extensions up to AVX2, but then dumps +it as an image and ships it to a customer whose machine only supports +SIMD extensions up to SSE2. Ideally, the image should contain multiple +optimized versions of all crucial functions, and dynamically select the +most appropriate version based on the instruction set extensions that +are actually available. +

    +

    This kind of run time instruction set dispatch is explicitly supported +by means of the instruction-set-case macro. The code resulting +from an invocation of this macro compiles to an efficient jump table +whose index is recomputed on each startup of the Lisp image. +

    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    18 Deprecation

    + +

    In order to support evolution of interfaces in SBCL as well as in user +code, SBCL allows declaring functions, variables and types as +deprecated. Users of deprecated things are notified by means of warnings +while the deprecated thing in question is still available. +

    +

    This chapter documents the interfaces for being notified when using +deprecated thing and declaring things as deprecated, the deprecation +process used for SBCL interfaces, and lists legacy interfaces in various +stages of deprecation. +

    +

    Deprecation in this context should not be confused with those +things the ANSI Common Lisp standard calls deprecated: the +entirety of ANSI CL is supported by SBCL, and none of those interfaces +are subject to censure. +

    + + + + + + + + +
    • Why Deprecate?   +
    • The Deprecation Pipeline   +
    • Deprecation Conditions   +
    • Introspecting Deprecation Information   +
    • Deprecation Declaration   +
    • Deprecation Examples   +
    • Deprecated Interfaces in SBCL   +
    + +
    +
    +

    +Next: , Up: Deprecation   [Contents][Index]

    +
    +

    18.1 Why Deprecate?

    + + +

    While generally speaking we try to keep SBCL changes as backwards +compatible as feasible, there are situations when existing interfaces +are deprecated: +

    +
      +
    • Broken Interfaces + +

      Sometimes it turns out that an interface is sufficiently misdesigned +that fixing it would be worse than deprecating it and replacing it +with another. +

      +

      This is typically the case when fixing the interface would change its +semantics in ways that could break user code subtly: in such cases we +may end up considering the obvious breakage caused by deprecation to +be preferable. +

      +

      Another example are functions or macros whose current signature makes +them hard or impossible to extend in the future: backwards compatible +extensions would either make the interface intolerably hairy, or are +sometimes outright impossible. +

      +
    • Internal Interfaces + +

      SBCL has several internal interfaces that were never meant to be used +in user code – or at least never meant to be used in user code +unwilling to track changes to SBCL internals. +

      +

      Ideally we’d like to be free to refactor our own internals as we +please, without even going through the hassle of deprecating things. +Sometimes, however, it turns out that our internal interfaces have +several external users who aren’t using them advisedly, but due to +misunderstandings regarding their status or stability. +

      +

      Consider a deprecated internal interface a reminder for SBCL +maintainers not to delete the thing just yet, even though it is seems +unused – because it has external users. +

      +

      When internal interfaces are deprecated we try our best to provide +supported alternatives. +

      +
    • Aesthetics & Ease of Maintenance + +

      Sometimes an interface isn’t broken or internal, but just inconsistent +somehow. +

      +

      This mostly happens only with historical interfaces inherited from +CMUCL which often haven’t been officially supported in SBCL before, or +with new extensions to SBCL that haven’t been around for very long in +the first place. +

      +

      The alternative would be to keep the suboptimal version around +forever, possibly alongside an improved version. Sometimes we may do +just that, but because every line of code comes with a maintenance +cost, sometimes we opt to deprecate the suboptimal version instead: +SBCL doesn’t have infinite developer resources. +

      +

      We also believe that sometimes cleaning out legacy interfaces helps +keep the whole system more comprehensible to users, and makes +introspective tools such as + +apropos more useful. +

      +
    + +
    +
    +

    +Next: , Previous: , Up: Deprecation   [Contents][Index]

    +
    +

    18.2 The Deprecation Pipeline

    + + +

    SBCL uses a deprecation pipeline with multiple stages: as time +goes by, deprecated things move from earlier stages of deprecation to +later stages before finally being removed. The intention is making users +aware of necessary changes early but allowing a migration to new +interfaces at a reasonable pace. +

    +

    Deprecation proceeds in three stages, each lasting approximately a +year. In some cases it might move slower or faster, but one year per +stage is what we aim at in general. During each stage warnings (and +errors) of increasing severity are signaled, which note that the +interface is deprecated, and point users towards any replacements when +applicable. +

    +
      +
    1. Early Deprecation + +

      During early deprecation the interface is kept in working +condition. However, when a thing in this deprecation stage is used, an + +sb-ext:early-deprecation-warning, which is a + +style-warning, is signaled at +compile-time. +

      +

      The internals may change at this stage: typically because the interface +is re-implemented on top of its successor. While we try to keep things +as backwards-compatible as feasible (taking maintenance costs into account), +sometimes semantics change slightly. +

      +

      For example, when the spinlock API was deprecated, spinlock objects ceased +to exist, and the whole spinlock API became a synonym for the mutex +API – so code using the spinlock API continued working, but silently +switched to mutexes instead. However, if someone relied on +

      +

      (typep lock 'spinlock) +

      +

      returning NIL for a mutexes, trouble could ensue. +

      +
    2. Late Deprecation + +

      During late deprecation the interface remains as it was during early +deprecation, but the compile-time warning is upgraded: when a thing in +this deprecation stage is used, a + +sb-ext:late-deprecation-warning, +which is a full + +warning, is signaled at compile-time. +

      +
    3. Final Deprecation + +

      During final deprecation the symbols still exist. However, when a thing +in this deprecation stage is used, a + +sb-ext:final-deprecation-warning, +which is a full + +warning, is signaled at compile-time and an + +error is signaled at run-time. +

      +
    4. After Final Deprecation + +

      The interface is deleted entirely. +

      +
    + +
    +
    +

    +Next: , Previous: , Up: Deprecation   [Contents][Index]

    +
    +

    18.3 Deprecation Conditions

    + + + +

    sb-ext:deprecation-condition is the superclass of all +deprecation-related warning and error conditions. All common slots and +readers are defined in this condition class. +

    +
    +
    Condition: deprecation-condition [sb-ext]
    +

    Class precedence list: deprecation-condition, condition, t +

    +

    Superclass for deprecation-related error and warning +conditions. +

    + +
    +
    Condition: early-deprecation-warning [sb-ext]
    +

    Class precedence list: early-deprecation-warning, style-warning, warning, deprecation-condition, condition, t +

    +

    This warning is signaled when the use of a variable, +function, type, etc. in :early deprecation is detected at +compile-time. The use will work at run-time with no warning or +error. +

    + +
    +
    Condition: late-deprecation-warning [sb-ext]
    +

    Class precedence list: late-deprecation-warning, warning, deprecation-condition, condition, t +

    +

    This warning is signaled when the use of a variable, +function, type, etc. in :late deprecation is detected at +compile-time. The use will work at run-time with no warning or +error. +

    + +
    +
    Condition: final-deprecation-warning [sb-ext]
    +

    Class precedence list: final-deprecation-warning, warning, deprecation-condition, condition, t +

    +

    This warning is signaled when the use of a variable, +function, type, etc. in :final deprecation is detected at +compile-time. An error will be signaled at run-time. +

    + +
    +
    Condition: deprecation-error [sb-ext]
    +

    Class precedence list: deprecation-error, error, serious-condition, deprecation-condition, condition, t +

    +

    This error is signaled at run-time when an attempt is made to use +a thing that is in :final deprecation, i.e. call a function or access +a variable. +

    + +
    +
    +

    +Next: , Previous: , Up: Deprecation   [Contents][Index]

    +
    +

    18.4 Introspecting Deprecation Information

    + + +

    The deprecation status of functions and variables can be inspected +using the sb-cltl2:function-information and +sb-cltl2:variable-information functions provided by the +sb-cltl2 contributed module. +

    +
    +
    +

    +Next: , Previous: , Up: Deprecation   [Contents][Index]

    +
    +

    18.5 Deprecation Declaration

    + + + +

    The sb-ext:deprecated declaration can be used to declare objects +in various namespaces11 as deprecated. +

    +
    +
    Declaration: deprecated [sb-ext]
    +
    +

    Syntax: +

    +
    sb-ext:deprecated stage since {object-clause}*
+
+stage ::= {:early | :late | :final}
+
+since ::= {version | (software version)}
+
+object-clause ::= (namespace name [:replacement replacement])
+
+namespace ::= {cl:variable | cl:function | cl:type}
+
    + +

    were name is the name of the deprecated thing, +version and software are strings describing the version in +which the thing has been deprecated and replacement is a name or a +list of names designating things that should be used instead of the +deprecated thing. +

    +

    Currently the following namespaces are supported: +

    +
    +
    cl:function
    +

    Declare functions, compiler-macros or macros as deprecated. +

    +
    +

    note: When declaring a function to be in :final deprecation, there +should be no actual definition of the function as the declaration emits +a stub function that signals a + +sb-ext:deprecation-error at run-time when called. +

    + +
    +
    cl:variable
    +

    Declare special and global variables, constants and symbol-macros as +deprecated. +

    +
    +

    note: When declaring a variable to be in :final deprecation, there +should be no actual definition of the variable as the declaration emits +a symbol-macro that signals a + +sb-ext:deprecation-error at run-time when accessed. +

    + +
    +
    cl:type
    +

    Declare named types (i.e. defined via deftype), standard classes, +structure classes and condition classes as deprecated. +

    +
    +
    +
    + +
    +
    +

    +Next: , Previous: , Up: Deprecation   [Contents][Index]

    +
    +

    18.6 Deprecation Examples

    + + +

    Marking functions as deprecated: +

    +
    (defun foo ())
+(defun bar ())
+(declaim (deprecated :early ("my-system" "1.2.3")
+                     (function foo :replacement bar)))
+
+;; Remember: do not define the actual function or variable in case of
+;; :final deprecation:
+(declaim (deprecated :final ("my-system" "1.2.3")
+                     (function fez :replacement whoop)))
+
    + +

    Attempting to use the deprecated functions: +

    +
    (defun baz ()
+  (foo))
+| STYLE-WARNING: The function CL-USER::FOO has been deprecated...
+=> BAZ
+(baz)
+=> NIL ; no error
+
+(defun danger ()
+  (fez))
+| WARNING: The function CL-USER::FEZ has been deprecated...
+=> DANGER
+(danger)
+|- ERROR: The function CL-USER::FEZ has been deprecated...
+
    + +
    +
    +

    +Previous: , Up: Deprecation   [Contents][Index]

    +
    +

    18.7 Deprecated Interfaces in SBCL

    + +

    This sections lists legacy interfaces in various stages of deprecation. +

    +

    18.7.1 List of Deprecated Interfaces

    + +

    18.7.1.1 Early Deprecation

    + + + +
      +
    • SOCKINT::WIN32-* + +

      Deprecated in favor of the corresponding prefix-less functions +(e.g. sockint::bind replaces sockint::win32-bind) as of +1.2.10 in March 2015. Expected to move into late deprecation in August +2015. +

      +
      +
    • SB-UNIX:UNIX-EXIT + +

      Deprecated as of 1.0.56.55 in May 2012. Expected to move into late +deprecation in May 2013. +

      +

      When the SBCL process termination was refactored as part of changes that +led to sb-ext:quit being deprecated, sb-unix:unix-exit +ceased to be used internally. Since SB-UNIX is an internal package +not intended for user code to use, and since we’re slowly in the process +of refactoring things to be less Unix-oriented, sb-unix:unix-exit +was initially deleted as it was no longer used. Unfortunately it became +apparent that it was used by several external users, so it was re-instated +in deprecated form. +

      +

      While the cost of keeping sb-unix:unix-exit indefinitely is +trivial, the ability to refactor our internals is important, so its +deprecation was taken as an opportunity to highlight that +SB-UNIX is an internal package and SB-POSIX should be +used by user-programs instead – or alternatively calling the foreign +function directly if the desired interface doesn’t for some reason +exist in SB-POSIX. +

      +

      Remedy +

      +

      For code needing to work with legacy SBCLs, use e.g. system-exit +as show above in remedies for sb-ext:quit. In modern SBCLs +simply call either sb-posix:exit or sb-ext:exit with +appropriate arguments. +

      +
      +
    • SB-C::MERGE-TAIL-CALLS Compiler Policy + +

      Deprecated as of 1.0.53.74 in November 2011. Expected to move into +late deprecation in November 2012. +

      +

      This compiler policy was never functional: SBCL has always merged tail +calls when it could, regardless of this policy setting. (It was also +never officially supported, but several code-bases have historically +used it.) +

      +

      Remedy +

      +

      Simply remove the policy declarations. They were never necessary: SBCL +always merged tail-calls when possible. To disable tail merging, +structure the code to avoid the tail position instead. +

      +
      +
    • Spinlock API + +

      Deprecated as of 1.0.53.11 in August 2011. Expected to move into late +deprecation in August 2012. +

      +

      Spinlocks were an internal interface, but had a number of external users +and were hence deprecated instead of being simply deleted. +

      +

      Affected symbols: sb-thread::spinlock, +sb-thread::make-spinlock, sb-thread::with-spinlock, +sb-thread::with-recursive-spinlock, +sb-thread::get-spinlock, sb-thread::release-spinlock, +sb-thread::spinlock-value, and sb-thread::spinlock-name. +

      +

      Remedy +

      +

      Use the mutex API instead, or implement spinlocks suiting your needs +on top of sb-ext:compare-and-swap, +sb-ext:spin-loop-hint, etc. +

      +
    • SOCKINT::HANDLE->FD, SOCKINT::FD->HANDLE + +

      Internally deprecated in 2012. Declared deprecated as of 1.2.10 in March +2015. Expected to move into final deprecation in August 2015. +

      +
    + +

    18.7.1.2 Late Deprecation

    + + + +
      +
    • SB-THREAD:JOIN-THREAD-ERROR-THREAD and SB-THREAD:INTERRUPT-THREAD-ERROR-THREAD + +

      Deprecated in favor of sb-thread:thread-error-thread as of +1.0.29.17 in June 2009. Expected to move into final deprecation in +June 2012. +

      +

      Remedy +

      +

      For code that needs to support legacy SBCLs, use e.g.: +

      +
      +
      +
      (defun get-thread-error-thread (condition)
+  #+#.(cl:if (cl:find-symbol "THREAD-ERROR-THREAD" :sb-thread)
+             '(and) '(or))
+  (sb-thread:thread-error-thread condition)
+  #-#.(cl:if (cl:find-symbol "THREAD-ERROR-THREAD" :sb-thread)
+             '(and) '(or))
+  (etypecase condition
+   (sb-thread:join-thread-error
+    (sb-thread:join-thread-error-thread condition))
+   (sb-thread:interrupt-thread-error
+    (sb-thread:interrupt-thread-error-thread condition))))
+
      +
      + +
      +
    • SB-INTROSPECT:FUNCTION-ARGLIST + +

      Deprecated in favor of sb-introspect:function-lambda-list as of +1.0.24.5 in January 2009. Expected to move into final deprecation in +January 2012. +

      +

      Renamed for consistency and aesthetics. Functions have lambda-lists, +not arglists. +

      +

      Remedy +

      +

      For code that needs to support legacy SBCLs, use e.g.: +

      +
      +
      +
      (defun get-function-lambda-list (function)
+  #+#.(cl:if (cl:find-symbol "FUNCTION-LAMBDA-LIST" :sb-introspect)
+             '(and) '(or))
+  (sb-introspect:function-lambda-list function)
+  #-#.(cl:if (cl:find-symbol "FUNCTION-LAMBDA-LIST" :sb-introspect)
+             '(and) '(or))
+  (sb-introspect:function-arglist function))
+
      +
      + +
      +
    • Stack Allocation Policies + +

      Deprecated in favor of sb-ext:*stack-allocate-dynamic-extent* +as of 1.0.19.7 in August 2008, and are expected to be removed in +August 2012. +

      +

      Affected symbols: sb-c::stack-allocate-dynamic-extent, +sb-c::stack-allocate-vector, and +sb-c::stack-allocate-value-cells. +

      +

      These compiler policies were never officially supported, and turned +out the be a flawed design. +

      +

      Remedy +

      +

      For code that needs stack-allocation in legacy SBCLs, conditionalize +using: +

      +
      +
      +
      #-#.(cl:if (cl:find-symbol "*STACK-ALLOCATE-DYNAMIC-EXTENT*" :sb-ext)
+           '(and) '(or))
+(declare (optimize sb-c::stack-allocate-dynamic-extent))
+
      +
      + +

      However, unless stack allocation is essential, we recommend simply +removing these declarations. Refer to documentation on +sb-ext:*stack-allocate-dynamic* for details on stack allocation +control in modern SBCLs. +

      +
      +
    • SB-SYS:OUTPUT-RAW-BYTES + +

      Deprecated as of 1.0.8.16 in June 2007. Expected to move into final +deprecation in June 2012. +

      +

      Internal interface with some external users. Never officially +supported, deemed unnecessary in presence of write-sequence and +bivalent streams. +

      +

      Remedy +

      +

      Use streams with element-type (unsigned-byte 8) +or :default – the latter allowing both binary and +character IO – in conjunction with write-sequence. +

      +
    + +

    18.7.1.3 Final Deprecation

    + + + +

    No interfaces are currently in final deprecation. +

    +

    18.7.2 Historical Interfaces

    + +

    The following is a partial list of interfaces present in historical +versions of SBCL, which have since then been deleted. +

    +
      +
    • SB-KERNEL:INSTANCE-LAMBDA + +

      Historically needed for CLOS code. Deprecated as of 0.9.3.32 in August +2005. Deleted as of 1.0.47.8 in April 2011. Plain lambda can be +used where sb-kernel:instance-lambda used to be needed. +

      +
      +
    • SB-ALIEN:DEF-ALIEN-ROUTINE, SB-ALIEN:DEF-ALIEN-VARIABLE, SB-ALIEN:DEF-ALIEN-TYPE + +

      Inherited from CMUCL, naming convention not consistent with preferred +SBCL style. Deprecated as of 0.pre7.90 in December 2001. Deleted as of +1.0.9.17 in September 2007. Replaced by +sb-alien:define-alien-routine, +sb-alien:define-alien-variable, and +sb-alien:define-alien-type. +

      +
    +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    Appendix A Concept Index

    + +
    Jump to:   A +   +B +   +C +   +D +   +E +   +F +   +G +   +H +   +I +   +L +   +M +   +N +   +O +   +P +   +Q +   +R +   +S +   +T +   +U +   +V +   +W +   +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Index Entry  Section
    A
    Actual Source: The Parts of a Compiler Diagnostic
    Actual Source: The Original and Actual Source
    Arithmetic, hardware: Modular arithmetic
    Arithmetic, hardware: sb-rotate-byte
    Arithmetic, modular: Modular arithmetic
    Arithmetic, modular: sb-rotate-byte
    Asynchronous Timeout: Asynchronous Timeouts
    Availability of debug variables: Variable Value Availability
    B
    Block compilation, debugger implications: Entry Point Details
    Block, basic: Source Location Availability
    Block, start location: Source Location Availability
    C
    Character Coding Conditions: Character Coding Conditions
    Character Names: Unicode Support
    Cleanup, stack frame kind: Entry Point Details
    Code Coverage: sb-cover
    Compatibility with other Lisps: Getting Existing Programs to Run
    Compile time type errors: Type Errors at Compile Time
    Compiler Diagnostic Severity: Diagnostic Severity
    Compiler messages: Diagnostic Messages
    Concurrency: sb-concurrency
    Converting between Strings and Octet Vectors: Converting between Strings and Octet Vectors
    D
    Deadline: Synchronous Timeouts (Deadlines)
    Debug optimization quality: Variable Value Availability
    Debug optimization quality: Source Location Availability
    Debug optimization quality: Debugger Policy Control
    Debug variables: Variable Access
    Debugger: Debugger
    debugger, disabling: Enabling and Disabling the Debugger
    debugger, enabling: Enabling and Disabling the Debugger
    Decimal Syntax for Rationals: Reader Extensions
    declaration, dynamic-extent: Dynamic-extent allocation
    Declaration, freeze-type: Efficiency Hacks
    Declarations: Package Lock Violations
    Deprecation Conditions: Deprecation Conditions
    Deprecation Declaration: Deprecation Declaration
    Deprecation Examples: Deprecation Examples
    disabling debugger: Enabling and Disabling the Debugger
    disabling ldb: Runtime Options
    disabling ldb: Enabling and Disabling the Debugger
    dynamic-extent declaration: Dynamic-extent allocation
    E
    Efficiency: Efficiency
    Entry points, external: Entry Point Details
    Errors, run-time: Unknown Locations and Interrupts
    Existing programs, to run: Getting Existing Programs to Run
    Extended Package Prefix Syntax: Reader Extensions
    External entry points: Entry Point Details
    External Format Designators: External Format Designators
    External formats: Foreign Type Specifiers
    External, stack frame kind: Entry Point Details
    F
    Fast Read Lock: sb-concurrency
    Finalization: Garbage Collection
    Foreign Function Interface, generation: sb-grovel
    freeze-type declaration: Efficiency Hacks
    Frlock: sb-concurrency
    Function, tracing: Function Tracing
    G
    Garbage collection: Garbage Collection
    Garbage Collection, conservative: History and Implementation of SBCL
    Garbage Collection, generational: History and Implementation of SBCL
    Gate: sb-concurrency
    H
    Hash tables: Hash Table Extensions
    Hashing, cryptographic: sb-md5
    I
    Inline expansion: Open Coding and Inline Expansion
    Inline expansion: Debugger Policy Control
    Interning Symbols: Reader Extensions
    Interpreter: Interpreter
    Interrupts: Unknown Locations and Interrupts
    Introspecting Deprecation Information: Introspecting Deprecation Information
    L
    ldb: Reporting Bugs
    ldb: Runtime Options
    ldb: Runtime Options
    ldb, disabling: Runtime Options
    ldb, disabling: Enabling and Disabling the Debugger
    ldb, enabling: Enabling and Disabling the Debugger
    Locations, unknown: Unknown Locations and Interrupts
    Logical pathnames: Lisp Pathnames
    M
    Macroexpansion: The Processing Path
    Macroexpansion, errors during: Errors During Macroexpansion
    Mailbox, lock-free: sb-concurrency
    Messages, Compiler: Diagnostic Messages
    Modular arithmetic: Modular arithmetic
    Modular arithmetic: sb-rotate-byte
    N
    Name, of character: Unicode Support
    NFKC: Reader Extensions
    Nicknames, Package-local: Package-Local Nicknames
    Normalization, String: Unicode Support
    Normalization, Symbol Name: Reader Extensions
    O
    Open-coding: Open Coding and Inline Expansion
    Operating System Interface: sb-posix
    optimization quality, safety: Dynamic-extent allocation
    Optimize declaration: Debugger Policy Control
    Optional, stack frame kind: Entry Point Details
    Original Source: The Parts of a Compiler Diagnostic
    Original Source: The Original and Actual Source
    P
    Package Locks: Reader Extensions
    Package Prefix Syntax, extended: Reader Extensions
    Package-Local Nicknames: Package-Local Nicknames
    Packages, locked: Package Locks
    Pathnames: Pathnames
    Pathnames, logical: Lisp Pathnames
    Policy, debugger: Debugger Policy Control
    Posix: sb-posix
    Precise type checking: Precise Type Checking
    Processing Path: The Parts of a Compiler Diagnostic
    Processing Path: The Processing Path
    Profiling: Profiling
    Profiling, deterministic: Deterministic Profiler
    Profiling, statistical: Statistical Profiler
    Q
    Queue, FIFO: sb-queue
    Queue, lock-free: sb-concurrency
    R
    Random Number Generation: Random Number Generation
    Rational, decimal syntax for: Reader Extensions
    Read errors, compiler: Read Errors
    Read-Eval-Print Loop: sb-aclrepl
    Reader Extensions: Reader Extensions
    Recursion, tail: Debug Tail Recursion
    REPL: sb-aclrepl
    S
    Safety optimization quality: Declarations as Assertions
    Safety optimization quality: Dynamic-extent allocation
    safety optimization quality: Dynamic-extent allocation
    Sb-concurrency: sb-concurrency
    Semi-inline expansion: Debugger Policy Control
    Severity of compiler messages: Diagnostic Severity
    SIMD: sb-simd
    Single Stepping: Single Stepping
    Slot access: Slot access
    Sockets, Networking: Networking
    Source location printing, debugger: Source Location Printing
    Source-to-source transformation: The Processing Path
    Stack frames: Stack Frames
    Static functions: Open Coding and Inline Expansion
    Stepper: Single Stepping
    Stream External formats: Stream External Formats
    Supported External Formats: Supported External Formats
    Symbol Name Normalization: Reader Extensions
    Symbols, interning: Reader Extensions
    Synchronous Timeout: Synchronous Timeouts (Deadlines)
    System Calls: sb-posix
    T
    Tail recursion: Debug Tail Recursion
    The Default External Format: The Default External Format
    The Deprecation Pipeline: The Deprecation Pipeline
    Timeout: Timeout Parameters
    Timeout: Synchronous Timeouts (Deadlines)
    Timeout: Asynchronous Timeouts
    Tracing: Function Tracing
    Type checking, at compile time: Type Errors at Compile Time
    Type checking, precise: Precise Type Checking
    Types, portability: Getting Existing Programs to Run
    U
    Unbound slots: Slot Access
    Unbound slots: Slot Access
    Unbound slots: Metaobject Protocol
    Unicode: Reader Extensions
    Unicode: Unicode Support
    Unknown code locations: Unknown Locations and Interrupts
    V
    Validity of debug variables: Variable Value Availability
    Variables, debugger access: Variable Access
    W
    Weak pointers: Garbage Collection
    Why Deprecate?: Why Deprecate?
    +
    Jump to:   A +   +B +   +C +   +D +   +E +   +F +   +G +   +H +   +I +   +L +   +M +   +N +   +O +   +P +   +Q +   +R +   +S +   +T +   +U +   +V +   +W +   +
    + +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    Appendix B Function Index

    + +
    Jump to:   ( +   +? +   +
    +A +   +B +   +C +   +D +   +E +   +F +   +G +   +H +   +I +   +J +   +L +   +M +   +N +   +O +   +P +   +Q +   +R +   +S +   +T +   +U +   +V +   +W +   +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Index Entry  Section
    (
    (setf: Extensible Sequences
    (setf: Simple Iterator Protocol
    (setf logical-pathname-translations [cl]): Lisp Pathnames
    (setf slot-value [cl]): Slot Access
    (setf slot-value [cl]): Slot Access
    (setf slot-value-using-class [sb-mop]): Metaobject Protocol
    (setf slot-value-using-class [sb-mop]): Metaobject Protocol
    ?
    ?: Information Commands
    A
    abort: Exiting Commands
    abort-thread: Threading basics
    add-implementation-package: Package Lock Dictionary
    add-package-local-nickname: Package-Local Nicknames
    addr: Coercing Foreign Values
    adjust-sequence: Extensible Sequences
    adjust-sequence [sb-sequence]: Extensible Sequences
    age: Unicode Support
    alien-callable-function: Calling Lisp From C
    alien-funcall: The alien-funcall Primitive
    alien-sap: Coercing Foreign Values
    alphabetic-p: Unicode Support
    always-bound: Global and Always-Bound variables
    apropos [cl]: Why Deprecate?
    array-storage-vector: Miscellaneous Extensions
    assert-version->=: Miscellaneous Extensions
    atomic-decf: Atomic Operations
    atomic-incf: Atomic Operations
    atomic-pop: Atomic Operations
    atomic-push: Atomic Operations
    atomic-update: Atomic Operations
    B
    backtrace: Information Commands
    barrier: Barriers
    bidi-class: Unicode Support
    bidi-mirroring-glyph: Unicode Support
    both-case-p [cl]: Unicode Support
    bottom: Stack Motion
    bytes-consed-between-gcs: Garbage Collection
    C
    cancel-finalization: Garbage Collection
    cas: Atomic Operations
    case-ignorable-p: Unicode Support
    cased-p: Unicode Support
    casefold: Unicode Support
    cast: Coercing Foreign Values
    change-class [cl]: Metaobject Protocol
    char-block: Unicode Support
    char-downcase [cl]: Unicode Support
    char-name [cl]: Unicode Support
    class-name [cl]: Metaobject Protocol
    class-of [cl]: Metaobject Protocol
    class-prototype [sb-mop]: Metaobject Protocol
    clear-coverage: sb-cover
    clear-semaphore-notification: Semaphores
    close: Methods common to all streams
    close-gate: sb-concurrency
    coerce [cl]: Extensible Sequences
    combining-class: Unicode Support
    compare-and-swap: Atomic Operations
    compute-effective-method [sb-mop]: Metaobject Protocol
    concatenate: Extensible Sequences
    condition-broadcast: Waitqueue/condition variables
    condition-notify: Waitqueue/condition variables
    condition-wait: Waitqueue/condition variables
    confusable-p: Unicode Support
    cons [cl]: Dynamic-extent allocation
    continue: Exiting Commands
    copy function: Iterator Protocol
    copy-seq [cl]: Extensible Sequences
    D
    decimal-value: Unicode Support
    declare [cl]: Package Lock Violations
    default-ignorable-p: Unicode Support
    defclass [cl]: Metaobject Protocol
    defclass [cl]: Metaobject Protocol
    defclass [cl]: Metaobject Protocol
    defconstant [cl]: Defining Constants
    defglobal: Global and Always-Bound variables
    define-alien-callable: Calling Lisp From C
    define-alien-routine: The define-alien-routine Macro
    define-alien-variable: External Foreign Variables
    define-hash-table-test: Hash Table Extensions
    defmethod [cl]: Metaobject Protocol
    defpackage: Package-Local Nicknames
    defpackage: Package Lock Dictionary
    defpackage [cl]: Package-Local Nicknames
    defpackage [cl]: Implementation Packages
    defstruct [cl]: Slot Access
    defstruct [cl]: Metaobject Protocol
    delete-directory: Miscellaneous Extensions
    deprecated: Deprecation Declaration
    deprecated [sb-ext]: Deprecation Declaration
    dequeue: sb-concurrency
    deref: Accessing Foreign Values
    describe: Information Commands
    describe-compiler-policy: Compiler Policy
    digit-value: Unicode Support
    disable-debugger: Enabling and Disabling the Debugger
    disable-package-locks: Package Lock Dictionary
    disable-package-locks [sb-ext]: Package Lock Violations
    dolist [cl]: Extensible Sequences
    dosequence: Extensible Sequences
    down: Stack Motion
    dynamic-space-size: Garbage Collection
    E
    east-asian-width: Unicode Support
    ed: Customization Hooks for Users
    element function: Iterator Protocol
    elt: Extensible Sequences
    emptyp: Extensible Sequences
    enable-debugger: Enabling and Disabling the Debugger
    enable-package-locks: Package Lock Dictionary
    enable-package-locks [sb-ext]: Package Lock Violations
    endp function: Iterator Protocol
    enqueue: sb-concurrency
    ensure-class [sb-mop]: Metaobject Protocol
    ensure-class [sb-mop]: Metaobject Protocol
    ensure-class-using-class [sb-mop]: Metaobject Protocol
    ensure-class-using-class [sb-mop]: Metaobject Protocol
    ensure-generic-function [cl]: Metaobject Protocol
    error: Information Commands
    eval [cl]: Interpreter
    exit: Exit
    expt [cl]: Random Number Generation
    extern-alien: External Foreign Variables
    F
    file-descriptor: File-descriptors
    filename: Filenames
    finalize: Garbage Collection
    finalize-inheritance [sb-mop]: Metaobject Protocol
    find [cl]: Extensible Sequences
    find-class [cl]: Metaobject Protocol
    find-class [cl]: Metaobject Protocol
    find-method [cl]: Metaobject Protocol
    find-package [cl]: Package-Local Nicknames
    find-symbol [cl]: Package-Local Nicknames
    flet [cl]: Dynamic-extent allocation
    flet [cl]: Package Lock Violations
    float-denormalized-p [sb-ext]: Stale Extensions
    frame: Stack Motion
    free-alien: Foreign Dynamic Allocation
    frlock-name: sb-concurrency
    frlock-read: sb-concurrency
    frlock-read-begin: sb-concurrency
    frlock-read-end: sb-concurrency
    frlock-write: sb-concurrency
    funcallable-standard-instance-access [sb-mop]: Metaobject Protocol
    G
    gate-name: sb-concurrency
    gate-open-p: sb-concurrency
    gatep: sb-concurrency
    gc: Garbage Collection
    gc-logfile: Garbage Collection
    general-category: Unicode Support
    generation-average-age: Garbage Collection
    generation-bytes-allocated: Garbage Collection
    generation-bytes-consed-between-gcs: Garbage Collection
    generation-minimum-age-before-gc: Garbage Collection
    generation-number-of-gcs: Garbage Collection
    generation-number-of-gcs-before-promotion: Garbage Collection
    generic-function-declarations [sb-mop]: Metaobject Protocol
    get-bytes-consed: Garbage Collection
    get-errno: External Foreign Variables
    get-host-by-address: Name Service
    get-host-by-name: Name Service
    get-protocol-by-name: INET Domain Sockets
    get-time-of-day: Miscellaneous Extensions
    getcwd: Functions with idiosyncratic bindings
    global: Global and Always-Bound variables
    grab-frlock-write-lock: sb-concurrency
    grab-mutex: Mutex Support
    grapheme-break-class: Unicode Support
    graphemes: Unicode Support
    H
    hangul-syllable-type: Unicode Support
    hash-table-synchronized-p: Hash Table Extensions
    hash-table-weakness: Hash Table Extensions
    help: Information Commands
    hex-digit-p: Unicode Support
    host-ent-address: Name Service
    I
    ideographic-p: Unicode Support
    index function: Iterator Protocol
    inspect [cl]: Tools To Help Developers
    int-sap: Accessing Foreign Values
    intern [cl]: Reader Extensions
    intern [cl]: Reader Extensions
    intern-eql-specializer [sb-mop]: Metaobject Protocol
    interrupt-thread: Threading basics
    iterator-copy: Simple Iterator Protocol
    iterator-element: Simple Iterator Protocol
    iterator-endp: Simple Iterator Protocol
    iterator-index: Simple Iterator Protocol
    iterator-step: Simple Iterator Protocol
    J
    join-thread: Threading basics
    join-thread [sb-thread]: Timeout Parameters
    L
    labels [cl]: Dynamic-extent allocation
    labels [cl]: Package Lock Violations
    length: Extensible Sequences
    let [cl]: Miscellaneous Efficiency Issues
    let [cl]: Package Lock Violations
    let* [cl]: Miscellaneous Efficiency Issues
    let* [cl]: Package Lock Violations
    line-break-class: Unicode Support
    lines: Unicode Support
    list [cl]: Dynamic-extent allocation
    list* [cl]: Dynamic-extent allocation
    list-all-threads: Threading basics
    list-all-timers: Timers
    list-locals: Variable Access
    list-mailbox-messages: sb-concurrency
    list-queue-contents: sb-concurrency
    load-shared-object: Loading Shared Object Files
    lock-package: Package Lock Dictionary
    logand [cl]: Modular arithmetic
    logical-pathname-translations [cl]: Lisp Pathnames
    lowercase: Unicode Support
    lowercase-p: Unicode Support
    M
    macrolet [cl]: Package Lock Violations
    mailbox-count: sb-concurrency
    mailbox-empty-p: sb-concurrency
    mailbox-name: sb-concurrency
    mailboxp: sb-concurrency
    main-thread: Threading basics
    main-thread-p: Threading basics
    make-alien: Foreign Dynamic Allocation
    make-alien-string: Foreign Dynamic Allocation
    make-array [cl]: Dynamic-extent allocation
    make-frlock: sb-concurrency
    make-gate: sb-concurrency
    make-hash-table: Hash Table Extensions
    make-inet-address: INET Domain Sockets
    make-inet6-address: INET Domain Sockets
    make-instance [cl]: Extensible Sequences
    make-mailbox: sb-concurrency
    make-method-lambda [sb-mop]: Metaobject Protocol
    make-method-specializers-form [sb-pcl]: Metaobject Protocol
    make-mutex: Mutex Support
    make-queue: sb-concurrency
    make-random-state [cl]: Random Number Generation
    make-semaphore: Semaphores
    make-semaphore-notification: Semaphores
    make-sequence-iterator: Iterator Protocol
    make-sequence-iterator [sb-sequence]: Iterator Protocol
    make-sequence-iterator [sb-sequence]: Iterator Protocol
    make-sequence-like: Extensible Sequences
    make-sequence-like [sb-sequence]: Extensible Sequences
    make-simple-sequence-iterator: Simple Iterator Protocol
    make-simple-sequence-iterator [sb-sequence]: Iterator Protocol
    make-thread: Threading basics
    make-timer: Timers
    make-waitqueue: Waitqueue/condition variables
    make-weak-pointer: Garbage Collection
    map: Extensible Sequences
    map-traces: Statistical Profiler
    math-p: Unicode Support
    md5sum-file: sb-md5
    md5sum-sequence: sb-md5
    md5sum-stream: sb-md5
    md5sum-string: sb-md5
    merge: Extensible Sequences
    mirrored-p: Unicode Support
    muffle-conditions: Controlling Verbosity
    mutex-name: Mutex Support
    mutex-owner: Mutex Support
    mutex-value: Mutex Support
    N
    name-char [cl]: Unicode Support
    name-conflict-symbols [sb-ext]: Resolution of Name Conflicts
    native-namestring: Native Filenames
    native-pathname: Native Filenames
    next: Single Stepping
    non-blocking-mode: General Sockets
    normalize-string: Unicode Support
    normalized-p: Unicode Support
    numeric-value: Unicode Support
    O
    octets-to-string: Converting between Strings and Octet Vectors
    open [cl]: External Format Designators
    open [cl]: Stream External Formats
    open-gate: sb-concurrency
    out: Single Stepping
    P
    package-implemented-by-list: Package Lock Dictionary
    package-implements-list: Package Lock Dictionary
    package-local-nicknames: Package-Local Nicknames
    package-locally-nicknamed-by-list: Package-Local Nicknames
    package-locked-error-symbol: Package Lock Dictionary
    package-locked-p: Package Lock Dictionary
    parse-native-namestring: Native Filenames
    parse-specializer-using-class [sb-pcl]: Metaobject Protocol
    posix-getenv: Querying the process environment
    print: Information Commands
    process-alive-p: Running external programs
    process-close: Running external programs
    process-core-dumped: Running external programs
    process-error: Running external programs
    process-exit-code: Running external programs
    process-input: Running external programs
    process-kill: Running external programs
    process-output: Running external programs
    process-p: Running external programs
    process-status: Running external programs
    process-wait: Running external programs
    profile: Deterministic Profiler
    profile-call-counts: Statistical Profiler
    prog2 [cl]: Exceptions to ANSI Conformance
    proplist-p: Unicode Support
    purify [sb-ext]: Efficiency Hacks
    Q
    queue-count: sb-concurrency
    queue-empty-p: sb-concurrency
    queue-name: sb-concurrency
    queuep: sb-concurrency
    R
    random [cl]: Random Number Generation
    random [cl]: Random Number Generation
    read [cl]: Reader Extensions
    read-from-string [cl]: Reader Extensions
    read-line [cl]: Synchronous Timeouts (Deadlines)
    readlink: Functions with idiosyncratic bindings
    readtable-normalization: Reader Extensions
    receive-message: sb-concurrency
    receive-message-no-hang: sb-concurrency
    receive-pending-messages: sb-concurrency
    release-frlock-write-lock: sb-concurrency
    release-mutex: Mutex Support
    remove-implementation-package: Package Lock Dictionary
    remove-package-local-nickname: Package-Local Nicknames
    report: Deterministic Profiler
    report: Statistical Profiler
    report: sb-cover
    require: Customization Hooks for Users
    reset: Deterministic Profiler
    reset: Statistical Profiler
    reset-coverage: sb-cover
    restart: Exiting Commands
    restart-frame: Exiting Commands
    restore-coverage: sb-cover
    restore-coverage-from-file: sb-cover
    restrict-compiler-policy: Compiler Policy
    return: Exiting Commands
    return-from-thread: Threading basics
    rotate-byte: sb-rotate-byte
    rotate-byte [sb-rotate-byte]: sb-md5
    run-program: Running external programs
    run-program [sb-ext]: Synchronous Timeouts (Deadlines)
    S
    sample-pc: Statistical Profiler
    sap-alien: Coercing Foreign Values
    sap-ref-32: Accessing Foreign Values
    sap=: Accessing Foreign Values
    satisfies [cl]: Handling of Types
    save-coverage: sb-cover
    save-coverage-in-file: sb-cover
    save-lisp-and-die: Saving a Core Image
    schedule-timer: Timers
    script: Unicode Support
    search-roots: Garbage Collection
    seed-random-state: Random Number Generation
    semaphore-count: Semaphores
    semaphore-name: Semaphores
    semaphore-notification-status: Semaphores
    send-message: sb-concurrency
    sentence-break-class: Unicode Support
    sentences: Unicode Support
    set-sbcl-source-location: Lisp Pathnames
    setf element function: Iterator Protocol
    setf [cl]: Miscellaneous Efficiency Issues
    setq [cl]: Miscellaneous Efficiency Issues
    signal-semaphore: Semaphores
    sleep [cl]: Timeouts and Deadlines
    sleep [cl]: Synchronous Timeouts (Deadlines)
    slot: Accessing Foreign Values
    slot-boundp [cl]: Slot Access
    slot-boundp [cl]: Slot Access
    slot-boundp-using-class [sb-mop]: Metaobject Protocol
    slot-boundp-using-class [sb-mop]: Metaobject Protocol
    slot-definition-allocation [sb-mop]: Metaobject Protocol
    slot-definition-name [sb-mop]: Metaobject Protocol
    slot-makunbound [cl]: Slot Access
    slot-makunbound [cl]: Slot Access
    slot-missing [cl]: Slot Access
    slot-unbound [cl]: Slot Access
    slot-value [cl]: Slot Access
    slot-value [cl]: Slot Access
    slot-value-using-class [sb-mop]: Metaobject Protocol
    slot-value-using-class [sb-mop]: Metaobject Protocol
    socket-accept: General Sockets
    socket-bind: General Sockets
    socket-close: General Sockets
    socket-connect: General Sockets
    socket-error: General Sockets
    socket-listen: General Sockets
    socket-make-stream: General Sockets
    socket-make-stream: General Sockets
    socket-name: General Sockets
    socket-open-p: General Sockets
    socket-peername: General Sockets
    socket-receive: General Sockets
    socket-send: General Sockets
    socket-shutdown: General Sockets
    sockopt-broadcast: Socket Options
    sockopt-bsd-compatible: Socket Options
    sockopt-debug: Socket Options
    sockopt-dont-route: Socket Options
    sockopt-keep-alive: Socket Options
    sockopt-oob-inline: Socket Options
    sockopt-pass-credentials: Socket Options
    sockopt-reuse-address: Socket Options
    sockopt-tcp-nodelay: Socket Options
    soft-dotted-p: Unicode Support
    source: Source Location Printing
    standard-instance-access [sb-mop]: Metaobject Protocol
    start: Single Stepping
    start-profiling: Statistical Profiler
    step: Single Stepping
    step: Single Stepping
    step function: Iterator Protocol
    stop: Single Stepping
    stop-profiling: Statistical Profiler
    stream-advance-to-column: Character output stream methods
    stream-clear-input: Input stream methods
    stream-clear-output: Output stream methods
    stream-element-type: Methods common to all streams
    stream-external-format [cl]: Stream External Formats
    stream-file-position: Methods common to all streams
    stream-finish-output: Output stream methods
    stream-force-output: Output stream methods
    stream-fresh-line: Character output stream methods
    stream-line-column: Character output stream methods
    stream-line-length: Character output stream methods
    stream-listen: Character input stream methods
    stream-peek-char: Character input stream methods
    stream-read-byte: Binary stream methods
    stream-read-char: Character input stream methods
    stream-read-char-no-hang: Character input stream methods
    stream-read-line: Character input stream methods
    stream-read-sequence: Input stream methods
    stream-start-line-p: Character output stream methods
    stream-terpri: Character output stream methods
    stream-unread-char: Character input stream methods
    stream-write-byte: Binary stream methods
    stream-write-char: Character output stream methods
    stream-write-sequence: Output stream methods
    stream-write-string: Character output stream methods
    string-to-octets: Converting between Strings and Octet Vectors
    string-upcase [cl]: Unicode Support
    subseq [cl]: Extensible Sequences
    subseq [cl]: Extensible Sequences
    subseq [cl]: Extensible Sequences
    subtypep [cl]: Metaobject Protocol
    symbol-macrolet [cl]: Package Lock Violations
    symbol-value-in-thread: Threading basics
    syslog: Functions with idiosyncratic bindings
    T
    terminate-thread: Threading basics
    thread-alive-p: Threading basics
    thread-error-thread: Threading basics
    thread-name: Threading basics
    thread-yield: Threading basics
    timer-name: Timers
    timer-scheduled-p: Timers
    titlecase: Unicode Support
    top: Stack Motion
    toplevel: Exiting Commands
    trace: Function Tracing
    trace [cl]: Tools To Help Developers
    truly-the: Efficiency Hacks
    try-semaphore: Semaphores
    typep [cl]: Metaobject Protocol
    U
    unicode-1-name: Unicode Support
    unicode-equal: Unicode Support
    unicode<: Unicode Support
    unicode<=: Unicode Support
    unicode=: Unicode Support
    unicode>: Unicode Support
    unicode>=: Unicode Support
    unload-shared-object: Loading Shared Object Files
    unlock-package: Package Lock Dictionary
    unmuffle-conditions: Controlling Verbosity
    unparse-specializer-using-class [sb-pcl]: Metaobject Protocol
    unprofile: Deterministic Profiler
    unprofile-call-counts: Statistical Profiler
    unschedule-timer: Timers
    untrace: Function Tracing
    up: Stack Motion
    uppercase: Unicode Support
    uppercase-p: Unicode Support
    V
    validate-superclass [sb-mop]: Metaobject Protocol
    validate-superclass [sb-mop]: Metaobject Protocol
    var: Variable Access
    vector [cl]: Dynamic-extent allocation
    W
    wait-for: Timeout Parameters
    wait-on-gate: sb-concurrency
    wait-on-semaphore: Semaphores
    waitqueue-name: Waitqueue/condition variables
    weak-pointer-value: Garbage Collection
    whitespace-p: Unicode Support
    with-alien: Local Foreign Variables
    with-compilation-unit: Compiler Policy
    with-compilation-unit [cl]: The Parts of a Compiler Diagnostic
    with-deadline: Synchronous Timeouts (Deadlines)
    with-locked-hash-table: Hash Table Extensions
    with-mutex: Mutex Support
    with-open-file [cl]: External Format Designators
    with-open-file [cl]: Stream External Formats
    with-profiling: Statistical Profiler
    with-recursive-lock: Mutex Support
    with-sampling: Statistical Profiler
    with-sequence-iterator: Iterator Protocol
    with-sequence-iterator-functions: Iterator Protocol
    with-timeout: Asynchronous Timeouts
    with-unlocked-packages: Package Lock Dictionary
    without-package-locks: Package Lock Dictionary
    word-break-class: Unicode Support
    words: Unicode Support
    +
    Jump to:   ( +   +? +   +
    +A +   +B +   +C +   +D +   +E +   +F +   +G +   +H +   +I +   +J +   +L +   +M +   +N +   +O +   +P +   +Q +   +R +   +S +   +T +   +U +   +V +   +W +   +
    + +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    Appendix C Variable Index

    + +
    Jump to:   * +   ++ +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Index Entry  Section
    *
    *after-gc-hooks*: Garbage Collection
    *command-char*: sb-aclrepl
    *compiler-print-variable-alist*: Controlling Verbosity
    *core-pathname*: Saving a Core Image
    *current-thread*: Threading basics
    *debug-print-variable-alist*: Debugger Command Loop
    *ed-functions*: Customization Hooks for Users
    *evaluator-mode*: Interpreter
    *evaluator-mode* [sb-ext]: Interpreter
    *exit-hooks*: Initialization and Exit Hooks
    *exit-on-eof*: sb-aclrepl
    *features* [cl]: Package-Local Nicknames
    *gc-run-time*: Garbage Collection
    *init-hooks*: Initialization and Exit Hooks
    *invoke-debugger-hook*: Debugger Invocation
    *max-history*: sb-aclrepl
    *max-samples*: Statistical Profiler
    *max-trace-indentation*: Function Tracing
    *module-provider-functions*: Customization Hooks for Users
    *muffled-warnings*: Customization Hooks for Users
    *on-package-variance*: Package Variance
    *package* [cl]: Reader Extensions
    *package* [cl]: Reader Extensions
    *package* [cl]: Package-Local Nicknames
    *package* [cl]: Implementation Packages
    *posix-argv* [sb-ext]: Shebang Scripts
    *posix-argv* [sb-ext]: Command-line arguments
    *prompt*: sb-aclrepl
    *random-state* [cl]: Random Number Generation
    *read-default-float-format* [cl]: Reader Extensions
    *read-default-float-format* [cl]: Reader Extensions
    *sample-interval*: Statistical Profiler
    *save-hooks*: Saving a Core Image
    *stack-allocate-dynamic-extent*: Dynamic-extent allocation
    *sysinit-pathname-function*: Saving a Core Image
    *trace-encapsulate-default*: Function Tracing
    *trace-indentation-step*: Function Tracing
    *trace-report-default*: Function Tracing
    *use-short-package-name*: sb-aclrepl
    *userinit-pathname-function*: Saving a Core Image
    +
    +slot-unbound+ [sb-pcl]: Metaobject Protocol
    +
    Jump to:   * +   ++ +
    + +
    +
    +

    +Next: , Previous: , Up: Top   [Contents][Index]

    +
    +

    Appendix D Type Index

    + +
    Jump to:   B +   +C +   +D +   +E +   +F +   +G +   +H +   +I +   +J +   +L +   +M +   +N +   +P +   +Q +   +R +   +S +   +T +   +V +   +W +   +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Index Entry  Section
    B
    built-in-class [cl]: Metaobject Protocol
    C
    character [cl]: Exceptions to ANSI Conformance
    code-deletion-note: Diagnostic Severity
    code-deletion-note [sb-ext]: Diagnostic Severity
    compiler-note: Diagnostic Severity
    compiler-note [sb-ext]: Diagnostic Severity
    D
    deadline-timeout: Synchronous Timeouts (Deadlines)
    deprecation-condition: Deprecation Conditions
    deprecation-condition [sb-ext]: Deprecation Conditions
    deprecation-error: Deprecation Conditions
    deprecation-error [sb-ext]: Deprecation Declaration
    deprecation-error [sb-ext]: Deprecation Declaration
    E
    early-deprecation-warning: Deprecation Conditions
    early-deprecation-warning [sb-ext]: The Deprecation Pipeline
    early-deprecation-warning [sb-ext]: Deprecated Interfaces in SBCL
    error [cl]: Diagnostic Severity
    error [cl]: The Deprecation Pipeline
    F
    file-descriptor: File-descriptors
    file-descriptor-designator: File-descriptors
    filename: Filenames
    filename-designator: Filenames
    final-deprecation-warning: Deprecation Conditions
    final-deprecation-warning [sb-ext]: The Deprecation Pipeline
    final-deprecation-warning [sb-ext]: Deprecated Interfaces in SBCL
    float [cl]: Reader Extensions
    float [cl]: Random Number Generation
    flock: Lisp objects and C structures
    frlock: sb-concurrency
    funcallable-standard-class [sb-mop]: Metaobject Protocol
    funcallable-standard-object [sb-mop]: Metaobject Protocol
    funcallable-standard-object [sb-mop]: Metaobject Protocol
    function [cl]: Metaobject Protocol
    function [cl]: Metaobject Protocol
    fundamental-binary-input-stream: Gray Streams classes
    fundamental-binary-output-stream: Gray Streams classes
    fundamental-binary-stream: Gray Streams classes
    fundamental-character-input-stream: Gray Streams classes
    fundamental-character-output-stream: Gray Streams classes
    fundamental-character-stream: Gray Streams classes
    fundamental-input-stream: Gray Streams classes
    fundamental-output-stream: Gray Streams classes
    fundamental-stream: Gray Streams classes
    G
    gate: sb-concurrency
    generic-function [cl]: Metaobject Protocol
    H
    host-ent: Name Service
    I
    inet-socket: INET Domain Sockets
    inet6-socket: INET Domain Sockets
    interrupt-thread-error: Threading basics
    J
    join-thread-error: Threading basics
    join-thread-error [sb-thread]: Timeout Parameters
    L
    late-deprecation-warning: Deprecation Conditions
    late-deprecation-warning [sb-ext]: The Deprecation Pipeline
    late-deprecation-warning [sb-ext]: Deprecated Interfaces in SBCL
    list [cl]: Extensible Sequences
    local-abstract-socket: Local (Unix) Domain Sockets
    local-socket: Local (Unix) Domain Sockets
    M
    mailbox: sb-concurrency
    mutex: Mutex Support
    N
    name-conflict [sb-ext]: Resolution of Name Conflicts
    nil [cl]: Exceptions to ANSI Conformance
    P
    package-error [cl]: Package Lock Violations
    package-lock-violation: Package Lock Dictionary
    package-lock-violation [sb-ext]: Package Lock Violations
    package-locked-error: Package Lock Dictionary
    package-locked-error [sb-ext]: Package Lock Violations
    passwd: Lisp objects and C structures
    protocol-unimplemented: Extensible Sequences
    Q
    queue: sb-concurrency
    R
    rational [cl]: Reader Extensions
    rational [cl]: Reader Extensions
    S
    semaphore: Semaphores
    semaphore-notification: Semaphores
    sequence [cl]: Extensible Sequences
    sequence [cl]: Extensible Sequences
    sequence [cl]: Extensible Sequences
    sequence [cl]: Iterator Protocol
    socket: General Sockets
    standard-class [cl]: Metaobject Protocol
    standard-generic-function [cl]: Metaobject Protocol
    standard-object [cl]: Metaobject Protocol
    standard-object [cl]: Extensible Sequences
    stat: Lisp objects and C structures
    string [cl]: Exceptions to ANSI Conformance
    structure-class [cl]: Metaobject Protocol
    style-warning [cl]: Diagnostic Severity
    style-warning [cl]: The Deprecation Pipeline
    symbol-package-locked-error: Package Lock Dictionary
    symbol-package-locked-error [sb-ext]: Package Lock Violations
    T
    t [cl]: Metaobject Protocol
    termios: Lisp objects and C structures
    thread: Threading basics
    thread-error: Threading basics
    timeout: Asynchronous Timeouts
    timer: Timers
    timeval: Lisp objects and C structures
    V
    vector [cl]: Extensible Sequences
    W
    waitqueue: Waitqueue/condition variables
    warning [cl]: Diagnostic Severity
    warning [cl]: The Deprecation Pipeline
    warning [cl]: The Deprecation Pipeline
    +
    Jump to:   B +   +C +   +D +   +E +   +F +   +G +   +H +   +I +   +J +   +L +   +M +   +N +   +P +   +Q +   +R +   +S +   +T +   +V +   +W +   +
    + +
    +
    +

    +Previous: , Up: Top   [Contents][Index]

    +
    +

    Colophon

    + +

    This manual is maintained in Texinfo, and automatically translated +into other forms (e.g. HTML or pdf). If you’re reading this +manual in one of these non-Texinfo translated forms, that’s fine, but +if you want to modify this manual, you are strongly advised to +seek out a Texinfo version and modify that instead of modifying a +translated version. Even better might be to seek out the +Texinfo version (maintained at the time of this writing as part of the +SBCL project at http://sbcl.sourceforge.net/) and submit a +patch. +

    +
    +
    +

    Footnotes

    + +
    (1)
    +

    Historically, the ILISP package at +http://ilisp.cons.org/ provided similar functionality, but it +does not support modern SBCL versions.

    +
    (2)
    +

    Actually, this declaration is unnecessary in +SBCL, since it already knows that position returns a +non-negative fixnum or nil.

    +
    (3)
    +

    A deprecated +extension sb-ext:inhibit-warnings is still supported, but +liable to go away at any time.

    +
    (4)
    +

    Since the location of an interrupt or hardware +error will always be an unknown location, non-argument variable values +will never be available in the interrupted frame. See Unknown Locations and Interrupts.

    +
    (5)
    +

    The variable bindings are actually created +using the Lisp symbol-macrolet special form.

    +
    (6)
    +

    A motivation, rationale and additional examples for the design +of this extension can be found in the paper Rhodes, Christophe +(2007): User-extensible sequences in Common Lisp available for download +at +http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf.

    +
    (7)
    +

    In SBCL versions prior to 1.0.13, sb-ext:run-program +searched for executables in a manner somewhat incompatible with other +languages. As of this version, SBCL uses the system library routine +execvp(3), and no longer contains the function, +find-executable-in-search-path, which implemented the old +search. Users who need this function may find it +in run-program.lisp versions 1.67 and earlier in SBCL’s CVS +repository here +http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/code/run-program.lisp?view=log. However, +we caution such users that this search routine finds executables that +system library routines do not.

    +
    (8)
    +

    Please +note that the codepoint U+1F5CF (PAGE) introduced in Unicode 7.0 is +named UNICODE_PAGE, since the name “Page” is required to be +assigned to form-feed (U+0C) by the ANSI standard.

    +
    (9)
    +

    See chapter 7 "Testing widely used RNGs" in +TestU01: A C Library for Empirical Testing of Random Number +Generators by Pierre L’Ecuyer and Richard Simard, ACM Transactions on +Mathematical Software, Vol. 33, article 22, 2007.

    +
    (10)
    +

    The functionality contained in the package +SB-UNIX is for SBCL internal use only; its contents are likely to +change from version to version.

    +
    (11)
    +

    See “namespace” entry in the glossary +of the Common Lisp Hyperspec.

    +
    +
    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Accessor-Discriminating-Functions.html b/clones/www.sbcl.org/sbcl-internals/Accessor-Discriminating-Functions.html new file mode 100644 index 00000000..2077b075 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Accessor-Discriminating-Functions.html @@ -0,0 +1,83 @@ + + +Accessor Discriminating Functions - SBCL Internals + + + + + + + + + + + + + +
    +

    + +Next: , +Previous: Method-Based Discriminating Functions, +Up: Discriminating Functions +

    +
    + + +

    3.3 Accessor Discriminating Functions

    + +

    Accessor Discriminating Functions are used when the effective method of +all calls is an access to a slot, either reading, writing or checking +boundness1; for this path to apply, there must be no non-standard +methods on SB-MOP:SLOT-VALUE-USING-CLASS and its siblings. The +first state is SB-PCL::ONE-CLASS, entered when one class of +instance has been accessed; the discriminating function here closes over +the wrapper of the class and the slot index, and accesses the slot of +the instance directly. + +

    If a direct instance of another class is passed to the generic function +for slot access, then another accessor discriminating function is +created: if the index of the slot in the slots vector of each instance +is the same, then a SB-PCL::TWO-CLASS function is created, +closing over the two class wrappers and the index and performing the +simple dispatch. If the slot indexes are not the same, then we go to +the SB-PCL::N-N state. + +

    For slot accesses for more than two classes with the same index, we move +to the SB-PCL::ONE-INDEX state which maintains a cache of +wrappers for which the slot index is the same. If at any point the slot +index for an instance is not the same, the state moves to +SB-PCL::N-N, which maintains a cache of wrappers and their +associated indexes; if at any point an effective method which is not a +simple slot access is encountered, then the discriminating function +moves into the SB-PCL::CHECKING, SB-PCL::CACHING or +SB-PCL::DISPATCH states. + +

    +
    +

    Footnotes

    [1] Although there is ordinarily no way for a user to +define a boundp method, some automatically generated generic functions +have them.

    + +
    + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Additional-Notes.html b/clones/www.sbcl.org/sbcl-internals/Additional-Notes.html new file mode 100644 index 00000000..76b020e3 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Additional-Notes.html @@ -0,0 +1,65 @@ + + +Additional Notes - SBCL Internals + + + + + + + + + + + + +
    +

    + +Previous: IR2 Conversion, +Up: Calling Convention +

    +
    + + +

    2.6 Additional Notes

    + +

    The low-hanging fruit here is going to be changing every call +and return to use CALL and RETURN instructions +instead of JMP instructions. + +

    A more involved change would be to reduce the number of argument +passing registers from three to two, which may be beneficial in +terms of our quest to free up a GPR for use on Win32 boxes for a +thread structure. + +

    Another possible win could be to store multiple return-values +somewhere other than the stack, such as a dedicated area of the +thread structure. The main concern here in terms of clobbering +would be to make sure that interrupts (and presumably the +internal-error machinery) know to save the area and that the +compiler knows that the area cannot be live across a function +call. Actually implementing this would involve hacking the IR2 +conversion, since as it stands now the same argument conventions +are used for both call and return value storage (same TNs). + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Assembly-Routines.html b/clones/www.sbcl.org/sbcl-internals/Assembly-Routines.html new file mode 100644 index 00000000..d547ef8a --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Assembly-Routines.html @@ -0,0 +1,70 @@ + + +Assembly Routines - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Up: Calling Convention +

    +
    + + +

    2.1 Assembly Routines

    + +
         ;;; The :full-call assembly-routines must use the same full-call
+     ;;; unknown-values return convention as a normal call, as some
+     ;;; of the routines will tail-chain to a static-function. The
+     ;;; routines themselves, however, take all of their arguments
+     ;;; in registers (this will typically be one or two arguments,
+     ;;; and is one of the lower bounds on the number of argument-
+     ;;; passing registers), and thus don't need a call frame, which
+     ;;; simplifies things for the normal call/return case. When it
+     ;;; is neccessary for one of the assembly-functions to call a
+     ;;; static-function it will construct the required call frame.
+     ;;; Also, none of the assembly-routines return other than one
+     ;;; value, which again simplifies the return path.
+     ;;;    -- AB, 2006/Feb/05.
+
    +

    There are a couple of assembly-routines that implement parts of +the process of returning or tail-calling with a variable number +of values. These are return-multiple and tail-call-variable in +src/assembly/x86/assem-rtns.lisp. They have their own calling +convention for invocation from a VOP, but implement various +block-move operations on the stack contents followed by a return +or tail-call operation. + +

    That's about all I have to say about the assembly-routines. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Basic-Implementation.html b/clones/www.sbcl.org/sbcl-internals/Basic-Implementation.html new file mode 100644 index 00000000..f1c2f019 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Basic-Implementation.html @@ -0,0 +1,105 @@ + + +Basic Implementation - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Up: Slot-Value +

    +
    + + +

    7.1 Basic Implementation

    + +

    All of the following, while described in terms of slot-value, +also applies to (setf slot-value) and to slot-boundp, and +could in principle be extended to slot-makunbound. + +

    The basic implementation of slot-value, following the suggestion +in the standards document, is shown in ex:slot-value; the +implementation of the other slot operators is similar. The work to be +done simply to arrive at the generic function call is already +substantial: we need to look up the object's class and iterate over the +class' slots to find a slot of the right name, only then are we in a +position to call the generic function which implements the slot access +directly. + +

    + +
         (defun slot-value (object slot-name)
+       (let* ((class (class-of object))
+              (slot-definition (find-slot-definition class slot-name)))
+         (if (null slot-definition)
+             (values (slot-missing class object slot-name 'slot-value))
+             (slot-value-using-class class object slot-definition))))
+
    +

    Example 7.1

    + +

    The basic implementation of slot-value-using-class specialized on +the standard metaobject classes is shown in +ex:slot-value-using-class. First, we check for an obsolete +instance (that is, one whose class has been redefined since the object +was last accessed; if it has, the object must be updated by +update-instance-for-redefined-class); then, we acquire the slot's +storage location from the slot definition, the value from the instance's +slot vector, and then after checking the value against the internal unbound +marker, we return it. + +

    + +
         (defmethod slot-value-using-class
+         ((class std-class)
+          (object standard-object)
+          (slotd standard-effective-slot-definition))
+       (check-obsolete-instance object)
+       (let* ((location (slot-definition-location slotd))
+              (value
+               (etypecase location
+                 (fixnum (clos-slots-ref (instance-slots object) location))
+                 (cons (cdr location)))))
+         (if (eq value +slot-unbound+)
+             (values (slot-unbound class object (slot-definition-name slotd)))
+             value)))
+
    +

    Example 7.2

    + +

    Clearly, all of this activity will cause the performance of clos slot +access to compare poorly with structure slot access; while there will be +of necessity a slowdown between the slot accesses because the structure +class need not be redefineable (while redefinition of standard-object +classes is extremely common), the overhead presented in the above +implementation is excessive. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Binding-and-unbinding.html b/clones/www.sbcl.org/sbcl-internals/Binding-and-unbinding.html new file mode 100644 index 00000000..21d512f6 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Binding-and-unbinding.html @@ -0,0 +1,82 @@ + + +Binding and unbinding - SBCL Internals + + + + + + + + + + + + +

    +

    + +Previous: Overview, +Up: Specials +

    +
    + +

    8.2 Binding and unbinding

    + +

    Binding goes like this: the binding stack pointer (bsp) is bumped, old +value and symbol are stored at bsp - 1, new value is stored in +symbol's value slot or the tls. + +

    Unbinding: the symbol's value is restored from bsp - 1, value and +symbol at bsp - 1 are set to zero, and finally bsp is decremented. + +

    The UNBIND-TO-HERE VOP assists in unwinding the stack. It +iterates over the bindings on the binding stack until it reaches the +prescribed point. For each binding with a non-zero symbol it does an +UNBIND. + +

    How can a binding's symbol be zero? BIND is not pseudo atomic +(for performance reasons) and it can be interrupted by a signal. If +the signal hits after the bsp is incremented but before the values on +the stack are set the symbol is zero because a thread starts with a +zeroed tls plus UNBIND and UNBIND-TO-HERE both zero the +binding being unbound. + +

    Zeroing the binding's symbol would not be enough as the binding's +value can be moved or garbage collected and if the above interrupt +initiates gc (or be SIG_STOP_FOR_GC) it will be greeted by a +garbage pointer. + +

    Furthermore, BIND must always write the value to the binding +stack first and the symbol second because the symbol being non-zero +means validity to UNBIND-TO-HERE. For similar reasons +UNBIND also zeroes the symbol first. But if it is interrupted +by a signal that does an async unwind then UNBIND-TO-HERE can +be triggered when the symbol is zeroed but the value is not. In this +case UNBIND-TO-HERE must zero out the value to avoid leaving +garbage around that may wreck the ship on the next BIND. + +

    In other words, the invariant is that the binding stack above bsp only +contains zeros. This makes BIND safe in face of gc triggered at +any point during its execution. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Build.html b/clones/www.sbcl.org/sbcl-internals/Build.html new file mode 100644 index 00000000..bb7adbf3 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Build.html @@ -0,0 +1,51 @@ + + +Build - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Top, +Up: Top +

    +
    + + +

    1 Build

    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Cacheing-and-Dispatch-Functions.html b/clones/www.sbcl.org/sbcl-internals/Cacheing-and-Dispatch-Functions.html new file mode 100644 index 00000000..bcadf84b --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Cacheing-and-Dispatch-Functions.html @@ -0,0 +1,58 @@ + + +Cacheing and Dispatch Functions - SBCL Internals + + + + + + + + + + + + + +
    +

    + +Next: , +Previous: Accessor Discriminating Functions, +Up: Discriminating Functions +

    +
    + + +

    3.4 Cacheing and Dispatch Functions

    + +

    SB-PCL::CACHING functions simply cache effective methods as a +function of argument wrappers, while SB-PCL::DISPATCH functions +have code that computes the actual dispatch. SB-PCL::CHECKING +functions have a cache, but on cache misses will recompute whether or +not to generate a SB-PCL::CACHING or SB-PCL::DISPATCH +function. + +

    (FIXME: I'm actually not certain about the above paragraph. Read the +code again and see if it makes any more sense.) + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Callbacks.html b/clones/www.sbcl.org/sbcl-internals/Callbacks.html new file mode 100644 index 00000000..4d3f29c2 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Callbacks.html @@ -0,0 +1,95 @@ + + +Callbacks - SBCL Internals + + + + + + + + + + + + +

    +

    + +Previous: Lazy Alien Resolution, +Up: Foreign Linkage +

    +
    + + +

    4.3 Callbacks

    + +

    SBCL is capable of providing C with linkage to Lisp – the upshot of which is that +C-functions can call Lisp functions thru what look like function pointers to C. + +

    These “function pointers” are called Alien Callbacks. An alien +callback sequence has 4 parts / stages / bounces: + +

      +
    • Assembler Wrapper + +

      saves the arguments from the C-call according to the alien-fun-type of +the callback, and calls #'ENTER-ALIEN-CALLBACK with the index +indentifying the callback, a pointer to the arguments copied on the +stack and a pointer to return value storage. When control returns to +the wrapper it returns the value to C. There is one assembler wrapper +per callback.[1] The SAP to the wrapper code vector is what is passed +to foreign code as a callback. + +

      The Assembler Wrapper is generated by +ALIEN-CALLBACK-ASSEMBLER-WRAPPER. + +

    • #'ENTER-ALIEN-CALLBACK + +

      pulls the Lisp Trampoline for the given index, and calls it with the +argument and result pointers. + +

    • Lisp Trampoline + +

      calls the Lisp Wrapper with the argument and result pointers, and the +function designator for the callback. There is one lisp trampoline per +callback. + +

    • Lisp Wrapper + +

      parses the arguments from stack, calls the actual callback with the +arguments, and saves the return value at the result pointer. The lisp +wrapper is shared between all the callbacks having the same same +alien-fun-type. + +

    + +

    [1] As assembler wrappers need to be allocated in static addresses and +are (in the current scheme of things) never released it might be worth +it to split it into two parts: per-callback trampoline that pushes the +index of the lisp trampoline on the stack, and jumps to the +appropriate assembler wrapper. The assembler wrapper could then be +shared between all the callbacks with the same alien-fun-type. This +would amortize most of the static allocation costs between multiple +callbacks. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Calling-Convention.html b/clones/www.sbcl.org/sbcl-internals/Calling-Convention.html new file mode 100644 index 00000000..8e1d6ce5 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Calling-Convention.html @@ -0,0 +1,82 @@ + + +Calling Convention - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Build, +Up: Top +

    +
    + + +

    2 Calling Convention

    + + + +

    The calling convention used within Lisp code on SBCL/x86 was, +for the longest time, really bad. If it weren't for the fact +that it predates modern x86 CPUs, one might almost believe it to +have been designed explicitly to defeat the branch-prediction +hardware therein. This chapter is somewhat of a brain-dump of +information that might be useful when attempting to improve the +situation further, mostly written immediately after having made +a dent in the problem. + +

    Assumptions about the calling convention are embedded throughout +the system. The runtime knows how to call in to Lisp and receive +a value from Lisp, the assembly-routines have intimate knowledge +of what registers are involved in a call situation, +src/compiler/target/call.lisp contains the VOPs involved in +implementing function call/return, and src/compiler/ir2tran.lisp has +assumptions about frame allocation and argument/return-value +passing locations. + +

    The current round of changes has been limited to VOPs, assembly-routines, +related support functions, and the required support in the runtime. + +

    Note that most of this documentation also applies to other CPUs, +modulo the actual registers involved, the displacement used +in the single-value return convention, and the fact that they +use the “old” convention anywhere it is mentioned. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Character-and-String-Types.html b/clones/www.sbcl.org/sbcl-internals/Character-and-String-Types.html new file mode 100644 index 00000000..283db6b2 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Character-and-String-Types.html @@ -0,0 +1,80 @@ + + +Character and String Types - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Specials, +Up: Top +

    +
    + + +

    9 Character and String Types

    + + + +

    The :SB-UNICODE feature implies support for all 1114112 potential +characters in the character space defined by the Unicode consortium, +with the identity mapping between lisp char-code and Unicode code +point. SBCL releases before version 0.8.17, and those without the +:SB-UNICODE feature, support only 256 characters, with the +identity mapping between char-code and Latin1 (or, equivalently, +the first 256 Unicode) code point. + +

    In the absence of the :SB-UNICODE feature, the types +base-char and character are identical, and encompass the +set of all 256 characters supported by the implementation. With the +:SB-UNICODE on *features* (the default), however, +base-char and character are distinct: character +encompasses the set of all 1114112 characters, while base-char +represents the set of the first 128 characters. + +

    The effect of this on string types is that an sbcl configured with +:SB-UNICODE has three disjoint string types: (vector +nil), base-string and (vector character). In a build +without :SB-UNICODE, there are two such disjoint types: +(vector nil) and (vector character); base-string is +identially equal to (vector character). + +

    The SB-KERNEL:CHARACTER-SET-TYPE represents possibly +noncontiguous sets of characters as lists of range pairs: for example, +the type standard-char is represented as the type +(sb-kernel:character-set '((10 . 10) (32 . 126))) + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Cold-init.html b/clones/www.sbcl.org/sbcl-internals/Cold-init.html new file mode 100644 index 00000000..c3281b16 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Cold-init.html @@ -0,0 +1,64 @@ + + +Cold init - SBCL Internals + + + + + + + + + + + +

    +

    + +Up: Build +

    +
    + + +

    1.1 Cold init

    + +

    At the start of cold init, the only thing the system can do is call +functions, because COLD-FSET has arranged for that (and nothing +else) to happen. + +

    The tricky bit of cold init is getting the system to the point that it +can run top level forms. To do that, we need to set up basic +structures like the things you look symbols up in the structures which +make the type system work. + +

    So cold-init is the real bootstrap moment. Genesis dumps +symbol<->package relationships but not the packages themselves, for +instance. So we need to be able to make packages to fixup the system, +but to do that we need to be able to make hash-tables, and to do that +we need RANDOM to work, so we need to initialize the +random-state and so on. + +

    We could do much of this at genesis time, but it would just end up +being fragile in a different way (needing to know about memory layouts +of non-fundamental objects like packages, etc). + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Compiler-Transformations.html b/clones/www.sbcl.org/sbcl-internals/Compiler-Transformations.html new file mode 100644 index 00000000..a6bdc951 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Compiler-Transformations.html @@ -0,0 +1,123 @@ + + +Compiler Transformations - SBCL Internals + + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Basic Implementation, +Up: Slot-Value +

    +
    + + +

    7.2 Compiler Transformations

    + +

    The compiler can assist in optimizing calls to slot-value: in +particular, and despite the highly-dynamic nature of CLOS, compile-time +knowledge of the name of the slot being accessed permits precomputation +of much of the access (along with a branch to the slow path in case the +parameters of the access change between compile-time and run-time). + +

    7.2.1 Within Methods

    + +

    +If the object being accessed is a required parameter to the method, +where the parameter variable is unmodified in the method body, and the +slot name is a compile-time constant, then fast slot access can be +supported through permutation vectors. + +

    (FIXME: what about the metaclasses of the object? Does it have to be +standard-class, or can it be funcallable-standard-class? Surely +structure-class objects could be completely optimized if the class +definition and slot name are both known at compile-time.) + +

    Permutation vectors are built up and maintained to associate a +compile-time index associated with a slot name with an index into the +slot vector for a class of objects. The permutation vector applicable +to a given method call (FIXME: or effective method? set of classes? +something else?) is passed to the method body, and slots are accessed by +looking up the index to the slot vector in the permutation vector, then +looking up the value from the slot vector. (FIXME: a diagram would +help, if I understood this bit well enough to draw a diagram). + +

    Subsequent redefinitions of classes or of methods on +slot-value-using-class cause an invalid index to be written into +the permutation vector, and the call falls back to a full call to +slot-value. + +

    If the conditions for (structure or) permutation vector slot access +optimization are not met, optimization of slot-value within +methods falls back to the same as for calls to slot-value outside +of methods, below. + +

    7.2.2 Outside of Methods

    + +

    +A call to slot-value with a compile-time constant slot +name argument is compiled into a call to a generic function +named (sb-pcl::slot-accessor :global name sb-pcl::reader), +together with code providing load-time assurance (via +load-time-value) that the generic function is bound and has a +suitable accessor method. This generic function then benefits from the +same optimizations as ordinary accessors, described in +Accessor Discriminating Functions. + +

    (FIXME: how does this get invalidated if we later add methods on +slot-value-using-class? Hm, maybe it isn't. I think this is +probably a bug, and that adding methods to slot-value-using-class +needs to invalidate accessor caches. Bah, humbug. Test code in +ex:buggycache, and note that I think that the analogous case +involving adding or removing methods from +compute-applicable-methods is handled correctly by +update-all-c-a-m-gf-info.) + +

    + +
         (defclass foo () ((a :initform 0)))
+     (defun foo (x) (slot-value x 'a))
+     (foo (make-instance 'foo)) ; => 0
+     (defmethod slot-value-using-class :after
+       ((class std-class) (object foo)
+        (slotd standard-effective-slot-definition))
+       (print "hi"))
+     (foo (make-instance 'foo)) ; => 0, no print
+     (defclass bar (foo) ((a :initform 1)))
+     (foo (make-instance 'bar)) ; => 1  and prints "hi"
+     (foo (make-instance 'foo)) ; => 0, no print
+
    +

    Example 7.3

    + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Discriminating-Functions.html b/clones/www.sbcl.org/sbcl-internals/Discriminating-Functions.html new file mode 100644 index 00000000..0e2d2e9c --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Discriminating-Functions.html @@ -0,0 +1,75 @@ + + +Discriminating Functions - SBCL Internals + + + + + + + + + + + + +
    +

    + +Next: , +Previous: Calling Convention, +Up: Top +

    +
    + + +

    3 Discriminating Functions

    + + + +

    The Common Lisp Object System specifies a great deal of run-time +customizeability, such as class redefinition, generic function and +method redefinition, addition and removal of methods and redefinitions +of method combinations. The additional flexibility defined by the +Metaobject Protocol, specifying the generic functions called to achieve +the effects of CLOS operations (and allowing many of them to be +overridden by the user) makes any form of optimization seem intractable. +And yet such optimization is necessary to achieve reasonable +performance: the MOP specifies that a slot access looks up the class of +the object, and the slot definition from that class and the slot name, +and then invokes a generic function specialized on those three +arguments. This is clearly going to act against the user's intuition +that a slot access given an instance should be relatively fast. + +

    The optimizations performed cannot be done wholly at compile-time, +however, thanks to all of these possibilities for run-time redefinition +and extensibility. This section describes the optimizations performed +in SBCL's CLOS implementation in computing and calling the effective +method for generic functions. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Foreign-Linkage.html b/clones/www.sbcl.org/sbcl-internals/Foreign-Linkage.html new file mode 100644 index 00000000..d6a30065 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Foreign-Linkage.html @@ -0,0 +1,53 @@ + + +Foreign Linkage - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Discriminating Functions, +Up: Top +

    +
    + + +

    4 Foreign Linkage

    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Full-Calls.html b/clones/www.sbcl.org/sbcl-internals/Full-Calls.html new file mode 100644 index 00000000..88472480 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Full-Calls.html @@ -0,0 +1,71 @@ + + +Full Calls - SBCL Internals + + + + + + + + + + + + + +
    +

    + +Next: , +Previous: Local Calls, +Up: Calling Convention +

    +
    + + +

    2.3 Full Calls

    + +
         ;;; There is something of a cross-product effect with full calls.
+     ;;; Different versions are used depending on whether we know the
+     ;;; number of arguments or the name of the called function, and
+     ;;; whether we want fixed values, unknown values, or a tail call.
+     ;;;
+     ;;; In full call, the arguments are passed creating a partial frame on
+     ;;; the stack top and storing stack arguments into that frame. On
+     ;;; entry to the callee, this partial frame is pointed to by FP.
+
    +

    Basically, we use caller-allocated frames, pass an fdefinition, +function, or closure in EAX, +argcount in ECX, and first three args in EDX, EDI, +and ESI. EBP points to just past the start of the frame +(the first frame slot is at [EBP-4], not the traditional [EBP], +due in part to how the frame allocation works). The caller stores the +link for the old frame at [EBP-4] and reserved space for a +return address at [EBP-8]. [EBP-12] appears to be an +empty slot available to the compiler within a function, it +may-or-may-not be used by some of the call/return junk. The first stack +argument is at [EBP-16]. The callee then reallocates the +frame to include sufficient space for its local variables, after +possibly converting any &rest arguments to a proper list. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Funcallable-Instances.html b/clones/www.sbcl.org/sbcl-internals/Funcallable-Instances.html new file mode 100644 index 00000000..19667501 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Funcallable-Instances.html @@ -0,0 +1,52 @@ + + +Funcallable Instances - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Foreign Linkage, +Up: Top +

    +
    + + +

    5 Funcallable Instances

    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Groups-of-signals.html b/clones/www.sbcl.org/sbcl-internals/Groups-of-signals.html new file mode 100644 index 00000000..7c802b6b --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Groups-of-signals.html @@ -0,0 +1,66 @@ + + +Groups of signals - SBCL Internals + + + + + + + + + + + + +
    +

    + +Next: , +Up: Signal handling +

    +
    + +

    6.1 Groups of signals

    + +

    There are two distinct groups of signals. + +

    6.1.1 Semi-synchronous signals

    + +

    The first group, tentatively named “semi-synchronous”, consists of +signals that are raised on illegal instruction, hitting a protected +page, or on a trap. Examples from this group are: +SIGBUS/SIGSEGV, SIGTRAP, SIGILL and +SIGEMT. The exact meaning and function of these signals varies +by platform and OS. Understandably, because these signals are raised +in a controllable manner they are never blocked or deferred. + +

    6.1.2 Blockable signals

    + +

    The other group is of blockable signals. Typically, signal handlers +block them to protect against being interrupted at all. For example +SIGHUP, SIGINT, SIGQUIT belong to this group. + +

    With the exception of SIG_STOP_FOR_GC all blockable signals are +deferrable. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/IR2-Conversion.html b/clones/www.sbcl.org/sbcl-internals/IR2-Conversion.html new file mode 100644 index 00000000..fcc86b44 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/IR2-Conversion.html @@ -0,0 +1,56 @@ + + +IR2 Conversion - SBCL Internals + + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Unknown-Values Returns, +Up: Calling Convention +

    +
    + + +

    2.5 IR2 Conversion

    + +

    The actual selection of VOPs for implementing call/return for a +given function is handled in ir2tran.lisp. Returns are handled +by ir2-convert-return, calls are handled by ir2-convert-local-call, +ir2-convert-full-call, and ir2-convert-mv-call, and +function prologues are handled by ir2-convert-bind (which calls +init-xep-environment for the case of an entry point for a full +call). + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Implementation-_0028Linux-x86_0029.html b/clones/www.sbcl.org/sbcl-internals/Implementation-_0028Linux-x86_0029.html new file mode 100644 index 00000000..c3fca9da --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Implementation-_0028Linux-x86_0029.html @@ -0,0 +1,74 @@ + + +Implementation (Linux x86) - SBCL Internals + + + + + + + + + + + +

    +

    + + +Up: Threads +

    +
    + +

    10.1 Implementation (Linux x86/x86-64)

    + +

    Threading is implemented using pthreads and some Linux specific bits +like futexes. + +

    On x86 the per-thread local bindings for special variables is achieved +using the %fs segment register to point to a per-thread storage area. +This may cause interesting results if you link to foreign code that +expects threading or creates new threads, and the thread library in +question uses %fs in an incompatible way. On x86-64 the r12 register +has a similar role. + +

    Queues require the sys_futex system call to be available: this +is the reason for the NPTL requirement. We test at runtime that this +system call exists. + +

    Garbage collection is done with the existing Conservative Generational +GC. Allocation is done in small (typically 8k) regions: each thread +has its own region so this involves no stopping. However, when a +region fills, a lock must be obtained while another is allocated, and +when a collection is required, all processes are stopped. This is +achieved by sending them signals, which may make for interesting +behaviour if they are interrupted in system calls. The streams +interface is believed to handle the required system call restarting +correctly, but this may be a consideration when making other blocking +calls e.g. from foreign library code. + +

    Large amounts of the SBCL library have not been inspected for +thread-safety. Some of the obviously unsafe areas have large locks +around them, so compilation and fasl loading, for example, cannot be +parallelized. Work is ongoing in this area. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Implementation-of-Funcallable-Instances.html b/clones/www.sbcl.org/sbcl-internals/Implementation-of-Funcallable-Instances.html new file mode 100644 index 00000000..78d3f1fc --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Implementation-of-Funcallable-Instances.html @@ -0,0 +1,69 @@ + + +Implementation of Funcallable Instances - SBCL Internals + + + + + + + + + + + + +

    +

    + +Previous: Overview of Funcallable Instances, +Up: Funcallable Instances +

    +
    + +

    5.2 Implementation of Funcallable Instances

    + +

    The first word after the header of a funcallable instance points to a +dedicated trampoline function (known as +funcallable_instance_tramp in SBCL 0.9.17) which is responsible +for calling the funcallable instance function, kept in the second word +after the header. The remaining words of a funcallable instance are +firstly the layout, and then the slots. + +

    The implementation of funcallable instances inherited from CMUCL +differed in that there were two slots for the function: one for the +underlying simple-fun, and one for the function itself (which is +distinct from the simple-fun in the case of a closure. This, +coupled with an instruction in the prologue of a closure's function to +fetch the function from the latter slot, allowed a trampolineless +calling sequence for funcallable instances; however, drawbacks included +the loss of object identity for the funcallable instance function (if a +funcallable instance was set as the function of another, updates to the +first would not be reflected in calls to the second) and, more +importantly, a race condition in calling funcallable instances from one +thread while setting its funcallable instance function in another. The +current implementation, described in the paragraph above, does not +suffer from these problems (the function of a funcallable instance can +be set atomically and retains its identity) at the cost of an additional +layer of indirection. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Implementation-warts.html b/clones/www.sbcl.org/sbcl-internals/Implementation-warts.html new file mode 100644 index 00000000..12ab8bc4 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Implementation-warts.html @@ -0,0 +1,97 @@ + + +Implementation warts - SBCL Internals + + + + + + + + + + + + + +

    +

    + +Next: , +Previous: The deferral mechanism, +Up: Signal handling +

    +
    + +

    6.3 Implementation warts

    + +

    6.3.1 RT signals

    + +

    Sending and receiving the same number of signals is crucial for +INTERRUPT-THREAD and sig_stop_for_gc, hence they are +real-time signals for which the kernel maintains a queue as opposed to +just setting a flag for “sigint pending”. + +

    Note, however, that the rt signal queue is finite and on current linux +kernels a system wide resource. If the queue is full, SBCL tries to +signal until it succeeds. This behaviour can lead to deadlocks, if a +thread in a WITHOUT-INTERRUPTS is interrupted many times, +filling up the queue and then a gc hits and tries to send +SIG_STOP_FOR_GC. + +

    6.3.2 Miscellaneous issues

    + +

    Signal handlers should automatically restore errno and fp +state. Currently, this is not the case. + +

    6.3.3 POSIX – Letter and Spirit

    + +

    POSIX restricts signal handlers to a use only a narrow subset of POSIX +functions, and declares anything else to have undefined semantics. + +

    Apparently the real reason is that a signal handler is potentially +interrupting a POSIX call: so the signal safety requirement is really +a re-entrancy requirement. We can work around the letter of the +standard by arranging to handle the interrupt when the signal handler +returns (see: arrange_return_to_lisp_function.) This does, +however, in no way protect us from the real issue of re-entrancy: even +though we would no longer be in a signal handler, we might still be in +the middle of an interrupted POSIX call. + +

    For some signals this appears to be a non-issue: SIGSEGV and +other semi-synchronous signals are raised by our code for our code, +and so we can be sure that we are not interrupting a POSIX call with +any of them. + +

    For asynchronous signals like SIGALARM and SIGINT this +is a real issue. + +

    The right thing to do in multithreaded builds would probably be to use +POSIX semaphores (which are signal safe) to inform a separate handler +thread about such asynchronous events. In single-threaded builds there +does not seem to be any other option aside from generally blocking +asynch signals and listening for them every once and a while at safe +points. Neither of these is implemented as of SBCL 1.0.4. + +

    Currently all our handlers invoke unsafe functions without hesitation. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Lazy-Alien-Resolution.html b/clones/www.sbcl.org/sbcl-internals/Lazy-Alien-Resolution.html new file mode 100644 index 00000000..0ee5fcb7 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Lazy-Alien-Resolution.html @@ -0,0 +1,68 @@ + + +Lazy Alien Resolution - SBCL Internals + + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Linkage-table, +Up: Foreign Linkage +

    +
    + + +

    4.2 Lazy Alien Resolution

    + +

    On linkage-table ports SBCL is able to deal with forward-references to +aliens – which is to say, compile and load code referring to aliens +before the shared object containing the alien in question has been +loaded. + +

    This is handled by ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, which +first tries to resolve the address in the loaded shared objects, but +failing that records the alien as undefined and returns the address of +a read/write/execute protected guard page for variables, and address +of undefined_alien_function for routines. These are in turn +responsible for catching attempts to access the undefined alien, and +signalling the appropriate error. + +

    These placeholder addresses get recorded in the linkage-table. + +

    When new shared objects are loaded UPDATE-LINKAGE-TABLE is +called, which in turn attempts to resolve all currently undefined +aliens, and registers the correct addresses for them in the +linkage-table. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Linkage_002dtable.html b/clones/www.sbcl.org/sbcl-internals/Linkage_002dtable.html new file mode 100644 index 00000000..35200e83 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Linkage_002dtable.html @@ -0,0 +1,128 @@ + + +Linkage-table - SBCL Internals + + + + + + + + + + + + +

    +

    + + +Next: , +Up: Foreign Linkage +

    +
    + + +

    4.1 Linkage-table

    + +

    Linkage-table allows saving cores with foreign code loaded, and is +also utilized to allow references to as-of-yet unknown aliens. +See Lazy Alien Resolution. + +

    The SBCL implementation is somewhat simplified from the CMUCL one by +Timothy Moore, but the basic idea and mechanism remain identical: +instead of having addresses from dlsym(3) in the core, we have +addresses to an mmapped memory area (LINKAGE_TABLE_SPACE) that +is initialized at startup to contain jumps & references to the correct +addresses, based on information stored on the lisp side in +*LINKAGE-INFO*. + +

    4.1.1 Differences to CMUCL

    + +

    CMUCL does lazy linkage for code, keeps all foreign addresses in the +linkage-table, and handles the initialization from C. We do eager +linkage for everything, maintain a separate +*STATIC-FOREIGN-SYMBOLS* just like on non-linkage-table ports +(this allows more code sharing between ports, makes thread-safety +easier to achieve, and cuts one jump's worth of overhead from stuff +like closure_tramp), and do the initialization from lisp. + +

    4.1.2 Nitty Gritty Details

    + +

    Symbols in *STATIC-FOREIGN-SYMBOLS* are handled the old +fashioned way: linkage-table is only used for symbols resolved with +dlsym(3). + +

    On system startup FOREIGN-REINIT iterates through the +*LINKAGE-INFO*, which is a hash-table mapping dynamic foreign +names to LINKAGE-INFO structures, and calls +arch_write_linkage_table_jmp/ref to write the +appropriate entries to the linkage-table. + +

    When a foreign symbol is referred to, it is first looked for in the +*STATIC-FOREIGN-SYMBOLS*. If not found, +ENSURE-FOREIGN-LINKAGE is called, which looks for the +corresponding entry in *LINKAGE-INFO*, creating one and writing +the appropriate entry in the linkage table if necessary. + +

    FOREIGN-SYMBOL-ADDRESS and FOREIGN-SYMBOL-SAP take an +optional datap argument, used to indicate that the symbol refers to a +variable. In similar fashion there is a new kind of fixup and a new +VOP: :FOREIGN-DATAREF and FOREIGN-SYMBOL-DATAREF-SAP. + +

    The DATAP argument is automagically provided by the alien +interface for normal definitions, but is really needed only for +dynamic foreign variables. For those it indicates the need for the +indirection either within a conditional branch in +FOREIGN-SYMBOL-SAP, or via :FOREIGN-DATAREF fixup and +FOREIGN-SYMBOL-DATAREF-SAP VOP: "this address holds the +address of the foreign variable, not the variable itself". Within SBCL +itself (in the fixups manifest in various VOPs) this fixup type is +never used, as all foreign symbols used internally are static. + +

    One thing worth noting is that FOREIGN-SYMBOL-SAP and friends +now have the potential side-effect of entering information in +*LINKAGE-INFO* and the linkage-table proper. If the usage case +is about checking if the symbol is available use +FIND-FOREIGN-SYMBOL-ADDRESS, which is side-effect free. (This +is used by SB-POSIX.) + +

    4.1.3 Porting

    + +
    4.1.3.1 Porting to new operating systems
    + +

    Find a memory area for the linkage-table, and add it for the OS in +src/compiler/target/parms.lisp by defining +SB!VM:LINKAGE-TABLE-SPACE-START and +SB!VM:LINKAGE-TABLE-SPACE-END. See existing ports and CMUCL for +examples. + +

    4.1.3.2 Porting to new architectures
    + +

    Write arch_write_linkage_table_jmp and arch_write_linkage_table_ref. + +

    Write FOREIGN-SYMBOL-DATAREF VOP. + +

    Define correct SB!VM:LINKAGE-TABLE-ENTRY-SIZE in +src/compiler/target/parms.lisp. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Local-Calls.html b/clones/www.sbcl.org/sbcl-internals/Local-Calls.html new file mode 100644 index 00000000..c3836f54 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Local-Calls.html @@ -0,0 +1,66 @@ + + +Local Calls - SBCL Internals + + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Assembly Routines, +Up: Calling Convention +

    +
    + + +

    2.2 Local Calls

    + +

    Calls within a block, whatever a block is, can use a local +calling convention in which the compiler knows where all of the +values are to be stored, and thus can elide the check for number +of return values, stack-pointer restoration, etc. Alternately, +they can use the full unknown-values return convention while +trying to short-circuit the call convention. There is probably +some low-hanging fruit here in terms of CPU branch-prediction. + +

    The local (known-values) calling convention is implemented by +the known-call-local and known-return VOPs. + +

    Local unknown-values calls are handled at the call site by the +call-local and mutiple-call-local VOPs. The main difference +between the full call and local call protocols here is that +local calls use a different frame setup protocol, and will tend +to not use the normal frame layout for the old frame-pointer and +return-address. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/MOP-Optimizations.html b/clones/www.sbcl.org/sbcl-internals/MOP-Optimizations.html new file mode 100644 index 00000000..6bf701a6 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/MOP-Optimizations.html @@ -0,0 +1,64 @@ + + +MOP Optimizations - SBCL Internals + + + + + + + + + + + + +

    +

    + +Previous: Compiler Transformations, +Up: Slot-Value +

    +
    + + +

    7.3 MOP Optimizations

    + +

    Even when nothing is known at compile-time about the call to +slot-value, it is possible to do marginally better than in +Example 7.2. Each effective slot definition +metaobject can cache its own effective method, and the discriminating +function for slot-value-using-class is set to simply call the +function in its slot definition argument. + +

    (FIXME: I'm pretty sure this is a bad plan in general. Or rather, it's +probably a good plan, but the effective methods should probably be +computed lazily rather than eagerly. The default image has 8589 +closures implementing this optimization: 3 (slot-value, +set-slot-value and slot-boundp) for each of 2863 effective +slots.) + +

    (Also note that this optimization depends on not being able to +specialize the new-value argument to (setf +slot-value-using-class).) + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Memory-Layout.html b/clones/www.sbcl.org/sbcl-internals/Memory-Layout.html new file mode 100644 index 00000000..17c466a5 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Memory-Layout.html @@ -0,0 +1,74 @@ + + +Memory Layout - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Up: Character and String Types +

    +
    + + +

    9.1 Memory Layout

    + +

    Characters are immediate objects (that is, they require no heap +allocation) in all permutations of build-time options. Even on a 32-bit +platform with :SB-UNICODE, there are three bits to spare after +allocating 8 bits for the character widetag and 21 for the character +code. There is only one such layout, and consequently only one widetag +is needed: the difference between base-char and character +is purely on the magnitude of the char-code. + +

    Objects of type (simple-array nil (*)) are represented in memory +as two words: the first is the object header, with the appropriate +widetag, and the second is the length field. No memory is needed for +elements of these objects, as they can have none. + +

    Objects of type simple-base-string have the header word +with widetag, then a word for the length, and after that a sequence of +8-bit char-code bytes. The system arranges for there to be a +null byte after the sequence of lisp character codes. + +

    Objects of type (simple-array character (*)), where this is a +distinct type from simple-base-string, have the header word with +widetag, length, and then a sequence of 32-bit char-code bytes. +Again, the system arranges for there to be a null word after the +sequence of character codes. + +

    Non-simple character arrays, and simple character arrays of non-unit +dimensionality, have an array header with a reference to an underlying +data array of the appropriate form from the above representations. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Method_002dBased-Discriminating-Functions.html b/clones/www.sbcl.org/sbcl-internals/Method_002dBased-Discriminating-Functions.html new file mode 100644 index 00000000..692b0d6b --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Method_002dBased-Discriminating-Functions.html @@ -0,0 +1,103 @@ + + +Method-Based Discriminating Functions - SBCL Internals + + + + + + + + + + + + + +

    +

    + + +Next: , +Previous: The Initial Discriminating Function, +Up: Discriminating Functions +

    +
    + + +

    3.2 Method-Based Discriminating Functions

    + +

    +The method-based discriminating functions are used if all the methods of +the generic function at the time of the first call are suitable: +therefore, these discriminating function strategies do not transition +into any of the other states unless the generic function is +reinitialized. Of these discriminating functions, the simplest is the +SB-PCL::NO-METHODS, which is appropriate when the generic +function has no methods. In this case, the discriminating function +simply performs an argument count check1 and then calls +NO-APPLICABLE-METHOD with the appropriate arguments. + +

    If all of the specializers in all methods of the generic function are +the root of the class hierarchy, t, then no discrimination need +be performed: all of the methods are applicable on every +call2. In this case, the SB-PCL::DEFAULT-METHOD-ONLY +discriminating function can call the effective method directly, as it +will be the same for every generic function call.3 + +

    If all methods of the generic function are known by the system to be +side-effect-free and return constants, and the generic function has +standard-method-combination and no eql-specialized methods, then the +SB-PCL::CONSTANT-VALUE discriminating function can simply cache +the return values for given argument types. Though this may initially +appear to have limited applicability, type predicates are usually of +this form, as in ex:pred4. + +

    + +
         (defgeneric foop (x))
+     (defmethod foop ((foo foo)) t)
+     (defmethod foop (object) nil)
+
    +

    Example 3.1

    + +

    More details of the cacheing mechanism are given in The Cacheing Mechanism below. + +

    +
    +

    Footnotes

    [1] Actually, this bit +isn't currently done. Oops.

    + +

    [2] Hm, there might be another problem with argument count +here.

    + +

    [3] I wonder if +we're invalidating this right if we define a method on +compute-applicable-methods...

    + +

    [4] There is vestigial code in SBCL +for a currently unused specialization of SB-PCL::CONSTANT-VALUE +for boolean values only.

    + +
    + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Overview-of-Funcallable-Instances.html b/clones/www.sbcl.org/sbcl-internals/Overview-of-Funcallable-Instances.html new file mode 100644 index 00000000..25b92335 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Overview-of-Funcallable-Instances.html @@ -0,0 +1,65 @@ + + +Overview of Funcallable Instances - SBCL Internals + + + + + + + + + + + + +
    +

    + +Next: , +Up: Funcallable Instances +

    +
    + +

    5.1 Overview of Funcallable Instances

    + +

    Funcallable instances in SBCL are implemented as a subtype of +function, and as such must be directly funcallable using the same +calling sequence as ordinary functions and closure objects, which means +reading the first word of the object after the header, and then jumping +to it (with an offset on non-x86 platforms). It must be possible to set +the function of a funcallable instance, as CLOS (one user of funcallable +instances) computes and sets the discriminating function for generic +functions with sb-mop:set-funcallable-instance-function, and also +allows the user to do the same. + +

    Additionally, although this functionality is not exported to the normal +user, they must support an arbitrary number of slots definable with +!defstruct-with-alternate-metaclass. If generic functions were +the only users of funcallable instances, then this might be less +critical, but (as of SBCL 0.9.17) other users of funcallable instances +are: the ctor make-instance optimization; the +method-function funcallable instance which does the bookkeeping +for fast method function optimization; and interpreted functions in the +full evaluator. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Overview.html b/clones/www.sbcl.org/sbcl-internals/Overview.html new file mode 100644 index 00000000..31501c63 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Overview.html @@ -0,0 +1,58 @@ + + +Overview - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Up: Specials +

    +
    + +

    8.1 Overview

    + +

    Unithread SBCL uses a shallow binding scheme: the current value of a +symbol is stored directly in its value slot. Accessing specials is +pretty fast but it's still a lot slower than accessing lexicals. + +

    With multithreading it's slightly more complicated. The symbol's value +slot contains the global value and each symbol has a TLS-INDEX +slot that - when it's first bound - is set to a unique index of the +thread local area reserved for this purpose. The tls index is +initially zero and at index zero in the tls NO-TLS-VALUE-MARKER +resides. NO-TLS-VALUE-MARKER is different from +UNBOUND-MARKER to allow PROGV to bind a special to no +value locally in a thread. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Programming-with-signal-handling-in-mind.html b/clones/www.sbcl.org/sbcl-internals/Programming-with-signal-handling-in-mind.html new file mode 100644 index 00000000..9619e78f --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Programming-with-signal-handling-in-mind.html @@ -0,0 +1,85 @@ + + +Programming with signal handling in mind - SBCL Internals + + + + + + + + + + + + +

    +

    + +Previous: Implementation warts, +Up: Signal handling +

    +
    + +

    6.4 Programming with signal handling in mind

    + +

    6.4.1 On reentrancy

    + +

    Since they might be invoked in the middle of just about anything, +signal handlers must invoke only reentrant functions or async signal +safe functions to be more precise. Functions passed to +INTERRUPT-THREAD have the same restrictions and considerations +as signal handlers. + +

    Destructive modification, and holding mutexes to protect desctructive +modifications from interfering with each other are often the cause of +non-reentrancy. Recursive locks are not likely to help, and while +WITHOUT-INTERRUPTS is, it is considered untrendy to litter the +code with it. + +

    Some basic functionality, such as streams and the debugger are +intended to be reentrant, but not much effort has been spent on +verifying it. + +

    6.4.2 More deadlocks

    + +

    If functions A and B directly or indirectly lock mutexes M and N, they +should do so in the same order to avoid deadlocks. + +

    A less trivial scenario is where there is only one lock involved but +it is acquired in a WITHOUT-GCING in thread A, and outside of +WITHOUT-GCING in thread B. If thread A has entered +WITHOUT-GCING but thread B has the lock when the gc hits, then +A cannot leave WITHOUT-GCING because it is waiting for the lock +the already suspended thread B has. From this scenario one can easily +derive the rule: in a WITHOUT-GCING form (or pseudo atomic for +that matter) never wait for another thread that's not in +WITHOUT-GCING. + +

    6.4.3 Calling user code

    + +

    For the reasons above, calling user code, i.e. functions passed in, or +in other words code that one cannot reason about, from non-reentrant +code (holding locks), WITHOUT-INTERRUPTS, WITHOUT-GCING +is dangerous and best avoided. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Reader-and-Printer.html b/clones/www.sbcl.org/sbcl-internals/Reader-and-Printer.html new file mode 100644 index 00000000..884a7d27 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Reader-and-Printer.html @@ -0,0 +1,54 @@ + + +Reader and Printer - SBCL Internals + + + + + + + + + + + + +

    +

    + +Previous: Memory Layout, +Up: Character and String Types +

    +
    + + +

    9.2 Reader and Printer

    + +

    The " reader macro always constructs an object of type +(simple-array character), even if all of the characters within +the quotation marks are of type base-char. This implies that +only strings of type (vector character) will be able to be +printed when *print-readably* is true: attempting to print +strings of other types will cause an error of type +print-not-readable. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Signal-handling.html b/clones/www.sbcl.org/sbcl-internals/Signal-handling.html new file mode 100644 index 00000000..259dd30b --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Signal-handling.html @@ -0,0 +1,54 @@ + + +Signal handling - SBCL Internals + + + + + + + + + + + + +

    +

    + +Next: , +Previous: Funcallable Instances, +Up: Top +

    +
    + + +

    6 Signal handling

    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Slot_002dValue.html b/clones/www.sbcl.org/sbcl-internals/Slot_002dValue.html new file mode 100644 index 00000000..7b46143d --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Slot_002dValue.html @@ -0,0 +1,73 @@ + + +Slot-Value - SBCL Internals + + + + + + + + + + + + +
    +

    + + +Next: , +Previous: Signal handling, +Up: Top +

    +
    + + +

    7 Slot-Value

    + +

    + +

    + +

    The ANSI Common Lisp standard specifies slot-value, (setf +slot-value), slot-boundp and slot-makunbound for +standard-objects, and furthermore suggests that these be implemented in +terms of Metaobject generic functions slot-value-using-class, +(setf slot-value-using-class), slot-boundp-using-class and +slot-makunbound-using-class. To make performance of these +operators tolerable, a number of optimizations are performed, at both +compile-time and run-time1. + +

    +
    +

    Footnotes

    [1] Note that ,at present, +slot-makunbound and slot-makunbound-using-class are not +optimized in any of the ways mentioned below.

    + +
    + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Specials.html b/clones/www.sbcl.org/sbcl-internals/Specials.html new file mode 100644 index 00000000..9b26888f --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Specials.html @@ -0,0 +1,52 @@ + + +Specials - SBCL Internals + + + + + + + + + + + + +
    +

    + +Next: , +Previous: Slot-Value, +Up: Top +

    +
    + + +

    8 Specials

    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/The-Cacheing-Mechanism.html b/clones/www.sbcl.org/sbcl-internals/The-Cacheing-Mechanism.html new file mode 100644 index 00000000..b8beb875 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/The-Cacheing-Mechanism.html @@ -0,0 +1,94 @@ + + +The Cacheing Mechanism - SBCL Internals + + + + + + + + + + + + +
    +

    + +Previous: Cacheing and Dispatch Functions, +Up: Discriminating Functions +

    +
    + + +

    3.5 The Cacheing Mechanism

    + +

    In general, the cacheing mechanism works as follows: each class has an +associated wrapper, with some number of uniformly-distributed random +hash values associated with it; each cache has an associated index into +this pseudovector of random hash values. To look a value up from a +cache from a single class, the hash corresponding to the cache's index +is looked up and reduced to the size of the cache (by bitmasking, for +cache sizes of a power of two); then the entry at that index is looked +up and compared for indentity with the wrapper in question. If it +matches, this is a hit; otherwise the cache is walked sequentially from +this index, skipping the 0th entry. If the original index is reached, +the cache does not contain the value sought1. + +

    To add an entry to a cache, much the same computation is executed. +However, if there is a collision in hash values, before the cache is +grown, an attempt is made to fill the cache using a different index into +the wrappers' hash values. + +

    Wrappers are invalidated for caches by setting all of their hash values +to zero. (Additionally, they are invalidated by setting their +depthoid to -1, to communicate to structure type testers, and +their invalid to non-nil, communicating to +obsolete-instance-trap. + +

    The hash value for multiple dispatch is computed by summing all of the +individual hash values from each wrapper (excluding arguments for which +all methods have t specializers, for which no dispatch +computation needs to be done), jumping to the cache miss case if any +wrapper has a zero hash index. + +

    (FIXME: As of sbcl-0.9.x.y, the generality of multiple hash values per +wrapper was removed, as it appeared to do nothing in particular for +performance in real-world situations.) + +

    References (O for working BibTeX): + +

    The CLOS standards proposal + +

    Kiczales and Rodruigez + +

    AMOP + +

    +
    +

    Footnotes

    [1] Actually, there's +some kind of scope for overflow.

    + +
    + + + diff --git a/clones/www.sbcl.org/sbcl-internals/The-Initial-Discriminating-Function.html b/clones/www.sbcl.org/sbcl-internals/The-Initial-Discriminating-Function.html new file mode 100644 index 00000000..e1ddb16e --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/The-Initial-Discriminating-Function.html @@ -0,0 +1,87 @@ + + +The Initial Discriminating Function - SBCL Internals + + + + + + + + + + + + +
    +

    + +Next: , +Up: Discriminating Functions +

    +
    + + +

    3.1 The Initial Discriminating Function

    + +

    +The system method on SB-MOP:COMPUTE-DISCRIMINATING-FUNCTION, +under most circumstances, returns a function which closes over a +structure of type SB-PCL::INITIAL, and which calls +SB-PCL::INITIAL-DFUN. This discriminating function is +responsible for implementing the computation of the applicable methods, +the effective method, and thence the result of the call to the generic +function. In addition, it implements optimization of these steps, based +on the arguments it has been called with since the discriminating +function was installed and the methods of the generic function. + +

    +discriminating-functions.png +

    Figure 3.1

    + +

    For each substantive change of the generic function (such as addition or +removal of a method, or other reinitialization) the discriminating +function is reset to its initial state. + +

    The initial discriminating function can transition into a discriminating +function optimized for the methods on the generic function +(SB-PCL::NO-METHODS, SB-PCL::DEFAULT-METHOD-ONLY, +SB-PCL::CONSTANT-VALUE), for slot access +(SB-PCL::ONE-CLASS, SB-PCL::TWO-CLASS, +SB-PCL::ONE-INDEX, SB-PCL::N-N1), or for dispatch based +on its arguments (SB-PCL::CACHING, SB-PCL::DISPATCH). +Those in the second category can transition into the third, or into a +SB-PCL::CHECKING state where the choice between +SB-PCL::CACHING and SB-PCL::DISPATCH has not yet been +made. + +

    The possible transitions are shown in Figure 3.1. + +

    +
    +

    Footnotes

    [1] Would be better +named as M-N, as there is no requirement for the number of +classes and number of indices to be the same.

    + +
    + + + diff --git a/clones/www.sbcl.org/sbcl-internals/The-deferral-mechanism.html b/clones/www.sbcl.org/sbcl-internals/The-deferral-mechanism.html new file mode 100644 index 00000000..78991498 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/The-deferral-mechanism.html @@ -0,0 +1,81 @@ + + +The deferral mechanism - SBCL Internals + + + + + + + + + + + + + +
    +

    + +Next: , +Previous: Groups of signals, +Up: Signal handling +

    +
    + +

    6.2 The deferral mechanism

    + +

    6.2.1 Pseudo atomic sections

    + +

    Some operations, such as allocation, consist of several steps and +temporarily break for instance gc invariants. Interrupting said +operations is therefore dangerous to one's health. Blocking the +signals for each allocation is out of question as the overhead of the +two sigsetmask system calls would be enormous. Instead, pseudo +atomic sections are implemented with a simple flag. + +

    When a deferrable signal is delivered to a thread within a pseudo +atomic section the pseudo-atomic-interrupted flag is set, the signal +and its context are stored, and all deferrable signals blocked. This +is to guarantee that there is at most one pending handler in +SBCL. While the signals are blocked, the responsibilty of keeping +track of other pending signals lies with the OS. + +

    On leaving the pseudo atomic section, the pending handler is run and +the signals are unblocked. + +

    6.2.2 WITHOUT-INTERRUPTS

    + +

    Similar to pseudo atomic, WITHOUT-INTERRUPTS defers deferrable +signals in its thread until the end of its body, provided it is not +nested in another WITHOUT-INTERRUPTS. + +

    Not so frequently used as pseudo atomic, WITHOUT-INTERRUPTS +benefits less from the deferral mechanism. + +

    6.2.3 Stop the world

    + +

    Something of a special case, a signal that is blockable but not +deferrable by WITHOUT-INTERRUPTS is SIG_STOP_FOR_GC. It +is deferred by pseudo atomic and WITHOUT-GCING. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Threads.html b/clones/www.sbcl.org/sbcl-internals/Threads.html new file mode 100644 index 00000000..47ed1035 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Threads.html @@ -0,0 +1,49 @@ + + +Threads - SBCL Internals + + + + + + + + + + + +

    +

    + +Previous: Character and String Types, +Up: Top +

    +
    + + +

    10 Threads

    + + + + + diff --git a/clones/www.sbcl.org/sbcl-internals/Unknown_002dValues-Returns.html b/clones/www.sbcl.org/sbcl-internals/Unknown_002dValues-Returns.html new file mode 100644 index 00000000..a2e8d1cb --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/Unknown_002dValues-Returns.html @@ -0,0 +1,88 @@ + + +Unknown-Values Returns - SBCL Internals + + + + + + + + + + + + + +
    +

    + + +Next: , +Previous: Full Calls, +Up: Calling Convention +

    +
    + + +

    2.4 Unknown-Values Returns

    + +

    The unknown-values return convention consists of two parts. The +first part is that of returning a single value. The second is +that of returning a different number of values. We also changed +the convention here recently, so we should describe both the old +and new versions. The three interesting VOPs here are return-single, +return, and return-multiple. + +

    For a single-value return, we load the return value in the first +argument-passing register (A0, or EDI), reload the old frame +pointer, burn the stack frame, and return. The old convention +was to increment the return address by two before returning, +typically via a JMP, which was guaranteed to screw up branch- +prediction hardware. The new convention is to return with the +carry flag clear. + +

    For a multiple-value return, we pass the first three values in +the argument-passing registers, and the remainder on the stack. +ECX contains the total number of values as a fixnum, EBX points +to where the callee frame was, EBP has been restored to point to +the caller frame, and the first of the values on the stack (the +fourth overall) is at [EBP-16]. The old convention was just to +jump to the return address at this point. The newer one has us +setting the carry flag first. + +

    The code at the call site for accepting some number of unknown- +values is fairly well boilerplated. If we are expecting zero or +one values, then we need to reset the stack pointer if we are in +a multiple-value return. In the old convention we just encoded a +MOV ESP, EBX instruction, which neatly fit in the two byte gap +that was skipped by a single-value return. In the new convention +we have to explicitly check the carry flag with a conditional +jump around the MOV ESP, EBX instruction. When expecting more +than one value, we need to arrange to set up default values when +a single-value return happens, so we encode a jump around a +stub of code which fakes up the register use convention of a +multiple-value return. Again, in the old convention this was a +two-byte unconditionl jump, and in the new convention this is +a conditional jump based on the carry flag. + + + diff --git a/clones/www.sbcl.org/sbcl-internals/discriminating-functions.png b/clones/www.sbcl.org/sbcl-internals/discriminating-functions.png new file mode 100644 index 0000000000000000000000000000000000000000..af724e48c58423a54dc28404086493b48f42afe8 GIT binary patch literal 45461 zcmX`T2|U-`_C1b-R7g@Pvmzv^hzyw}6(KT@8HyxhDDylOLPBINp$t((#-vOcq6}$3 zWJ-oq|8<`G`~F|Id++n|=<|8M&)H}1wbxqvglV2u-Auoeo`Qm6^9ePjvlJARBlxcs z9Swf6yf|)%|D&-usj5WrkNoFeb#5GfLhEwklrnAq#`P?;EYjGc$cp(?Oi7j)w=r}%Sr(z6) zy!NWPq2aDiV`Eo-O`ZSz?OXka54->V{kucv+TrKb)#f%fwB$q1pRcQ}rJ(2-8hRV* zY;4RYP_FU{O9E8AvbVxs@liTh=Jy}5-&=9kNA`0&X9dQoM&N5;>B|NLIM z|M)TU=;$ccWLjAKizQb#z$prtb{);_ung3)aSS zylQJ}`1&Sg%g&wQg@zR`>+0n1f6>#^v+R3h{M7Y3Yt72nUDWH>+m(7_MYU-0O=qmX zy-f{`iD|AFzP^!>k+E>#tbsxJ=3U}u1EqEzGu2CZ5*itrG>3m4;R{z77#y5i{a&Of z!1C!sp{&>~7{CO1GX(PX9UZ|ctxpC;mKOcvbc^$VOA2ui|Dqb2W zJu#Sry$|o|;I>ug_mJjbW@dIV@uoEU-dm`quC8$Yd~*3Id>Ko229?G{gPy5RP>kGP z{rtn)IT~84hm@NafBuX&(O>LTwF(R6#hCBJ+@`bmK{Yy}w;|zi|FSkMJt7?`Y9=Gn7d zMbbC|%H8BKm=xmE0(?GPG%mB>rV_n7EGH+2UsgN*>)Ogf(qTL1&(5Bl`>zMq)X0uo zT&E8b>$pdyVUA5&m-t#&@RWnY{ss4|SFh%dv8U_m=_#H$!^j+#rF|zaPr&={$~OuQ z&qgZ0kuYg5{QCNkdaeIf%yySxEel0VIjhT+EAsaC1!pIwrl*r%gfOrVOn5Zg2(xZH z=KiB0e49|3+SXmWNDM76FV{9TeGO~(QapQ>dGDz^Svot(2^J5=3C=u^BPu8)q@}Cd zxOQ7TTU1PpDx%RpE^aG_v74j*d1f(Z?TAaq$aX ztlPJb)icU9+~id)wXQk)(4>0jOwDf*I_{B$6@dc>RIgq=6d4sY`uQ`pc*W!K=Dfm9o0$U}i| zzAbPw(cR0q4ZdMVGc zm?Dv0KIh8a>DO2H&Ckyl+q83F=L`Eg<*~uy4g=I@&YbaHoybiMEH5o(LEaY-5b#Y+ zW%u{@ADNjMF7h<3G>R@L5X|A#F)@k0eVcX1u3d-HoI{T8Vq?qyBy<*~gHEt^XI5op z@|M9{x0pj4E&AWTuY2=m^N$}tMx2gH^~CDw=y2`bOM?w~@#ohrq|y-N!rHE`v-jQT zf)v(f>ls6%q8e}fUEmB13X)k|o1C=I%FgCS8Bz@1ByVQMr4qwYC^ng(&* zIXXJ}MEg8++_`JlTr=m5dl?y&5v=>kDM6k%ohBW|d1Gx0N{Yv~RQLGnrh4a*OJ-3L zMq3kv^j}<;xxL>o=V$RV)I=2(8nHu%~*W>ZEJm0g>TaRFa*0+3dp7oH9kB`6i^y!YCo*vO7M}i(a5c=@(cm93R%u&@l3; zF`}cduX(cPL5XcAPlCs-!otFq)>egU*QD;Gq>O(59&zs;*HKBy{95NmCIwAnyMzqUa84jtd$Slzn%5XL!V36|~K6$KOg>ql#` zqZ}L@#T6BLQaO*sxdXZO?b{&X_@TDcu3Pl_+H&r|0p>8WT;}f|TdQekG`xReqlGWS z=b|o{{~Yg}ouBuwu9kWD@L?JgD}t)2N#$K{Z|1#wzFQhwTh)u-U-Gzi%>sp}`0?Yj zgYL*6oetRA+rJE; zWh8mcsnTc%8=Lv^?C6ez7SzFvoD5sHZgoiMw|V^J$(6ZJ%F8P&=3m>AW!}oa{^Gp0 zJQkC5(2~a6+gr-#oUU$ATbqWJl@*tq9OvfEn{6*$3e*v_e%smI9gva1jVCvAaEL;> z;}H;`qokyCa&e)ixGU?k6Uih=)~9Ong_Fc^{=It?f7ra_#ET}VaS*xU~D zACvp99^EZfp^>qPIgdileol@`M#Ts2R`S&@DK=+)zc@>Vhlj_erbdM@a=vV7p&J?++9B!8XJl+l zYaOuXrkc}4*B+K_+qeY<=>hlDv)fx*YJsq3zouNaf2ep?OUv)RYK+BLQnC`{B?Cml9I_JR@ru5%;w%yw{5*>8p{rmR< z`}UEngf$uY_AR%!r>sf|sp9Y2!Wn8>TFcd+6F!r+p-Md7zo#qoD;!gMO|qqK{FRQ3 zj1=|yb*V6Zcq<-V?aUd~3m5j{hfFLifwi^AQyC5OTMTJx1Ba*de_8`9SfAV%U-#-B zvssvu|J2l_tlZrDH8mVqK{`4*-)GN$AL@B>0Go~TS9jsbLH8dYWWB5dnWlzcaK`bU z2`(xs3NO@o8(r};My-l8uMf5xJRGHMY8vyzrk#r7YkT_e zjGC@qk%{ufi$a;1nL6esFPI`4`=8h_n)od0X0t}y#i62*11BTHem0*4`+d%kMZ}et zg}!cVPV?M38j-|^)zxbk0%94=-CSI}bEK+R)NioGQVFxrUs?KLe4*tsG7H*}-J&MJ z1;Cn(jS<`NSDChL3mUBtSvuB^*!%P{Xrl+#+%-q5@X@2De}9+cE`4~aWmE6r7NW+d zfOqKX>gpI62>11+h-5o-;rL~*{@&gurR7h~m3a>zTCsY&ZZduL^y&CJo+I?ii91B8 zgjpkQrlm!{d#5u#F~QBpNA2h5*Zy-Y9w~b9d*97lxBSmPxxjt&sQ#W6aS4erpz-Fx z%P$JArrx=GcQ^35*`L)#sWO3+Y*@S>!!KfRrZP%Owp_n{9cL=C*FELzdiG;#a~{%2 zW=Qj-ruO%Xriq2rcPUgaj`Vl4W!Bv};Fb9X&TSIVm{C zO);D?#l@ltp80`Hq|7GCc!^8P$mrh6EvN(}MtL|gFZ;OaCNk~Yw@ru$O;b}wPEJlN z0?pgEZwJIrWgiw77t3t>;@sKaPlr6(r2W^p;=vBb#iw0Pf6KzbT`A@yLY9ge+9EST8|z+3^Wp< z1&BrtKUDN^TFr_jT(F~xLhszUPe>p*>GEo7bbC+V&5NtsRH_Ut`!@9$El%Wi6A!=l z#m9S4?WcyScO7`K_IO}vMRyzfGqFPb5~@q$hJ#=8Hsc9s897FVs=bhx1D-uQhTJkb zF(H}P_%tBe^Go!$ek>?Z@DA}yJ9t|kJ$lss^BPlYtCX-Vo94=j&;%j~L=FJWZ(t90vwvy^c@{6lSz0Nc_8I zfBjPN@Hjf1>?V)Qjh_9f=fd7JuOE^ccMhMhv{?SLG;Gz;cpiJ(Ve71qC3BGwbMx8meGS3yC+*xR>*ahwr; zhmJ|eT;!$x$jutTCNF|_ML2A;4sX&*p}1OU1dvvXZ@l`oEu+(kMN?ltRPOKcI%HE1 z^oK_{o|_6LSb$6TZ`n@Od;c8QDtFkfR@T;aFJDqwHboM^Ilal< zFI-HyJI}~>7mzG+%aUFFl1&h>cSBRt%cdrpg|BbA4K9sDY(Ma_x0iLSIi^p2Ws+3B z-1O@TSWSSPr0E^Gr&4kpx?TK9dflarvwh*)-qo*u7HNB1ft0a0yJAbK_f`3|QYSI_ zFE4ullAHfsTfvT;Q!Wpn$4Tq&*T-t|2nwn{*rfs_KQ&mvXjp!U&E;widlA2~vhpZ` z5baWbxx=pMO>XjBOrnDVlSr7NqD&-Vwz;MHWIqsaZ`%h{B-qN5tr5Pu9F1NTiYakPf>12aNE?x-f&Q_DAgu>Ub!g2KTt2i`_L1}3mJiNSH z(3Lnmak(9xnu6FwKqoK1Yyb4f!e`VjbLz(r26uP&fszbq`4{VtqT~Q<>z7zG-it6D zGzHpcLa%*OEwH6UEp@}b{&(*J0fH^-gEtR|D}TXx-Yw-qmz z6CE}U4UPU|s|}#=${YrKl>rg+^5}r31Vlt=Lh9w6oJ2vkoXAaGl}B%@e)6Q2k5U=PJY5cviDyjbMUSrus`zUvv|Vr5FL1e|&t_`R*Mxn3qWQW2{K? zNk=ZSQc+QrI+#?ft$a%dNkK?4_fo3X($%whbeJ7nha>>IAGid6sCYGd`=pI^LWXBUQ#_Qv9H1#$uL2%UTAn_-@wnCX(4 zpT7YWQ&(3P+*978M>H|bguuc#D)DS-usGPgx5er)f3O>R60#Ht>R^@0`9S+yhgW1^ zU;q;|@iXPkg?jK3dwvN;DDjvNG<^DGarp3IP!-H*eP?H9eN$2lD=1^7hGNpCTnkjB z#&~Yhm6eqN!YJU|?CtF}4GkmE%c8Fp+qic<6(t=vx&)1TJFx2bHsClUOa;LN1+auz zcpM*VDNleEH1Hw$`TK%5@1jA!41Q+QF7Zvje*J3ucZb2_=izJnYmXc`vb@-5+Vex^ zMD|$}gi*vl=~IxQI){cBgoK398y}?XkpxUiO*OZ+UTjg9&@7}$0 z31>uQ1xdKR(um>Mv15_DBpA54xpy3M6YhQz|H^9lQ^bMVFV4v{AKKa;YL7j07!)rv zPWkIRJ0jnfF30KS<~AVyCBMZ=3{jf_vIta6Th26=9S_G9DB3sN)%7?o&z1i=`(`_w zG~xaGb$e~q`Iw<8P8kDh zm&8H)VF3u~$j{FYChB0sOuUa=1<0P-`xJ`o{#s}&=jWYO#)A~N>9~=Webdu9*Z%w& z{q`+H>%NMe^gxoPfYOyK2mePQg@dd^KCc}f=0y9dVc7V^xy0wU8@7nhoxCcM<9d~1 z$(z8s2?z@-UB501o_TI|R1sUvq+sUg_?C_vAQH64!l6t3qJ&0;=z(zesTyvyIEdi% zRdwy{?+*pTrZUdC{V(Dhl?DVx-N%pY=;_)lD!1^e*dDgGELy)@>$eUNzP!~`+1Alf z1@P;w01&gVu-pS#(Ae0BlSj)E7|4@ z`cesr?dQ**CmRik2WNR|YDyH1yY$kBt58Djs_gPmphNk%nUWHLmqo zk_GCDxw*L?meA}=YeMz4lcXF20Y3$#10RG6lC{+$M>xiPCp|sArlw}C%g(m8HbRm# zZP4y>ORr`g!Ojqx?Ty5+&WVi0#l@puzl7hW$!t`h%Q=-2j4r!=c-YiN@AtOt+j(VW z(>&SHjBGkkv&;ios?5Qlh&1#*KGjVjEh%^I#6sbMu0eWs6hm-(*qz8wROxy^0~()k z%A0D`XnD~aaG^T_IfP;vj1-OlqFT4^;I*H&*p-)W-kcizDl6~hb?om-`wcgPW1W7; z9%Nm>BQ!KO6N&>F^6+66bo?r|w&T80BD(0xKYzC3+p~vTQZm^N7%?UH=Clf@Di;&i zo;~YNoHzm8U=#g)VxkV|PCNH><3hV!dujdj^fca}8K>~dpH)}ne4vIyFHs3{53zIU z@}Ln;Ol)>JjIcMqbSW}yE58LqE>fpYe9P3M+P!t_IypHxM8)ERVj!GR0ztL4x84>p z4iDP6ouMT}eQ(?-xXYuS^L#jQCC*>eg-vUWazp4DQ7I*_eytrEGI6jjt*98oX@BbT zTio$uRS-LyN41h^P|5aqS$)>i-L;~{RAer4O{3~-+o=2~h@>iaU3%}Cv`vsB6B1P?WE3)(_U+q8RLNU$ zah+f^Hf-I?#lu6jb+1OpB!fQw^^3o&LeaY={SR6;jbta9bd7WLS5a|OWBZS~P3`FF z?j}3%(4dSST8h1pHkyXQiXlRNfsjgyjzv}M)km%|1Ihc7?K(Zq13`u8eM73Mq=fa0 zDPAWY(6euT$gy4@ie`U_B_X=HXf9Y;5s8sJ?~vDwOseTxHz&^Km9^z7-v9nA5qkYx zp+WYcs1raC$ZExSiiFRJNMys;e{V*Pu=;eP9Yn2W-;CLDL=0B{DHsgqty>9n1LtG; z<3r`n1#u*GXq{nbkj>uQIU*(JoOOci$>)|W1lmGM?0;+>VIZ{tjvO2{QDqh$tpQvX zTfJg_{B^O7pu>RfsE z(qMU%lCttm@JoUTZuhze2GnI&$9b9A*iHZklsYhQ2gV`^--?axD3ZocTDF^d%ahLa z@s%+Z{PZ|pU)PFTc^3qMSoVjP?Rx&t3vkRWc6Qe3@r5@#Z{50;**l+k|Ng7M4O?3} z@2gH!FOZb>3h=vy{3t^);n>|N^wySx2KR0OgIQOchh3kP{(cXn`?ff7n z&&X7$Ql372dM{RT%5{`EEKu0ED&BjsM^8y4aY^c<8ELJpJ~f2#$;p`x=EUOlmnwO6 z3=Guqb5$N5o|d_><`ag7DdC0p$Ei@8KSxOnapB~AhWa4*#*m9CcKt@ySV%bON_@=u zhiB>{)%bY+EjP=x_^;onrmY>PJ`bApGXy;@d^UfDTkqMhaU(B|b|U>lFY&OL7=BcQtg5Oi z(-mYhvR|_Q))s6AB)bmtpGo7xzod7)r%GAlKEqLYZPC7ne)aF~nOA4z{$xE5+DSn% z(HQ!y)pK@)k}P-WwR(JTpL%Nhw}n@*8@%#cNBhp+{fz6a#6(rJ*)7X+W4gC(OeZeZ z6g*b#Ub+l`K%NGQj?Y^~o|~~qaIwfX+YEB9mm2qlw_w}QL_F_epI|UBFla#v9-hh1 ztMkuE&;9VhNX%j2Flh14_t9z0w-XX>ZskAyQ{PupfbZ(Jw>|IEbT3|fa1PzN0aJ3IHUzIdE=j(;~p2%0p(1RGTu;LW8z>0q>ZvcqyR zKFvd!QNJrdC<&i`9Edu4|I7qZ#zp7(&nLDSX3I+bU~}kmb>Dr=Et0e_KI*^GBHjX@ zq1ecp&tRS2_g8j!z$5MPB!FBwwXmu6Yk_e0{p))x9Of z#ayb1Js;y^o6+J-w%Lk*@N_ zKiRqYc^+i7w#8|KTz1!C<5Zcy=lh0)DJ*Plmz6%c-mO5;SU5VKcAMkB)ihI*RR zbfUAm=jL{b$H2m$Mn*d9jFtL+mp_~7-=;iK_3Ya=(Y|5@5jg!MC4HBkRX^}cK(q)Y&TmYJ_UftRw_#}X-(c#kN z!OO~hU*|6VTYfTR%n_b;S%IZuqw!#LZt6+3_SG)VzrQM8-2D9c^S>t<5@C44&M`?C zNjNIqXH16o^9I5m5Zln8M4-Bu{X2o2MCb7iZW4r8x((cc02pz*BphRFYik`BPN=K% zfb>j_mNPL&->hV6n$DyU8W-2SbwMaRdNIVVJ11ZGfOYIED=YBG)v~5r-GYOHZURc& zf@GI-nx)6Ck9KNK%1heeMviuq~i`0HhG@3`>4~s-x~{gWLG|K&Hm;DjQFZR z_ra>Mn|q&PXPI{V>Ex;(*BD(3zyD~}(djF2l#}vU`I2}7R+Y1M*xutcYx5@)1~T%Z zrX7A4jt{sjJ#Q&*w+q);|xUD9-vLm&ZJqG7IlEVjL(|%^lfhu!z4!yRg z7Jegs$S!AOzJW`e$(r(kE6ErA5)X4&Xhy~;@49EwEP+fGmo8~gFm2r$cRJnG+Yyc= zr!vRpZzUxq4fXW_D=&(RV@b=L8f?6c{W~MTlkN#wA9*%L{jF4&@HYWkxwF1WP2ani z>iTERj_N~M?x0^<+R)aC^b4x)U-ng9-iFmF$MSS9-Fp3{p}jo@&&LcVKI-|~g*sZ! zpVzoA(0a?JKh!T#*z-lGisQ^PH=n}qX+H}8|25IC@s`|o;DDasn*<@f7Su;w`;biW z@`~w-%!>=9HpW^UA7!)=e2{kH4%xhA0@Cgp8hTVbJ$~oMob1GV#WbKISsoye|XAZ^2uGO2v&f?ldNQK7#G2C%yc^3*LQCNXilr27w} zTuUsb#x+AjL+4Ko8>oCsOG}v)I2My6cc0EZjOYpioSyGGd0_EadQD~|#lNK&|MsZH zaOmDY66oRK5esfF4$17GYe(7Xi}v<(6feIxZ{SukPX+IG6N!?Uo&C-3nLHZ`jr;w6 znZNTTmTsf>$bb0I`_mc#h(b%;l7stjiBNc#t9!fL^?&fc#G>WCg%bbkKI=8rQ>QkE zg@%sDbpT8RfD*W#F#K^*(`EXadY`s2u|z z3Y4^V4G#WFiRCXk)m+A(weSS}*(1@I=JuIZ;DWH5H@CchapT|C71wuf#-^3}#IyK) zCKz{#U*cMt8MgU5lR&f*xr5h-ww35>pr)=aLdS31!Wy9rVWZ{C>%`=Z?_BT7N=e-T zc@p^0_}MvgS*(0Re}57z4u_gK+Appx&wc)qXu20{L}2}>XftQ}_j4`}i-qnov` zwCvuunc}f+XXfcIZtik2e=9P*z9Zv$+7CSX{})v6?U{RHdo73rT&?hO)fYW*)izLE99o9KpKJI485}ob~U{Iuz1|(D26u zd+E}vd<^Cx;hmnGoUR+;*7cNCzFj%-~mpYIyF5f zU1@Y${8ImM@ykPN8X@~5!@{@$X4DTPY0^qcO8Q(cQxjmh1vg)kMw)c8H(*OvO^r!o zuU6?PG?JB0qg2UqH)PL0wmR`*_`-O&5)b#~nw7nt*r#OAtLp8r7v0n|@eF#t*lQ@r z9wvouAz93tUea?u>ur<6j!kecMQJ391$oakZvQAHTFp9=naPvwe_}UIAZ$I0Ue-U4 z-!Ct}jkvx|UWk7CkZk}ADDz0WOG1n|64(DM>WQI&CClOr6(pfCH`|s2F9jIff(EDs zME|Q7e-{s2s7t9L=sy_-s+GwHMQXr32CsLvfM>deq<;(AP=22lU4k;+_r{;^rhLM} zk-KHRmy_LY>x7|1Zx=D*LXz2oGITA5LBHtNIvNTncL?FpRQI8YHxm>TP&bIzv#o6t z0W47F-hVG$7X_(=XdFoU%b(-Uh+h4w;gIq!3{gN?RI^&3UVdHZz=7uELpF%2^*eU% zv;Zni0$c$rtz))N*%++gC$zeu5fO^OfeMO>CFnXLIps_&4Q*Pj#Bfr_2*Y#8hGEEK zY%?r7c3GE4l547OkkD{GDm zN0mBSiC;fHMxZEKg2f?vF&?w$ag5Ck($AumI_R_NlJIp9+6cONZfIucE=ZSzZbbCT zC#Ar^z*^vt>@Ql^&dAGCqA3d)thmez3J2^VG1{OY=P$l>Ld3mImy5xY*S&kka-jMr zGqjr{O!!LpiD&9DH`h({8KZabFb25&Ts2@ZkosFk7}zfDU%YrR;8jvB zzci_IvqF`;HnidqU*=)f_K{ABb7_Yky zO9u{a_UBJ4DMgs6r3Pc?SG?~^dotfxo1?wt;BXMqIchR7UOWsIKLZ7*Fql8?m6x+NH8nZ8yNAFC0E_rRn0D}Df^R=Uz=N9uq_h@f)Bhp7KmneR(s3C z)H`7uMe;=_If9}eski(`RekF@tP6N)g7 zjf%NBH$W}oj4;~A1FCm zSaK6S9>dYNDa)5^|7AJdl3OzYMv=SX1-`8KrUSMUjv$Mgn z665fpy93-%@_Il11(A7>odIjzbPVq{#b+kt8jjw-qqmoaqU{g$+OQ0bw0$VFq=oK| zj*f{N@U)ibf7oXVP?vLc&O;RvZdrS`Oh7VhvmajE;KX`9MYoH6;7WYWo%q_^&Ta#w z5R?<*t%t3L*tZWK4opbchOBkaWn2@b>g9(IYa7}N@0-8?1M{DD1zrzg8hKa{C@?!{ zLLz|XH~#&*qNyn-bdTdmZeX}!h!f>{Zm8QeFwjbOJ|r*U_U%kX3*_rsixN>N9zd@3 zb#;C#!|&e3+tpLnVr~QhnVQzu4A+syw^FP;Sa6Gy9Z=F>07Fv@eOnm|1kXwxbIdE)cFc_teL;ur6W0HZcOI$P2S7;*S7} z7?oh$D`J<1s0@dLzP^4fQaF~KEC8H(L~vsWS%*K6ov=dkcsD}!!V5rLk7d6K(A$Gb zC1x-4`e5^yfg2FZy)Duo!N4V%teC-7A*VYF6+i2&U2X^~#m=2OlU^MA!8y|DROIJJ z3DT5{h5lHWiz+X}J#Cw!i({R}s#t^7WJBAm6YyWveOvg?w2u@L4EYqQ*;Phx-S?4I z0-18Ots&UT$jJOpHo6z52?YV^BO@*kZnO@DTg*h%3@jPDk*`Cn&I)w@6FVU~(os`z zg#E^WN*bm}TJ>Ce{{-?XEUdiq$Z!aNw&ALB0iAt>6Qtp$MsnB7JylIyDEdz>L>XKY z2J5;Xu#1VEz3^rw48t*~;$z@%$mC4ciMV%CO8etp%}!SgTg-iGBxlu7k_;40aAdF7 z=VLYpQ#VK6r3TAQMq@2!4s+ zAA%YNv-*b1FpJ+ySIxpOim}yk`dJ8`CE(*=w|P)@_hh2TD9FTG{8I0W_FcCES_SnpL!-KPUzIkEu*;oAO-d%%n-zO)5G)h;cP9eL% z5q?DM258LFRGGyqv*Ss0K<0GO5c z^br_^!v-hH`fcW9sDr6$#s8cHtg&?#`O zmj3ie^JChPyEpRcv>UW2JqGPZ`S?&@oc8} z(t9!J%o;*p`e58@+-}+c!ps*;vRz~FBb=g9Bs+MMRbkYC#_-{r91I6||f@Jyfr`e9IhaaTuVxOj-UI;J`?B@H*Y=r=@VDIsmF6(m<6DLz( zn`rQnW!s#dp(rwkDe*UK_i$mySW!4kv;rleMwZZd&3X!S^`E)zN5-4&(KE%)JnFko z3NE2nK&pfQc^)w&57@pJdk*az7I@8z6q}TZ4ICg2^H1HjmDQtY{FHE-Ax7jsS;#>) zg)T!B2iOT=i19iS53$@IdX5Er>O|A+T{nb5j#e{;3Ed9oN+WhR7dQ~)wX|-&{h?Ti z7M;wrfpb6Z<@K!mjTV?GZg>wvU;LTAOt)!ML%w$IEC|*6#l^Gv6R=d2fXYO&8$kVZ?LP(V;o!)i3y(QEtr_9HFi7b(b6Yu*vp3 z(9=49J`7R>+4{FDcR&$%I{JjX^Z}80`dOs~Id-m=qzlVB(dI8rq21 z66@C#WXXm-_w?!ijEX98e`8?IN3EKin!TzAHPqbRK748T1}EZb2UA*cSl9+I?o7s|Z7Q0OwxDGUs zS-|J3lMi+d^Hshus_{;K-(Y^Px`{VI{U#C&jvq0efZ>~VdwL#16kdYBT_7Q%?G!d` z$i+(g1)g<`z%XOglm`_YO<+kW`D<$L`?3NHk%7h2>9U1$9m#*{P>g`?6!rCYoIQJ% zR2)!j^oK6AnTfyrQQOhMgf6HFU2okN=l|e6mKE_8fQieayQ6Q{1Wm$Rf>aN!8_>m1 zjc@WNFKYz+T}e!7XHrxpP~#xnJuECV2Li&WLla`rUu-V*%s)*bBabm#+6*WRY1zJE zovh0^Q_h)m*?YU@vaJ%gc+5Dh&;B zz;h(%*^EuRkC6;uUxEa2dQqTJSYYf!sW3A$qrgkx!4a{wt*zl(^#3;sYi})^^54K0 zggh?fdia5G%7U<1u(##kn&#if67HB0Pl4?iK{p4tDFlv^%CQsL;qO~_i2oU)j z*ql;&puY~J17r$=^3#&=OcAv^MdC6Kw0u(4)Qd5z1iFZ%I=FVp{0vCyum!1LD>$)| z*Wga$zNv<1?Ra%^x)x{`p9F6$9V#wacDUsTmcSrke%iA~@^qB2NfBS}{Jbbs1Mos@ z80#1ik3x6=U_C{mv}sS%eMWHuEKolNeSGajy?Ef81gTjIevFLr0&#=H-$Bc;yQAFB zM*&9yT@@hB>d4~)k&pcmXz*OMP*jNgD1Q}NB>Cqj`S!6>OjcyhVxdkRAC?Y)gY_0fV>(P}uXJ}8zz3UuImfS1Ww%YgU;Q!+4w znV|lsS9pP&NeY1Ro>&C0I6J@Gb@{m;rUFKw2Zx4*b-riHW1;^tF&QlCbg^i;}q4py7LZ44SvZu=iGQ z5w$fwzX{!h!bzStS=v+VT#-o>5)^S&42Xv)WC-}3-Z1;|nLC+waY)HvMLUBf^(Fpu zoRMIh+yzHbj5E5pl-}O2vmZ7mGNTNf9mIaj4c-vz4i_<(C<1>Gs4yNip`SinW6Ad4 zVSGY&l8b2sZJ5XR!U~P;VP26zU79Bmk`wt&(Li0mrCxwLmpEFNG zLxT&k3Wy8%isXQ12|2-a^#c-LAQS%4@6CmP{|%lIxAv7Qeh(fzP|-`mvJ;a#x>S&T z^S&F~C1X)pl`uAmXgHKN#B&dTOp3P_L`g6P86jqn=aQ!bd}WNqXa=|(LOQ?@f^32A zA?Sb81u%wUG6}}9ce$EDm{kPT9T}U5HX7aA>o1w0bkH}Dkte{S5G+A~%qnx@>qh*O zsOzK-q45f>WnM$k9-II28iod++zAFiB*XDY3ZfDBKlfa?=iLrR1uq6|@NEAX+gKwo z(+|pM|YUPRC(CdhD1b-Y_&Ylp^KLInQL|Oq;iN z{q%*KFepr8?em>#Wo2aD#dkz}1fF@e5yJMQ@OAQLDc zGOShX_)%(S>n(*&`FPe5kgB6VO}hD8z&&F6uEF>H(vltVxPsR_icu%RN}(Ho0bFzN z!r}%TLc-R7#z7S$NUhkcjw-?PJG)|6QT4AorybsjCaI~ZQ2^fI7007bvV=!x=u|w# zAj$sv^B8Ia1)$|wb0-U}HJLm<_sA#=jTsLb!+(EfZqPnlrt$?Wz~m8t@Ik__A_fR2 z3M-NBy#1Dt`Z^qvIVjcls;Uguvuam~VJiWgxVX9H$)J3^2)IK420@8?_zHx}Iya0) z$Bp7|G+-)p3#N>oK0S*3r!RE1YO(>$4yX4lB{5mE&>zG{5hKu_w~37wWLcDPz+RqW z6Zpdq-V%ZZx`hE4Rx+f6dvy;SIpSLT$Qw+b3Wzu$xGRg3x@~tQwFmd+v!mu*djEJm zOan)qMkvZJz3;kwxgXyJ`)e(ZfInD{ZRgb|j-z=kdOlANkXCT}^kH&5)i)Lw$UO6t zTDyz52YbIBNE~d<<{;v+!_EHNcS<_%){%?7W^k7QFnhj` zSP#=|E!fnO%fqrb-`mcsO>kjc3QLMH;|_9T!FqN2;sVRn3)a?TMpW>P_DB5Q+Vtfc z^*C8BZdYB98KNF}VDzLG4PR*LG524`4!}}I3|jyG{?Q5Ssf7pS%8w6{J0BqoDN84> zef|2?;$5EBz+rhiC@H~^pZppv7WY-}6;BzTadI-%uXNtyIP`pj-|>!_=i~$cT#bH9 zzX7A2mY-`p12pq3J9dN;Fg%Dc0=uAn8U@*6`3<8+5!ejLRV`8kxQt`W@_#;7#SI9nwSiI`w7OW?RgGt z@Z>4Z$gWV6V?eq&+*2V|zXrOI;4jQ@fPP#*(pl#9eCr7AkpRiyDtOcUGHCtxAlh|$LOyAQ_oO;4OYeeSi0Dms{YGQbYJ^$CS9r)Xb(DEwLvF16x%6@i#8 zs)yl{hO+5Jw^Q8?*HyWG2i8xM%^j}1YLhGZ8S^F&jVhVRaeh!#6D~325wJ4#Y^J6j zvpq4y+Xfp30ty3sL@>gTu4psI@MQ_i#1L2d+#IX~#D44l0!gp!8xh(6#Z>=}4xhAN zqWzm{KHep-Q$@#Gz{5(tk4I2Vqj;l*GVji)YYSiZzTlI1^*~}sKQ6CzzTqc$_NL7o?8o-92ve7lw^YVNNw zU8)L4CzMxq+~q+0Vg*v2BV#dgO-L?wsXg3unG1YUk;JkGeD90-Q;k#;=op~x1SQvR zrof#n4Im3p2MfnF z-eo;=l<&mAv81>--n6s2$|>RwFVPgnfLvA%$z-Yd{o@!~MzJ(+zY3w}xCH>4!ie~Q z3lr9tZIMfZy2*F$d_or&&Je&=wWm^U9c!2pGIK{~=S}y%(oRg)BQ*bGx%0_B}_g>VED4uJd0&#CuY;Sfb10q$7^*DjElBBN?x zLy3_VT@wp)ilF(E_r)b8b&#>qfESEA;pJ}HQfoBZzXGVqygXbZR&ifLT3VW*2*^(a zqU%5RIJp0}eL@h(FM^lMUs6wfsN71r2*k^_+unwob{}QJlW+U?zQ2D5A&M|L3cs)j zndAXzq>t2GnOpHDlm_x?I71Lu6?<6jJ!|7D17a2v;edGL+k_2D>5!>{fby^ZU9o{j zSxD+|7{*x$;K5-gJz1LEjc9CKil1-EG%IVlI3~(nPEbKkwis2(-?MD$I z0~a^%-qrXm&tpv5Mo4mVU*GIf4pCtG7_Fq;!J_=?@OoohGl2q~Kclw|r?J1we>CuSkf{-TFI@Ktj#V+40`PEg9XhlX8uW4SllXCoS)KnmS~Vz>Fp_hkNhNX- zeAJ>&BgZkRfA+_}a)@Koys0NHrp+aL&bu*$D%SL(x5Gj~Y zCsG$^HH>Val@|zCfF6sd(bU#n2VEC`4NV-6C`C zr!S~j^l}-<1P~G7p27t|G}WNUm)Nf3^uoSa4B`+v`3YSCWegn2%gbZb=i$*;m@EH( z69>Qe^b8G!=G1LiBZ4T`(U{fxQWE(E-7B%d10~~qX%T&;O?hn?lWR1jIzhFUZY6Gz z4lIAQ`>iwX#Ig>nA)wp3*SGio9!W`sN`%@Sf*!=x!x%dN$_VY|@soFT!$MIR0n_E1L+f{^8H^H8EV4^#^x%u-zDJjq1OZOY7VX7^xowdVp2j_%oy4_d+D76W!dxGgnk%X)}dBIOgw znGLt>)B__~sVmLwtt4ItB+QPUo<@Y6l}O83P0iycWv;MB>`7Dk=3M#T7GW@yVu!Sc zC^)WXpI;VY))v=C(E3h2+ePOed-sD%Eza#H(_cS$KmZZ-o|Gs1$<#)Ru-q(|ox_m@ z7)4qqHBv|?>*`8IF+n{XfH+8GVkqB<_VkD42@%5W1EUhtJq;rVt{9p*{m*zqkOE@tV3miup5AssWY5h} zqP;~8CnkOTl?qK?@leRcG_{nQw-K1!saJWo8xE^$33b& z7aU$+wpXA6lVJ+NeL%>ag-fCPmki_*7o`&XnaceKa`}4KHwCHFCBu2Py zHXzHu*zx~VA|M6~dcOpC*8Nm@P+7}k{__UdQz$8rW~~luFwt{qQQiI$cO5sKB^LVj zWP-ke7TW}A0k|%E+{v~ccPg>5k?8;~+((2a<-V&<`=}F9?Kg4C?#9FkDF`sG!d39@ zhsj514>&%ZtO0x&fZEN@J~}>5H!^+oFB#7P`T|jis_%;wfqazU>~c3HWg|GnIof=v z1j(ES5tWi*%*CbMI+)ggGKioQ#Guj^*jq3!;! z{GMG~xeAl@CZsRSI2k>l?tI*SzOyXP5aUg?eSO=J_QCpk{F-6|YSq-y2}Fp5t2VdJ zQ~t!^+aY)T`Eom^hj1f^rkN6Tr_3vB`YNQO3H1YA6TsNuOBw(Po_V|OLAfIy6Jjv} z!H0bKT1^fo6&DT>kssP8{1>8*AC5xPAr%3-d*n|cA#?|ub{?h+pxI0{`zzo*z!_n$ zHCck7a^b)$ns2PcL>C0yL3=GT^eGh|GLAEa@4Z6hcRbql?mtLE3m-i)+=NV z?XYh*T!Ta%u*n` zlP!Ueh-3+J|F)M{&GkQ0Slosik8r&NsQ9y|6SgYp@h5ImK<8@w_@$<^v)GTJ>In2+ zZYiG!$v`HaLJ?OTppk3yxPe#$(Q+JE40x{u@0M`Pn%K+9ja0ZH3^N&+NQ8${iFD>@ z<|ETFFa9o&2#~m(X>9<^{pYHrD6Y_dyouCC@a$*j+}jua67Cx<3}Rte;<&M~aVPh_ zKqPVS6Pi$3KxtO)KIMTUOy+0^^$*Ul%2X@5#<;fTddw<7z>d7?_63uUeu4o>`jxk%gL}`58#l;s8hi|# z8Z7L%xHEo&Z|}Nw>o9@GgIWX1Kn31?bvaI4Rnh>B(9Fgr1XF?Qp}sqq=-~`*KVVY2 z(*GG7^~v6tT3&!=OuNHKMDGi8F^E{8dSW(;cTMfX#hmbYS|DINR_6DR8xerm|JO!N z%fMqpt{#Jt61Pe4>F$CfN34j7h646$82G7RdTfN9)d|-ZB@gQS7ZkXOrN8njKZ@hf z?^Uo%2d!J<#kb4jg2j4Ro;b{zsXH0MD!5PF@!hp^r%r)-JQ^ubTTDB4gK;EulE1jgF+Os66kh z`#ksSyq?#6?x*ciTZ!EFAj62J_IqzSvyhD<3^8Wft-#U8sACbc-5TH7_xXpa|Js)$ z(RwOxBJ_-=>rEP9A7r~-)2xfJaVJW1OP^=f%?u6W9b$|YEnX}cBpX_L?x4}4OI-n# zWBuw|@zZYR5%$2EbAY}f%y4=j$;vrgZmo#$BnaWRP=Z-R!!VJK)PnFG(B-8?@p zQ&VThIH(UuyI@4>Nhv{1yy};~Eh^Hzd#`X6n-VfZgp1fGExH?zQ%dJp5kVDtDbyE@ zv2M9LD1K5qF-tYdaMv(J5+su9?>l89Ka@;031Ql@=&QdIq&ICbeY&Pj$Zeti=G}nMD)x-%G_?)3S9v1uAVyc*DYGQ^fn&he&B%$%dJ-By?pr^`M_dN zot<~PWhbhbPOv!Q>0Md80abQr#LdM^mrC)*tIzs8TWek1nKM$q(6oqhlv6X3NGh&0 z81rNLYE*7-65RgR8*W77i4=ANT|>@%=4SsFtfcVp=?P{Ob(fU43bRCV40X|MHT)l*B{`+e@a;4eqdgi!*bnN)YxH zj+h3b{+lrcqQySB8ntdk@X$bA&B<}CS5Vo+By!l8uUmKZctO8X&^-?C>;F`ne)#xt z>*Fg7VDq(c;jf>qfPxw|ZMk&lC91d__>x8h)Z!-6PD)Za^^hY_!pb6(0XcWwzc2v5U$Ct;FxyzD*z)9 z5Yf_7jpKGBk9te)N_FKM&9V6c4f9|}_@?si-Fv=y@|t}Q8Z>wPtEI?K=su;~5Ty#J zBxy#@@jp`@NVg5b4xQBI`kIDczCu3JSZ)Mo5G63H_D;*I3(idwCpWk=Qo26Yb?2Y& zoF4)u#reM(L~0g)K|+2^JKq)U_JMx0OoOu?5Tqs;^X8U1YMdL$zW+40P#@=`_e=ku zug$Mq*w;%jH#he!kb~&+yLD?z`8zhaWfycQOL9)jyESr2-b6%pw~-@fla1kx)$%jo7{a>9bEwfxK-uC6x{!XQUYRLEMKj( z4Q8F2b^y}_8?}*+j?RhizIuOswtl00Ix(?tg=W(EA2(5KiD>1d?^7*EJHB=i`J;5p z;zyu1zKcy@-?H}hwv^Wb3d#r7GIWp&o1SGPfo_Y+GtpyEt4MxnnfpNLI_X93kh4In zUf0|-LUqORAPrQhH>x7(OylB0wgsqiAPiP=$mmsES?K{Rl;wA3xvlM<+H2Y321k&q z=6W?#lXFX;M~PRC92+dm?KSVJkQ`$X2=Vtst^4<{1R|0qOn?;nJN*Ksv`cI#$+?j_!teY0w$cLRy~4#t zMqZxFwA`b{zI9``bJ%K8(|ZT%9_X@C349QC{`2~#OD~Pf9Z33tB7A)`9!)?P+GL@$ zV9)$kbYJB-7@?kIOi}LKhBa88mnSKq<<9oiO6|(!)Ta`Z7M|ju-?Q-?Pon&TI2jjL zzcDb73NwHX_fWTPDyFu!W#e~wD7GQl`b9_%N;=YtpEyjNrmOCT`$Ynz?9Qz3-Ubct zSvncy@3Z+(Nf$dH)8bHm4Ii6yu~#b~CiucXXI}H#AP>YTBs5CDqw)H7$QVMs-AzE= zQ8fwku+PvAClme_M~>jVVPS3E-7Pck-u<{S zm&BH<|Jwg7Z}_!bIC_elq@%z1^=%FNH&_96|QR+YNz@FTg$DfOMl%*%J6yXB95+#%95!-7)LG**-5wqYL$D> z&FOGK8n+|f>ejux*+^5WwLacer9nwagA|ruo>=nf(_1QS_e)u;TzzUrqwVM1OsMX3 zIr~FOx4F~DXR=30$WHQm5d!y$nP%aV$%Rdtw+mn^&f)m(JksynC@#`rtKO*~MK#M@ zN~+g}ix&s8sr6Pn^PVQhDMNN_BYDr-bvfNK{*6V+d-5o*$+zq~lDMD@$uX*eP16%-YOtwT+N)F63C{-UdisrAv((a?Z-4qM&x7Js8l1{c4* zAi@_HyW7FGA7RLfINb(ZtT+P-DF!1hPnOwoUal0JSjvOIJ0`4epoSOW6I{$w?WyQo z*;ba$K78~Idv0=o#)8SLt*ZmAFzDLV^w62(Uu!Go7>pcwq7>}R5~Yz&_3%2zV$sjDJ1F?m_bO!Y#SQw zuo9nW{SYTUktg@Z!TfcO?9_`a6*7~a=AF5ws;p$tqlbCa^^X+xHk4Z1Zhu4GF_qP~ zEoqYa?cn?KFZ~dWwkH=JeCE%bhQl?^uq&KZ()0&h?)Lst-b08ZMi^{`OT%s03M6uO zNqy%1`|HZ>I!$N!%mKIE=3chDE#1CwF9 z$&engtLQ6Yb&Qaf&i5>E)x8nu}}wcXk?eO5A??Hf%6Salho5n1sV@ z^3PoVpJC5y)^2+IaVm{|w6c<7x3bK9Ui>M*#!DmO+LGc+2``Y{o!J7Yc_J0Llh;!v zYEJKvJ!f)WArPQjF12=T;Bb+gF_vTWpaRc4fVP#qH-dE|c2{R*WdSd2WYHM@&>ud} zma1#rw-2v5)wk)?(y#2G*sOWf!oeOg?N?pRp6~XJ+1_J2*==!JR#Q6(rV~ zJIdkS{vkaiC5Ui0nym!2HP^f8h64;@Z#u;r4bhO$ZL*fwXWYsdLaWEV@q z+BDT`9IGOopL=x5ER+{xE=1n8=Kx2?y8d_C;L9Td7;bRKoPswv*N6h!TZ zAYsqR%$6=(OSF-e zP2j(A5yrmno+WZ^i$2oMP8q`KYUTYwa3k3Hr8>i=i-+g0e;(~1#8#B@1X|6g>!$Li z!6LjrSv{!H^GZHVnmEyI{`{QS?1(*a=%J`)L<`Vql=qWDKOgXa$`BK2^9ods(CbgI+ z`{VXxF<8xO+hQK~De=ZyJ3l)nI0X?hg~8h9wIPY|e@py4xMt8Dlcv<--0fXPj_k-1 zCNA(cPw;(?f8xy4FLhN*u2zj#zwJC=l8M#8#=~acR^iEo?T_k+2v6v1VpJ3rh|E_T zeK_pa>mq_TZ=l!~P)v>SeKU`aB&$;~kyY480qFS_5=8Qg!>k(Swm+n+IkvP->AXMRt`+qi zlM2`s$ICh)2a;6>7~oa0x9j+H_x=M0+@#eZaeIa&GDGr$3yWflb=m?DN+J=Vh}#WX zsE!=>SY+f4uNkO1C6{u|nju7{NFxt~4(%q7VIuJDiF8Hrwv`*OA1nkV%xm8u(PtswaKN*&9C|T>1k{ko?3T# zUfwF;0Xn0bWbzzir`x{*cG(mY)05^iBaz`HywPR!>KF*J=80tgfn;t<1A2LIW^=uuyF6)6;1U34%~rE_%h3cbF4 zXz^cLN~grmq+k@C8DNGueW{PqU*D^YKGqLDSA+oEBSHZWgWu2TSe zu>P9yo3}kO<}|UebK0+~;(f33O#Z4zkN~y@cO6 zrxe%H#M#KY{r&xU=ZzGY=}-?xPfuayfG?@ z^bJ_?O===nG7kGoS?;~|lJn%25u!EBw+{S%klW(LYQ#@oNlCfB*4@%F#H;R*S0-p5 zZOU!HZo<+}RQjBsd}P>$fPjEjJ6;SPG)T1B@^}HV-h906G5f+xgQ^>$y2)w>3s10m z^@e|Rr1u!Pn0s&I<;$1H1t&C9R{9O%e|WfP^}gu1h<8{PNxAsK$>15MuyH`|Ayds^ zCeksbskd#L8M_u-*{&xfYA@Fa0i4TUw2}+*>IA_^TE0M*S1wXUQ zeDIT#c*4cvztL(?eoAaX*}41Y<2UH4l-&Dq>>)AU%L}iSJipkn<;T>ysYD;hQN%te zD_r|2rwJbbL^981u8|Uxf}6(@s!)x zOJqpJ1G|rZf(bl6I!fXOw(m~$ZAohWBKN(zf9<$`BtWNQN4?>bg6_V(ST~UVQ%=w7 zN1FuBmQZisy2@6U3J^>23DyqRHZuSrLh-ti2^%%@o2Ynm#0%LbAg88|TBp%|y^WK` zYBRV<^rBe&uFNo+^fcAXucfMK8mc4!oqg-t_(P`&0nGj7kcdh5HTx37oOR6j_3Tv* zoxP`2U`jd4q#?Q;-6e9$DUJN4`!e?RnmPrIApLnzhG@!Vj2Dp^CuQZLT_Palns_LgYz#em@E=BmoA&(DMU6!mtvcHy@{^T`w14-@TDB#V;ERf7XMenmb-6X z6F;&m?s=RZx)mAe!gXy~Kv1#XV}Dgs#f1~n`Sn7N(07fvw&U@~wO5{f<>2+Ic+(i8 zc?AWyrOr-l?4%3yt@`Qlw!%vwFif6v^8%F=P$tY(?%fD<6~~~u;ICX&bAAf;gpz{$ zY1ZkT+SKCWY6eKRs{uyC%^Xp9OeL^ZH&5+@_qugrdeoVDi@@jD*q0wHDLa|U0p~)T?STMp7ovfz6f~2QM^-Q(l`b<3!;B{jasE{a(&N z>JZ7b-SXMz+lNUhRoSY6ZY>kaHPFh!v!5JSL(``wBL1o>-|{7tWDxG@46^IBvN!rG z6NtLoHBY+}9l}J1QLtEZojkJlSD&moDp3wBA^lroV}( zM-*Y*xtFE7vhTu4=|uf;JG);Pk~BuwYk6Z2#H1j)%%wQJrl!jyv=5v)XzMjH2KfE( zI_R+Zfe1(BN(MPu^y)(9+lqa^PCMJTVg4VoxV6bA*EwUDqFGR*s&C(I?-8__6hwLk z=2LBK6uHBjM0Zt*>XUSRZ#_Aoh`h>E3n_#sNRzzF0M^LHeb=;A_XgC3D`^3@99>SG zIE#bT!piDX2Sx7sVB~%bm*|Jsn6S02tA$ zo8F~!sfy{Zg$)T8ko{1l7dpSd5dX?R5%1hvz+D)wI=92ra)i$iS(xiTAt{x#C$l%v zEiu)+w{2C+M6BC19Z&$ucj|P_zLhK>j+a2+*tk>SsI4imH=H?R)M)nvYxF^!F!(=e zi!RQ!A7!H7vRh{#w5TiTuN@Mp9g@5^4ktZ?ILv74u=Iib`lVB#%5W-Jp*5wQ_@UCW zfdg*D`owY>(J;wFY3E%6h1)iK=TP>ltL*iwD$)OG-s91`=e#{Y#(+3eudSW!IG$U7 zGbN?dr2|iUkrMnHVSD_5hWg$&*T5<2<{Dp+`xIKGm+uIm4xO^$q>@M0c44Bh=7AKv(|DdQzO|i-vdw*x6VNRm%kUfxY%9@BUHO7Iwc$|>toJ* z{PtbSDtG6H#m5;Bgkzj25f3jHiqq+elhoC2S}5fpLQG5Zi#O|oEb~okL`wrWR(jg! zqn@dSROvVGfhMrgU#|X_`_f8sgGnH8RFvtD-V^uip0ohAh|Gwa)GwcM6Yuig+a<0? zZqR*ofoqg6KLg6XNNv5U; zg(Iq?rna{tanYK2$;o zi?sHd-_Jvrsz;da*fFQ&){L9faL7orUwckII#SWh2G;J_k*<3?k}(n%<`~?p^?j8C zx|+e~l*yy;hoT8_485dR1nwwvLOxW}3rTBFdTJM5A@wh4sOHWY;5m|RTUq|fb)-89 zL*tygY{k`m$y?in%OC&Q1Q+8A7w#>#|FFH|pXYC#kK<^PFlOUlwR8S7?;g$~qv^U( z(ApOmjSJ>|N2pwdjj9KrWVw|QZYX^5&)>xjJ0?Fc6v?y5ig?#hg7`u+ctaVkLjiZ$ zCGk(!n3)AV{5fRMplg@2<4|QwZ^A4wqt*2~$Y4(T8iX&L#75wLDEl=E-^Z=|d}pJk zeeQ+adhLeCw(QJbJwmfpOjowku}<|duz_K zQTqC|iB&#n?h*kEqpFC~#BVh-TQbDs)S-i68Vgzj0(vvo7~#PZ-hxg;hGTJGlU2gJ z$w0wfi0mL-K5~i*Db{=;#<|HFmh&EPj(yn#Rzr;J2=v8F+~?KQ1xR!*JFPeGCv^+> zOz_^lQ{!`q>Ihwxy?Q)dBNo$O=qFheKTs77E(^_52`nCI-sUVyQBGZiQ;6ch7n|V; za>^S5CeNP|QxZtzTgp1ov$6vOj^yX?+hx(SbJ95hgc2eAMnZOY4fA5udQ!{?DaJ{B z3zr5|=a)Ab%|s6a2erR`;B;6o^T+497g7V>z!LJZ^dclBJ^873akDrHjxZI#UJ1!r zotxHhSeaW3k$tc_L{rS8Vm3teMrBdQLc|0<{zwjNYj*f}a?L5{Hv_N9!3gP*!CF4y zeWCy0!5J`Sw?h-;>Xny?^ao?mUEFZ*hHsZjgR}5zRj$j*VMiPukB1ur0upn7WApB* z9F^3(;%xhIV3VF(;FR8Xf*C=vMoN6hcreY3X`|^yiMIJ&F=%NuCWW8Vc?RxE@|>c| zw)bFCix@kkxa7y(MA-mA5$3#oKIc7e=l+Sr&z}pFY1+3jJ1f+vQR&;aS*6co*6!_Z zqW<-+m(u6#__hLnblTYzWu$q%HJy(0H>mQ13HqA!)CNkE!JRq_KhG^amRXb0z68qe*6ZCAM2Pl5 zQo(_|HFa9{DNM*B&BVgmw5v+vJyuGxI4M55-MwgUXIIql^Lj%th!~kO5!Kb*ML;0I z-;xgyU3I8M^X5)vo;?n%rb3AQwBHcz<%oCh-|ud87a)ZW^-Y15{d5A?+@QvGgEz(IqTVd3E| zc#&6hM-&`-ia-X?5$cTP6>5l-qC zk(djPzx&d>!GZ_>xr+Zv1wKJ({xk##tTP}}EgiKoF;B3U@@n3-p=Am+c8WQX7dk*q zRdrqB9t{`J*LJSO*#!jzLIGhEt!S5M-)${d13vlVCx@BnANWT@c6>q^a)@I%MW}*j zpJRVYYC~md_NUYfwxcVn9u4T%&u!`TWtnT*4G6l&vh3)z<8M0$R*fFZCGdWCMXH^w zwAa^hbHX|DL*B1aRN&CHm^8_Zt8|>Jqc$Wfg9gq--74Or9}<|H>>Zzc-{o(hUTW$8 zd3p9`{&0c-TjW15D<@}vT#r>&1s|v-8hNF>Xi|IKW?tsvGJijp_7k-m;gzA|4|!&N zBmO*Gs~gyx~CuDQJY)g1~oEuAJN>MloSX!J9)NgCZKhpU92dfVC8$+A3k z#LwzwL1$X|rd|Lq%P5X414%;q!9Uxop6bxe0>Be}&}+En9fUVqJ6}br?7wP)e+(_i)g^$; zTVKznqRbi+?HVBG&Eqs|GL^7soLXld`@m;Ti0YiWSraYncdywD?+dIsqg&kUeU4$J0J>b zY8Z--Q0G@vW&(=iNPL&Gz!4L&{!yD^Bfz`#w-uVaYY*pDFSk(pzyErt8jwxGdi0hh&=~TCidODosD}N8QtMpRBzv2jqoA_1Sad} zpC(5PMYbZ(Vrk(u8Rs##a?&HXCm1JDFOa?PXxeC(>DkC$+sNzQA{D z+KshRwO9vGJcbtoVMm5n@PxfRW>x?DQiw=OiW7@3T)86o66v5tQa6ecoo~;y-j#=Q zWjrPQjydNrxu@G$*MFo%SD$;iRG?Xk4|a<~a-ZpOMf71VbwxqduuTuDYWC>3okKh4pP&w{xyYem~ zDbIhqH~Z`f$mjAi$nL)>`~+Zn@12?F|SgH`vL*0Qj% zHk!zenEn$}JVn!7SKTAt_px&1QVXSJ!Gz~Tt6q_(bPim0Tf6>BBA-H2WM`iM#w%Vx zh2_omK0G?A1Bh(*AniQNYK4cbqJd6P_>7F}ZeVn7|$zvnfwa4wE&3Pd* z&_rM@mMezx5kD1Wo+1ZGe>B>Lxwrc7yU$vIRCrd_Y~M(q>TMH8x7nnzD|5tdQFXZEm5jK%`Vz0!<0CFIE;zigBV+%qcx0d>@sY;OT zI>v|X95~yU%;wK2}(!FCf;9_d*?Lv8yMZ>#^O>BX&IeW_;c5s<;!;p4aEKug=UI#7>#dJx=>WP zXEVFMMtnq_u)FoEhGeWks6~H&yauaf-Q4VFY-)Th+}JU+RjaPMi&Ogy!K5d%&^WsT z*f($R%9Z<`!aE7^)mwZ{q2FhYX3oif61%A$`j#7_^d%jYLQ_8AUk%-P$NZE%ThA(d z@BBbl+B7=d>owk1+e`52ZG8Okw=?_Ry@i9{RFSF3;}RK%`6HA4mxbK`oPC$Rp}`X~ z5UkzaHyxBC$5BSqCtau)pjl?4@%;@h}i;FKY&@|&Ix;bXp!-<-Xhwa7qY-!H?t zniv!?hbcc4rRh9LaTY2pkI;D>KB6t+p<9q92U{K-BBt32x~@p9#O&)E$WiVsEcb_q zXvMng+3cx`>HS@1(>lvm9AFrE`0!!K;hd6Bo*o{ekX>I_5_1ponO{(W%tajNB;HFH z0~Y5SZnrC`SmAF?;jjGaN_x`06UjaC>8xIj>G=;G$}5}f-&JLv-sPw(aY=`2UE&5Q z?RNlbP}kPpj1ofz{IZ`+AUF2+b=^U2z-ct?+Fxg2qB*ebsRBe#|HVxOQedShq zxgdg;(shGPuR@xV{yfNK{&j6k^bNlrerbkej{DnPG27NJM{v;9yfY_;H< zqmST`t_ThUtd^pNqy_uSlhY{WfS3YM-BFmRMCq*Rpco$;JK>sz#dKCRi+L=_>C?z0 z;?G;5aM+gQzHHeJy7uce9j{X_!3iB0?VtACeX3><&xRBcehK$F0j=cXO3)f-vm~04 zmh>@X_HDgRdnY-;U9Y z8gpOWAf4ey6)y(^aB_bCok)myGZJglalGXH@Wy(J%rAudjDUb{d}6*GUP{)$e>6V7 zm?wXXs^r%ncuP#7=Q>X+tUz-YtrdZ6Ky>Hm%s7X(Y^_5+%BewYdtWI6Inu?L&+3-?lifu9 zDUK)FX5eoHh#Bh4fLptNj!)!?3Kqv+#oe$HYDG>Sum?bS85jNE5XttxwC#lVrHh|; zC{$O))OgyyBL-hOz0Ns>aZG?kHKM70_WRzn{MtebZ z@C~Pc>*13Zmn?AJ)EBWM1YD^75?Q-(4Coc)x=`}u==?8AqW^ZlEiAT@3eJHXb*qcY zn?~=9l^o2t1jrP1^k`S+P3uUCKT9~7uWFio z-@U^ggPuif3H>rv6AlX4qGw`n7b21N9Mi{#1{4?%vql0WR7tI-L1l zVx)yHkgI`tV=Y+C+bT~;(g7Kf;M4}BxfD8GL|qU{ zVmhHqN{zZzvJ3wlC0zwB2g9Wo|1?oQzk7+2L(ZZZ_EjAG&D-@0$Qi;S7h@m)`!tZBGe2ihLY`8DDz^m_C#DA;28KMR@om`By~pp4(`4+!nQVS?#P<1vV@ z=sDPEPjcpi2g)%4teKa$Z_R6$@rEA~T~d0u4-3CD|3U@lG3$GCMcVMKDAggDc{S}Q zb!DZSn!g)#+?qObYFuhMOZfT9BO zJQbQue%kTB>p2H+yF+MJ?2p;MyFZi*Maa{5$G$5ME69^YF=bu4yCwxq+X@tW2lI|K zGqVw`86{m~PJgrDvFge#*bRETS|Dz-;4Tcxv98ygYhtqD;R#c+m7PTr$w9KLDmfvc z4+Gu}3ghb_r@LYkfyw*yB@I)_EI#0y))gt;&`d2sFmNfaAsGb{*bpHmQ$H;7Kn}pY z!|&fnyMq4;aq<5g#wvlww#@kS1#?OKzl#P#V$kCs`*|>a5DFgdOPM3#ls|ajz`ftc z-eCbr4mp+g>1+wtQP4HEXO>Ybgo1CrhL#nyMd$~nSh29W;H?VXUP0U>g=vI%{qpx& z+bR3`#a}IcG&2p@rMyB(v!8lQSCzj4ZB1G?O=_9YE$8ZDt(B!K@(V9z7Jj;!^8C!q ze4ld(o(tz`1cwAB%!pCDr@zl;o|>*&Y=GW|U0Zg2`}Nw&FY1)~fDQE*w5|TU|I(+Y z{^aUEeVBx~D61c76Eo7*Uv*4u98kD-yS}CxyG^pJycmU6HC#JTcaT-gK)10e+w$8W zo^Ns?B!!SckKrzFJI{sA-@zeU9oK?(gvg!Pw6w!-q>>zJ8(VqeBg{Zc zJk&Q24PL_7>8CGVobrB@<-Vrla&980-%*|3F57-VXL!4)8iiVlCgNs6LAbJOU~#ZV z`+ydsV!meLe(5l=M^O^ zD$S*=RR{cCL4?Y=zlzkitg5Q4;or@O;m6;a6aDSzPw%?^3bimWqQxV(1`avyr?L3y z3JYiU9VkQ@+8PO!gQ9-Au0h$Pc(Zl6qVx3Wp2@DcVZli-RhCRs4B>N>HtMN1{8>lvctoYW=PhJ{eqMjF>W%a~&U6X$Z&n2JUC@lW6KvU_N znN~eJD==-~3n7GVq~b{X^lsJFociZ6)HLEU<*kh)YtXvUF(#&POFk(q+yPIpyU0pC zQ8hdE`3x=y!l7B>zr=^u0bK#(8 z5cd(4l!UTbqZA|?v^c2&(K1<|4L5k@c3bbN1bU6y^~Z{#AORc6?)-axG~`p?Iak({ zwMQkwa-PMco(q25E9X2vISAj$Z7PxSu&`49hi^B@;&`Aj-yj+zWWFXuBjXQ_|8}zp z9u6++JDh_Tfnao1Zk_x#uA^^-?R+z{#%PyL}vR4Kt&WJpuYmbAH-?RNo)zP^2a79(@hX{N1fQC4U7r}@?Cbh40?dOl#mw6uW~~#GJK`m!ll#=^Cb#s${`75q~<{(`g86q zUrGe=u;43AaPQttC2F~@VyzZqD{$v1wBO!DxB@ZEd1_0du7ZqGR{An`@FgC0PQ9!> zjImr#R5(gVU$6bF&JX`=L%5L)E(T#x-_f*buec$u*U+o29p(-=nBy4FI3$^M!>5UxV|l_hzL}>K$mlk>pJ|B2(OsZc z>oHu1La5m80m!)~FUp+H%xc+6laW2M6y1}|S`ix)6EB7i4TjSKi6`F0{@`7T3FtwV zBoi{2fue>w9cD9r*#bElsiY+z;=lNujZPDYqzz!_%5P@J&5aacL8W@Y2nW-eP=zBA z5j%J7+GTxLU>sy{2{9@o$vUOVyO>sH5o;F(d`-Wm^hGcHEy`5Y+PoQ= zBkegcYwLAd6V`(bF*4%&)YBW+EzBJCuC&~^bH4_?7rmlq@*(G3_&iE=F+|Yfe=0jl z9k$u3ui}-&rDhKZghjj)G2+qO0Wx!>)6SUC>3_riFgLpDWA*VNLx*l8hBMARBx(iA zn_>dqB%Sz>)gK-{ot6{xS^3qkiIG#pr3%`^6=Fm3n$vr~QS`duX_Ll}wh4?2d z^prNI_!8SWs^!5@9B;EXl(H)aNo%Qs@cSIB+mFU2+f;B@PKBNSH*os&A=j@cz8%z z&|{cEpOSwG`REEU0q!fZ*5J;5r>eHOU^9{wXvo*R+{K~GY2ePxxEd%XV!nLWu*0f> z#r=7f2&nZ#EnU{;yOUK6=|mhzu3^Lytbmd^%!@`lX_N98V1`&WHw0mQeP=p`9qX>4 ziWFZ`2N=mR3%Bp^!$D~~Zq#r~NQkgBF5Er=)-k_Vd!>!{{Y_>z`;3#z_KT&OinSnZ za_NT;o2h>S9)FAv^QoXd6Ol^~mO-f{YRj%|_P3P#DeeOlk{8p_xjT{5|vC}Y1QhUH^ z>7ZP8KKf+gSAp4Stzi*y)o_$7_nR1-nIz%;vNWspdRFeM#G0>4ljnbzW}fZ{Z_kbS z7pg|-1?twRrYaMlv4q25qguM<2@M&E3-I&m?P>y0Wez*)F^_{)v4)7kF*4nOM0NdR zy^PDCLc%)JmUajYXG-DuG1*wf30C=BbHkCKZe+XirFjrC%gZCqQl(Q&3_8pjOEBG=*HSP;O7CTNuj4-?sk(3l-tj$eKw z?Cx8^_hl|E(UDPM{TDj35&s(+B5)!%NL?ol6ZN0_W-6VHbT@lL960bI#ccMnTiEF( z&s>NKP6VR}h#64fF4|ieX0h4G@zGZvA`%gp90{WY-L$_y6ab{^QeL$z35M%iTH z;llaw_^zE@*6ulUNNvfIPu5z&-kDs4G}N%O@N>ruMt`C3kkJYpr`%Zo0FcR;u9}*m zFQz*pWaPnP(al@%V0@Y-=#~5q*0>N|U`J1Cc5y6ED(S8;uwC=i1-E$4H_<|Uf8epV z^uUOvQ;d*yU9DmxK6^=NESQyD_ zJG=h-s_ku~IQolwu?>75SEHO;$uw&@Hw`_Vn8-wGGzDI;B#Cntb2mv1$(nASHsoL0 zk=;PD$ooi;FYy_+c<=qWQqHhmsnpK$cl-wK#obw+Wu?$$cwhZz9+BU}ptNpKm~CUI z=fd|#=Yxt#@Y(AX*a&}Td=(_yza40Fb;g;{hmM>ZRG22b0f)FAC4vs}XUPp|iYh4l z-R&Ooxw}~gTd{waw5D-oSOHZs2Bk4wcQZFaO{StJ6<(iVG@hjI!gU{YaQ!Vwaz_U$ z*9E7%1auIy1w|nj2AKC7_fLChUO}Ip9v=8r#HJM>j5aO57_@HqQ}TH9;Z}$S_%KgpT9TV{4`Qpp-&z)rxEV z*N=6a_izB_<(E~w-wBwsBZ%HgM&{tPuQXVw zI9a>upETbNg3A-gk6MV#xTB7ryUZVOP(@Ys2K1s7JqnYJY5?TVIscU0Rp^?ye`nze zf>Yd=mlzFN#_MM!Bxz0ohYvePsH9P{69+2;<76Z##h7h^nw_$Vdf4@jUlkP8>nDse zvD-X`Hk-L>>~91gapi;mTutnhycu%0WdIhP)$b9Gz>_I|?=TxhV3~5bbuiKxxz?zV z)_z*gK_F4Ta76rmg`@wTEBpLrAbXz3Rw>}87=#{sx-ix0?+%?iC$TV+PzED1DhTUpSkBHSz*3MXYRjBnrJ%^XV|*bqoKy1a7oI*8cH6} zP&%`0wKNJAxEMs`3R^RjptWsd#h3`Z<*lgz<11?WAk)aCVej1++^&v;L&M8V5f2>kWc8CGV8mYl)tjzKQy#F3%PzEOU1^!`n)mBweSC zO=R7PC6wAAh{RjSWEW`d-rDiw!%iX0ez|B(?#e@obn#2$ry_3q@GmXxhB zGP6POEMFMDus>N0*S>!^tT#%}L_M+b_VPw_O0uQ^#YE@}2oksc_S^v`FWKtI!&V)DUi@Y70l#y zqvXV=Y3k{Du{6G${YQ5HEEI%lrwR5ud--xOOgoc&cuYJj>h~^t@5@M`-4=Eq^Yiio ze*-1LLxBpQ;K^P1>ysc7C`qNvV&_x;%V=Fb%_>*U&s@vIM!aq5byApGC4Yj6N-lRbKeWv(R2Pm|z(U?T>6ZwL-< z%3o1U=9n&?rC@|(nu{J9LpW&6Y~t*#vfC93uQav`KyWd_FIf1j{3LT;lHi&rNP=@-K%uXagL!elu z&a~wQkZdzB$Vhr1_Bxw`K-rEXM~)mmuSqwRK;5Io4hoM5k{I3aeR98c&DWDdmFg4} zZ-^9BW*ACJF+D4{Ce4U_YZdHG9ECDjip4Efc8b-kPkyv)C_zH5Tp1=oAVfO%`>R#2 zQGyJKLO@y$nJvgIxW@Y$*Bm-!qKX_+BY-Ly)znCk6RL#{|2AzAsH-xz;+Xr@;a)d)G2`e5&=TvaF^1JsHqjE1jsZR3hFie>xpCUVs;ZwA^Z3NpyEHFJ z6(G6nTfGCXTXLXjnPlG49n?ZHLYlIddEslkji_kax~`w~WU$-{&F?pBw1QI6_{W#A zV%bJTncOMt4vE=-)jHz(Lk2&{yR%4-2*;Ao!T(U_(mwz=L44T~2n<}vrlCk>jNRhL z7ik~0drv#I_hx%m#7~njMHyT=`p1_>2y`Tr-*=mpA*iP$tw4CSxx2G-?!D$!ToJ+x z3n>IT*kaqWegxnPcgb;Ci-}NitI_E;f#NTxeTzd(^HW&eVi`j+83CJd(<(a(ejrzG4NJ znPAhu3?4AR`*rGz&mSxta$o(b9*S)Ab&$_S*Y^x3ln7RDt@SD1Kl9cX^!2&!BU6gR zu>mmH#N13>xx(AFG3ebkO!(o;`j_gfJqZP9NvL)QL*QzBi@# zXna|e>RUh~>GgV!{J_P`&OlFe_D&v)-K*e~(hAN^6s_6Iim5`*o`dpo6&yRwIow(F3P=6@6`4F`;W=~dtL2{DF46o; z**9L?OrPfsZ98%b(QGc7E7&2^%tp0fw_ zBd1u5s_Hf+btaySxU{riSKsny>}X6gUazp*IqK&xTg~j))X!cPjS+iZORV&97$bx~EMqz7*?QB`whM;U=Q=g*!!M$sS3 zd%Jj-!4#)Rd8@3w#s@3~)wfA;ZNJ@o!U@}usNvVsc9dskX2!z$+Ry}s@4(4DK~E#Z zJlaOH>PLP3QlC-lu4hL+3U15E@J2Pe`$Eb%ZnD@>d)KU5g&NZ~W)6UjjC4{Qd9|VT z-_@X*3LX!#{(1iVxPb{KgkS%>g>jJZhX44p&~R{*KLqirSce^$0FJ3CuW;PRd^QY$ z%3u6z=0_N%*4}8^+3oespzucwM!3VtZGTzqsIUKqo?-D!Ne=kv-=nYh^=unk+ra*F z?wsYo{XzDRK&p2Lcf`uOmIPx_JTeZ>oR#kO^YI_n7YbuI}$D^7Clzw_y9s#{o zK|sobM~`+Wjrm?*A3t~|8BzQ)NqJfvo`Tw}l=^#dxR3m_8*Wn~)_+x{5vsbG+qre? z$l*;DGTi#<1Gd-wF{+;TW~PIB)ajbnxwweW*It!!glx@gaNwL*2`No#b%kRKpwt9= zx5>x;Er|l5JfyY`kr71P+M|}e#bLyFY;)RMr#X~VVn?BeNIKeQqOQ6`9@3#SIX8L) zM;N`%O^}zWQJR5tb@5roMP0^jc0;I%|E&?=dgb7gj+hcRl4#Bz3#PX36ycATkmc&( zbgp13jZf`|!^`EmrlXB7uwKjdQwVspq{-U%uwl}hVh;W9$0uaYctV2ZOb1# z00L|dbY>3IwbQ+WVc}pn1$*0HwHKEdRBtM zKd*T+9FP5IozB4^$mIjwO2Cpz%1 z`ug|WtVROQiEoUqHwafReNa?YU^_0n#0#Ao7qvv%Ec_a{5|!}|?&vvK;boc$#ng~H z-%X{@oiM?KuS#iIgu#NoW8$Gf6Jp+a9i%9goL&%9X(>)lJQzs$qo~thcD(NNV&{h51)damj(|R5~t)!+q%!PJ3U=fEa2cbP@N(G zY;U-x?`{iW24SGkxX~MOX*NaCFB6ovfsfDO&TNueewYt7y3|v_&jF&FJt7q((UYS4 zg1}Tzz-NZ(e#8B_B!mlF$UDL4p%%o$U+C^`|1%ufT#vmsZr@fGEf-x51ZWUH{?^l{ zHhahBHlt=lX9lP)P6qL$ai#kBjG!u^)p1+4tR>hKRUP#n{~!ib^7`tR3HhX~1iZx3 z;=dsI35e3C?xXLJMu-3|xPk r03)`q?q5CYs?F^=$^wg{e|6Sf{lYLSL$y?a|4cBm9(TsnE%5&U6z8b_ literal 0 HcmV?d00001 diff --git a/clones/www.sbcl.org/sbcl-internals/ex_003abuggycache.html b/clones/www.sbcl.org/sbcl-internals/ex_003abuggycache.html new file mode 100644 index 00000000..623a7c49 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/ex_003abuggycache.html @@ -0,0 +1 @@ + diff --git a/clones/www.sbcl.org/sbcl-internals/ex_003apred.html b/clones/www.sbcl.org/sbcl-internals/ex_003apred.html new file mode 100644 index 00000000..cefd010a --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/ex_003apred.html @@ -0,0 +1 @@ + diff --git a/clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue.html b/clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue.html new file mode 100644 index 00000000..9ba3c853 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue.html @@ -0,0 +1 @@ + diff --git a/clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue_002dusing_002dclass.html b/clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue_002dusing_002dclass.html new file mode 100644 index 00000000..9a93daaf --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/ex_003aslot_002dvalue_002dusing_002dclass.html @@ -0,0 +1 @@ + diff --git a/clones/www.sbcl.org/sbcl-internals/fig_003adfun_002dtransitions.html b/clones/www.sbcl.org/sbcl-internals/fig_003adfun_002dtransitions.html new file mode 100644 index 00000000..9a11ccad --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/fig_003adfun_002dtransitions.html @@ -0,0 +1 @@ + diff --git a/clones/www.sbcl.org/sbcl-internals/index.html b/clones/www.sbcl.org/sbcl-internals/index.html new file mode 100644 index 00000000..899781b7 --- /dev/null +++ b/clones/www.sbcl.org/sbcl-internals/index.html @@ -0,0 +1,166 @@ + + +SBCL Internals + + + + + + + + + + +

    SBCL Internals

    +
    +

    Table of Contents

    + +
    + + + +
    +

    + +Up: (dir) +

    +
    + + +

    SBCL Internals

    + +
    +This manual is part of the SBCL software system. See the +README file for more information. + +

    This manual is in the public domain and is provided with absolutely no +warranty. See the COPYING and CREDITS files for more +information. +

    + + + + + From 18b0878e63e602fd0ce7a2f43be14f4c56afc9db Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 20:43:29 +0100 Subject: [PATCH 11/15] Update slime HyperSpec url --- bundle/bundle--package.el | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/bundle/bundle--package.el b/bundle/bundle--package.el index 49f79fff..ef13b6fe 100644 --- a/bundle/bundle--package.el +++ b/bundle/bundle--package.el @@ -178,6 +178,13 @@ slime-indentation slime-editing-commands slime-sbcl-exts)) + (progn + (setq common-lisp-hyperspec-root + (concat "file://" (expand-file-name "~/.emacs.d/clones/lisp/HyperSpec-7-0/HyperSpec/"))) + (setq common-lisp-hyperspec-symbol-table + (concat common-lisp-hyperspec-root "Data/Map_Sym.txt")) + (setq common-lisp-hyperspec-issuex-table + (concat common-lisp-hyperspec-root "Data/Map_IssX.txt"))) (when (eq system-type 'windows-nt) (setq sbcl-exe "C:\\Program Files\\Steel Bank Common Lisp\\sbcl.exe" sbcl-core "C:\\Program Files\\Steel Bank Common Lisp\\sbcl.core" @@ -248,5 +255,14 @@ (mastodon-instance-url "https://emacs.ch") (mastodon-active-user "qhBidG3d")) +;; (eval-after-load "slime" +;; '(progn +;; (setq common-lisp-hyperspec-root +;; (concat "file://" (expand-file-name "~/.emacs.d/clones/lisp/HyperSpec-7-0/HyperSpec/"))) +;; (setq common-lisp-hyperspec-symbol-table +;; (concat common-lisp-hyperspec-root "Data/Map_Sym.txt")) +;; (setq common-lisp-hyperspec-issuex-table +;; (concat common-lisp-hyperspec-root "Data/Map_IssX.txt")))) + (load "bundle--irc") (load "bundle--news") From 37b866d84918bd6395543ca6af00943bb3a41605 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 22:00:14 +0100 Subject: [PATCH 12/15] Replace if with when --- bundle/bundle--package.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bundle/bundle--package.el b/bundle/bundle--package.el index ef13b6fe..317b6231 100644 --- a/bundle/bundle--package.el +++ b/bundle/bundle--package.el @@ -193,8 +193,7 @@ (when (eq system-type 'gnu/linux) (setq inferior-lisp-program "/usr/bin/sbcl --noinform")) (let ((helper (expand-file-name "~/quicklisp/slime-helper.el"))) - (if (file-exists-p helper) - (load helper))) + (when (file-exists-p helper) (load helper))) (add-to-list 'slime-filename-translations (slime-create-filename-translator :machine-instance "ubuntu-2gb-nbg1-1" From 067abccc54b665ecc475dcc0c218d4331e1f26b7 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Wed, 18 Jan 2023 22:22:27 +0100 Subject: [PATCH 13/15] Remove slime filename translations --- bundle/bundle--package.el | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/bundle/bundle--package.el b/bundle/bundle--package.el index 317b6231..193e480a 100644 --- a/bundle/bundle--package.el +++ b/bundle/bundle--package.el @@ -193,12 +193,7 @@ (when (eq system-type 'gnu/linux) (setq inferior-lisp-program "/usr/bin/sbcl --noinform")) (let ((helper (expand-file-name "~/quicklisp/slime-helper.el"))) - (when (file-exists-p helper) (load helper))) - (add-to-list 'slime-filename-translations - (slime-create-filename-translator - :machine-instance "ubuntu-2gb-nbg1-1" - :remote-host "ubuntu-2.marcuskammer.de" - :username "marcus"))) + (when (file-exists-p helper) (load helper)))) (use-package simple-httpd :defer t) From da4182d777898fb9cad89c184eb35eecd83f0294 Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Thu, 19 Jan 2023 11:00:04 +0100 Subject: [PATCH 14/15] If windows use another file path --- bundle/bundle--package.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bundle/bundle--package.el b/bundle/bundle--package.el index 193e480a..31d12bbd 100644 --- a/bundle/bundle--package.el +++ b/bundle/bundle--package.el @@ -180,7 +180,9 @@ slime-sbcl-exts)) (progn (setq common-lisp-hyperspec-root - (concat "file://" (expand-file-name "~/.emacs.d/clones/lisp/HyperSpec-7-0/HyperSpec/"))) + (let ((file (if (eq system-type 'windows-nt) "file:///" "file://"))) + (concat file + (expand-file-name "~/.emacs.d/clones/lisp/HyperSpec-7-0/HyperSpec/")))) (setq common-lisp-hyperspec-symbol-table (concat common-lisp-hyperspec-root "Data/Map_Sym.txt")) (setq common-lisp-hyperspec-issuex-table From 66d10b80daca560956f59d898ea8bf3b6771714b Mon Sep 17 00:00:00 2001 From: Marcus Kammer Date: Thu, 19 Jan 2023 17:12:32 +0100 Subject: [PATCH 15/15] Update sbcl slime inferior lisp program path for windows --- bundle/bundle--package.el | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/bundle/bundle--package.el b/bundle/bundle--package.el index 31d12bbd..05a68b5a 100644 --- a/bundle/bundle--package.el +++ b/bundle/bundle--package.el @@ -187,12 +187,11 @@ (concat common-lisp-hyperspec-root "Data/Map_Sym.txt")) (setq common-lisp-hyperspec-issuex-table (concat common-lisp-hyperspec-root "Data/Map_IssX.txt"))) - (when (eq system-type 'windows-nt) + (if (eq system-type 'windows-nt) (setq sbcl-exe "C:\\Program Files\\Steel Bank Common Lisp\\sbcl.exe" sbcl-core "C:\\Program Files\\Steel Bank Common Lisp\\sbcl.core" inferior-lisp-program "sbcl" - slime-lisp-implementations `((sbcl (,sbcl-exe "--core" ,sbcl-core))))) - (when (eq system-type 'gnu/linux) + slime-lisp-implementations `((sbcl (,sbcl-exe "--noinform" "--core" ,sbcl-core)))) (setq inferior-lisp-program "/usr/bin/sbcl --noinform")) (let ((helper (expand-file-name "~/quicklisp/slime-helper.el"))) (when (file-exists-p helper) (load helper))))