how would monadic rules apply if the function could be of a different type

user_1291986 0
Viewed 342

I'm looking at doing some interop between clojure and scala. As java itself now has lambdas, I was thinking of a generalisation between data and how to apply a function to a collection

  • clojure functions extend clojure.lang.IFn and generalises collection operations on clojure.lang.ISeq
  • scala functions extend scala.Function and generalises collection operations on scala.collection.Traversable
  • java lambdas extend java.util.function.Function and generalises collection operations on java.util.stream.Stream

Questions:

  • Would monads be useful in this case?
  • If so, would a map operation be implemented across all collection types and how might this be generalisable?

Example:

  (map (scala-fn +) 
       [1 2 3]
       (scala-seq [1 2 3]) 
       (.stream [1 2 3]))
  => (scala-seq [3 6 9])

Continued (added haskell as a tag just in case the hardcore type people might know)

There are operations in both Clojure, Scala and Java that take a collection, applies a function to that collection and returns a new collection.

  • All of these languages run on the JVM.
  • However, each language defines it's own class to represent a function.

I'm more familiar with clojure, so there are operations like:

 (into {} [[:a 1] [:b 2]]) => {:a 1 :b 2}

Which converts a clojure vector into a clojure map. Because the into operation generalises on java.util.List any datastructure that inherits java.util.List can be used.

I wish to work with some scala libraries in clojure and face certain obstacles:

  • Scala, like clojure also has immutable data structures, but they are defined very differently from clojure data structures
  • Scala functions inherit from scala.Function and so need to be wrapped to clojure.lang.IFn

  • Scala datastructures do not inherit from java.util.List which means that:

    (into {} (scala-list [:a 1] [:b 2])) will not work.

  • I'm looking to reimplement some basic clojure functions that also incorporate scala datastructures. (map, reduce, mapcat, etc...)

The functionality would look something like:

 (into {} (scala-list [:a 1] [:b 2])) => {:a 1 :b 2}

 (into (scala-map) [[:a 1] [:b 2]]) => (scala-map :a 1 :b 2)

 (concat (scala-list 1 2) [3 4]) => (scala-list 1 2 3 4)

 (concat [1 2] (scala-list 3 4)) => (1 2 3 4) ;lazy seq

 (map + [1 2] (scala-list 3 4)) => [4 6]

 (map (scala-fn +) [1 2] (scala-list 3 4)) => [4 6]
  • What I'm looking for is the ability to use both clojure and scala functions in collection operations.
  • I can do this without using monads (by checking the collection and function types and doing some coercing before function application)
  • What I'm asking here serves as a bit of a curiosity for me, as all the literature I've read on monads seem to presume that any function f:X->Y is universal.
  • However, in the case of clojure/scala/lambda interop, a clojure function, a scala function and a java lambda are not universal. I'm curious about how category theory might be used to solve this problem.
clojure scala haskell
2 Answers

scala functions extend scala.Function and generalises collection operations on scala.collection.Traversable

java lambdas extend java.util.function.Function and generalises collection operations on java.util.stream.Stream

First, the good news: this isn't correct, Java and Scala lambdas can implement any SAM (single abstract method) interface. This allows using Java lambdas with APIs expecting scala.FunctionN and Scala lambdas with APIs expecting java.util.function.* (including Java streams). This interoperability should be complete in Scala 2.12 and later (so far as I know).

The bad news (you knew this was coming): when talking about Scala collection API specifically, it also very much relies on implicit parameters, and those aren't really usable from Java or Clojure. Similarly, Clojure collection API relies on dynamic typing, and IFn isn't a SAM type (because it covers functions with different numbers of arguments). And of course, for use from Clojure, interoperation between Java and Scala lambdas doesn't help.

More generally speaking, the 3 collection APIs (4 if you count the redesing coming in Scala 2.13) are probably too different to be unified like that.

I don't see any way in which monads per se would be useful here. If I was trying to do something usable from Clojure, I'd go with "checking the collection and function types and doing some coercing before function application" as the solution. Protocols could simplify it, but with some performance cost.

alexey_r_92040

I can only give you the Haskell answer, since I don't speak any of those other languages. However to me it seems like you're mostly looking for a way to automatically convert the input to a function. It doesn't appear to have anything to do with monads.

(concat (scala-list 1 2) [3 4]) => (scala-list 1 2 3 4)

If I translate this to Haskell I would give it a type like this

concat :: (IsList l1, IsList l2) => l1 elem -> l2 elem -> [elem]

where ToList is a typeclass which will just convert this container to a list

class IsListOf a where
    toList :: a elem -> [elem]

It is not clear from your example how you would decide on an output type, so I can't help with that.

(map + [1 2] (scala-list 3 4)) => [4 6]

In Haskell this function is not called map but zipWith. If you want to automcatically convert the input you can do it like this.

zipWith :: (IsList l1, IsList l2) => (a -> b -> c) -> l1 a -> l2 b -> [c]

If you want to automatically convert the function you can do it just as well.

zipWith :: (IsList l1, IsList l2, Is2Function f) => f a b c -> l1 a -> l2 b -> [c]

Is2Function would again be a typeclass that just converts to a 2-ary function

class Is2Function f where
    toFunction :: f a b c -> a -> b -> c

There is also something to keep in mind concerning generalizations. I said in the previous that I didn't know how you would decide on the output. This is a problem the compiler also has from time to time (at least in haskell) when you do to many generalizations. Generalizations seem nice on the surface but they don't always make things more clear and can lead to ambiguity.

user_11178840
Related