TDNR without new operators or syntax changes

[AntC]

> 
> With syntaxless TDNR enabled, the last line could be:
> 
>     f b c = do { reset b; reset c }
> 

Heck, I didn't think you meant something that radical.
So bare name in a function application context is to need disambiguating.

I think you'll find rather a lot of those in existing code.
So this is a code-breaking change.
The merit of adding an extension via new syntax,
is that in the places you didn't and don't use the syntax,
 nothing breaks.

Note that currently if you have in scope both a bare name
and that same name qualified,
the bare name applies, the compiler ignores the qualified one,
unless you deliberately write in the qualification.

How much are people deliberately playing with same name
bare and qualified? Probably seldom.
How much are people importing qualified
so they don't have to worry about their local name clashing?
Suddenly they'll have to start worrying.

So I see difficulties.
Perhaps TDNR's dot-apply would have suffered them too, but
* it was expected that dot-suffixing would only be used for field access
    (and access to field-like functions)
* it was expected that the argument to the function would be near by,
    so the compiler wouldn't have to look far for the type by which to resolve
* the debate around TDNR didn't get into this much detail,
    because the dot syntax proposal met such a violent counter-reaction
* so TDNR never got beyond a wiki page, AFAIK.

One thing TDNR certainly suffers is that you still
 can't declare two distinct data types in the same module
with the same field name. ORF Part 1 in GHC 8.0 at least allows that.

Difficulties:
overloaded functions (methods) don't have a specific data type argument,
by which we could disambiguate the bare name.
(Disambiguation is supposed to be lightweight,
 we don't want to go hunting for instances.)
So a lot of the bare function names (eg imported from the Prelude)
are going to run into trouble.

In
    f $ g $ h x
we have to disambiguate h to know its result type,
before we can disambiguate g, before we can disambiguate f.
Type improvement could rapidly get stuck.
Ah! but those are not bare names in a function application context.
So ($) contexts (and function composition (.) contexts)
are going to behave different to
    f (g (h x))

But then your OP suggested users who want postfix apply
could define their own operator.
Presumably TDNR *is* to apply to that sort of function application(?)
So to ($) or not? to (.) or not? to sections or not?
to bare name functions supplied as arguments (to say map) or not?

I think this is the point SPJ would ask you to write up a proposal on a wiki,
to the same level of detail as all those other records proposals.


AntC