Implicit function parameters

[edongashi]

Proposal

The proposed feature allows a function to mark parameters as implicit. An implicit parameter is automatically inserted by the compiler if a valid term for its type is given in callsite scope.

fn join(items: List(a), to_string: implicit fn(a) -> String) -> String {
  items |> list.map(to_string) |> string.join(", ")
}

fn main() {
  given int.to_string

  // Implicit
  [1, 2, 3] |> join() |> io.println()
  
  // Explicit
  [1, 2, 3] |> join(implicit int.to_string) |> io.println()
}

The given/implicit (undecided) keyword should function similar to let, try, const. But unlike those, a name is not required:

implicit Type = <expr>
implicit name: Type = <expr>

A shorthand to implicit Type = <expr> could be implicit <expr> where Type is inferred:

implicit <expr>

A pub modifier exposes the implicit to other modules.

Examples:

// Anonymous
implicit Monoid(Int) = Monoid(
  unit: 0,
  combine: fn(x: Int, y: Int) -> Int { x + y }
)

// Named
pub implicit http_config: HttpConfig = HttpConfig(8080, "docs.scala-lang.org")

// Anonymous + Inferred?
pub implicit HttpConfig(8080, "docs.scala-lang.org")

// Named + Inferred???
pub implicit http_config = HttpConfig(8080, "docs.scala-lang.org")

Exported implicits can be imported from other modules by type:

import lib/config.{implicit HttpConfig, implicit Monoid(Int)}

Importing by name would look like the following:

import lib/config.{http_config}

implicit http_config

Issues to discuss

Naming: implicit/implicit, given/implicit, given/using?

Exporting: Can you expose a given term to other modules (with pub keyword)?

Importing: If exportable, do you import a given by name or by type? Any syntax to import all givens from a module?

Scoping

• Module level / function level / block level?
• Provides match in closest scope?
• Should an implicit parameter be automatically given in the scope? I think not. You would need to re-give locally with given param.

Conflicts/ambiguities

• Will this cause ambiguity with pipe operator? [1, 2, 3] |> join() vs [1, 2, 3] |> join?
• Will this cause issues with optional arguments?
• Should they be last in the params list? What if we have both optional and implicits?
• When passing explicitly, should args be marked as implicit to let the reader know that it's an explicit injection of an implicit param?
• Can an optional arg be implicit?

try syntax: Can the following work? I think it should not.

pub fn main() {
  try implicit db.connect()
}

Import givens syntax: Specific: import lib/config.{given http_config}, All: import lib/config.{given} or import lib/config.{given *}?

Import by type syntax: import lib/config.{given HttpConfig} - expects a given constant with this type. We don't care about its name.

Should re-exporting be possible?

// string_utils.gleam
import gleam/int
import gleam/float

pub given int.to_string
pub given float.to_string

Notes

Based on Scala 3's given/using mechanism.

I think (explicit) importing by type (instead of name) is powerful. Values can be resolved with the equivalent of Scala's summon.

fn take(value: implicit a) { value }

Locally given expressions should be bound to a compiler-generated variable, whereas global given consts will be inlined in callsites.

Obligatory type class example:

type Monoid(a) {
  Monoid(unit: a, combine: fn(a, a) -> a)
}

implicit Monoid(Int) = Monoid(
  unit: 0,
  combine: fn(x: Int, y: Int) -> Int { x + y }
)

implicit Monoid(String) = Monoid(
  unit: "",
  combine: fn(x: String, y: String) -> String { string.append(x, y) }
)

fn sum(items: List(a), monoid_impl: implicit Monoid(a)) {
  list.fold(
    over: items,
    from: monoid_impl.unit,
    with: monoid_impl.combine
  )
}

[lpil]

Thanks for this fab proposal. Implicits in this style seem like a much better fit for Gleam than traits, type classes, and so on. I've been looking mostly at the implicits of Scala 3, which seem quite similar to this proposal.

  // Explicit
  [1, 2, 3] |> join(implicit int.to_string) |> io.println()

Why is it that the keyword implicit is required before the value when passed explicitly?

A shorthand to implicit Type = could be implicit where Type is inferred:

