Alexander Berntsen wrote

First of all, I don't like magic built-in stuff. And this certainly is just that. It requires a higher precedence than you can possibly give in regular code, and it is an exception to how all other operators work with regards to requiring no spaces (note that this is different to "not requiring spaces") -- this is reserved for module namespaces per now.

Indeed, this is intended to be syntactically the same as dot-for-module-namespaces rather than an operator. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

I'm a strong -1. This already exists as an operator anyway: http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht ml#v:-38- On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese" wrote:

+1

I'm convinced that this proposed extension would be extremely natural and practical if we give it a chance. The fact that it may conflict with previous, less natural syntax choices (lens composition with . comes to mind) should not be counted against an opt-in extension. Lens packages could easily provide an alternative notation for their . for when the extension is enabled.

Regards, Dominique

2015-11-04 11:44 GMT+01:00 Jeremy :

...

Dot as Postfix Function Apply

(https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5 VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= ) was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax.

The idea is that instead of

(title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person)

we could have

person.title ++ " " ++ person.firstName ++ " " ++ person.lastName

This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are:

1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing .

This would be an opt-in extension.

I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it.

-- View this message in context: https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W 70W4uY&e= Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi- 2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD 0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=

---

Libraries mailing list Libraries@haskell.org https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2 Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T 3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=

This has been proposed before and rejected before on many separate occasions. (.) already has a complicated enough role in our lives being used for qualified names as well as composition. Just.Just already doesn't parse as you'd expect due to its double-life. Giving it a third job breaks every f.g out there in user code and actively worsens systems that already exist for this purpose that compose better. I remain strongly in the -1 camp. -Edward On Wed, Nov 4, 2015 at 1:57 PM, Andrew Gibiansky

wrote:

I'm not on either side of this fence yet, but keep in mind that this can't just be done with an operator, because, if I understand the proposal correctly, the proposed dot hack would have a precedence *higher* than function application.

That is, code like

print person.name

would desugar to

print (name person)

and not to

name (print person)

This is something that can't be replicated with current Haskell and is the crux of the issue, I think.

As Chris Done said, "All of this because Haskellers are allergic to parentheses." (A true comment, if perhaps one I maybe don't agree with)

-- Andrew

On Wed, Nov 4, 2015 at 10:28 AM, Andrew Farmer wrote:

...

I'm a strong -1. This already exists as an operator anyway:

http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht ml#v:-38- http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.htm...

On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese" wrote:

...

+1

I'm convinced that this proposed extension would be extremely natural and practical if we give it a chance. The fact that it may conflict with previous, less natural syntax choices (lens composition with . comes to mind) should not be counted against an opt-in extension. Lens packages could easily provide an alternative notation for their . for when the extension is enabled.

Regards, Dominique

2015-11-04 11:44 GMT+01:00 Jeremy :

...

Dot as Postfix Function Apply

( https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra

...

...

c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5

...

...

VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= ) was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax.

The idea is that instead of

(title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person)

we could have

person.title ++ " " ++ person.firstName ++ " " ++ person.lastName

This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are:

1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing .

This would be an opt-in extension.

I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it.

-- View this message in context:

https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na

...

...

bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm

...

...

l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH

...

...

H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W 70W4uY&e= Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-

...

...

2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD

...

...

0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=

---

Libraries mailing list Libraries@haskell.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2

...

Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T

...

3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=

_______________________________________________ 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

Edward Kmett-2 wrote

Just.Just already doesn't parse as you'd expect due to its double-life. Giving it a third job breaks every f.g out there in user code and actively worsens systems that already exist for this purpose that compose better.

The proposal actually removes .'s ambiguity by defining syntactically whether it's an operator (surrounded by spaces) or namespace/postfix (without spaces). It will only break existing code if you turn on the extension for it. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

print (name person) person.^name & print Sorry, I'm not seeing the disaster yet. On Nov 4, 2015 2:40 PM, "Harry ." wrote:

When you consider that every other programming language in common use (and almost every language not in common use as well) allows you to write:

print person.name

while Haskell requires something like:

print (person & name) or

print $ person.^name

and even that after importing a third-party library or defining it yourself, you begin to understand why beginners think that Haskell looks more like Japanese emoticons than programming.

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

Is it confusing to newcomers that (.) doesn't bind tighter than ' ' in haskell? Sure. But causing that to randomly change back and forth is more confusing still.

It already does randomly change back and forth though, due to module syntax. With the proposed option turned on, the change seems *less* random to me, being solely based on whitespace and not *also* based on whether the LHS is a module name. -- Dan Burton On Wed, Nov 4, 2015 at 12:20 PM, Edward Kmett wrote:

Precedence and syntax in a language tells you a lot about what the language considers important. We take the 'quietest' syntax for things that we want to have fade into the background. Whitespace and periods are both very quiet syntax.

In math ' ' is often multiplication, in the lambda calculus it is function application.

We choose ' ' to have the tightest precedence in Haskell in a way that nicely emphasizes the importance of functions here. Admittedly we already have two awkward exceptions there that routinely throw folks for loops. @ syntax in patterns and the {}'s used by record syntax both bind tighter than whitespace application.

We choose . for function composition a.) because it on the keyboard and again, it emphasizes the importance of functions. Functions compose and you can make more interesting things out of the parts, the field accessor syntax you propose here does not compose particularly well.

With other solutions available today that this proposal actively makes worse, I can both read and write back to those fields

You're asking for (.), one of the most common symbols in Haskell code today to take on another meaning, furthering confusion for its current standard role, for it to effectively alternate binding looser than ' ' when you put spaces around it to tighter than ' ' when you don't while simultaneously changing semantics entirely.

Is it confusing to newcomers that (.) doesn't bind tighter than ' ' in haskell? Sure. But causing that to randomly change back and forth is more confusing still.

-Edward

On Wed, Nov 4, 2015 at 2:40 PM, Harry . wrote:

...

When you consider that every other programming language in common use (and almost every language not in common use as well) allows you to write:

print person.name

while Haskell requires something like:

print (person & name) or

print $ person.^name

and even that after importing a third-party library or defining it yourself, you begin to understand why beginners think that Haskell looks more like Japanese emoticons than programming.

_______________________________________________ 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

2015-11-05 9:21 GMT+01:00 Jules Bean :

...

The fact that it may conflict with previous, less natural syntax choices (lens composition with . comes to mind) should not be counted against an opt-in extension.

Lens composition with (.) is not really a syntax choice - Lens composition with (.) is simply function composition with (.) which is a fairly deeply-set Haskell choice. I can see arguments against using (.) for function composition but I don’t think anyone would seriously consider changing that now: and Lens composition will always have the same syntax as function composition.

It just so happens that Lens composition with (.) gives us the ability to write person^.job.title which is one of those nice coincidences which looks a bit like C-style object dereference.

This coincidence is nice because it approximates expectations from other languages. Unfortunately, this approximation breaks down quickly in only slightly more complex cases like `func person^.job.title`, "person^.someFuncProperty someArgument" and doesn't extend to writing `person.job.title`, leading (imho) to confusion and an unnatural feel. Also, I'm not sure why there's a "vote" about this now. As someone already mentioned, no community approval is needed to *first* implement it in some way (perhaps using ghc-reskin as suggested by someone), experiment with it and see if it makes as much sense as some of us expect. Regards, Dominique

-1, making (foo.bar) =/= (foo . bar) seem plain evil to me. It's already bad enough that module namespace selection syntax clashes with function composition. Best regards, Marcin Mrotek

On Wed, Nov 4, 2015 at 2:41 PM Dan Burton wrote:

+1, it's no worse than module syntax, and it's opt-in.

I suppose my vote bumps it up from -1000 to -999. /shrug

Dot as postfix function application is frankly a great idea that exists in many many languages. It's great for intellisense and it's often great for reading code left to right. It may not be the best fit for Haskell, but Haskell has never been one of those "one right way to code" sort of languages.

This isn't about dot as postfix function application. You can already do that: import Prelude hiding ((.)) a . f = f a main = 23 . print This is about changing the syntax of the language to make it more comfortable to people coming from OO languages, in particular mimicking the way most of those languages select features from an object. The syntax change is making dot without spaces bind tighter than function application so you can say "print object.element" instead of having to say print (element object)" or "print $ element object". Alexander Berntsen suggested adding a new fixity so you could declare operators that bind tighter than function application. That would let you write "print object . element" by declaring the fixity of "." to be that new fixity. Since such a change doesn't break any existing code, it doesn't need to be an extension that's enabled. It's a need I've felt every so often myself. -1. Once you get past wanting to write OO code in Haskell, this itch should go away. I think it would be like all the "OO in haskell" libraries that newcomers write, then quit using once they get past that desire. At the very least, make this a general change, so that name<op>name without spaces binds tighter than functions, so it's useful for more than writing code that looks like Pyhton/C/C++/etc.

The library committee does not generally have any formal authority over or involvement in language extensions or language changes. I would argue this entire discussion should probably have taken place elsewhere (e.g., haskell-cafe or ghc-devs). That said, the library gurus likely do have some sense of how much you're likely to gain by adding such an extension. While I'm writing this message, I think I might as well try to explain a bit better why I think the proposed extension is a bad idea. In a procedural language, the field dot is an all-purpose way to narrow focus from a record or object to a field or method. In C, the following all make sense (I think--my C is rusty). foo = fish.dog (fish.cat) + 4 fish.cat = 12 fish.cat += 17 shark = &fish.cat In Haskell, only the first usage is sensible. Once the hypothetical .cat is applied, the fish is out of the picture. Lenses, on the other hand, offer sensible ways to talk about functional approximations of all of these things. I believe a syntactic extension making lenses easier to use could be a big win, but the current proposal just makes easy things easy, which they already are. Others have, correctly, mentioned the use of . in the module system as justification. This is sensible, since modules look a bit like records if you squint enough. But I think most Haskellers will agree that they'd rather see modules look more like records than the other way around. On Nov 4, 2015 7:20 PM, "Greg Weber" wrote:

+1 for an opt-in extension. I am not sure if any approval is needed from the libraries committee for an optional extension like this if you are willing to do the work to bring it to fruition yourself.

On Wed, Nov 4, 2015 at 2:44 AM, Jeremy wrote:

...

Dot as Postfix Function Apply ( https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields... ) was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax.

The idea is that instead of

(title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person)

we could have

person.title ++ " " ++ person.firstName ++ " " ++ person.lastName

This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are:

1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing .

This would be an opt-in extension.

I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it.

-- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ 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