3 ms·

The functions in those examples have fixed numbers of arguments, so one would use the original formulation shown by Tyr42. > (+) <$> ZipList [1,2,3] <*> Zi

by tome 6y ago

The functions in those examples have fixed numbers of arguments, so one would use the original formulation shown by Tyr42. > (+) <$> ZipList [1,2,3] <*> ZipList [4,5,6] ZipList {getZipList = [5,7,9]} > (+3) <$> ZipList [1,2,3] ZipList {getZipList = [4,5,6]} > let max3 x y z = max x (max y z) > max3 <$> ZipList [1,2] <*> ZipList [3,4] <*> ZipList [5,6] ZipList {getZipList = [5,6]} If you want to use "functions unknown at runtime that could take any number of arguments" then you'll have to pass the arguments in a list. Of course these can crash at runtime, which Haskellers wouldn't be happy with given an alternative, but hey-ho, let's see where we get. > let unsafePlus [x, y] = x + y > fmap unsafePlus (sequenceA [ZipList [1,2,3], ZipList [4,5,6]]) ZipList {getZipList = [5,7,9]} > let unsafePlus3 [x] = x + 3 > fmap unsafePlus3 (sequenceA [ZipList [1,2,3]]) ZipList {getZipList = [4,5,6]} > unsafeMax3 [x, y, z] = x `max` y `max` z > fmap unsafeMax3 (sequenceA [ZipList [1,2], ZipList [3,4], ZipList [5,6]]) ZipList {getZipList = [5,6]} So the answer to your question is that cl_map :: ([a] -> b) -> [ZipList a] -> ZipList b cl_map f = fmap f . sequenceA except you don't actually want all the elements of the list to be of the same type, you want them to be of dynamic type, so let's just make them Dynamic. > let unwrap x = fromDyn x (error "Type error") > > let unsafeGreeting [name, authorized] = > if unwrap authorized then "Welcome, " ++ unwrap name > else "UNAUTHORIZED!" > > fmap unsafeGreeting (sequenceA [ZipList [toDyn "tome", toDyn "simiones", toDyn "pg"] > , ZipList [toDyn True, toDyn True, toDyn False]]) ZipList {getZipList = ["Welcome, tome","Welcome, simiones","UNAUTHORIZED!"]} and the type of cl_map becomes cl_map :: ([Dynamic] -> b) -> [ZipList Dynamic] -> ZipList b cl_map f = fmap f . sequenceA One could polish this up a bit and make a coherent ecosystem out of it, but Haskell programmers hardly ever use Dynamic. We just don't come across the situations where Clojurists seem to think it's necessary.

simiones 6y ago
So in the end, as I claimed initially, this function can't be written in a simple, safe way in Haskell; and as the article I linked claims, Haskell's type system can't encode the type of the cl_map function. It's nice that Haskell does offer a way to circumvent the type system to write somewhat dynamic code, but it's a shame that in order to write a relatively simple function we need to resort to that. Note that the type of cl_map is perfectly static. It would be `Integer N => (a_0 ->... a_N -> r) -> [a_0] ->... [a_N] -> [r]` assuming some fictitious syntax.
- tome 6y ago
  > So in the end, as I claimed initially, this function can't be > written in a simple, safe way in Haskell Steady on! You posed a question and I gave an answer. You weren't happy with that answer. I think it's a bit premature to conclude that "this function can't be written in a simple, safe way in Haskell". > as the article I linked claims, Haskell's type system can't encode the type of the cl_map function. Could you say where you see that claim in the article? I can see three mentions of "Haskell" in the body, two of them mentioning that one researcher's particular implementation doesn't handle this case, but not a claim that it can't be done. > Note that the type of cl_map is perfectly static. It would be `Integer N => (a_0 ->... a_N -> r) -> [a_0] ->... [a_N] -> [r]` assuming some fictitious syntax. OK, fine, it's a bit clearer now what you are looking for. How about this: > cl_map (uncurry (+)) ([1,2,3], [4,5,6]) [5,7,9] > cl_map (+3) [1,2,3] [4,5,6] > let max3 (x, y, z) = x `max` y `max` z > cl_map max3 ([1,2], [3,4], [5,6]) [5,6] Notice that the function arguments are have different, statically-known types! The type of this miracle function? cl_map :: Default Zipper a b => (b -> r) -> a -> [r] And the implementation? -- Type definition newtype Zipper a b = Zipper { unZipper :: a -> ZipList b } deriving Functor -- Instance definition instance a ~ b => D.Default Zipper [a] b where def = Zipper ZipList -- These three instances are in principle derivable instance P.Profunctor Zipper where dimap f g = Zipper . P.dimap f (fmap g) . unZipper instance Applicative (Zipper a) where pure = Zipper . pure . pure f <*> x = Zipper (liftA2 (<*>) (unZipper f) (unZipper x)) instance PP.ProductProfunctor Zipper where purePP = pure (****) = (<*>) Given that the only two lines that actually matter are newtype Zipper a b = Zipper { unZipper :: a -> ZipList b } deriving Functor instance a ~ b => D.Default Zipper [a] b where def = Zipper ZipList and the rest are boiler plate that could be auto-derived, I think this is pretty satisfactory. What do you think?
  - simiones 6y ago
    First of all, thank you for bearing with me this long! Still, you haven't written exactly the function I was asking for. You require a manual, compile-time step of transforming the N-ary function to a unary function taking a tuple. Still, it's impressive that this can define variable-length, variable-type tuples. Unfortunately I am not able at all to follow your solution, as it's using too many types that I'm not familiar with, and it seems to require some external packages, so I can't easily try it out in an online compiler to understand it better (as I have been doing so far). Either way, I would say we are well outside the limits of an easy to understand way of specifying this kind of function - even if you are only showing 2 lines of code, it seems that your definition requires, outside of lists and functions (the objects we intended to work with): ZipList, Default, Functor, Profunctor, ProductProfunctor, Applicative, and a helper type. Even if these were derivable, someone seeking to write this function would still need to be aware of all of these types, some of which are not even part of the standard library; and of the way they work together to magically produce the relatively simple task they had set out to do. > Could you say where you see that claim in the article? The claim is presented implicitly: for one, they conjecture that, were Haskell or SML to "pragmatically support" such a feature, it would be used more often (offering as argument the observation that both Haskell's and SML's standard libraries define functions that differ only in the arity of their arguments, such as zipWith/zipWith3 in Haskell). This implies that, to their knowledge, it is not pragmatically possible to implement this in Haskell. Similarly, given that in their "Related Works" section they don't identify any complete implementation of variadic polymorphism, it can be assumed that they claim at least not to have found one.

