www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - pure, safe and generalized attributes

reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
With all the talk about pure, safed and transitivity.
I think the time is right for a discussion about
user defined code attributes.

Code attributes is just meta data for the code.
Normally, this meta data is stored in revision systems, databases, in
the code comments or just plain left out.
But there is some advantages by placing them in the code and letting the
compiler take care of them.

Scott Meyers does a good job of introducing the subject in
http://video.google.com/videoplay?docid=-4728145737208991310

----

The simplest use of code attribute I can imagine
is a attribute which indicate that this piece of code have been review.
It could be defined by.
attribute KilroyWasHere;

and used like
int func(param p1) KilroyWasHere
{
...
}

You can do this with comments as well, but imagine you use.

attribute FixMe warn;

and the compile gave you a warning every time it sees the FixMe attribute.

attribute FixMe fail;

Would give you a error and the build would fail.

----

The next attribute indicate that the code is license under the GPL.

attribute GPL transitive;

Here the transitive keyword tells the compiler that the attribute is
transitive, and the compiler should check that every function called
also has the attribute GPL.
----

attribute LGPL deny GPL;

This attribute is not transitive but the code should not call GPL code.
-----

attribute safe transitive allow pure;

Define an attribute for thread-safety which is transitive but also
allows pure functions. pure would be a build in attribute because it
need to be able to validate the code.
-----

Now imagine a big team need to refactor a big ugly code base.

Then the following attributes will allow the team to mark
the code after how it smells (good, okay or bad);

attribute good transitive warn;
attribute okay transitive warn allow good;
attribute bad transitive warn allow okay,good;

The attributes only issue warnings, so they wouldn't stop the code form
compiling, and only when more smelly code is called.


I hope that I have illustraded that user definded code attributes
could be very useful.

Knud
Apr 04 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 04/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:
<snip>

Nice. But to avoid accruing an infinite number of keywords, the syntax
needs to be slightly changed. Instead of

    int func(param p1) KilroyWasHere
    {
        ...
    }

use

    int func(param p1) attribute(KilroyWasHere)
    {
        ...
    }
Apr 04 2008
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Janice Caron, el  4 de abril a las 08:42 me escribiste:

 On 04/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:
 <snip>
 
 Nice. But to avoid accruing an infinite number of keywords, the syntax
 needs to be slightly changed. Instead of
 
     int func(param p1) KilroyWasHere
     {
         ...
     }
 
 use
 
     int func(param p1) attribute(KilroyWasHere)
     {
         ...
     }


Or something simpler, like Python's decorators:

 KilroyWasHere
int func(param p1)
{
    ...
}

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
All men are born equal
But quite a few get over it
Apr 04 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:

 Or something simpler, like Python's decorators:
  KilroyWasHere
 int func(param p1)
 {
     ...
 }


Do you mean to copy just the syntax? Because Python decorator semantics is
quite different, they are a way to feed a function/method to one of more
metafunctions :-)

So this:

 foo
int func(param p1) {}

means something like:

func = foo(func)

And there are more complex usages, stacking more than one decorators, giving
them arguments, etc.

Bye,
bearophile
Apr 04 2008
prev sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Leandro Lucarella wrote:

 Janice Caron, el  4 de abril a las 08:42 me escribiste:

 On 04/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:
 <snip>

 Nice. But to avoid accruing an infinite number of keywords, the syntax
 needs to be slightly changed. Instead of

     int func(param p1) KilroyWasHere
     {
         ...
     }

 use

     int func(param p1) attribute(KilroyWasHere)
     {
         ...
     }


 
 Or something simpler, like Python's decorators:
 
  KilroyWasHere
 int func(param p1)
 {
     ...
 }


I like the idea with   as short for (at)tribute.
Apr 05 2008
prev sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Janice Caron wrote:

 On 04/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:
 <snip>
 
 Nice. But to avoid accruing an infinite number of keywords, the syntax
 needs to be slightly changed. Instead of
 
     int func(param p1) KilroyWasHere
     {
         ...
     }
 
 use
 
     int func(param p1) attribute(KilroyWasHere)
     {
         ...
     }


