What an interesting meeting! We went over the third set of exercises from the MGS 2019 course on Lambda Calculus.
I've attached my solutions. Ed and I came up with basically the same solutions for the streaming problems.
But we arrived at pretty different results for Problem 5, which involved implementing product types (pairing and unpairing). I thought that it wasn't possible to formulate it in terms of the existing types, but one would have to introduce new typing rules to the system. Ed came up with an ingenious solution, in terms of the simply typed lambda calculus, without any extensions. But I believe it only works when you have a single abstract base type
as described in the lecture. His solution involved finding a least upper bound between the two types to be paired, and deriving injections and projections to and from that type.
For example, if you have a value of type
, you can can construct a function from
, which is just a constant function returning the original value. Hopefully Ed will send out his notes for the complete scheme, which is quite interesting and seems sound. But, there was one flaw - doing a projection could sometimes involve creating a "dummy" value of type
. Because it's an abstract type, we have no way of coming up with such a value. This could be solved if type
that is, if it had some distinguished value we could name. That would be the case if, instead of this abstract type
, we had a primitive
type, for example. But if we had multiple, arbitrary base types, I don't think Ed's plan would work anymore.
Exercise 7 was about converting between types
. An interesting observation was that
is the same type as
! And it seems that to map from
, you can just use Ed's trick from Problem 5: just apply the K combinator to it, that is,
. But the question is, does that give us the right number? If we start with
and apply the K combinator to it, do we get
? And the answer is, no.
But then we wondered if all
values of a particular type aren't actually the same! The reason is that, since
has no terms, the only term from
is the identity function. Since all a
does is apply a function from
some number of times, it must be applying the identity function. Thus all
values, when applied to an
value, must just return the original value. But then, there aren't any
Something clearly isn't right here. I think we're supposed to assume that there are
values of type
, but we just don't know what they are. The author's scheme is unusual. Other presentations I see of the STLC either start with some set primitive types, like
, or they say that there is some arbitrary set of base types. They don't just have one arbitrary base type. That seems to lead to quirky properties.