Advantages over MLStyle.jl?

[cscherrer]

The @match calls in our code led me to assume we were using MLStyle. I've never used Match.jl; does this approach have any advantages over MLStyle?

[ghost]

I'm not sure. I believe our use of Match.jl predates MLStyle, or at the very least, predates our having learned about MLStyle.

I've also suggested in the past that we need to do an investigation to see whether our use cases are entirely covered by either package, and consolidate on one of them.

None of us seem particularly enthused about supporting this package, so converging on MLStyle sounds great to me if it hits all of our use cases! :)

---

For more context, there's this open issue to consolidate this package and Match.jl together, which we should also probably execute on: #25

[cscherrer]

Thanks Nathan. MLStyle seems maybe a bit more advanced in some ways, because it matches according to Julia's AST structure. Or at least, that's how I always use it. I really like this, but for Julia newcomers it may be harder to use

[ghost]

That sounds appealing!

[thautwarm]

MLStyle also provides extensible pattern matching so that you can define patterns/deconstructors for free.

I'm now unsatisfied with MLStyle because I want to make pattern matching libraries as develop time only frameworks.

And I now think comparing to mlstyle, rematch is more lightweighted and more friendly to get integrated into projects. However I'd say using rematch is now suffering from some issues.

The match failure error reporting can be confusuing, and it doesn't point to the position of errors occurred.

The where clause has very misleading precedences, MLStyle used to use this notation but finally dropped this.

I hereby think the major problems of Julia pattern matching are these, and I hope the Julia community can work together to end them:

1. Optimizations: merging and splitting using algorithms of analysing decision trees, thus users won't need aware how to write efficient code but how to write readable and maintainable code.

2. Portability. Expanding match macros usually needs non trivial analysis of the code, and this could be really time-consuming. As a result, debugging can be really slow and disturbing. My personal suggestion is making a small set of a pattern matching library "develop time only", which just statically generates julia code without @match macros.

3. Extensibility. The capability of defining custom patterns counts, because the demands of practical developments vary from the fields we work on, and one can never say he/she has known all fields of software developments and she/he has already made the useful pattern matching facilities for all those fields. One way to address this is providing a convenient way to define domain-specific patterns, which is called extensible pattern matching. And something called first class pattern matching is also helpful to this case.

4. Error reporting(Maintainability). The failure information of matching helps us to understanding the incorrectness in our code, and if the information doesn't make sense, users will feel awful about the experience. It also closely concerns the maintainability and reliability of our code. IMO, w need source code positions, representation of the pattern in which the failure occurred, and the potential suggestions to resolve.