Allowing type variables in local values

[joshi-monster]

Hello!

I'm sorry, but I'm still confused; this might also belong in questions 🙂

So from what I could figure out from probing the compiler, the following is true:

// top-level constants and functions automatically infer the most general type
const constant_list  = [] // : List(a)
fn fn_list() { [] } // : fn() -> List(a)

pub fn main() {
  // let bindings by default specialise to the type of their first usage,
  // even if a more general type would be possible
  let list = [] // : List(String) 
  string.join(list, " ")

  let id = fn(a) { a } // : fn(Int) -> Int
  list.map([1,2,3], id)

  // for functions, it is possible to force them to be more general by explicitly annotating them:
  let id = fn(a: b) -> b { a }
  list.map([1, 2, 3], id)
  list.map(["wibble", "wobble"], id)

  // for values, it allows you to introduce a new type variable, but wont unify it with anything:
  let list: List(c) = []
  string.join(list, " ") // type mismatch: Expected type: List(String) Found Type: List(c) 

  // you can refer this type variable again, making a function that behaves like that;
  // this is not true for other type variables which can be reused.
  let id = fn(a: c) -> c { a }
  list.map([1, 2, 3], id) // type mismatch: Expected type: fn(Int) -> a Found type: fn(c) -> c
}

Is this the intended semantics?

If it is:

I think allowing the introduction of new type variables in (non-function) values like that is mostly useless and should produce a warning/error immediately, instead of more confusing type errors further down. Since everywhere else in the language a value of type List(a) can be used in places where i.e. a List(Int) would be expected, an error saying the types here dont match was not very clear to me at first.

It also allows you to accidentally change the type of local functions like in the last example, leading to some really confusing type errors; why was fn(Int) -> a expected here?

Unfortunately I think making this an error would be a breaking change.

If it isn't:

Personally I would prefer allowing generic local bindings as well, with the only difference being that you need to annotate them locally, similarly to functions. Those should also like local functions introduce a new scope for their type variables, to avoid problems like the last example. This would remove those edge cases, making local (non-function) values behave exactly the same as all other values or functions in the language.

---

Also sorry again for not knowing all the right language dev terms; I hope what I mean is somewhat understandable. I only know so much from looking at Haskell from a very safe distance for a long time 😄

~ 💜

[lpil]

I believe there's issue for not making generic type variables in let annotations rigid, but for the life of me I can't find it now.