3 ms·

C++ doesn't have bounds checks in the std library in release builds by default, so you can't get better than that. Your reaction is like criticizing a talk whi

C++ doesn't have bounds checks in the std library in release builds by default, so you can't get better than that. Your reaction is like criticizing a talk which shows sorting 5 numbers with programs, It is not, because this idea that loops and bounds checks are complex in the first place isn't true. No other language invests so much complexity in a simple problem that is barely an issue in modern languages in the first place.

one-punch 3y ago
> C++ doesn't have bounds checks in the std library in release builds by default, so you can't get better than that. In Haskell you can provide your own prelude, which uses unsafe functions without bounds checks by default. With CPP or cabal tricks, you can easily have bounds checks only for debug builds, but no bounds checks for release builds. No Liquid Types needed either, though this is only testing in development but not compile time verification. Less safe, but same effort and result as in C++. > loops and bounds checks are complex in the first place isn't true. Liquid Types people are not thinking about only loops and bounds checks. They think about any properties, for example: * pointer checks, a huge security issue, see [1] or https://news.ycombinator.com/item?id=37376946 https://news.ycombinator.com/item?id=37376946. * valid expression checks (Beyond Bounds Checking of [2]), see https://news.ycombinator.com/item?id=37440896 https://news.ycombinator.com/item?id=37440896. [1]: https://arxiv.org/abs/2207.04034 https://arxiv.org/abs/2207.04034 "Flux: Liquid Types for Rust" [2]: https://www.tweag.io/blog/2022-01-19-why-liquid-haskell/ https://www.tweag.io/blog/2022-01-19-why-liquid-haskell/ "Why Liquid Haskell matters" Sorting 5 numbers is complex in the first place isn't true. No other technology invests so much complexity as programming and this is barely an issue in modern problem solving in the first place. My previous comments already said loops and bounds checks are not complex in the first place, and they are only used as a demo in a talk, as Liquid Types scale to handle any properties. I am pretty certain that a reasonable reader can judge the merits of our arguments and make up their mind. Thanks for raising a possible misconception about Haskell and Liquid Types, and this forced me to strengthen the arguments to clear the misconception for other reasonable readers. This is my last comment on this issue.
- CyberDildonics 3y ago
  In Haskell you can provide your own prelude, which uses unsafe functions without bounds checks by default. So your solution is to rewrite the haskell standard library yourself? With CPP or cabal tricks I don't know what cabal tricks is supposed to mean here.
  - tome 3y ago
    > With CPP or cabal tricks > I don't know what cabal tricks is supposed to mean here. It means conditional compilation, i.e. what the C preprocessor also gives you (but somewhat more principled).
  - one-punch 3y ago
    (Can't resist this one line rebuttal) > So your solution is to rewrite the haskell standard library yourself? No need--the simplest solution is to pass flags correctly to the dependent library (set all flags BoundsChecks, UnsafeChecks, and InternalChecks to false for the vector package) for release builds. Explanation after the one-line rebuttal: This exactly matches the C++ behavior: no bound checks for release builds, but with bounds checks for debug builds. This shows that Haskell can do what C++ can do, very easily, just by passing compiler/cabal/stack flags correctly. With this rebuttal, I think the issue is completely settled, at least for reasonable readers.
    - CyberDildonics 3y ago
      No need--the simplest solution is to pass flags correctly to the dependent library (set all flags BoundsChecks, UnsafeChecks, and InternalChecks to false for the vector package) for release builds. If performance is an issue, why not just do this instead of dealing with "Liquid Types". And with this rebuttal, the issue is now settled for all readers and even those differently abled that are using voice readers.
      - one-punch 3y ago
        Safety. For pointer checks. https://news.ycombinator.com/item?id=37440896 https://news.ycombinator.com/item?id=37440896

one-punch 3y ago

> C++ doesn't have bounds checks in the std library in release builds by default, so you can't get better than that. In Haskell you can provide your own prelude, which uses unsafe functions without bounds checks by default. With CPP or cabal tricks, you can easily have bounds checks only for debug builds, but no bounds checks for release builds. No Liquid Types needed either, though this is only testing in development but not compile time verification. Less safe, but same effort and result as in C++. > loops and bounds checks are complex in the first place isn't true. Liquid Types people are not thinking about only loops and bounds checks. They think about any properties, for example: * pointer checks, a huge security issue, see [1] or https://news.ycombinator.com/item?id=37376946 https://news.ycombinator.com/item?id=37376946. * valid expression checks (Beyond Bounds Checking of [2]), see https://news.ycombinator.com/item?id=37440896 https://news.ycombinator.com/item?id=37440896. [1]: https://arxiv.org/abs/2207.04034 https://arxiv.org/abs/2207.04034 "Flux: Liquid Types for Rust" [2]: https://www.tweag.io/blog/2022-01-19-why-liquid-haskell/ https://www.tweag.io/blog/2022-01-19-why-liquid-haskell/ "Why Liquid Haskell matters" Sorting 5 numbers is complex in the first place isn't true. No other technology invests so much complexity as programming and this is barely an issue in modern problem solving in the first place. My previous comments already said loops and bounds checks are not complex in the first place, and they are only used as a demo in a talk, as Liquid Types scale to handle any properties. I am pretty certain that a reasonable reader can judge the merits of our arguments and make up their mind. Thanks for raising a possible misconception about Haskell and Liquid Types, and this forced me to strengthen the arguments to clear the misconception for other reasonable readers. This is my last comment on this issue.

CyberDildonics 3y ago
In Haskell you can provide your own prelude, which uses unsafe functions without bounds checks by default. So your solution is to rewrite the haskell standard library yourself? With CPP or cabal tricks I don't know what cabal tricks is supposed to mean here.
- tome 3y ago
  > With CPP or cabal tricks > I don't know what cabal tricks is supposed to mean here. It means conditional compilation, i.e. what the C preprocessor also gives you (but somewhat more principled).
- one-punch 3y ago
  (Can't resist this one line rebuttal) > So your solution is to rewrite the haskell standard library yourself? No need--the simplest solution is to pass flags correctly to the dependent library (set all flags BoundsChecks, UnsafeChecks, and InternalChecks to false for the vector package) for release builds. Explanation after the one-line rebuttal: This exactly matches the C++ behavior: no bound checks for release builds, but with bounds checks for debug builds. This shows that Haskell can do what C++ can do, very easily, just by passing compiler/cabal/stack flags correctly. With this rebuttal, I think the issue is completely settled, at least for reasonable readers.
  - CyberDildonics 3y ago
    No need--the simplest solution is to pass flags correctly to the dependent library (set all flags BoundsChecks, UnsafeChecks, and InternalChecks to false for the vector package) for release builds. If performance is an issue, why not just do this instead of dealing with "Liquid Types". And with this rebuttal, the issue is now settled for all readers and even those differently abled that are using voice readers.
    - one-punch 3y ago
      Safety. For pointer checks. https://news.ycombinator.com/item?id=37440896 https://news.ycombinator.com/item?id=37440896