Base Library Restructuring

As more features are being added to the base library, this causes significant clutter and in particular makes documentation hard to navigate.

To resolve this problem, it is proposed to group features from the base library together fit together.

Features that stay

Nonetheless, some features integrated very deeply into Fuzion should remain at the top-level of the base library. This certainly includes:

• Any
• Type
• bool
• choice
• f32
• f64
• i8
• i16
• i32
• i64
• tuple
• u8
• u16
• u32
• u64
• unit
• void
• the features from equals.fz

It might also include these features, which do however also fit into one of the categories listed below:

• Cons
• Function
• String
• conststring
• f128
• i128 (only returns NYI anyway at the moment)
• int
• nil
• some
• u128
• uint

It might seem counterintuitive to move a feature like nil, which is used very often, away from the top level. See the section on moving commonly used features away from the top level, which addresses this problem.

Moving commonly used features away from the top level

Moving some commonly used features such as list into a subfeature has the unfortunate effect of making some easy things longer to write. For example,

some_list_function(x list i32) list String =>
  # the code

would become:

some_list_function(x collections.list i32) collections.list String =>
  # the code, but list is replaced by collections.list.

We do not want this. Since we need a mechanism anyway to load modules other than the base module from Fuzion code anyway, there should be an import or use (or whatever) statement to make available such features without specifying their full qualified name.

As an example, Rust provides a prelude which imports a sensible subset of the standard library by default.

Containers / Collections

This includes the features that provide some kind of data structure to store and retrieve values:

• Linked_List
• Map
• Mutable_Linked_List
• Sequence
• Set
• array
• array2
• array3
• bitset
• ctrie
• float_sequence
• hash_map
• list
• map_of
• mutate.array
• numeric_sequence
• ordered_map
• ps_map
• ps_set
• searchable_list
• searchable_sequence
• set_of
• sorted_array

Or perhaps Sequence and/or array should stay at the top level because they are relatively important?

Three convincing names have been proposed for this category:

• container / containers
• collection / collections
• adt

If one of container or collection is chosen, do we use singular or plural?

C++ does not group features, however this group of classes is referred to by documentation as containers (std::array, std::vector, …). The equivalents in D and Go are likewise named container.

Java, Python, and Rust refer to these as collections.

There does not seem to be another language that uses adt.

This category might get subdivided into even more sub-categories. For example, Python has the collections.abc - Abstract Base Classes for Containers - which provide a basic set of classes to inherit from.

num

This includes the features that relate in some way to numbers, such as:

• complex
• fraction
• matrix

and perhaps the aforementioned:

• int
• uint

and possibly the features that the numeric types inherit from:

• float
• integer
• numeric
• wrapping_integer

It has been proposed to group these into a feature named num. Other possibilities are:

• math (Go, Java & Python)
• numeric (if the old numeric is renamed?)
• number / numbers

type classes

Features like:

• has_hash / hashable
• has_equality / equatable
• has_partial_order
• has_total_order / comparable

seem to be not sorted in most languages (Equatable in Swift, Data.Eq in Haskell among Data.Either and other unrelated stuff). But these can be easily put into a separate feature, because they are used rather rarely (only in the feature declaration, essentially).

Ideas:

• kind
• type_class / typeclass

intrinsics

Intrinsics which are not used in specific features (such as the int type.infix ... ones), so essentially all the intrinsics in lib/fuzion/, should be moved to a separate feature.

Ideas:

• intrinsic / intrinsics