Re: [Haskell-cafe] [Haskell] Rank-N types with (.) composition

19 views
Skip to first unread message

Henning Thielemann

unread,
Feb 11, 2015, 3:25:49 AM2/11/15
to Tyson Whitehead, has...@haskell.org, Haskell Cafe

On Tue, 10 Feb 2015, Tyson Whitehead wrote:

> I came across something that seems a bit strange to me. Here is a
> simplified version (the original was trying to move from a lens
> ReifiedFold to a lens-action ReifiedMonadicFold)

You are on Has...@haskell.org here. Could you please move to
haskell-cafe?
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Henning Thielemann

unread,
Feb 11, 2015, 4:53:17 AM2/11/15
to Simon Peyton Jones, Tyson Whitehead, Haskell Cafe

On Wed, 11 Feb 2015, Simon Peyton Jones wrote:

> ($) has its own *typing rule*; it does not have a special type. It's
> very ad hoc, but ($) is used so much to decrease parens that (e1 $ e2)
> is almost special syntax!

I already wondered why

runST $ do
foo
bar

worked in some versions of GHC and not in others. I guess it is better to
tell the programmer the truth, i.e. remove the special treatment of ($).
If you save a programmer from wondering about why "runST $ do ... " does
not work with the special typing rule for ($), the programmer will later
wonder why (.) does not work or why his privately defined function
application operator (e.g. for reversed order of argument and function)
will not work.

I think that I stay with "runST (do ...)" in order to be compatible with
several GHC versions.

Tyson Whitehead

unread,
Feb 11, 2015, 10:06:45 AM2/11/15
to Simon Peyton Jones, Dan Doel, haskel...@haskell.org
On 11/02/15 04:39 AM, Simon Peyton Jones wrote:
> ($) has its own *typing rule*; it does not have a special type. It's very ad hoc, but ($) is used so much to decrease parens that (e1 $ e2) is almost special syntax!

I do like the idea of being able to end a function application with a
lambda, let, if, case, or do without having to use $ though. Would
something like the following grammar rules be problematic for parsing?

infixexp→ lexp qop infixexp
| - infixexp
| [fexp] lexp (*)
| aexp (*)

lexp → \ apat1 … apatn -> exp
| let decls in exp
| if exp [;] then exp [;] else exp
| case exp of { alts }
| do { stmts }
(*)

fexp → [fexp] aexp

aexp → qvar
| gcon
| literal
| ( exp )
| ( exp1 , … , expk )
| [ exp1 , … , expk ]
| [ exp1 [, exp2] .. [exp3] ]
| [ exp | qual1 , … , qualn ]
| ( infixexp qop )
| ( qop⟨-⟩ infixexp )
| qcon { fbind1 , … , fbindn }
| aexp⟨qcon⟩ { fbind1 , … , fbindn }

https://www.haskell.org/onlinereport/haskell2010/haskellch3.html

were I've added (*) to where I have added or removed lines (basically
I've moved function application from lexp to infixexp in order to allow
the last exp in a function application to be an lexp).

> At the moment the *only* robust way to pass a polymorphic function to a polymorphic function (here, you are passing Wrap to (.)) is to wrap it in a newtype, much as Wrap does.

Good to know.

Thanks! -Tyson

Reply all
Reply to author
Forward
0 new messages