Concepts for types to separate algorithms from datatypes

[Vindaar]

Concepts as a way to abstract our implementations

NOTE: this may be updated in the future. So far it is mainly a dump of thoughts of myself.

As we have discussed many times now on matrix, there is a serious need for an abstraction of the data types we use in our libraries. Instead of making assumptions about the types in play, be it float, seq[T] or Tensor[T], it'd be ideal to replace these explicit primitives by concepts.

What kind of concepts do we require?

The obvious ones are (names are not final of course):

• TensorLike: A concept that behaves as a tensor, i.e. an object storing a contiguous chunk of data that can be reshaped into arbitrary dimensions at (possibly only) runtime
• MatrixLike (maybe): A concept that matches rank 2 tensors, useful to describe regular linear algebra
• VectorLike: A concept matching 1D data, like a seq[T] or a rank 1 tensor. It allows to define things like linspace, histogram, sequtils procedures etc. for any matching type. A basic proof of concept is implemented in:
  https://github.com/SciNim/scinim/tree/experimentalConceptPlayground
• ScalarLike: A concept matching scalar data, e.g. float, int, ... but also a rank 0 tensor
• FloatLike: A concept matching types that can be converted to floats. For example to match the unchained units in another library without the knowledge of any such units. So in particular matching distinct float types.
• FloatConvertible (optional, if used changes meaning of FloatLike): If we decide to add a FloatConvertible it specifies that FloatLike are only types that can be treated as float without any loss of information. Any algorithm using FloatLike would have to essentially work for floats exactly. FloatConvertible on the other hand would include int and other types that can be converted to float, but using a specific type conversion.
• ? possibly multiple others

Explicit API ideas

/This section will fill more specific ideas of the required API that a type must match for the proposed concepts./

Implementing concepts

The main practical issues implementing specific concepts are two fold:

1. it requires to define a common API of required functionality for each concept. This is easier said than done, as currently many implementations use all sorts of different functionality. We need to scan over many different implementations to figure out which functions are required primitives (e.g. [] for a VectorLike) and which can be already implemented on top of the concepts (e.g. sorted.
2. it requires to go over all code and perform the laborious task of replacing all explicit types by their corresponding concepts. It should be possible to somewhat automate this, but it will remain a boring task.

Open questions & possible issues

There are questions as to what kind of issues we encounter once we attempt to "conceptualize" everything. This includes:

• possible compilation time increases: it's possible that once concepts are used in a big chunk of our libraries, compile times might increase by a significant amount.
• possible compiler errors: it's possible we encounter different compiler errors, missing features of concepts and other fun things. For example, are nested concepts working? VectorLike[FloatLike]?
• concept mismatch errors are harder to understand than regular overload resolution failures.