You could also ague that it is not necessary because
attributes can only appear in certain places

only in function, class, struct and module declarations.
Apr 05 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:

 You could also ague that it is not necessary because
  attributes can only appear in certain places

  only in function, class, struct and module declarations.


    KilroyWasHere:

Is that an attribute or a label?
Apr 05 2008
parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Janice Caron wrote:

 On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:

 You could also ague that it is not necessary because
  attributes can only appear in certain places

  only in function, class, struct and module declarations.


 
     KilroyWasHere:
 
 Is that an attribute or a label?


"KilroyWasHere" is the label for the attribute
that this place was inspected by Kilroy

Why do you ask ??
Apr 05 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:

 Janice Caron wrote:


 On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:


  >> You could also ague that it is not necessary because
  >>  attributes can only appear in certain places
  >>
  >>  only in function, class, struct and module declarations.
  >


     KilroyWasHere:


  >
  > Is that an attribute or a label?

 "KilroyWasHere" is the label for the attribute
  that this place was inspected by Kilroy

  Why do you ask ??


I was trying to make the point that D has a context-free grammar, and
that an identifier followed by a colon, where you might expect to find
a statement or a declaration, might be ambiguous.

In hindsight, I might have jumped too fast. It might be possible to
tell the difference because: if you're expecting a statement, it's a
label; if you're expecting a declaration, it's an attribute.

However, the point still stands. Allowing arbitrary identifiers as
attributes is /bound/ to confuse the parser somewhere along the line,
unless we explicitly indicate to the compiler that this identifier is
an attribute.
Apr 05 2008
parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Janice Caron wrote:

 On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:

 Janice Caron wrote:


 On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:


  >> You could also ague that it is not necessary because
  >>  attributes can only appear in certain places
  >>
  >>  only in function, class, struct and module declarations.
  >


     KilroyWasHere:


  >
  > Is that an attribute or a label?

 "KilroyWasHere" is the label for the attribute
  that this place was inspected by Kilroy

  Why do you ask ??


 
 I was trying to make the point that D has a context-free grammar, and
 that an identifier followed by a colon, where you might expect to find
 a statement or a declaration, might be ambiguous.
 
 In hindsight, I might have jumped too fast. It might be possible to
 tell the difference because: if you're expecting a statement, it's a
 label; if you're expecting a declaration, it's an attribute.
 
 However, the point still stands. Allowing arbitrary identifiers as
 attributes is /bound/ to confuse the parser somewhere along the line,
 unless we explicitly indicate to the compiler that this identifier is
 an attribute.


I see that the D manual already have something called attributes
it might have been confusing you.

Maybe if i use the word constrain, for what we talking about is a way to
define code constrains.

We have this now i D
ModuleDeclaration:
 module ModuleName ;

ClassDeclaration:
  class Identifier BaseClassList(opt)  ClassBody

FunctionDeclaration: (I didn't find this in the manual)
 type Identifier(Parameters) FunctionBody

With constrains we will have this
ModuleDeclaration:
 module ModuleName ConstrainList(opt);

ClassDeclaration:
  class Identifier BaseClassList(opt)  ConstrainList(opt) ClassBody

FunctionDeclaration:
 type Identifier(Parameters) ConstrainList(opt) FunctionBody

Hope this helps

Knud
Apr 05 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:

 I see that the D manual already have something called attributes
  it might have been confusing you.


Yes it was. I assumed that "attribute" meant what it means in the D
grammar docs.

This wasn't the first time that confusion was caused by two people
assuming the same word meant two different things. I'm sure it won't
be the last! :-)

That said, you'd probably want your constraints to be attributes
anyway. That is, you'd want to put them anywhere you can currently put
"static", "private", etc.
Apr 05 2008
parent Georg Wrede <georg nospam.org> writes:
Janice Caron wrote:

 On 05/04/2008, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:
 