by tome 6y ago

simiones 6y ago

So in the end, as I claimed initially, this function can't be written in a simple, safe way in Haskell; and as the article I linked claims, Haskell's type system can't encode the type of the cl_map function. It's nice that Haskell does offer a way to circumvent the type system to write somewhat dynamic code, but it's a shame that in order to write a relatively simple function we need to resort to that. Note that the type of cl_map is perfectly static. It would be `Integer N => (a_0 ->... a_N -> r) -> [a_0] ->... [a_N] -> [r]` assuming some fictitious syntax.

tome 6y ago
> So in the end, as I claimed initially, this function can't be > written in a simple, safe way in Haskell Steady on! You posed a question and I gave an answer. You weren't happy with that answer. I think it's a bit premature to conclude that "this function can't be written in a simple, safe way in Haskell". > as the article I linked claims, Haskell's type system can't encode the type of the cl_map function. Could you say where you see that claim in the article? I can see three mentions of "Haskell" in the body, two of them mentioning that one researcher's particular implementation doesn't handle this case, but not a claim that it can't be done. > Note that the type of cl_map is perfectly static. It would be `Integer N => (a_0 ->... a_N -> r) -> [a_0] ->... [a_N] -> [r]` assuming some fictitious syntax. OK, fine, it's a bit clearer now what you are looking for. How about this: > cl_map (uncurry (+)) ([1,2,3], [4,5,6]) [5,7,9] > cl_map (+3) [1,2,3] [4,5,6] > let max3 (x, y, z) = x `max` y `max` z > cl_map max3 ([1,2], [3,4], [5,6]) [5,6] Notice that the function arguments are have different, statically-known types! The type of this miracle function? cl_map :: Default Zipper a b => (b -> r) -> a -> [r] And the implementation? -- Type definition newtype Zipper a b = Zipper { unZipper :: a -> ZipList b } deriving Functor -- Instance definition instance a ~ b => D.Default Zipper [a] b where def = Zipper ZipList -- These three instances are in principle derivable instance P.Profunctor Zipper where dimap f g = Zipper . P.dimap f (fmap g) . unZipper instance Applicative (Zipper a) where pure = Zipper . pure . pure f <*> x = Zipper (liftA2 (<*>) (unZipper f) (unZipper x)) instance PP.ProductProfunctor Zipper where purePP = pure (****) = (<*>) Given that the only two lines that actually matter are newtype Zipper a b = Zipper { unZipper :: a -> ZipList b } deriving Functor instance a ~ b => D.Default Zipper [a] b where def = Zipper ZipList and the rest are boiler plate that could be auto-derived, I think this is pretty satisfactory. What do you think?
- simiones 6y ago
  First of all, thank you for bearing with me this long! Still, you haven't written exactly the function I was asking for. You require a manual, compile-time step of transforming the N-ary function to a unary function taking a tuple. Still, it's impressive that this can define variable-length, variable-type tuples. Unfortunately I am not able at all to follow your solution, as it's using too many types that I'm not familiar with, and it seems to require some external packages, so I can't easily try it out in an online compiler to understand it better (as I have been doing so far). Either way, I would say we are well outside the limits of an easy to understand way of specifying this kind of function - even if you are only showing 2 lines of code, it seems that your definition requires, outside of lists and functions (the objects we intended to work with): ZipList, Default, Functor, Profunctor, ProductProfunctor, Applicative, and a helper type. Even if these were derivable, someone seeking to write this function would still need to be aware of all of these types, some of which are not even part of the standard library; and of the way they work together to magically produce the relatively simple task they had set out to do. > Could you say where you see that claim in the article? The claim is presented implicitly: for one, they conjecture that, were Haskell or SML to "pragmatically support" such a feature, it would be used more often (offering as argument the observation that both Haskell's and SML's standard libraries define functions that differ only in the arity of their arguments, such as zipWith/zipWith3 in Haskell). This implies that, to their knowledge, it is not pragmatically possible to implement this in Haskell. Similarly, given that in their "Related Works" section they don't identify any complete implementation of variadic polymorphism, it can be assumed that they claim at least not to have found one.