| The biggest one is that I would like to be able to make [(ix,el)], [Pair
| ix el], and Array ix el all members of a Find class while should look
| something like this:
|
| class Find c ix el where
| find :: ix -> c -> Maybe el
|
| without having to define a new type or introducing the possibility of
| unresolved overloading when the return type isn't explicitly known.
|
| I would _really_ like to know if
|
| 1) Am I correct in assuming this is not possible with current Haskell as
| implemented in Hugs and GHC (ie not just Haskell 98)?
If I understand the terms of your question correctly, then I believe that
you are correct. For a more precise answer, I would need a more precise
question.
| 2) Does anyone care that this type of thing is not possible?
Yes, they do. That said, I've often found that people are usually happy
simply to write something like:
newtype Assocs i e = MkAssocs [(i,e)]
I know it's a bit of a pain to be forced to use the MkAssocs constructor,
but this kind of thing usually works pretty well in practice. I don't think
you've explained why this solution isn't suitable for your purposes?
| 3) Does any one have a solution to this problem?
I believe that "parametric type classes", introduced by Chen, Hudak and
Odersky at the Lisp and FP conference in 1992 (but as yet unimplemented)
would provide a solution. You can download their paper from Yale, but
I'm afraid I don't have the URL to hand right now. (My own paper on
"Simplifying and Improving qualified types" from 1995 is also relevant,
but is more abstracr and has also not been implemented as yet in any general
form.)
| 4) What did you think of my idea for getting around this problem (and a
| lot more) in the post titled "Idea: Nameable type parameters"
Well I think you'd need to spell out your idea in a lot more detail before
anyone could give any firm conclusions. All you have given us so far is
an example. What exactly are you proposing in more general terms, and how
would it interact with type inference and modules? I don't want to
discourage
you from fleshing out the proposal more fully, but I think you should pay
particular attention to these last two points. For example, the essence
of your proposal seems to be a notation for defining functions on types,
and I suspect that you will have problems making unification work properly
in that setting.
I hope that this helps.
All the best,
Mark