I see that the D manual already have something called attributes
 it might have been confusing you.


 
 
 Yes it was. I assumed that "attribute" meant what it means in the D
 grammar docs.
 
 This wasn't the first time that confusion was caused by two people
 assuming the same word meant two different things. I'm sure it won't
 be the last! :-)
 
 That said, you'd probably want your constraints to be attributes
 anyway. That is, you'd want to put them anywhere you can currently put
 "static", "private", etc.


This would be enormously confusing to people reading others' code.
Apr 09 2008
prev sibling next sibling parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
Good, but I'd rather see 'thread-safe' built-in attribute.

On Fri, 04 Apr 2008 11:19:49 +0400, Knud Soerensen  =

<4tuu4k002 sneakemail.com> wrote:


 With all the talk about pure, safed and transitivity.
 I think the time is right for a discussion about
 user defined code attributes.

 Code attributes is just meta data for the code.
 Normally, this meta data is stored in revision systems, databases, in
 the code comments or just plain left out.
 But there is some advantages by placing them in the code and letting t=


he

 compiler take care of them.

 Scott Meyers does a good job of introducing the subject in
 http://video.google.com/videoplay?docid=3D-4728145737208991310

 ----

 The simplest use of code attribute I can imagine
 is a attribute which indicate that this piece of code have been review=


.

 It could be defined by.
 attribute KilroyWasHere;

 and used like
 int func(param p1) KilroyWasHere
 {
 ...
 }

 You can do this with comments as well, but imagine you use.

 attribute FixMe warn;

 and the compile gave you a warning every time it sees the FixMe  =



 attribute.

 attribute FixMe fail;

 Would give you a error and the build would fail.

 ----

 The next attribute indicate that the code is license under the GPL.

 attribute GPL transitive;

 Here the transitive keyword tells the compiler that the attribute is
 transitive, and the compiler should check that every function called
 also has the attribute GPL.
 ----

 attribute LGPL deny GPL;

 This attribute is not transitive but the code should not call GPL code=


.

 -----

 attribute safe transitive allow pure;

 Define an attribute for thread-safety which is transitive but also
 allows pure functions. pure would be a build in attribute because it
 need to be able to validate the code.
 -----

 Now imagine a big team need to refactor a big ugly code base.

 Then the following attributes will allow the team to mark
 the code after how it smells (good, okay or bad);

 attribute good transitive warn;
 attribute okay transitive warn allow good;
 attribute bad transitive warn allow okay,good;

 The attributes only issue warnings, so they wouldn't stop the code for=


m

 compiling, and only when more smelly code is called.


 I hope that I have illustraded that user definded code attributes
 could be very useful.

 Knud
Apr 04 2008
parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Koroskin Denis wrote:

 Good, but I'd rather see 'thread-safe' built-in attribute.
 


Yes, a threat-safe attribute would be very useful.

But if we can utilise the same code that help
implement build-in attributes like const, pure or thread-safe
to define user defined constrains
that would be a much better utilisation of the code and make D more
powerful.


 On Fri, 04 Apr 2008 11:19:49 +0400, Knud Soerensen
 <4tuu4k002 sneakemail.com> wrote:
 

 With all the talk about pure, safed and transitivity.
 I think the time is right for a discussion about
 user defined code attributes.

 Code attributes is just meta data for the code.
 Normally, this meta data is stored in revision systems, databases, in
 the code comments or just plain left out.
 But there is some advantages by placing them in the code and letting the
 compiler take care of them.

 Scott Meyers does a good job of introducing the subject in
 http://video.google.com/videoplay?docid=-4728145737208991310

 ----

 The simplest use of code attribute I can imagine
 is a attribute which indicate that this piece of code have been review.
 It could be defined by.
 attribute KilroyWasHere;

 and used like
 int func(param p1) KilroyWasHere
 {
 ...
 }

 You can do this with comments as well, but imagine you use.

 attribute FixMe warn;

 and the compile gave you a warning every time it sees the FixMe
 attribute.

 attribute FixMe fail;

 Would give you a error and the build would fail.

 ----

 The next attribute indicate that the code is license under the GPL.

 attribute GPL transitive;

 Here the transitive keyword tells the compiler that the attribute is
 transitive, and the compiler should check that every function called
 also has the attribute GPL.
 ----

 attribute LGPL deny GPL;

 This attribute is not transitive but the code should not call GPL code.
 -----

 attribute safe transitive allow pure;

 Define an attribute for thread-safety which is transitive but also
 allows pure functions. pure would be a build in attribute because it
 need to be able to validate the code.
 -----

 Now imagine a big team need to refactor a big ugly code base.

 Then the following attributes will allow the team to mark
 the code after how it smells (good, okay or bad);

 attribute good transitive warn;
 attribute okay transitive warn allow good;
 attribute bad transitive warn allow okay,good;

 The attributes only issue warnings, so they wouldn't stop the code form
 compiling, and only when more smelly code is called.


 I hope that I have illustraded that user definded code attributes
 could be very useful.

 Knud
