Lazy map operator

[yannham]

Depend on #243. For some reason the map primitive operation on list was not lazy in its first argument, f, which is unjustified. This PRs fixes another small issue at the same time, which was that map and mapRec (renamed recordMap on the way) created lists and records respectively which content was not directly put into a thunk (closurized). This means that expression had to be recomputed multiple times in a call-by-name way, and was also responsible of serialization errors.

[aspiwack]

Frankly, this whole laziness thing is a bit of a distraction. We don't have to care too much about laziness. And I assume that we will be revisiting the semantics in more details soon (such as for #103 ).

[aspiwack]

Anyway, what's done is done. And it doesn't make things worse. So let's merge.

[aspiwack]

For instance, I think this is not a particularly useful invariant. But, again, let's revisit later.

[yannham]

I agree that this may not very important in general, but currently, this allows for simple serialization: because this invariant is enforced, when you deepSeq a term, you are guaranteed to only encounter values or variables. Hence the serializer can just evaluate let x = stuff in deepSeq x x, walk the AST of the evaluated term and serialize basic values. Here, let x = list.map (fun x => x + 1) [1,2,3]) in deepSeq x x would leave thunks of the form %somevar + 1 inside, on which the serializer choked with errors, so very concretely, you couldn't export a term with a lists.map, which was one of the (a bit orthogonal to map's laziness) motivation behind this PR. Sorry, I should have made this clear.

[dpulls]

🎉 All dependencies have been resolved !