It's fair to say that the boundaries of "functional programming" are pretty amorphous and I certainly didn't mean untyped functional programming. In any case,

It's fair to say that the boundaries of "functional programming" are pretty amorphous and I certainly didn't mean untyped functional programming. In any case, if you want to prevent null/None errors in a way that gives the programmer his/her own access to create similar new abstractions then you need * sum types * parametric polymorphism * pattern matching at which point you may as well also add * first class functions and then if you don't describe your language as "typed functional" then how do you describe it?