Racket:
> (define (fact n)
(if (= n 1)
1
(* n (fact (- n 1)))))
> (fact 6)
720
OCaml: # let rec fact = function
| 1 -> 1
| n when n > 1 -> n * (fact (n - 1))
in fact 6;;
- : int = 720115 karma · joined January 22, 2021
Racket:
> (define (fact n)
(if (= n 1)
1
(* n (fact (- n 1)))))
> (fact 6)
720
OCaml: # let rec fact = function
| 1 -> 1
| n when n > 1 -> n * (fact (n - 1))
in fact 6;;
- : int = 720If you can provide (valid!) methods `T -> U` and `U -> T` for two types, why wouldn't `T = U` hold? (Atleast for types where `=` makes sense)
This is the definition I am using:
> S is a subtype of T, written S <: T, if a value of type S can safely be used in any context where a value of type T is expected.
from Pierce's "Software Foundations"
Of course, you may not want to make `String <: Number` and `Number <: String` (and thus `String = Number`), because there is no sensible way to do so; but this is an issue with the way PHP/JS handles subtyping, not with the notion of subtyping itself and certainly does not apply to the example of nullable types.
Unfortunately, I am not familiar enough with C++ to comment on the other question, sorry!
But surely, you can still use subtyping in other cases -- when it is already unboxed -- right?
Like so: `T <: T?` for all boxed `T`.
the presence of an implicit conversion rule `T -> T?` amounts to the observation that `T <: T?`, where <: is the subtyping relation
> make an unboxed integer nullable ...
I don't think any language allows this, in any case disallowing nullability for unboxed types amounts to the observation that `P !<: P?`, where !<: is "does not subtype"
I believe (unless I have misunderstood you) that both your examples are subsumed (heh) by subtyping
It seems aerospace engineers are just like priests and counselors in the courts of ancient kings.....
Peak HN.
Did anybody think this through more than once?
I would just like to point out that the GP did mention,
>...not culturally specific to Chinese...