4 ms·

> a big problem w/ static languages is that the developers of these languages are not willing to compromise type-safety for simplicity: there are very few 80/20

> a big problem w/ static languages is that the developers of these languages are not willing to compromise type-safety for simplicity: there are very few 80/20 type systems out there that just say "Well, that's too hard to deal w/ you can bail out to unsafe code" when the implementation gets too crazy. Well, this is the internet, so there will always be someone to disagree with you. In this case, I get to be one of those people for you! Yay, you. :) I find that most statically typed languages do bail out on type safety for simplicity for very many cases. Take arithmetic. Just about every statically typed language allows you to add two `int32`s together to get another `int32` with no acknowledgement in the type system that this operation my fail (overflow/underflow). Some languages will wrap the value around, and some will actually abort, but those are "runtime" decisions and not in the static type systems. Similarly, most languages allow us to compare IEEE float values for equality with no complaints from the type checker. Most languages allow us to index an array and assume that we will always receive a value. It's funny that you mention Java's generics, because they are kind of implemented in the exact 80/20 way you describe. Java's generics are type-erased at compile time, so all of these generic values and functions actually end up working in terms of `Object` (the base/root reference type) and doing runtime casts where needed. The only reason that's possible is because of the JVM's type system allowing for all of that loosey-goosey stuff.

alcover 3y ago
> Some languages will wrap the value around, and some will actually abort What if a language had clamped int and modular mod types ? Overflow on mod would work as advertised and, if you disabled abort, overflow on int would be closer to its virtual value than if wrapped. mod32 m = UINT_MAX+1 //-> 0 int32 i = INT_MAX+1 //-> INT_MAX
- Jtsummers 3y ago
  Ada offers modular types (ranging from 0 to modulus-1 as expected) with the overflow and underflow behavior you want, but not a clamped type as you describe it. So you can get the first but not the second behavior.
  - alcover 3y ago
    So, Ada modular types are just like C uint ?
    - Jtsummers 3y ago
      Except that it allows for an arbitrary modulus. For instance, you can have: type Whatever_Name is mod 10; Removing restrictions is nice, lets the language and its type system actually express parts of the program logic unlike the inexpressive type system C provides.
      - alcover 3y ago
        Ok that's nice. Would one call that a dependent type ? I guess I would naively implement this by appending %10 to all assignments to a Whatever_Name.
        Jtsummers 3y ago
        No. Dependent types go further and allow you to do things like express that the length of an output vector/array is the same as some input number. That is, depends on some value (as in a runtime value). This mod type is fixed at compile time.
- nuancebydefault 3y ago
  I don't know of any language that has these types, i personally find them not so handy. What would e.g. happen if you mix both types? If you want mod or clip functionality for a certain part of an algo, it is easy enough to make a function that does it, you can overload the + operator if you want the algo code to read or write more easily. Also, in C it is simply modulo (straight what the CPU does) and in python there's simply no overflow, every int is an object that can be as big as needed. Both takes are consistent and rather straightforward to understand.
  - alcover 3y ago
    > What would e.g. happen if you mix both types? Like in int32 y=INT_MAX mod32 x=1 y+=x ? You'd get y==INT_MAX. Or did you mean something more involved ? > you can overload the + operator I fail to see the need. (Sorry I'm a bit tired). In this thread context of static languages, your compiler knows the target type of an assignement (clip/mod) and so applies the right correction. > in python there's simply no overflow, every int is an object that can be as big as needed I guess there's a huge speed penalty in wrapping values into objects.
    - nuancebydefault 3y ago
      I'm not sure if the target type is always clear. Y=(x+x)+y What is the target type for x+x? You could argue that you can have the same problem with operator overloading. But then again, it is best to implement the class just for a specific (type of) algo whithin which you use the overloaded + operator (or maybe better another symbol, resembling a + sign) in an unambiguous way. Also the class might have more functionality specifically suited for that type of algo. The benifits are less ambiguity and, that normal operations keep being fast (directly use the cpu arithmetic functions); the code is only slower where clipping or something the like is needed. Python is indeed slow and resource intensive, that's where libraries like numpy fit in. It uses vectorized native types (numpy ints and floats are native machine types), together with vector operations running in a precompiled low level language. Python only sees the 'outside' of the vectors as python objects. I once wondered why my language did not have native support for fixed point type operations. Once i started implementing custom types for and a class supporting fixed point, i noticed the sheer amount of design choices that were needed. A concise generic implementation of it is nearly impossible.
