3 ms·

It's bad because of the explicit signature. If the signature had been `string | int` thenn it's a type system feature

sparkie 2y ago
Yeah, we can consider `string`, `int` to both be subtypes of `string | int`, and `string & int` to be a subtype of both `string`, `int`. There are some problems with doing so though, such as inferring the types, but this can be mostly mitigated by giving types a polarity, as Dolan introduced in Algebraic Subtyping[1]. This can be a bit hard to wrap your head around at first because given a function `f : a -> b`, the parameter `a` has negative polarity and return type `b` has positive polarity, but in the function body, the polarities are reversed, and the argument becomes positive, with the result value being negative. Local variables are ambipolar as they can be both introduced and eliminated in the function body. It becomes even more of a problem when you have types of kind `* -> *` or higher where the type argument can be covariant or contravariant. As far as I'm aware type inference for handling these in combination with algebraic subtyping is still an open problem. [1]:https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/thesis.pdf https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/the...
librasteve 2y ago
good point - I am just a little reluctant to swallow that a strong type system is intended to stop us accidentally assigning a number to a string var - raku is an interesting case since the strong types in raku (aka perl6) were crafted so that the typical (untyped) perl case of my $x = "1"; print $x+1; #2 print $x.1; #'11' ('.' is perl for string concatenate) so in raku, untyped, thats my $x = "1"; say $x+1; #2 say $x~1; #'11' ('~' is raku for string concatenate) ok, but raku can be strongly typed too, so how to graduate to that without throwing out the first draft my IntStr $x = <1>; ('<>' is raku for Allomorph literal) say $x+1; #2 say $x~1; #'11' just reach for the IntStr type (it's built in and has a literal syntax sugar) the main idea for gradual typing to allow code to be evolved by adding types over time without necessarily knowing all the types you are going to settle on before you start

Yeah, we can consider `string`, `int` to both be subtypes of `string | int`, and `string & int` to be a subtype of both `string`, `int`. There are some problems with doing so though, such as inferring the types, but this can be mostly mitigated by giving types a polarity, as Dolan introduced in Algebraic Subtyping[1]. This can be a bit hard to wrap your head around at first because given a function `f : a -> b`, the parameter `a` has negative polarity and return type `b` has positive polarity, but in the function body, the polarities are reversed, and the argument becomes positive, with the result value being negative. Local variables are ambipolar as they can be both introduced and eliminated in the function body. It becomes even more of a problem when you have types of kind `* -> *` or higher where the type argument can be covariant or contravariant. As far as I'm aware type inference for handling these in combination with algebraic subtyping is still an open problem. [1]:https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/thesis.pdf https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/the...

librasteve 2y ago

good point - I am just a little reluctant to swallow that a strong type system is intended to stop us accidentally assigning a number to a string var - raku is an interesting case since the strong types in raku (aka perl6) were crafted so that the typical (untyped) perl case of my $x = "1"; print $x+1; #2 print $x.1; #'11' ('.' is perl for string concatenate) so in raku, untyped, thats my $x = "1"; say $x+1; #2 say $x~1; #'11' ('~' is raku for string concatenate) ok, but raku can be strongly typed too, so how to graduate to that without throwing out the first draft my IntStr $x = <1>; ('<>' is raku for Allomorph literal) say $x+1; #2 say $x~1; #'11' just reach for the IntStr type (it's built in and has a literal syntax sugar) the main idea for gradual typing to allow code to be evolved by adding types over time without necessarily knowing all the types you are going to settle on before you start