3 ms·

In my eyes newlines don't solve what I feel to be the issue. Reader needs to recognize reading from left->right to right->left. Of course this really only matt

In my eyes newlines don't solve what I feel to be the issue. Reader needs to recognize reading from left->right to right->left. Of course this really only matters when you're 25 minutes into critical downtime and a bug is hiding somewhere in these method chains. Anything that is surprising needs to go. IMHO it would be better to set intermediate variables with dead simple names instead of newlines. fn get_ids(data: Vec<Widget>) -> Vec<Id> { let iter = iter(data); let wingdings = map(iter, |w| w.toWingding()); let alive_wingdings = filter(wingdings, |w| w.alive); let ids = map(alive_wingdings, |w| w.id); let collected = collect(ids); collected }

trealira 2y ago
> Reader needs to recognize reading from left->right to right->left. Yeah, I agree. The problem is that you have to keep track of nesting in the middle of the expression and then unnest it at the end, which is taxing. So, I also think it could also read better written like this, with the arguments reversed, so you don't have to read it both ways: fn get_ids(data: Vec<Widget>) -> Vec<Id> { collect( map(|w| w.id, filter |w| w.alive, (map(|w| w.toWingding(), iter(data))))) } That's also what they do in Haskell. The first argument to map is the mapping function, the first argument to filter is the predicate function, and so on. People will often just write the equivalent of: getIDs = map getID . filter alive . map toWingDing as their function definitions, with the argument omitted because using the function composition operator looks neater than using a bunch of dollar signs or parentheses. Making it the second argument only makes sense when functions are written after their first argument, not before, to facilitate writing "foo.map(f).filter(y)".
- RHSeeger 2y ago
  The argument ordering Haskell (and, I think, most functional languages) uses is definitely simpler to read. It keeps the components of the tranformation/filter together.
- matt_kantor 2y ago
  I've been prototyping a programming language[0] with Haskell-like function conventions (all functions are unary and the "primary" parameter comes last). I recently added syntax to allow applying any "binary" function using infix notation, with `a f b` being the same as `f(b)(a)`[1]. Argument order is swapped compared to Haskell's infix notation (where `a f b` would desugar to `f(a)(b)`). Along with the `|>` operator (which is itself just a function that's conventionally infixed), this turns out to be really nice for flexibility/reusability. All of these programs do the same thing: 1 - 2 - 3 + 4 1 |> -(2) |> -(3) |> +(4) +(4)( -(3)( -(2)(1) ) ) It was extremely satisfying to discover that with this encoding, `|>` is simply an identity function! [0]: https://github.com/mkantor/please-lang-prototype https://github.com/mkantor/please-lang-prototype [1]: In reality variable dereferencing uses a sigil, but I'm omitting it from this comment to keep the examples focused.

trealira 2y ago

> Reader needs to recognize reading from left->right to right->left. Yeah, I agree. The problem is that you have to keep track of nesting in the middle of the expression and then unnest it at the end, which is taxing. So, I also think it could also read better written like this, with the arguments reversed, so you don't have to read it both ways: fn get_ids(data: Vec<Widget>) -> Vec<Id> { collect( map(|w| w.id, filter |w| w.alive, (map(|w| w.toWingding(), iter(data))))) } That's also what they do in Haskell. The first argument to map is the mapping function, the first argument to filter is the predicate function, and so on. People will often just write the equivalent of: getIDs = map getID . filter alive . map toWingDing as their function definitions, with the argument omitted because using the function composition operator looks neater than using a bunch of dollar signs or parentheses. Making it the second argument only makes sense when functions are written after their first argument, not before, to facilitate writing "foo.map(f).filter(y)".

RHSeeger 2y ago
The argument ordering Haskell (and, I think, most functional languages) uses is definitely simpler to read. It keeps the components of the tranformation/filter together.
matt_kantor 2y ago
I've been prototyping a programming language[0] with Haskell-like function conventions (all functions are unary and the "primary" parameter comes last). I recently added syntax to allow applying any "binary" function using infix notation, with `a f b` being the same as `f(b)(a)`[1]. Argument order is swapped compared to Haskell's infix notation (where `a f b` would desugar to `f(a)(b)`). Along with the `|>` operator (which is itself just a function that's conventionally infixed), this turns out to be really nice for flexibility/reusability. All of these programs do the same thing: 1 - 2 - 3 + 4 1 |> -(2) |> -(3) |> +(4) +(4)( -(3)( -(2)(1) ) ) It was extremely satisfying to discover that with this encoding, `|>` is simply an identity function! [0]: https://github.com/mkantor/please-lang-prototype https://github.com/mkantor/please-lang-prototype [1]: In reality variable dereferencing uses a sigil, but I'm omitting it from this comment to keep the examples focused.