Ticket #3 (closed enhancement: wontfix)

Opened 7 years ago

Last modified 6 years ago

Generalize function application and container lookup

Reported by: jmcarthur Owned by: somebody
Priority: major Milestone:
Component: component1 Version:
Keywords: Cc:

Description (last modified by jmcarthur) (diff)

These functions all share something in common:

($) :: (a -> b) -> a -> b
(!!) :: [a] -> Int -> a
(!) :: Ord k => Map k a -> k -> a
(!) :: IntMap a -> Int -> a

The similarity is clearer if we replace [a], Map k a, and IntMap? a with isomorphic function types:

($) :: (a -> b) -> a -> b
(!!) :: (Int -> a) -> Int -> a
(!) :: Ord k => (k -> a) -> k -> a
(!) :: (Int -> a) -> Int -> a

They all are a form of function application (or, alternatively, map lookup). I propose some sort of type class for this idea:

class Mapping m where
    type Domain m
    type Codomain m
    ($) :: m -> Domain m -> Codomain m

We should also make the partial map lookups total by making their Codomains use Maybe.

Open questions:

  • Are there better names to use?
  • Should we have different operators for different fixities? ($) has a very particular fixity which we might not always want for e.g. list indexing.
  • All the examples above have the codomain as a type parameter. Can we leave out the Codomain type in this type class and just have it take * -> * instead?
  • Are there any other functions that could naturally be in this type class?

Change History

Changed 7 years ago by jmcarthur

  • description modified (diff)

Changed 7 years ago by jmcarthur

  • description modified (diff)

Changed 7 years ago by jmcarthur

An interesting generic composition:

(.) :: (Mapping f, Mapping g, Codomain g ~ Domain f) => f -> g -> Domain g -> Codomain f
(f . g) x = f $ g $ x

I'm not entirely sure how to make this play nice with the Category version of (.) though, or even if that is desired.

Changed 7 years ago by jmcarthur

  • description modified (diff)

Changed 6 years ago by jmcarthur

  • status changed from new to closed
  • resolution set to wontfix

This proposal, if taken to logical extremes, would lead to insanely complex types everywhere. I'm marking this ticket as wontfix. If anybody thinks of an idea that retains some or all of the generality from this proposal without complicating everything, I would be up for reconsidering it.

Note: See TracTickets for help on using tickets.