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

Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
30 Jan 2001 23:23:46 GMT


30 Jan 2001 22:01:55 GMT, Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> pisze:

> I propose to change the meaning of pattern and result type signatures.
> They should only constrain the type to the amount of knowledge written,
> and give names to types or appropriate parts of types. But they should
> not require that the types involved are not determined in more details
> somewhere else. It's a type *pattern*, where a type variable can
> stand for anything, and means not "forall" anyway, but "don't care".

As for type signatures on expressions, it can be done either way.
Currently new type variables have the implicit forall. Alternatively
they could mean "don't care", with the scope being only the expression
with the signature.

This would allow to write
    (l :: [a])
in an expression to disambiguate the type which would otherwise
be overloaded on some container types, for example, without saying
anything about "a" (provided that "a" is not bound outside).

An expression is not used polymorphically itself except rank-2
polymorphism, so a real forall is rarely assumed anyway. With my
proposal the programmer is not forced to bind (in pattern and result
type signatures outside) all type variables of an explicitly written
type which are taken from the environment - type variables just mean
"don't care".

In other words
    expr :: [a]
would be equivalent to
    let private :: [a] = expr in private
after my proposed change to the meaning of pattern and result type
signatures.

This reduces the need of (..) in types even more. Generally if one
wants to partially specify a type of a let-bound variable, maybe he
will be happy if the context is omitted completely, and he can write
appropriate pattern and result types instead of a separate signature,
putting type variables in place of (..)'s. If one wants to partially
specify a type of a subexpression, similarly he can just write type
variables in place of (..)'s in its explicit type signature.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK