6 ms·

That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavi

That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavior at all. 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.

kbp 8y ago
> And there is no undefined behavior at all. 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.
- lispm 8y ago
  It's only undefined in the standard. Most implementations document their behavior somehow. Generally I run my code with safety 3 and only selected portions might have unsafe code - but with args check before in surrounding code.
- stassats 8y ago
  That is theoretically true, but what implementation really does that with SAFETY being 3? Claiming that SBCL following the standard is poisoning anything is completely baseless, though.
  - kbp 8y ago
    > what implementation really does that with SAFETY being 3? 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"
    - stassats 8y ago
      It needs (optimize safety debug) and the function needs to be compiled (interpreted code doesn't perform any optimizations based on the types).
      - kbp 8y ago
        Sure, but the point is that that exact same code will throw a type error in SBCL. It at least complicates what you need to do before you can say "what implementation doesn't behave like that?".
        stassats 8y ago
        But what is the point, really? SBCL will disable type checks with safety=0, LW will enable with safety=3, debug=3. Is the point "read your documentation before relying on things"? 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.
        deleted 8y ago
        [deleted]
dang 8y ago
> 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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

kbp 8y ago

> And there is no undefined behavior at all. 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.

lispm 8y ago
It's only undefined in the standard. Most implementations document their behavior somehow. Generally I run my code with safety 3 and only selected portions might have unsafe code - but with args check before in surrounding code.
stassats 8y ago
That is theoretically true, but what implementation really does that with SAFETY being 3? Claiming that SBCL following the standard is poisoning anything is completely baseless, though.
- kbp 8y ago
  > what implementation really does that with SAFETY being 3? 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"
  - stassats 8y ago
    It needs (optimize safety debug) and the function needs to be compiled (interpreted code doesn't perform any optimizations based on the types).
    - kbp 8y ago
      Sure, but the point is that that exact same code will throw a type error in SBCL. It at least complicates what you need to do before you can say "what implementation doesn't behave like that?".
      - stassats 8y ago
        But what is the point, really? SBCL will disable type checks with safety=0, LW will enable with safety=3, debug=3. Is the point "read your documentation before relying on things"? 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.
        deleted 8y ago
        [deleted]

dang 8y ago

> 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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html