www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Wrong Stuff

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-business-james-bagian-nasa-astronaut-turned-patient-safety-expert-on-being-wrong.aspx


tl;dr: "Telling people to be careful is not effective. Humans are not reliable 
that way. ... You need a solution that's not about making people perfect."


This article doesn't say anything about software, but I think it is very 
applicable to programming and the design of programming languages. I often hear 
that a fault isn't a fault because we can "educate" programmers to avoid the 
problem. This article puts the kibosh on that. Errors that we can eliminate by 
changing the design of the language, we should so eliminate (unless their costs 
make the language unuseable, obviously).
Sep 22 2010
next sibling parent "JimBob" <jim bob.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i7e7jp$1q7h$1 digitalmars.com...
 http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-business-james-bagian-nasa-astronaut-turned-patient-safety-expert-on-being-wrong.aspx


 tl;dr: "Telling people to be careful is not effective. Humans are not 
 reliable that way. ... You need a solution that's not about making people 
 perfect."


 This article doesn't say anything about software, but I think it is very 
 applicable to programming and the design of programming languages. I often 
 hear that a fault isn't a fault because we can "educate" programmers to 
 avoid the problem. This article puts the kibosh on that. Errors that we 
 can eliminate by changing the design of the language, we should so 
 eliminate (unless their costs make the language unuseable, obviously).

I read an article once where they were explaining how hospitals put a lot of effort designing procedures and protocols so that they minimizes human error. We have the phrase "human error" cause we humans are error prone. So particulary where peoples lives are at stake it's very worthwhile to do everything you can to minimize the possibility of it happening. One example was having the pharmacist set out each patients drugs and also have the nurse who gives them to the patient check each one. If humans have a 1/100 fail rate on such tasks, then the double check reduces it to 1/10000.
Sep 23 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-business-james-bagian-nasa-astronaut-turned-patient-safety-expert-on-being-wrong.aspx

It's a very good article, thank you for the link. I think it's a book chapter. It says many different things. James Bagian looks like a quite unusual person. The stress over "close calls" in medicine is important, as it's very important to manage errors correctly. Just punishing the doctors/nurses that have done a mistake, as often done today, is not a solution.
 Errors that we can eliminate by changing the design of the language, we should
so eliminate (unless their costs make the language unuseable, obviously).<

Beside few things already present in D2, some of the features that may help avoid some bugs are: 1) Typestate, a feature that is attracting more my interest and appreciation, that will be present in the Rust language by Mozilla labs (I think typestate may avoid many of the bugs found by the real-world static analysis done by Microsoft: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.3285 ); 2) Some lint-like capabilities in the compiler, that *are* able to catch an enormous amount and variety of bugs. This is not a new feature for D2, because it's a collection of many small tests. The new C/C++ Clang compiler shows that it's positive to put some of those capabilities inside the compiler instead of inside an external tool that's uncommonly used; 3) Optional integer/unsigned overflow tests, as C#; 4) Some kind of compile-time enforcement against null references/pointers (my example: http://d.puremagic.com/issues/show_bug.cgi?id=4571 ). 5) Pluggable type systems may help in unforseen situations, they are special-purpose parts of the type system that you may add to the compiler/interpreter to enforce some new contraints. The Treehydra (the GCC plugin that provides a low level JavaScript binding to GCC's GIMPLE AST representation) is an example of pluggable type system. Python3 has added a type annotation syntax for this purpose. D3 may add such capabilities expanding static reflection, and letting user-defined attributes use it. Among those five things the typestate is the one that I have never tried, but it looks good. The other four features look fit for D3 (among those five features, the only one that may change the run-time performance of the code are the overflow tests, the other four things are essentially flexible type system-level constraints). Bye, bearophile
Sep 23 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Recently I have read this article by Dennis Shasha and Cathy Lazere, about
adding adaptability into engineering systems to make them more reliable, this
is also one of the design strategies most used by naturally evolved systems
like animal bodies:
http://www.ddj.com/embedded-systems/223101723

Bye,
bearophile
Sep 23 2010
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-

wrong.aspx
 
 
 tl;dr: "Telling people to be careful is not effective. Humans are not reliable
 that way. ... You need a solution that's not about making people perfect."
 
 
 This article doesn't say anything about software, but I think it is very
 applicable to programming and the design of programming languages. I often
 hear that a fault isn't a fault because we can "educate" programmers to avoid
 the problem. This article puts the kibosh on that. Errors that we can
 eliminate by changing the design of the language, we should so eliminate
 (unless their costs make the language unuseable, obviously).

Very good article. I also liked this one, about the development done in the shuttle software group: http://www.fastcompany.com/node/28121/print It has similar conclusions about process and culture.
Sep 23 2010
prev sibling next sibling parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote:
 Errors that we can eliminate by changing the design of the
 language, we should so eliminate (unless their costs 
 make the language unuseable, obviously).

So are you returning to the very bad design error in switch statements? ;) Silent fall-through is bad, and keeps hitting quite a few programmers - I don't have any links handy right now, but I do remember it has been talked over before here. What I'd like to see is requiring either a continue or a break at the end of a case to make the intent clear. The "problem" would be empty cases, as is the typical C-style method to get multiple values to do the same thing, but these have already been fixed in the language design with multiple values per case statement and ranged case statements. One of the general design principles of D has been "if it compiles in C, it compiles in D and does the same thing or it does not compile at all", if I remember correctly. I would really like to see the C-style silent fallthrough to be a compile time error, which would not contradict that design principle. And if you have a lot of code that relies on this misfeature, then it does not take long to add continue statements where they're needed - not even if translating C source to D.
Sep 23 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/23/2010 09:16 PM, Rioshin an'Harthen wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote:
 Errors that we can eliminate by changing the design of the
 language, we should so eliminate (unless their costs make the language
 unuseable, obviously).

So are you returning to the very bad design error in switch statements? ;) Silent fall-through is bad, and keeps hitting quite a few programmers - I don't have any links handy right now, but I do remember it has been talked over before here. What I'd like to see is requiring either a continue or a break at the end of a case to make the intent clear. The "problem" would be empty cases, as is the typical C-style method to get multiple values to do the same thing, but these have already been fixed in the language design with multiple values per case statement and ranged case statements. One of the general design principles of D has been "if it compiles in C, it compiles in D and does the same thing or it does not compile at all", if I remember correctly. I would really like to see the C-style silent fallthrough to be a compile time error, which would not contradict that design principle. And if you have a lot of code that relies on this misfeature, then it does not take long to add continue statements where they're needed - not even if translating C source to D.

The correct change is not to require break or continue - it's to require any control flow statement. Andrei
Sep 23 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 I don't really mind it how it is, but I've known plenty of programmers who
hated 
 the fallthrough behavior in other languages. So, it would likely be a good 
 change to make.

I'm probably alone in this, but I've always liked the C behavior and never had a problem with it. It's probably from my asm days, as it works just like labeled asm statements do.
Sep 23 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/10 22:59 CDT, Walter Bright wrote:
 Jonathan M Davis wrote:
 I don't really mind it how it is, but I've known plenty of programmers
 who hated the fallthrough behavior in other languages. So, it would
 likely be a good change to make.

