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

AntC anthony_clayden at clear.net.nz
Fri Feb 3 16:40:50 CET 2012


Gábor Lehel <illissius <at> gmail.com> writes:

> 
> On Fri, Feb 3, 2012 at 2:37 PM, AntC <anthony_clayden <at> clear.net.nz> 
wrote:
> > Do people really write code with huge pile-ups of functions prefix upon
> > prefix? Wouldn't that be confusing even when it's unidirectional?
> 
> Not really. Pipeline-like chains where you apply each function to the
> result of the previous one are quite common and readable, whether in
> the shell, ..

Thank you for reminding me! Unix Pipelining -- that's where I've seen it. And 
in the shell, the pipelining is postfix.

My (.$) is loose-binding postfix application. But let me do:

    (.|) = flip ($)        -- same as (.$), but suggestive of the pipe

        customer.lastName  -- field select, dot 'allowed' per Gábor
     .| tail               -- function apply, dot not
     .| head
     .| toUpper            -- are you warming to it?

        [1..10]
     .| filter even
     .| foldr (+) 0
     .| (^ 2)              -- the parens is a bit of a let-down

> 
> What -is- a problem is if you
> are forced or encouraged to write confusing code (because there's no
> other way to do it or because it's the path of least resistance),
> which is why I dislike proposals which make postfix application
> mandatory for some purposes, or which make it have different behaviour
> from normal prefix application.

Totally agree, that's one of the things I didn't like about TDNR or SORF. 
That's why I'm trying to support both prefix and dot-notation field selectors.

The main thing, though, I like about field selectors as functions (and nothing 
more) is that we've then got a mechanism for overloading them to select from 
multiple record types, and the mechanism is rock-sold instance resolution, not 
some semi-syntactic/semi-type-driven dodginess.

[I'll let you into a secret about my plan for world domination:
 If field selection is just an (overloaded) function,
 we can apply it to other things than records.
      tuple.fst
 We can turn our data dictionary into a type dictionary:
      newtype Customer_id = Customer_id Int
 We can 'hunt out' the customer_id from a tuple:
      tuple.customer_id
 (Using instance resolution to the only Customer_id in that tuple.)

 And now we've got tuples as anonymous records.
 Crucially: we don't care about the field's position within the tuple.
 We could have two tuples with the same fields, but different order.
 And treat them as equivalent at the type level.
 (What relational theory calls 'union compatible'.)

 End of mad moment.]

> If postfix code can be conveniently written using your (.$) combinator
> (and presumably its extended family), with no changes required to
> existing or future functions, I guess it could all work out. What I'm
> afraid of is that introducing postfix notation results in a pressure
> to make functions convenient to use with it, and then we eventually
> end up in the morass I described.

Totally agree, I think order of parameters in declarations should continue to 
expect prefix style, with least specific first (that is, leftmost).

> I'm not sure what we would need to be able to
> reasonably expect that.
> 

I think time for others 'listening in' to develop the family of combinators!






More information about the Haskell-Cafe mailing list