DIP60: @nogc attribute

[Frustrated via Digitalmars-d]

On Monday, 21 April 2014 at 16:45:15 UTC, Jacob Carlborg wrote:
> On Sunday, 20 April 2014 at 14:38:47 UTC, Frustrated wrote:
>
>> How bout this!
>>
>> Why not allow one to define their own attributes from a 
>> generalized subset and then define a few standard ones like 
>> @nogc.
>
> Sounds like you want AST macros. Have a look at this 
> http://wiki.dlang.org/DIP50#Declaration_macros
>
> --
> /Jacob Carlborg

Not quite. AST macros simply transform code. Attributes attach 
meta data to code. While I'm sure there is some overlap they are 
not the same.

Unless AST macros have the ability to arbitrary add additional 
contextual information to meta code then they can't emulate 
attributes.

E.g., Suppose you have D with AST macros but not attributes, how 
can you add them?

In the dip, you have

macro attr (Context context, Declaration decl)
{
     auto attrName = decl.name;
     auto type = decl.type;

     return <[
         private $decl.type _$decl.name;

         $decl.type $decl.name ()
         {
             return _$decl.name;
         }

         $decl.type $decl.name ($decl.type value)
         {
             return _$decl.name = value;
         }
     ]>;
}

class Foo
{
     @attr int bar;
}

but attr is not an attribute. It is an macro. @attr converts the 
"int bar" field into a private setter and getter. This has 
nothing to do with attributes.

(just cause you use the attr word and the @ symbol doesn't make 
it an attribute)


I don't see how you could ever add attributes to D using AST 
macros above unless the definition of an AST macro is modified. 
[Again, assuming D didn't have attributes in the first place]

This does not mean that AST macros could not be used to help 
define the generalized attributes though.


What I am talking about is instead of hard coding attributes in 
the compiler, one abstracts and generalizes the code so that any 
attribute could be added in the future with minimal work.

It would simply require one to add the built in attributes list, 
add the attribute grammar(which is used to reduce compound 
attributes), add any actions that happen when the attribute is 
used in code.

e.g.,

builtin_attributes = {

     {pureness, pure, !pure/impure,
         attr = any(attr, impure) => impure
         attr = all(attr, pure) => pure
     }

     {gc, gc, !gc/nogc,
         attr = any(attr, gc) => gc
         attr = all(attr, nogc) => nogc
     }
     etc... }

notices that pureness and gc have the same grammatical rules. 
Code would be added to handle the pureness and gc attributes when 
they are come across for optimization purposes.

The above syntax is just made up and pretty bad but hopefully not 
too difficult to get the bigger picture.

Every new built in attribute would just have to be added to the 
list above(easy) and code that uses it for whatever purpose would 
be added in the code where it belongs.

User define attributes essentially would make the attributes list 
above dynamic allowing the user to add to it. The compiler would 
only be told how to simplify the attributes using the grammar and 
would do so but would not have any code inserted because there is 
no way for the user to hook into the compiler properly(I suppose 
it could be done if the compiler was written in an oop like way).

In any case, because the compiler knows how to simplify UDA's by 
using the provided grammar it makes UDA's much more powerful. CT 
reflection and AST macros would make them way more powerful. The 
ability to add hooks into the compiler would nearly give the user 
the same power as the compiler writer. Of course, this would 
probably lead to all kinds of compatibility problems in user code.

Basically, as of now, all we can do is define UDA's, we can't 
define how they relate to each other(the grammar) nor what 
happens when the exist(the behavior). There should not be any 
real difference between UDA's and built in attributes(except 
hooking, only because of complexity issues) and having a 
generalized attribute system in the compiler would go a long way 
to bridging the gap.

The main thing to take away from this is that *if* D had such an 
attribute system, the gc/nogc issue would be virtually 
non-existent. It would only take a few minutes to add a UDA 
@gc/@nogc to D in user code. At least a few people would have 
done it, and it's merits could be seen. Then it would be only a 
matter of "copy and pasting" the definition of the attribute to 
the compiler code and it would then become a built in making it 
available for everyone.

At some point optimizations in the compiler could potentially be 
added... just for fun. Not really the point of the attribute but 
having it does provide such possibilities.

Also, with such a system, attributes can propagate from the 
bottom up and inference makes it a lot easier.

E.g., atomic statements could be "marked" with attributes. Blocks 
of statements can be marked but also inherit from the statements 
and blocks they use.

With such a system, one could mark individual assembly 
instructions as, say, @dangerous. If @dangerous was a "bubbling" 
attribute then you could check and see which functions in your 
code was @dangerous, or if your program was @dangerous.

One could do it similar with @allocate. Any primitive thing that 
allocates in D should get the attribute. Then, if @allocate is a 
"bubbling" attribute, you could find out exactly which parts of 
code in your allocates. You could even find out were this happens.

e.g.,

void foo()
{
      auto m = core.stdc.stdlib.malloc(size);
      bar(); // assume bar does not have @allocate attribute(does 
not allocate memory in any way)
}

foo would be marked @allocate since malloc is marked with 
@allocate and @allocate is an inheriting attribute. A utility 
could be written that shows the hierarchy of the program allowing 
you to explore things and you could find foo and see that the 
reason why foo is marked @allocate is because it calls malloc 
which is marked @allocate. (malloc would be explicitly marked 
while foo would be deduced by the compiler for us)

Hopefully it is easy to see that by starting from the bottom and 
with a well defined attribute system the compiler can become more 
powerful by automatically simplifying attributes for us no matter 
how complex the program.