View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2012
UDA + Pegged AST Hack
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

Yes, it was possible to do similar stuff before and 
"examples/dgrammar.d" from Pegged is quite impressive, but not 
bug free.

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 know my proof-of-concept doesn't handle multi-line, but it can 
be added, and doesn't matter for the sake of prototyping AST 
manipulations.

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;

  // insert pegged parsing / transformations here.

  return result;
}

mixin("struct magic2\n{\n" ~ parse() ~"}");
November 28, 2012
Re: UDA + Pegged AST Hack
On Wednesday, 28 November 2012 at 21:40:35 UTC, Daniel N 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
>
> Yes, it was possible to do similar stuff before and 
> "examples/dgrammar.d" from Pegged is quite impressive, but not 
> bug free.
>
> 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 know my proof-of-concept doesn't handle multi-line, but it 
> can be added, and doesn't matter for the sake of prototyping 
> AST manipulations.
>
> 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;
>
>   // insert pegged parsing / transformations here.
>
>   return result;
> }
>
> mixin("struct magic2\n{\n" ~ parse() ~"}");

I made two, but not as cool as yours: 
http://dpaste.dzfl.pl/32536704 http://dpaste.dzfl.pl/15e4591b
November 28, 2012
Re: UDA + Pegged AST Hack
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<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.
November 28, 2012
Re: UDA + Pegged AST Hack
> I made two, but not as cool as yours: http://dpaste.dzfl.pl/32536704


I like this one :)

I think this part:

static T readArgs(T)(string[] args)
{
T ret;
pragma(msg, "getopt(args"~buildGetOptArguments!(T, "ret")~");");
mixin("getopt(args"~buildGetOptArguments!(T, "ret")~");");
return ret;
}


Could be slightly simplified somewhat. Try passing 'ret' as an alias. That
way, buildGetOptArguments should be able to create the "ret" string by
itself, like this:


private static string buildGetOptArguments(T, alias instance)()
{
   enum string instanceName = instance.stringof; // for example
...

And I'd have buildGetOptArguments return the "getopt(args" ... ")" part
also.
Which gives:

T readArgs(T)(string[] args)
{
T ret;
pragma(msg, buildGetOptArguments!(T, ret));
mixin(buildGetOptArguments!(T, ret)~";");
return ret;
}
November 29, 2012
Re: UDA + Pegged AST Hack
On Wednesday, 28 November 2012 at 21:40:35 UTC, Daniel N 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
>
> Yes, it was possible to do similar stuff before and 
> "examples/dgrammar.d" from Pegged is quite impressive, but not 
> bug free.
>
> 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 know my proof-of-concept doesn't handle multi-line, but it 
> can be added, and doesn't matter for the sake of prototyping 
> AST manipulations.
>
> 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;
>
>   // insert pegged parsing / transformations here.
>
>   return result;
> }
>
> mixin("struct magic2\n{\n" ~ parse() ~"}");

Here we go, annotation with strings. The feature is not even out 
that its quirks already shows up.

You take the least resistance path, and this is comprehensible, 
but anotationg with a string is known to be a bad idea. It have 
been mentionned in UDA and what you did here is the perfect 
example : when the least resistance path is something plain 
wrong, people will do it anyway.

Can someone remember me why this ended up in master ? This 
feature is clearly not ready.
November 29, 2012
Re: UDA + Pegged AST Hack
On 2012-11-29 01:16, deadalnix wrote:

> Can someone remember me why this ended up in master ? This feature is
> clearly not ready.

Because that's what Walter do, committing new features to the master 
branch willy nilly.

-- 
/Jacob Carlborg
November 29, 2012
Re: UDA + Pegged AST Hack
On Thursday, 29 November 2012 at 07:37:31 UTC, Jacob Carlborg 
wrote:
> On 2012-11-29 01:16, deadalnix wrote:
>
>> Can someone remember me why this ended up in master ? This 
>> feature is
>> clearly not ready.
>
> Because that's what Walter do, committing new features to the 
> master branch willy nilly.

I want to remind you that there is still no consensus about 
whether unconstrained attributes are good or bad.
November 29, 2012
Re: UDA + Pegged AST Hack
On Thursday, 29 November 2012 at 09:56:29 UTC, Max Samukha wrote:
> On Thursday, 29 November 2012 at 07:37:31 UTC, Jacob Carlborg 
> wrote:
>> On 2012-11-29 01:16, deadalnix wrote:
>>
>>> Can someone remember me why this ended up in master ? This 
>>> feature is
>>> clearly not ready.
>>
>> Because that's what Walter do, committing new features to the 
>> master branch willy nilly.
>
> I want to remind you that there is still no consensus about 
> whether unconstrained attributes are good or bad.

Furthermore I intentionally used __LINE__ (int), as an 
optimization, among other things; it results in reduced memory 
consumption during CTFE.

In my case I only intend to use the magic type inside the same 
source file to generate another type(magic2) which I then will 
expose externally, thus it's perfectly safe. Magic will be 
discarded and never escape, nor be used for anything.
November 29, 2012
Re: UDA + Pegged AST Hack
On Wednesday, 28 November 2012 at 21:43:40 UTC, Robik wrote:
> I made two, but not as cool as yours: 
> http://dpaste.dzfl.pl/32536704 http://dpaste.dzfl.pl/15e4591b

awesome, this is really nice inspiration too, thanks! :)
November 29, 2012
Re: UDA + Pegged AST Hack
On Wednesday, 28 November 2012 at 22:04:14 UTC, Philippe Sigaud 
wrote:
> 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.

I'm trying to find a safe spot in the middle of a file, where I 
can start parsing, normally you have to parse the entire file to 
understand it, ex with your grammar files, there are many 
keywords inside huge strings, so basically I let the compiler 
handle comments and white-space parsing, which allows to me to 
make a stable localized parser for a subset of the language.

> What I don't get is how the [__LINE__] part in magic contains 
> significant
> info.

It allows me to retrieve the entire original source for a 
declaration... it kinda emulates a ".sourceof" trait / property. 
:)
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home