LITHPers often >>204 claim the parens soup is the basis of computing. They unironically think CPUs execute lambda calculus
expressions, not assembly opcodes: since they refuse to believe
assembler or layer exists >>199,200 their frame of reference cannot entertain the idea that 'lambda calculus' is actually high-level representation of available hardware reality(note how CAR/CDR are LISP words divorced from their original meaning).
Their entire delusion is inability
to reconcile mathematical abstractions(the lambda soup) and reality(imperative sets of commands and data registers) which underlies their abstractions and defines the performance and "strange limitations" thereof(garbage collection and linked lists being incredibly inefficient for their purpose as basis of computation). Fanatic LISPers cannot see the low-level stuff,
their position is that pseudocode is the real code, not a blueprint but an exact formula unaffected by the compiler and hardware.
The actual idea that 'lambda calculus' doesn't actually exist,
and is merely emulated by a virtual machine that is LISP, seems
repugnant and offensive, so they invent coping mechanisms that
involves fantasies about computing: that LISP virtual machine, interpretation that is running on C-based software is somehow enabling their software to transcend above limits(garbage collection enabling the idea that 'something manages their memory for them') and circumstances(runtime interpretation allowing 'code to be used as data'), to feel smug about languages without these qualities, despite the LITHPers relying on them on the lower level.
When a lisp weenies boldly proclaims how superior LISP is, he
doesn't see irony that C-bases interpreter can be embedded in a
C-program which hold far more computational flexibility than their
parens soup. They just demand that this lower-level language on which LISP is constructed to be exactly equivalent to it, and when
some qualities of LISP are exposed to be equivalent to some primitive aspects of the underlying language they feel offended
because their fantasy abstraction being exclusive to LISP is the basis of their pride and elitism.
Of course C preprocessor and above mentioned lambda.h are not the same as LISP lambdas and LISP macros, C is a static system language: C can emulate any part of LISP interpreter, even if C isn't a 'pure' functional language.
C preprocessor can achieve most of LISP macro functionality:
its primitives are capable of expressing LISP constructs despite
being far different from LISP itself(which irks LITHPers because
their delusion ascribes exclusive magical qualities to LISP interpreters, denying that functional programming exists outside of LISP or that all functional programming requires LISP).