The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.
XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible
The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.
XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible
I get it, but it's hard to track
1 reply →