Two Proposals

[George Giorgidze]

On Oct 6, 2011, at 10:30 AM, Roman Leshchinskiy wrote:

> Manuel M T Chakravarty wrote:
>> Roman Leshchinskiy:
>>> 
>>> What data structures other than lists do we want to construct using list
>>> literals? I'm not really sure what the use cases are.
>> 
>> Parallel arrays! (I want to get rid of our custom syntax.)
> 
> Why? Don't you think it is useful to have a visual indication of which
> data structure you are using and what is going to be evaluated in
> parallel?

I am not a DPH developer :) (just an user), but I thought I would express some of my opinions that are related to your question.

Syntactic indications are nice. But why single out DPH arrays?

DPH arrays and associated combinators support a very important but only one kind of parallelism, namely nested data parallelism on shared memory multi-core hardware. As parallelism may turn out to be Haskell's killer application we will be dealing with many kinds of parallel data structure supporting different kinds of operations and thus having different types (e.g., GPU arrays, distributed arrays, flat data-parallel arrays). Having a special syntax for each of those would not be manageable.

> 
> In any case, if we want to get rid of the parallel array syntax, we have
> to overload list literals, enumerations and list comprehensions. We have
> the generic monadic desugaring for the latter but recovering an efficient
> DPH program from that sn't trivial.

See Proposal (5) in my previous email. It suggests overloading of list literals and enumerations (I call those arithmetic sequences in that email) without going through lists at runtime. Would that work?

As for generic monad comprehension desugaring rules not being efficient enough, I believe it should be possible to define monad instance specific GHC rewrite rules that can rewrite the desugared code as needed. For example, I could imagine how one could rewrite monadic guards into filters, a chain of six zips into zip6 and things like that. I have not tried any of those though.

Cheers, George

> 
> Roman
> 
> 
>