Re: Type Level "Application" Operator

Wouldn't there also be a problem with type unification? When unifying ((f . g) a) and (h b) do you set ((f . g) ~ h) or ((g a) ~ b)? On Nov 2, 2016 6:28 PM, "Edward Kmett" wrote:

On Wed, Nov 2, 2016 at 3:11 PM, Index Int wrote:

...

Edward, I don't quite follow why you think that (.) is needed here. Monad transformers take two parameters, so your example is not type-correct, whereas the original one is.

Indeed, I appear to have hyper-corrected that example.

-Edward

On Wed, Nov 2, 2016 at 5:24 PM, Edward Kmett wrote:

...

...

+1, but the operator you're looking for in App there would actually be a type level version of (.).

type App a = ExceptT Err $ ReaderT Config $ LogT Text $ IO a

type App = ExceptT Err . ReaderT Config . LogT Text . IO

which would need

type (.) f g x = f (g x) infixr 9 .

to parse

-Edward

On Tue, Nov 1, 2016 at 7:13 PM, Elliot Cameron wrote:

...

Folks,

Has there been a discussion about adding a type-level operator "$" that just mimics "$" at the value level?

type f $ x = f x infixr 0 $

Things like monad transformer stacks would look more "stack-like" with this:

type App = ExceptT Err $ ReaderT Config $ LogT Text IO

Elliot Cameron

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries