Comments (12)
To add some color for my own stance: I prefer C because I like to distinguish compositional pipelines (f . g . h
) from application pipelines (f $ g $ h x
). In other words, if an expression is pointful, it should be (simple) applications all the way, not an (unnecessary) applied composition, which is just a hair more complex to my brain. Totally subjective, but that's why.
from guides.
For some reason GitHub notifies me about new issues on this repo. And I can't help but comment on Haskell style questions 😆
I like style A because it's tied for the fewest number of operators and I find (.)
much easier to visually parse than ($)
. However it can be really annoying to refactor that style because changing the number of functions involved can require changing a few operators; looking at things from that angle, style C seems like the best choice.
from guides.
I prefer C now, but I used to prefer E
E
f (g (h x))
Which probably means I can learn to prefer anything.
from guides.
For some reason GitHub notifies me about new issues on this repo
hiiii @tfausak 👋. I'm happy to see you chime in, but let us know if you want us to stop pinging you, should be easy to fix 😛
from guides.
Oh I'm sure I could find the setting to toggle, but I like these discussions. I've been trying to whittle away at our own style guide. Case in point: EdutainmentLIVE/haskell-style-guide#37
from guides.
I prefer A (f . g $ h x
)
- This uses the number of operators as C
- In general, I prefer function composition over application
I should also note that I don't mind if these styles are mixed. They're all acceptable to me (except D, but I think hlint will complain about that)
from guides.
I use all of them depending on context and intent. I'm 👎 on having this in a style guide.
from guides.
I'm genuinely curious what intents/contexts would lead you to using either of these equivalent forms over others. Can you expand on that?
from guides.
If I want something to feel "pipeline-y", like I'm doing a lot of complex operations in a row, I tend to use .
a lot. If I just want to do a couple operations on something, like head $ take 2 $ [1, 2, 3, 4]
, I might just use $
.
To be honest I don't have a nice, consistent rule for when I use one or the other because I don't think about it too much. I've seen all of these styles used and I don't think any one of them really has an advantage over the others since it is pretty clear what is going on.
from guides.
I don't think any one of them really has an advantage over the others
Just to be clear, no one is saying that's the case. It's just about consistency, and having a simple answer for people ramping up when they ask about how to write things.
from guides.
I prefer A
from guides.
Also a 👎 on a style guide for this.
from guides.
Related Issues (14)
- Operator-first / Applicative HOT 15
- Blank line between extension and module HOT 6
- default-extensions rule HOT 26
- Haddock paragraph whitespace HOT 15
- Brittany HOT 27
- Handlers Naming Conventions HOT 16
- Add StrictData to default-extensions HOT 22
- Use prettier-markdown? HOT 1
- Link vs Location HOT 10
- Mention MS API Guidelines
- Update response body Guides for API Types HOT 1
- Formalize PATCH Semantics for Sub-Resources HOT 3
- fomatting typo in best-practies HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from guides.