I'm probably alone in this, but I've always liked the C behavior and never had a problem with it. It's probably from my asm days, as it works just like labeled asm statements do.

Well admitting you're alone in this is the first step to recovery :o). Andrei
Sep 24 2010
next sibling parent reply lurker <lurk lurking.net> writes:
Andrei Alexandrescu Wrote:

 On 9/23/10 22:59 CDT, Walter Bright wrote:
 Jonathan M Davis wrote:
 I don't really mind it how it is, but I've known plenty of programmers
 who hated the fallthrough behavior in other languages. So, it would
 likely be a good change to make.

I'm probably alone in this, but I've always liked the C behavior and never had a problem with it. It's probably from my asm days, as it works just like labeled asm statements do.

Well admitting you're alone in this is the first step to recovery :o). Andrei

He's not alone with his view. The automatic implicit porting of C code is an important feature - D should work even more like C than it does now. The syntax could also make use of a revamp, we have 'pure' and 'const' and so forth, in C those are __attribute__((pure)) and similar kind of conventions. The C approach saves keywords for actual code.
Sep 24 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/10 10:56 CDT, lurker wrote:
 Andrei Alexandrescu Wrote:

 On 9/23/10 22:59 CDT, Walter Bright wrote:
 Jonathan M Davis wrote:
 I don't really mind it how it is, but I've known plenty of programmers
 who hated the fallthrough behavior in other languages. So, it would
 likely be a good change to make.

I'm probably alone in this, but I've always liked the C behavior and never had a problem with it. It's probably from my asm days, as it works just like labeled asm statements do.

Well admitting you're alone in this is the first step to recovery :o). Andrei

He's not alone with his view. The automatic implicit porting of C code is an important feature - D should work even more like C than it does now. The syntax could also make use of a revamp, we have 'pure' and 'const' and so forth, in C those are __attribute__((pure)) and similar kind of conventions. The C approach saves keywords for actual code.

Preventing implicit fall-through is unlikely to affect large portions of C code, and will never compile programs with different semantics. Andrei
Sep 24 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-25 08:23:52 -0400, "Simen kjaeraas" <simen.kjaras gmail.com> said:

 A rose by any other name...
 
 You may label them whatever you want. The fact still is - built-in
  tributes are reserved words of the language, with special meaning to
 the compiler. If that is not a keyword, I would like to hear a
 common definition of keyword that does not include  tributes, and a
 definition of what  tributes are in comparison.

Just to add to your point: Objective-C is an extension of C that defines a few more keywords too. Most of which are prefixed with so they don't conflict with anything, yet they're said to be keywords. I concur with Simen: this "attribute" vs. "keyword" thing is just a naming convention. The D community has chosen to call "attributes" the keywords that are prefixed by in an attempt to "reduce" the number of keywords (because some have criticized the increasing number of keywords). True, those "attribute-style keywords" don't take more identifiers as reserved words. But if you dig a little in the DMD source, you'll see there is no difference in how these attributes and other keywords are processed once you have passed the parsing stage, they just become flags on data structures, just like regular keywords often do. And to make the matter worse, most attributes are not attributes [1]. We have a concept of attribute at the syntactic level, and another totally different concept of attribute at the semantic level. [1]: http://www.digitalmars.com/d/2.0/attribute.html At this stage I've lost all hopes of coherency in that part of the language. To me, the explanation to differentiate the two is quite simple: an historical incident made all new keywords added after a certain date use the attribute syntax. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 25 2010
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jonathan M Davis wrote:
 There is a distinct difference between keywords and attributes, but it'=

 certainly true that attributes at this point don't have much semantic d=

 The real difference is in the grammar. The fact that you can write a pr=

 this
=20
 void main()
 {
     int property =3D 7;
 }
=20
 is because property is not a keyword.

I believe that the point Simen and Michel are trying to make is that although "property" is not a keyword, " property" is. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Sep 25 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 September 2010 14:25:47 Simen kjaeraas wrote:
 J=C3=A9r=C3=B4me M. Berger <jeberger free.fr> wrote:
 Jonathan M Davis wrote:
 void main()
 {
=20
     int property =3D 7;
=20
 }
=20
 is because property is not a keyword.
=20

=20 that although "property" is not a keyword, " property" is. =20 Jerome

Eggzactly.

That could be the case - I'd have to look at the grammar or parser to be su= re -=20 but that would be a poor way to do it if you ever intended to have user-def= ined=20 attributes. Normally, would be in the grammar as a separate symbol indica= ting=20 that the symbol immediately followed was an identifier which was an attrib= ute.=20 It's quite possible, however, that property is currently treated as a sing= le=20 symbol which is a keyword. I doubt that it will stay that way in the long t= erm=20 though, if it is the case. =2D Jonathan M Davis
Sep 25 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 That could be the case - I'd have to look at the grammar or parser to be  
 sure -
 but that would be a poor way to do it if you ever intended to have  
 user-defined
 attributes. Normally,   would be in the grammar as a separate symbol  
 indicating
 that the symbol  immediately followed was an identifier which was an  
 attribute.
 It's quite possible, however, that  property is currently treated as a  
 single
 symbol which is a keyword. I doubt that it will stay that way in the  
 long term
 though, if it is the case.

It appears I have not made my stance on this clear - in my mind, anything that is illegal to use as an identifier, but that is allowed to use in the language, is a keyword (that is roughly my definition, at least). I don't care whether the compiler uses this method or that to determine whether it is a keyword. Perhaps it would be better to use the term 'reserved word' to encompass both keywords and tributes (the latter with the -prefix included). -- Simen
Sep 25 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis

 Ultimately, it does pretty much come across as later stuff being made
 into attributes rather than keywords with no overriding principle behind it.

One thing that later will help is to give a scope to attributes, so if you want to use them you have to import them from a (standard) module into the current module. I think this is an important step for a later introduction of user-defined attributes. Bye, bearophile
Sep 25 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, September 24, 2010 08:56:22 lurker wrote:
 Andrei Alexandrescu Wrote:
 On 9/23/10 22:59 CDT, Walter Bright wrote:
 Jonathan M Davis wrote:
 I don't really mind it how it is, but I've known plenty of programmers
 who hated the fallthrough behavior in other languages. So, it would
 likely be a good change to make.

I'm probably alone in this, but I've always liked the C behavior and never had a problem with it. It's probably from my asm days, as it works just like labeled asm statements do.

Well admitting you're alone in this is the first step to recovery :o). Andrei

He's not alone with his view. The automatic implicit porting of C code is an important feature - D should work even more like C than it does now. The syntax could also make use of a revamp, we have 'pure' and 'const' and so forth, in C those are __attribute__((pure)) and similar kind of conventions. The C approach saves keywords for actual code.

