<div dir="ltr">Seems reasonable to me too.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 9, 2018 at 7:52 PM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm in support as well.<br>
<br>
Richard<br>
<br>
> On Oct 9, 2018, at 4:45 PM, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br>
> <br>
> Hello,<br>
> <br>
> This proposal would extend the parser to allow the '.' character to appear in type operators, allowing one to write code like the following:<br>
> <br>
> ```<br>
> type (f . g) x = f (g x)<br>
> <br>
> foo :: (Maybe . Either Int) Bool<br>
> foo = Just (Right True)<br>
> ```<br>
> <br>
> I recommend we accept the proposal, as it would resolve an odd inconsistency between the term and type languages. The main downside seems to be that combining a type-level '.' with a 'forall' is a bit hard to read, but I think the benefits of a more consistent syntax outweigh this concern.<br>
> <br>
> Eric<br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>