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

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?
participants (1)
-
Evan Laforge