Rethinking Math for Gleam

[jagged parcel]

—— Suggestion ——

— Unified Numbers —

A new type which forms a common metaclass of ints and floats:

Number := Int(x) | Float(x) | Inf | -Inf | NaN

— Unified Operators —

No more dot affix for float operations! Instead, type conversion of ints to floats when floats are involved.

Int + Int -> Int
Int + Float -> Float
Float + Int -> Float
Float + Float -> Float

Same type handling for “-”, “*”, “/” and “**”.

Standard Division is “/” and returns “NaN” for division by zero.

Floor Division is “/.” (repurposed operator) and goes like this:

Int /. Int -> Int
Int /. Float -> Float
Float /. Int -> Int
Float /. Float -> Float

Floor Division by floats: Number of steps by the right operand furthest away from 0 possible without going beyond the left operand.

Floor Division allows for flooring a float to an int: x /. 1 -> z where “x” is any float and “z” is the resulting int.

— Infix Exponentiation —

Int ** Int -> Int
Int ** Float -> Float
Float ** Int -> Float
Float ** Float -> Float

Same type handling as “+”.

— Infinities and Invalid —

“Inf”, “-Inf” and “NaN”: Edge cases may be discussed in the community!

— Positive and Negative Zeros —

They may be necessary for better compatibility with JavaScript’s floating point numbers and to better handle edge cases with infinities. If added, please discuss the possible cases here too!

— Unified Library —

New module for Unified Numbers (best named “number” or “math”), merging the “int” and “float” libraries into one, removing current de facto duplicates and keeping all the functions from both.

— No Curly Braces for Grouping —

Nesting is already reduced with the pipeline operator so parentheses are perfectly fine! They are also easier on the eyes when reading arithmetic computations and correspond to mathematical notation.

#768594524158427168 #general #math #number #int #float #types

[undone moth]

Gleam doesn't have subtyping so that union is not possible

BEAM doesn't have NaN so that is not possible either

[jagged parcel]

In case anyone is worried about types here: Gleam should be type robust but certainly not “type stubborn”. What I mean by this is that since ints and floats have many similarities, they should be treated similarly in these regards. This includes both arithmetics and library functions. It doesn’t mean that ints and floats won’t exist in Gleam anymore at all!

[jagged parcel]

Okay, then please go add it, it’s a very useful feature anyway!

[undone moth]

It's not

Not having subtyping is one of the main design goals of Gleam

[jagged parcel]

Okay, but maybe there is another way…

[undone moth]

A lack of subtyping is a huge part of why Gleam is so nice to work with

[undone moth]

I think you're describing interfaces here, a feature that Gleam does not have by design.

[jagged parcel]

Just like tuples are an exception being a heterogenous container, numbers can be an exception to no subtyping, no?

[jagged parcel]

Hm…

[undone moth]

Tuples are not an exception to any rules in Gleam

Gleam doesn't have special cases as much as possible, it is a very consistent language

What problem are you trying to solve?

[jagged parcel]

Regarding that, maybe we can go ask the rest of the community whether they’d be okay with making an exception here.

[undone moth]

This isn't a democracy! I make the design decisions.

Design by committee results in poor design most often

So if something is to change it then the person who wants it needs to present examples of real-world problems that cannot be solved with Gleam today that can be with the new system

[jagged parcel]

I didn’t mean it that way! Saying that no subtyping makes Gleam “nice to work with” seems rather subjective to me. I didn’t mean to come off as aggressive or something.

[jagged parcel]

Okay, I’ll bring in some real code examples then.

[undone moth]

Thank you

[jagged parcel]

One small correction from the suggestion (if it would be applied): Standard Division of two ints would yield a float.

[split widget]

Isn't it too late for a change like this?

It seems like this would be very breaking

[undone moth]

Yes any new system would needs to be backwards compatible

[pastel apex]

There is an IEEE float package that I use. It's very good

[exotic folio]

This whole thing goes against a lot of gleam principles I feel.
And, as pointed out above is nowhere near backwards compatible

(Also FYI Int ** Int -> Int doesn't really work because what what do you do with negative exponents)

[undone moth]

Copy Elm and just return a float and pretend it's an int 😎

[exotic folio]

How does Erlang store numbers internally? Does it have separate int and float types?