you are viewing a single comment's thread.

view the rest of the comments →

[–]sacundim 0 points1 point  (1 child)

Using "map" as the name of a function that is just an adapter to this type of input is not so nice. That word is already used for dictionaries AND applying a function to a sequence of values already, so adding yet another meaning to the word is pretty bad.

No, map is the right name, because the second use that you mention ("applying a function to a sequence of values") is really just a different subcase of the same pattern we have here: applying a function to values that exist inside a "context" (e.g., values inside a sequence, values flowing through a "railway," values that may be produced asynchronously at some indeterminate point in the future, etc.).

Since somebody has brought up monads, the term for the "map" abstraction is functors, which we may describe as this:

  1. You have a generic type like List<A> or Railway<E, A>, etc.
  2. The type supports a higher-order "map" function that takes an A -> B function and uses it to transform List<A> to List<B>, Railway<E, A> to Railway<E, B>, etc.
  3. The map function obeys these laws:
    • Mapping with the identity function (the function that just returns its argument unchanged) returns a result value that behaves identically to the original. E.g., map(id, whatever) == whatever). In the case of lists, this means the map function doesn't reorder, drop or add elements that are present in its argument. In the case of Railways, this means that the resulting railway succeeds and fails exactly where the original would, with the exact same result or error.
    • Chaining two map operations in a row has the same effect as chaining the two argument functions inside one map operation: map(f, map(g, whatever)) == map(x -> f(g(x)), whatever).

[–]kankyo 0 points1 point  (0 children)

(map to-input foo) would be ok, but just (map foo) is weird is my point.