<p>Crash blossoms, while amusing, are not a desirable feature of a programming language. They are specifically a failure to communicate clearly.</p>
<div class="gmail_quote">On Feb 6, 2012 6:38 PM, "AntC" <<a href="mailto:anthony_clayden@clear.net.nz">anthony_clayden@clear.net.nz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Donn Cave <donn <at> <a href="http://avvanta.com" target="_blank">avvanta.com</a>> writes:<br>
<br>
><br>
> You can find stuff like "fromIntegral.ord" in<br>
> packages downloaded to build cabal-install for example. It graphically<br>
> appeals to the notion of a function composed of several functions, so<br>
> the programmers in question will likely not even be repentant!<br>
<br>
Data.Char.toUpper -- a name composed of several names<br>
shape.position.xCoord -- a structure composed of several structures<br>
<br>
Here's an off-the-wall idea for the syntactics:<br>
- Where there's a block of names with dot separators (and no spaces).<br>
- The dots must be either all postfix apply or all prefix compose.<br>
- Postpone analysing until we've got some type info for the sub-names.<br>
- The types must interlock either left-to-right or right-to-left.<br>
So now we know whether we're prefix or postfix.<br>
- Then we can adjust the AST for loose-binding vs tight-binding.<br>
(As happens for operator precedence.)<br>
<br>
?Do we call this "Type-Directed Syntax Resolution" ;-)<br>
<br>
(By the way, natural languages do this sort of stuff all the time. In fact<br>
they revel in it:<br>
"Eighth Army Push Bottles Up German Rear."<br>
<a href="http://languagelog.ldc.upenn.edu/nll/?p=3708" target="_blank">http://languagelog.ldc.upenn.edu/nll/?p=3708</a> )<br>
<br>
<br>
The more I think about it, the more the pseudo-fields makes sense, the more I<br>
want field selectors to be just functions. There's an interesting example in<br>
Wadler's original paper that became View Patterns "Views: A way for pattern<br>
matching to cohabit with data abstraction" [1987], 4. "Viewing a complex<br>
number in cartesian and polar coordinates".<br>
<br>
We may want our implementation of complex to be abstract. We provide (pseudo-)<br>
fields to select the coordinates. Then they're ever-so like methods for an<br>
(abstract) object.<br>
<br>
Also we want the (pseudo-) fields to be updatable, which means field update<br>
needs to be polymorphic (overloaded). Then all I need is a type-(or kind-)<br>
level 'peg' for the name, and an instance for Has/get/set.<br>
<br>
AntC<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>