2

I'm writing a functional programming library and I'm trying to decide which name is best for a series of functions.

The functions all take a function and return another function. The returned function has a different return type compared to the input function, but the parameters are not changed.

Implementations are:

  • <parameters> -> T|undefined => <parameters> -> Option<T> apidoc
  • <parameters> -> R|undefined <may throw> => <parameters -> Either<L,R> apidoc
  • <parameters> -> Promise<T> => <parameters> -> Future<T> (planning to add)

There has been some discussion about naming and it's still ongoing in the repository of my library.

The question is whether using the 'lift' terminology is appropriate for the functions I've described.

The reason why it may not be appropriate is that lifting is most often used to describe lifting over a functor, meaning lifting both parameter types and result type. So.. A -> B -> C to F<A> -> F<B> -> F<C>. Which is not what these functions do.

However I see that scala is using the 'lifting' terminology in exactly the way I was:

I wanted to look how they name this in scala-land.. and it turns out... they say it's lifting if I understand correctly: What is "lifting" in Scala?

Remember a PartialFunction[A, B] is a function defined for some subset of the domain A (as specified by the isDefinedAt method). You can "lift" a PartialFunction[A, B] into a Function[A, Option[B]]. That is, a function defined over the whole of A but whose values are of type Option[B]

On the other hand for the lifting when all parameters are lifted besides the result, they say:

"lift" the function A => B into the domain of the functor. [..] "lifting into a functor"

It is there => https://www.scala-lang.org/api/current/scala/PartialFunction.html#lift:A=%3EOption[B]

So that would mean lifting is a general concept, of which functor lifting is only a sub-category. Also, haskell is talking about 'lifted types' and 'unlifted types', suggesting that the terminology is used in a more loose way.

On the other hand this one says lifting is only "functor lifting": https://stackoverflow.com/a/43596202/516188

I have been offering the 'functor' lifting in my library, naming the functions liftA2 and liftAp -- so making a difference between 'lifting' and 'applicative lifting'. Do you think that's appropriate? If not, what naming would you recommend?

EDIT so tu summarize my proposed naming is lift for A->B->X<C> and liftA (like applicative) for F<A>->F<B>->F<C>

Emmanuel Touzery
  • 9,008
  • 3
  • 65
  • 81
  • 1
    In a sense, the quoted Scala use is a transformation both on the parameters and the result type because, although the partial function has the same parameter type, it is only applicable to a subset of the values inhabiting that type. – Aluan Haddad Sep 02 '18 at 10:13
  • You have a `liftA2 :: (A -> B -> C) -> (Option A -> Option B -> Option C)` but no `liftA :: (A -> B) -> (Option A -> Option B)` method in your current library? – Bergi Sep 02 '18 at 12:19
  • @Bergi true. The idea being that you would simply call `map` instead of using liftA1. Could be added at some point though if someone misses it. – Emmanuel Touzery Sep 02 '18 at 12:34
  • OK. For the rest, I recommend not to use the plain name "lift" - it's too ambiguous. Be a bit more verbose and call them "liftThrowing" or "liftPromised" or something. – Bergi Sep 02 '18 at 12:39
  • Thing is, in the end it would be `Either.lift`, `Option.lift`, `Future.lift` so there's already some context (currently they are `FunctionN.liftOption`, `FunctionN.liftEither`). But it could be `Either.liftThrowing`, and so on. Does break the symmetry though. The same name for all, but in different namespaces, is attractive. Was considering something like `liftResult` but it's the function we lift, not the result, so... – Emmanuel Touzery Sep 02 '18 at 12:51

0 Answers0