Generic type/function parameters over values

[Shad0wRim]

In Rust, there are const generics that allow a type to be generic over a value rather than a type:

fn foo<const N: usize>(arr: [i32; N]) { todo!(); }

struct Bar<const N: usize>([i32; N])

I would love something like this to be put into gleam, using perhaps using const like rust or just by specifying the type of the parameter in the type parameter.

// rust-like
type MyType(const n: Int) {
  Phantom(a: Int, b: Int)
  Concrete(a: Int, n: Int)
}
// without const
type MyType(n: Int) {
  Phantom(a: Int, b: Int)
  Concrete(a: Int, b: Int, n: Int)
}

Instantiating this type would require a type hint, as I am unsure how it could be specified in the constructor if it is used as a "phantom" parameter.
Perhaps if the type parameter name shares the same name and type as one of the fields in the record, the type hint could be removed, but the corresponding field would have to be known at compile time.

fn main() {
  // type hinted
  let val: MyType(5) = Phantom(1, 2)
  let defined = Concrete(1, 2, 5)
}

Functions that use this type could extract the const type parameter with similar syntax to current generics

fn my_func(val: MyType(n)) {
  let assert Phantom(a, b) = val
  a * n
}

Would love some feedback on this, and would love something like this as I ran into an issue where I couldn't create a type representing the rationals adjunct square_root(n) without creating a separate type for each n or supplying the n to each function call, making the calls not type-safe.

[lpil]

Hello! Could you expand on what real-world problems and pain points this feature would solve for Gleam users please? The concrete benefits of adding this feature are not very clear to me yet. Thanks!

[Shad0wRim]

Currently, if someone wants to use something like bounded integer type, error checking has to be done at runtime in order to validate that the value is actually bounded.

type BoundedInt {
  BoundedInt(value: Int, low: Int, high: Int)
}

fn do_stuff(val: BoundedInt) -> Result(a, Nil) {
  case val.value >= val.low && val.value <= val.high {
    True -> Ok(more_stuff(val))
    False -> Err(Nil)
  }
}

With a const parameter, this check can be eliminated by knowing that the type enforces the range it can be bounded, for example:

opaque type BoundedInt(const low: Int, const high: Int) {
   BoundedInt(val)
}

fn do_stuff(val: BoundedInt(0, 100)) -> a {
  more_stuff(val)
}

The function signature knows that due to the restrictions of the type, the value must be in the correct range and this error checking can be solely done by the constructor of the type, while also removing the error types from the return since we don't have to validate input, the type validates it.

Another example would be with a mathematical field, such as Z[√n], represented by (a + b√n)

type ZRootN {
  ZRootN(a: Int, b: Int, n: Int)
}

fn add(x: ZRootN, y: ZRootN) -> Result(ZRootN, Nil) {
  case x.n == y.n {
    True -> ZRootN(x.a + y.a, x.b + y.b, x.n)
    False -> Err(Nil)
  }
}

The fields Z[√2] and Z[√3] are separate spaces and shouldn't interact with one another, and this can be checked at compile time while still being general using a const parameter:

type ZRootN(const n: Int) {
  ZRootN(a: Int, b: Int)
}

fn add(x: ZRootN(n), y: ZRootN(n)) -> ZRootN(n) {
  ZRootN(x.a + y.a, x.b + y.b)
}

This removes the need for any error checking done, removing the Result from the signature and making add make more sense (adding two numbers should be infallible) and removes code duplication if multiple types of these types want to be used, since each value in the parameter would constitute a separate type.

[Shad0wRim]

Another use case would be for using the newtype pattern by not introducing new types, but by grouping them together with one type but using the variants to distinguish the types:

type State {
  Valid
  Pending
  Invalid
}
type Process(const s: State) {
  Data(v: Int)
}

fn do_stuff(val: Process(Valid)) {
  todo
}

Since the parameter is a value, perhaps it can be returned and acted on by other functions.

fn get_state(val: Process(s)) -> State {
  s
}

[lpil]

What would these phantom type level values give you that regular phantom types do not?

pub type N0

pub type N100

pub opaque type BoundedInt(low, high) {
   BoundedInt(val)
}

pub fn do_stuff(val: BoundedInt(N0, N100)) -> a {
  more_stuff(val)
}

[Shad0wRim]

Being able to associate a value with the type would allow the constructor for this type to be simultaneously generalized and type safe, If there is a way to associate a value with a type in a way that allows this without this feature then this feature would be redundant, but I couldn't find a way to do that.

pub opaque type BoundedInt(const low: Int, const high: Int) {
  BoundedInt(val)
}

pub fn new(val, low, high) -> Result(BoundedInt(low, high), Nil) {
  case val <= high && val >= low {
    True -> Ok(BoundedInt(val))
    False -> Err(Nil)
  }
}

The way to do this with regular phantom types the way I see it would be to create a separate function for each one:

pub type N100
pub type N50
pub type N0

pub opaque type BoundedInt(low, high) {
  BoundedInt(val)
}

pub fn new_0_100(val) -> Result(BoundedInt(N0, N100), Nil) {
  case val <= 100 && val >= 0 {
    True -> Ok(BoundedInt(val))
    False -> Err(Nil)
  }
}

pub fn new_0_50(val) -> Result(BoundedInt(N0, N100), Nil {
  todo
}

This creates a lot of mental overhead for adding simply one for value for the bounds that this type can have. If there is a way to do this in gleam already without this, then I would absolutely use that instead.

[lpil]

That example you've given there requires a lot more than the feature you've specified in the first post, rather it would require dependant types.

Dependant types are an active area of computer science research and it is not yet understood how they can be practically utilised in a programming language.

This is an extremely complex area of research and I don't believe we would be able to do anything in this area.