2 ms·

Common LISP is a bit weird because its type system was originally designed primarily as a way to speed up the executables (by letting the compiler aggressively

by ufo 11y ago

Common LISP is a bit weird because its type system was originally designed primarily as a way to speed up the executables (by letting the compiler aggressively optimize memory representation and remove runtime checks). Nowadays that kind of efficiency isn't as big of a deal as it used to be and people tend to go more towards the angle of using the type system for error detection but I still can't shake that feeling that CL's type system feels a bit off when you compare it to other modern type systems. (this is no excuse to not at least cite Common LISP though)

rurban 11y ago
No it's not. That's exactly the same use-case those slow dynamic languages have now. This kind of efficiency is a big deal, in languages designed by people with the same mindset. Getting errors is the same if at compile-time or in the test-suite or at the customer, though having them at compile-time is of course preferred. In LISP you have all 3 cases. In static languages only the first. These guys here solve their type-checking performance problem by deferring the check to dynamic code. Checks are expensive if your type checking code is slow, or the source code is a dynamic mess. We are talking about ruby on rails here, which is the biggest dynamic mess one can think of. It's the similar problem the JIT guys have, deferring compilation to only actually invoked code and skipping dead branches.
lispm 11y ago
A compiler with some compile time type checking has been implemented starting around 1985. That's the public domain CMUCL compiler (named Python) by Robert MacLachlan. See 'Types in Python' from the manual: https://common-lisp.net/project/cmucl/doc/cmu-user/compiler.html#toc127 https://common-lisp.net/project/cmucl/doc/cmu-user/compiler.... A variant of that compiler is used in the now popular SBCL implementation: http://www.sbcl.org/manual/index.html#Handling-of-Types http://www.sbcl.org/manual/index.html#Handling-of-Types

by ufo 11y ago

rurban 11y ago

No it's not. That's exactly the same use-case those slow dynamic languages have now. This kind of efficiency is a big deal, in languages designed by people with the same mindset. Getting errors is the same if at compile-time or in the test-suite or at the customer, though having them at compile-time is of course preferred. In LISP you have all 3 cases. In static languages only the first. These guys here solve their type-checking performance problem by deferring the check to dynamic code. Checks are expensive if your type checking code is slow, or the source code is a dynamic mess. We are talking about ruby on rails here, which is the biggest dynamic mess one can think of. It's the similar problem the JIT guys have, deferring compilation to only actually invoked code and skipping dead branches.

lispm 11y ago

A compiler with some compile time type checking has been implemented starting around 1985. That's the public domain CMUCL compiler (named Python) by Robert MacLachlan. See 'Types in Python' from the manual: https://common-lisp.net/project/cmucl/doc/cmu-user/compiler.html#toc127 https://common-lisp.net/project/cmucl/doc/cmu-user/compiler.... A variant of that compiler is used in the now popular SBCL implementation: http://www.sbcl.org/manual/index.html#Handling-of-Types http://www.sbcl.org/manual/index.html#Handling-of-Types