I'm sorry, but that doesn't make sense to me. You say it as if it's the only sensible way to design a declaration syntax, but Haskell (and other languages) did it the other way just fine. I don't see how the differences in semantics between the 2 type systems give rise to a benefit in having the type expressed on the left.
If the design came to be decided like that, it seems it's simply not something that was put much thought over. That's fine too, since the limitations of the type system do not give rise to cases where this syntax choice becomes too big of an inconvenience.
Still, no benefits as far as I can see. Maybe it simply appealed to the designer's intuition more. Choosing because of that indicates that the choice was pretty arbitrary, though.
> You say it as if it's the only sensible way to design a declaration syntax
I don't say that -- in fact, I'm replying to my own post saying that the declaration on the left was a mistake. My only point is that it is a design decision that has some historical grounding.
So the declaration on the left [ed: Was right] makes a certain amount of sense - you’re declaring an int, so that’s what you lead with. When you declare a “string” you have to think about how the string is stored; and that implementation detail bleeds into the syntax.
A C has matured the notion of incompatible types has seeped into the language to the point where now it becomes a little annoying that I can just go ahead and pass an int into a function that expects a typedef’d “type”; libraries often wrap them in very lightweight structs just to get an additional bit of typechecking. The expectations for what kind of errors the compiler can catch have grown over time but the language has only made small concessions.