Wow, the automatic {0,1} range for ImageTransformation is so trolly…

Turns out you need to use DataRange -> Full. That's pretty unintuitive. I spent forever trying to figure out why my image always transformed into black…

@WReach thanks for the feedback. Maybe not a bug but a documentation bug, though I don't expect anything from docs lately. As you noticed it is not consistent with general pattern-matching principles, what is it then? Something between 'proper pattern' and OptionsPattern[]? What is a 'proper pattern' then? The most annoying thing to me is that one can't predict an outcome of my example only by reading docs. I'm confused now.

@RolfMertig Yes, but it was only an example. What I'm really after are the general rules and exceptions, when a pattern symbol on the LHS is going to be inserted on the RHS.

I have an implementation, but I thought this might already be discussed on the site.

Consider this more complex example:

rule = s : {x_Integer,  y_ /; ((y /. x1_Real :> Round[x1]) === {1, 2, 3})} :> {s, x, y, x1}

In[70]:= {1, {1, 2.2, 2.9}} /. rule

Out[70]= {{1, {1, 2.2, 2.9}}, 1, {1, 2.2, 2.9}, x1}

Your fun will miss the s and find the wrong x1. So the rules for determining the "real" pattern symbols are a bit more complex. Currently, I have

ClearAll[visitElement]
SetAttributes[visitElement, {HoldFirst}];
visitElement[
   Verbatim[Pattern][
    s_Symbol, _Blank | _BlankSequence | _BlankNullSequence]] :=
  SymbolName[Unevaluated[s]];
visitElement[Verbatim[Pattern][s_Symbol, args_]] :=
  Prepend[visitElement[args], SymbolName[Unevaluated[s]]];
visitElement[Verbatim[Condition][a_, _]] := visitElement[a];
visitElement[_[args___]] := List @@ (visitElement /@ Hold[args])

with inspects only the LHS

In[68]:= With[{f = First[rule]},
 visitElement[f]
 ]

Out[68]= {"s", "x", "y"}

@halirutan this is only an example, first you'd have to extract symbols from rhs and assemble Module like that:

Module[{rule, s, x, y, x1},

 rule = s : {x_Integer,
     y_ /; ((y /. x1_Real :> Round[x1]) === {1, 2, 3})} :> {s, x, y,
    x1};

 Union@Cases[rule,
   s_Symbol /; StringEndsQ[SymbolName[Unevaluated[s]], "$"] :>
    StringDrop[SymbolName[Unevaluated[s]], -1], {1, \[Infinity]}]
 ]

@halirutan Using all relevant symbols with special meaning in pattern matching: mathematica.stackexchange.com/questions/82936/… we get something like this:

symPatt = Except[HoldPattern@Symbol@___, _Symbol];
pattNameExtractRules = {
  x : (Blank | BlankNullSequence | BlankSequence | OptionsPattern | Verbatim)@___ :> {}
  ,
  (HoldPattern | IgnoringInactive | KeyValuePattern | Literal | Longest | Optional | Repeated | RepeatedNull | Shortest)@patt_ |
  (Except | Longest | Optional | PatternTest | Repeated | RepeatedNull | Shortest)[patt_, _] |
  Verbatim[Condition][patt_, __] :>
    (Unevaluated@patt /. pattNameExtractRules)
  ,
  Verbatim[Pattern][name : symPatt, patt_] :> {SymbolName@Unevaluated@name, Unevaluated@patt /. pattNameExtractRules}

rule // First // getPatternNames(* {"s", "x", "y"} *)

Or safer: instead of first rule all of this symbols should be listed (...)@___ :> {} before symPatt -> List rule.

@Kuba I was more targeting something without using Mathematica aka only inspecting the AST as I have to implement it in Java. But thanks for your suggestion.

@jkuczm That looks promising!

@halirutan sure, I wouldn't use this anyway as I am not sure I trust automatic renaming ;)

I still have my very first implementation of "PatternVisitor" implemented in IDEA and I finally wanted to tackle it.

Slightly refined version:

symPatt = Except[HoldPattern@Symbol@___, _Symbol];
oneArgPatt = HoldPattern | IgnoringInactive | KeyValuePattern | Literal | Longest | Optional | Repeated | RepeatedNull | Shortest;
firstArgOfTwoPatt = Except | Longest | Optional | PatternTest | Repeated | RepeatedNull | Shortest;
firstArgOfTwoOrMorePatt = Alternatives[Condition];
relevantPatt = Union[Blank | BlankNullSequence | BlankSequence | OptionsPattern | Pattern | Verbatim, oneArgPatt, firstArgOfTwoPatt, firstArgOfTwoOrMorePatt];

pattNameExtractRules = {

@jkuczm Would you say that in Mathematica this is a highlighting bug?

There is no way that pp is ever replaced in the RHS, still it is indicated as this is the case.

@halirutan I suspect that Mathematica is currently simply searching for <something>_ on LHS, no matter where it is precisely, so it's the same e.g. for Verbatim.

I'm not sure whether I'd call it a bug, but it could be improved.

@jkuczm I think Verbatim is a bit different, as you can indeed use the verbatimized expression in LHS. Look here

@halirutan But what you get here is just literal symbol test not any value bound to a pattern variable.

@jkuczm Gosh,.. of course you are correct.

@halirutan Your Except example is maybe more similar to 1 /. pp_Real | p_Integer :> {pp, p}, in general pattern names naming pattern fragments that are allowed to not match, while whole pattern matches, by default are bound to empty sequence.

So one might argue that there's nothing wrong in your Except example pp_Real pattern fragment was simply not matched, so it defaults to empty sequence, but pp is correctly used as pattern variable, while in Verbatim case test is not used as pattern variable at all.

@jkuczm Yes. And in the verbatim example there is no way to proof if test is actually used as placeholder or if it is just the literal symbol that is used on the RHS.

@jkuczm In your implementation, shouldn't Except rather be in a group secondArgOfTwoPatt?

@halirutan Oh, this might be a bug in pattern matcher, I missed it in above response, but actually it's pp that is bound: 1 /. Except[pp_Real, p_Integer] :> {HoldComplete@pp, HoldComplete@p} (* {HoldComplete[1], HoldComplete[]} *)!

And in case of one argument we get some artifacts: 1 /. Except[pp_Real] :> HoldComplete@pp (* HoldComplete[Removed["$Variable"][1]] *)

@jkuczm That is weird

@jkuczm Because see this:

In[205]:= 1 /. Except[_Real, p_Integer] :> {p}

Out[205]= {1}

So you're right, Except should be in secondArgOfTwoPatt, the fact that it sometimes fall into firstArgOfTwoPatt category is most likely a bug.

@jkuczm In any case, thank you for pointing out the details. I'm confident I can come up with a much better Java implementation now.

Up to 10.0 Except with Pattern in first argument gives Except::named error, so it's a regression from 10.1.