Uni pipe chaining for imperative APIs

[chenglou]

let mySet = Set.make();
mySet |. [
  Set.add(1),
  Set.add(2),
  Set.remove(1),
];

This feature was held back due to being overly magical and due to |. still being new. Upvote this issue if you'd like to see it re-released.

[bobzhang]

note [ ] would cause some ambiguity, [| |] is preferred implementation wise. It would be simplified as:

mySet |. Set.[|
   add 1 ; 
   add 2 ;
   remove 1
|]  

[chenglou]

What's the ambiguity of []?

[bobzhang]

$ bsc -dparsetree -bs-syntax-only -bs-eval '[1;3]'
[
  structure_item (//toplevel//[1,0+0]..[1,0+5])
    Pstr_eval
    expression (//toplevel//[1,0+0]..[1,0+5])
      Pexp_construct "::" (//toplevel//[1,0+1]..[1,0+5]) ghost
      Some
        expression (//toplevel//[1,0+1]..[1,0+5]) ghost
          Pexp_tuple
          [
            expression (//toplevel//[1,0+1]..[1,0+2])
              Pexp_constant Const_int 1
            expression (//toplevel//[1,0+3]..[1,0+5]) ghost
              Pexp_construct "::" (//toplevel//[1,0+3]..[1,0+5]) ghost
              Some
                expression (//toplevel//[1,0+3]..[1,0+5]) ghost
                  Pexp_tuple
                  [
                    expression (//toplevel//[1,0+3]..[1,0+4])
                      Pexp_constant Const_int 3
                    expression (//toplevel//[1,0+4]..[1,0+5]) ghost
                      Pexp_construct "[]" (//toplevel//[1,0+4]..[1,0+5]) ghost
                      None
                  ]
          ]
]

the [ ] is already de-sugared in the parsetree

[chenglou]

cc @jaredly this was the feature I was talking about

[justgage]

I really like this! Admittedly I think people should just you immutable data structures but when that's not an option then this is sweet.

[chenglou]

Yeah, the goal is not to make the performant paradigm unnecessarily harder.

[jaredly]

so fancy

[justgage]

Good point @chenglou.

I thought about this a little more and it would be easy enough to just define this in plain code:

let (|..) = (obj: 'a, lst: list('a => unit)) : unit =>
  Belt.List.forEach(lst, fn => fn(obj));

let a = Stack.create();

a
|.. Stack.[
      push(1),
      push(2),
      s => pop(s) |> ignore,
      push(3),
      iter(Js.log),
    ];

Runnable example: https://reasonml.github.io/en/try.html?rrjsx=true&reason=DYUwLgBAFAPgdHAlBAvNA9gIwFYC4IDkAhgDQTADOY+wAllVMagHwQCuAdrWIsvp9xYAoCBABCIYGDgAZetIBm6AE4BRIgGMAFlEpgyCjiwiGoWbLwDcQoaEhFUEAMphNAazgblIImBBREayEiIXg4Z1cNDwBtEVF4gAc2Ch0ARkQSOPiIJJSoACYMrPiKYwT0BKgKZBhWWgBzDhUQTOzRXJ0AZiK2iG4QZSgAKQo4YHR6nviAXWsgA

Pros:

1. No compiler differences
2. No giving people false hope for writing their own polymorphic operators (can be run on tuples or on arrays or etc..)

Cons:

1. There's a different operator for each thing (tuples, list, etc...)

Another option might be to just define a function on Belt rather than an operator. Not sure where it would live.

[chenglou]

@justgage this undoes the performance benefits. See the generated code. This pipe operator is specifically syntax and not just a function. Additionally, function doesn't compose with other non-function things. A syntax-level pipe does: a |. Some.

[justgage]

Ah very good point @chenglou. I forgot about that benefit!

[SllyQ]

Correct me if I'm wrong, but given that this is a thing.
let (left, middle, right) = myData |. (getLeft, getMiddle, getRight)
I think you could just do

let mySet = Set.make();
let _ = mySet |. (
  Set.add(1),
  Set.add(2),
  Set.remove(1),
);

Maybe that could be good enough?

[chenglou]

Yeah, though that leaves a tuple in the output

[SllyQ]

Yeah, it does, that's why I ignored it. I guess it introduces some room for mistakes. Maybe it would be possible to do so that if you use fast pipe with a tuple of functions and they all return units you don't have to ignore them? I think it would be a win in terms of consistency and less syntax to learn.

[chenglou]

You mean like this? https://reasonml.github.io/en/try.html?rrjsx=true&reason=PYBwpgdgBAQmA2AXA3AKFfMioFsCeAyllALxQCyArogIYBGmRiAdAJIQs40DWYAFAEo0GYn0EAaKBKkCBpVFFyEsCqAB9mU1Yqq0GYJmw7MaAE1N8AjAPHaK1eoyxGWZiwCYbd3Y4PP2LABOYDjAAG781raKQqhAA

[SllyQ]

I was thinking just doing like this https://reasonml.github.io/en/try.html?rrjsx=true&reason=PYBwpgdgBAQmA2AXA3AKFfMioFsCeAyllALxQCyArogIYBGmRiAdAJIQs40DWYAFAEo0qfE1QAfZlD6ooFavUZY2HZjQAm6vgEYBAGlnzaDMExUsNWgEz7DVY0pbsWAJzA5gAN366DQ1EA

Thought that would give a warning, but it doesn't seem to do so.

[bobzhang]

this could be optimized, but when I read tuple, in general, I don't assume evaluation order, it is not the case for semicolons though

[SllyQ]

Well the semicolon argument applies only to ocaml so I'm not sure if we want to get too attached to that. And in general I think the expectation is that code executes from left to right and top to bottom (at least for me) so I think it should be ok. Or am I incorrect in assuming such evaluation order in ocaml / reason?

[ELLIOTTCABLE]

I'm confused as to why this is necessary — isn't this what the chained imperative statements already do? i.e. the semicolon in OCaml-syntax?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.