Re: The madness of implicit parameters: cured?
At 2003-08-03 14:09, Ben Rudiak-Gould wrote:
((let g = \_ _ -> \@x -> @x in ((g (\@x -> @x)) {@x = 2})) (\@x -> @x)){@x = 1} ((let g = \_ _ -> \@x -> @x in (g 2)) (\@x -> @x)){@x = 1}
This reduction is incorrect. Auto-lifted parameters on the RHS of an application get lifted out, so
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 then you have this reduction: g ?x g (\@x -> @x) \@x -> (g { @x = @x } @x) \@x -> ((\_ -> 3) { @x = @x } @x) error: can't apply (\_ -> 3) { @x = @x } 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. For instance, if you define this: type Func = (->) then all these are the same type: Func a b (->) a b a -> b But in your scheme, (->) has been extended to allow certain pseudo-types in its first position. It might be better to use a different syntax rather than overload (->) with something that isn't a type-constructor. -- Ashley Yakeley, Seattle WA
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
participants (2)
-
Ashley Yakeley -
Ben Rudiak-Gould