I cannot see how an empty list of tyvars is useful or desirable in practice: data Foo = Foo (forall . Int) is equivalent to just data Foo = Foo Int so why bother to permit the former? It probably indicates some error in the thinking of the programmer, so the compiler should bring it to her attention.
The only reasons that I could see in favor of allowing empty "forall"s is that it might be easier to automatically generate code. Haskell seems to be a bit inconsistent in how it treats empty constructs. For example, empty let and empty where seems to be allowed, but not an empty case?
On the other hand, I can imagine a use for phantom type variables in the quantifier (especially if they occur in multi-parameter predicates, but not in the type). So I think accepting them with a warning is reasonable.
I can also imagine predicates that do not mention locally-quantified variables - the assumption must be that they mention variables bound on the LHS of the datatype decl instead? e.g. the Show predicate here:
data Foo a b = Foo a b | Bar (forall c . (Show b, Relation b c) => (b,c))
Hmm, maybe a simpler version of this example would illustrate what you mean by the proposal (first of the three bullets) to allow an empty quantifier list:
data Foo a b = Foo a b | Bar (forall . Show b => b)
In which case, does this even count as a polymorphic component at all? Is it not rather GADT-like instead?
data Foo a b where Foo :: a -> b -> Foo a b Bar :: Show b => b -> Foo a b
Would these two have the same meaning? I have a feeling what the GADT is, but no idea what the former type means.
Constructor that have polymorphic components cannot appear in the program without values for their polymorphic fields.
I didn't fully understand this requirement. If Haskell-prime gets rank-2 or rank-n types, then do we need to restrict constructors in this way?
Ok, this really boils down to the question of whether we do rank-2 or rank-n types. I'm biased, because I actually use rank-n types frequently, and feel somewhat limited by the rank-2 restrictions. I don't know how many people actually do, though. I can understand Iavor's points that rank-2 might be easier to explain, but at least GHC's rank-n extension has a very detailed paper explaining it, so I guess it's one of the better documented extensions. I very much agree that "nested" patterns for polymorphic components should be disallowed. Cheers, Andres