rename std / algorithm to std / algorithms (plural)

[Pietro Peterlongo]

Abstract

the idea is to be able to import std / algorithms to import module that contains algorithms like sort and search.

Motivation

tldr; I always forget, you too?

most of stdlib module are with plurals and it is standard practice in stdlib and nim in general.
indeed this is useful also to be able to use the single name as variable name (e.g. import myobjects; let myobject = initMyObject()).

as far as I can tell algorithm is the only one it is very common to forget the name to import.
you can review for yourself here: https://nim-lang.org/docs/lib.html

Description

of course we should not remove the possibility to import std / algorithm anytime soon.
we could copy content of algorithm.nim in stdlib to new algorithms.nim.

content of algorithm.nim could be replaced with:

import std / algorithms
export algorithms

Code Examples

import std / algorithms

# hey I can use the identifier algorithm!
func algorithm*(input: InputType): OutputType =
  discard # todo

Backwards Compatibility

none that I am aware of (we are essentially adding a new stdlib module, are there subtle differences when exporting stuff?) until we decide to remove the possibility to import std / algorithm. This I think should not happen at least until next breaking version (3.0) preceded by a few versions were importing std / algorithm is appropriately deprecated.

[Andreas Rumpf]

Makes sense.

[Pietro Peterlongo]

I will wait for some time (a few weeks?) in order to receive appropriate feedback, in the meantime some notes on what might need to be changed in a potential PR (happy to pick up the task if this is accepted):

• we could already add deprecation and errors using when (NimMajor, NimMinor): ...
• everywhere where algorithm is used (in Nim code in the repo and in documentation) we should already changed to algorithms
• the change should be documented (starting from version ...) in all appropriate places

The idea should be to minimize effort in the future. In particular if we decide to plan to already throw error on 3.0 the impact would be quite big (a large part of the ecosystem used algorithm). We might decide to keep also algorithm forever (with a deprecation warning from some moment forward) and never remove it or throw error on import (so that we never break old code). Yeah, probably I would go this way.

There are probably other changes, these are some initial thoughts, noting them down so I do not forget.

[Jacek Sieka]

We might decide to keep also algorithm forever (with a deprecation warning from some moment forward) and never remove it or throw error on import (so that we never break old code). Yeah, probably I would go this way.

of all the problems nim has, the name of the algorithm module is not high on the lets-break-things list.. ie who really cares? deprecating it is annoying but it also has other downsides: if you, the library author, follow the deprecation and rename your module and do nothing else, you've broken the use of your library with any older Nim release that does not yet contain the new module and the total amount of "working nim code" out there decreases as a result (specially because of the lax approach to versioning that the community generally takes).

[Zoom]

I say, soft deprecation is fine, but this can easily wait for some bigger structural changes, such as moving some procedures here from other modules. It's better to bundle potential breakage together. If only there were any plans laid out to shuffle around/add things to the stdlib and people could plan ahead...

I almost remember reading someone's opinions that some routine should've been moved to algorithms.

[Yardanico]

@ZoomRmc I bet they were talking about some things in sequtils - most (if not all?) of the procs/templates there actually operate on openArray (so on normal arrays as well), they're not exclusive to sequences.

[ee7]

I guess algorithms is a bit better. But I've never accidentally written algorithms instead of algorithm.

If we accept this RFC, I'd suggest that we decide on the naming scheme and check whether we want to rename other modules while we're here.

From a quick look, if this RFC is accepted, maybe heapqueue should become heapqueues? (If that better matches deques, intsets, lists, ropes, sets, tables, etc).