Donn Cave
You can find stuff like "fromIntegral.ord" in packages downloaded to build cabal-install for example. It graphically appeals to the notion of a function composed of several functions, so the programmers in question will likely not even be repentant!
Data.Char.toUpper -- a name composed of several names shape.position.xCoord -- a structure composed of several structures Here's an off-the-wall idea for the syntactics: - Where there's a block of names with dot separators (and no spaces). - The dots must be either all postfix apply or all prefix compose. - Postpone analysing until we've got some type info for the sub-names. - The types must interlock either left-to-right or right-to-left. So now we know whether we're prefix or postfix. - Then we can adjust the AST for loose-binding vs tight-binding. (As happens for operator precedence.) ?Do we call this "Type-Directed Syntax Resolution" ;-) (By the way, natural languages do this sort of stuff all the time. In fact they revel in it: "Eighth Army Push Bottles Up German Rear." http://languagelog.ldc.upenn.edu/nll/?p=3708 ) The more I think about it, the more the pseudo-fields makes sense, the more I want field selectors to be just functions. There's an interesting example in Wadler's original paper that became View Patterns "Views: A way for pattern matching to cohabit with data abstraction" [1987], 4. "Viewing a complex number in cartesian and polar coordinates". We may want our implementation of complex to be abstract. We provide (pseudo-) fields to select the coordinates. Then they're ever-so like methods for an (abstract) object. Also we want the (pseudo-) fields to be updatable, which means field update needs to be polymorphic (overloaded). Then all I need is a type-(or kind-) level 'peg' for the name, and an instance for Has/get/set. AntC