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;

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-


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).


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
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
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
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
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 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 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 reply "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
next sibling parent reply 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
parent reply "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
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 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
parent reply 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 

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
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Jonathan M Davis wrote:

 There is a distinct difference between keywords and attributes, but it'=


s=20

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


ifference.=20

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


ogram like=20

 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
parent reply "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
parent reply 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


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


=20
 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
parent reply "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
parent reply 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
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 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 parent reply 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
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 parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
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=




nger.

=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
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=


s. 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.


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 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 next sibling 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 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 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.


 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 __.
Sep 25 2010
parent reply 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
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.


 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


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
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 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 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 

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
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 

 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
next 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
prev sibling next sibling 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 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 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

 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