cvs commit: fptools/ghc/compiler/typecheck TcMonad.lhs TcSimplify.lhs fptools/ghc/compiler/types FunDeps.lhs Unify.lhs

30 Jan 2001 21:14:21 GMT

Tue, 30 Jan 2001 12:37:24 -0800, Mark P Jones <mpj@cse.ogi.edu> 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
different choices.

> 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 * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK