4 ms·

Changing the type signature (which, by the way, could be at least in easy cases implicitly deduced by the compiler rather than edited by hand) allows new client

Changing the type signature (which, by the way, could be at least in easy cases implicitly deduced by the compiler rather than edited by hand) allows new client code to assume that the result is present.

cubefox 2y ago
(or absent in the case of input parameters)
- the_af 2y ago
  A function in which the input is needed for the computation is very different to one where it's not needed. I would expect the type signature to reflect this, why would you want it otherwise?
  - cubefox 2y ago
    Say you have a function which expects objects of type Foo as an input and which returns objects of type Baz. One day, the function is improved by also accepting the type Bar, i.e. Foo|Bar. So Foo isn't needed for the computation, because Bar is also accepted. Or you have a function which expects objects of type String as an input. But then you realize that in your case, null values can be handled just like empty strings. So the input type can be relaxed to String|Null.
    - deleted 2y ago
      [deleted]
    - tobz619 2y ago
      There's a difference between empty strings and Null values imo. Just "" != Nothing If you want to handle empty strings as a input in haskell then you have a function of type `f :: String -> b` and you pattern match on your input? f "" = someResult f ... Nothing assumes a proper null in that there is genuinely nothing to work with. Still you can make a function to handle it or use `maybe`?
the_af 2y ago
Changing the type signature to relax/strengthen pre or post conditions is a fundamental change though. I would expect it to break call sites. That's a feature!
- HelloNurse 2y ago
  Strengthening postconditions and relaxing preconditions is harmless in theory, so it should be harmless in practice. Haskell gets in the way by facilitating clashes of incompatible types: there are reasons to make breaking changes to type signatures that in more deliberately designed languages might remain unaltered or compatible, without breaking call sites.
  - deleted 2y ago
    [deleted]
  - the_af 2y ago
    > If function f returns b or nothing/error, and is then improved to return b always, client code that calls f should not require changes or become invalid, except perhaps for a dead code warning on the parts that deal with the now impossible case of a missing result from f. You can achieve this by not changing the type and keeping the result as Maybe b. Dead code to handle `Nothing`, no harm done. However, you clarify you don't want this because: > Changing the type signature (which, by the way, could be at least in easy cases implicitly deduced by the compiler rather than edited by hand) allows new client code to assume that the result is present. But this cuts both ways. If the old call site can assume there may be errors (even though the new type "b" doesn't specify them) then the new call site cannot assume there are no errors (what works for old must work for new). I must say I see no real objection to the proposal at https://news.ycombinator.com/item?id=41519649 https://news.ycombinator.com/item?id=41519649 besides "I don't like it", which is not very compelling to me.

cubefox 2y ago

(or absent in the case of input parameters)

the_af 2y ago
A function in which the input is needed for the computation is very different to one where it's not needed. I would expect the type signature to reflect this, why would you want it otherwise?
- cubefox 2y ago
  Say you have a function which expects objects of type Foo as an input and which returns objects of type Baz. One day, the function is improved by also accepting the type Bar, i.e. Foo|Bar. So Foo isn't needed for the computation, because Bar is also accepted. Or you have a function which expects objects of type String as an input. But then you realize that in your case, null values can be handled just like empty strings. So the input type can be relaxed to String|Null.
  - deleted 2y ago
    [deleted]
  - tobz619 2y ago
    There's a difference between empty strings and Null values imo. Just "" != Nothing If you want to handle empty strings as a input in haskell then you have a function of type `f :: String -> b` and you pattern match on your input? f "" = someResult f ... Nothing assumes a proper null in that there is genuinely nothing to work with. Still you can make a function to handle it or use `maybe`?

the_af 2y ago

Changing the type signature to relax/strengthen pre or post conditions is a fundamental change though. I would expect it to break call sites. That's a feature!

HelloNurse 2y ago
Strengthening postconditions and relaxing preconditions is harmless in theory, so it should be harmless in practice. Haskell gets in the way by facilitating clashes of incompatible types: there are reasons to make breaking changes to type signatures that in more deliberately designed languages might remain unaltered or compatible, without breaking call sites.
- deleted 2y ago
  [deleted]
- the_af 2y ago
  > If function f returns b or nothing/error, and is then improved to return b always, client code that calls f should not require changes or become invalid, except perhaps for a dead code warning on the parts that deal with the now impossible case of a missing result from f. You can achieve this by not changing the type and keeping the result as Maybe b. Dead code to handle `Nothing`, no harm done. However, you clarify you don't want this because: > Changing the type signature (which, by the way, could be at least in easy cases implicitly deduced by the compiler rather than edited by hand) allows new client code to assume that the result is present. But this cuts both ways. If the old call site can assume there may be errors (even though the new type "b" doesn't specify them) then the new call site cannot assume there are no errors (what works for old must work for new). I must say I see no real objection to the proposal at https://news.ycombinator.com/item?id=41519649 https://news.ycombinator.com/item?id=41519649 besides "I don't like it", which is not very compelling to me.