One of the reasons is that a single s-expression is slighty less practical in actual programming in many cases.

Remember, the evaluator in Lisp works like this: it reads a form and then evaluates it. The file compiler in Lisp works like this: it reads a form, then compiles it and creates the compiled code.

Now if we have a single form a file it might have some drawbacks:

• the form may be very large and the reader would return a very large data structure for the program

• if there is a s-expression syntax error, just reading that large form creates an error. Thus we would not work with smaller expressions and have eventually an error, we would always get the error from the s-expression reader for the whole program up-front. That can be undesirable

• a program may want to manipulate the state of Lisp, such that the reader would read the following expressions differently. But that's not possible if all code is in an already read expression. Common Lisp for example has packages, which are symbol namespaces. Changing a namespace might for example import a symbol and one might later use that symbol as it was imported. These things would not be possible that way if we have a single s-expression for the code.

• all your code would be already indented by some characters, by the usual Lisp code formatting conventions

Of course it is possible to write code in one expression, but as indicated above it is usually seen as less flexible and more problematic to edit in conventional text editors.

CL-USER 16 > (defmacro program (&body body) `(progn ,@body))
PROGRAM

CL-USER 17 > (program
               (defun foo (bar) (1+ bar))
               (defun baz (bar) (* pi (foo bar)))
               (+ (foo 10) (baz 20)))
76.97344572538566D0

Common Lisp was designed in such a way that:

• there are top-level defining macros like defun, defmacro, defvar and defclass for individual declarations.

• there are special macros and functions influencing the execution and compilation, which are not nesting: in-package, proclaim, ...

• there are some operators which are influencing execution and compilation, which are nesting: progn, eval-when, ... But these are usually not used to group large amounts of code.

One of the reasons is that a single s-expression is slighty less practical in actual programming in many cases.

Remember, the evaluator in Lisp works like this: it reads a form and then evaluates it. The file compiler in Lisp works like this: it reads a form, then compiles it and creates the compiled code.

Now if we have a single form in a file, then it might have some drawbacks:

• the form may be very large and the reader would return a very large data structure for the program

• if there is a s-expression syntax error, just reading that large form creates an error. Thus we would not work with smaller expressions and have eventually an error, instead we would always get the error from the s-expression reader for the whole program up-front. That can be undesirable.

• a program may want to manipulate the state of Lisp, such that the reader would read the following expressions differently. But that's not possible if all code is in an already read expression. Common Lisp for example has packages, which are symbol namespaces. Changing a namespace might for example import a symbol and one might later use that symbol as it was imported. These things would not be possible that way if we have a single s-expression for the code.

• all your code would be already indented by some characters, by the usual Lisp code formatting conventions, which wastes horizontal space

Of course it is possible to write code in one expression, but as indicated above it is usually seen as less flexible and more problematic to edit in conventional text editors.

CL-USER 16 > (defmacro program (&body body) `(progn ,@body))
PROGRAM

CL-USER 17 > (program
               (defun foo (bar) (1+ bar))
               (defun baz (bar) (* pi (foo bar)))
               (+ (foo 10) (baz 20)))
76.97344572538566D0

Common Lisp was designed in such a way that:

• there are top-level defining macros like defun, defmacro, defvar and defclass for individual definitions.

• there are special macros and functions influencing the execution and compilation, which are not nesting: in-package, proclaim, ...

• there are some operators which are influencing execution and compilation, which are nesting: progn, eval-when, ... But these are usually not used to group large amounts of code - but sometimes in code which is generated by Lisp.