The madness of implicit parameters: cured?

[Ashley Yakeley]

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