This could be challenging to parse as we would not know if after seeing implicit if we should attempt to parse a type name or an expression. One(two, Three) could be parsed as either, so we could easily parse the wrong thing.

The Gleam parser does not back-track so we cannot rewind and try again if we parse something incorrectly.

Another syntax idea off the top of my head:

implicit get_config(): Config

This is less consistent with let, assert, and try but it would resolve the parsing problem.

We could also use type holes (as currently supported in Gleam's type annotations) to make it more concise:

implicit Config = get_config() // annotate the type
implicit _ = get_config() // type is purely inferred

Should it be permitted to omit the type annotation? I see in Scala 3 it is always required.

I would be keen to hear any other syntax ideas people have.

Naming: implicit/implicit, given/implicit, given/using?

I prefer implicit. Is there a reason to have two keywords? I cannot think of any at present.

Importing: If exportable, do you import a given by name or by type?

A great question!

I'm leaning towards values only being implicit within the module they are defined in, and to make a value implicit in another module you must mark them as so when importing them.

Module level / function level / block level?

Block scope sounds good, with module level implicit values using an implicit statement outside a function.

Will this cause ambiguity with pipe operator? [1, 2, 3] |> join() vs [1, 2, 3] |> join?

I think this will be OK.

Will this cause issues with optional arguments?
Should they be last in the params list? What if we have both optional and implicits?

Possibly. We need to consider how it would work with optional arguments and labelled arguments too.

When passing explicitly, should args be marked as implicit to let the reader know that it's an explicit injection of an implicit param?

What advantages of this might there be beyond a sort of in-code documentation?

Resolving implicits for values of unknown type

At times it may not be possible to infer at the point of use what instance is required with how Gleam types code top to bottom, left to right.

Consider this code.

import gleam/int
import gleam/float

implicit int.to_string
implicit float.to_string

fn stringify(x: a, to_string: implicit fn(a) -> String) {
  to_string(x)
}

pub fn run(x) {
  // the type of x is not annotated, we don't know what it is

  // As we don't know what x's type is we don't know which implicit to use
  let s = stringify(x)

  // x has been used as an int, so it must be an int.
  x + 1
}

Should this code successfully compile? If so we may need to defer resolving instances until after the function has been type checked.

If that is the case consider this code where the implicit is declared after the usage.

import gleam/int

fn stringify(x: a, to_string: implicit fn(a) -> String) {
  to_string(x)
}

pub fn run(x) {
  let s = stringify(x)

  implicit int.to_string

  x + 1
}

Should this compile? I think not.

We must be careful to only take into account implicit values that are in scope at the point of use.

Resolving implicits when there are generic options

Consider this code:

implicit fn(a) -> String = anything_to_string
implicit fn(Int) -> String = int.to_string

fn stringify(x: a, to_string: implicit fn(a) -> String) {
  to_string(x)
}

pub fn main() {
  stringify(123)
}

Should the fn(Int) -> String implicit or the fn(a) -> String implicit be used here? I suspect the Int one.

What about an instance in which we are picking between Map(k, String) and Map(String, v)? They have the same number of type variables.

Should there be some constraint on how type variables can be used?

How would we efficiently implement this type lookup from the scope? Currently we implement type and values scopes using HashMaps so access is O(1), but that won't work for these type partial matches.

[lpil]

Wow, this is really interesting! Thanks gang.

A boring practical consideration: Types can be very long and quite tedious to write compared to variable names. i.e. fn(String) -> Result(a, ParseError). Having to write the in your code could be quite irritating and verbose.

pub fn main(a, b, impl, impl) {
  try parsed_a = ?fn(String) -> Result(a, ParseError)(a)
  try parsed_b = ?fn(String) -> Result(b, ParseError)(b)
  todo
}

In your example @timjs you've defined a record to contain the desired functions so the usage is just ?Eq(a). This looks quite nice, but does require the boilerplate of the record definition up-front.

It may be that this boilerplate is desirable- to discourage over-use of implicit values. Or to formalise abstractions in a similar way to type-class/trait definitions.

It allows for full type reconstruction. Writing the expression ?Display(a) signifies that there should be an implicit parameter with that type. For example, we wouldn't be able to infer the type of the following function: ...

We could if the type annotation was required for implicits, which would also resolve the naming problem above.

fn lt(x, y, impl ord: Ord(a)) {
  case ord.cmp(x, y) {..}
}

I do not know if this is better or not.

explicit passing of implicit values should not be possible;

I am very interested in this one @timjs ! Why should this not be permitted?

I've worked out some examples on this page, containing:

Could you explain the problem shown in the "Need rules" section? I'm afraid I don't understand it.

[lpil]

Some more thoughts on referring to implicits by their type.

Parser ambiguities

fn main(x, impl) {
  ?Something(x)
}

How do we know if this is the type Something being dereferenced and then called as a function, or if it the type Something(x) being dereferenced and then returned? In the parser we have no type information so we cannot determine if Something is a type constructor.

Accidental function signature changes

fn main(a, b, impl, impl) {
  let x = ?X(a)
  let y = ?Y(b)
  todo
}

If the ordering of the definition of x or y change the function signature changes.
This would most the time not be an issue for Gleam callers but it would be more so for Erlang, Elixir, JavaScript etc callers of Gleam code.

It would be good to not be brittle towards accidental changes and mistakes.

[timjs]

First one is a difficult one indeed. The syntax I used is mostly based on a combination of the syntax used in articles and the highlighting provided by GitHub for readability. Some options:

• Extra parens: ?(T(a))(x)
• Keyword: use(T(a))(x)
• Use [] for type params instead of (): ?T[a](x)

The second one is also unfortunate. If this is something we really like to avoid, requiring explicit type annotations for implicits is the only way I think.

[timjs]

Sorry, missed your other post

In your example @timjs you've defined a record to contain the desired functions so the usage is just ?Eq(a). This looks quite nice, but does require the boilerplate of the record definition up-front.

Indeed. Type aliasing a function type works equally well, it doesn't need to be a record. Only if you'd like to do more advanced things like type class hierarchies.

We could if the type annotation was required for implicits, which would also resolve the naming problem above.

Yes, this would also solve the problem of double implicits you mention in your other post.

I am very interested in this one @timjs ! Why should this not be permitted?

Looking up implicits by type is not only more puristic, but keeps mentally a distinction between explicit and implicit parameters for a programmer. Naming implicit parameters and allowing to explicitly pass implicits mixes both styles of programming making it harder to read and understand. But that's my personal impression and gut feeling.

Explicit passing of implicits is more like syntax sugar:

// Taking the modulo example
fn main() {
  add(3, 5, use Modulo(4))
  // is essentially sugar for
  use Modulo(4)
  add(3, 5)
}

The second way of writing is more faithful to the idea of implicit arguments and doesn't introduce new ways of doing the same thing (in style of Python's Zen).

