
Thank you, Adam,
for I didn't know about paczesiowa's article. That will be useful for me.
What I was trying to make is a zipWithN that takes the zipper function
as its "last" argument, not the first. This is because in my
applications the zipper functions tend to be complicated lambdas, as
illustrated in [1] . Since we live in curried world where all
functions are superficially unary, to define the "last" argument, and
to implement forZN, needs extra work than to implement zipWithN, I
believe [2] . I'm interested how much we can make these two share
their internal mechanisms.
[1] https://github.com/nushio3/practice/blob/master/free-objects/zipf-05.hs
[2] https://groups.google.com/forum/?fromgroups=#!topic/haskell-cafe/-e-xaCEbd-w
2012/12/6 adam vogt
On Wed, Dec 5, 2012 at 12:12 AM, Takayuki Muranushi
wrote: Dear everyone,
I have a code https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11-1...
that produces a type-error when I remove a type signature. https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11.h...
Hi Takayuki,
The ghc manual sections about the extensions are a good place to start. Also check out http://okmij.org/ftp/Haskell/
I think you are expecting forZN to be able to use the number of -> in the function(s) supplied to decide how many lists to take, as done here: http://paczesiowa.blogspot.ca/2010/03/generalized-zipwithn.html
Replacing the [] container used in the above zipWithN with a `Data.Key.Zip v => v' that is the same for all of the arguments might be straightforward. But there are a lot of type signatures that have to add that parameter, and maybe that will interfere with the incoherent instance business going on.
Adam
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html