And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type.
Spreading misinformation like this is what's poisoning the ecosystem.
And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type.
Spreading misinformation like this is what's poisoning the ecosystem.
Please don't respond to flamebait by upping the ante. We've all seen what programming language flamewars lead to. Your comment would be much better without the last sentence.
Well, there is. Violating type declarations is UB in Common Lisp, the only thing the standard says about it is "the consequences are undefined". In SBCL, an error will be signalled, but there's no guarantees about what other compilers might do. This could show up if a Lisp programmer who primarily used SBCL was relying on the type system to do some of their input validation for them when portable code would have to actually check it (ie, in their head they might think their program will raise an error if you pass it garbage, when really it just invokes UB if you pass it garbage). I still don't think it's that big of an issue, and mentioning it alongside benchmarks certainly indicates some misunderstanding, but it's not completely baseless.
Generally I run my code with safety 3 and only selected portions might have unsafe code - but with args check before in surrounding code.
LispWorks:
CL-USER 1 > (declaim (optimize safety))
NIL
CL-USER 2 > (defun f (x) (declare (fixnum x)) x)
F
CL-USER 3 > (f "foo")
"foo"Or is the OP's point that SBCL shouldn't exist because it's "poisoning" and "a bad thing"?
That's the problem with such FUD, can't ignore it or somebody might actually believe it, can't just say "nonsense" since that's not convincing.