5 ms·

I don't see how this reduces the need for a test that the wrong type is handled correctly.

dmichulke 10y ago
The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
- mac01021 10y ago
  And you don't need tests to make sure the assertions are there?
  - dmichulke 10y ago
    Interesting point :) At some point you have to assume something is there and correct (e.g., you don't write tests to check whether the tests are there, also you assume the testing tools work, ...). In static languages you also assume the programmer set the right type for the function argument, so you might as well assume to have an assertion in the critical code of the functional languages.
    - bbcbasic 10y ago
      > At some point you have to assume something is there and correct If you excel at compositional design then this may work OK but a lot of code bases I have worked on just need a good ol' refactor to sort the mess out. And then the "there and correct" part could fail due to human error, or the new person not knowing the old assumptions etc. The asserts are a step in the right direction in documenting the assumptions though. Types go one level better by both documenting the interface, and enforcing that contract at compile time.
  - winstonewert 10y ago
    Do you need a test to verify that your compiler correctly checks the type signature? (Actually, that could be occasionally useful in the face of implicit conversions)
    - eropple 10y ago
      My compilers have test suites.
      - winstonewert 10y ago
        And the compiler that generates the assert also has a test suite for that.
    - bbcbasic 10y ago
      You can't get true 100% coverage* on digital hardware. (on quantum maybe!) so what to test or not is always a judgement call. Most of the time I'd assume the software stack is trustworthy but if you are doing something extreme you may want to test the compiler or even formally prove the compiler works as expected. * true as in all possible inputs and outputs rather than merely all code paths
      - winstonewert 10y ago
        Perhaps a better way to ask my question: do you write a test to make sure your type signature was correct?

The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.

mac01021 10y ago
And you don't need tests to make sure the assertions are there?
- dmichulke 10y ago
  Interesting point :) At some point you have to assume something is there and correct (e.g., you don't write tests to check whether the tests are there, also you assume the testing tools work, ...). In static languages you also assume the programmer set the right type for the function argument, so you might as well assume to have an assertion in the critical code of the functional languages.
  - bbcbasic 10y ago
    > At some point you have to assume something is there and correct If you excel at compositional design then this may work OK but a lot of code bases I have worked on just need a good ol' refactor to sort the mess out. And then the "there and correct" part could fail due to human error, or the new person not knowing the old assumptions etc. The asserts are a step in the right direction in documenting the assumptions though. Types go one level better by both documenting the interface, and enforcing that contract at compile time.
- winstonewert 10y ago
  Do you need a test to verify that your compiler correctly checks the type signature? (Actually, that could be occasionally useful in the face of implicit conversions)
  - eropple 10y ago
    My compilers have test suites.
    - winstonewert 10y ago
      And the compiler that generates the assert also has a test suite for that.
  - bbcbasic 10y ago
    You can't get true 100% coverage* on digital hardware. (on quantum maybe!) so what to test or not is always a judgement call. Most of the time I'd assume the software stack is trustworthy but if you are doing something extreme you may want to test the compiler or even formally prove the compiler works as expected. * true as in all possible inputs and outputs rather than merely all code paths
    - winstonewert 10y ago
      Perhaps a better way to ask my question: do you write a test to make sure your type signature was correct?