I don't think that it's ever been the case that we've been all that worried about making C code portable with minimal effort. We just don't want to make it harder without added value. Really, choices with regards to changes from C or C++ come down to two things: 1. Changes aren't made without value being added. 2. When C and D are the same, the semantics are the same so that ported code doesn't change behavior. And really, stuff like __attribute((pure)) wouldn't be standard C anyway. There is no pure, nothrow, etc. in C, and such features were added to D in the manner that seemed best to Walter and Andrei and company. Since C doesn't have those features, there is no conflict with C. And even if there were, if the changes are deemed to be of great enough benefit, then making them is fine because they don't result in C code ending up with different semantics when it's ported over. Personally, I don't think that it should be D's goal to be like C. It shouldn't change things willy-nilly or make it so that C code would have different semantics as D code, but the lack of direct backwards compatability with C is a *feature* of D. And as for keywords, while we don't want to go overboard adding new ones, considering how many words there are in the English language and how programmers tend to use altered and abbreviated versions of them anyhow, even doubling the number of keywords that we have now wouldn't ultimately be that big a deal. Sure, it would be annoying at times, and you'd have to search for synonyms and the like, but it wouldn't be all that restrictive ultimately. However, we're not going to double the number of keywords that we have, and the syntax has allowed us to remove some keywords and will allow us to add more stuff later without having to add keywords. In any case, I think that on the whole, D has taken the right approach here. - Jonathan M Davis
Sep 24 2010
prev sibling next sibling parent reply Torarin <torarind gmail.com> writes:
2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have, and the
   syntax has allowed us to remove some keywords and will allow us to add more
 stuff later without having to add keywords.

Why are attributes not considered keywords? Because the compiler doesn't care about them?
Sep 25 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Torarin wrote:
 2010/9/25 Jonathan M Davis <jmdavisProg gmx.com>:
 Part of the point of attributes was to make it so that they
 weren't keywords and therefore didn't make the list of keywords any lo=


=20
 If they make the attribute list longer, what do you gain from making
 the keyword list shorter, other than  -ifying the keywords?

Basically, all it does is defining a namespace for keywords. Since you can't define identifiers with an , then whenever Walter wants to add a new keyword, he only has to pick one that start with to make sure that he won't break anyone's code. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Sep 25 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Torarin <torarind gmail.com> wrote:

 2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have,  
 and the
   syntax has allowed us to remove some keywords and will allow us to  
 add more
 stuff later without having to add keywords.

Why are attributes not considered keywords? Because the compiler doesn't care about them?

Mostly because normal keywords eat up valid identifiers, while tributes don't. That said, tributes are of course keywords too. -- Simen
Sep 25 2010
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i7h7o4$2361$1 digitalmars.com...
 I'm probably alone in this, but I've always liked the C behavior and never 
 had a problem with it. It's probably from my asm days, as it works just 
 like labeled asm statements do.

I learnt to program in ms batch, so it always seemed perfectly natural to me.
Sep 24 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Indeed, though it might be okay to allow totally empty case statements on the 
 theory that the programmer pretty much couldn't have meant anything other than 
 fallthrough - though given that D has the syntax to do that as one case 
 statement, it might be reasonable (and probably easier to implement) to not 
 allow totally empty case statements.

In my opinion empty case fall-through is not significantly bug-prone, so it may be acceptable: switch (x) { case 1: case 2: case 3: x++; break; default: y++; break; } But it has few disadvantages: In most cases in D2 it's not necessary, because D allows the comma operator to list several cases, and it has the range case syntax: switch (x) { case 1, 2, 3: x++; break; default: y++; break; } switch (x) { case 1: .. case 3: x++; break; default: y++; break; } It adds a corner case to a rule. The rule is: "D2 doesn't allow 'free' fall-through, some control statement is required". If that is allowed then you need "D2 doesn't allow 'free' fall-through, some control statement is required, unless the case statement is empty." Adding one corner case doesn't make the language significantly worse, but many corner cases make the language more complex for the programmer, the D2 compiler, and the D2 manuals. So corner cases need to be added only when they are very useful. On this topic I have a bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4349 Bye, bearophile
Sep 24 2010
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 23 September 2010 19:27:19 Andrei Alexandrescu wrote:
 On 09/23/2010 09:16 PM, Rioshin an'Harthen wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote:
 Errors that we can eliminate by changing the design of the
 language, we should so eliminate (unless their costs make the language
 unuseable, obviously).

So are you returning to the very bad design error in switch statements? ;) Silent fall-through is bad, and keeps hitting quite a few programmers - I don't have any links handy right now, but I do remember it has been talked over before here. What I'd like to see is requiring either a continue or a break at the end of a case to make the intent clear. The "problem" would be empty cases, as is the typical C-style method to get multiple values to do the same thing, but these have already been fixed in the language design with multiple values per case statement and ranged case statements. One of the general design principles of D has been "if it compiles in C, it compiles in D and does the same thing or it does not compile at all", if I remember correctly. I would really like to see the C-style silent fallthrough to be a compile time error, which would not contradict that design principle. And if you have a lot of code that relies on this misfeature, then it does not take long to add continue statements where they're needed - not even if translating C source to D.

The correct change is not to require break or continue - it's to require any control flow statement. Andrei

Indeed, though it might be okay to allow totally empty case statements on the theory that the programmer pretty much couldn't have meant anything other than fallthrough - though given that D has the syntax to do that as one case statement, it might be reasonable (and probably easier to implement) to not allow totally empty case statements. I don't really mind it how it is, but I've known plenty of programmers who hated the fallthrough behavior in other languages. So, it would likely be a good change to make. - Jonathan M Davis
Sep 23 2010
parent BCS <none anon.com> writes:
Hello Jonathan,

 Indeed, though it might be okay to allow totally empty case statements
 on the theory that the programmer pretty much couldn't have meant
 anything other than fallthrough - though given that D has the syntax
 to do that as one case statement, it might be reasonable (and probably
 easier to implement) to not allow totally empty case statements.

In other languages, the solution is to make it not a cases statement but a statement with one or more case labels. (Technically "case exp:" isn't a statment at all.)
 
 I don't really mind it how it is, but I've known plenty of programmers
 who hated the fallthrough behavior in other languages. So, it would
 likely be a good change to make.
 
 - Jonathan M Davis
 

... <IXOYE><
Sep 24 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 September 2010 03:23:12 Torarin wrote:
 2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have,
 and the   syntax has allowed us to remove some keywords and will allow
 us to add more stuff later without having to add keywords.

Why are attributes not considered keywords? Because the compiler doesn't care about them?

Because they don't need to be any more than variable names do. indicates that what follows is an attribute, so the next symbol is parsed as an attribute. If it were a keyword, then it wouldn't compile. keywords are always treated as keywords no matter the context. They show up explicitly in the grammar. Attributes do not show up explicitly in the grammar any more than variables do. The grammar indicates when a symbol is a variable, and it's parsed as variables. The grammar also indicates when a symbol is an attribute, and it's parsed as an attribute. Basically, what it comes down to is that keywords are symbols in the grammar - just like ! or ~ or <. Variable names and attributes are not. Attributes allow us to add more modifiers to stuff (particularly functions) without having to add new keywords. And someday, we may even be able to define attributes in our own code (right now, they're all known by the compiler) - and that's something that you obviously can't do with keywords. - Jonathan M Davis
Sep 25 2010
parent reply Don <nospam nospam.com> writes:
Jonathan M Davis wrote:
 On Saturday 25 September 2010 03:23:12 Torarin wrote:
 2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have,
 and the   syntax has allowed us to remove some keywords and will allow
 us to add more stuff later without having to add keywords.

doesn't care about them?

Because they don't need to be any more than variable names do. indicates that what follows is an attribute, so the next symbol is parsed as an attribute. If it were a keyword, then it wouldn't compile. keywords are always treated as keywords no matter the context. They show up explicitly in the grammar. Attributes do not show up explicitly in the grammar any more than variables do. The grammar indicates when a symbol is a variable, and it's parsed as variables. The grammar also indicates when a symbol is an attribute, and it's parsed as an attribute. Basically, what it comes down to is that keywords are symbols in the grammar - just like ! or ~ or <. Variable names and attributes are not. Attributes allow us to add more modifiers to stuff (particularly functions) without having to add new keywords. And someday, we may even be able to define attributes in our own code (right now, they're all known by the compiler) - and that's something that you obviously can't do with keywords. - Jonathan M Davis

Sep 25 2010
parent reply Don <nospam nospam.com> writes:
Jonathan M Davis wrote:
 On Saturday 25 September 2010 22:59:51 Don wrote:
 Jonathan M Davis wrote:
 On Saturday 25 September 2010 03:23:12 Torarin wrote:
 2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have,
 and the   syntax has allowed us to remove some keywords and will allow
 us to add more stuff later without having to add keywords.

doesn't care about them?

indicates that what follows is an attribute, so the next symbol is parsed as an attribute. If it were a keyword, then it wouldn't compile. keywords are always treated as keywords no matter the context. They show up explicitly in the grammar. Attributes do not show up explicitly in the grammar any more than variables do. The grammar indicates when a symbol is a variable, and it's parsed as variables. The grammar also indicates when a symbol is an attribute, and it's parsed as an attribute. Basically, what it comes down to is that keywords are symbols in the grammar - just like ! or ~ or <. Variable names and attributes are not. Attributes allow us to add more modifiers to stuff (particularly functions) without having to add new keywords. And someday, we may even be able to define attributes in our own code (right now, they're all known by the compiler) - and that's something that you obviously can't do with keywords. - Jonathan M Davis


Do you mean that you can use user-defined attributes as long as they're prefixed with _ or that you can use keywords if they're prefixed with _? Prefixing a keyword with _ makes it so that it's a different token, so it's not going to match any keywords. Now, if you mean that you could use your own attributes as long as they start with an underscore (.e.g. _myproperty), then that could be useful, but I don't know how you'd be able to make use of it, since you'd need a way to get at through __traits or std.traits, and functionAttributes() (which is the only function that I see for looking at attributes) isn't string-based but rather flag-based, which means that it won't work with anything but a predefined set of attributes. - Jonathan M Davis

I was just referring to the "without having to add new keywords" bit. And a fairly general comment to the whole thread (not just this post). I meant that __keywords are available, and the argument that provides a namespace for keywords is completely wrong, and utterly dreadful. I'm a bit disturbed that people are even thinking in that way. See also the August 28 post by Herb Sutter: http://herbsutter.com/ "My biggest (but not only) beef with C++0x [[attributes]] is that the standard itself was abusing attributes as disguised [[keywords]]. Attributes are acceptable as pure annotations, but they should have no semantic effect on the program. [snip] it’s a clear example of adding language keywords dressed in attributes’ clothing, and not something I want to be responsible for forcing three million C++ developers to live with until the end of time."
Sep 26 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said:

 I was just referring to the "without having to add new keywords" bit. 
 And a fairly general comment to the whole thread (not just this post). 
 I meant that __keywords are available, and the argument that   provides 
 a namespace for keywords is completely wrong, and utterly dreadful. I'm 
 a bit disturbed that people are even thinking in that way.

People (including me) are thinking that way because there is no sane semantic definition of what the syntax stands for. I'll grant you one thing: attributes are only used to affect declarations in one way or another, so as long as this stands they're more limited in purpose than keywords in general. But beyond that, what makes different from another namespace for keywords?
 See also the August 28 post by Herb Sutter:
 http://herbsutter.com/
 
 "My biggest (but not only) beef with C++0x [[attributes]] is that the 
 standard itself was abusing attributes as disguised [[keywords]]. 
 Attributes are acceptable as pure annotations, but they should have no 
 semantic effect on the program.
 [snip]
 it’s a clear example of adding language keywords dressed in attributes’ 
 clothing, and not something I want to be responsible for forcing three 
 million C++ developers to live with until the end of time."

Unfortunately, one attribute with the syntax in D -- and I'd say the flagship one as it was the first and most discussed -- is not a pure annotation as it has a noticeable effect on semantics. I'm talking about property which, if it ever get implemented, changes your function so it simulates a field. In Herb's terms, property is clearly a keyword in disguise. And then you realize many keywords fit that same definition of an attribute (deprecated, pure, nothrow...) and you're left with a very fuzzy concept of what the syntax is for. We have an important keyword disguised as an attribute ( property) and attributes disguised as keywords for historical reason (deprecated, pure, nothrow...). Whatever the syntax was supposed to stand for, it's pretty messed up right now. There's also confusion about the term "attribute" itself. Try reading that page and come with a sane definition of what is an attribute in D. <http://digitalmars.com/d/2.0/attribute.html> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 26 2010
next sibling parent reply Don <nospam nospam.com> writes:
Michel Fortin wrote:
 On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said:
 
 I was just referring to the "without having to add new keywords" bit. 
 And a fairly general comment to the whole thread (not just this post). 
 I meant that __keywords are available, and the argument that   
 provides a namespace for keywords is completely wrong, and utterly 
 dreadful. I'm a bit disturbed that people are even thinking in that way.

People (including me) are thinking that way because there is no sane semantic definition of what the syntax stands for. I'll grant you one thing: attributes are only used to affect declarations in one way or another, so as long as this stands they're more limited in purpose than keywords in general. But beyond that, what makes different from another namespace for keywords?
 See also the August 28 post by Herb Sutter:
 http://herbsutter.com/

 "My biggest (but not only) beef with C++0x [[attributes]] is that the 
 standard itself was abusing attributes as disguised [[keywords]]. 
 Attributes are acceptable as pure annotations, but they should have no 
 semantic effect on the program.
 [snip]
 it’s a clear example of adding language keywords dressed in 
 attributes’ clothing, and not something I want to be responsible for 
 forcing three million C++ developers to live with until the end of time."

Unfortunately, one attribute with the syntax in D -- and I'd say the flagship one as it was the first and most discussed -- is not a pure annotation as it has a noticeable effect on semantics. I'm talking about property which, if it ever get implemented, changes your function so it simulates a field. In Herb's terms, property is clearly a keyword in disguise. And then you realize many keywords fit that same definition of an attribute (deprecated, pure, nothrow...) and you're left with a very fuzzy concept of what the syntax is for. We have an important keyword disguised as an attribute ( property) and attributes disguised as keywords for historical reason (deprecated, pure, nothrow...). Whatever the syntax was supposed to stand for, it's pretty messed up right now. There's also confusion about the term "attribute" itself. Try reading that page and come with a sane definition of what is an attribute in D. <http://digitalmars.com/d/2.0/attribute.html>

Yeah, it's a big mess. property is most definitely a keyword. The only value I can see at this point in making something an attribute rather than a __keyword is that we could develop a standard syntax for compile-time (and runtime) querying of attributes.
Sep 26 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 The only value I can see at this point in making something an  attribute
 rather than a __keyword is that we could develop a standard syntax for 
 compile-time (and runtime) querying of attributes.

I think you need: 1) To be able to import an user-defined attribute in just the current scope/module, using a normal import: import myattributes: noallocs; Or just: import myattributes: noallocs; // the is not used when you import it 2) More compile-time introspection capabilities. To implement in D a user-defined attribute like noallocs you need some way to transitively inspect the code inside a function, looking for heap memory allocations. 3) Some syntax to attach CTFE functions to user attributes. The simplest design is to do nothing, and allow any function name to be used with a prefix. The argument of such functions may be the AST of the function the attribute is put on, its JSON or even its body as text. Then when you add noallocs to a function signature the compiler runs at compile-time the code that performs those tests: noallocs int myLevenshteinDistance(T)(const T[] data) { ... // gives a compile-time error because it contains one new statement. The JSON DMD produces from modules may be used by some attributes, because it contains lot of semantics about the functions in a easy machine-readable way. Something like __traits(json, functionname), plus few Phobos functions to transverse and query a Json tree structure, may be useful for some attributes. Such attributes may be useful to create in simple ways pluggable type systems, that is extensions to the type system ( noallocs is essentially a way to ensure a transitive function tree doesn't do something you don't want it to do, so it's a little extension to the type system). The Mozilla Dehydra/Treehydra does the same things, but it uses JavaScript to write the attributes and the syntax is worse. Recently I have shown something about a tool written to test the source code of Linux, it's essentially a plugged-in type system added to the normal C type system, and its purpose is to avoid some bugs in the kernel code. My theory is that such little extensions to the type system, fit for specific purposes, will become very useful in languages. D has a chance to do this in an almost transparent way. Bye, bearophile
Sep 26 2010
prev sibling next sibling parent reply lurker <lurk lurking.net> writes:
retard Wrote:

 Sun, 26 Sep 2010 09:26:28 -0400, Michel Fortin wrote:
 
 On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said:
 
 I was just referring to the "without having to add new keywords" bit.
 And a fairly general comment to the whole thread (not just this post).
 I meant that __keywords are available, and the argument that   provides
 a namespace for keywords is completely wrong, and utterly dreadful. I'm
 a bit disturbed that people are even thinking in that way.

People (including me) are thinking that way because there is no sane semantic definition of what the syntax stands for. I'll grant you one thing: attributes are only used to affect declarations in one way or another, so as long as this stands they're more limited in purpose than keywords in general. But beyond that, what makes different from another namespace for keywords?
 See also the August 28 post by Herb Sutter: http://herbsutter.com/
 
 "My biggest (but not only) beef with C++0x [[attributes]] is that the
 standard itself was abusing attributes as disguised [[keywords]].
 Attributes are acceptable as pure annotations, but they should have no
 semantic effect on the program.
 [snip]
 it’s a clear example of adding language keywords dressed in attributes’
 clothing, and not something I want to be responsible for forcing three
 million C++ developers to live with until the end of time."

Unfortunately, one attribute with the syntax in D -- and I'd say the flagship one as it was the first and most discussed -- is not a pure annotation as it has a noticeable effect on semantics. I'm talking about property which, if it ever get implemented, changes your function so it simulates a field. In Herb's terms, property is clearly a keyword in disguise. And then you realize many keywords fit that same definition of an attribute (deprecated, pure, nothrow...) and you're left with a very fuzzy concept of what the syntax is for. We have an important keyword disguised as an attribute ( property) and attributes disguised as keywords for historical reason (deprecated, pure, nothrow...). Whatever the syntax was supposed to stand for, it's pretty messed up right now. There's also confusion about the term "attribute" itself. Try reading that page and come with a sane definition of what is an attribute in D. <http://digitalmars.com/d/2.0/attribute.html>

This just makes me wonder, why is it so *** hard to get things right? I remember when D didn't have the stuff syntax at all. I wished it worked like annotations in Java or in C#. If I made my own 3rd party lint/ document_generator/unit_test_tool/whatever, and I'd just want a way to decorate some syntax tree nodes. How can it be so hard to do this? Can you use your own annotations now? Probably not. There's only the property syntax, nothing else. The __traits keyword was also supposed to change to 'traits' or something a bit more sane. Nothing really happened. Why am I using this language?

There is absolutely no need to use D. In fact some (most?) of us wish that you wouldn't. This answer isn't for you because you implicitly seem to disagree with everything, but here it goes: Designing new keywords is a complicated task. Walter follows a so called parser oriented thinking - what's easy to implement in the parser (the low hanging fruit), seems to be the best solution. If you need other kind of changes to the language, you need to carefully take into consideration (Herb Sutter like C++ thinking) all kinds of aspects such as legacy concerns (C compatibility), namespace issues (__keywords and keywords nicely create new namespaces and don't conflict with user symbols like variables). I can't even possibly imagine why would anyone (except you) want to use their own keywords. It sounds like a new treacherous way to invite dangerous macros to the language. The reservation of the word macro without giving an implementation is a conscious decision to disable all kinds of over-expressive macros in forthcoming versions of the language. Providing customized keywords for 3rd party tools seems like mocking the damn good state of the art meta-programming system D has. If I could design D, I'd use in front of every keyword to avoid namespace collisions with user symbols.
Sep 26 2010
parent Justin Johansson <no spam.com> writes:
On 27/09/2010 5:34 AM, lurker wrote:
 retard Wrote:
 Why am I using this language?

