On Thu, Jan 17, 2013 at 9:02 PM, Kim-Ee Yeoh wrote:

On Thu, Jan 17, 2013 at 8:40 PM, Rustom Mody wrote:

...

And I need to do things like

type Vertex = Ix a => a (so that a vertex can be used to index an adjacency-list-array)

Two things seem to be going on:

(1) you're trying to define a data type using "type" and not "data"+class instances. Recall that the "type" declares a type /synonym/, and while type synonyms seem to behave like CPP-style macros, they aren't.

...

That is to say that whenever 'Vertex' appears in a type signature, the Ix should 'float' out to the qualifier list

(2) you're trying to save on keyboarding by using Vertex as a CPP-style macro that expands in the "smart" way you just described. Something that has been requested before is collapsing a list of constraints into just one (search haskell-cafe archives and also see "No Module Abstraction" of [1]). The larger the number of constraints, i.e. (A x) expands out to (B x, C x, D x, ...) the greater the need for such a feature. But there's no benefit to be gained here.

(3) you're trying to improve readability of code because "Ix a => a" isn't explicit that type variable "a" is a vertex. Nothing stops you from writing "Ix vertex => vertex" however. See [2].

[1] http://lukepalmer.wordpress.com/2010/03/19/haskells-big-three/

Thanks for that link. So it seems its not possible to do what I want. my aesthetic choice: I don’t obscure my code’s inner beauty behind

repulsive indecipherable type signatures…

Vow! Thats stronger language than I am habituated to use and yes thats what I am talking about. And further if the type signature is already turgid and obese with super-generic constraints, writing (... Ix vertex...) => ... instead of Ix v just worsens it -- http://www.the-magus.in http://blog.languager.org