[Haskell-cafe] a variant of TDNR (was: Re: Some thoughts on Type-Directed Name Resolution)

[Evan Laforge]

I brought up an idea on another thread, but it was a bit off subject
and I think it got buried.  Anyway, I'm curious to know if there are
any obvious problems with this idea, or if it could be pursued
further:

It could be called Tagged Type Directed Name Resolution.

The idea is a # prefix for identifiers.  #f is a "type directed function".  It
requires the type of its argument to be monomorphic, and is desugared to M.f,
where M is the module defining the type of 'f's argument.

Everything else remains the same.  Records wishing the same name must live in
separate modules, but field access looks like: (#a . #b) record

This works to set fields of a record as well.  Let M.f be a function from
a record to a lens focused on a certain field of that record.  Now you can
write:

M.a :: M.Record -> Lens M.Record M.A
set :: Lens record field -> record -> record
val = set (#a 42) record

which becomes: set (M.a record) 42

Or composed 'set ((#a.#b) record) 42' becomes 'set ((M.a . N.b) record) 42'

An operator with convenient fixity should be able to remove the parens.

As long as the compiler can figure out a monomorphic type expected by the input
of #a then it shouldn't need type annotations.


The thing I'm not sure about is if the ghc typechecker can do this.  It would
know that '#a' is a function 'alpha -> beta', then need to figure out what
alpha is.  Then once it has a monomorphic type for alpha, then it has to look
up a symbol 'a' in the module defining that type, and only then does it know
the type of beta.  If #b.#a style composition is to work, then of course '#b'
would have to hold off until the return type of '#a' has been resolved.

I don't know how hard that would be, or it would even be possible.

This idea is less powerful than other proposals because the #-decorated
function must be able to statically determine a monomorphic type for its
argument.  So no structural types.  And no records with the same field
name in the same module.  Personally that doesn't bother me much since
I try to keep modules small, but perhaps that could be addressed in an
orthogonal nested module feature.


The '#' prefix would mess up people using that as an operator.  I guess @ is
free, right?