Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Piped variable clobbers existing `_` variable #181

qqueue opened this Issue · 4 comments

3 participants

_ = require \underscore
thing.create! |>! [1,2,3] -> it.toString! # probably won't work
var _;
_ = require('underscore');
_ = thing.create();;[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();
_$;[1, 2, 3], function(it){
  return it.toString();
@qqueue qqueue referenced this issue from a commit in qqueue/coco
@qqueue qqueue Add test for pipe not clobbering `_`, issue #181 5d7ed79
@qqueue qqueue referenced this issue from a commit in qqueue/coco
@qqueue qqueue Unclobber `_` inside pipes, fix #181
Node#pipe is factored to as separate class Pipe.

The pipee `_` in coco is compiled to `_$`, using `o.scope.temporary \_`.

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.


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?)


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 |> [&, &]

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.

@satyr satyr closed this in ee47572
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.