Hi Stef - I saw that blog post - which looks like its essentially the help text that comes up in the rewrite tool when you press the help button. I was going to submit to add to the help text as I think a better example that pulls all the ideas together is helpful. However, I have realised the Rewrite tool is not the main pharo-project repo and comes under NewTools? How do I find out where that repo is to submit a pr? I think the help button on that tool should launch the normal doc browser with the text in the normal help format vs a seperate window? The help browser could probably use some work but at least if help is one place it all will get updated together? I was going to propose the following example which helped me a lot - if I wanted to rewrite how logging was done in the following example (and separate the Transcript line into 2 lines): appLog: anObject "Log anObject for debugging" | date | date := Date today. Transcript traceCr: 'debug: ', date printString, anObject printString. date isLeapYear ifTrue: [ ^nil ]. ^anObject I could write a match expression like this: appLog: `arg | `@temps | `.@before. Transcript traceCr: `#str , `@exp1, `@exp2. `.@after and a rewrite rule like this: appLog: `arg | `@temps | `.@before. Transcript cr; traceCr: `#str, `@exp1. `arg traceCr. `.@after I think this demonstrates most of the concepts that caught me out - namely: you need to call out the variable matching explicitly -= the .@before (list statement matching doesn't match variables - and using @temps will match 0 or more vars, so its safer to include it if matching expressions that may have any otherwise nothing will match. If you want to match a string you need to match it as a literal e.g. `#str. You may need to match 0 or more statements before and after your target expression hence `.@before and `.@after but its important to include the trailing "." on the @before. to cut off before the expression you are trying to match next. I didn't fully understand in my example is why I can't match the remaining statements after the transcript string using just `.@exp1. I seem to have to call out both expressions which I now realise (and worth documenting) is because the AST for that line is actually VariableNode(transcript) + MsgNode(MsgNode(Literal+MsgNode(exp1)), MsgNode(exp2) and so you have to call them all out to match things or match the entire sequence with @stmnt (in my case I wanted to pick them apart). I think the top tip in all of this is to use the handy source code ast inspector to help you reason on the structure. The above is probably the gist of the kinds of docs we would need, and happy to submit a pr with this in it. On Wed, 5 Jun 2024, at 6:35 AM, stephane ducasse wrote:
Hi Tim
This is on my todo to have a serious look at the pattern matcher Now one of the few documentation that we have in the blog and I ported it in the blog post in /doc folder.
S
On 4 Jun 2024, at 01:35, Tim Mackinnon <tim@testit.works> wrote:
Hey Gabriel - thanks for chipping in - you've made me realise that its perhaps easier to give a simpler example (for the multiple replacement)., and while trying to explain in simpler terms I managed to solve the problem myself - but it does demonstrate the docs around this need a bit more work as I didn't find it easy to reason on.
I am still confused what the setting "this rule is for a method" does - so am keen for someone to shed light.
Anyway for my example it seems that I have to be very specific in how I match things for example I had to use the search pattern:
taskbarButtonMenu: `arg | `@temps | `.@before.
moveSubmenu addToggle: 'Move right' translated target: self selector: #taskbarMoveRight getStateSelector: nil enablementSelector: #canBeMovedToRight.
`.@after
And it took me ages to realise that I have to specify the temp vars matching, and also understand that the @before and @after both needed the "." to represent lists of expressions both before and after and then the really subtle "." after @before which I guess prevents greedy matching.
With all of that in place, could then have the write rule add an extra statement after the moveSubmenu (or as many as I want)
e.g.
taskbarButtonMenu: `arg | `@temps | `.@before.
moveSubmenu addToggle: 'Move right' translated target: self selector: #taskbarMoveRight getStateSelector: nil enablementSelector: #canBeMovedToRight.
moveSubmenu addToggle: 'Move to...' translated target: self selector: #taskbarMoveTo getStateSelector: nil.
`.@after
I'm curious now whether there is a more efficient way to do what I have done? Possibly the {} syntax could help now i've figured out the basic matching.
I really find it easy to confuse that if you don't specify the @temps section that can leave out a lot of matches (it essentialy means 0 or more temps vs. leaving it out means no temps at all). This is a trap that the docs should call out better I think.
Anyway - now I just need to figure out how to do this programatically - and possibly I can write a few more useful refactorings I've also thought it was odd that were missing.
On Mon, 3 Jun 2024, at 12:19 PM, Gabriel Cotelli wrote:
I've used the rewrite tool extensively but never tried to create more than one expression from the original one. I think that this probably won't work because in your example the code is just statements, but the matching expression can be in code like this:
self doSomething: ( moveSubmenu addToggle: 'Move right' translated target: self selector: #taskbarMoveRight getStateSelector: nil enablementSelector: #canBeMovedToRight)
and in this case, you cannot replace this with two statements. So I'm tempted to say that what you want is not supported.
Regards, Gabriel
On Mon, Jun 3, 2024 at 5:44â¯AM Tim Mackinnon <tim@testit.works> wrote:
__ I've never really learned the rewrite tool but while waiting for changes to propagate through P12, I thought maybe I could use it to safely patch changes until there are official updates (and it was a good chance to get more familiar with it).
I thought there was more documentation available for how it works (interested in any old articles - but the online help in P12 is ok - although it doesn't display in markdown - in fact give there is markdown support now - I am a bit confused what should appear more readable these days - and how to fix/contribute changes to help).
This aside - I wanted to patch the SystemWindow>>taskbarButtonMenu: (and add my fix to move tabs to any position).
I started writing the following search expression - the find the last call to #addToggle:... method call that has a literal referencing #canBeMovedRight - as I want to add my new menu item after it.
e.g.
moveSubmenu `@addToggle: `{ :node | node isLiteralNode and: [ node value = #canBeMovedToRight] }
but I'm not sure my {} filter block is ever called, as the above matches both addToggle:... calls, and not the one I'm after? I don't understand this - any have ideas on the proper syntax for generic matching?
Anyway - I decided that in my case there is only one - so I can match it explicitly and so I search on the full call:
and I entered this: moveSubmenu addToggle: 'Move right' translated target: self selector: #taskbarMoveRight getStateSelector: nil enablementSelector: #canBeMovedToRight.
Which matches exactly - then I want to replace the single statement with 2 statements e.g.
moveSubmenu addToggle: 'Move right' translated target: self selector: #taskbarMoveRight getStateSelector: nil enablementSelector: #canBeMovedToRight.
moveSubmenu addToggle: 'Move to' translated target: self selector: #taskbarMoveTo getStateSelector: nil.
However this gives an error in the rewrite tool (actually it results in a zero change, that then gives an error for EpMonitor).
But my question is - why can't you rewrite a single statement to multiple ones? I have noticed that in this case I can cascade the message send - and this then rewrites properly - so it looks like it wants to replace a single node with a single node.
If I couldn't cascade - It seems I would have to rewrite with something like: [ "put multiple expressions here" ] value.
This seems an odd choice - but am I missing something obvious?
Do you have to do what I'm proposing in 2 steps - rewrite to a block (or some equivalent) and then a 2nd rewrite to simplify the expression (like a refactor step) - so its more provably correct?
I'm just curious on this - as it seemed time to learn this properly?
Tim
Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73
"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes