Minimal syntax can be implemented in reader macros in Common Lisp. If you really think some punctuation marks are more readable than a LAMBDA form you can write a reader macro to do it (and people have).
Parens are not overloaded in Common Lisp. It's always (function value value ...). And lists are always (). It's an artifact of homoiconicity that the program code can be represented in the same first-class data structures that it manipulates. I think we can all agree that is an advantage.
'()
Is just a reader macro for QUOTE which returns its arguments unevaluated. LIST simply returns a new list from its arguments. BACKQUOTE lets you optionally evaluate parts of a list (which is useful unsurprisingly in macro definitions).
Re: seq; I don't really see the advantage. Some defaults might be right for certain applications but I prefer to be in control of making that decision.
ABCL interop is working rather well. They even have CLOS support now.
Parenscript generates great Javascript from Common Lisp code. The great thing about Lisp-like languages is that the evaluator can take a description of a process and create a machine capable of emulating that process. This happens to be really useful when experimenting with new languages. There's even a cl-python project to evaluate Python code in Common Lisp.
The great idea of Common Lisp was to bring together under one standard the forest of incompatible lisp implementations. I'm happy to see experimentation in the lisp space but it seems that fragmentation is only going to happen if everyone runs off into the woods to write their own incompatible lisp over things like syntax.
As for $SOME_HOST interop... a fair bit of the language is an artifact of the JVM. LOOP/RECUR is simply because the JVM is probably never going to support TCO (and while not required by a CL implementation it's nearly universal because it makes for efficient recursive programs... a style of program that is rather natural to lisps). The language doesn't have conditions and restarts because of the JVM (though I've heard it posited that it could be possible to implement them on top of exceptions).
Parens are not overloaded in Common Lisp. It's always (function value value ...). And lists are always (). It's an artifact of homoiconicity that the program code can be represented in the same first-class data structures that it manipulates. I think we can all agree that is an advantage.
Is just a reader macro for QUOTE which returns its arguments unevaluated. LIST simply returns a new list from its arguments. BACKQUOTE lets you optionally evaluate parts of a list (which is useful unsurprisingly in macro definitions).Re: seq; I don't really see the advantage. Some defaults might be right for certain applications but I prefer to be in control of making that decision.
ABCL interop is working rather well. They even have CLOS support now.
Parenscript generates great Javascript from Common Lisp code. The great thing about Lisp-like languages is that the evaluator can take a description of a process and create a machine capable of emulating that process. This happens to be really useful when experimenting with new languages. There's even a cl-python project to evaluate Python code in Common Lisp.
The great idea of Common Lisp was to bring together under one standard the forest of incompatible lisp implementations. I'm happy to see experimentation in the lisp space but it seems that fragmentation is only going to happen if everyone runs off into the woods to write their own incompatible lisp over things like syntax.
As for $SOME_HOST interop... a fair bit of the language is an artifact of the JVM. LOOP/RECUR is simply because the JVM is probably never going to support TCO (and while not required by a CL implementation it's nearly universal because it makes for efficient recursive programs... a style of program that is rather natural to lisps). The language doesn't have conditions and restarts because of the JVM (though I've heard it posited that it could be possible to implement them on top of exceptions).