Could you explain the problem shown in the "Need rules" section? I'm afraid I don't understand it.

I'll open a new discussion below.

[lpil]

Thank you Tim!

My gut feels that being able to pass implicits explicitly would be a good thing for Gleam. It has some symmetry with labelled arguments where they can be given positionally, and it would need to be the case when using Gleam from Erlang or Elixir. I could be wrong though.

RE syntax, this parser issue is a pain- I was quite coming around to the idea of referring to them by type.

[] would be ambiguous with lists.
<> is another common option but it seems like it would be ambiguous with <, >, << and >>. Other languages have these though, so perhaps there is something I am missing here.

[edongashi]

Thanks for the feedback! I'll answer section by section because this will become a lengthy discussion and I don't have time to write everything at once.

Resolving implicits when there are generic options

Consider this code:

implicit fn(a) -> String = anything_to_string
implicit fn(Int) -> String = int.to_string

fn stringify(x: a, to_string: implicit fn(a) -> String) {
  to_string(x)
}

pub fn main() {
  stringify(123)
}

We had a discussion where we concluded that a lambda instance cannot be type-parametric in Gleam (aka higher rank polymorphism), meaning you cannot pass an "open type" function/struct around. Imagine we wrapped fn(a) -> String = anything_to_string in a struct instance and you will see that it's not possible for a single record to quantify forall a. An implicit should act like a let binding, not a macro, even if that's the case for constants.

