View mode: basic / threaded / horizontal-split · Log in · Help
March 22, 2012
Proposal: __traits(code, ...) and/or .codeof
So the discussions about Attributes and Aspect Oriented 
Programming (AOP) got me thinking... Basically AOP requires 
injecting code fragments together in a comprehensible way. 
Similarly, Attributes that go beyond @note (such as @GC.NoScan) 
need similar ability.

D already has the ability to mixin arbitrary code fragments at 
compile time, and to process those in useful ways through CTFE. 
Which rocks. What it lacks is the ability to reflect upon the 
actual source code due to IO limitations of CTFE. So creating a 
mixin templates which pieces together a unique object is, to my 
knowledge, currently next to impossible (and slow since you'd 
have to parse and isolate code in .d file multiple times in a 
separate process, then compile again to put it all together).

So, to quote Walter, what compelling features would it bring? 
Here's an example of a simple AOP program from the AOP wiki page 
(probably not the best implementation, but the concept is there):

  struct BankType
  {
    void transfer() { ... }
    void getMoneyBack() { ... }
  }

  struct Logger
  {
    void transfer() {
      log("transferring money...");
    }
    void getMoneyBack() {
      log("User requested money back");
    }
  }

and now some magic...

  string bankCode(T...)(T aspects) {
    auto code = "struct Bank {";
    auto members = [__traits(allMembers, Bank)];
    foreach (m; members) {
      code ~= "void "~m~"() {";
      code ~= __traits(getMember, Bank, m).codeof;
      foreach (a; aspects) {
        if (__traits(hasMember, a, m) {
          code ~= __traits(getMember, a, m).codeof;
        }
      }
      code ~= "}"
    }
    return code ~ "}";
  }

  mixin template Bank(T...)
  {
    mixin(bankCode(T));
  }

  mixin Bank!Logger;

  void main() {
    auto b = Bank();
    b.transfer(); // logs
    b.getMoneyBack(); // ditto
  }

So this would allow us to make "Compilers" within the Compiler 
(Codeception), since we could parse/strip/append any existing 
code fragments together in endless combination. Generic 
"Builders" could probably be built and put into a std.builder lib 
for general use.

One particular use I have in mind is for Behavior Objects (Game 
Scripts). Each behavior would hold Property(T) objects which 
define per-property, per-state "binding" dependencies (eg. 
position.x.bind(other.x, State.Idle)) and execution code. On 
release, the Property(T) object would be stripped away (leaving 
just T) and it's behavior code "compressed" with others into 
optimized functions.

I don't know much about the internals of DMD, so I'm not sure 
this is a realistic request, but I think the idea is compelling. 
Also, for Attributes I'm not sure this technique is really 
applicable. But it's possible that the compiler could exploit 
this internally for certain Attributes like @GC.whatever
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
ps. Mono-C#'s NRefactory, and Microsoft .Net's forthcoming Roslyn 
Project are the only comparable infrastructures I can think of 
with this level of reflection, and they're the foundation to some 
pretty innovative new development tools.

NRefactory: http://wiki.sharpdevelop.net/NRefactory.ashx
Roslyn: http://msdn.microsoft.com/en-us/vstudio/hh500769
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
On Thursday, 22 March 2012 at 16:55:34 UTC, F i L wrote:
> ps. Mono-C#'s NRefactory, and Microsoft .Net's forthcoming 
> Roslyn Project are the only comparable infrastructures I can 
> think of with this level of reflection, and they're the 
> foundation to some pretty innovative new development tools.
>
> NRefactory: http://wiki.sharpdevelop.net/NRefactory.ashx
> Roslyn: http://msdn.microsoft.com/en-us/vstudio/hh500769

Even if I'm closer to the opposite of a MS-evangelist... color me 
impressed, I like your idea. +1.
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
in addition to .codeof, let's think about .astof returning an abstract  
syntax tree.
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
On Thursday, 22 March 2012 at 18:06:24 UTC, Felix Hufnagel wrote:
> in addition to .codeof, let's think about .astof returning an 
> abstract syntax tree.

I agree, as stated on the IRC, .astof (and therefor 
.astof.toString()) is a much better concept.
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
On Thursday, 22 March 2012 at 18:06:24 UTC, Felix Hufnagel wrote:
> in addition to .codeof, let's think about .astof returning an 
> abstract syntax tree.

I haven't really looked at DMD's AST structure, but I assume we 
could just duplicate that minus any CTFE stuff or codegen stuff.
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
Am 22.03.2012 19:06, schrieb Felix Hufnagel:
> in addition to .codeof, let's think about .astof returning an abstract
> syntax tree.

Would this not require something similar to the expression trees in .NET?

http://msdn.microsoft.com/en-us/library/bb397951.aspx

--
Paulo
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
Am 22.03.2012 18:34, schrieb CTFE-4-the-win:
> On Thursday, 22 March 2012 at 16:55:34 UTC, F i L wrote:
>> ps. Mono-C#'s NRefactory, and Microsoft .Net's forthcoming Roslyn
>> Project are the only comparable infrastructures I can think of with
>> this level of reflection, and they're the foundation to some pretty
>> innovative new development tools.
>>
>> NRefactory: http://wiki.sharpdevelop.net/NRefactory.ashx
>> Roslyn: http://msdn.microsoft.com/en-us/vstudio/hh500769
>
> Even if I'm closer to the opposite of a MS-evangelist... color me
> impressed, I like your idea. +1.
>

Same here.

Microsoft R&D does lots of cool stuff actually, pity that sometimes they
get it so wrong, due to the way the management/marketing works.


--
Paulo
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
On 03/22/2012 07:08 PM, F i L wrote:
> On Thursday, 22 March 2012 at 18:06:24 UTC, Felix Hufnagel wrote:
>> in addition to .codeof, let's think about .astof returning an abstract
>> syntax tree.
>
> I agree, as stated on the IRC, .astof (and therefor .astof.toString())
> is a much better concept.

I think that would necessitate the addition of AST macros.
March 22, 2012
Re: Proposal: __traits(code, ...) and/or .codeof
Timon Gehr wrote:
> I think that would necessitate the addition of AST macros.

You mean passing DMD's actual AST tree object? Only a stripped 
down version?
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home