Issue 1364 - Pattern matching case expression grouping - haxe

[waneck]

[Google Issue #1364 : http://code.google.com/haxe/issues/detail?id=1364] by si...@haxe.org, at 2013-01-06T10:02:14.000Z Currently all case expressions are kept inline when using pattern matching. This can lead to quite some code duplication for lengthy code blocks, in particular for the default case which may be present at all nested levels.

We should check if it is possible to generate local functions holding these expressions, and have them called in the case expression. This requires checking the control flow (break, return, continue) and the identity of captured variables.

[waneck]

[comment from ncanna...@gmail.com, published at 2013-01-06T11:04:42.000Z] Note : some platforms might have "goto" statement/opcode (Flash9, CPP, Neko), so it would be better to abstract these "code blocks", and leave the backend do the branching.

We can still provide a reference implementation in Codegen that will convert this abstraction in local functions + function calls

I think the best is to start discussing from the typed AST structure and see how it goes. An idea can be found in the NekoML compiler implementation as part of neko sources.

[waneck]

[comment from si...@haxe.org, published at 2013-01-06T11:56:22.000Z] You are correct, but that should be done on an even larger scale. Here I just wanted to handle the actual case expression code, whereas your optimization should be applied to the whole decision tree as such. That is, we would also want to group nested, internal matches and build a proper dag.

Regarding goto, we have to consider capture variables that may come from different or-pattern branches.

But we should think about this when the time comes, I think for haxe 3 the current output is good enough. It should also be noted that most optimization will optimize code size at the cost of performance, but that's the usual trade off.

[waneck]

[comment from si...@haxe.org, published at 2013-02-24T17:12:14.000Z]