[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[David Thomas]

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_clayden at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120207/a3dfe686/attachment.htm>