On Wednesday, January 22, 2003, at 11:42 AM, Kwindla Hultman Kramer wrote:
Michael Lazzaro writes:

And it provides a very visual way to define any pipe-like algorithm, in
either direction:

$in -> lex -> parse -> codify -> optimize -> $out; # L2R

$out <- optimize <- codify <- parse <- lex <- $in; # R2L

It's clear, from looking at either of those, that they represent data
pipes. Both are even clearer than the equiv:

$out = $in.lex.parse.codify.optimize;
<snip>
One question: How does this approach to building a pipe-lining syntax
square with the "alternative spelling of the assignment operator"
feature that's been discussed elsewhere in this thread? It's not
immediately obvious to me how the post-/pre-invocant operation
"becomes" an assignment at the end of the chain. In other words, are
the first two code fragments above really equivalent to the third?
They're equiv only if make a rule saying they're equiv, like what Damian was proposing for <~ and ~>. (Except this isn't quite the same thing as Damian was proposing, which is why I'm not using <~ and ~> to describe it.)

You could for example use:

$x <- 5;

...to do assignment (if you're into that sort of thing) if the '<-' was overloaded to do the right thing when it was piping 'to' a simple variable. Even

$x <- $y <- 5;

could work, since the R2L chain would do the same as $x = $y = 5;

So short answer, it squares pretty well with an alternative spelling for assignment, for persons that would like to do that. They'd be equiv iff we defined the operators such that they were.

MikeL



Reply via email to