4 ms·

Well I guess car and cdr literally were CPU instructions back in the day, but it doesn't really make you a low level language in the way that C is. i.e: The ent

Well I guess car and cdr literally were CPU instructions back in the day, but it doesn't really make you a low level language in the way that C is. i.e: The entire language is really a thin wrapper over the assembly language which itself is an abstraction of the byte code. Most languages have arithmetic and more advanced mathematical operators that reflect actual op codes in the cpu, but that doesn't make those low level either.

lispm 8y ago
The expectation is still that cons cells and the operators CAR and CDR can be implemented very efficiently. A CONS cell will on a typical machine be just two machine words - on a Lisp Machine it was sometimes just one machine word - when the cons cell was a part of a linear list. If you look at an unsafe CAR operation, it is often just a single machine instruction. Take this function which calls FOO twice. FOO is just calling CAR and inlining this call. (defun bar (a) (declare (optimize (speed 3) (safety 0) (debug 0)) (type cons a) (inline foo)) (the cons (foo (the cons (foo a))))) The disassembly then shows that CAR is a MOV instruction: ; Size: 14 bytes. Origin: #x1002FB5E49 ; 49: 488B40F9 MOV RAX, [RAX-7] ; no-arg-parsing entry point ; 4D: 488B50F9 MOV RDX, [RAX-7] ; 51: 488BE5 MOV RSP, RBP ; 54: F8 CLC ; 55: 5D POP RBP ; 56: C3 RET For a language like Lisp this is low-level stuff: telling the compiler to optimize for speed, no runtime checks, provide no debug information, declare the type of a variable, declare return types and instruct the compiler to inline a function. Or take structures in CL. They are defined such that can be compiled to a linear vector-like data structure with slot-access to known and static offsets. No redefinition, no meta-data information - low overhead. Two of the original goals of Common Lisp were defined as this: > Portability > Common Lisp intentionally excludes features that cannot be implemented easily on a broad class of machines. On the one hand, features that are difficult or expensive to implement on hardware without special microcode are avoided or provided in a more abstract and efficiently implementable form. (Examples of this are the invisible forwarding pointers and locatives of Zetalisp. Some of the problems that they solve are addressed in different ways in Common Lisp.) On the other hand, features that are useful only on certain ``ordinary'' or ``commercial'' processors are avoided or made optional. (An example of this is the type declaration facility, which is useful in some implementations and completely ignored in others. Type declarations are completely optional and for correct programs affect only efficiency, not semantics.) Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, such as word length, while allowing some variety of implementation techniques. > Efficiency > Common Lisp has a number of features designed to facilitate the production of high-quality compiled code in those implementations whose developers care to invest effort in an optimizing compiler.

lispm 8y ago

The expectation is still that cons cells and the operators CAR and CDR can be implemented very efficiently. A CONS cell will on a typical machine be just two machine words - on a Lisp Machine it was sometimes just one machine word - when the cons cell was a part of a linear list. If you look at an unsafe CAR operation, it is often just a single machine instruction. Take this function which calls FOO twice. FOO is just calling CAR and inlining this call. (defun bar (a) (declare (optimize (speed 3) (safety 0) (debug 0)) (type cons a) (inline foo)) (the cons (foo (the cons (foo a))))) The disassembly then shows that CAR is a MOV instruction: ; Size: 14 bytes. Origin: #x1002FB5E49 ; 49: 488B40F9 MOV RAX, [RAX-7] ; no-arg-parsing entry point ; 4D: 488B50F9 MOV RDX, [RAX-7] ; 51: 488BE5 MOV RSP, RBP ; 54: F8 CLC ; 55: 5D POP RBP ; 56: C3 RET For a language like Lisp this is low-level stuff: telling the compiler to optimize for speed, no runtime checks, provide no debug information, declare the type of a variable, declare return types and instruct the compiler to inline a function. Or take structures in CL. They are defined such that can be compiled to a linear vector-like data structure with slot-access to known and static offsets. No redefinition, no meta-data information - low overhead. Two of the original goals of Common Lisp were defined as this: > Portability > Common Lisp intentionally excludes features that cannot be implemented easily on a broad class of machines. On the one hand, features that are difficult or expensive to implement on hardware without special microcode are avoided or provided in a more abstract and efficiently implementable form. (Examples of this are the invisible forwarding pointers and locatives of Zetalisp. Some of the problems that they solve are addressed in different ways in Common Lisp.) On the other hand, features that are useful only on certain ``ordinary'' or ``commercial'' processors are avoided or made optional. (An example of this is the type declaration facility, which is useful in some implementations and completely ignored in others. Type declarations are completely optional and for correct programs affect only efficiency, not semantics.) Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, such as word length, while allowing some variety of implementation techniques. > Efficiency > Common Lisp has a number of features designed to facilitate the production of high-quality compiled code in those implementations whose developers care to invest effort in an optimizing compiler.