Scaffolding: build lambda expressions automatically from type

[dhess]

I've been pushing for awhile for some editor smarts that would automatically build a function's expression lambdas as the student creates the function's type. For example, as the student fills out type A -> B -> C, the editor could be filling in the expression hole with λa -> λb -> ?.

I still think this is a good idea. However, it's something we should only enable at levels well above Beginner level. The reason is that I think it's quite important for students to build their function expressions by hand for quite awhile before we automate this for them. It should arguably not be enabled until the student begins to feel a bit frustrated/bored by the robotic nature of building the expression lambda spines. (When this point occurs could be left to the discretion of the instructor.)

[georgefst]

To state the obvious drawback (which I raised when we discussed this), the body of a function needn't necessarily contain a lambda.

-- ignore polymorphism and our need for explicit type applications here - they aren't relevant

f :: a -> a
f = id

f :: [Int] -> [Int]
f = map succ

The former is trivial, and fairly useless. But the latter less so.

So if we were to introduce the feature discussed above, we may wish to disable it again once the student grasps partial application.

[georgefst]

we may wish to disable it again once the student grasps partial application

Alternatively, we could continue to insert the lambda, allow them to construct f = \xs -> map succ xs, then expect them to recognise the opportunity to simplify it (or even point it out to them, as HLint would). This would benefit from a new "eta-contract" action (which would be a refactoring action like those discussed in hackworthltd/primer#19, but not one we'd see in Eval mode).

[brprice]

we may wish to disable it again once the student grasps partial application.

The two other options which spring to mind are

• automatically insert it, but then allow the student to delete (some of) it, if they want to do a partial-application thingy. This raises some questions about UX: what happens if the student deletes it, but then adds more to the type; what happens if the student deletes it but after some effort realises it was a mistake (it would be annoying to have to undo lots of flailing just to get the lambdas back). However, very similar questions are already raised: what happens if we have the type A -> B -> C, engendering λa. λb. ?, the user starts filling in the hole, and then realises they need an extra argument to the function?
• don't automatically do anything, but have an action "insert the canonical construction here", which will do this. (c.f. hackworthltd/vonnegut#354 )

[dhess]

Those are all good points. Perhaps this feature isn't as useful as I thought it might be. Ironically, it's probably the most convenient in the beginning stages when students are just writing pattern matches on inputs, rather than composing functions, but that is precisely when I think it's important that they build the lambdas by hand, so that they understand what "make a function with an input" means.

I'll keep this open for now, in any case, but I don't see any reason to prioritize it for the time being.

[georgefst]

* don't automatically do anything, but have an action "insert the canonical construction here", which will do this.

This is a nice compromise.