[Haskell-cafe] computation over containers, greatly simplified notation.

[Takayuki Muranushi]

Thank you Jason, I have implemented those.
https://github.com/nushio3/practice/blob/master/free-objects/zipn-03.hs

I implemented what I have wanted. It is "forZN" in the following code.

https://github.com/nushio3/practice/blob/master/free-objects/zipf-05.hs

"forZN", much like "printf", can be used in place of any of the following
functions.

forLiftZ1 :: Zip f => f a -> (a -> b) -> f bforLiftZ2 :: Zip f => f a
-> f b -> (a -> b -> c) -> f c
forLiftZ3 :: Zip f => f a -> f b -> f c -> (a -> b -> c -> d) -> f d

...and more...


The last example in above code is the usecase of forZN in my mind: to zip
several arrays with a long lambda. This pattern occurs frequently in my
codes.

One drawback of current approach is that we need verbose type annotations
like
" :: V.Vector String" in   "print $ (forZN vd1 vc1 vi1 f_dci_s :: V.Vector
String) ".

Maybe this is because PType carries insufficient type-level information,
compared to Reduce and Insert. Now I'm now wondering if we can use
ghc-7.6.1's rich kind features such as type-level lists to remove those
verbose type annotations.




2012/12/1 Jason Dagit <dagitj at gmail.com>

> You might find this paper an interesting read:
> http://www.brics.dk/RS/01/10/
>
> On Fri, Nov 30, 2012 at 4:43 PM, Takayuki Muranushi <muranushi at gmail.com>wrote:
>
>> Dear everyone,
>>
>> After a number of attempts [1] I'm starting to think that my initial
>> approach was ill-directed.
>>
>> After all, Functor, Applicative, Zip are three different classes.
>> Functors are type constructors where you can map unary functions over
>> them.
>> Applicatives are those with map-over of zero-ary functions (pure,) unary
>> functions, binary functions, ternary functions, ... etc.
>> Zip are those with unary, binary, ternary ... mapover, but not zero-ary
>> map-over.
>>
>> Repa Arrays and Vectors belong to Zip because there's no trivial unique
>> way to implement pure.
>>
>> What the customer really needed [2] seems to be the following series of
>> functions:
>>
>>
>> forLiftZ1 :: Zip f => f a -> (a -> b) -> f b
>>
>>
>>
>> forLiftZ2 :: Zip f => f a -> f b -> (a -> b -> c) -> f c
>>
>>
>>
>>
>> forLiftZ3 :: Zip f => f a -> f b -> f c -> (a -> b -> c -> d) -> f d
>>
>>
>>
>> Now I'm trying if it's possible to implement the series in a single shot
>> [3] .
>>
>> I'm reporting my progress for anyone who might be still thinking for me.
>> Thank you!!
>>
>> [1] https://github.com/nushio3/practice/tree/master/free-objects
>> [2] http://www.projectcartoon.com/cartoon/3
>> [3]
>> https://github.com/nushio3/practice/blob/master/free-objects/printf6.hs
>>
>>
>>
>>
>> 2012/11/29 Takayuki Muranushi <muranushi at gmail.com>
>>
>>> Dear all,
>>>
>>> I came up with an idea to greatly simplify some kinds of array
>>> computations. It should work well with many kinds of arrays. Is this new?
>>>
>>> https://gist.github.com/4162375
>>>
>>>
>>>
>>> These few days, I've been trying to rewrite a hydrodynamic simulation
>>> code that used Data.Vector (~250 lines), to Repa [1] . It seemed promising,
>>> but soon I realized that I needed to use Repa.map and Repa.zipWith almost
>>> everywhere. I need careful thinking to transform every lines (that used
>>> vector's indexing) to Repa's point-free stile. Is there any better ways?
>>>
>>> Then I realized that I was the author of Paraiso [2], a DSL for stencil
>>> computation. One of its feature is to write down array computation just as
>>> if it were scalar computation.
>>>
>>> Basically what I need is ZipList-like Applicative instances for vectors
>>> and Repa arrays. Why not they support ZipVector? Because 'pure' of zipList
>>> was an infinite list and you can't do infinite vectors. Then I came up with
>>> this idea.
>>>
>>> https://gist.github.com/4162375
>>>
>>> the wrapper W does several things: it represents the 'pure,' homogeneous
>>> array in a space-efficient manner, and also serves as a newtype-wrapper of
>>> Num (and possibly Fractional, Floating...) instances.
>>>
>>> Questions are: is this technology new? or promising? doomed?
>>> It seems to me like a free-Applicative, like the free-Monad theory. Are
>>> they related?
>>> The function 'backend' helps to mix in the non-zip-like computations.
>>> How can we remove the 'undefined' in the 'backend?'
>>> Some of Repa computations are Monads. W needs to be a monad transformer
>>> to incooperate this.
>>>
>>> Also I'm grateful to past cafe discussion on existing Zippable
>>> implementations [3][4] .
>>>
>>> [1] hackage.haskell.org/package/repa
>>> [2] http://hackage.haskell.org/package/Paraiso
>>> [3] http://www.haskell.org/pipermail/haskell-cafe/2009-July/064403.html
>>> [4]
>>> http://hackage.haskell.org/packages/archive/category-extras/latest/doc/html/Control-Functor-Zip.html
>>>
>>>
>>> --
>>> Takayuki MURANUSHI
>>> The Hakubi Center for Advanced Research, Kyoto University
>>> http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html
>>>
>>
>>
>>
>> --
>> Takayuki MURANUSHI
>> The Hakubi Center for Advanced Research, Kyoto University
>> http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121201/b81d6710/attachment.htm>