Mark P Jones wrote:
> | 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?
Ok. In case you haven't figured out I am also the one who asked about
an STL like library for haskell and the one who is attempting to come up
with a good abstraction for Haskell. While doing this abstraction I
have come up against many of the limitations of Haskell type system.
Perhaps if I document the process and detail all the workarounds I had
to do to get around limitations of Haskell type system and the drawback
to those limitations I could give everyone a better idea of the
frustrations I am felling?
>
> | 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.)
Thanks for pointing the paper out. (A url with a copy of the paper is
(http://www.cis.unisa.edu.au/~cismxo/papers/ for those who are
interested) I have not taken a detail look at it but if I don't think it
would completely solve my problem. For example would this be legal:
class c :: ToList a where
toList :: c -> [a]
instance Array a b :: ToList (a,b) where ...
> | 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 have not thought of all the details I was more interested if it had
potential and if it is needed.
> 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.
Your right as I presented it there are some problem. But I think I can
work them out. However I would like to know if it is even worth
pursuing as I am doing this completely on my own time.
>
> I hope that this helps.
It does. Thanks for responding.
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