In other words, in Gleam we cannot have the following bindings:

fn do_something(id: fn(a) -> a) {
  let x = id(123)
  let y = id("abc")
}

fn do_something2() {
  let id = fn(x: a) -> a { x }
  let x = id(123)
  let y = id("abc")
}

If the id value is monomorphic then so should be an implicitly declared/passed value. In global scope there can't be an open a type. For a local a we will discuss later.

What about an instance in which we are picking between Map(k, String) and Map(String, v)? They have the same number of type variables.

This is a tough one!

fn pick_element(key: k, dict: implicit Map(k, v)) -> v {
  dict |> map.get(key)
}

fn main() {
  implicit Map(String, Int) = ...
  implicit Map(String, Float) = ...
  implicit Map(Int, Float) = ...

  let x: Int = pick_element("abc") // ok, all type params known
  let y = pick_element("abc") // error, v unknown
  let z = pick_element(25) // Theoretically can resolve, but I think this should be a compile error?
}

Should there be some constraint on how type variables can be used?

Maybe we need some restrictions to avoid situations like above... I think a rule such as: a generic type cannot be determined by implicitly passed params. All open types must be determined by other parameters or by expected return type.

How would we efficiently implement this type lookup from the scope?

I am way too underqualified to answer this question😆

[lpil]

That's a great point about type variables there! I feel like I have a lot more thinking to do about how type variables could work here.

fn pick_element(key: k, dict: implicit Map(k, v)) -> v {
  dict |> map.get(key)
}

fn main() {
  implicit Map(String, Int) = ...
  implicit Map(String, Float) = ...
  implicit Map(Int, Float) = ...

  let x: Int = pick_element("abc") // ok, all type params known
  let y = pick_element("abc") // error, v unknown
  let z = pick_element(25) // Theoretically can resolve, but I think this should be a compile error?
}

x in this example is interesting as it shows how the type information comes from an annotation on the let assignment, which is something we currently check after type inference of the value being assigned.

Maybe we need some restrictions to avoid situations like above... I think a rule such as: a generic type cannot be determined by implicitly passed params. All open types must be determined by other parameters or by expected return type.

That might be it, though I wonder if it could be too restrictive. I feel there are lots of edge cases to consider here!

[lpil]

This other issue has some prior discussion #1244

[timjs]

Some more general thoughts about implicit parameters when comparing them to other solutions in the design space.

Implicit parameters have the same power as multi-parameter type classes, with two distinctions:

1. they ask developers to explicitly import instances (or givens);
2. there is no global uniqueness of instances.

Both can be a blessing or can be a chore. This brings us back to the question what to what purpose we'd like to implement implicts into Gleam. What problem do we like to solve?

Implicits solve two problems: configuration depending on context, and overloading off function names.

Configuration problem

The configuration problem is best illustrated by this example, which calculates a result depending on the implicit value of Modulo:

type Modulo { Modulo(k: Int) };

fn add(a: Int, b: Int, impl: Modulo) {
  a + b % ?Modulo.k
}

fn mul(a, b, impl) {
  a * b % ?Modulo.k
}

fn test(a, b, impl) {
  add(mul(a, a), mul(b, b))
}

fn main() {
  use Modulo(4)
  print(test(2, 3))  // Implicitly pass `Modulo(4)` as argument

  use Modulo(5)
  print(test(2, 3))  // Implicitly pass `Modulo(5)` as argument
}

Implicit parameters are a neat solution to pass on configuration data, without mentioning it over and over again. Haskell/PureScript solve this using a Reader monad, which is not an option for Gleam atm. Is this a problem we'd like to solve?

Overloading

Using implicits, we can implement overloading of function names. We can create functions which are polymorphic only over a subset of types, for example which implement equality, or addition and multiplication:

mod eq {
  type Eq(a) { Eq(eq: fn(a, a) -> Bool) }
  fn ==(x: a, y: a, impl: Eq(a)) {
    ?Eq(a).eq(x, y)
  }
  fn /=(x: a, y: a, impl: Eq(a)) {
    not(eq(x, y))
  }
}

