cvs commit: fptools/ghc/compiler/typecheck TcMonad.lhs TcSimplify.lhs fptools/ghc/compiler/types FunDeps.lhs Unify.lhs
Marcin 'Qrczak' Kowalczyk
30 Jan 2001 21:14:21 GMT
Tue, 30 Jan 2001 12:37:24 -0800, Mark P Jones <email@example.com> pisze:
> Yes, the type is valid, at least as far as the theory is concerned.
> But I have strong personal doubts about it as good language
> design ... as I said before, "from a practical perspective, one
> can argue that the polymorphic type is misleading, obfuscating,
> and cumbersome."
What if I want to say: I don't care which type the class C maps Char
to, but whatever it is, call it b, I am writing a function of the
type Char -> b -> Int?
I disagree that it's misleading. It doesn't matter if "for any b
satisfying the following constraint" matches a single type or many
> It might be better to consider a notation that allows partial type
> specifications. (e.g., allow ".." in any part of a type where the
> user doesn't want to go into more detail.)
This could be useful too; not necessarily instead. Although I don't
have a practical need for it at the moment.
> As things already stands, if a user writes:
> foo :: Eq a => a -> String
> foo x = "I don't need equality"
> then you still have to pass in a dictionary at each call, not because
> it's really necessary, but because the user asked for it.
A compiler is not _allowed_ to optimize it away, keeping the same
behavior? I disagree! It can be inlined, worker/wrappered, specialized
etc. It doesn't matter at all what is physically passed.
In fact as long as foo is not passed as a rank-2 polymorphic argument,
there is probably no reason at all to pass the Eq dictionary.
__("< Marcin Kowalczyk * firstname.lastname@example.org http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA