digitalmars.D - The Wrong Stuff
- Walter Bright (9/9) Sep 22 2010 http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-...
- JimBob (10/20) Sep 23 2010 I read an article once where they were explaining how hospitals put a lo...
- bearophile (13/15) Sep 23 2010 It's a very good article, thank you for the link. I think it's a book ch...
- bearophile (4/4) Sep 23 2010 Recently I have read this article by Dennis Shasha and Cathy Lazere, abo...
- Lutger (7/20) Sep 23 2010 business-james-bagian-nasa-astronaut-turned-patient-safety-expert-on-bei...
- Rioshin an'Harthen (19/22) Sep 23 2010 So are you returning to the very bad design error in switch
- Andrei Alexandrescu (4/26) Sep 23 2010 The correct change is not to require break or continue - it's to require...
- Jonathan M Davis (10/40) Sep 23 2010 Indeed, though it might be okay to allow totally empty case statements o...
- Walter Bright (4/7) Sep 23 2010 I'm probably alone in this, but I've always liked the C behavior and nev...
- Andrei Alexandrescu (3/10) Sep 24 2010 Well admitting you're alone in this is the first step to recovery :o).
- lurker (2/15) Sep 24 2010 He's not alone with his view. The automatic implicit porting of C code i...
- Andrei Alexandrescu (4/19) Sep 24 2010 Preventing implicit fall-through is unlikely to affect large portions of...
- Jonathan M Davis (28/48) Sep 24 2010 I don't think that it's ever been the case that we've been all that worr...
- Torarin (3/6) Sep 25 2010 Why are attributes not considered keywords? Because the compiler
- Simen kjaeraas (5/13) Sep 25 2010 Mostly because normal keywords eat up valid identifiers, while @tributes
- Jonathan M Davis (10/23) Sep 25 2010 No they're not. Go look at the list of keywords in TDPL. property, for i...
- Simen kjaeraas (9/24) Sep 25 2010 A rose by any other name...
- Simen kjaeraas (6/30) Sep 25 2010 To clarify a bit (I hope), any word prefixed with @ is special to the
- Michel Fortin (26/33) Sep 25 2010 Just to add to your point: Objective-C is an extension of C that
- Jonathan M Davis (38/71) Sep 25 2010 There is a distinct difference between keywords and attributes, but it's...
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (11/22) Sep 25 2010 ifference.=20
- Simen kjaeraas (4/14) Sep 25 2010 Eggzactly.
- Jonathan M Davis (15/33) Sep 25 2010 That could be the case - I'd have to look at the grammar or parser to be...
- Simen kjaeraas (10/23) Sep 25 2010 It appears I have not made my stance on this clear - in my mind, anythin...
- Jonathan M Davis (26/48) Sep 25 2010 Well, I'm definitely looking at it from the point of view of the grammar...
-
Simen kjaeraas
(8/8)
Sep 25 2010
Jonathan M Davis
wrote: - bearophile (4/6) Sep 25 2010 One thing that later will help is to give a scope to attributes, so if y...
- Torarin (3/5) Sep 25 2010 If they make the attribute list longer, what do you gain from making
- retard (4/10) Sep 25 2010 You make the list shorter, of course ? Some experts claim that that D is...
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (11/17) Sep 25 2010 Basically, all it does is defining a namespace for keywords. Since
- Torarin (7/11) Sep 25 2010 I see. It guess it's good idea to have a namespace for lesser-used
- Daniel Murphy (4/7) Sep 24 2010 I learnt to program in ms batch, so it always seemed perfectly natural t...
- BCS (6/18) Sep 24 2010 In other languages, the solution is to make it not a cases statement but...
- bearophile (24/29) Sep 24 2010 In my opinion empty case fall-through is not significantly bug-prone, so...
- Jonathan M Davis (16/23) Sep 25 2010 Because they don't need to be any more than variable names do. @ indicat...
- Don (2/28) Sep 25 2010 You can already do that by prefixing with __.
- Jonathan M Davis (12/44) Sep 25 2010 Do you mean that you can use user-defined attributes as long as they're ...
- Don (16/59) Sep 26 2010 I was just referring to the "without having to add new keywords" bit.
- Jonathan M Davis (15/20) Sep 26 2010 Well, considering the small list of attributes that we currently have an...
- Michel Fortin (26/42) Sep 26 2010 People (including me) are thinking that way because there is no sane
- Don (5/50) Sep 26 2010 Yeah, it's a big mess. @property is most definitely a keyword. The only
- bearophile (14/17) Sep 26 2010 I think you need:
- retard (10/54) Sep 26 2010 This just makes me wonder, why is it so *** hard to get things right? I
- lurker (3/59) Sep 26 2010 There is absolutely no need to use D. In fact some (most?) of us wish th...
- Simen kjaeraas (29/51) Sep 26 2010 Well, the @tribute syntax has been touted as an extensible property
- Jonathan M Davis (30/39) Sep 26 2010 Other languages - like Java - allow user-defined attributes. Certainly i...
- Justin Johansson (8/12) Sep 27 2010 No need for any confrontational post; Devil's Advocates
- Justin Johansson (11/20) Sep 27 2010 Perhaps you mean "why do you hang around here".
- Bruno Medeiros (7/13) Oct 25 2010 You don't want attributes to affect semantics? That's odd, it seems to
- Michel Fortin (11/23) Oct 25 2010 What I meant is that @property actually *changes* the semantics:
- Bruno Medeiros (12/31) Oct 25 2010 Hum, I think I see what you mean. That being the case, I agree, if an
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
"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
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.aspxIt'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; 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
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
Walter Bright wrote:http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-business-james-bagian-nasa-astronaut-turned-patient-safety-expert-on-being- wrong.aspxtl;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
"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
On 09/23/2010 09:16 PM, Rioshin an'Harthen wrote:"Walter Bright" <newshound2 digitalmars.com> wrote:The correct change is not to require break or continue - it's to require any control flow statement. AndreiErrors 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
On Thursday 23 September 2010 19:27:19 Andrei Alexandrescu wrote:On 09/23/2010 09:16 PM, Rioshin an'Harthen wrote: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"Walter Bright" <newshound2 digitalmars.com> wrote:The correct change is not to require break or continue - it's to require any control flow statement. AndreiErrors 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
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
On 9/23/10 22:59 CDT, Walter Bright wrote:Jonathan M Davis wrote:Well admitting you're alone in this is the first step to recovery :o). AndreiI 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 24 2010
Andrei Alexandrescu Wrote:On 9/23/10 22:59 CDT, Walter Bright wrote: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.Jonathan M Davis wrote:Well admitting you're alone in this is the first step to recovery :o). AndreiI 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 24 2010
On 9/24/10 10:56 CDT, lurker wrote:Andrei Alexandrescu Wrote:Preventing implicit fall-through is unlikely to affect large portions of C code, and will never compile programs with different semantics. AndreiOn 9/23/10 22:59 CDT, Walter Bright wrote: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.Jonathan M Davis wrote:Well admitting you're alone in this is the first step to recovery :o). AndreiI 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 24 2010
On Friday, September 24, 2010 08:56:22 lurker wrote:Andrei Alexandrescu Wrote: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 DavisOn 9/23/10 22:59 CDT, Walter Bright wrote: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.Jonathan M Davis wrote:Well admitting you're alone in this is the first step to recovery :o). AndreiI 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 24 2010
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
Torarin <torarind gmail.com> wrote:2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:Mostly because normal keywords eat up valid identifiers, while tributes don't. That said, tributes are of course keywords too. -- SimenHowever, 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
On Saturday 25 September 2010 03:28:35 Simen kjaeraas wrote:Torarin <torarind gmail.com> wrote: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 Davis2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>:Mostly because normal keywords eat up valid identifiers, while tributes don't. That said, tributes are of course keywords too.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
Jonathan M Davis <jmdavisProg gmx.com> wrote: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. -- SimenThat 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.
Sep 25 2010
Simen kjaeraas <simen.kjaras gmail.com> wrote:Jonathan M Davis <jmdavisProg gmx.com> wrote: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. -- SimenA 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.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.
Sep 25 2010
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
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: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.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.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 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
Jonathan M Davis wrote:There is a distinct difference between keywords and attributes, but it'=s=20certainly true that attributes at this point don't have much semantic d=ifference.=20The real difference is in the grammar. The fact that you can write a pr=ogram like=20this =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
J=C3=A9r=C3=B4me M. Berger <jeberger free.fr> wrote:Jonathan M Davis wrote:Eggzactly. -- = Simenvoid 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
Sep 25 2010
On Saturday 25 September 2010 14:25:47 Simen kjaeraas wrote:J=C3=A9r=C3=B4me M. Berger <jeberger free.fr> wrote: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 DavisJonathan M Davis wrote:=20 Eggzactly.void main() { =20 int property =3D 7; =20 } =20 is because property is not a keyword. =20I believe that the point Simen and Michel are trying to make is =20 that although "property" is not a keyword, " property" is. =20 Jerome
Sep 25 2010
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
On Saturday 25 September 2010 18:24:27 Simen kjaeraas wrote:Jonathan M Davis <jmdavisProg gmx.com> wrote: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 DavisThat 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).
Sep 25 2010
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
Jonathan M DavisUltimately, 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
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
Sat, 25 Sep 2010 13:34:10 +0200, Torarin wrote:2010/9/25 Jonathan M Davis <jmdavisProg gmx.com>: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.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
Torarin wrote:2010/9/25 Jonathan M Davis <jmdavisProg gmx.com>:nger.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
2010/9/25 "J=E9r=F4me M. Berger" <jeberger free.fr>:=A0 =A0 =A0 =A0Basically, all it does is defining a namespace for keyword=s. Sinceyou 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
"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
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
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
On Saturday 25 September 2010 03:23:12 Torarin wrote:2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>: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 DavisHowever, 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
Jonathan M Davis wrote:On Saturday 25 September 2010 03:23:12 Torarin wrote:You can already do that by prefixing with __.2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>: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 DavisHowever, 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
On Saturday 25 September 2010 22:59:51 Don wrote:Jonathan M Davis wrote: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 DavisOn Saturday 25 September 2010 03:23:12 Torarin wrote:You can already do that by prefixing with __.2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>: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 DavisHowever, 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
Jonathan M Davis wrote:On Saturday 25 September 2010 22:59:51 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. 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."Jonathan M Davis wrote: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 DavisOn Saturday 25 September 2010 03:23:12 Torarin wrote:You can already do that by prefixing with __.2010/9/24 Jonathan M Davis <jmdavisProg gmx.com>: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 DavisHowever, 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 26 2010
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
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
Michel Fortin wrote:On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said: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.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>
Sep 26 2010
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
Sun, 26 Sep 2010 09:26:28 -0400, Michel Fortin wrote:On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said: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 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?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>
Sep 26 2010
retard Wrote:Sun, 26 Sep 2010 09:26:28 -0400, Michel Fortin wrote: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.On 2010-09-26 03:56:32 -0400, Don <nospam nospam.com> said: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 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?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>
Sep 26 2010
lurker <lurk lurking.net> wrote: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.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.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
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
On 27/09/2010 5:34 AM, lurker wrote:retard Wrote: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 JohanssonWhy am I using this language?There is absolutely no need to use D. In fact some (most?) of us wish that you wouldn't.
Sep 27 2010
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 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
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
On 2010-10-25 10:32:45 -0400, Bruno Medeiros <brunodomedeiros+spam com.gmail> said:On 26/09/2010 14:26, Michel Fortin wrote: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/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" ?
Oct 25 2010
On 25/10/2010 16:01, Michel Fortin wrote:On 2010-10-25 10:32:45 -0400, Bruno Medeiros <brunodomedeiros+spam com.gmail> said: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 EngineerOn 26/09/2010 14:26, Michel Fortin wrote: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.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" ?
Oct 25 2010