Apr 05 2008
prev sibling parent reply "David Wilson" <dw botanicus.net> writes:
On Fri, Apr 4, 2008 at 7:19 AM, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:

  With all the talk about pure, safed and transitivity.
  I think the time is right for a discussion about
  user defined code attributes.

  Code attributes is just meta data for the code.
  Normally, this meta data is stored in revision systems, databases, in
  the code comments or just plain left out.
  But there is some advantages by placing them in the code and letting the
  compiler take care of them.

  Scott Meyers does a good job of introducing the subject in
  http://video.google.com/videoplay?docid=-4728145737208991310

  ----

  The simplest use of code attribute I can imagine
  is a attribute which indicate that this piece of code have been review.
  It could be defined by.
  attribute KilroyWasHere;


For all that I'd love to see something like .NET attributes in D, if
it means people starting to mark functions and fields with
[BugFix(1234)] or [ReviewedBy("me")] then count me out! Source files,
i.e. the data structures you feed to a compiler,  really isn't the
place for adding support for ticket tracking or a review process. :)

For the first case, get a revision control system and use its
annotation function (this has the benefit of systematically recording
all changes to every line of code in a file, not just ones some
programmer arbitrarily decided to tag with an attribute). For the
latter case, see something like review-board.org or search Google for
"QA branch". These really aren't good uses of custom attributes at
all.


David.
Apr 04 2008
parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
David Wilson wrote:

 On Fri, Apr 4, 2008 at 7:19 AM, Knud Soerensen <4tuu4k002 sneakemail.com>
wrote:

  With all the talk about pure, safed and transitivity.
  I think the time is right for a discussion about
  user defined code attributes.

  Code attributes is just meta data for the code.
  Normally, this meta data is stored in revision systems, databases, in
  the code comments or just plain left out.
  But there is some advantages by placing them in the code and letting the
  compiler take care of them.

  Scott Meyers does a good job of introducing the subject in
  http://video.google.com/videoplay?docid=-4728145737208991310

  ----

  The simplest use of code attribute I can imagine
  is a attribute which indicate that this piece of code have been review.
  It could be defined by.
  attribute KilroyWasHere;


 
 For all that I'd love to see something like .NET attributes in D, if
 it means people starting to mark functions and fields with
 [BugFix(1234)] or [ReviewedBy("me")] then count me out! Source files,
 i.e. the data structures you feed to a compiler,  really isn't the
 place for adding support for ticket tracking or a review process. :)
 
 For the first case, get a revision control system and use its
 annotation function (this has the benefit of systematically recording
 all changes to every line of code in a file, not just ones some
 programmer arbitrarily decided to tag with an attribute). For the
 latter case, see something like review-board.org or search Google for
 "QA branch". These really aren't good uses of custom attributes at
 all.
 


Yes, if you only read the part of my post that you have cited
then there is no point of implementing it.

That why I write the you can do that with comment as well.

The real power comes when you utilise the compiler to ensure
the transitivity constraint of the attribute, something most revision
control system can't do and something I think will be very helpful when
dealing with big code bases and/or big teams.
Apr 05 2008