Then in another module:

mod list {
  import eq.{Eq}
  fn unique(xs: List(a), impl: Eq(a)) -> List(a) {..}
  fn has_prefix(xs: List(a), impl: Eq(a)) -> Bool {..}
  fn elem(xs: List(a), y: a, impl: Eq(a)} -> Bool {..}
  fn lookup(xs: List(#(a,b)), y: a, impl: Eq(a)) -> b {..}
  // ...etc
}

Do we want to create functions with implicits like described above? When doing this, implicit parameters would be all over the place. Letting users explicitly import givens would become unwieldy quickly and is maybe not that user friendly, especially for developers.

On the other hand, I know Erlang has build-in equality for all types. Is it a goal of Gleam to use that? In that case, implicits would be far less common, and this problem would not arise that often.

Global uniqueness

Next, global uniqueness. The reason Haskell and Rust have type classes and traits, is the "Hashmap problem" or "Set problem". Take the following (hypothetical) Gleam code (translated from this blog post on global uniqueness in Haskell).

mod gleam/set {
  type Ord(a) = fn(a, a) -> Ordering;
  // Insertion needs an ordering
  fn insert(into set: Set(a), this member: a, impl: Ord(a)) -> Set(a) {..}
}

mod test/definition {
  type T {
    X
    Y
  };
}

mod test/usage1 {
  import gleam/set
  import test/definition
  
  fn cmp1(a, b) {
    case a, b {
      X, X -> EQ
      X, Y -> LT
      Y, X -> GT
      Y, Y -> EQ
    }
  }
  use cmp1
  
  fn ins1(set, member) {
    set.insert(set, member) // uses cmp1
  }
}

mod test/usage2 {
  import gleam/set
  import test/definition
  
  fn cmp2(a, b) {
    case a, b {
      X, X -> EQ
      X, Y -> GT // Different!
      Y, X -> LT // Different!
      Y, Y -> EQ
    }
  }
  use cmp2
  
  fn ins2(set, member) {
    set.insert(set, member) // uses cmp2
  }
}

mod test/main {
  import gleam/set
  import test/definition
  import test/usage1
  import test/usage2
  
  fn main() {
    let test_same = set.empty() |> ins1(X) |> ins1(Y) |> ins1(X)
    let test_diff = set.empty() |> ins2(X) |> ins1(Y) |> ins1(X)
  
    print(set.to_list(test_same)) // OK: prints [X,Y]
    print(set.to_list(test_diff)) // ERROR: prints [X,Y,X]!!!
  }
}

The module set needs an ordering, and usage1 and usage2 both define a different way of ordering type T, and they both implement their own ins function to insert an ordered type into a set. Using both modules create strange behaviour!

Scala doesn't run into this problem, because every object has its own equals and compare function, which can only be overridden once in an application (if I understand it correctly). Haskell/PureScript/Rust need global uniqueness of instances to ensure above behaviour will never happen. Is this something we'd like to take care off?

Summarising

So, when compared to multi-parameter type classes (or traits), implicits give us the power to manually control the scope of implicits, but we as developers need to be explicit about when they are in scope and when they are imported. Also, they won't give us global uniqueness of implicits/instances/implementations. But the question is: what do we like for Gleam and why?

[edongashi]

fn inline_example() -> String {
  let local_id = fn(x: a) -> a { x } // This is a function that can handle _any_ `a`

  let x = local_id(123) // `a` is instantiated here to be `Int`
  let y = local_id("Hallo") // `a` is instantiated here to be `String`
}

Is this valid gleam? I don't think this will compile.

I don't understand your question here. Can you elaborate? Or does above example help?

In my connect_to_database example the implicit binding performs a side effect. If the compiler plugs in connect_to_database() twice then you get 2 connections to the database without the user's knowledge. That is not an ideal solution to the configuration problem.

[timjs]

Is this valid gleam? I don't think this will compile.

Yes it is, please try it out.

In my connect_to_database example the implicit binding performs a side effect. If the compiler plugs in connect_to_database() twice then you get 2 connections to the database without the user's knowledge. That is not an ideal solution to the configuration problem.

Ah I see, didn't think about that and was thinking in terms of common subexpression elimination.

In light of side effects, I think it depends on the type of connect_to_database(). If the call results in some type DatabaseConnection, I'd say you get just one connection which you implicitly pass to both query functions. If it results in a function, and query requires a function, then query will connect to the database twice. All in all, (b) should be the correct translation.

[edongashi]

Yes it is, please try it out.

You're right, it works! I thought that due to the higher rank limitation you couldn't have an open lambda value.
What is interesting is that even a struct wrapper is allowed to be generic!

let wrapper = IdWrapper(fn(x: a) -> a { x })

wrapper.id(123)
wrapper.id("abc")

However, reassigning does not work:

let local_id = fn(x: a) -> a { x }
let id2 = local_id

id2(123)
id2("abc") // does not work

[lpil]

Lots of great stuff here! Thank you. I really enjoyed reading this thread

Do we want to create functions with implicits like described above? When doing this, implicit parameters would be all over the place. Letting users explicitly import givens would become unwieldy quickly and is maybe not that user friendly, especially for developers.

I'm not yet convinced that proliferation of implicit arguments for data structure manipulating functions would be a good thing for Gleam. There is an increase in cognitive load and a decrease in the quality of error messages when the main advantage is being able to write enum.map rather than list.map. I think there is more value in solving the configuration problem.

Because of this I would be comfortable with declaring implicit values to be a bit boilerplate-y.

On the other hand, I know Erlang has build-in equality for all types. Is it a goal of Gleam to use that? In that case, implicits would be far less common, and this problem would not arise that often.

That is the goal. We have comparison of all types but not ordering.

The module set needs an ordering, and usage1 and usage2 both define a different way of ordering type T, and they both implement their own ins function to insert an ordered type into a set. Using both modules create strange behaviour!

Scala doesn't run into this problem, because every object has its own equals and compare function, which can only be overridden once in an application (if I understand it correctly). Haskell/PureScript/Rust need global uniqueness of instances to ensure above behaviour will never happen. Is this something we'd like to take care off?

This is very interesting! I do not know what would be ideal for Gleam here but I currently do have a preference for locally imported implicit values rather than globally unique ones.

Isn't a reason to add ad-hoc polymorphism to Gleam to merge the + and +. for ints and floats?

I'm not very into overloading of operators by users as it can be challenging for newcomers to search online to learn what is happening in unfamiliar code. An overloaded add function may be preferable.

These opinions are largely a mix of gut feelings and attempting to think about what impact these decisions would make on the experience of writing Gleam. I do not have much knowledge on the technical aspects of implicits, do not take any opinions as unmovable facts. Thanks

[timjs]

Lots of great stuff here! Thank you. I really enjoyed reading this thread

:-D

I'm not yet convinced that proliferation of implicit arguments for data structure manipulating functions would be a good thing for Gleam. There is an increase in cognitive load and a decrease in the quality of error messages when the main advantage is being able to write enum.map rather than list.map. I think there is more value in solving the configuration problem.

Yes, I agree with you about list.map vs enum.map. Most of the time this could be solved using iter as intermediate data (see F#'s seq for example), and + vs +. solves the same problem on numbers.

However, there is more to it then enum or fold like types. The examples I gave somewhere on lists all need equality:

mod list {
  import eq.{Eq}
  fn unique(xs: List(a), impl: Eq(a)) -> List(a) {..}
  fn has_prefix(xs: List(a), impl: Eq(a)) -> Bool {..}
  fn elem(xs: List(a), y: a, impl: Eq(a)} -> Bool {..}
  fn lookup(xs: List(#(a,b)), y: a, impl: Eq(a)) -> b {..}
  // ...etc
}

So abstracting over equality is very pervasive throughout the whole api. Off course we are currently blessed by Erlang that equality comes built-in, so overloading equality is not a big issue at first sight. However... polymorphic equality can lead to some strange behaviour from the developer's perspective, as we currently already see in the gleam/queue module, which has a is_equal function. This means that list.unique as currently defined in gleam/list does not work properly on equivalent queues with different internal representations (runnable Gleam code):

pub fn main(args) {
  let q1 = queue.new() |> queue.push_back(42)
  let q2 = queue.new() |> queue.push_front(42)
  let l = [q1, q2] |> list.unique()

  debug(queue.is_equal(q1, q2)) // => true
  debug(q1 == q2) // => false
  debug(l) // => [{queue,[42],[]},{queue,[],[42]}]
}

So overloading in style of Haskell/PureScript/Rust/Swift takes away these kind of errors and allows us to write robust and correct code.

One can introduce special equality type variables, like Standard ML does, and require that opaque types cannot be compared using polymorphic equality. But this technique has it own plusses and minuses (see polymorphic equality on page 18 of Appel (1992)). It is in some way a "type classes light" approach, which quickly grows into a desire to have more such special type variables, e.g. for ordering. Elm does something like this with its comparable and number "built-in type classes".

That is the goal. We have comparison of all types but not ordering.

Why only equality and not ordering? Erlang provides both doesn't it? And for every data type you can define in Gleam you can derive ordering if you like, because all types are inductive. Although this is still strange for functions, but how Erlang compares functions for equality is also not entirely clear for me, as this is in general undecidable. So if someone can explain that to me, I'd be grateful.

There is an increase in cognitive load and a decrease in the quality of error messages [..]

PS I'm concerned implicits aid to this as well, as they allow for many different ways of usage.

[timjs]

Then, another consequence of implicits: the order of top level declarations matter, including imports!

Currently, Gleam is a declarative language on the top level: it doesn't matter in which order you define your functions, and in which order you import functions or types from other modules. When introducing implicits, order does matter. For example, moving a function definition can change its meaning, as below example shows with different placements (f, g, and h) for the same function body:

fn f() {
  println(?Int) // => ERROR: no implicit of type `Int` in scope
}

use 42

fn g() {
  println(?Int) // => Will use "42"
}

use 37

fn h() {
  println(?Int) // => Will use "37"
}

fn main() {
  f()
  g() // => prints "42"
  h() // => prints "37"
}

The same holds for importing givens from different modules, swapping the order of imports changes the meaning of the program.

import a.{given Int}
import b.{given Int}

fn f() {
  println(?Int) // => Will use `b`'s int
}

Maybe it doesn't matter at first sight, but it can be confusing. Also, tooling which auto sorts imports are not an option any more.

This boils down to the question: do we intend Gleam to be declarative on the top level or not? Rust, Haskell, Elm, PureScript are, OCaml, F#, Scale aren't.

[timjs]

I think that disallowing multiple implicits of the same type in function bodies defeats the purpose of having implicits at all. You're not allowed to abstract over the context any more, taking away the one additional feature of implicits over multi-parameter type classes. For example, the configuration problem described above would not be expressible any more:

fn main() {
  use Modulo(4)
  print(test(2, 3)) 

  use Modulo(5) // ILLEGAL
  print(test(2, 3))
}

as bringing Modulo(5) into scope would not be legal any more.

[lpil]

however, a strange separation that you can bring multiple implicits into scope in a function body, but that the compiler checks for implicits of the same type at the top level?

I think there is some precedence of this in Gleam. In functions ordering of statements (er- expressions) matter and name rebinding is permitted. In modules ordering of statements is (mostly) unimportant and name rebinding is not permitted.

[edongashi]

I think this is an argument for assignment style implicits: implicit Modulo = Modulo(4) because of the familiarity of users with assignment semantics. implicit db_connect() may be misinterpreted, whereas implicit Connection = db_connect() is quite clear that the expression is being evaluated and bound at this point in time and may be re-bound at a later point.

I don't consider the type-hole syntax a problem. We require names for let bindings, so it's natural to require types for implicit bindings.

[timjs]

I think there is some precedence of this in Gleam. In functions ordering of statements (er- expressions) matter and name rebinding is permitted. In modules ordering of statements is (mostly) unimportant and name rebinding is not permitted.

Yes that's true! Maybe not such a big problem as I thought.

[timjs]

I think this is an argument for assignment style implicits: implicit Modulo = Modulo(4) because of the familiarity of users with assignment semantics. implicit db_connect() may be misinterpreted, whereas implicit Connection = db_connect() is quite clear that the expression is being evaluated and bound at this point in time and may be re-bound at a later point.

Yes that sounds nice, especially the evaluation part. On the other hand, this syntax signals you can "assign something to a type", doesn't it? That's very strange for me.

[timjs]

Another thing to think about when adding implicits to the language, is rules, or when to abstract over implicits and when to fill them.

As always, this is best illustrated with an example. Say we already have some way to do equality with a type Eq(a) which, for simplicity in this example, is just an alias to the needed function type. Now lets look at declaring a Pair type and its equality function:

type Eq(a) = fn(a, a) -> Bool;

type Pair(a, b) {
  Pair(a, b) // Just a pair of `a` and `b`
};

// `equals` takes two pairs of the same type
// We need two implicit arguments to equate both components:
// one of type `a` and one of type `b`
fn equals(x: Pair(a, b), y: Pair(a, b), impl: Eq(a), impl: Eq(b)) -> Bool {
  match x, y {
    Pair(x1, x2), Pair(y1, y2) ->
      eq.eq(x1, y1) && eq.eq(x2, y2)
    // needs Eq(a)      needs Eq(b)
  }
}

Now, let us try to bring equals for Pair(a, b) into the implicit scope:

use equals // ERROR: no givens for `Eq(a)` and `Eq(b) in scope

This won't work, as equals needs two implicits, one of type Eq(a) and one of type Eq(b)` which are not in scope.

We need to abstract over its implicits when bringing equals into scope. Thus we need something like:

use equals if Eq(a), Eq(b)

Which says: "if there is equality for a and equality for b in scope, I can give you an equals functions which equates Pairs"

This is comparable to a type class instance in Haskell/PureScript (and also a trait implementation in Rust):

instance (Eq a, Eq b) => Eq (Pair a b) where ...

So in the end you still need some kind of constraints or rules (as sometimes called in literature) to use implicits.

[JoelVerm]

Hey everyone, I know this discussion is quite old now, but I would really enjoy a basic version of this idea!'
Sadly I'm both too bad at gleam and compilers to understand most of what y'all wrote above, so if you do have some spare time, would the following be possible to implement?

import gleam/int
import gleam/float
import gleam/list
import gleam/string
import gleam/io

pub fn stringify(a: a, f: implicit fn(a) -> String) -> String {
  f(a)
}

pub fn join(vals: List(a), sep: String) -> String {
  given int.to_string
  given float.to_string
  given fn(a: String) { a }
  list.map(vals, stringify) |> string.join(sep)
}

pub fn main() {
    join([1, 2, 3], ", ") |> io.println
    join([1.0, 2.0, 3.0], ", ") |> io.println
}

given would then only be allowed inside of functions, and implicit only as parameter. Also no multiple given for the same type (eg. fn(Int) -> String) would be allowed, and given must come before any calls to functions using implicit.

When a function is called without a given for the supplied type, the compiler would give an error. I don't know what the type hint for join would look like, because a could only be Int, Float or String.

I've probably repeated/skipped a lot of stuff you have already talked about, but I didn't understand all of it, and I would really like something like this in the language if possible. Feel free to ignore me, roast me, or anything else 😅 but if you could look into this again if only a really simplified version, I would really appreciate it!

[lpil]

Hello! Yes, you could implement that in a Gleam similar to Gleam.

One thing that would make it highly restrictive and not very intuitive with Gleam is that there are multiple types with the same runtime representation. The consequence of this is that in the join function you could only have given functions for types that can be identified at runtime, which is not many.

[JoelVerm]

Can't you compile that away? Like generic functions already kinda do?
The first join would then use int.to_string, the second one float?

[lpil]

How would you do that given two types that are identical at runtime? What code would you generate?

[JoelVerm]

Oh yeah I understand now... The compile destination language couldn't know the right function of course. I didn't think about that earlier, im sorry for opening this discussion again 🥲