There is absolutely no need to use D. In fact some (most?) of us wish that you wouldn't.

No need for any confrontational post; Devil's Advocates are surely welcome here too according to Walter's principles of diversity and equity. While outright rudeness is not wanted from anyone, those that post oppositely-opposed arguments should be considered an asset to this newsgroup. Cheers Justin Johansson
Sep 27 2010
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
On 26/09/2010 11:58 PM, retard wrote:
 This just makes me wonder, why is it so *** hard to get things right? I
 remember when D didn't have the  stuff syntax at all. I wished it worked
 like annotations in Java or in C#. If I made my own 3rd party lint/
 document_generator/unit_test_tool/whatever, and I'd just want a way to
 decorate some syntax tree nodes. How can it be so hard to do this? Can
 you use your own  annotations now? Probably not. There's only the
  property syntax, nothing else. The __traits keyword was also supposed to
 change to 'traits' or something a bit more sane. Nothing really happened.

 Why am I using this language?

Perhaps you mean "why do you hang around here". For me, it is a fun newsgroup and all are welcome here (more-or-less so long as one is not too obtuse). As for why are you using this language, I suspect you are not using it for anything "big". OTOH, if you are using D for anything big, please show and tell. Either way I'd like to here why you continue to remain here. Maybe for the same reasons as myself. ??? Bests to all, Justin Johansson
Sep 27 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 26/09/2010 14:26, Michel Fortin wrote:
 Unfortunately, one attribute with the   syntax in D -- and I'd say the
 flagship one as it was the first and most discussed -- is not a pure
 annotation as it has a noticeable effect on semantics. I'm talking about
  property which, if it ever get implemented, changes your function so it
 simulates a field. In Herb's terms,  property is clearly a keyword in
 disguise.

You don't want attributes to affect semantics? That's odd, it seems to me the most useful scenarios for attributes is actually to affect semantics, and they're somewhat limited otherwise. I mean, what exactly do you mean by "effect on semantics" ? -- Bruno Medeiros - Software Engineer
Oct 25 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-10-25 10:32:45 -0400, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 On 26/09/2010 14:26, Michel Fortin wrote:
 Unfortunately, one attribute with the   syntax in D -- and I'd say the
 flagship one as it was the first and most discussed -- is not a pure
 annotation as it has a noticeable effect on semantics. I'm talking about
  property which, if it ever get implemented, changes your function so it
 simulates a field. In Herb's terms,  property is clearly a keyword in
 disguise.

You don't want attributes to affect semantics? That's odd, it seems to me the most useful scenarios for attributes is actually to affect semantics, and they're somewhat limited otherwise. I mean, what exactly do you mean by "effect on semantics" ?

What I meant is that property actually *changes* the semantics: calling the function becomes a different thing and the function lose its regular semantics. Other attributes only *restrict* existing semantics, they don't change the existing semantics beyond making illegal some things which are normally legal. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 25 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 25/10/2010 16:01, Michel Fortin wrote:
 On 2010-10-25 10:32:45 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:

 On 26/09/2010 14:26, Michel Fortin wrote:
 Unfortunately, one attribute with the   syntax in D -- and I'd say the
 flagship one as it was the first and most discussed -- is not a pure
 annotation as it has a noticeable effect on semantics. I'm talking about
  property which, if it ever get implemented, changes your function so it
 simulates a field. In Herb's terms,  property is clearly a keyword in
 disguise.

You don't want attributes to affect semantics? That's odd, it seems to me the most useful scenarios for attributes is actually to affect semantics, and they're somewhat limited otherwise. I mean, what exactly do you mean by "effect on semantics" ?

What I meant is that property actually *changes* the semantics: calling the function becomes a different thing and the function lose its regular semantics. Other attributes only *restrict* existing semantics, they don't change the existing semantics beyond making illegal some things which are normally legal.

Hum, I think I see what you mean. That being the case, I agree, if an annotation radically changes the nature of whatever is being defined, it probably should not be an annotation. But I don't agree with Herb Sutter's comment that "Attributes are acceptable as pure annotations, but they should have no semantic effect on the program.", at least as applied to D. Just the fact that C++'s attribute are 4-characters extra (compared to just 1 in D, or Java for example) makes the comparison not very valid. I also would not like to have [[override]] [[pure]] [[safe]] , etc. in D. -- Bruno Medeiros - Software Engineer
Oct 25 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 September 2010 03:28:35 Simen kjaeraas wrote:
 Torarin <torarind gmail.com> wrote:
 2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have,
 and the
   syntax has allowed us to remove some keywords and will allow us to
 add more
 stuff later without having to add keywords.

Why are attributes not considered keywords? Because the compiler doesn't care about them?

Mostly because normal keywords eat up valid identifiers, while tributes don't. That said, tributes are of course keywords too.

No they're not. Go look at the list of keywords in TDPL. property, for instance, is not a keyword. Part of the point of attributes was to make it so that they weren't keywords and therefore didn't make the list of keywords any longer. An attribute can't both not eat up valid identifiers and be a keyword at the same time. Attributes are parsed like variable names and are not considered special by the grammar. Now, there are currently on a fixed set of properties recognized by the compiler, and user-defined attributes don't yet exist, but they aren't keywords. - Jonathan M Davis
Sep 25 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2010/9/25 Jonathan M Davis <jmdavisProg gmx.com>:
 Part of the point of attributes was to make it so that they
 weren't keywords and therefore didn't make the list of keywords any longer.

If they make the attribute list longer, what do you gain from making the keyword list shorter, other than -ifying the keywords?
Sep 25 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 25 Sep 2010 13:34:10 +0200, Torarin wrote:

 2010/9/25 Jonathan M Davis <jmdavisProg gmx.com>:
 Part of the point of attributes was to make it so that they weren't
 keywords and therefore didn't make the list of keywords any longer.

If they make the attribute list longer, what do you gain from making the keyword list shorter, other than -ifying the keywords?

You make the list shorter, of course ? Some experts claim that that D is a complex language because there are so many builtin features and keywords. -fying keywords makes D simpler.
Sep 25 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 That said,  tributes are of course keywords too.

No they're not. Go look at the list of keywords in TDPL. property, for instance, is not a keyword. Part of the point of attributes was to make it so that they weren't keywords and therefore didn't make the list of keywords any longer. An attribute can't both not eat up valid identifiers and be a keyword at the same time. Attributes are parsed like variable names and are not considered special by the grammar. Now, there are currently on a fixed set of properties recognized by the compiler, and user-defined attributes don't yet exist, but they aren't keywords.

A rose by any other name... You may label them whatever you want. The fact still is - built-in tributes are reserved words of the language, with special meaning to the compiler. If that is not a keyword, I would like to hear a common definition of keyword that does not include tributes, and a definition of what tributes are in comparison. -- Simen
Sep 25 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Simen kjaeraas <simen.kjaras gmail.com> wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 That said,  tributes are of course keywords too.

No they're not. Go look at the list of keywords in TDPL. property, for instance, is not a keyword. Part of the point of attributes was to make it so that they weren't keywords and therefore didn't make the list of keywords any longer. An attribute can't both not eat up valid identifiers and be a keyword at the same time. Attributes are parsed like variable names and are not considered special by the grammar. Now, there are currently on a fixed set of properties recognized by the compiler, and user-defined attributes don't yet exist, but they aren't keywords.

A rose by any other name... You may label them whatever you want. The fact still is - built-in tributes are reserved words of the language, with special meaning to the compiler. If that is not a keyword, I would like to hear a common definition of keyword that does not include tributes, and a definition of what tributes are in comparison.

To clarify a bit (I hope), any word prefixed with is special to the compiler and the language. It is an error to use an -prefixed identifier anywhere in the code, thus they follow the rules of keywords. -- Simen
Sep 25 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2010/9/25 "J=E9r=F4me M. Berger" <jeberger free.fr>:
 =A0 =A0 =A0 =A0Basically, all it does is defining a namespace for keyword=

 you can't define identifiers with an  , then whenever Walter wants
 to add a new keyword, he only has to pick one that start with   to
 make sure that he won't break anyone's code.

I see. It guess it's good idea to have a namespace for lesser-used keywords to avoid naming conflicts. My first impression was that ttributes were specialized comments, since the absence of property doesn't stop you from using property syntax, and disable just produces a nicer error message from the compiler.
Sep 25 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 September 2010 06:11:25 Michel Fortin wrote:
 On 2010-09-25 08:23:52 -0400, "Simen kjaeraas" <simen.kjaras gmail.com> said:
 A rose by any other name...
 
 You may label them whatever you want. The fact still is - built-in
  tributes are reserved words of the language, with special meaning to
 the compiler. If that is not a keyword, I would like to hear a
 common definition of keyword that does not include  tributes, and a
 definition of what  tributes are in comparison.

