TDNR without new operators or syntax changes

[AntC]

> Bertram Felgenhauer <bertram.felgenhauer <at> googlemail.com> writes:
> ...
> I don't understand your conclusion.

Hi Bertram, I'm trying to tease out of Jeremy,
what he thinks his proposal amounts to.
Seeing as he's given very little clue so far.

So if I've arrived at an incorrect conclusion,
I want him to tell me where/what's gone wrong.

The point, I believe, although Jeremy's not said, is exactly as you say:

> Note that this has nothing to do with record fields at all, ...

So let's modify Jeremy's code snippet

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

to something that's nothing to do with record fields:

         f b c = do { print b; print c }

`print` is a bare name appearing in a function application context.
It therefore needs disambiguating.
It's type :: (Show a) => a -> IO ()
Are `f`s params of type `a`, or of type (Show a) => a ? 
No, they're String or Int or whatever.
Compile fail.

Now you might say `print` doesn't need disambiguating.
Why not? Jeremy hasn't said.
Perhaps Jeremy intends a rule:
If there's only one version of the function in scope, choose that.
If so, Jeremy hasn't said. "syntaxless TDNR" doesn't give me a clue.
I don't think TDNR intended such a rule.

Suppose I do Jeremy's job for him and presume such a rule.

OK then. Second example:
Suppose I don't like what's happening with the FTP library changes,
specifically not the generalisation of `length`. So I write my own

    import qualified Data.List as D
              -- note the qualified
    length :: [a] -> Int.     -- my version restricted to lists
    length = D.length

Now I use length in a bare name function application

    ... (length [1, 2, 3, 4, 5]) ...

Therefore length needs disambiguating.
a) the disambiguator can't match argument type [Int] to [a].
b) even if it could, `length` remains ambiguous
     between my definition and the import.
     (As it happens, they're the same, but can the disambiguator tell that?
      Jeremy hasn't said what he thinks the disambiguator can do.
      But this is way beyond the original TDNR proposal.)

> Jeremy's proposal, I believe, is that the compiler should pick /the/
> possibility that type-checks ..

Well you're guessing what is the proposal, as much as I am.
In both the examples above, neither type checks.
(Or arguably both do if we allow polymorphic type checking.
 But should that allow both paramteric and ad-hoc polymorphic?
 Polymorphic checking is too generous for the way TDNR was spec'd.)

> Note that this has nothing to do with record fields at all,
> except that they give rise to a compelling use case.
> 

So the compelling use case has given us ORF Part 1 in GHC 8.0.
That has a clear antecedent in TDNR. But, pace your note,
it applies _only_ for record fields.
If you look at the implementation notes,
the functions derived from field labels
are specially flagged.
So disambiguation applies only to them,
not in general to bare function names.

> (I'm not endorsing the proposal, ...

Quite.

> ... just trying to clarify what it is.)
> 

Quite.

And since 8.0 is officially released as of this weekend,
I rather think "syntaxless TDNR", whatever it is/was, is stillborn.


AntC