The madness of implicit parameters: cured?

[Ben Rudiak-Gould]

On Sun, 3 Aug 2003, Ashley Yakeley wrote:

> At 2003-08-03 14:09, Ben Rudiak-Gould wrote:
> >	g (\@x -> @x)  =>  (\@x -> g { @x = @x } @x)
> 
> Hmm... I assume you mean specifically this:
> 
>   g (\@x -> @x)
>   \@x -> (g { @x = @x } @x)
> 
> Supposing you have this:
> 
>   g = \_ -> 3

Yeah, the application rule is actually more complicated than that: it
depends on knowing all the auto-lifted parameters of both the LHS and the
RHS. The set of autolifted parameters of the application node is the union
of these two sets, and each parameter is passed on only to the function(s)
that need it. This means that in a dynamically-typed implementation,
application is necessarily quite strict: both the LHS and the RHS need to
be reduced to HNF, whereas normally you need only WHNF on the LHS and
nothing on the RHS. However, I don't think this is a problem in Haskell,
since all the necessary information can be derived statically from the
type.

> Something else I haven't mentioned is that you shouldn't use (->) as such 
> in the type signatures. This is because (->) is an ordinary 
> type-constructor.

Okay, good point. (=>) seems like the obvious choice. I shall use it
henceforth.


-- Ben