Crash blossoms, while amusing, are not a desirable feature of a programming language. They are specifically a failure to communicate clearly. On Feb 6, 2012 6:38 PM, "AntC" <anthony_clay...@clear.net.nz> wrote:
> Donn Cave <donn <at> avvanta.com> writes: > > > > > 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 > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe