Automatic `@as_record` pattern matching
jariji opened this issue · comments
Is there a risk of problems if structs are treated as @as_record
by default? It would be more convenient and seems standard in other languages.
I have some to say in terms of this issue, so I divide them into the following 2 parts.
Replies
Is there a risk of problems if structs are treated as @as_record by default?
"No" for most pattern matching implementations: other Julia matching libraries, Python PEP 634, Rust, etc.
For MLStyle:
- Currently,
@as_record
has a significant impact on pre-compilation time. - (See the reply to your next question)
It would be more convenient and seems standard in other languages.
This is quite right, but MLStyle was designed with "extensible matching" in mind. In fact, how patterns map to Julia code is fully controlled by the pattern_uncall
method which allows further customization for user types. Such an implementation gives great extensibility, but in some degree makes it a bit difficult to make @as_record
default using multiple dispatch.
Further Plan
MLStyle was a bit too extreme in terms of completeness and extensibility in the previous years, but it turns out that not all features are widely used, which is partially due to the poor promotion but also suffers from a disconnect with major/simple use cases.
I'm planning to rewrite MLStyle with only "pragmatic" features included, to promise
- more common assumptions such as default
@as_record
and native support forBase.Enum
- easier APIs for user-level extensibility.
- lightning-fast import time and macro expansion time
- performance improvements (for
@noinline
and@nospecialize
argument) - native support for dependency free codegen (Roger-luo/Expronicon.jl#13)
Currently in the process of trying to organize some interested contributors;