Is there a pipeline operator that can run forms about racket-rash HOT 8 CLOSED

Yes, though I want to improve its name.

=basic-object-pipe/expression= (+ 5 6) -- this is like your bottom example.

=basic-object-pipe/form= + 5 6 -- this is like your top example.

I don't think I really like the /form one. Both need better names. Also all of the basic- ones do no implicit transformation of their argument, whereas if you take basic- out of their names they automatically transform ports to strings. I regret that convention now.

But another note I would make is that cd is implemented as a line macro, and other cd-like things should be too. I'm not sure if I've documented it well (I should check), but everything in a pipeline is executed in a different thread, and any parameter modifications will not be seen in the original thread. So I wholeheartedly recommend making ../.. macros, make them as line macros rather than pipeline operators.

from racket-rash.

Oh, that makes sense, I was wondering why I wasn't getting any errors but the wd wasn't changing. So essentially aliases are for pipes, and line macros are for more shell specific things?

from racket-rash.

Line macros are a general way to make a line mean anything. The run-pipeline macro that does the pipelining is itself a line macro. Pipeline operators are macros with meaning only in the pipeline DSL implemented with run-pipeline. Aliases are... an extra level implemented by some pipeline operators (currently just =unix-pipe=) that add an extra level of indirection that isn't really necessary, but feels more like aliases that people expect from eg. Bash. Basically aliases let a pipeline operator defer to a different pipeline operator instead -- any alias could be implemented as a pipeline operator instead.

So aliases are sort of stupid, but kind of nice, pipeline operators make pipelining more powerful, and line macros let you do anything, of which pipelining is just one example.

from racket-rash.

for things like making ls mean ls --color=auto, are aliases the right choice? Or would you recommend implementing them as pipeline operators or line macros?

from racket-rash.

I would use an alias. cd is just special in this respect.

from racket-rash.

As some more concrete examples of line macros:

demo/setup.rkt has a line-macro called in-dir that executes its body inside a given directory (but that is back in the original directory when it is done). You can give it a list or a glob that matches multiple times and it automatically loops over them:

in-dir /tmp {
  echo I am in:
  pwd
  ;; it would print that it is in /tmp
}

You can make all sorts of forms that have multiline bodies with that pattern -- control flow, parameterization forms, function definitions, error handling, etc.

You could also make a different line-oriented language. Eg demo/infix-math.rkt includes an infix math line macro, so you can write:

infix-math 5 * (3 + 4) ;; returns 35

So you could make a language that acts entirely differently than normal Racket or pipelining.

(This example is maybe a little silly, and I made it mostly so I could do quick calculator-type math in my shell. The real thing I use from the infix math demo package is the =unix-or-infix-math= pipeline operator, which auto-detects math based on whether the form in command position is a literal number. Poor heuristic, perhaps, but convenient enough for my purposes.)

Another important point of line macros is that you can set the default (for the top-level or for a region of code). So you can have a region of code that changes the language implicitly. For instance there is a make replacement demo that does this -- at the top level of the module it sets the default line macro to be one for specifying build targets, but that line macro sets the default within its body (IE for the build recipe) to be run-pipeline.

from racket-rash.

Wow that's pretty cool. You can set the default pipeline to =infix-math= to do some math then change it back when you wan't a normal shell. People can make their own pipeline operators to streamline whatever they want to do and switch between them.

So, if I understand correctly, rash uses linea as it's reader, and sets the #%linea-default-line-macro to run-pipeline. Then run-pipeline sets it's default pipeline to =unix-pipe=. So essentially if you type a line macro in the repl, linea will use that instead of run-pipeline, and if you type a pipeline operator in the repl, linea will use run-pipeline, and run-pipeline will use the pipeline operator you typed instead of =unix-pipe=.

Sorry for all the questions when you're out of town, but I guess my final question would be: Do pipeline operators have the same power as line macros? Because it seems like your =infix-math= pipeline basically acts like an infix math dsl. It also has the added benefit of being able to interface with other pipelines because it's part of run-pipeline. It seems like pipeline operators have all the power of line macros and then some, at least in terms of writing mini-DSL's like =infix-math=.

from racket-rash.

They can often do the same things, in which case it may be better to have it in a pipeline operator. For instance, =infix-math= the operator is the one I actually use, not the infix-math line macro. But there are some things you can do with line macros that you can't with pipeline operators. For instance, you can make definition forms with line macros, but not with pipeline operators (a pipeline operator could include local definitions [both in its use-site and as part of the macro template], but it can't create definitions visible outside of the pipeline segment). In most cases line macros are probably what you want for flow control, error handling, etc (though not always -- eg. you may want pipeline operators to loop over something or contain errors somehow...). Also they are more suitable for many weird macro-y things. For instance the make demo language uses a make-target line macro that builds an expansion-time list of available targets which is then used to generate a command-line form that accepts targets to build and lists them when it gets the --help flag.

Maybe a good way to sum up is that line macros are a more general language building tool for line-oriented languages, while pipeline operators are more useful for customizing shell-style code. If you are staying in the realm of shell-style stuff (with a few exceptions like cd), you likely want a pipeline operator. If you are moving outside of pipeline-oriented shell-style programming you probably want a line macro.

from racket-rash.