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

[quick at sparq.org]

Fair deuce.  With all due respect now included, my same concern still seems to
apply although I believe I poorly stated it originally.  Allow me to retry:

  By declaring partial application an invalid parse, it introduces an exception
to point-free style that is at odds with the normal intuition of the uses of "f x".

SPJ's SOPR raises it as an issue and indicates he's inclined to disallow it; my
concern above would still apply.

As I surely mis-understand it (referencing your proposal as RHCT since I haven't
seen another reference):

SOPR:      map (\r -> f r) recs
SOPR:      map (get f) recs
SOPR/alt:  qfmap (undefined :: "f") id recs

RHCT:      map (\r -> f r) recs
RHCT:      map (\r -> r.$rev_ f) recs
RHCT:      map ((.$)f) recs

If partial application is allowed (against SPJ's inclination and explicitly
disallowed in your scheme), I could have:

    map .f recs

in either SOPR or your proposal, which (to me) is an intuitive coordination of
the two concepts (point-free/partial application and f.x desugaring).  I don't
think this is currently a valid parse, so I don't think it breaks existing, but
that's not a very well informed opinion either.

My concern is a triviality however; my intent was to attempt to assist in trying
to clarify a what I perceived as a conceptual gap in the discussion.  I am most
grateful for the significant time and effort contributed by yourself, SPJ, and
all other parties, and I fear I've mostly wasted people's time on syntactic
trivialities already well discussed and dismissed.  Please do carry on, it's all
good stuff.

-KQ


Quoting AntC <anthony_clayden at clear.net.nz>:

> Kevin Quick <quick <at> sparq.org> writes:
> 
> > 
> > 
> > On Tue, 31 Jan 2012 23:10:34 -0700, Anthony Clayden  
> > <anthony_clayden <at> clear.net.nz> wrote:
> > > I'm proposing x.f is _exactly_ f x. That is, the x.f gets
> > > desugared at an early phase in compilation.
> > 
> > Anthony,
> > 
> > I think part of the concern people are expressing here is that the above  
> > would imply the ability to use point-free style.  But this orthogonality  
> > is disavowed by your exception:
> > 
> > > A 'one-sided dot doesn't mean anything.
> > 
> 
> Kevin, thank you for helping me clarify my descriptions. I admit my
> 'proposal' 
> is probably a bit hard to follow at the moment, because it lives in a series
> 
> of emails, rather than all in a coherent wiki page.
> 
> It's also possibly confusing because there are three differing proposals in 
> play, and they all use dot notation for field selection, but they use it 
> somewhat differently.
> 
> But every proposal supports dot-as-function-composition, providing the dot 
> appears with space on both sides.
> 
> The discussion with Donn Cave has clarified that under my proposal (but not 
> TDNR or SORF), the dot notation is not necessary. Donn is concerned that
> older 
> code might be using dot for function composition in contexts that would be 
> ambiguous with field-selection-as-reverse-application.
>  http://www.haskell.org/pipermail/haskell-cafe/2012-January/099008.html
> 
> So we could make the dot notation a compiler option:
> - you either keep with H98 syntax,
>   so field selection must be by usual function syntax f x
> - or use dot notation so that x.f desugars to f x
>   (of course you could still use f x: nothing forces you to use the dot)
> 
> Let me give some examples to clarify what I mean by 'one-sided' dot:
>    M.f    -- no spaces, upper case to left, is qualified name
>    x.f    -- no spaces, lower case to left, desugars to f x
>    x . f  -- spaces both side of dot, is function composition
>    x. f   -- space on one side only, what does that mean?
>    x .f   -- space on one side only, what does that mean?
> 
> In my view, those last two (which I'm calling 'one-sided' dot) are too 
> confusing (for the eye, at least). I would reject them as invalid syntax. H98
> 
> might treat them as function composition. (I'm not sure, I wouldn't code like
> 
> that.)
> 
> Donn is saying that he doesn't want to break extant code that uses
> 'one-sided' 
> dot. Fair enough. Under my proposal we could make it a compiler option to 
> stick with H98 syntax, an which case x.f is function composition (I believe),
> 
> not field selection.
> 
> I know Wadler's rule about the disproportionate time spent on lexical syntax.
> 
> SPJ was trying (inter alia) to introduce dot notation to support more OO-type
> 
> thinking. I'm more familiar with dot-as-field-selector from relational 
> databases, so I'm keen to introduce it.
> 
> But frankly it's a side-show compared to addressing the namespace issues 
> around records.
> 
> 
> > I haven't read the underlying proposals, ...
> 
> No, clearly you haven't from what follows. Pay me (and the other
> contributors) 
> the respect of doing so before wasting my time. I'm a busy person. I 
> appreciate the feedback on this forum when it's informed. I appreciate that 
> people give their time voluntarily (which is what I'm doing).
> 
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/