On Wed, Nov 28, 2012 at 10:40 PM, Daniel N
<ufo@orbiting.us> wrote:
Thanks to the wonderful UDA implementation in 2.061, I thought of a little hack, which may interest at least someone.
I'm using it for prototyping ctfe ast transformations together with: https://github.com/PhilippeSigaud/Pegged
Aha!
Yes, it was possible to do similar stuff before and "examples/dgrammar.d" from Pegged is quite impressive, but not bug free.
No kidding :)
I've a few contributors who're helping me stabilize / make the engine better. We will tackle the D grammar afterwards. It does make a good testing ground for when I want to push the CTFE throttle.
This UDA-line-hack-way is actually significantly cleaner, because when using __LINE__ you are certain that there will be at least one [__LINE__] which is not inside a string or comment on the attributed line... this allows one to make a very limited grammar/parser which doesn't have to know/parse/understand the entire file.
I don't understand what you're trying to do. Could you please explain it a bit more? UDA's a quite new and I'd be very interested in their interaction with compile-time code manipulation.
If anyone else have fun UDA hacks, considering that it's a new feature, please share.
import std.string;
import std.range;
struct magic
{
[__LINE__] int var1;
[__LINE__] int var2;
[__LINE__] int var3;
}
enum dsrc = import(__FILE__).splitLines(KeepTerminator.yes);
string parse()
{
string result = "";
foreach(m; __traits(allMembers, magic))
result ~= dsrc.drop(__traits(getAttributes, mixin("magic." ~ m))[0]-1).takeOne().front;
What I don't get is how the [__LINE__] part in magic contains significant info.