- skitter 3y ago
  Rust has those types as Saturating<u32> and Wrapping<u32>.
pjmlp 3y ago
For the time being, one of the goals of Valhala is to fix that, which is also another reason why it is taking so long to re-ingenier value types, without breaking the world of compiled jars in Maven Central.
recursivedoubts 3y ago
late to reply to this, but the problem w/ java generics is they picked the wrong 80 and the wrong 20...

alcover 3y ago

> Some languages will wrap the value around, and some will actually abort What if a language had clamped int and modular mod types ? Overflow on mod would work as advertised and, if you disabled abort, overflow on int would be closer to its virtual value than if wrapped. mod32 m = UINT_MAX+1 //-> 0 int32 i = INT_MAX+1 //-> INT_MAX

Jtsummers 3y ago
Ada offers modular types (ranging from 0 to modulus-1 as expected) with the overflow and underflow behavior you want, but not a clamped type as you describe it. So you can get the first but not the second behavior.
- alcover 3y ago
  So, Ada modular types are just like C uint ?
  - Jtsummers 3y ago
    Except that it allows for an arbitrary modulus. For instance, you can have: type Whatever_Name is mod 10; Removing restrictions is nice, lets the language and its type system actually express parts of the program logic unlike the inexpressive type system C provides.
    - alcover 3y ago
      Ok that's nice. Would one call that a dependent type ? I guess I would naively implement this by appending %10 to all assignments to a Whatever_Name.
      - Jtsummers 3y ago
        No. Dependent types go further and allow you to do things like express that the length of an output vector/array is the same as some input number. That is, depends on some value (as in a runtime value). This mod type is fixed at compile time.
nuancebydefault 3y ago
I don't know of any language that has these types, i personally find them not so handy. What would e.g. happen if you mix both types? If you want mod or clip functionality for a certain part of an algo, it is easy enough to make a function that does it, you can overload the + operator if you want the algo code to read or write more easily. Also, in C it is simply modulo (straight what the CPU does) and in python there's simply no overflow, every int is an object that can be as big as needed. Both takes are consistent and rather straightforward to understand.
- alcover 3y ago
  > What would e.g. happen if you mix both types? Like in int32 y=INT_MAX mod32 x=1 y+=x ? You'd get y==INT_MAX. Or did you mean something more involved ? > you can overload the + operator I fail to see the need. (Sorry I'm a bit tired). In this thread context of static languages, your compiler knows the target type of an assignement (clip/mod) and so applies the right correction. > in python there's simply no overflow, every int is an object that can be as big as needed I guess there's a huge speed penalty in wrapping values into objects.
  - nuancebydefault 3y ago
    I'm not sure if the target type is always clear. Y=(x+x)+y What is the target type for x+x? You could argue that you can have the same problem with operator overloading. But then again, it is best to implement the class just for a specific (type of) algo whithin which you use the overloaded + operator (or maybe better another symbol, resembling a + sign) in an unambiguous way. Also the class might have more functionality specifically suited for that type of algo. The benifits are less ambiguity and, that normal operations keep being fast (directly use the cpu arithmetic functions); the code is only slower where clipping or something the like is needed. Python is indeed slow and resource intensive, that's where libraries like numpy fit in. It uses vectorized native types (numpy ints and floats are native machine types), together with vector operations running in a precompiled low level language. Python only sees the 'outside' of the vectors as python objects. I once wondered why my language did not have native support for fixed point type operations. Once i started implementing custom types for and a class supporting fixed point, i noticed the sheer amount of design choices that were needed. A concise generic implementation of it is nearly impossible.
skitter 3y ago
Rust has those types as Saturating<u32> and Wrapping<u32>.

pjmlp 3y ago

For the time being, one of the goals of Valhala is to fix that, which is also another reason why it is taking so long to re-ingenier value types, without breaking the world of compiled jars in Maven Central.

recursivedoubts 3y ago

late to reply to this, but the problem w/ java generics is they picked the wrong 80 and the wrong 20...