Is there a reason the pipe operator doesn't allow spaces?

1

I’m just wondering what the reasoning is for formatting pipe operations like this

let result = name->preprocess->Some

person
  ->parseData
  ->getAge
  ->validateAge

instead of this

let result = name -> preprocess -> Some

person
  -> parseData
  -> getAge
  -> validateAge

As well not liking it aesthetically, I find it impairs readability and is inconsistent with other operators in the language. Not to mention just about every other language I’ve seen with such an operator.

3 Likes
2

I think one of the reasons behind that is that ReScript, being an OCaml follower, has a pretty dense formatting. Denser than the default Prettier style, and way denser than, say, Elm. Also, one thing I might never get used to is 2 spaces indentation (especially since I prefer narrow fonts like PragmataPro or Iosevka).

That said, I don’t think the examples in your post do the fast pipes any justice. With ligatures and proper syntax highlighting it doesn’t look half as bad:

image

As for consistency, it kinda makes sense actually, because the fast pipe is not quite an operator. It’s syntactic sugar for nested function calls, plain and simple, and function calls don’t have any spaces either.

1 Like
3

Think of it like C, Perl, etc. accessor operators. Not a normal binary operator. In C you wouldn’t write record -> field either. It’s meant to ‘look like’ a fluent access style from OOP languages.

4

That said, I don’t think the examples in your post do the fast pipes any justice. With ligatures and proper syntax highlighting it doesn’t look half as bad

As for consistency, it kinda makes sense actually, because the fast pipe is not quite an operator. It’s syntactic sugar for nested function calls, plain and simple, and function calls don’t have any spaces either.

Both of these seems more like post-hoc rationalizations. I don’t think that when it comes to deciding how a language should be formatted, the use of syntax highlighting and ligatures (which most devs don’t use) should be relied upon. I’d say the language should be optimised for readability without those assumptions.

Regarding the second point - it may be the case that pipe is syntactic sugar, but it is still an operator within the language

5

It’s meant to ‘look like’ a fluent access style from OOP languages

Surely if the lack of spaces makes ReScript’s pipe look like member access operators in other languages, then that’s all the more reason to change it? Seeing as pipe is an FP operator

1 Like
6

The pipe-first operator is not really an ‘FP operator’ in the traditional sense. It’s not a functional you could define yourself like other operators. It’s a syntax sugar–it’s baked into the syntax of ReScript. It is intended to look like member access. For example, you wouldn’t write member access in an OOP language like obj . field, right?

4 Likes
7

The pipe does technically allow spaces. You can put as much white space as you want around it and it will compile just fine. The formatter is what removes them.

And like @yawaramin said, it’s not actually an operator/function. (Although it seems similar to a function). It’s part of the language syntax, kind of like how . is used for record field access.

I don’t have any personal opinion about whitespace around ->, but there have been other requests for adding options to the formatter, which currently can’t be configured at all. This issue could be raised in the syntax repo.

4 Likes
8

I agree with you here. The choice of this operator to make it “look like OOP access” does not feel amazing to me. The pipe |> would have been less confusing…

I also don’t understand why an infix operator that does f(a,b) = b(a) should look like member access… :face_with_peeking_eye: