Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List Module Inconsistancy :: "map"+"mapi" "iter"+"iteri" "rev_map"... but no "rev_mapi" #7283

Closed
vicuna opened this issue Jul 5, 2016 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Jul 5, 2016

Original bug ID: 7283
Reporter: tormen
Status: acknowledged (set by @damiendoligez on 2017-04-14T14:39:49Z)
Resolution: open
Priority: normal
Severity: feature
Category: standard library
Monitored by: @ygrek @hcarty

Bug description

In module List there is "map"+"mapi" "iter"+"iteri"
"rev_map"... but no "rev_mapi" :(
Any particular reason ?

IMHO this seems like a inconsistency.
There should be either have map + mapi AND rev_map + rev_mapi OR map + rev_map.

I opt for the former (and pledge to add rev_mapi) :)

@vicuna
Copy link
Author

vicuna commented Jul 5, 2016

Comment author: @alainfrisch

FWIW, other iterators are missing the "i" variant as well: fold_left, fold_right, iter2, map2, fold_left2, fold_right2, rev_map2, but also for_all, exists, for_all2, exists2, find, filter, find_all, partition.

@vicuna
Copy link
Author

vicuna commented Jul 5, 2016

Comment author: @paurkedal

rev_map is just an optimisation of rev o map, so I see it as a pragmatic addition driven by need more than consistency. If we mark out optimisations, then we can worry about consistency for the remainder of the interface.

That said, folds don't need indexed variants, since one can just pass a counter in the accumulator. If we could also argue that indices are less useful in predicates (my guess), then we would be left with rev_mapi and rev_map2i as candidates for inclusion.

@github-actions
Copy link

github-actions bot commented May 9, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant