rename std / algorithm to std / algorithms (plural)

[pietroppeter]

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.

[Araq]

Makes sense.

[pietroppeter]

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.

[arnetheduck]

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).

[ZoomRmc]

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.

[ghost]

@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).

[zerothi]

This seems to be accepted by lots of people? Could this be marked as accepted?

Or should it be extended based on https://github.com/nim-lang/RFCs/issues/533#issuecomment-1715700134, which is quite valid!

[Araq]

Meh, pointless friction. Instead move the single valuable thing of algorithm to its own module sorts or sortings or sorters.

[metagn]

IMO fill/product/maybe reverse/rotate should be in sequtils, the rest should be in a module std/sort or std/ordering. import algorithms is not much better than import algorithm

[zerothi]

I am more concerned on the naming convention, people will frequently mistype since some modules has plural s, while others don't. I don't mind either, as long as it is consistent.

[Araq]

We have no data whatsoever on how many people mistype "algorithm".

[zerothi]

I'll just have to re-iterate that consistency is really key for new users. While one can get used to certain naming conventions, I think the predictability of what names to expect outweighs anything.

[Araq]

You can iterate it as often as you want, that doesn't make it true. Lisp is vastly more consistent than any other syntax out there, look how many care.

[metagn]

I think the naming convention is good but "algorithms" is so vague it loops back around to making no sense for the module. At the risk of sounding repetitive a more precise name is probably better.

[Zectbumo]

I would like to propose renaming to std/sorting Example use: "that is found in the sorting module"

[juancarlospaco]

std/algos ? 🤔

[pietroppeter]

Thanks everyone for the feedback, summing up how I see it:

• I think consistency in naming is nice for new users
• if we were to do this I would now go with a soft deprecation (and align also heapqueues), so that would mean no breaking ever, just a deprecation warning
• but maybe the trade-off with the friction it would generate (a warning is still friction) it does not make it worth it (not sure about it)
• and it might make more sense to split the content of algorithms in other modules (one does not exclude the others though)

so the summary is that although I think this could still be overall a net positive, I am not so sure it is worth the effort. and to be honest at the moment I definitely have no plans to commit time to this, so if someone cares enough, they can pick it up (or it can be closed).

have a good day