I know about all that, and I’ve tried to discuss about some kind of
collaboration, but it didn’t work out.
RBPattern nodes are straight-forward. The are just a Smalltalk code with
special nodes. The problem about them is that it is not clear what is
happening, because you have to create a LintRule which creates one more Rule
which creates an AST node, and then it traverses an AST and changes it in the
same time… for me it was a lot of mess. I moved to the lowest level and
introduces a really simple API:
matchNode := RBPatternParser parseExpression: aMatchString.
matchNode
match: anASTNode
onSuccess: [ :map | “do something with a mapping" ]
onFailure: [ “do something in case of failure” ]
And you can easily debug this, and other tools can use this, for example match
tool does:
testAST nodesDo: [ :node | “try to match node” ]
so I can look for all possible matches.
I’ve heard that Camille and Mark are making something super generic for
matching objects, but my problem is that I need to give people possibility to
make their rules easy, and each time I ask if I can use something there is
still work in progress.
There is another problem: for now I have no use case for matching objects, I
have a prototype of rules about objects, but sadly it’s out of my scope. Then
how easy is the syntax? RBPatternCode is the closest you can get to Smalltalk
code, if we give people another syntax they will have to learn something new
and will resist. Finally what infrastructure do we have around it? I always use
rubular.com when I need to work with regex, and now I will always use MatchTool
when I need to work with the pattern code. Is there any support for inspecting
the matches from the new framework?
So in the end I’m always ready for collaboration and always looking for
collaboration, but at the moment I don’t need some super-powerful matching
framework. I need something easy for people to use, and this is why I’m
refactoring rules and implementing tools like this. And it seems easier for me
to fix a bug in pattern code matching (especially as it is easier to debug it)
than adopting a new framework.
Another example. MatchTool should definitely marry RewriteTool, because after
you’ve investigated the matches you should be able to say: "ok, and now I want
to transform this”, and then you enter another expression and save a rule. In
fact RewriteTool inspired me a lot. Because it is very useful, but you enter
code and it is not highlighted, so you have no clue if you made a mistake. Or
you create a “meta variable” and you want to know what are these `@ things and
you have to google. Or your code is finally matching, but you have no idea what
was matched to what. I really hate when I have no clue what is happening, and
this is why I’ve implemented MatchTool.
Cheers.
Uko
> On 04 Aug 2016, at 13:45, stepharo <[email protected]> wrote:
>
> BTW our experience with anne and JC when they tried to document how the
> patterns were working is that there are some situations
>
> that are not clear, and this is why Camille and Mark started to work on
> another solution.
> I hope to get to know more soom.
>
> Stef
>
> Le 4/8/16 à 10:23, Yuriy Tymchuk a écrit :
>> Hi everyone!
>>
>> I’m happy to announce a new tool that can help you to understand to the
>> pattern code is working in match & rewrite rules.
>> You can read more on my blogpost:
>> http://blog.yuriy.tymch.uk/2016/08/matchtool.html
>> <http://blog.yuriy.tymch.uk/2016/08/matchtool.html>
>> The tool is available for Pharo 6 from the catalog.
>>
>> <Mail Attachment.png>
>>
>> Cheers!
>> Uko
>
