Issue 1534 - case macro - haxe

[waneck]

[Google Issue #1534 : http://code.google.com/haxe/issues/detail?id=1534] by si...@haxe.org, at 2013-02-24T23:09:42.000Z There are some issues with case macro usage at the moment, which extend to general matching of { pos: p }. We have to find a way to distinguish the generated pos fields from real, user-defined ones.

[waneck]

[comment from si...@haxe.org, published at 2013-02-25T12:41:02.000Z] In r6313 we now pseudo-detect reification mode if there's an ECheckType(e, Expr). This example works now:

class Main { static public function main() { var e = macro test("hello", "foo"); switch(e) { case macro $i($a1, $a2): trace(i); // { expr : EConst(CIdent(test)), pos : { min : 64, file : src/Main.hx, max : 68 } } trace(a1); // { expr : EConst(CString(hello)), pos : { min : 69, file : src/Main.hx, max : 76 } } trace(a2); // { expr : EConst(CString(foo)), pos : { min : 78, file : src/Main.hx, max : 83 } } case {pos:p}: trace(p); } } }

It would be nice if there was a way to escape down to value level, so we could catch e.g. "hello" directly instead of EConst(CString("hello")).

[waneck]

[comment from ncanna...@gmail.com, published at 2013-02-25T12:50:16.000Z] I guess that would mean reversing $v{$hello}, not easy to do I think

[waneck]

[comment from si...@haxe.org, published at 2013-02-25T12:58:27.000Z] I don't think that's required. We can already catch specific literals, the problem is catching a literal of a specific type. I think $i{i}($a1, $a2) would actually work for the above and yield "test", if $i was properly implemented (I would appreciate if you could have a look at that by the way). If we can get that working then it shouldn't be too hard to support CString and CInt as well.

[waneck]

[comment from ncanna...@gmail.com, published at 2013-02-25T21:51:39.000Z] Yes $i{} could work, but unless we add $s{} for string and $somethingNotI for Int that will not be generic enough.

Maybe using ${CIdent(CString(hello)} would work directly ?

As for $i compiling to EConst(CIdent(i)) it's quite easy to do. Open an issue and assign it to me.

[waneck]

[comment from si...@haxe.org, published at 2013-02-25T23:27:26.000Z] $i works nicely now, so it would make sense to allow $s for String and $f for Float as well. The sad part is that Int starts with i, I guess it's too late to change current $i to $id.

We could go for $I, $S and $F instead, which goes nicely with the uppercase type names.

[waneck]

[comment from ncanna...@gmail.com, published at 2013-02-26T11:16:35.000Z] Don't agree Int/Float/String are needed. They are only used for pattern matching, not real reification (which is already handled by $v), so I would prefer another solution here.

Does ${EConst(CFloat(f))} works in patterns ?

[waneck]

[comment from si...@haxe.org, published at 2013-02-26T12:23:01.000Z] Not quite, you would have to use ${{expr:EConst(CFloat(f))}}, which looks more like ascii art than macro reification.

I also don't agree that Int/Float/String would be pattern matching only. You may use them for normal reification as well in order to avoid the heavy and macro-only makeExpr call.

[waneck]

[comment from ncanna...@gmail.com, published at 2013-02-26T13:56:13.000Z] Well the later is another story, we could actually have optimization path in order to work well with Int/Float/String.

What about $v{f:Float} then ? (once we have added ECheckType concrete syntax)

[waneck]

[comment from si...@haxe.org, published at 2013-02-26T17:17:22.000Z] Looks a bit funny, and I'm not sure I see the advantage over $Float{f}, but at least it's not ascii art.

[waneck]

[comment from si...@haxe.org, published at 2013-04-10T15:42:22.000Z]