Conversation

You should look at Paulette's; she's scaled it up to handle if, and recursion via eliminators. Even have a sketch of how to handle match and fix, but preserving the guard condition is on you.
2
3
Yeah, but I would really worry about performance. The eliminators you'd generate could be absurd, and I FEEL like it would be easier to compile and optimize match + fix. I think disagrees about having match+fix in the core and I need to investigate.
2
2
I was hoping to elaborate pattern matching to eliminators, but I keep hearing claims that it's bad idea for performance, and then others claiming it's not bad, if you do it right. I don't really know either way, but aesthetically eliminators seem nicer?
2
1
For _one_ of my languages I want to support targets which might have a non-dependent match construct (like Rust). So it might be better to preserve pattern matching in the core in that case, but I'm not sure.
1
1
So the interpretation cost isn't what I'm worried about (I hope to be able to JIT during type checking o.0), but the size of the data type + eliminator generated to get the eliminator the corresponds to a small pattern match+fix.
1
1
E.g. if you look at what Coq's Program generates.. you wouldn't want to run that code. And Coq pulls some tricks to extract the code you wrote, not the generated code, to OCaml.
1
Show replies