Piped variable clobbers existing `_` variable

[qqueue]

_ = require \underscore
thing.create! |>
  _.foo!

_.map [1,2,3] -> it.toString! # probably won't work

var _;
_ = require('underscore');
_ = thing.create();
_.foo();
_.map([1, 2, 3], function(it){
  return it.toString();
});

Possible solution: attempt make actual compiled variable unique in the scope:

var _, _$x;
_ = require('underscore');
_$x = thing.create();
_$x.foo();
_.map([1, 2, 3], function(it){
  return it.toString();
});

[satyr]

Isn't it suboptimal to leave you unable to use the outer _ within pipes, still nudging you to use a different name for require \underscore and such.

The sole point of our pipe is being an extremely light sugar (|> ⇔ _=), using the semi-reserved approach (same as it etc.) to make the compilation as straight-forward as possible. Your partial-clobbering approach makes it slightly deviate from the point.

[goto-bus-stop]

I think & would be a good sign for this too, it's obviously consistent with how cascades use it, and one could think of a pipe as a single-expression cascade (that returns the result of the expression). Then a pipe's ~the same as expr then cascade. (|> converting a single expression into a cascade block, essentially)

Or the other way around, a cascade being a multiline pipe, returning the subject: expr |> (block); expr, whichever way is easier to implement.

Still a light sugar (|>; & <=> x$ =; x$) and it unifies pipes and cascades (which serve a similar purpose, right?)

[qqueue]

Good point on the similarity with that and it, but _ still feels different, since it's not a word; it's just a short identifier--that also happens to be a valid js identifier--used to refer to the left hand side of the pipe. The purpose of |> is not sugar for _ =; that's just the implementation.

Now that & works in more places, it's probably better, both for the fact that it doesn't clobber any identifiers, and that it's more consistent with cascade, as @renekooi says.

box =
  $ \my-img |> Math.max &width, &height |> [&, &]

[satyr]

a cascade being a multiline pipe, returning the subject: expr |> (block); expr

Sounds like a better approach/analogy. We can then call & reference rather than cascadee or pipee.

The purpose of |> is not sugar for _ =

It sure was (#90). I wanted to see if such seemingly pointless sugar could prove to be useful. Maybe time to go right than light now that it has users.