> You can add garbage collection to Forth
Sure, but to do this properly you'd need to get your hands dirty with the implementation. Garbage collection doesn't work well as a bolted-on library, it needs to be handled in the language implementation. Forth is no different from any other language in that regard.
> I can't say anything about adding a type system, because it's unclear what sort of type system would even apply here.
It's directly analogous to static type-checking in a 'normal' programming-language, except we use the stack for accepting parameters and for returning values.
It would ensure each word manipulates the stack in the expected way, ensuring that the appropriate number of elements are consumed and pushed, and that each element is treated as being the correct kind of data (type-checking should fail if you attempt to dereference an integer).
This has been done in the Kitten programming language. [0] Java bytecode verifiers do something similar.
> SBCL even lets you hook into the compiler, and I saw some article about someone adding vectorization to SBCL using only user-level code.
Neat. I like the idea of advanced optimisations as libraries, sounds like a good research topic.
> it seems like you're saying that "extensible" means "easily extended" or "doesn't take serious engineering." It just means you can extend it (and, I'd add, in a principled way)
Perhaps I seem dismissive, but it just doesn't seem to me like many serious language features can be done properly in extensible languages.
The latest major features in mainstream programming languages are await/async and borrower-checking. I imagine it might be possible to implement await/async using Lisp macros, but I really doubt the same goes for borrower-checking.
> In Lisp, you can (and do) define pattern match destructuring and lvalue assignments entirely using macros.
That's pretty impressive, but it still seems that there are plenty of useful language-extensions that can't practically be implemented in extensible languages.
[0] https://kittenlang.org/
Sure, but to do this properly you'd need to get your hands dirty with the implementation. Garbage collection doesn't work well as a bolted-on library, it needs to be handled in the language implementation. Forth is no different from any other language in that regard.
> I can't say anything about adding a type system, because it's unclear what sort of type system would even apply here.
It's directly analogous to static type-checking in a 'normal' programming-language, except we use the stack for accepting parameters and for returning values.
It would ensure each word manipulates the stack in the expected way, ensuring that the appropriate number of elements are consumed and pushed, and that each element is treated as being the correct kind of data (type-checking should fail if you attempt to dereference an integer).
This has been done in the Kitten programming language. [0] Java bytecode verifiers do something similar.
> SBCL even lets you hook into the compiler, and I saw some article about someone adding vectorization to SBCL using only user-level code.
Neat. I like the idea of advanced optimisations as libraries, sounds like a good research topic.
> it seems like you're saying that "extensible" means "easily extended" or "doesn't take serious engineering." It just means you can extend it (and, I'd add, in a principled way)
Perhaps I seem dismissive, but it just doesn't seem to me like many serious language features can be done properly in extensible languages.
The latest major features in mainstream programming languages are await/async and borrower-checking. I imagine it might be possible to implement await/async using Lisp macros, but I really doubt the same goes for borrower-checking.
> In Lisp, you can (and do) define pattern match destructuring and lvalue assignments entirely using macros.
That's pretty impressive, but it still seems that there are plenty of useful language-extensions that can't practically be implemented in extensible languages.
[0] https://kittenlang.org/