The previous post in this series discussed the lay of the (is)land from the perspective of TSL (I’m so disappointed in myself for not making this pun last time; better late than never). I mentioned that the TSL view cannot handle all island constraints. Sometimes, we need an alternative approach. But this alternative approach doesn’t come out of nowhere. It is also what we need for all kinds of licensing constraints, and it also handles restrictions on movement that are not island constraints.

Continue reading

As you might have gleaned from my previous post, I’m not too fond of features, but I haven’t really given you a reason for that. It is actually straight-forward: features lower complexity. By itself, that is actually a useful property. Trees lower the complexity of syntax, and nobody (or barely anybody) uses that as an argument that we should use strings. Distributing the workload between representations and operations/constraints over these representations is considered a good thing. Rightfully so, because factorization is generally a good idea.

But there is a crucial difference between trees and features. We actually have models of how trees are constructed from strings — you might have heard of them, they’re called parsers. And we have some ways of measuring the complexity of this process, e.g. asymptotic worst-case complexity. We lack a comparable theory for features. We’re using an enriched representation without paying attention to the computational cost of carrying out this enrichment. That’s no good, we’re just cheating ourselves in this case. Fortunately, listening to people talk about features for 48h at the workshop gave me an epiphany, and I’m here to share it with you.

Continue reading