A core concept in LISP is the idea that code and data are interchangeable. While this principle holds true in a general sense across programming, LISP specifically emphasizes it both culturally and syntactically. Consider a simple LISP expression:
(+ 2 2)This expression evaluates to 4.
However, by introducing a quote before it:
'(+ 2 2)The result becomes the expression itself: (+ 2 2). This transformation signifies that “quoting” a LISP expression instructs the interpreter not to evaluate it, but instead to treat the expression as raw data.
The quoted expression can, of course, be evaluated at a later point:
(eval '(+ 2 2))Executing this yields 4 once more.
This illustrates how deeply ingrained the “code is data” philosophy is within LISP. The language provides a fundamental mechanism, quoting, to explicitly designate parts of the code for non-execution.
The context of web applications presents an interesting parallel. A web server’s primary function involves generating another program—the client program, composed of HTML and JavaScript—and delivering it to the client’s browser. This process of generating and transmitting code bears a strong resemblance to the concept of quoting.
JavaScript lacks a direct equivalent to LISP’s quoting mechanism. It is not possible to simply prefix a function with a special character to treat it as data rather than executable code. While wrapping code in a string literal is an option, it sacrifices syntax highlighting and other essential language benefits, making it an impractical approach for coding.
Directly “quoting” individual JavaScript code blocks without losing language advantages is not feasible. However, a different approach emerges if the concept of “quoting” could apply to an entire module.
React Server Components (RSC) represent a client-server programming paradigm that employs a similar concept for referencing client code from server code. The 'use client' directive enables the import of client-intended code without executing it on the server:
'use client'
export function onClick() {
alert('Hi.');
}Similar to LISP’s quoting, this directive designates a segment of code to be treated as data. However, a key distinction from LISP quoting is that the returned result is opaque; it prevents direct transformation or introspection of the code.
Consequently, when a server-side component imports a client-side function like onClick, it does not receive the actual function. Instead, it obtains a reference such as '/js/chunk123.js#onClick', which specifies how to load that module on the client. This mechanism provides code-as-data. Unlike LISP’s runtime quoting, this functionality is implemented during compile time through a bundler.
Ultimately, this client-side code is delivered to the browser (typically within a <script> tag) and evaluated there. At that point, the onClick function becomes fully operational and can be invoked.
This architecture provides the capability to construct programs that modularly combine behaviors executing at distinct stages—on both the server and the client. An example can be found here. Components outside the “quoted” client boundary manage server-exclusive resources, while those inside are stateful and reside on the client. Crucially, these components can be composed: server logic can encapsulate client logic, and vice versa, provided all composition originates from the server. Server-side composition ensures that all server-related operations complete within a single request/response roundtrip and are also progressively streamed.
While RSC offers significant advantages, its “quoting” mechanism is less powerful than LISP’s. React dictates the evaluation strategies, and the system does not support metaprogramming, such as direct code transformation. Therefore, the analogy to LISP’s quoting might be considered a conceptual stretch.
LISP boasts a rich history of solutions for composing code across diverse environments, with contemporary approaches like Electric gaining traction. A deeper understanding of these LISP paradigms could offer valuable insights for JavaScript developers, particularly regarding historical precedents and innovative concepts.
The author expresses gratitude and an intention to learn LISP in the future.
