forked from nenbutsu/ISLispHyperDraft
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathislisp-v23.html
6104 lines (4916 loc) · 523 KB
/
islisp-v23.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="stylesheet.css" />
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" type="image/gif" href="animated_favicon1.gif" />
<title>Programming Language ISLISP Working Draft 23.0</title>
</head>
<body>
<div id="sidebar">
<h2>Contents</h2>
<ol>
<li><a href="#scope">Scope</a></li>
<li><a href="#normative_references">Normative references</a></li>
<li><a href="#compliance">Compliance of ISLisp processors and text</a></li>
<li><a href="#terms_and_definitions">Terms and definitions</a></li>
<li><a href="#notation_and_conventions">Notation and conventions</a></li>
<li><a href="#lexemes">Lexemes</a>
<ol>
<li><a href="#separators">Separators</a></li>
<li><a href="#comments">Comments</a></li>
</ol>
</li>
<li><a href="#textual_representation">Textual representation</a></li>
<li><a href="#reserved_identifiers">Reserved identifiers</a></li>
<li><a href="#errors">Errors</a>
<ol>
<li><a href="#classes_of_error_specification">Classes of error specification</a></li>
<li><a href="#pervasive_error_types">Pervasive error types</a></li>
</ol>
</li>
<li><a href="#classes">Classes</a>
<ol>
<li><a href="#metaclasses">Metaclasses</a></li>
<li><a href="#predefined_classes">Predefined classes</a></li>
<li><a href="#standard_classes">Standard classes</a>
<ol>
<li><a href="#slots">Slots</a></li>
<li><a href="#creating_instances">Creating instances of classes</a></li>
</ol>
</li>
</ol>
</li>
<li><a href="#scope_and_extent">Scope and extent</a>
<ol>
<li><a href="#the_lexical_principle">The lexical principle</a></li>
<li><a href="#scope_of_identifiers">Scope of identifiers</a></li>
<li><a href="#some_specific_scope_rules">Some specific scope rules</a></li>
<li><a href="#extent">Extent</a></li>
</ol>
</li>
<li><a href="#forms_and_evaluation">Forms and evaluation</a>
<ol>
<li><a href="#forms">Forms</a></li>
<li><a href="#function_application_forms">Function application forms</a></li>
<li><a href="#special_forms">Special forms</a></li>
<li><a href="#defining_forms">Defining forms</a></li>
<li><a href="#macro_forms">Macro forms</a></li>
<li><a href="#the_evaluation_model">The evaluation model</a></li>
<li><a href="#functions">Functions</a></li>
<li><a href="#defining_operators">Defining operators</a></li>
</ol>
</li>
<li><a href="#predicates">Predicates</a>
<ol>
<li><a href="#boolean_values">Boolean values</a></li>
<li><a href="#class_predicates">Class predicates</a></li>
<li><a href="#equality">Equality</a></li>
<li><a href="#logical_connectives">Logical connectives</a></li>
</ol>
</li>
<li><a href="#control_structure">Control structure</a>
<ol>
<li><a href="#constants">Constants</a></li>
<li><a href="#variables">Variables</a></li>
<li><a href="#dynamic_variables">Dynamic variables</a></li>
<li><a href="#conditional_expressions">Conditional expressions</a></li>
<li><a href="#sequencing_forms">Sequencing forms</a></li>
<li><a href="#iteration">Iteration</a></li>
<li><a href="#non_local_exits">Non-local exits</a></li>
<li><a href="#establishing_and_invoking_non_local_exits">Establishing and invoking non-local exits</a></li>
<li><a href="#assuring_data_consistency">Assuring data consistency during non-local exits</a></li>
</ol>
</li>
<li><a href="#objects">Objects</a>
<ol>
<li><a href="#defining_classes">Defining classes</a>
<ol>
<li><a href="#determining_the_class_precedence">Determining the class precedence list</a></li>
<li><a href="#accessing_slots">Accessing slots</a></li>
<li><a href="#inheritance_of_slots">Inheritance of slots and slot options</a></li>
</ol>
</li>
<li><a href="#generic_functions">Generic functions</a>
<ol>
<li><a href="#defining_generic_functions">Defining generic functions</a></li>
<li><a href="#defining_methods">Defining methods for generic functions</a>
<ol>
<li><a href="#agreement_on_parameter_specializers">Agreement on parameter specializers and qualifiers</a></li>
<li><a href="#congruent_lambda_lists">Congruent lambda-lists for all methods of a generic function</a></li>
</ol>
</li>
<li><a href="#inheritance_of_methods">Inheritance of methods</a></li>
</ol>
</li>
<li><a href="#calling_generic_functions">Calling generic functions</a>
<ol>
<li><a href="#selecting_the_applicable_methods">Selecting the applicable methods</a></li>
<li><a href="#sorting_the_applicable_methods">Sorting the applicable methods</a></li>
<li><a href="#applying_methods">Applying methods</a>
<ol>
<li><a href="#simple_method_combination">Simple method combination</a></li>
<li><a href="#standard_method_combination">Standard method combination</a></li>
</ol>
</li>
<li><a href="#calling_more_general_methods">Calling more general methods</a></li>
</ol>
</li>
<li><a href="#object_creation">Object creation and initialization</a>
<ol>
<li><a href="#initialize_object">Initialize-object</a></li>
</ol>
</li>
<li><a href="#class_enquiry">Class enquiry</a></li>
</ol>
</li>
<li><a href="#macros">Macros</a></li>
<li><a href="#declarations_and_coercions">Declarations and coercions</a></li>
<li><a href="#symbol_class">Symbol class</a>
<ol>
<li><a href="#symbol_names">Symbol names</a>
<ol>
<li><a href="#notation_for_symbols">Notation for symbols</a></li>
<li><a href="#alphabetic_case_in_symbol_names">Alphabetic case in symbol names</a></li>
<li><a href="#nil_and">nil and ()</a></li>
</ol>
</li>
<li><a href="#symbol_properties">Symbol properties</a></li>
<li><a href="#unnamed_symbols">Unnamed symbols</a></li>
</ol>
</li>
<li><a href="#number_class">Number class</a>
<ol>
<li><a href="#number_class_2">Number class</a></li>
<li><a href="#float_class">Float class</a></li>
<li><a href="#integer_class">Integer class</a></li>
</ol>
</li>
<li><a href="#character_class">Character class</a></li>
<li><a href="#list_class">List class</a>
<ol>
<li><a href="#cons">Cons</a></li>
<li><a href="#null_class">Null class</a></li>
<li><a href="#list_operations">List operations</a></li>
</ol>
</li>
<li><a href="#arrays">Arrays</a>
<ol>
<li><a href="#array_classes">Array classes</a></li>
<li><a href="#general_arrays">General arrays</a></li>
<li><a href="#array_operations">Array operations</a></li>
</ol>
</li>
<li><a href="#vectors">Vectors</a></li>
<li><a href="#string_class">String class</a></li>
<li><a href="#sequence_functions">Sequence functions</a></li>
<li><a href="#stream_class">Stream class</a>
<ol>
<li><a href="#streams_to_files">Streams to files</a></li>
<li><a href="#other_streams">Other streams</a></li>
</ol>
</li>
<li><a href="#input_and_output">Input and output</a>
<ol>
<li><a href="#argument_conventions">Argument conventions for input functions</a></li>
<li><a href="#character_io">Character I/O</a></li>
<li><a href="#binary_io">Binary I/O</a></li>
</ol>
</li>
<li><a href="#files">Files</a></li>
<li><a href="#condition_system">Condition system</a>
<ol>
<li><a href="#conditions">Conditions</a></li>
<li><a href="#signaling_and_handling">Signaling and handling conditions</a>
<ol>
<li><a href="#operations_relating_to_condition_signaling">Operations relating to condition signaling</a></li>
<li><a href="#operations_relating_to_condition_handling">Operations relating to condition handling</a></li>
</ol>
</li>
<li><a href="#data_associated_with_condition_classes">Data associated with condition classes</a>
<ol>
<li><a href="#arithmetic_errors">Arithmetic errors</a></li>
<li><a href="#domain_errors">Domain errors</a></li>
<li><a href="#parse_errors">Parse errors</a></li>
<li><a href="#simple_errors">Simple errors</a></li>
<li><a href="#stream_errors">Stream errors</a></li>
<li><a href="#undefined_entity_errors">Undefined entity errors</a></li>
</ol>
</li>
<li><a href="#error_identification">Error identification</a></li>
</ol>
</li>
<li><a href="#miscellaneous">Miscellaneous</a></li>
<li><a href="#index">Index</a></li>
</ol>
</div>
<main id="content">
<h1>Programming Language ISLISP</h1>
<div>ISLISP Working Draft 23.0</div>
<p>This document was created Thu 17-Mar-2007 00:10am JST.</p>
<p>Permission to copy all or part of the material in this document, ISLISP Working Draft 23.0, without fee is granted provided that either it is reproduced without modification, or else the portion to be copied no longer identifies itself (through its title or any running headers) as ISLISP Working Draft 23.0.</p>
<p>
The textual material that makes up this document, excluding the cover and any running headers that establish the identity of the document itself as ISLISP Working Draft 23.0, is expressly dedicated to the Public Domain, from which individual, copyrighted works (including any
<a href="https://www.iso.org/obp/ui/#iso:std:iso-iec:13816:ed-2:v1:en">resulting ISO standard</a>) may be non-exclusively derived without fee or other restriction.
</p>
<p>
<a href="https://github.com/nenbutsu">Yuji Minejima</a> ([email protected]) is in charge of this HTML version. (2017 Jul.)
</p>
<p>
Acknowledgment:
<a href="https://github.com/SaitoAtsushi">Atsushi Saito</a> did the first tagging of HTML version. (2017 Jul.)
</p>
<p>
ChangeLog:
<a href="https://github.com/asciian">Masaya Taniguchi</a> added sidebar. (2017/07/30)
</p>
<h2>Introduction</h2>
<p><a href="https://en.wikipedia.org/wiki/ISLISP">The programming language ISLISP</a> is a member of the <a href="https://en.wikipedia.org/wiki/Lisp_(programming_language)">LISP family</a>.</p>
<p>The following factors influenced the establishment of design goals for ISLISP:</p>
<ol>
<li>A desire of the international LISP community to standardize on those features of LISP upon which there is widespread agreement.</li>
<li>The existence of the incompatible dialects <a href="https://en.wikipedia.org/wiki/Common_Lisp">COMMON-LISP</a>, <a href="https://en.wikipedia.org/wiki/EuLisp">EULISP</a>, <a href="https://en.wikipedia.org/wiki/Le_Lisp">LE-LISP</a>, and <a href="https://en.wikipedia.org/wiki/Scheme_(programming_language)">SCHEME</a> (mentioned in alphabetical order).</li>
<li>A desire to affirm LISP as an industrial language.</li>
</ol>
<p>This led to the following design goals for ISLISP:</p>
<ol>
<li>ISLISP shall be compatible with existing LISP dialects where feasible.</li>
<li>ISLISP shall have as a primary goal to provide basic functionality.</li>
<li>ISLISP shall be <a href="https://en.wikipedia.org/wiki/Object-oriented_programming">object-oriented</a>.</li>
<li>ISLISP shall be designed with extensibility in mind.</li>
<li>ISLISP shall give priority to industrial needs over academic needs.</li>
<li>ISLISP shall promote efficient implementations and applications.</li>
</ol>
<h2>Programming Language ISLISP</h2>
<h3 id="scope">Scope</h3>
<p>This document specifies syntax and semantics of the computer programming language ISLISP by specifying requirements for a conforming ISLISP processor and a conforming ISLISP text.</p>
<p>This document does not specify:</p>
<ul>
<li>the size or complexity of an ISLISP text that exceeds the capacity of any specific data processing system or the capacity of a particular processor, nor the actions to be taken when the corresponding limits are exceeded;</li>
<li>the minimal requirements of a data processing system that is capable of supporting an implementation of a processor for ISLISP;</li>
<li>the method of preparation of an ISLISP text for execution and the method of activation of this ISLISP text, prepared for execution;</li>
<li>the typographical presentation of an ISLISP text published for human reading.</li>
<li>extensions that might or might not be provided by the implementation.</li>
</ul>
<h3 id="normative_references">Normative references</h3>
<p>The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.</p>
<ul>
<li>ISO/IEC TR 10034:1990, <span class="standard_title">Guidelines for the preparation of conformity clauses in programming language standards.</span></li>
<li>IEEE standard 754-1985. <span class="standard_title">Standard for binary floating point arithmetic.</span></li>
</ul>
<h3 id="compliance">Compliance of ISLisp processors and text</h3>
<p>An ISLISP processor complying with the requirements of this document shall</p>
<ul>
<li>accept and implement all features of ISLISP specified in this document.</li>
<li>reject any text that contains any textual usage which this document explicitly defines to be a violation (see <a href="#errors">§9</a>).</li>
<li>be accompanied by a document that provides the definitions of all <a href="#td_implementation_defined">implementation-defined</a> features.</li>
<li>be accompanied by a document that separately describes any features accepted by the processor that are not specified in this document; these extensions shall be described as being <q>extensions to ISLISP as
specified by ISLISP Working Draft 23.0.</q></li>
</ul>
<p>A complying ISLISP text shall not rely on <a href="#td_implementation_dependent">implementation-dependent</a> features. However, a complying ISLISP text may rely on <a href="#td_implementation_defined">implementation-defined</a> features required by this document.</p>
<p id="constant_violation">A complying ISLISP text shall not attempt to create a lexical variable binding for any named constant defined in this document. It is a violation if any such attempt is made.</p>
<h3 id="terms_and_definitions">Terms and definitions</h3>
<p>For the purposes of this document, the following terms and definitions apply.</p>
<h4 id="td_abstract_class" class="term">abstract class</h4>
<p>class that by definition has no direct instances</p>
<h4 id="td_activation" class="term">activation</h4>
<p>computation of a function</p>
<div class="note">Note: Every activation has an activation point, an activation period, and an activation end. The activator, which is a function application form prepared for execution, starts the activation at the activation point.</div>
<h4 id="td_accessor" class="term">accessor</h4>
<p>association of a reader and a writer for a slot of an instance</p>
<h4 id="td_argument_position" class="term">argument position</h4>
<p>occurrence of a text unit as an element in a form excluding the first one</p>
<h4 id="td_binding" class="term">binding</h4>
<p>concept that has both a syntactic and a semantic aspect, where</p>
<ul>
<li>syntactically, <q>binding</q> describes the relation between an identifier and a binding ISLISP form, and</li>
<li>semantically, <q>binding</q> describes the relation between a variable, its denoting identifier, and an object (or, the relation between a variable and a location)</li>
</ul>
<div class="note">Note 1: The property of being bound can be checked textually by relating defining and applied identifier occurrences.</div>
<div class="note">Note 2: Semantically, the binding relation might be imagined to be materialized in some entity, the binding. Such a binding entity is constructed at run time and destroyed later, or might have indefinite extent.</div>
<h4 id="td_class" class="term">class</h4>
<p>object that determines the structure and behavior of a set of other objects called its instances</p>
<div class="note">Note: The behavior is the set of operations that can be performed on an instance.</div>
<h4 id="td_condition" class="term">condition</h4>
<p>object that represents a situation that has been (or might be) detected by a running program</p>
<h4 id="td_definition_point" class="term">definition point</h4>
<p>textual point of an ISLISP text that is the start of an identifier's representation of an ISLISP object</p>
<h4 id="td_direct_instance" class="term">direct instance</h4>
<p>instance of a class but not an instance of one of its subclasses</p>
<div class="note">Note: Every ISLISP object is direct instance of exactly one class, which is called <q>its class</q>. The set of all direct instances together with their behavior constitute a class.</div>
<h4 id="td_dynamic" class="term">dynamic</h4>
<p>having an effect that is determined only through program execution and that cannot, in general, be determined statically</p>
<h4 id="td_dynamic_variable" class="term">dynamic variable</h4>
<p>variable whose associated binding is determined by the most recently executed active block that established it, rather than statically by a lexically apparent block according to the lexical principle</p>
<h4 id="td_evaluation" class="term">evaluation</h4>
<p>computation of a form prepared for execution which results in a value and/or a side-effect</p>
<h4 id="td_execution" class="term">execution</h4>
<p>sequence of (sometimes nested) activations</p>
<h4 id="td_extension" class="term">extension</h4>
<p><a href="#td_implementation_defined">implementation-defined</a> modification to the requirements of this document that does not invalidate any ISLISP text complying with this document (except by prohibiting the use of one or more particular spellings of identifiers), does not alter the set of actions which are required to signal errors, and does not alter the status of any feature designated as <a href="#td_implementation_dependent">implementation dependent</a></p>
<h4 id="td_form" class="term">form</h4>
<p>single, syntactically valid unit of program text, capable of being prepared for execution</p>
<h4 id="td_function" class="term">function</h4>
<p>ISLISP object that is called with arguments, performs a computation (possibly having side-effects), and returns a value</p>
<h4 id="td_generic_function" class="term">generic function</h4>
<p>function whose application behavior is determined by the classes of the values of its arguments and which consists - in general - of several methods</p>
<h4 id="td_identifier" class="term">identifier</h4>
<p>lexical element (lexeme) which designates an ISLISP object</p>
<div class="note">Note: In the data structure representation of ISLISP texts, identifiers are denoted by symbols.</div>
<h4 id="td_immutable_binding" class="term">immutable binding</h4>
<p>binding in which the relation between an identifier and the object represented by this identifier cannot be changed</p>
<div class="note">Note: It is a violation if there is attempt to change an immutable binding (error-id. <span class="error_id">immutable-binding</span>).</div>
<h4 id="td_immutable_object" class="term">immutable object</h4>
<p>object which is not subject to change, either because no operator is provided that 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</p>
<div class="note">Note: Except as explicitly indicated otherwise, a conforming processor is not required to detect attempts to modify immutable objects; the consequences are undefined if an attempt is made to modify an immutable object.</div>
<h4 id="td_implementation_defined" class="term">implementation defined</h4>
<p>feature, possibly differing between different ISLISP processors, but completely defined for every processor</p>
<h4 id="td_implementation_dependent" class="term">implementation dependent</h4>
<p>feature, possibly differing between different ISLISP processors, but not necessarily defined for any particular processor</p>
<div class="note">Note: A conforming ISLISP text must not depend upon implementation-dependent features.</div>
<h4 id="td_inheritance" class="term">inheritance</h4>
<p>relation between a class and its superclass which maps structure and behavior of the superclass onto the class</p>
<div class="note">Note: ISLISP supports a restricted form of multiple inheritance; <span class="latin">i.e.</span>, a class may have several direct superclasses at once.</div>
<h4 id="td_instance" class="term">instance</h4>
<p>〈class〉 either a direct instance of a class or an instance of one of its subclasses</p>
<h4 id="td_literal" class="term">literal</h4>
<p>object whose representation occurs directly in a program as a constant value</p>
<h4 id="td_metaclass" class="term">metaclass</h4>
<p>class whose instances are themselves classes</p>
<h4 id="td_method" class="term">method</h4>
<p>case of a generic function for a particular parameter profile, which defines the class-specific behavior and operations of the generic function</p>
<h4 id="td_object" class="term">object</h4>
<p>anything that can be created, destroyed, manipulated, compared, stored, input, or output by the ISLISP processor</p>
<div class="note">Note 1: In particular, functions are ISLISP objects.</div>
<div class="note">Note 2: Objects that can be passed as arguments to functions, can be returned as values, can be bound to variables, and can be part of structures, are called first-class objects.</div>
<h4 id="td_operator" class="term">operator</h4>
<p>first element of a compound form, which is either a reserved name that identifies the form as a special form, or the name of a macro, or a lambda expression, or else an identifier in the function namespace</p>
<h4 id="td_operator_position" class="term">operator position</h4>
<p>occurrence of a text unit as the first element in a form</p>
<h4 id="td_parameter_profile" class="term">parameter profile</h4>
<p>parameter list of a method, where each formal parameter is accompanied by its class name</p>
<div class="note">Note: If a parameter is not accompanied by a class name, it belongs to the most general class.</div>
<h4 id="td_place" class="term">place</h4>
<p>location where objects can be stored and retrieved later</p>
<div class="note">Note: Places are designated by forms which are permitted as the first argument of <span class="terminal">setf</span>. If used this way an object is stored in the place. If the form is not used as first argument of <span class="terminal">setf</span> the stored object is retrieved. The cases are listed in the description of <a href="#s_setf" class="terminal">setf</a>.</div>
<h4 id="td_process" class="term">process</h4>
<p>execution of an ISLISP text prepared for execution</p>
<h4 id="td_processor" class="term">processor</h4>
<p>system or mechanism, that accepts an ISLISP text (or an equivalent data structure) as input, prepares it for execution, and executes the result to produce values and side-effects</p>
<h4 id="td_program" class="term">program</h4>
<p>aggregation of expressions to be evaluated, the specific nature of which depends on context</p>
<div class="note">Note: Within this document, the term “program” is used only in an abstract way; there is no specific syntactic construct that delineates a program.</div>
<h4 id="td_scope" class="term">scope</h4>
<p>〈identifier〉 the textual part of a program where the meaning of that identifier is defined; <span class="latin">i.e.</span>, there exists an ISLISP object designated by this identifier</p>
<h4 id="td_slot" class="term">slot</h4>
<p>named component of an instance which can be accessed using the slot accessors Note: The structure of an instance is defined by the set of its slots.</p>
<h4 id="td_text" class="term">text</h4>
<p>text that complies with the requirements of this document (<span class="latin">i.e.</span>, with the syntax and static semantics of ISLISP)</p>
<div class="note">Note: An ISLISP text consists of a sequence of toplevel forms.</div>
<h4 id="td_toplevel_form" class="term">toplevel form</h4>
<p>any form that either is not nested in any other form or is nested only in progn forms</p>
<h4 id="td_toplevel_scope" class="term">toplevel scope</h4>
<p>scope in which a complete ISLISP text unit is processed</p>
<h4 id="td_writer" class="term">writer</h4>
<p>method associated with a slot of a class, whose task is to bind a value with a slot of an instance of that class</p>
<h3 id="notation_and_conventions">Notation and conventions</h3>
<p>For a clear definition of, and a distinction between, syntactic and semantic concepts, several levels of description abstraction are used in the following.</p>
<p>There is a correspondence from ISLISP textual units to their ISLISP data structure representations. Throughout this document the text and the corresponding ISLISP objects (data structures) are addressed simultaneously. ISLISP text can be seen as an external specification of ISLISP data structures. To distinguish between the two representations different concepts are used. When textual representation is discussed, textual elements (such as <span class="nonterminal">identifiers</span>, <span class="nonterminal">literals</span>, and <span class="nonterminal">compound forms</span>) are used; when ISLISP objects are discussed, <span class="nonterminal">objects</span> (such as <span class="nonterminal">symbols</span> and <span class="nonterminal">lists</span>) are used.</p>
<p id="forms7">The constituents of ISLISP text are called <a href="#td_form" class="term">forms</a>. A <a href="#td_form" class="term">form</a> can be an <a href="#td_identifier" class="nonterminal">identifier</a>, a <a href="#td_literal" class="nonterminal">literal</a>, or a <span class="nonterminal">compound form</span>. A <span class="nonterminal">compound form</span> can be a <span class="nonterminal">function application form</span>, a <span class="nonterminal">macro form</span>, a <span class="nonterminal">special form</span>, or a <span class="nonterminal">defining form</span>.</p>
<p>An <a href="#td_identifier" class="nonterminal">identifier</a> is represented by a <span class="nonterminal">symbol</span>. A <span class="nonterminal">compound form</span> is represented by a non-null <span class="nonterminal">list</span>. A <a href="#td_literal" class="nonterminal">literal</a> is represented by neither a <span class="nonterminal">symbol</span> nor a <span class="nonterminal">list</span>, and so is neither an <a href="#td_identifier" class="nonterminal">identifier</a> nor a <span class="nonterminal">compound form</span>; for example, a number is a literal.</p>
<p id="evaluation_model">An object is <span class="term">prepared for execution</span>; this might include transformation or compilation, including macro expansion. The method of preparation for <span class="term">execution</span> and its result are not defined in this document (with exception of the violations to be detected). After successful preparation for execution the result is ready for execution. The combination of preparation for execution and subsequent execution implements ISLISP's <span class="term">evaluation model</span>. The term “evaluation” is used because ISLISP is an expression language—each form has a value which is used to compute the value of the containing form. The results obtained when an entity is prepared for execution are designated throughout this document by the construction <q>prepared entity</q>; <span class="latin">e.g.</span>, <q>prepared form,</q> <q>prepared special form.</q></p>
<div class="example">A “cond special form” becomes a “prepared cond” by preparation for execution.</div>
<p>In the examples, the metasymbol “⇒” designates the result of an actual evaluation. For example:</p>
<pre>
<span class="input" contenteditable="true">(+ 3 4)</span><button class="eval"> ⇒ </button><span class="output">7</span>
</pre>
<p>The metasymbol <q>→</q> identifies the class that results from the evaluation of a form having a given pattern. For example:</p>
<pre>
(+ <span class="arg">i<sub>1</sub></span> <span class="arg">i<sub>2</sub></span>) → <span class="class">integer</span>
</pre>
<p id="form_patterns">Given a form pattern (usually defined by its constant parts, the function name or special operator), → relates it to the class to which the result of the evaluation of all matching forms belong.</p>
<p>Form patterns or forms which are equivalent are related by ≡.</p>
<p>The following notational conventions for form patterns are used:</p>
<div class="definition-example">
(<span class="operator">f-name</span> <span class="arg">argument</span>*) → <span class="class">result-class</span>
</div>
<p>In this notation, words written in italics are non-terminal (pattern variables). <span class="terminal">f-name</span> is always terminal: Specific function names, special operators, defining form names, or generic function names are always presented.</p>
<p>An underlined term (like the name in a defining form) in this notation, indicates an expression that is not evaluated. If a form might or might not be evaluated (like one of the <span class="nonterminal">then-form</span> or <span class="nonterminal">else-form</span> in an <span class="terminal">if</span>), this is indicated explicitly in the text.</p>
<p>Class names are uniformly denoted as follows: <span class="class">class-name</span>. For example, <span class="class">list</span> is the name of a class; this is usually spoken aloud as <q>list class.</q></p>
<p>Notes, appearing as Note: note-text, in this document have no effect on the language. They are for better understanding by the human reader.</p>
<p>Regarding the pattern variables and the extensions of above, the following conventions are also adopted:</p>
<dl>
<dt><span class="nonterminal">term</span>+</dt>
<dd>denotes one or more occurrences of <span class="nonterminal">term</span>;</dd>
<dt><span class="nonterminal">term</span>*</dt>
<dd>denotes zero or more occurrences of <span class="nonterminal">term</span>;</dd>
<dt>[<span class="nonterminal">term</span>]</dt>
<dd>denotes at most one occurrence of <span class="nonterminal">term</span>, commonly one says that <span class="nonterminal">term</span> is optional;</dd>
<dt>{<span class="nonterminal">term<sub>1</sub></span> <span class="nonterminal">term<sub>2</sub></span> …}</dt>
<dd>denotes grouping of <span class="nonterminal">terms</span>.</dd>
<dt><span class="nonterminal">term<sub>1</sub></span> | <span class="nonterminal">term<sub>2</sub></span> | …</dt>
<dd>denotes grouping of alternative <span class="nonterminal">terms</span>.</dd>
</dl>
<p>The following naming conventions are used to denote forms whose arguments obey the respective class restrictions:</p>
<dl>
<dt><span class="arg">array</span>, <span class="arg">array<sub>1</sub></span> , … <span class="arg">array<sub>j</sub></span> , …</dt>
<dd><span class="class">basic-array</span></dd>
<dt><span class="arg">cons</span>, <span class="arg">cons<sub>1</sub></span> , … <span class="arg">cons<sub>j</sub></span> , …</dt>
<dd><span class="class">cons</span></dd>
<dt><span class="arg">list</span>, <span class="arg">list<sub>1</sub></span> , … <span class="arg">list<sub>j</sub></span> , …</dt>
<dd><span class="class">list</span></dd>
<dt><span class="arg">obj</span> , <span class="arg">obj<sub>1</sub></span> , … <span class="arg">obj<sub>j</sub></span> , …</dt>
<dd><span class="class">object</span></dd>
<dt><span class="arg">sequence</span>, <span class="arg">sequence<sub>1</sub></span> , … <span class="arg">sequence<sub>j</sub></span> , …</dt>
<dd><span class="class">basic-vector</span> or <span class="class">list</span> (see <a href="#sequence_functions">§25</a>)</dd>
<dt><span class="arg">stream</span>, <span class="arg">stream<sub>1</sub></span> , … <span class="arg">stream<sub>j</sub></span> , …</dt>
<dd><span class="class">stream</span></dd>
<dt><span class="arg">string</span>, <span class="arg">string<sub>1</sub></span> , … <span class="arg">string<sub>j</sub></span> , …</dt>
<dd><span class="class">string</span></dd>
<dt><span class="arg">char</span> , <span class="arg">char<sub>1</sub></span> , … <span class="arg">char<sub>j</sub></span> , …</dt>
<dd><span class="class">character</span></dd>
<dt><span class="arg">function</span>, <span class="arg">function<sub>1</sub></span> , … <span class="arg">function<sub>j</sub></span> , …</dt>
<dd><span class="class">function</span></dd>
<dt><span class="arg">class</span>, <span class="arg">class<sub>1</sub></span> , … <span class="arg">class<sub>j</sub></span> , …</dt>
<dd><span class="class">class</span></dd>
<dt><span class="arg">symbol</span> , <span class="arg">symbol<sub>1</sub></span> , … <span class="arg">symbol<sub>j</sub></span> , …</dt>
<dd><span class="class">symbol</span></dd>
<dt><span class="arg">x</span> , <span class="arg">x<sub>1</sub></span> , … <span class="arg">x<sub>j</sub></span> , …</dt>
<dd><span class="class">number</span></dd>
<dt><span class="arg">z</span> , <span class="arg">z<sub>1</sub></span> , … <span class="arg">z<sub>j</sub></span> , …</dt>
<dd><span class="class">integer</span></dd>
</dl>
<p id="conventions">In this document the conventions detailed below are used, except where noted:</p>
<dl>
<dt class="terminal">-p</dt>
<dd>
<p>Predicates—sometimes called <q>boolean functions</q>—usually have names that end in a -p.</p>
<p>Usually every class <span class="class">name</span> has a characteristic function, whose name is built as <span class="nonterminal">name</span>-p if <span class="nonterminal">name</span> is hyphenated (<span class="terminal">generic-function-p</span>), or <span class="nonterminal">name</span>p if <span class="nonterminal">name</span> is not hyphenated (<span class="terminal">symbolp</span>). Note that not all functions whose names end with <q><span class="terminal">p</span></q> are predicates.</p>
</dd>
<dt class="terminal" id="create_">create-</dt>
<dd>Usually a built-in class <span class="class">name</span> has a constructor function, which is called create-<span class="nonterminal">name</span>.</dd>
<dt class="terminal" id="def_">def</dt>
<dd>This is used as the prefix of the defining operators.</dd>
<dt class="terminal">set-</dt>
<dd>Within this document, any functions named set-<span class="nonterminal">name</span> are writers for a place, for which there is a corresponding reader named <span class="nonterminal">name</span>.</dd>
</dl>
<p>For any kind of entity in the language, the phrase <q><span class="nonterminal">entity-kind name</span></q> refers to the entity of kind <span class="nonterminal">entity-kind</span> denoted by <span class="nonterminal">name</span>. For example, the phrases <q>function <span class="nonterminal">name</span></q>, <q>constant <span class="nonterminal">name</span></q>, or <q>class <span class="nonterminal">name</span></q> respectively mean the function, constant, or class denoted by <span class="nonterminal">name</span>.</p>
<h3 id="lexemes">Lexemes</h3>
<p>An ISLISP text is built up from lexemes. Lexemes are built up from at least the following characters (<a href="#character_class">see §20</a>):</p>
<pre>
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 + - < > / * & = . ? _ ! $ % : @ [ ] ^ { } ~ #
</pre>
<p>Additional characters are <a href="#td_implementation_defined">implementation defined</a>.</p>
<p>The following characters are individual lexemes (see <a href="#macros">§16</a> and <a href="#cons">§21.1</a>):</p>
<pre>
( ) , ' `
</pre>
<p>The following character tuples (where <span class="nonterminal">n</span> is a sequence of digits) are individual lexemes (see <a href="#functions">§12.7</a>, <a href="#macros">§16</a>, and <a href="#array_classes">§22.1</a>):</p>
<pre>
#' #( ,@ #B #b #O #o #X #x #na #nA
</pre>
<p>
The textual representations of symbols (see <a href="#symbol_class">§18</a>), numbers (see <a href="#number_class">§19</a>), characters (see <a href="#character_class">§20</a>), and strings (see <a href="#string_class">§24</a>) are lexemes.
</p>
<p>\ (single escape) and | (multiple escape) are special characters. They may occur in some lexemes (identifiers and string literals).</p>
<p>Other lexemes are separated by delimiters. Delimiters are separators along with the following characters:</p>
<pre>
( ) ` , '
</pre>
<p>The effect of delimiting is disestablished inside a string (see <a href="#string_class">§24</a>) or inside a corresponding pair of multiple escape characters (see <a href="#symbol_class">§18</a>) or for the character immediately following #\.</p>
<h4 id="separators">Separators</h4>
<p>Separators are as follows: blank, comments, newline, and an <a href="#td_implementation_defined">implementation-defined</a> set of characters, (<span class="latin">e.g.</span>, tabs). Separators have no meaning and can be replaced by each other without changing the meaning of the ISLISP text.</p>
<h4 id="comments">Comments</h4>
<p>The character semicolon (;) is the comment begin character. That is, the semicolon and all the characters up to and including the end-of-line form a comment.</p>
<p>A character sequence beginning with #| and ending with |# is a comment. Such comments may be nested.</p>
<p>Being a separator, a comment cannot occur inside a lexeme.</p>
<h3 id="textual_representation">Textual representation</h3>
<p>The textual representation of an object is machine independent. The following are some of the textual representations of the ISLISP objects. This representation is readable by the read function. Lexemes are described in <a href="#lexemes">§6</a></p>
<dl>
<dt class="classname" id="null10">Null</dt>
<dd>The object <span class="terminal">nil</span> is the only object whose class is <span class="class">null</span>. Upon input, it may be written as <span class="terminal">nil</span> or <span class="terminal">()</span>. It is <a href="#td_implementation_defined">implementation defined</a> whether <span class="terminal">nil</span> prints as <span class="terminal">nil</span> or <span class="terminal">()</span>.</dd>
<dt class="classname" id="list10">List</dt>
<dd>Proper lists are those lists terminated by <span class="terminal">nil</span>. Usually they are denoted as (<span class="nonterminal">obj<sub>1</sub></span> <span class="nonterminal">obj<sub>2</sub></span> ...<span class="nonterminal">obj<sub>n</sub></span>). A dotted list (<span class="latin">i.e.</span>, a list whose last tail is not <span class="terminal">nil</span>) appears as (<span class="nonterminal">obj<sub>1</sub></span> <span class="nonterminal">obj<sub>2</sub></span> ...<span class="nonterminal">obj<sub>n</sub></span> . <span class="nonterminal">obj<sub>n+1</sub></span>).</dd>
<dt class="classname" id="character">Character</dt>
<dd>An instance of the <span class="class">character</span> class is represented by #\<span class="nonterminal">?</span>, where <q><span class="nonterminal">?</span></q> is the character in question. There are two special standard characters that are not represented in this way, namely newline and space, whose representations are #\newline and #\space, respectively.</dd>
<dt class="classname" id="cons10">Cons</dt>
<dd>A cons is expressed as (<span class="nonterminal">car</span> . <span class="nonterminal">cdr</span>), where the <span class="nonterminal">car</span> and <span class="nonterminal">cdr</span> are objects.</dd>
<dt class="classname" id="integer10">Integer</dt>
<dd>An integer (radix 10) is represented as a sequence of digits optionally preceded by a <span class="terminal">+</span> or <span class="terminal">-</span> sign. If the number is represented in binary radix (or in octal or hexadecimal) then the textual representation is preceded by #b (or #o or #x, respectively).</dd>
<dt class="classname" id="float11">Float</dt>
<dd>
<p>A floating point number is written in one of the following formats:</p>
<pre>
[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>.<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>
[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>.<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>E[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>
[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>.<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>e[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>
[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>E[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>
[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>e[<span class="nonterminal">s</span>]<span class="nonterminal">dd</span> … <span class="nonterminal">d</span>
</pre>
<p>where <span class="nonterminal">s</span> is either <q>+</q> or <q>-</q>, and <span class="nonterminal">d</span> is one of <q>0</q> – <q>9</q>. <span title="This number, although belonging to the set of natural numbers, usually is considered as only a floating point number because of its representation.">For example: 987.12, +12.5E-13, -1.5E12, 1E32</span></p>
</dd>
<dt class="classname" id="vector11">Vector</dt>
<dd>A vector of class <span class="class">general-vector</span> is written as #(<span class="nonterminal">obj<sub>1</sub></span> … <span class="nonterminal">obj<sub>n</sub></span>).</dd>
<dt class="classname" id="array">Array</dt>
<dd>
<p>An array of class <span class="class">general-array*</span> or <span class="class">general-vector</span> can be written on input as #<span class="nonterminal">n</span>a (where <span class="nonterminal">n</span> is an integer indicating the number of dimensions of the array) followed by a nested structure of sequences denoting the contents of the array. This structure is defined as follows. If <span class="nonterminal">n</span> = 1 the structure is simply (<span class="nonterminal">obj<sub>1</sub></span> ... <span class="nonterminal">obj<sub>n</sub></span>). If <span class="nonterminal">n</span> > 1 and the dimensions are <span class="nonterminal">n<sub>1</sub></span> <span class="nonterminal">n<sub>2</sub></span> ..., the structure is (<span class="nonterminal">str<sub>1</sub></span> ... <span class="nonterminal">str<sub>n</sub></span>), where the <span class="nonterminal">str<sub>i</sub></span> are the structures of the <span class="nonterminal">n<sub>1</sub></span> subarrays, each of which has dimensions (<span class="nonterminal">n<sub>2</sub></span> ...). As an example, the representation of (create-array '(2 3 4) 5) is as follows:</p>
<pre>
#3a(((5 5 5 5) (5 5 5 5) (5 5 5 5)) ((5 5 5 5) (5 5 5 5) (5 5 5 5)))
</pre>
<p>On output (see <a href="#f_format">format</a>), arrays of class <span class="class">general-vector</span> will be printed using #(...) notation.</p>
</dd>
<dt class="classname" id="string11">String</dt>
<dd>A string is represented by the sequence of its characters enclosed in a pair of "'s. For example: "abc". Special characters are preceded with a backslash as an escape character.</dd>
<dt class="classname" id="symbol11">Symbol</dt>
<dd>A named symbol is represented by its print name. Vertical bars (|) might need to enclose the symbol if it contains certain special characters; see <a href="#symbol_class">§18</a>. The notation, if any, used for unnamed symbols is <a href="#td_implementation_defined">implementation defined</a>.</dd>
</dl>
<p>There are objects which do not have a textual representation, such as a class or an instance of the <span class="class">function</span> class.</p>
<h3 id="reserved_identifiers">Reserved identifiers</h3>
<p>Symbols whose names contain a colon (<span class="terminal">:</span>) or an ampersand (<span class="terminal">&</span>) are reserved and may not be used as identifiers. Symbols whose names start with colon (<span class="terminal">:</span>) are called keywords.</p>
<h3 id="errors">Errors</h3>
<p>An <span class="term">error</span> is a situation arising during execution in which the processor is unable to continue correct execution according to the semantics defined in this document. The act of detecting and reporting such an error is called <span class="term">signaling</span> the error.</p>
<p>A <span class="term">violation</span> is a situation arising during preparation for execution in which the textual requirements of this document are not met. A violation shall be detected during preparation for execution.</p>
<h4 id="classes_of_error_specification">Classes of error specification</h4>
<p>The wording of error specification in this document is as follows:</p>
<dl>
<dt><q><span class="term">an error shall be signaled</span></q></dt>
<dd>
<p>An implementation shall detect an error of this kind no later than the completion of execution of the form having the error, but might detect them sooner (<span class="latin">e.g.</span>, when the code is being prepared for execution).</p>
<p>Evaluation of the current form shall stop. If no active handler is established by <span class="terminal">with-handler</span>, it is <a href="#td_implementation_defined">implementation defined</a> whether the entire running process exits, a debugger is entered, or control is transferred elsewhere within the process.</p>
</dd>
<dt id="consequences_are_undefined"><q><span class="term">the consequences are undefined</span></q></dt>
<dd>This means that the consequences are unpredictable. The consequences may range from harmless to fatal. No conforming ISLISP text may depend on the results or effects. A conforming ISLISP text must treat the consequences as unpredictable. In places where <q>must,</q> <q>must not,</q> or <q>may not</q> are used, then this is equivalent to stating that <q>the consequences are undefined</q> 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.</dd>
</dl>
<p>For indexing and cross-referencing convenience, errors in this document have an associated <i>error identification</i> label, notated by text such as <q>(error-id. <span class="error_id">sample</span>).</q> The text of these labels has no formal significance to ISLISP texts or processors; the actual class of any object which might be used by the implementation to represent the error and the text of any error message that might be displayed is <a href="#td_implementation_dependent">implementation dependent</a>.</p>
<h4 id="pervasive_error_types">Pervasive error types</h4>
<p>Most errors are described in detail in the contect in which they occur. Some error types are so pervasive that their detailed descriptions are consolidated here rather than repeated in full detail upon each occurrence.</p>
<ol>
<li id="domain_error">Domain error: an error shall be signaled if the object given as argument of a standard function for which a class restriction is in effect is not an instance of the class which is required in the definition of the function (error-id. <span class="error_id">domain-error</span>).</li>
<li id="arity_error"> Arity error: an error shall be signaled if a function is activated with a number of arguments which is different than the number of parameters as required in the function definition (error-id. <span class="error_id">arity-error</span>).</li>
<li id="undefined_entity">Undefined entity error: an error shall be signaled if the entity denoted by an identifier does not exist when a reference to that entity is made (error-id. <span class="error_id">undefined-entity</span>). Two commonly occuring examples of this type of error are <span class="error_id">undefined-function</span> and <span class="error_id">unbound-variable</span>.</li>
</ol>
<p>This list does not exhaust the space of error types. For a more complete list, see <a href="#error_identification">§29.4</a>.</p>
<h3 id="classes">Classes</h3>
<p>In ISLISP, data types are covered by the class system. A <span class="term">class</span> is an object that determines the structure and behavior of a set of other objects, which are called its <span class="term">instances</span>. Every ISLISP object is an instance of a class. The behavior is the set of operations that can be performed on an instance.</p>
<p>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 <span class="term">subclass</span> of each of those classes. The classes that are designated for purposes of inheritance are said to be <span class="term">superclasses</span> of the inheriting class.</p>
<p>A class can be named by an <span class="nonterminal">identifier</span>. For example, this <span class="nonterminal">identifier</span> can be used as a parameter specializer in method definitions. The <span class="terminal">class</span> special form can be used to refer to access the class object corresponding to its name.</p>
<p>A class <span class="nonterminal">C<sub>1</sub></span> is a <span class="term">direct superclass</span> of a class <span class="nonterminal">C<sub>2</sub></span> if <span class="nonterminal">C<sub>2</sub></span> explicitly designates <span class="nonterminal">C<sub>1</sub></span> as a superclass in its definition, or if <span class="nonterminal">C<sub>1</sub></span> is defined by this document to be a direct superclass of <span class="nonterminal">C<sub>2</sub></span> (for example, by use of a directed arrow from <span class="nonterminal">C<sub>1</sub></span> to <span class="nonterminal">C<sub>2</sub></span> in <a href="#figure_1">Figure 1</a>). In this case <span class="nonterminal">C<sub>2</sub></span> is a <span class="term">direct subclass</span> of <span class="nonterminal">C<sub>1</sub></span>. A class <span class="nonterminal">C<sub>n</sub></span> is a <span class="term">superclass</span> of a class <span class="nonterminal">C<sub>1</sub></span> if there exists a series of classes <span class="nonterminal">C<sub>2</sub></span> , … , <span class="nonterminal">C<sub>n−1</sub></span> such that <span class="nonterminal">C<sub>i+1</sub></span> is a direct superclass of <span class="nonterminal">C<sub>i</sub></span> for 1 ≤ <span class="nonterminal">i</span> < <span class="nonterminal">n</span>. In this case, <span class="nonterminal">C<sub>1</sub></span> is a subclass of <span class="nonterminal">C<sub>n</sub></span>. A class is considered neither a superclass nor a subclass of itself. That is, if <span class="nonterminal">C<sub>1</sub></span> is a superclass of <span class="nonterminal">C<sub>2</sub></span>, then <span class="nonterminal">C<sub>1</sub></span> ≠ <span class="nonterminal">C<sub>2</sub></span>. The set of classes consisting of some given class <span class="nonterminal">C</span> along with all of its superclasses is called <q><span class="nonterminal">C</span> and its superclasses.</q></p>
<p>If a user-defined class <span class="nonterminal">C</span> inherits from two classes, <span class="nonterminal">C<sub>1</sub></span> and <span class="nonterminal">C<sub>2</sub></span>, the only superclasses that <span class="nonterminal">C<sub>1</sub></span> and <span class="nonterminal">C<sub>2</sub></span> may have in common are <span class="class">standard-object</span> or <span class="class">object</span>. This allows a restricted form of multiple inheritance.</p>
<p>Every ISLISP object is a <span class="nonterminal">direct instance</span> of exactly one class which is called <q>its</q> class.</p>
<p>An <span class="nonterminal">instance</span> of a class is either a direct instance of that class or an instance of one of its subclasses.</p>
<p>Classes are organized into a <span class="term">directed acyclic graph</span> defined by the subclass relation. The nodes are classes and there is an edge from C<sub>1</sub> to C<sub>2</sub> iff C<sub>2</sub> is direct subclass of C<sub>1</sub> . This graph is called the inheritance graph. It has as root the class <span class="class">object</span>, the only class with no superclass.</p>
<p>Therefore it is the superclass of every class except itself. The class named <span class="class">standard-object</span> is an instance of the class <span class="class">standard-class</span> and is a superclass of every class that is an instance of <span class="class">standard-class</span> except itself.</p>
<p id="class_precedence_list">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 <span class="term">shadow</span>, or override, 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.</p>
<h4 id="metaclasses">Metaclasses</h4>
<p>Classes are represented by objects that are themselves instances of classes. The class of the class of an object is termed the <span class="term">metaclass</span> of that object. The term <span class="nonterminal">metaclass</span> is used to refer to a class that has instances that are themselves classes.</p>
<div id="figure_1">
Figure 1. Class Inheritance
<ul>
<li><span class="class">object</span>
<ul>
<li><span class="class">basic-array</span>
<ul>
<li><span class="class">basic-array*</span>
<ul>
<li><span class="class">general-array*</span></li>
</ul>
</li>
<li><span class="class">basic-vector</span>
<ul>
<li><span class="class">general-vector</span></li>
<li><span class="class">string</span></li>
</ul>
</li>
</ul>
</li>
<li><span class="class">built-in-class</span></li>
<li><span class="class">character</span></li>
<li><span class="class">function</span>
<ul>
<li><span class="class">generic-function</span>
<ul>
<li><span class="class">standard-generic-function</span></li>
</ul>
</li>
</ul>
</li>
<li><span class="class">list</span>
<ul>
<li><span class="class">cons</span></li>
<li><span class="class">null</span></li>
</ul>
</li>
<li><span class="class">symbol</span></li>
<li><span class="class">number</span>
<ul>
<li><span class="class">float</span></li>
<li><span class="class">integer</span></li>
</ul>
</li>
<li><span class="class">serious-condition</span>
<ul>
<li><span class="class">error</span>
<ul>
<li><span class="class">arithmetic-error</span>;
<ul>
<li><span class="class">division-by-zero</span></li>
<li><span class="class">floating-point-overflow</span></li>
<li><span class="class">floating-point-underflow</span></li>
</ul>
</li>
<li><span class="class">control-error</span></li>
<li><span class="class">parse-error</span></li>
<li><span class="class">program-error</span>
<ul>
<li><span class="class">domain-error</span></li>
<li><span class="class">undefined-entity</span>
<ul>
<li><span class="class">unbound-variable</span></li>
<li><span class="class">undefined-function</span></li>
</ul>
</li>
</ul>
</li>
<li><span class="class">simple-error</span></li>
<li><span class="class">stream-error</span>
<ul>
<li><span class="class">end-of-stream</span></li>
</ul>
</li>
</ul>
</li>
<li><span class="class">storage-exhausted</span></li>
</ul>
</li>
<li><span class="class">standard-class</span></li>
<li><span class="class">standard-object</span></li>
<li><span class="class">stream</span></li>
</ul>
</li>
</ul>
</div>
<p>The metaclass determines the form of inheritance used by the classes that are its instances and the representation of the instances of those classes.</p>
<p>The ISLISP Object System provides the following predefined metaclasses:</p>
<ul>
<li>The class <span class="class">standard-class</span> is the default class of classes defined by defclass.</li>
<li>The class <span class="class">built-in-class</span> is the class whose instances are classes that have special implementations or restricted capabilities. For example, it is not possible to define subclasses of a built-in class.</li>
</ul>
<h4 id="predefined_classes">Predefined classes</h4>
<p>The following classes are primitive classes in the class system (<span class="latin">i.e.</span>, predefined classes that are not metaclasses):</p>
<ul>
<li><span class="class">arithmetic-error</span></li>
<li><span class="class">basic-array</span></li>
<li><span class="class">basic-array*</span></li>
<li><span class="class">basic-vector</span></li>
<li><span class="class">character</span></li>
<li><span class="class">cons</span></li>
<li><span class="class">control-error</span></li>
<li><span class="class">division-by-zero</span></li>
<li><span class="class">domain-error</span></li>
<li><span class="class">end-of-stream</span></li>
<li><span class="class">error</span></li>
<li><span class="class">float</span></li>
<li><span class="class">floating-point-overflow</span></li>
<li><span class="class">floating-point-underflow</span></li>
<li><span class="class">function</span></li>
<li><span class="class">general-array*</span></li>
<li><span class="class">general-vector</span></li>
<li><span class="class">generic-function</span></li>
<li><span class="class">integer</span></li>
<li><span class="class">list</span></li>
<li><span class="class">null</span></li>
<li><span class="class">number</span></li>
<li><span class="class">object</span></li>
<li><span class="class">parse-error</span></li>
<li><span class="class">program-error</span></li>
<li><span class="class">serious-condition</span></li>
<li><span class="class">simple-error</span></li>
<li><span class="class">standard-generic-function</span></li>
<li><span class="class">standard-object</span></li>
<li><span class="class">storage-exhausted</span></li>
<li><span class="class">stream</span></li>
<li><span class="class">stream-error</span></li>
<li><span class="class">string</span></li>
<li><span class="class">symbol</span></li>
<li><span class="class">unbound-variable</span></li>
<li><span class="class">undefined-entity</span></li>
<li><span class="class">undefined-function</span></li>
</ul>
<p>The classes <span class="class">standard-class</span> and <span class="class">built-in-class</span> are predefined metaclasses.</p>
<p>A user-defined class, defined by <span class="terminal">defclass</span>, must be implemented as an instance of <span class="class">standard-class</span>. A predefined class can be implemented either as an instance of <span class="class">standard-class</span> (as if defined by <span class="terminal">defclass</span>) or as an instance of <span class="class">built-in-class</span>.</p>
<p><a href="#figure_1">Figure 1</a> shows the required inheritance relationships among the classes defined by ISLISP. For each pair of classes <span class="nonterminal">C<sub>1</sub></span> and <span class="nonterminal">C<sub>2</sub></span> in this figure, if <span class="nonterminal">C<sub>1</sub></span> is linked directly by an arrow to <span class="nonterminal">C<sub>2</sub></span>, <span class="nonterminal">C<sub>1</sub></span> is a direct superclass of <span class="nonterminal">C<sub>2</sub></span> (and <span class="nonterminal">C<sub>2</sub></span> is a direct subclass of <span class="nonterminal">C<sub>1</sub></span>). Additional relationships might exist, subject to the following constraints:</p>
<ul>
<li>It is <a href="#td_implementation_defined">implementation defined</a> whether <span class="class">standard-generic-function</span> is a subclass of the class <span class="class">standard-object</span>.</li>
<li>Except as described in <a href="#figure_1">Figure 1</a> and the above constraint on <span class="class">standard-generic-function</span>, no other subclass relationships exist among the classes defined in this document. However, additional implementation-specific subclass relationships may exist between implementation-specific classes and classes defined in this document.</li>
<li>The class precedence list for <span class="class">null</span> observes the partial order <span class="class">null</span>, <span class="class">symbol</span>, <span class="class">list</span>, <span class="class">object</span>.</li>
<li>Users may define additional classes using <span class="terminal">defclass</span>.</li>
</ul>
<p>A built-in class is one whose instances have restricted capabilities or special representations. The <span class="terminal">defclass</span> defining form must not be used to define subclasses of a built-in class. An error shall be signaled if create is called to create an instance of a built-in class.</p>
<p>A standard class is an instance of <span class="class">standard-class</span>, and a built-in class is an instance of <span class="class">built-in-class</span>.</p>
<p>A standard class defined with no direct superclasses is guaranteed to be disjoint from all of the classes in the figure, except for the classes named <span class="class">standard-object</span> and <span class="class">object</span>.</p>
<p>The class <span class="class">function</span> is the class of all functions. The class <span class="class">standard-generic-function</span> is the default class of all generic functions.</p>
<h4 id="standard_classes">Standard classes</h4>
<h5 id="slots">Slots</h5>
<p>An object that has <span class="class">standard-class</span> as its metaclass has zero or more named slots. The slots of an object are determined by the class of the object. Each slot can hold one object as its value. The name of a slot is an identifier.</p>
<p>When a slot does not have a value, the slot is said to be <span class="term">unbound</span>. The consequences are undefined if an attempt is made to retrieve the value of an unbound slot.</p>
<p>Storing and retrieving the value of a slot is done by generic functions defined by the <span class="terminal">defclass</span> defining form.</p>
<p>All slots are local; <span class="latin">i.e.</span>, there are no shared slots accessible by several instances.</p>
<p id="define_a_slot">A class is said to <span class="term">define</span> a slot with a given name when the <span class="terminal">defclass</span> defining form for that class contains a slot specifier with that name. Defining a slot does not immediately create a slot; it causes a slot to be created each time an instance of the class is created.</p>
<p id="accesible_slots">A slot is said to be <span class="term">accessible</span> 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 detailed explanation of the inheritance of slots is given in the section §<a href="#inheritance_of_slots">15.1.3</a>.</p>
<h5 id="creating_instances">Creating instances of classes</h5>
<p>The generic function <span class="terminal">create</span> creates and returns a new instance of a class. ISLISP 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 by providing default initial values. Further initialization activities can be performed by methods written for generic functions that are part of the initialization protocol.</p>
<h3 id="scope_and_extent">Scope and extent</h3>
<p>In describing ISLISP, the notions of <span class="nonterminal">scope</span> and <span class="nonterminal">extent</span> are useful. The first is a syntactic concept, the latter is a semantic concept. Although syntactic constructs, especially identifiers, are used to refer to runtime entities (<span class="latin">i.e.</span>, objects arising during execution), a single entity cannot have both scope and extent. Scope is a feature of an identifier, referring to that textual part of an ISLISP text (see <a href="#td_text">§4.38</a> and <a href="#notation_and_conventions">§5</a>) within which this identifier occurs with unique meaning. <span class="nonterminal">Extent</span> refers to the interval of execution time during which a certain object exists.</p>
<p>A <span class="term">namespace</span> is a mapping from identifiers to meanings. In ISLISP there are six namespaces: variable, dynamic variable, function, class, block, and tagbody tag. It is therefore possible for a single identifier to have any or all of these six meanings, depending on the context. For example, an identifier's meaning is determined by the function namespace when the identifier appears in the operator position of a function application form, whereas the same identifier's meaning is determined by the variable namespace if it appears in an argument position in the same form.</p>
<h4 id="the_lexical_principle">The lexical principle</h4>
<p>ISLISP is designed following the principle of <span class="term">lexical visibility</span>. This principle states that an ISLISP text must be structured in properly nested lexical blocks of visibility. Within a block, all defined identifiers of that block and of all enclosing outer blocks are visible. Each identifier in a namespace has the meaning determined by the innermost block that defines it.</p>
<p>ISLISP also supports a form of <span class="term">dynamic binding</span>. Dynamic bindings are established and accessed by a separate mechanism (<span class="latin">i.e.</span>, <span class="terminal">defdynamic</span>, <span class="terminal">dynamic-let</span>, and <span class="terminal">dynamic</span>). The dynamic value associated with such an identifier is the one that was established by the most recently executed <span class="term">active block</span> that established it, where an <span class="term">active</span> block is one that has been established and not yet disestablished. Because a separate mechanism is used, the lexical meaning of and the dynamic value associated with an identifier are simultaneously accessible wherever both are defined.</p>
<h4 id="scope_of_identifiers">Scope of identifiers</h4>
<p>The <span class="term">scope</span> of an identifier is that part of an ISLISP text where the meaning of the identifier is defined. It starts textually with the definition point—a point that is specified individually for each form that establishes an identifier. Only identifiers can have a scope.</p>
<p>For each namespace, if an identifier has scope <span class="nonterminal">s<sub>a</sub></span> and an identical identifier (in the same namespace) has nested scope <span class="nonterminal">s<sub>b</sub></span>, then the scope <span class="nonterminal">s<sub>b</sub></span> of the inner identifier and every scope contained in it are not part of the scope <span class="nonterminal">s<sub>a</sub></span>. It is said that the inner scope <span class="term">shadows</span> the outer scope.</p>
<p>Each complete ISLISP text unit is processed in a scope called the toplevel scope.</p>
<p>In each namespace, nested binding forms shadow outer binding forms and defining forms.</p>
<pre>
(let ((a1 f-a1)
...
(x f-x)
...
(z1 f-z1)) ;
... ; now a1...x...z1 are applicable, their scope begins here
(let ((a2 f-a2) ; a1...x...z1 might be defined newly, but:
... ; the outer a1...x...z1 are still usable
(x f-x2) ; the inner a2...x...z2 are not yet usable
...
(z2 f-z2)) ; the scope of the outer x becomes shadowed
; the scope for the inner a2...x...z2 starts
... ; now outer a1, z1 and inner a2...x...z2 are applicable
) ; scopes of a2...x...z2 end here
... ; scope of outer x becomes unshadowed
) ; scopes of a1...x...z1 end here
<span>Figure 2. Scope Example</span>
</pre>
<h4 id="some_specific_scope_rules">Some specific scope rules</h4>
<p>The toplevel scope is the scope of identifiers of required built-in functions, special operators, defining operators, and constants.</p>
<p>Reserved identifiers are not subject to the lexical principle, because they are not identifiers. They cannot be defined or bound. See <a href="#reserved_identifiers">§8</a>.</p>
<h4 id="extent">Extent</h4>
<p>Complementary to scope which is a syntactic concepts, <span class="term">extent</span> is a semantic concept: It describes the lifetime of entities.</p>
<p>Objects are created at some time during execution. In most cases, it is undetermined when an object ends its existence: its lifetime begins when the object is created and ends when reference to it is no longer possible (and the object is subject to garbage collection). In this case the object is said to have <span class="term">indefinite extent</span>.</p>
<p id="dynamic_extent">In other cases the processor creates entities that are associated with prepared text. The lifetime of such objects begins at the activation point of a defining construct and ends at the end of activation; in this case the object is said to have dynamic extent.</p>
<p>During execution, defining forms and the following binding forms create bindings at their activation points:</p>
<ul>
<li><a href="#s_block"><span class="terminal">block</span></a></li>
<li><a href="#s_dynamic_let"><span class="terminal">dynamic-let</span></a></li>
<li><a href="#s_flet"><span class="terminal">flet</span></a></li>
<li><a href="#s_for"><span class="terminal">for</span></a></li>
<li><a href="#s_labels"><span class="terminal">labels</span></a></li>
<li><a href="#s_let"><span class="terminal">let</span></a></li>
<li><a href="#s_let_s"><span class="terminal">let*</span></a></li>
<li><a href="#s_tagbody"><span class="terminal">tagbody</span></a></li>
<li><a href="#s_with_error_output"><span class="terminal">with-error-output</span></a></li>
<li><a href="#s_with_open_input_file"><span class="terminal">with-open-input-file</span></a></li>
<li><a href="#s_with_open_io_file"><span class="terminal">with-open-io-file</span></a></li>
<li><a href="#s_with_open_output_file"><span class="terminal">with-open-output-file</span></a></li>
<li><a href="#s_with_standard_input"><span class="terminal">with-standard-input</span></a></li>
<li><a href="#s_with_standard_output"><span class="terminal">with-standard-output</span></a></li>
</ul>
<p id="binding_established_disestablished">The bindings established by defining forms may have indefinite extent. Even in local binding constructs, bindings might not vanish upon activation end of the prepared block—if one or more function objects are created during execution of the prepared block that contain references to those bindings, the bindings will have a lifetime equal to the longest lifetime of those function objects.</p>
<blockquote>
<cite>Example:</cite>
<pre>
(defun copy-cell (x) (cons (car x) (cdr x)))
</pre>
<p>The scope of the identifier x is the body alone—<span class="latin">i.e.</span>, (cons (car x) (cdr x)). The meaning of x is defined for the entire body. x, as identifier, cannot have an extent.</p>
<p>The defun form for copy-cell is prepared for execution and thereby copy-cell becomes a prepared function. During execution the prepared function copy-cell might be activated. Activation in this case results in the creation of a binding between the variable denoted by x and the object which is used as argument. The binding of x is an entity whose extent lasts from the activation point to the activation end of the function. (In general the extent of a binding can last beyond the activation end, but this does not occur in this simple case.) We say that the binding of x is <span class="nonterminal">established</span> upon activation of the function and is <span class="nonterminal">disestablished</span> at activation end.</p>
</blockquote>
<h3 id="forms_and_evaluation">Forms and evaluation</h3>
<h4 id="forms">Forms</h4>
<p>Execution presupposes successful preparation for execution of an ISLISP text subject to the evaluation model. Execution is an activation of a prepared text form that results in a value and perhaps in some side-effects.</p>
<p>An ISLISP text is a sequence of forms.</p>
<p>Throughout this document the value a form returns is described, but in general a form might not return if one of its subforms executes a non-local exit (see <a href="#establishing_and_invoking_non_local_exits">§14.7.1</a>). Therefore, it should be understood that all such descriptions implicitly include the provision that <i>if the form returns</i>, a particular value is returned.</p>
<p>The following are valid forms in ISLISP:</p>
<ul>
<li id="compound_forms">Compound forms
<ul>
<li>Special forms</li>
<li>Defining forms</li>
<li>Function application forms</li>
<li>Macro forms</li>
</ul>
</li>
<li>Identifiers</li>
<li>Literals</li>
</ul>
<p>A form, when evaluated, returns an object as its value, though some forms may not return (<span class="latin">e.g.</span>, <span class="terminal">return-from</span>).</p>
<p>A compound form is written as (<span class="term">operator</span> <span class="arg">argument*</span>). The <span class="nonterminal">operator</span> must be a special operator, a defining operator, an identifier, or a lambda expression. The identifier names a function, a macro, or a generic function. It is a violation if operator is a literal.</p>
<p id="toplevel_form">A <span class="term">toplevel form</span> is a form that is either not lexically nested within another form or is lexically nested only within one or more <span class="terminal">progn</span> forms. Special forms and function application forms at toplevel are called <span class="term">set-up forms</span>. It is a violation if a defining form is not a toplevel form.</p>
<h4 id="function_application_forms">Function application forms</h4>
<p>A <span class="term">function application form</span> is a compound form whose operator is an identifier (naming a function) or whose operator is a lambda expression. All of the arguments are evaluated, from left to right, and the function is called with (or “applied to”) arguments that are, in the same order, the objects resulting from these evaluations. This document describes a function application form in the following format:</p>
<div class="definition-function">
(<span class="operator">function-name</span> <span class="arg">argument</span>*) → <span class="class">result-class</span>
</div>
<p>This describes an ordinary function.</p>
<div class="definition-generic">
(<span class="operator">generic-function-name</span> <span class="arg">argument</span>*) → <span class="class">result-class</span>
</div>
<p>This describes a generic function.</p>
<div class="definition-local">
(<span class="operator">local-function-name</span> <span class="arg">argument</span>*) → <span class="class">result-class</span>
</div>
<p>This describes an ordinary function that is available only in a specified lexical scope.</p>
<h4 id="special_forms">Special forms</h4>
<p>A <span class="term">special form</span> is a form whose arguments are treated in a special way; for example, arguments are not evaluated or are evaluated in a special order. It is <a href="#td_implementation_defined">implementation defined</a> whether any special form is implemented as a macro (see <a href="#macro_forms">§12.5</a> and <a href="#macros">§16</a>). Special forms are recognized because they have a <span class="term">special operator</span> in their operator position. The following are special operators:</p>
<ul>
<li><a href="#s_and">and</a></li>
<li><a href="#s_assure">assure</a></li>
<li><a href="#s_block">block</a></li>
<li><a href="#s_case">case</a></li>
<li><a href="#s_case_using">case-using</a></li>
<li><a href="#s_catch">catch</a></li>
<li><a href="#s_class">class</a></li>
<li><a href="#s_cond">cond</a></li>
<li><a href="#s_convert">convert</a></li>
<li><a href="#s_dynamic">dynamic</a></li>
<li><a href="#s_dynamic_let">dynamic-let</a></li>
<li><a href="#s_flet">flet</a></li>
<li><a href="#s_for">for</a></li>
<li><a href="#s_function">function</a></li>
<li><a href="#s_go">go</a></li>
<li><a href="#s_if">if</a></li>
<li><a href="#s_ignore_errors">ignore-errors</a></li>
<li><a href="#s_labels">labels</a></li>
<li><a href="#s_lambda">lambda</a></li>
<li><a href="#s_let">let</a></li>
<li><a href="#s_let_s">let*</a></li>
<li><a href="#s_or">or</a></li>
<li><a href="#s_progn">progn</a></li>
<li><a href="#s_quote">quote</a></li>
<li><a href="#s_return_from">return-from</a></li>
<li><a href="#s_set_dynamic">set-dynamic</a></li>
<li><a href="#s_setf">setf</a></li>
<li><a href="#s_setq">setq</a></li>
<li><a href="#s_tagbody">tagbody</a></li>
<li><a href="#s_the">the</a></li>
<li><a href="#s_throw">throw</a></li>
<li><a href="#s_unwind_protect">unwind-protect</a></li>
<li><a href="#s_while">while</a></li>
<li><a href="#s_with_error_output">with-error-output</a></li>
<li><a href="#s_with_handler">with-handler</a></li>
<li><a href="#s_with_open_input_file">with-open-input-file</a></li>
<li><a href="#s_with_open_io_file">with-open-io-file</a></li>
<li><a href="#s_with_open_output_file">with-open-output-file</a></li>
<li><a href="#s_with_standard_input">with-standard-input</a></li>
<li><a href="#s_with_standard_output">with-standard-output</a></li>
</ul>
<p>There might be additional, <a href="#td_implementation_defined">implementation-defined</a> special operators.</p>
<p>This document describes the evaluation of special forms in the following format:</p>
<div id="special_operator" class="definition-special">
(<span class="operator">special-operator</span> <span class="arg">argument</span>*) → <span class="class">result-class</span>
</div>
<h4 id="defining_forms">Defining forms</h4>
<p>A <span class="term">defining form</span> is a toplevel special form (see <a href="#special_forms">§12.3</a>) that establishes a binding between <span class="nonterminal">name</span> and an object which is the result of handling the <span class="nonterminal">arguments</span> according to the semantics implied by <span class="nonterminal">defining-form-name</span>; it is a violation if a defining form is not a toplevel form. For each namespace, defining forms can occur at most once for the same <span class="nonterminal">name</span> and, in case of method definitions for the same parameter profile. A defining form is a compound form whose operator is a <span class="term">defining operator</span>. These are the defining operators:</p>
<ul>
<li><a href="#def_defclass">defclass</a></li>
<li><a href="#def_defdynamic">defdynamic</a></li>
<li><a href="#def_defglobal">defglobal</a></li>
<li><a href="#def_defmethod">defmethod</a></li>
<li><a href="#def_defconstant">defconstant</a></li>
<li><a href="#def_defgeneric">defgeneric</a></li>
<li><a href="#def_defmacro">defmacro</a></li>
<li><a href="#def_defun">defun</a></li>
</ul>
<p>This document describes defining forms in the following format:</p>
<div class="definition-defining">
(<span class="operator">defining-form-name</span> <span class="noeval_arg">name</span> <span class="arg">argument</span>*) → <span class="class">symbol</span>
</div>
<h4 id="macro_forms">Macro forms</h4>
<p>Macro forms are expanded during preparation for execution.</p>
<p>For information on how macros are processed, see <a href="#macros">§16</a>.</p>