Dot-Notation for Flipped Function Application

Please allow to put a dot . (without whitespaces) between two things for flipped function application. This could make for code in pseudo-OOP style:

encrypt(str) = do {
  str.map(succ);
}

Currently, as a workaround, this can be achieved by defining (.) = flip ($) (making . for function composition unavailable, though):

encrypt(str) = do {
  str.map(succ);
} where (.) = flip ($)

(For a remotely similar look-and-feel, one could use Data.Function.((&)) instead of (.).)

Side note: . without whitespaces is already an OOP-like notational convenience in order to denote Modules and their elements in Haskell.

OOP:

• Prelude.length("Hello") (static function length of class Prelude applied to "Hello")

Haskell:

• Prelude.length("Hello") (function length of module Prelude applied to "Hello")

This means, that a distinction between . (with whitespaces) and . (without whitespaces) is already been made, which is why Just . Just $ 42 compiles, whereas Just.Just $ 42 doesn't. Analogously, with this Feature Request implemented, "Hello".map(succ) would compile whereas "Hello" . map(succ)" wouldn't.

Current dot-notation for modules (not to be changed):

• Foo.bar (bar of module Foo)

Proposed dot-noation for function application:

• foo.bar (function bar applied to foo)

changed weight to 5

added Tfeature request Trac import labels

changed title from Dot-Notation for Function Application to Dot-Notation for Flipped Function Application

This is definitely a request that should go through GHC's proposal process.

I don't even think this should go into the proposal process. The Foo.Bar.baz notation has nothing to do with OO, it is just about hierarchical names, which is a lexical issue. Furthermore, apart from the offside rule, whitespace should not have a meaning at all. Another complication/quiz: What should Foo.bar mean at all then? The hierarchical name Foo.bar or bar Foo (flipped application of the function bar to the constructor Foo)? It can't be the latter, otherwise hierarchical names wouldn't work, so in addition to one exception to the language (whitespace matters) it would introduce another exception (. means something different if things look like a hierarchical name).

Replying to [ticket:14812#comment:149081 bgamari]:

This is definitely a request that should go through GHC's proposal process.

Sorry and thanks for the hint. What's the difference between GHC proposals and feature requests? Or where to find a FAQ that answers that? Thanks in advance!

Replying to [ticket:14812#comment:149085 svenpanne]: Your premise is that whitespaces do or should only matter for indentation ("offside rule"), but they do matter as I pointed out, exactly when it comes to modules and the . syntax: Foo . bar is function composition of constructor Foo and function bar, whereas Foo.bar is bar of module Foo. The aim of my proposal is not to change that.

Current dot-notation for modules (not to be changed):

• Foo.bar (bar of module Foo)

Proposed dot-notation for function application:

• foo.bar (function bar applied to foo)

Replying to [ticket:14812#comment:149085 svenpanne]: Side note: Prelude.length("Hello") in an OOP language is likely to refer to a (static) method length of class Prelude applied to "Hello", hence my wording "OOP-like". Thanks for pointing it out.

changed the description

Just to reiterate a few points:

The fact that Foo.bar is a single entity is a lexical issue, as you can see in the Haskell report (https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17700010.2, look for modid). Of course whitespace is relevant on that level. The initial proposal (https://mail.haskell.org/pipermail/libraries/2001-February/000258.html) already mentions that this syntax effectively steals some syntax with previously different semantics, but the consensus was that this is not nice, but OK: Hierarchical names are a big win and chaining constructors with dots but without whitespace was considered sufficiently rare.

Your proposal would steal yet another syntax and give it completely different semantics for a very low benefit: foo.bar is currently semantically equivalent to foo . bar, and you propose to change that to bar $ foo. I bet this will break lots of code, and one should have a very, very good reason to do that. Emulating some surface syntax from a different programming paradigm is not really enough for that.

Furthermore, you would introduce syntactic ambiguity for Foo.bar, because one can't distinguish module names and constructor names on the lexical level. This needs to be resolved to the meaning "hierarchical name", but obscure, non-regular things like this are warts in any language design, so plesase let's not do this.

Replying to [ticket:14812#comment:149093 svenpanne]: I cannot argue with historical consensus and what is and isn't a "very, very good reason"/"warts in language design". So, if it's going to be "let's not do this", then "meh" it is.

Concerning breaking old code, a language pragma {-# LANGUAGE FlippedFunctionApplicationDot #-} might provide the necessary backward-compatibility.

But, so far, I haven't seen Haskell code with the dot-operator without white-spaces. It seems to be consensus (or at least advisable) to use the dot-operator with whitespaces, and to leave . without whitespaces only for module access.

Thanks for the links, though. Maybe they will help me understand why, on a "lexical level" Foo.bar would cease to be unambiguously parsed as "bar of module Foo" once foo.bar would be parsed as "bar applied to foo".

In my opinion, given that we have the ghc-proposals process now, I don't think we should have "Feature Request" tickets in Trac. Regardless, I do encourage you, @tepan, so post a proposal if you're keen on this. This debate is better there, where more eyes will see it.

Replying to tepan:

Please allow to put a dot . (without whitespaces) between two things for flipped function application. This could make for code in pseudo-OOP style:

Great idea! It's been suggested many times, including by SPJ https://prime.haskell.org/wiki/TypeDirectedNameResolution; and especially to represent field application to a record or struct, similar to OOP https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix.

Sadly, it was shot down in flames; because it seems there's lots of code using dot as function composition not surrounded by whitespace -- for example, it's a common idiom with lenses.

But I think worth asking again. As others have said, please submit a proposal on github.

There's plenty of historical discussion about this; wiki link in ticket:14812#comment:149104 is a good starting point. Personally, I think that something like this would be very attractive for writing pipelines of computation.

One particularly attractive possibility is using type inference to drive auto-complete and drop-down menus of possibilities. IDEs for OO languages use this to tremendous effect.

There's an old paper The power is in the dot which I have not reviewed recently but remember enjoying some years ago.

Definitely a GHC-proposal suggestion though.

It would surely be controversial.

added Pnormal label