This is actually possible with the ConstraintKinds extension in GHC.

    type Mappable = Functor
    type NotScaryFluffyThing = Monad

This makes Mappable a synonym for Functor and likewise for Monad. (This is not necessarily a good idea; it goes against the principle of least surprise, but it'll work).

My code definitely needs more NotScaryFluffyThings in it.

Isn't aliasing types a core language feature?

Functor and Monad are technically not types but type classes (i.e. interface vs an implementing class), hence why simple/naive type aliasing is not enough.

That would be wrong. Functors also describe things that aren't necessarily "mappable". The actual definition of functor is more general than that.

A fork of Haskell with descriptive names and operators could be really popular, I think.

Actually wouldn't be a fork. It's just an alternative Prelude library. People do this occasionally. The result tends to be idiosyncratic.

In Scala there aren't any names for functors that I'm aware of. I just though one day that "wouldn't it be practical if I could map an option instead of match-casing the meaning out?" and lo and behold it worked. Maybe we just don't need that much terminology.

That's because the Scala stdlib doesn't abstract over things that can be mapped over. If you want to do that, then you need a typeclass. Scalaz has a typeclass for mappable things and it's called Functor.

You need a term for "thing that I can map" if you want to be able to write a function that takes a generic "thing that I can map". Which I do.

    > I wish there was a language or library that was willing
    > to take the Haskell functionality and just give it all
    > names like this.

I don't think this helps understanding that - for example - Either is also a functor.

`Either a` is a functor, not Either. I agree with the rest of your point, though. Maybe might be a better example - similar in spirit to Either, but without requiring an application to get a functor.

That Either is Mappable is, IMO, both clearer and more informative than that it's a Functor.

Maybe someone can correct me here, but that kind of approach seems ill-founded to me when after a couple examples, people are already talking about different things using the same terminology.

The article says "A list is a Functor". Now you're saying "Either is a Functor". But those two things don't have the same nature.

Maybe what the author meant "The [] list constructor is a Functor"?

I'm not sure what is gained by garbling abstractions and reducing them to a subset of their potential interpretations.

I think the problem here is terminology. A functor is the abstract concept and it implies having the map operation with the right signature and obeying the right properties.

The best way to say it is "The list type 'forms' a functor" or "The Either type 'forms' a functor". The fact that they form a functor implies that their map operation has a fixed set of properties, and these properties are independent of what exactly the data structure does and how it works.

"Either" actually isn't a Functor, at least in Haskell

In Haskell, a Functor actually consists of two parts: The type itself (f), which 'transforms' a type a into type "f a". ie. Maybe "applied" to Int gives "Maybe Int", a new simple type (let's handwave kinds away for now). In addition to that, the fmap function is required for Maybe to be a Functor. A Functor is defined by this ability to "add structure" to existing types and the mapping operation.

Seen this way, Either is clearly not a Functor: "Either Int" is not a simple type. However, "Either Int" is a functor: Either Int String forms a simple type, and you can implement fmap. In fact, that works for any type, so "Either a" is the functor as usually defined in Haskell.

There's no subset, no garbling; Functor literally has one member, map (fmap in Haskell but that's a historical artefact).

More specifically, a pedagogical artifact. Originally, fmap was spelled map. The list-specialized map was added to make teaching easier.

Scala programmer here.

  class Container(val property:Int)

  val list:List[Container]
  val mappedlist:List[Int] = list.map(x=>x.property)

  val option:Option[Container]
  val mappedOption:Option[Int] = option.map(x=>x.property)

It works in exactly the same way...