Making Map Operations Implicit in Programming

This is an 'ancient' idea pre-dating the recent functional craze: array programming, it is so well known that it has a substantial wikipedia page:

http://en.wikipedia.org/wiki/Array_programming

its also important to note that this is syntactic sugar - and like most kinds of syntactic sugar it can make code confusing to read, in order to make it prettier. being explicit is often a very good thing for readability and for compilers (they must also read your code) - i value it highly.

although there is something nice about being able to add two arrays together and it do 'what i would expect'... but what do i expect if the arrays do not match in size? how much more thinking do i need to do over being explicit?

This is a standard feature of many languages or libraries, and generally known as array programming – something APL is known for. It crops up in numerical libraries like "numpy" (Python) or "PDL" (Perl) where selected scalar operations distribute over the whole collection. This is great when using collections of numbers, but is not very generalizable: It may not be possible to distinguish whether a method was called on a collection or all items in the collection. One solution would be a “mapping method call operator” like "!" (it's like a method call "." and a shell pipe "|") – but now we have an explicit "map" again.

I think an explicit "map" is more flexible in a general-purpose language. Some languages do interesting experiments with this, e.g. Perl6 which uses “hyperoperators” to precisely control how a given operator is applied.

How many times will Monads be reinvented?

    name.trim.filter{ _.length != 0 }.toUpperCase

becomes:

    name >>= (return . trim) >>= (guard . ((/= 0) . length)) >>= (return . toUpperCase)

I've purposefully used >>= and return instead of fmap to show that '.' above is almost >>=.

EDIT: I've just noticed a type error in the use of guard, but you get the idea.

The problem I see is that implicit mapping restricts the scope of operations that can work on collections -- if there is no distinction between applying an operation to an single object and applying the same operation to all members of a collection, then no collection can directly support the same operation as anything which might be a member of the collection, because you can't disambiguate between attempts to operate on the collection and attempts to operate on the members.

This would seem to be a problem in general, and a particular problem for nested collections. Explicitness makes intent clear.

The example in the article was taken directly from the Scala documentation for [Option](http://www.scala-lang.org/api/current/index.html#scala.Optio...). The map is implicit if you use Scala's for notation. From the linked docs:

    val upper = for {
      name <- request getParameter "name"
      trimmed <- Some(name.trim)
      upper <- Some(trimmed.toUpperCase) if trimmed.length != 0
    } yield upper
    println(upper getOrElse "")

In Scala, an implementation of flatMap (bind), map, and filter allows you to use for expressions like the above. Objects that support these operations are not strictly monads, but they're close enough for most practical uses. Haskell is great, but give Scala a little credit.

This is somewhat similar to the List monad in Haskell:

http://en.m.wikibooks.org/wiki/Haskell/Understanding_monads/...

Bind is concatMap and return puts something into a singleton list. This allows "nondeterministic" computations, where applying functions over all elements in the list is implicit (via bind). Using the monad is not the same as having map be implicit everywhere, but it allows cases where you need several chained implicit (concat)maps to be cleanly implemented.

This is arguably a better design than making all functions polymorphic over lists, and having implicit maps be a global rule (rather than something constrained in a monad's context).

How difficult will code be to read if implicit operations are happening without any mention of the language construct executing them? As far as this goes, Haskell's Maybe monad is the simplest system I've ever seen:

  let x = Just 3 in
  do
   value <- x
   guard (value > 1)
   return (value * 4)

If x was 'Nothing' then the whole operation would short circuit and 'Nothing' would be returned. If the guard fails, then 'Nothing' is returned.

My favourite example of a language with 'automatic functorization' is Icon/Unicon. All functions, when applied to generators, themselves become generators.

So e.g. `read` is a generator that reads lines from the input, `write` writes a line to output, and the composition of them, `write(read())`, is a generator that copies lines from input to output. To run the generator, you can write `while write(read())`.

> What would our languages look like if we made them shape polymorphic? If we moved in that direction it would be like baking the Composite Design Pattern deeply into language machinery. It could be very powerful.

In addition to APL and J, that would look a lot like SQL as well.

R also doesn't distinguish between applying an operation to a scalar or a vector.

Erik Meijer points to this as research in this area: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146....

This is already the case in Haskell. Look up functor