Not quite sure what you mean there. If you are talking about the Lexer, it's also rather simple since LISP doesn't need lookahead. Everything is in prefix notation.
>Garbage Collector
Which can be incredibly simple since you only have the persistent global scope and the list local scope, so you only discard data that goes out of scope. There are no references
Heck, you could probably just write the Garbage Collector in LISP too.
>Hash Table
LISP-family languages usually aren't called LISP for being Hash Table Processors. There are only lists.
Not needed either, you can macro Vectors, you can macro the Object System, you have lists, not a stack and closures are a basic property of the language last I checked.
>Unicode
---------
LISP is a rather simple language since you can write a macro for almost everything, a minimal implementation only needs a couple keywords. Object Systems are usually implemented via macros.
It is special because after implementing a minimal set, you can program the language itself to provide the rest.
And I'd like you to name another language that is not assembler or original BASIC where you would not have to implement
all this stuff while remaining as simple and expressive as LISP.
I don't think you really need any of this complicated 1960s and later stuff. LISP is the second oldest programming language, it's really not complex.
The Reader is the thing which reads the many Lisp data structures: lists, symbols, floats, integers, strings, characters, vectors, arrays, structures, ...
> Which can be incredibly simple since you only have the persistent global scope and the list local scope, so you only discard data that goes out of scope. There are no references
Lisp has references.
> Heck, you could probably just write the Garbage Collector in LISP too.
Basically you can't.
> LISP-family languages usually aren't called LISP for being Hash Table Processors. There are only lists.
All Lisp have hash-tables since decades. Internally the symbol table is a hash-table in most Lisp implementations.
> Not needed either, you can macro Vectors, you can macro the Object System, you have lists, not a stack and closures are a basic property of the language last I checked.
You can't. You don't see to know what a macro is. If you only have linked lists, you can't make vectors. No macro will help you with that.
> Object Systems are usually implemented via macros.
They aren't. Object systems are a mix of new data structures, functions and some macros. In Common Lisp, the CLOS system is a layering of data structures, functions and only at the top are macros. Parts of CLOS then are defined in itself.
> It is special because after implementing a minimal set, you can program the language itself to provide the rest.
But it is not done that way. You won't implement arithmetic as a macro.
> while remaining as simple and expressive as LISP.
Once you have all that, Lisp is no longer simple.
> LISP is the second oldest programming language, it's really not complex.
Check the recent Scheme standard for some entertainment.
Forth has a minimal set of primitives as well, and an even simpler parser (it's literally "read until next space" and "search a linked list to see if this matches an existing word, otherwise, is this a number?, otherwise, yell")
And, likewise, the Turing completeness of those primitives doesn't mean what some naive new computer scientists think it means. Turing completeness doesn't mean that those primitives constitute a language which can be extended to become any language; it means that for any given Turing machine, those primitives can be used to write a program which computes the same thing as that Turing machine. That program might be, for instance, a small state machine dispatcher accompanied by a big table with some initial contents. VirtualBox can run an entire PC, and that PC can run an OS, under which we have a C++ compiler. That doesn't mean VirtualBox has been extended to be a C++ language implementation.
> You only need about 9 primitives and can build the rest from there.
You can't practically. No actual Lisp is developed that way. It's mostly without any practical use. It's a theoretical idea from lambda calculus. It is not an implementation technique for Lisp. It's also not special to Lisp, any Functional Programming language can do that. Note also that one does not need macros for that.
In a real Lisp implementation, numbers are not implemented based on functions. Any real-world Lisp implementation will use the facilities of a processor to represent numbers (integers, floats, ...) and to do computation with numbers. Thus numbers are a separate data type with their own operations. Both the data type and the operations will need to be implemented - the basic operations you mentioned won't help. Thus for a real Lisp, you will a) need to implement numbers using the machine facilities and you will need to understand them. For example floating point operations are in Lisp not simpler than in C, C++, Ada, Java, or any other language which provides floating point operations.
Any language which does not provide floating point operations (like an imaginary primitive Lisp) is simpler than a language with floating point operations (like most existing Lisp languages).
So, an imaginary primitive Lisp is simple. But that has no practical implications, since actual Lisp programming languages are not primitive, and thus not simple. See the definitions of popular Lisp dialects.
> You can implement arithmetic as macros and functions, from scratch.
You don't need macros. And no, nobody does that, because it is not practical.
> Point me at a language that won't require a symbol table that is not assembler.
Why?
> Point me at a language that is simpler to implement than LISP and is not assembler. (and maybe not brainfuck)
Forth. Basic. Logo.
> If you have a turing complete language, you can do everything. I don't think you know what a turing-complete language is.
I know what that is. I think you don't know what algorithmic complexity is and what the difference between a linked list and a vector is.
> How nitpicky.
No, it shows you that macros are neither necessary nor sufficient to implement an object system.
> Compared to most other popular languages, it is.
Basic is simpler. Forth is simpler. Logo is simpler.
Not quite sure what you mean there. If you are talking about the Lexer, it's also rather simple since LISP doesn't need lookahead. Everything is in prefix notation.
>Garbage Collector
Which can be incredibly simple since you only have the persistent global scope and the list local scope, so you only discard data that goes out of scope. There are no references
Heck, you could probably just write the Garbage Collector in LISP too.
>Hash Table
LISP-family languages usually aren't called LISP for being Hash Table Processors. There are only lists.
>Vectors, Object System, Stack Unwinding, Closures
Not needed either, you can macro Vectors, you can macro the Object System, you have lists, not a stack and closures are a basic property of the language last I checked.
>Unicode
---------
LISP is a rather simple language since you can write a macro for almost everything, a minimal implementation only needs a couple keywords. Object Systems are usually implemented via macros.
It is special because after implementing a minimal set, you can program the language itself to provide the rest.
And I'd like you to name another language that is not assembler or original BASIC where you would not have to implement all this stuff while remaining as simple and expressive as LISP.
I don't think you really need any of this complicated 1960s and later stuff. LISP is the second oldest programming language, it's really not complex.