![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ch1.n CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / ucb / lisp / doc|
Return to ch1.n CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / ucb / lisp / doc |
1.1 root 1: .\" Copyright (c) 1980 Regents of the University of California.
2: .\" All rights reserved. The Berkeley software License Agreement
3: .\" specifies the terms and conditions for redistribution.
4: .\"
5: .\" @(#)ch1.n 6.3 (Berkeley) 5/14/86
6: .\"
7: .\" $Header: ch1.n,v 1.3 83/07/27 15:11:17 layer Exp $
8: .Lc \s+2F\s-2RANZ\s0\ L\s-2ISP\s0\s-2 1
9: .sh 2
10: .Fr \*[\(dg\*]
11: was created as a tool to further research in symbolic and
12: algebraic manipulation,
13: artificial intelligence,
14: and programming languages at the University of California
15: at Berkeley.
16: .(f
17: \*[\(dg\*]It is rumored that this name has something to do with Franz
18: Liszt [F\fIr\fPa\*:nts List] (1811-1886) a Hungarian composer
19: and keyboard virtuoso.
20: These allegations have never been proven.
21: .)f
22: Its roots are in a PDP-11 Lisp system which originally came
23: from Harvard.
24: As it grew it adopted features of Maclisp and Lisp Machine Lisp.
25: Substantial compatibility with other Lisp dialects
26: (Interlisp, UCILisp, CMULisp) is achieved by
27: means of support packages and compiler switches.
28: The heart of
29: .Fr
30: is written almost entirely in the programming language C.
31: Of course, it has been greatly extended by additions written
32: in Lisp.
33: A small part is written in the assembly language for the current
34: host machines, VAXen and a couple of flavors of 68000.
35: Because
36: .Fr
37: is written in C, it is relatively portable and easy to comprehend.
38: .pp
39: .Fr
40: is capable of running large lisp programs in a timesharing environment,
41: has facilities for arrays and user defined structures,
42: has a user controlled reader with character and word macro capabilities,
43: and can interact directly with compiled Lisp, C, Fortran, and Pascal code.
44: .pp
45: This document is a reference manual for the
46: .Fr
47: system.
48: It is not a Lisp primer or introduction to the language.
49: Some parts will be of interest primarily to those maintaining
50: .Fr
51: at their computer site.
52: There is an additional document entitled
53: \fIThe Franz Lisp System,\fP
54: by John Foderaro, which partially describes the system implementation.
55: .Fr ,
56: as delivered by Berkeley, includes all source code
57: and machine readable version of this manual and system document.
58: The system document is in a single file named "franz.n" in
59: the "doc" subdirectory.
60: .pp
61: This document is divided into four Movements.
62: In the first one we will attempt to describe the language of
63: .Fr
64: precisely and completely as it now stands (Opus 38.69, June 1983).
65: In the second Movement we will look at the reader, function types,
66: arrays and exception handling.
67: In the third Movement we will look at several large support packages
68: written to help the
69: .Fr
70: user, namely the trace package, compiler, fixit and stepping package.
71: Finally the fourth movement contains an index into the other movements.
72: In the rest of this chapter we shall examine the data types of
73: .Fr .
74: The conventions used in the description of the
75: .Fr
76: functions will be given in \(sc1.3 -- it is very important that
77: these conventions are understood.
78: .sh 2 Data\ Types
79: .Fr
80: has fourteen data types.
81: In this section we shall look in detail at each type and if a type is
82: divisible we shall look inside it.
83: There is a Lisp function
84: .i type
85: which will return the type name of a lisp object.
86: This is the official
87: .Fr
88: name for that type and we will use this name and this name only in
89: the manual to avoid confusing the reader.
90: The types are listed in terms of importance rather than alphabetically.
91: .sh 3 lispval - - 0
92: This is the name we use to describe any Lisp object.
93: The function
94: .i type
95: will never return `lispval'.
96: .sh 3 symbol
97: This object corresponds to a variable in most other programming languages.
98: It may have a value or may be `unbound'.
99: A symbol may be
100: .i lambda
101: .i bound
102: meaning that its current value is stored
103: away somewhere and the symbol is given a new value for the duration of a
104: certain context.
105: When the Lisp processor leaves that context, the
106: symbol's current value is thrown
107: away and its old value is restored.
108: .sp .5v
109: A symbol may also have a
110: .i function
111: .i binding .
112: This function binding is static; it cannot be lambda bound.
113: Whenever the symbol is used in the functional position of a Lisp expression
114: the function binding of the symbol is examined (see Chapter 4 for more
115: details on evaluation).
116: .sp .5v
117: A symbol may also have a
118: .i property
119: .i list ,
120: another static data structure.
121: The property list consists of a list of an even number of elements,
122: considered to be grouped as pairs.
123: The first element of the pair is the
124: .i indicator
125: the second the
126: .i value
127: of that indicator.
128: .sp .5v
129: Each symbol has a print name
130: .i (pname)
131: which is how this symbol is accessed from input and referred to
132: on (printed) output.
133: .sp .5v
134: A symbol also has a hashlink used to link symbols together in the
135: oblist -- this field is inaccessible to the lisp user.
136: .sp .5v
137: Symbols are created by the reader and by the functions
138: .i concat ,
139: .i maknam
140: and their derivatives.
141: Most symbols live on
142: .Fr 's
143: sole
144: .i oblist ,
145: and therefore two symbols with the same print name are
146: usually the exact same object (they are
147: .i eq ).
148: Symbols which are not on the oblist are said to be
149: .i uninterned.
150: The function
151: .i maknam
152: creates uninterned symbols while
153: .i concat
154: creates
155: .i interned
156: ones.
157: .(b
158: .TS
159: box center ;
160: c | c | c | c .
161: Subpart name Get value Set value Type
162:
163: =
164: value eval set lispval
165: setq
166: _
167: property plist setplist list or nil
168: list get putprop
169: defprop
170: _
171: function getd putd array, binary, list
172: binding def or nil
173: _
174: print name get_pname string
175: _
176: hash link
177: .TE
178: .)b
179: .sh 3 list
180: A list cell has two parts, called the car and cdr.
181: List cells are created by the function
182: .i cons .
183: .(b
184: .TS
185: box center ;
186: c | c | c | c .
187: Subpart name Get value Set value Type
188:
189: =
190: car car rplaca lispval
191: _
192: cdr cdr rplacd lispval
193: .TE
194: .)b
195: .sh 3 binary
196: This type acts as a function header for machine coded functions.
197: It has two parts, a pointer to the start of the function and a
198: symbol whose print name describes the
199: argument
200: .i discipline .
201: The discipline (if
202: .i lambda ,
203: .i macro
204: or
205: .i nlambda )
206: determines whether the arguments to this function will be evaluated
207: by the caller
208: before this function is called.
209: If the discipline is a string (specifically
210: "\fIsubroutine\fP",
211: "\fIfunction\fP",
212: "\fIinteger-function\fP",
213: "\fIreal-function\fP",
214: "\fIc-function\fP",
215: "\fIdouble-c-function\fP",
216: or "\fIvector-c-function\fP"
217: )
218: then this function is
219: a foreign subroutine or function (see \(sc8.5 for more details on this).
220: Although the type of the
221: .i entry
222: field of a binary type object is usually \fBstring\fP or \fBother\fP,
223: the object pointed to
224: is actually a sequence of machine instructions.
225: .br
226: Objects of type binary are created by
227: .i mfunction,
228: .i cfasl,
229: and
230: .i getaddress.
231: .(b
232: .TS
233: box center ;
234: c | c | c | c .
235: Subpart name Get value Set value Type
236:
237: =
238: entry getentry string or fixnum
239: _
240: discipline getdisc putdisc symbol or fixnum
241: .TE
242: .)b
243: .sh 3 fixnum
244: A fixnum is an integer constant in the range \(mi2\*[31\*] to
245: 2\*[31\*]\(mi1.
246: Small fixnums (-1024 to 1023) are stored in a special table so they needn't be
247: allocated each time one is needed.
248: In principle, the range for fixnums is machine dependent, although
249: all current implementations for franz have this range.
250: .sh 3 flonum
251: A flonum is a double precision real number. On the VAX,
252: the range is
253: \(+-2.9\(mu10\*[-37\*] to \(+-1.7\(mu10\*[38\*].
254: There are approximately sixteen decimal digits of precision.
255: Other machines may have other ranges.
256: .sh 3 bignum
257: A bignum is an integer of potentially unbounded size.
258: When integer arithmetic exceeds the limits of fixnums mentioned above,
259: the calculation is automatically done with bignums.
260: Should calculation with bignums give a result which can be represented
261: as a fixnum, then the fixnum representation will be used\*[\(dg\*].
262: .(f
263: \*[\(dg\*]The current algorithms for integer arithmetic operations will return
264: (in certain cases) a result
265: between \(+-2\*[30\*] and 2\*[31\*] as a bignum although this
266: could be represented as a fixnum.
267: .)f
268: This contraction is known as
269: .i integer
270: .i normalization .
271: Many Lisp functions assume that integers are normalized.
272: Bignums are composed of a sequence of
273: .b list
274: cells and a cell known as an
275: .b sdot.
276: The user should consider a
277: .b bignum
278: structure indivisible and use functions such as
279: .i haipart ,
280: and
281: .i bignum-leftshift
282: to extract parts of it.
283: .sh 3 string
284: A string is a null terminated sequence of characters.
285: Most functions of symbols which operate on the symbol's print name will
286: also work on strings.
287: The default reader syntax is set so that
288: a sequence of characters surrounded by double quotes is a string.
289: .sh 3 port
290: A port is a structure which the system I/O routines can reference to
291: transfer data between the Lisp system and external media.
292: Unlike other Lisp objects there are a very limited number of ports (20).
293: Ports are allocated by
294: .i infile
295: and
296: .i outfile
297: and deallocated by
298: .i close
299: and
300: .i resetio .
301: The
302: .i print
303: function prints a port as a percent sign followed by the name of the file it
304: is connected to (if the port was opened by \fIfileopen, infile, or outfile\fP).
305: During initialization,
306: .Fr
307: binds the symbol \fBpiport\fP to a port attached to the standard input stream.
308: This port prints as %$stdin.
309: There are ports connected to the standard output and error streams,
310: which print as %$stdout and %$stderr.
311: This is discussed in more detail at the beginning of Chapter 5.
312: .sh 3 vector
313: Vectors are indexed sequences of data.
314: They can be used to implement a notion of user-defined types
315: via their associated property list.
316: They make \fBhunks\fP (see below) logically unnecessary, although hunks are very
317: efficiently garbage collected.
318: There is a second kind of vector, called an immediate-vector,
319: which stores binary data.
320: The name that the function \fItype\fP returns for immediate-vectors
321: is \fBvectori\fP.
322: Immediate-vectors could be used to implement strings and block-flonum arrays,
323: for example.
324: Vectors are discussed in chapter 9.
325: The functions
326: \fInew-vector\fP, and
327: \fIvector\fP, can
328: be used to create vectors.
329: .(b
330: .TS
331: box center ;
332: c | c | c | c .
333: Subpart name Get value Set value Type
334:
335: =
336: datum[\fIi\fP] vref vset lispval
337: _
338: property vprop vsetprop lispval
339: vputprop
340: _
341: size vsize \- fixnum
342: .TE
343: .)b
344: .sh 3 array
345: Arrays are rather complicated types and are fully described in
346: Chapter 9.
347: An array consists of a block of contiguous data, a function
348: to access that data, and auxiliary fields for use by the accessing
349: function.
350: Since an array's accessing function is created by the user, an array can
351: have any form the user chooses (e.g. n-dimensional, triangular, or hash
352: table).
353: .br
354: Arrays are created by the function
355: .i marray .
356: .(b
357: .TS
358: box center ;
359: c | c | c | c .
360: Subpart name Get value Set value Type
361:
362: =
363: access function getaccess putaccess binary, list
364: or symbol
365: _
366: auxiliary getaux putaux lispval
367: _
368: data arrayref replace block of contiguous
369: set lispval
370: _
371: length getlength putlength fixnum
372: _
373: delta getdelta putdelta fixnum
374: .TE
375: .)b
376: .sh 3 value
377: A value cell contains a pointer to a lispval.
378: This type is used mainly by arrays of general lisp objects.
379: Value cells are created with the
380: .i ptr
381: function.
382: A value cell containing a pointer to the symbol `foo' is printed
383: as `(ptr\ to)foo'
384: .sh 3 hunk
385: A hunk is a vector of from 1 to 128 lispvals.
386: Once a hunk is created (by
387: .i hunk
388: or
389: .i makhunk )
390: it cannot grow or shrink.
391: The access time for an element of a hunk is slower than a list cell element
392: but faster than an array.
393: Hunks are really only allocated in sizes which are powers of two, but
394: can appear to the user to be any size in the 1 to 128 range.
395: Users of hunks must realize that \fI(not\ (atom\ 'lispval))\fP
396: will return true if
397: .i lispval
398: is a hunk.
399: Most lisp systems do not have a direct test for a list cell and instead use
400: the above test and assume that
401: a true result means
402: .i lispval
403: is a list cell.
404: In
405: .Fr
406: you can use
407: .i dtpr
408: to check for a list cell.
409: Although hunks are not list cells, you can still access the first two
410: hunk elements with
411: .i cdr
412: and
413: .i car
414: and you can access any hunk element with
415: .i cxr \*[\(dg\*].
416: .(f
417: \*[\(dg\*]In a hunk, the function
418: .i cdr
419: references the first element
420: and
421: .i car
422: the second.
423: .)f
424: You can set the value of the first two elements of a hunk with
425: .i rplacd
426: and
427: .i rplaca
428: and you can set the value of any element of the hunk with
429: .i rplacx .
430: A hunk is printed by printing its contents surrounded by { and }.
431: However a hunk cannot be read in in this way in the standard lisp system.
432: It is easy to write a reader macro to do this if desired.
433: .sh 3 other
434: Occasionally, you can obtain a pointer to storage not allocated
435: by the lisp system. One example of this is the entry field of
436: those
437: .Fr
438: functions written in C. Such objects are classified as of type
439: \fBother\fP.
440: Foreign functions which call malloc to allocate their own space,
441: may also inadvertantly create such objects.
442: The garbage collector is supposed to ignore such objects.
443: .sh 2 Documentation Conventions.
444: The conventions used in the following chapters were designed to
445: give a great deal of information in a brief
446: space.
447: The first line of a function description contains the function
448: name in \fBbold\ face\fP and then lists the arguments, if any.
449: The arguments all have names which begin with a letter or letters and
450: an underscore.
451: The letter(s) gives the allowable type(s) for that argument according to
452: this table.
453: .(b
454: .TS
455: box center ;
456: c | c
457: l | l .
458: Letter Allowable type(s)
459:
460: =
461: g any type
462: _
463: s symbol (although nil may not be allowed)
464: _
465: t string
466: _
467: l list (although nil may be allowed)
468: _
469: n number (fixnum, flonum, bignum)
470: _
471: i integer (fixnum, bignum)
472: _
473: x fixnum
474: _
475: b bignum
476: _
477: f flonum
478: _
479: u function type (either binary or lambda body)
480: _
481: y binary
482: _
483: v vector
484: _
485: V vectori
486: _
487: a array
488: _
489: e value
490: _
491: p port (or nil)
492: _
493: h hunk
494: .TE
495: .)b
496: In the first line of a function description,
497: those arguments preceded by a quote mark are evaluated (usually
498: before the function is called).
499: The quoting convention is used so that we can give a name to the result of
500: evaluating the argument and we can describe the allowable types.
501: If an argument is not quoted it does not mean that that argument will
502: not be evaluated, but rather that
503: if it is evaluated, the time at which it is evaluated
504: will be specifically mentioned in the function description.
505: Optional arguments are surrounded by square brackets.
506: An ellipsis (...) means zero or more occurrences of an argument of the
507: directly preceding
508: type.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.