(`evalState` S.empty) looks stupid

[Gurkenglas]

I'm not sure whether this should look this stupid and I should change my approach, or we're just missing an alias.

[mstksg]

Not sure where I've ever seen this idiom?

[Gurkenglas]

http://ircbrowse.net/browse/haskell?q=%28%60evalState%60+S.empty%29 http://ircbrowse.net/browse/haskell?q=flip+evalState http://ircbrowse.net/browse/haskell?q=flip+execState http://ircbrowse.net/browse/haskell?q=flip+runReaderT http://ircbrowse.net/browse/haskell?q=flip+evalStateT etc.

[mstksg]

ah. i usually do flip evalState x, things like that. (evalState x) does look a bit silly, but flip evalState x seems pretty mundane to me.

that being said, the only reason runStateT has the order that it does is to be a hack using record accessors, I think:

data StateT s m a = StateT { runStateT :: s -> m (a, s) }

so you get

runStateT :: StateT s m a -> (s -> m (a, s))

for "free". I always felt like this was an abuse of record syntax, but :|

flip runState looks pretty nice to me. in any case, having an alias for flip runState sounds like a pretty bad sort of API bloat or fairnbairn-threshold-failing thing :/

[Gurkenglas]

Right about the bloat, but both flips have their place. My intuition does tell me runStateT is the correct one, because it and evalState etc. often allow eta reduction. Only sometimes the initial state is constant and I wonder.

[Gurkenglas]

[ Hmm. Couldn't you just make "asd . evalState do dsa; sda" behave like "asd . evalState (do dsa; sda)"? That's currently a parse error, so free for the taking.

Gurkenglas : well, i'd like that as well (and similar with `foo \x -> ..x..',`foo if ...', `foo case ... of ...',`foo let ... in ...') Gurkenglas: allowing "do", lambda, "let", "case", etc to appear as subexpressions (and not just infix argument subexpressions) would be very welcome IMO too. It's weird that it is only allowed as infix args! yep that would obliterate most of my remaining uses of `$'](http://ircbrowse.net/browse/haskell?id=22561319×tamp=1459850137#t1459850137) Good thing I kept that problem in the back of my head! This resolution seems trivial, if one has access to GHC source.

[neongreen]

This has already been proposed and there's even a patch: https://phabricator.haskell.org/D1219, https://ghc.haskell.org/trac/ghc/ticket/10843. However:

My conclusion was that support for the extension was very mixed, and that I do not think the extension makes sense without overall approval from the community. I am not planning on pushing this any further.

[Gurkenglas]

Those cons are stupid!

It's harder to read than the alternative.

Subjective.

Creating a language extension to get rid of a single character is overkill and unnecessary.

Overkill yes, unnecessary no - it's literally what needs to happen to get rid of that character (right?)

You can already get rid of the $ by just adding parentheses.

$ was introduced in the first place to get rid of parentheses! The preference ordering is () < $ < _.

More and more syntactic "improvements" just fragment the language.

That can be said about any syntactic improvement, and this is the way we've been left to get to the mythical Haskell'.

Although this is consistent with record syntax, record syntax without parents was a mistake originally.

If those are the same cons that were brought up here, see above.

Why do we need approval to introduce language extensions anyway, instead of me being able to import that patch like a library?