3 ms·

Note that this is on SBCL 1.5.6 which is a little bit over a year old at this point; the article is from 2015 so we should pick a properly dated version from ht

Note that this is on SBCL 1.5.6 which is a little bit over a year old at this point; the article is from 2015 so we should pick a properly dated version from https://sourceforge.net/projects/sbcl/files/sbcl/ https://sourceforge.net/projects/sbcl/files/sbcl/ and check there. The Common Lisp implementations and compilers keep on getting better with time and they produce more and more compile-time warnings (especially SBCL).

dunefox 6y ago
I know, I just wanted to make a counterpoint in case somebody is deterred from the article.
thesz 6y ago
I once read modification of Greenspun's Tenth Rule which looked like "typical Common Lisp implementation contains slow ad hoc bug ridden implementation of half of Haskell type system". Which case I clearly see here.
- phoe-krk 6y ago
  That's a common phenomenon. Statically typed programming languages try to implement features of dynamically typed programming languages, whereas dynamically typed programming languages try to implement features of statically typed programming languages. On one side, we have a struggle of languages like C++ attempting to relax their own rigidness to achieve dynamic behavior, and on the other, we have languages like Javascript and Lisp attempting to constraint their own dynamic nature for benefits that come from static typing.
guenthert 6y ago
I haven't tried with a five year old version of SBCL, but even early on (from the beginning of the project?) SBCL treated type declarations (using DECLARE) as assertions (as opposed to mere hints for optimization), making it what some might call a gradual-typed system. So with properly declared type, SBCL could have found it then too. Now, some discourage the use of type declarations in Common Lisp (for a variety of reasons, one being the limited portability as less clever compilers don't warn against mismatch, but might produce broken code) and suggest the (run-time type testing) CHECK-TYPE (standard) macro instead. SBCL's type inference (at least in recent versions) is sufficiently clever to detect mismatches at compile time, when the type is (implicitly) announced using CHECK-TYPE.

dunefox 6y ago

I know, I just wanted to make a counterpoint in case somebody is deterred from the article.

thesz 6y ago

I once read modification of Greenspun's Tenth Rule which looked like "typical Common Lisp implementation contains slow ad hoc bug ridden implementation of half of Haskell type system". Which case I clearly see here.

phoe-krk 6y ago
That's a common phenomenon. Statically typed programming languages try to implement features of dynamically typed programming languages, whereas dynamically typed programming languages try to implement features of statically typed programming languages. On one side, we have a struggle of languages like C++ attempting to relax their own rigidness to achieve dynamic behavior, and on the other, we have languages like Javascript and Lisp attempting to constraint their own dynamic nature for benefits that come from static typing.

guenthert 6y ago

I haven't tried with a five year old version of SBCL, but even early on (from the beginning of the project?) SBCL treated type declarations (using DECLARE) as assertions (as opposed to mere hints for optimization), making it what some might call a gradual-typed system. So with properly declared type, SBCL could have found it then too. Now, some discourage the use of type declarations in Common Lisp (for a variety of reasons, one being the limited portability as less clever compilers don't warn against mismatch, but might produce broken code) and suggest the (run-time type testing) CHECK-TYPE (standard) macro instead. SBCL's type inference (at least in recent versions) is sufficiently clever to detect mismatches at compile time, when the type is (implicitly) announced using CHECK-TYPE.