4 ms·

Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? As a long-t

by 13415 8y ago

Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? As a long-time Racket and Scheme user, I'd say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithmetics.

outworlder 8y ago
This is reminiscent of 'numeric tower' discussions from years ago.
coder543 8y ago
> it just makes it harder to port all kinds of code that relies on modulo arithmetics. If you're relying on modulo arithmetic, you should be using a fixed size integer anyways, not one that varies based on the architecture. Go has fixed size integer types available, and modulo arithmetic should be using those, not "int".
- viraptor 8y ago
  I'm not sure how these two are related. Why would you mix modulo operations and fixed size? Modulo on an arbitrary bigint is perfectly valid and useful.
  - coder543 8y ago
    Modulo arithmetic refers to the property of fixed-size integers where they will predictably wraparound in expected ways if you overflow or underflow them. This wraparound is "free", so it used to be commonly used for cyclic high performance code. An arbitrary bigint is computationally more expensive, and it will never experience this effect, so it's a double whammy of irrelevance for bigints. You can manually do a modulo operation on a bigint, but that just makes them even more computationally expensive than a fixed size int, requires more code, and would be considered an unnecessary inconvenience by most people who care about modulo arithmetic.
    - Beldin 8y ago
      Except cryptographers. They like modulo arithmetic, and 64 bits really doesn't cut it.
      - deleted 8y ago
        [deleted]
dmurray 8y ago
> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.
- usrusr 8y ago
  It's like building in special handling for a string type, exactly one instead of a catalog of library options. I'd say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of "minimalism" would be providing tools to allow libraries to define what other languages can only support as special builtins. C++ and Scala went down that road, they minimize builtins by empowering libraries to replace them. That's also a form of minimalism, but not the one chosen by Go. Tangent: now I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type it inherited from Java or if just reimplements those syntax extras in the standard library using implicits.
  - dtech 8y ago
    > I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type Scala uses Java's String exactly, but does define a few extra methods using its extension method functionality (called implicit class in Scala) Templates like s"This is a string with a $variable", are part of the language, but `s` is a stdlib feature. xxx"First $a $b Second" will be translated by the compiler to new StringContext(Array("First ", " ", " Second")).xxx(a, b) The standard library defines `StringContext.s`, but there's no restriction. Several SQL Libraries for example define `StringContext.sql`, to allow you to safely and type-checked embed SQL queries directly inside the code.
- joppy 8y ago
  Arrays, slices, hashtables, and channels are not supported natively by the processor, but Go still has them as primitives. Why not also add a number type which behaves in a sane, easy-to-understand, useful way?

by 13415 8y ago

outworlder 8y ago

This is reminiscent of 'numeric tower' discussions from years ago.

coder543 8y ago

> it just makes it harder to port all kinds of code that relies on modulo arithmetics. If you're relying on modulo arithmetic, you should be using a fixed size integer anyways, not one that varies based on the architecture. Go has fixed size integer types available, and modulo arithmetic should be using those, not "int".

viraptor 8y ago
I'm not sure how these two are related. Why would you mix modulo operations and fixed size? Modulo on an arbitrary bigint is perfectly valid and useful.
- coder543 8y ago
  Modulo arithmetic refers to the property of fixed-size integers where they will predictably wraparound in expected ways if you overflow or underflow them. This wraparound is "free", so it used to be commonly used for cyclic high performance code. An arbitrary bigint is computationally more expensive, and it will never experience this effect, so it's a double whammy of irrelevance for bigints. You can manually do a modulo operation on a bigint, but that just makes them even more computationally expensive than a fixed size int, requires more code, and would be considered an unnecessary inconvenience by most people who care about modulo arithmetic.
  - Beldin 8y ago
    Except cryptographers. They like modulo arithmetic, and 64 bits really doesn't cut it.
    - deleted 8y ago
      [deleted]

dmurray 8y ago

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.

usrusr 8y ago
It's like building in special handling for a string type, exactly one instead of a catalog of library options. I'd say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of "minimalism" would be providing tools to allow libraries to define what other languages can only support as special builtins. C++ and Scala went down that road, they minimize builtins by empowering libraries to replace them. That's also a form of minimalism, but not the one chosen by Go. Tangent: now I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type it inherited from Java or if just reimplements those syntax extras in the standard library using implicits.
- dtech 8y ago
  > I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type Scala uses Java's String exactly, but does define a few extra methods using its extension method functionality (called implicit class in Scala) Templates like s"This is a string with a $variable", are part of the language, but `s` is a stdlib feature. xxx"First $a $b Second" will be translated by the compiler to new StringContext(Array("First ", " ", " Second")).xxx(a, b) The standard library defines `StringContext.s`, but there's no restriction. Several SQL Libraries for example define `StringContext.sql`, to allow you to safely and type-checked embed SQL queries directly inside the code.
joppy 8y ago
Arrays, slices, hashtables, and channels are not supported natively by the processor, but Go still has them as primitives. Why not also add a number type which behaves in a sane, easy-to-understand, useful way?