Consider a program like the following (from this solution):
That is, unweave the arglist, yank the result, then check whether y with each sublist uniquified is equal to y.
Suppose = were a meta-operator that meant "apply the operation, then check whether the result equals the original value." Then we could instead write:
for -3 bytes.
This is a meta-operator that takes a unary operator and produces a unary compound operator. Another possible meaning for = as a meta-operator would turn a unary operator into a binary one: "apply the operation to lhs and rhs, then check whether the results equal each other." This is the implied meaning of = in the existing #= operator. I think it's possible for both meanings to coexist: the arity of the compound operator with = could be determined by the parser, and the meaning applied accordingly.
This could interact with $ in some weird ways. In particular, if $ is applied before =, certain combinations aren't possible that would be possible the other way around (e.g. if $#= is [$#]=, that's meaningless, while $[#=] would mean "fold on length-equality"). On the other hand, when both ways are possible, I think applying $ first is typically more useful and more intuitive (e.g. $+= makes more sense as "sum and check equality" than as "fold on equality-when-converted-to-number"). That order would also suggest that operators modified with both $ and = could be binary, which would require changes to the parser. On the other hand, I think = applying to unary operators at all would require changes to the parser, so maybe it's no big deal.
It could also interact with * in some weird ways. Both orders of application are potentially meaningful, and could actually be distinguished by the parser, but it would require some changes to how meta-operators are currently handled. The easier route would be to pick an order. R*= ("reverse each and check equality") seems a bit more useful than R=* ("check if each is equal to its reverse"). The latter could be written as R=_Ma for one more byte (but maybe more, depending on context, since M is low-precedence); the former would have to be R*a=a, which gets a lot hairier if a is a full expression.
Consider a program like the following (from this solution):
That is, unweave the arglist, yank the result, then check whether
ywith each sublist uniquified is equal toy.Suppose
=were a meta-operator that meant "apply the operation, then check whether the result equals the original value." Then we could instead write:for -3 bytes.
This is a meta-operator that takes a unary operator and produces a unary compound operator. Another possible meaning for
=as a meta-operator would turn a unary operator into a binary one: "apply the operation to lhs and rhs, then check whether the results equal each other." This is the implied meaning of=in the existing#=operator. I think it's possible for both meanings to coexist: the arity of the compound operator with=could be determined by the parser, and the meaning applied accordingly.This could interact with
$in some weird ways. In particular, if$is applied before=, certain combinations aren't possible that would be possible the other way around (e.g. if$#=is[$#]=, that's meaningless, while$[#=]would mean "fold on length-equality"). On the other hand, when both ways are possible, I think applying$first is typically more useful and more intuitive (e.g.$+=makes more sense as "sum and check equality" than as "fold on equality-when-converted-to-number"). That order would also suggest that operators modified with both$and=could be binary, which would require changes to the parser. On the other hand, I think=applying to unary operators at all would require changes to the parser, so maybe it's no big deal.It could also interact with
*in some weird ways. Both orders of application are potentially meaningful, and could actually be distinguished by the parser, but it would require some changes to how meta-operators are currently handled. The easier route would be to pick an order.R*=("reverse each and check equality") seems a bit more useful thanR=*("check if each is equal to its reverse"). The latter could be written asR=_Mafor one more byte (but maybe more, depending on context, sinceMis low-precedence); the former would have to beR*a=a, which gets a lot hairier ifais a full expression.