<div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>let's get the discussion going about proposal #155 (<a href="https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst">https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst</a>).</div><div><br></div><div>Summary:</div><div>the idea is pretty simple:  allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition.   The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference").</div><div><br></div><div>This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :)</div><div><br></div><div>I am a bit concerned with the notation though:  in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable.   I wonder if this punning might be confusing.   I don't really have an alternative suggestion though.</div><div><br></div><div>What does everyone else thing?</div><div><br></div><div>-Iavor </div></div></div>