Conversation

Yeah, well... I guess I have ideas how to make it work but that might not work in reality ; _ ; just hate how positional all the currying and pairing stuff is - as much as it's nice in some cases then stuff lines up properly
1
1
I had this weird (probably bad) idea to have records with 'abstract' fields that you could make concrete later - which would end up kind of being like functions? And you'd be able to have a 'default' field that your record would reduce to if all the fields were concrete.
2
1
[Replying to this whole thread]. Like how you refer to my PhD student's work for the unbundling problem 😆. And yes, contexts should be at least DAGs, not lists. (mutual can involve local cycles too...). Records with abstract fields are quite common in math. 1/
1
2
Think of a concrete vector space (say of dimension 4) over an unknown field. You can also see this as a record definition with some manifest entries (i.e. definitional extensions). The change of perspective can at times be useful. 2/
1
3
In both cases, I think the best view is as a substitution [aka generalized term], mapping from the vector space context to the field that specifies part of it, and the rest is the identity. Yes, this is related to existentials, but where you slice off a whole leading context.
1
2
Oh cool! Didn't know they were your student! Yeah I first noticed the weirdness of bundling with traits in Rust - ie. do I use a type parameter or an associated type? Then in the 1ML paper where they showed that you can do stuff in the 'type class style' or the 'ML style'.
2