Just to add to your point: Objective-C is an extension of C that defines a few more keywords too. Most of which are prefixed with so they don't conflict with anything, yet they're said to be keywords. I concur with Simen: this "attribute" vs. "keyword" thing is just a naming convention. The D community has chosen to call "attributes" the keywords that are prefixed by in an attempt to "reduce" the number of keywords (because some have criticized the increasing number of keywords). True, those "attribute-style keywords" don't take more identifiers as reserved words. But if you dig a little in the DMD source, you'll see there is no difference in how these attributes and other keywords are processed once you have passed the parsing stage, they just become flags on data structures, just like regular keywords often do.

There is a distinct difference between keywords and attributes, but it's certainly true that attributes at this point don't have much semantic difference. The real difference is in the grammar. The fact that you can write a program like this void main() { int property = 7; } is because property is not a keyword. Keywords are specifically words reserved by the compiler and cannot be used as identifiers. What they actually do is irrelevant (heck, goto and const are keywords in Java that aren't used for *anything* - they're just reserved, so you can't use them). Properties don't fall in that category at all, regardless of how they're used semantically, so they definitely aren't keywords. Attributes make a lot more sense when you look at a language like Java which allows for user-defined attributes. At the moment, they only really act as type modifiers similar to pure or static, so they don't end up being particularly different from type modifiers which are keywords. Still, they aren't keywords.
 And to make the matter worse, most attributes are not  attributes [1].
 We have a concept of  attribute at the syntactic level, and another
 totally different concept of attribute at the semantic level.
 
 [1]: http://www.digitalmars.com/d/2.0/attribute.html
 
 At this stage I've lost all hopes of coherency in that part of the
 language. To me, the explanation to differentiate the two is quite
 simple: an historical incident made all new keywords added after a
 certain date use the  attribute syntax.

Even Java has that sort of problem, though differently. For instance, Serialiazable is an interface - which has nothing in it. It just says that that class is allowed to be serialized. It really should be an attribute, but it was put in the language before attributes were. As for D, arguably pretty much any modifier really should be an attribute, but that wouldn't be following what C++, Java, C#, etc have done with static, private, etc. So, anything that is in any of those languages as a keyword is a keyword in D rather than an attribute. That alone makes it so that attributes and modifiers which are keywords will never be consistent. But it's not even consistent with the stuff that D added as to whether it's an attribute or a keyword - pure being a prime example (nothrow at least has the excuse of throws being used in essentially the same context in other languages). Ultimately, it does pretty much come across as later stuff being made into attributes rather than keywords with no overriding principle behind it. But unless we want to break convention with other languages, I don't think that there's much hope of making it consistent anyway. You'd have to make a lot of stuff attributes instead of keywords which would throw people off (like static, public, abstract, etc.) and make it more work to port code. - Jonathan M Davis
Sep 25 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
J=C3=A9r=C3=B4me M. Berger <jeberger free.fr> wrote:

 Jonathan M Davis wrote:

 void main()
 {
     int property =3D 7;
 }

 is because property is not a keyword.

I believe that the point Simen and Michel are trying to make is that although "property" is not a keyword, " property" is. Jerome

Eggzactly. -- = Simen
Sep 25 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 September 2010 18:24:27 Simen kjaeraas wrote:
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 That could be the case - I'd have to look at the grammar or parser to be
 sure -
 but that would be a poor way to do it if you ever intended to have
 user-defined
 attributes. Normally,   would be in the grammar as a separate symbol
 indicating
 that the symbol  immediately followed was an identifier which was an
 attribute.
 It's quite possible, however, that  property is currently treated as a
 single
 symbol which is a keyword. I doubt that it will stay that way in the
 long term
 though, if it is the case.

It appears I have not made my stance on this clear - in my mind, anything that is illegal to use as an identifier, but that is allowed to use in the language, is a keyword (that is roughly my definition, at least). I don't care whether the compiler uses this method or that to determine whether it is a keyword. Perhaps it would be better to use the term 'reserved word' to encompass both keywords and tributes (the latter with the -prefix included).

Well, I'm definitely looking at it from the point of view of the grammar and the parser, and in theory at least, indicates than the identifier which immediately follows is an attribute (so, technically, property would be the attribute, not property - just indicates that the intentifier which follows - in this case, property - is an attribute). As such, they're not keywords. But obviously, you can't use property for something else in your code, so it is reserved in that sense. However, since you can't use in an identifier *anyway*, it's not like it's really costing you anything. Object costs you more when it's not even a keyword (it's just that it's a type which is always defined). By your thinking, Object *would* be considered a keyword, but it isn't as far as the grammar and parser are concerned. And if we ever get user-defined attributes like Java does (we can only hope), then what follows the could be of your own design, and it really won't work to think about property as a single entity any more than it works to think of int x as a single entity. x is an entity which has been defined as type int by the int, It's generally better to think of property as property being an entity which has been defined as an attribute by the . Now, given that D does not currently support user-defined attributes, and given that there is not presently really any difference between type modifiers and attributes (some just so happen to be one as opposed to the other), I can see why you'd think of them like keywords. But being into parsers and grammars and the like and having used attributes in other languages, I tend to be much more exact in how I look at it. - Jonathan M Davis
Sep 25 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:

<Good stuff>

I can see your point of view better now, and I believe
we can conclude that both views have merits, and this
discussion is mostly a waste of time anyways. :p

Thanks for the debate, though. It was fun.

-- 
Simen
Sep 25 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 September 2010 22:59:51 Don wrote:
 Jonathan M Davis wrote:
 On Saturday 25 September 2010 03:23:12 Torarin wrote:
 2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:
 However, we're not going to double the number of keywords that we have,
 and the   syntax has allowed us to remove some keywords and will allow
 us to add more stuff later without having to add keywords.

Why are attributes not considered keywords? Because the compiler doesn't care about them?

Because they don't need to be any more than variable names do. indicates that what follows is an attribute, so the next symbol is parsed as an attribute. If it were a keyword, then it wouldn't compile. keywords are always treated as keywords no matter the context. They show up explicitly in the grammar. Attributes do not show up explicitly in the grammar any more than variables do. The grammar indicates when a symbol is a variable, and it's parsed as variables. The grammar also indicates when a symbol is an attribute, and it's parsed as an attribute. Basically, what it comes down to is that keywords are symbols in the grammar - just like ! or ~ or <. Variable names and attributes are not. Attributes allow us to add more modifiers to stuff (particularly functions) without having to add new keywords. And someday, we may even be able to define attributes in our own code (right now, they're all known by the compiler) - and that's something that you obviously can't do with keywords. - Jonathan M Davis

You can already do that by prefixing with __.

Do you mean that you can use user-defined attributes as long as they're prefixed with _ or that you can use keywords if they're prefixed with _? Prefixing a keyword with _ makes it so that it's a different token, so it's not going to match any keywords. Now, if you mean that you could use your own attributes as long as they start with an underscore (.e.g. _myproperty), then that could be useful, but I don't know how you'd be able to make use of it, since you'd need a way to get at through __traits or std.traits, and functionAttributes() (which is the only function that I see for looking at attributes) isn't string-based but rather flag-based, which means that it won't work with anything but a predefined set of attributes. - Jonathan M Davis
Sep 25 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 26 September 2010 00:56:32 Don wrote:
 I was just referring to the "without having to add new keywords" bit.
 And a fairly general comment to the whole thread (not just this post). I
 meant that __keywords are available, and the argument that   provides a
 namespace for keywords is completely wrong, and utterly dreadful. I'm a
 bit disturbed that people are even thinking in that way.

Well, considering the small list of attributes that we currently have and that there is nothing to really distinguish semantically whether something is a keyword or attribute, they really do come across as a way to add keywords without adding keywords. pure could be pure. property could be property. This was debated previously with regards to what should and shouldn't be an attribute, and in the end, it seems entirely arbitrary. This is completely different from attributes in Java (I don't know about C++0x - I didn't even know that it had attributes; I really should study up on it one of these days soon). If we allowed user-defined attributes, then the nature of attributes in general would be very different from being keywords which aren't keywords, but as it stands, that's pretty much what they are. I totally agree that that's not what attributes should be, but right now, as far as I can tell, that's what they are. - Jonathan M Davis
Sep 26 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sun, 26 Sep 2010 09:26:28 -0400, Michel Fortin wrote:

 On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said:
 
 I was just referring to the "without having to add new keywords" bit.
 And a fairly general comment to the whole thread (not just this post).
 I meant that __keywords are available, and the argument that   provides
 a namespace for keywords is completely wrong, and utterly dreadful. I'm
 a bit disturbed that people are even thinking in that way.

People (including me) are thinking that way because there is no sane semantic definition of what the syntax stands for. I'll grant you one thing: attributes are only used to affect declarations in one way or another, so as long as this stands they're more limited in purpose than keywords in general. But beyond that, what makes different from another namespace for keywords?
 See also the August 28 post by Herb Sutter: http://herbsutter.com/
 
 "My biggest (but not only) beef with C++0x [[attributes]] is that the
 standard itself was abusing attributes as disguised [[keywords]].
 Attributes are acceptable as pure annotations, but they should have no
 semantic effect on the program.
 [snip]
 it’s a clear example of adding language keywords dressed in attributes’
 clothing, and not something I want to be responsible for forcing three
 million C++ developers to live with until the end of time."

Unfortunately, one attribute with the syntax in D -- and I'd say the flagship one as it was the first and most discussed -- is not a pure annotation as it has a noticeable effect on semantics. I'm talking about property which, if it ever get implemented, changes your function so it simulates a field. In Herb's terms, property is clearly a keyword in disguise. And then you realize many keywords fit that same definition of an attribute (deprecated, pure, nothrow...) and you're left with a very fuzzy concept of what the syntax is for. We have an important keyword disguised as an attribute ( property) and attributes disguised as keywords for historical reason (deprecated, pure, nothrow...). Whatever the syntax was supposed to stand for, it's pretty messed up right now. There's also confusion about the term "attribute" itself. Try reading that page and come with a sane definition of what is an attribute in D. <http://digitalmars.com/d/2.0/attribute.html>

This just makes me wonder, why is it so *** hard to get things right? I remember when D didn't have the stuff syntax at all. I wished it worked like annotations in Java or in C#. If I made my own 3rd party lint/ document_generator/unit_test_tool/whatever, and I'd just want a way to decorate some syntax tree nodes. How can it be so hard to do this? Can you use your own annotations now? Probably not. There's only the property syntax, nothing else. The __traits keyword was also supposed to change to 'traits' or something a bit more sane. Nothing really happened. Why am I using this language?
Sep 26 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 26 September 2010 12:34:43 lurker wrote:
 I can't even possibly imagine
 why would anyone (except you) want to use their own keywords. It sounds
 like a new treacherous way to invite dangerous macros to the language. The
 reservation of the word macro without giving an implementation is a
 conscious decision to disable all kinds of over-expressive macros in
 forthcoming versions of the language. Providing customized  ! keywords for
 3rd party tools seems like mocking the damn good state of the art
 meta-programming system D has. If I could design D, I'd use   in front of
 every keyword to avoid namespace collisions with user symbols.

Other languages - like Java - allow user-defined attributes. Certainly in Java, is not at all intended to be a space for creating new keywords. It's intended to be a space for putting attributes of functions and classes and the like. Those attributes are sometimes defined by the compiler ( override for instance) and sometimes created by 3rd party library or you on your own project. For instance, there's a 3rd party library (I forget what it is at the moment - it's been a while since I used it) which allows you to serialize your classes to and from xml using reflection. For that to work correctly, you need to use markup on your classes. So, they have attributes along the lines of xml and xml_transient to indicate things which should or shouldn't be put into xml or how it should be translated into xml. It's _extremely_ useful. A number of libraries in Java use that sort of thing. There are those among us who'd love to have that sort of thing in D. At present, D's attributes are all fixed, and the choice of what is an attribute and what is a keyword is pretty arbitrary such that does come across as another namespace for keywords, but it doesn't have to be that way. Assuming that the grammar is such that indicates that the identifier that follows is an attribute (as opposed to the whole identifier being a keyword), then making it parse 3rd party attributes would be easy. They wouldn't do anything, but they'd be available through reflection (which at the moment, would only be compile-time reflection, but perhaps someday we'll get runtime reflection too), and so you could use __traits and traits to get at them and your libraries could then generate code based on them. It really isn't crazy to want user-defined attributes, and it's not necessarily hard (though if you want user-defined attributes as good as Java's, you'll need more since they allow attributes with parametrs and the like). At some point, Walter may add such a feature. It's obviously not high on his priority list right now (which is fine with me), but it _is_ a feature which many of us think should be in the language. - Jonathan M Davis
Sep 26 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
lurker <lurk lurking.net> wrote:

 Why am I using this language?

There is absolutely no need to use D. In fact some (most?) of us wish that you wouldn't. This answer isn't for you because you implicitly seem to disagree with everything, but here it goes: Designing new keywords is a complicated task. Walter follows a so called parser oriented thinking - what's easy to implement in the parser (the low hanging fruit), seems to be the best solution. If you need other kind of changes to the language, you need to carefully take into consideration (Herb Sutter like C++ thinking) all kinds of aspects such as legacy concerns (C compatibility), namespace issues (__keywords and keywords nicely create new namespaces and don't conflict with user symbols like variables). I can't even possibly imagine why would anyone (except you) want to use their own keywords. It sounds like a new treacherous way to invite dangerous macros to the language.

Well, the tribute syntax has been touted as an extensible property system, where users may possibly throw their own into the mix, and create systems for checking their validity.
 The reservation of the word macro without giving an implementation is a  
 conscious decision to disable all kinds of over-expressive macros in  
 forthcoming versions of the language.

What? The macro keyword has been reserved because future version of D are likely to have an AST macro system, and it would be unfortunate if everyone was already using that symbol in their code.
 Providing customized  keywords for 3rd party tools seems like mocking  
 the damn good state of the art meta-programming system D has.

I believe, but am not sure, that user-defined tributes would require an AST macro system, so that e.g. transitive tributes may be enforced. This is not something D's current MP capabilities cover.
 If I could design D, I'd use   in front of every keyword to avoid  
 namespace collisions with user symbols.

module foo; safe: import std.stdio; class Bar { private: static property pure immutable Bar myBar( ) { try { if ( baz in qux ) { } else { } } catch { } } } Really? Note: it may be that your post was all irony, in which case it was a bit hard to decipher. -- Simen
Sep 26 2010