Architecture for overriding "trait" implementations many times in different contexts?

Question

I just asked this question about Rust: Is it possible to create a default trait implementation in Rust, and then override that trait implementation somewhere else? My problem is, in my custom lang, I want to define a default implementation for printing error messages to the terminal. What I hate the most about JS/Node.js is the error message printing is terrible, so I would like to override all error messages and reformat it. Likewise in my language, I wanted to have the ability to override how error messages are displayed. And other things will use this pattern, but this is just top-of-mind.

The question is, how can I:

1. Define the default implementation of stringifying?
2. Allow overriding (possibly multiple times) of the stringification?

By multiple times, I mean a library might define some errors and renderings for them. Then another library might override that. Then an application might override that, so 3 layers of definitions, the last one which will take precedence (and all internal/external error messages will use that final formatter).

How can I do this in a statically typed sort of way? It appears Rust doesn't allow you to override trait implementations (for some reason I'm unaware of, waiting to hear about that!). Could you theoretically just add that feature to Rust without consequences? What about other languages, what is a good example how another language solves this problem?

In some ways it's kind of like dependency injection, but not 100% sure about that.

Answer 1

Scala uses the given system for a superset of what Rust traits do. For example, this Rust (pseudo-)code

trait Show {
  fn show(&self) -> String;
}

impl Show for String {
  fn show(&self) -> String {
    format!("\"{}\"", self)
  }
}

fn show(x: &impl Show) {
  x.show()
}

converts to this Scala code:

trait Show[+A]:
  def show(a: A): String

given Show[String] where
  def show(str: String) = s"\"$str\""

def show[A](a: A)(using sh: Show[A]) = sh(a)

The important difference is that givens act as variables - that is, they can be scoped.

def foo() =
  given Show[String] where
    def show(str: String) = s"[${str.length}]$str"
  println(show("hi"))

println(show("hi")) // outputs "hi"
foo() // outputs [2]hi

Multiple libraries can export givens of the same type and you can choose which to use when you import them:

import lib.{given Show[String]}
println(show("hi")) // calls the library's implementation

And of course, you can mix the two things and use imports inside a block to override the default given

import bar.{given Show[String]}
def q() =
  import foo.{given Show[String]}
  println(show("hi"))
println(show("hi"))
q()

You can also decide to explicitly pass an instance to a function without having it as a given:

object A extends Show[String]:
  def show(str: String) = s"$str from A"
object B extends Show[String]:
  def show(str: String) = s"$str from B"
given Show[String] = A
println(show("hi")) // hi from A
println(show("hi")(using B)) // hi from B

All these features combined can make Scala givens much more powerful than Rust-style traits or traditional Haskell-like typeclasses, if used correctly.

Answer 2

Your traits calls library code

By multiple times, I mean a library might define some errors and renderings for them. Then another library might override that. Then an application might override that, so 3 layers of definitions, the last one which will take precedence (and all internal/external error messages will use that final formatter).

In existing languages, this level of configuration is possible if the default implementation is published in a public vtable, and default trait implementations calls into these vtables, that in turn are initially filled with the default implementation. Any library or user code can, then, change that. It's only a form of dependency pointer injection, as noted.

impl in Rust, is more in direction of dependency code injection, in comptime no less. After the code is compiled, there is only functionality, no extension points.

Aspect-oriented programming

So if you want both, your language will need some form of virtual trait that accepts a default implementation, so that any library or user code can modify latter. If these 3 layers of (re)definitions are to occur at comptime, then your language will need some syntax to declare some aspect syntax rewriting rules.

You will note, in above Wikipedia link, that logging is a prime case in aspect-oriented programming.