www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Contextualizing keywords

reply Robert Fraser <fraserofthenight gmail.com> writes:
Hi, hope you're all enjoying the properties debate.

I've been seeing the "too many keywords" argument a lot lately, and I 
think it's definitely a valid argument. "shared" and "body" in 
particular are rather annoying keywords since I frequently use them in 
code. And if users are deciding not to use D because of the number of 
keywords, that's even worse.

The idea of "kewyord" as a parser construct is antiquated thinking. Look 

a particular context. C++/CLI takes it a step further (from 
http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx ). There are 
three new reserved words ("gcnew", "generic", "nullptr") and a few 
multi-word keywords ("for each", "enum/interface/ref/value 
class/struct") as well as some contextual keywords that can only appear 
in certain positions.

In D, without a significant change to the lexer/parser, any keywords 
that cannot appear in the same place as an identifier could be made 
legal identifiers easily. Off the top of my head, "in", "out", "body", 
"module", "unittest", "import", "throw" and probably a few others could 
be freed up.

With some parser lookahead, you could add modifiers and storage classes 
to the list and probably dozens of others. If braces were required in 
try/catch statements, "try", "catch", and "finally" could be added.

Further, this might be pretty easy to implement (i.e. Walter, if you're 
interested, I'm willing to make a patch). It's all backwards-compatible 
and would even work in D1.

Thoughts?
Aug 02 2009
next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Robert Fraser wrote:

 Hi, hope you're all enjoying the properties debate.
 
 I've been seeing the "too many keywords" argument a lot lately, and I
 think it's definitely a valid argument. "shared" and "body" in
 particular are rather annoying keywords since I frequently use them in
 code. And if users are deciding not to use D because of the number of
 keywords, that's even worse.
 
 The idea of "kewyord" as a parser construct is antiquated thinking. Look

 a particular context. C++/CLI takes it a step further (from
 http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx ). There are
 three new reserved words ("gcnew", "generic", "nullptr") and a few
 multi-word keywords ("for each", "enum/interface/ref/value
 class/struct") as well as some contextual keywords that can only appear
 in certain positions.
 
 In D, without a significant change to the lexer/parser, any keywords
 that cannot appear in the same place as an identifier could be made
 legal identifiers easily. Off the top of my head, "in", "out", "body",
 "module", "unittest", "import", "throw" and probably a few others could
 be freed up.
 
 With some parser lookahead, you could add modifiers and storage classes
 to the list and probably dozens of others. If braces were required in
 try/catch statements, "try", "catch", and "finally" could be added.
 
 Further, this might be pretty easy to implement (i.e. Walter, if you're
 interested, I'm willing to make a patch). It's all backwards-compatible
 and would even work in D1.
 
 Thoughts?


This makes things more difficult for syntax highlighters.  A number of
them will just not work correctly because they don't actually parse the
code.
That's all I've got.
Aug 02 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.


That's true. Another thing keywords provide are "anchors" that enable 
better error recovery.
Aug 02 2009
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.


 
 That's true. Another thing keywords provide are "anchors" that enable 
 better error recovery.


Read Herb's article; he mentions error recovery. I agree that the ";" at 
the end of the line is a useful anchor, but in the position "in" "out" 
and "body" can appear, the ONLY valid words are in, out, body, const, 
immutable, shared, pure, nothrow, etc. So the error messages for these 
ones won't get much worse.

For category 3 (keywords that can appear where identifiers can), I agree 
it could get confusing. But at least category 1 (keywords that cannot 
appear in the same place as identifiers) would be little loss.
Aug 02 2009
prev sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Aug 2, 2009 at 9:30 PM, Walter Bright<newshound1 digitalmars.com> w=
rote:

 Chad J wrote:

 This makes things more difficult for syntax highlighters. =A0A number of
 them will just not work correctly because they don't actually parse the
 code.


 That's true. Another thing keywords provide are "anchors" that enable bet=


ter

 error recovery.


I've often wondered about how useful parser recovery really is.  Most
of the time, parsing errors after the first are complete bull anyway,
so the compiler's just filling up my console with garbage.  If you
combine that with the fact that recompiles are extremely cheap with D
and modern machines, and that D's module organization limits the scope
of parsing errors to a single file (instead of with C/C++, where a
parsing error in a header can cascade into a number of following
headers and the source), I wonder how useful it really is to continue
to try to parse after the first error.
Aug 02 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley escribió:

 On Sun, Aug 2, 2009 at 9:30 PM, Walter Bright<newshound1 digitalmars.com>
wrote:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.


 That's true. Another thing keywords provide are "anchors" that enable better
 error recovery.


 
 I've often wondered about how useful parser recovery really is.  Most
 of the time, parsing errors after the first are complete bull anyway,
 so the compiler's just filling up my console with garbage.  If you
 combine that with the fact that recompiles are extremely cheap with D
 and modern machines, and that D's module organization limits the scope
 of parsing errors to a single file (instead of with C/C++, where a
 parsing error in a header can cascade into a number of following
 headers and the source), I wonder how useful it really is to continue
 to try to parse after the first error.


At least it's useful in an IDE, because it doesn't break your outline, 
autocompletion can still work, etc. So I'm glad DMD's parser has error 
recovery. :-)

What I don't like is that one semantic error leads to five other 
semantic errors, and it's hard to track what the problem really is.
Aug 02 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Aug 3, 2009 at 12:00 AM, Ary Borenszweig<ary esperanto.org.ar> wrot=
e:

 Jarrett Billingsley escribi=F3:

 On Sun, Aug 2, 2009 at 9:30 PM, Walter Bright<newshound1 digitalmars.com=



 wrote:

 Chad J wrote:

 This makes things more difficult for syntax highlighters. =A0A number =








of

 them will just not work correctly because they don't actually parse th=








e

 code.


 That's true. Another thing keywords provide are "anchors" that enable
 better
 error recovery.


 I've often wondered about how useful parser recovery really is. =A0Most
 of the time, parsing errors after the first are complete bull anyway,
 so the compiler's just filling up my console with garbage. =A0If you
 combine that with the fact that recompiles are extremely cheap with D
 and modern machines, and that D's module organization limits the scope
 of parsing errors to a single file (instead of with C/C++, where a
 parsing error in a header can cascade into a number of following
 headers and the source), I wonder how useful it really is to continue
 to try to parse after the first error.


 At least it's useful in an IDE, because it doesn't break your outline,
 autocompletion can still work, etc. So I'm glad DMD's parser has error
 recovery. :-)


Why would you care about that?  ;)


 What I don't like is that one semantic error leads to five other semantic
 errors, and it's hard to track what the problem really is.


All compiler error recovery is bound to give some (or several) false
positives.  At least with semantic errors, the errors are localized
within a single class, function, brace block, or expression, and it's
much easier to recover from them.  Parsing errors are much more
difficult to recover from, since you can't really make any assumptions
about what comes next when you read some malformed code; and as a
result, the false positive rate on subsequent parsing errors is much
higher.
Aug 02 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Aug 3, 2009 at 12:43 AM, Nick Sabalausky<a a.a> wrote:

 "Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message
 news:mailman.272.1249267359.14071.digitalmars-d puremagic.com...


 I've often wondered about how useful parser recovery really is. =A0Most
 of the time, parsing errors after the first are complete bull anyway,
 so the compiler's just filling up my console with garbage.
 <

 Frequently, yes, but I find that getting numerous *real* errors from one
 compile is also a frequent occurrance - and a real time saver. I get real=


ly

 annoyed when I get into a 5-10 iteration cycle of "fix the one reported
 error, recompile, get one more error, fix that, etc..."


 If you


 combine that with the fact that recompiles are extremely cheap with D
 and modern machines,
 <

 That actual recompile is often (though not always) short, but the total
 programmer time is much higher. I find that the whole process goes *much*
 faster overall when I do get a bunch of real errors at once than when I j=


ust

 get one at a time.


Oh, I agree that multiple errors on a single compile is useful.  But
multiple *parser* errors on a single compile is next to useless, since
the parser can very easily get confused at the beginning of some
malformed code and start throwing up all kinds of crap.  Try this:

void foo()
{
    bar() // no semicolon
}

DMD spits out a semicolon expected, followed by several useless "found
EOF instead of statement" errors at the end of the file.  This is by
no means the only parser error BS, but it's the one I can think of off
the top of my head.

Once it's parsed, though, it's easy (and useful!) to flag multiple
semantic errors on a single compile.



 Aug 02 2009



prev sibling  parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.
 That's all I've got.


Ehhh.... How often will you actually use the identifiers? The point 
isn't to make them free for use, it's more to reduce the number of 
people bitching about how many keywords there are.



 Aug 02 2009



  parent reply Oliver Hoog <kingboscop gmail.com>  writes:


Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.
 That's all I've got.


 
 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


I guess they would still keep complaining since the number of available 
keywords to be remembered doesn't decrease.



 Aug 02 2009



  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 
 I guess they would still keep complaining since the number of available 
 keywords to be remembered doesn't decrease.


There are a million words in the English language, so it's not likely 
that we'll run short of identifier space in the conceivable future :-)

The real problem is remembering the keywords.



 Aug 02 2009



 next sibling parent  Ary Borenszweig <ary esperanto.org.ar>  writes:


Walter Bright escribió:

 Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 I guess they would still keep complaining since the number of 
 available keywords to be remembered doesn't decrease.


 
 There are a million words in the English language, so it's not likely 
 that we'll run short of identifier space in the conceivable future :-)
 
 The real problem is remembering the keywords.


"Hmmm... I want to define a property... but... can't... remember... 
the... keyword... was it 'property' or something like that? I keep 
forgetting..."



 Aug 02 2009



prev sibling  parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Walter Bright wrote:

 Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 I guess they would still keep complaining since the number of 
 available keywords to be remembered doesn't decrease.


 
 There are a million words in the English language, so it's not likely 
 that we'll run short of identifier space in the conceivable future :-)
 
 The real problem is remembering the keywords.


Eh? I disagree -- think about how many uses of "static" there are, or 
the wars about "enum". Overloading keywords is MUCH more confusing than 
reserving another word.



 Aug 02 2009



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Robert Fraser wrote:

 Walter Bright wrote:

 Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse 
 the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 I guess they would still keep complaining since the number of 
 available keywords to be remembered doesn't decrease.


 There are a million words in the English language, so it's not likely 
 that we'll run short of identifier space in the conceivable future :-)

 The real problem is remembering the keywords.


 
 Eh? I disagree -- think about how many uses of "static" there are, or 
 the wars about "enum". Overloading keywords is MUCH more confusing than 
 reserving another word.


Confession:

I've never, ever been confused by the use of "static". Not even once, 
and not even when I was a complete beginner. I have always taken in the 
numerous jokes related to "static" with the politely faked, resigned 
smile of someone who knows will never really "get" it. And deep in my 
heart of hearts, whenever a "static" joke comes about, the belief that 
I'm an outcast sinks in a bit deeper.

Guess it's time for me to join the Static-Impaired Anonymous...


Andrei



 Aug 02 2009



 next sibling parent reply Max Samukha <spambox d-coding.com>  writes:


On Mon, 03 Aug 2009 01:41:53 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


Robert Fraser wrote:

 Walter Bright wrote:

 Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse 
 the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 I guess they would still keep complaining since the number of 
 available keywords to be remembered doesn't decrease.


 There are a million words in the English language, so it's not likely 
 that we'll run short of identifier space in the conceivable future :-)

 The real problem is remembering the keywords.


 
 Eh? I disagree -- think about how many uses of "static" there are, or 
 the wars about "enum". Overloading keywords is MUCH more confusing than 
 reserving another word.


Confession:

I've never, ever been confused by the use of "static". Not even once, 
and not even when I was a complete beginner. I have always taken in the 
numerous jokes related to "static" with the politely faked, resigned 
smile of someone who knows will never really "get" it. And deep in my 
heart of hearts, whenever a "static" joke comes about, the belief that 
I'm an outcast sinks in a bit deeper.

Guess it's time for me to join the Static-Impaired Anonymous...


Andrei


I dare say I don't believe you. What about static (aka fixed-size)
arrays that can be allocated non-statically on stack or statically in
the static data segment? So we have static static arrays and static
non-static arrays. If it's not a confusion, I don't know what it is.

The D specs at
http://www.digitalmars.com/d/2.0/arrays.html#static-arrays continue
the tradition. Please read "Static Initialization of Static Arrays".
The section confusingly claims that static arrays are not static when
they appear in a local context without 'static' modifier.



 Aug 03 2009



  parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


Max Samukha escribió:

 On Mon, 03 Aug 2009 01:41:53 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Robert Fraser wrote:

 Walter Bright wrote:

 Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse 
 the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 I guess they would still keep complaining since the number of 
 available keywords to be remembered doesn't decrease.


 There are a million words in the English language, so it's not likely 
 that we'll run short of identifier space in the conceivable future :-)

 The real problem is remembering the keywords.


 Eh? I disagree -- think about how many uses of "static" there are, or 
 the wars about "enum". Overloading keywords is MUCH more confusing than 
 reserving another word.


 Confession:

 I've never, ever been confused by the use of "static". Not even once, 
 and not even when I was a complete beginner. I have always taken in the 
 numerous jokes related to "static" with the politely faked, resigned 
 smile of someone who knows will never really "get" it. And deep in my 
 heart of hearts, whenever a "static" joke comes about, the belief that 
 I'm an outcast sinks in a bit deeper.

 Guess it's time for me to join the Static-Impaired Anonymous...


 Andrei


 
 I dare say I don't believe you. What about static (aka fixed-size)
 arrays that can be allocated non-statically on stack or statically in
 the static data segment? So we have static static arrays and static
 non-static arrays. If it's not a confusion, I don't know what it is.
 
 The D specs at
 http://www.digitalmars.com/d/2.0/arrays.html#static-arrays continue
 the tradition. Please read "Static Initialization of Static Arrays".
 The section confusingly claims that static arrays are not static when
 they appear in a local context without 'static' modifier.


What does that mean? I don't get it...



 Aug 03 2009



  parent  Max Samukha <spambox d-coding.com>  writes:


On Mon, 03 Aug 2009 09:10:49 -0300, Ary Borenszweig
<ary esperanto.org.ar> wrote:


Max Samukha escribi?:

 On Mon, 03 Aug 2009 01:41:53 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Robert Fraser wrote:

 Walter Bright wrote:

 Oliver Hoog wrote:

 Robert Fraser schrieb:

 Chad J wrote:

 This makes things more difficult for syntax highlighters.  A number of
 them will just not work correctly because they don't actually parse 
 the
 code.
 That's all I've got.


 Ehhh.... How often will you actually use the identifiers? The point 
 isn't to make them free for use, it's more to reduce the number of 
 people bitching about how many keywords there are.


 I guess they would still keep complaining since the number of 
 available keywords to be remembered doesn't decrease.


 There are a million words in the English language, so it's not likely 
 that we'll run short of identifier space in the conceivable future :-)

 The real problem is remembering the keywords.


 Eh? I disagree -- think about how many uses of "static" there are, or 
 the wars about "enum". Overloading keywords is MUCH more confusing than 
 reserving another word.


 Confession:

 I've never, ever been confused by the use of "static". Not even once, 
 and not even when I was a complete beginner. I have always taken in the 
 numerous jokes related to "static" with the politely faked, resigned 
 smile of someone who knows will never really "get" it. And deep in my 
 heart of hearts, whenever a "static" joke comes about, the belief that 
 I'm an outcast sinks in a bit deeper.

 Guess it's time for me to join the Static-Impaired Anonymous...


 Andrei


 
 I dare say I don't believe you. What about static (aka fixed-size)
 arrays that can be allocated non-statically on stack or statically in
 the static data segment? So we have static static arrays and static
 non-static arrays. If it's not a confusion, I don't know what it is.
 
 The D specs at
 http://www.digitalmars.com/d/2.0/arrays.html#static-arrays continue
 the tradition. Please read "Static Initialization of Static Arrays".
 The section confusingly claims that static arrays are not static when
 they appear in a local context without 'static' modifier.


What does that mean? I don't get it...


void foo()
{
    int[4] a; // static (fixed-size, not dynamic) array
    static int[4] b; // static (allocated in the static data segment)
and static (fixed-size) array;  
}

Here we have two absolutely unrelated concepts denoted by 'static':
1. Having a length fixed at compile time
2. Allocated in the data segment

When they are shoved together, they make things confusing, just like
in "Static Initialization of Static Arrays" where the second 'static'
in the title refers to either 1 or 2, or both, but not to the static
arrays allocated on stack, while 'static' in the title and contents of
"Static Arrays" section refers to 1 and covers all static arrays
including those allocated on stack.



 Aug 03 2009



prev sibling  parent  Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Mon, Aug 3, 2009 at 2:41 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 I've never, ever been confused by the use of "static". Not even once, and
 not even when I was a complete beginner. I have always taken in the numerous
 jokes related to "static" with the politely faked, resigned smile of someone
 who knows will never really "get" it. And deep in my heart of hearts,
 whenever a "static" joke comes about, the belief that I'm an outcast sinks
 in a bit deeper.


Same here, but it's still fun to poke at it ;)



 Aug 03 2009



prev sibling next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Sun, Aug 02, 2009 at 08:27:19AM -0700, Robert Fraser wrote:

 If braces were required in 
 try/catch statements, "try", "catch", and "finally" could be added.


I'm against that - it makes quick try/catch blocks a little harder to type,
for very, very little benefit.

-- 
Adam D. Ruppe
http://arsdnet.net



 Aug 02 2009



prev sibling next sibling parent reply Oliver Hoog <kingboscop gmail.com>  writes:


Robert Fraser schrieb:

 Hi, hope you're all enjoying the properties debate.
 
 I've been seeing the "too many keywords" argument a lot lately, and I 
 think it's definitely a valid argument. "shared" and "body" in 
 particular are rather annoying keywords since I frequently use them in 
 code. And if users are deciding not to use D because of the number of 
 keywords, that's even worse.
 
 The idea of "kewyord" as a parser construct is antiquated thinking. Look 

 a particular context. C++/CLI takes it a step further (from 
 http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx ). There are 
 three new reserved words ("gcnew", "generic", "nullptr") and a few 
 multi-word keywords ("for each", "enum/interface/ref/value 
 class/struct") as well as some contextual keywords that can only appear 
 in certain positions.
 
 In D, without a significant change to the lexer/parser, any keywords 
 that cannot appear in the same place as an identifier could be made 
 legal identifiers easily. Off the top of my head, "in", "out", "body", 
 "module", "unittest", "import", "throw" and probably a few others could 
 be freed up.
 
 With some parser lookahead, you could add modifiers and storage classes 
 to the list and probably dozens of others. If braces were required in 
 try/catch statements, "try", "catch", and "finally" could be added.
 
 Further, this might be pretty easy to implement (i.e. Walter, if you're 
 interested, I'm willing to make a patch). It's all backwards-compatible 
 and would even work in D1.
 
 Thoughts?


Of the keywords mentioned, I only needed "body" in the past. And (maybe 
except for "in" and "out") I don't think I would ever need the others. 
Freeing them is generally good though. But if it slows down compilation 
time, I would rather have it as it is. And requiring try/catch to have 
braces introduces inconsistency.



 Aug 02 2009



 next sibling parent  Oliver Hoog <kingboscop gmail.com>  writes:


Oliver Hoog schrieb:

 Robert Fraser schrieb:

 Hi, hope you're all enjoying the properties debate.

 I've been seeing the "too many keywords" argument a lot lately, and I 
 think it's definitely a valid argument. "shared" and "body" in 
 particular are rather annoying keywords since I frequently use them in 
 code. And if users are deciding not to use D because of the number of 
 keywords, that's even worse.

 The idea of "kewyord" as a parser construct is antiquated thinking. 

 keywords in a particular context. C++/CLI takes it a step further 
 (from http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx ). 
 There are three new reserved words ("gcnew", "generic", "nullptr") and 
 a few multi-word keywords ("for each", "enum/interface/ref/value 
 class/struct") as well as some contextual keywords that can only 
 appear in certain positions.

 In D, without a significant change to the lexer/parser, any keywords 
 that cannot appear in the same place as an identifier could be made 
 legal identifiers easily. Off the top of my head, "in", "out", "body", 
 "module", "unittest", "import", "throw" and probably a few others 
 could be freed up.

 With some parser lookahead, you could add modifiers and storage 
 classes to the list and probably dozens of others. If braces were 
 required in try/catch statements, "try", "catch", and "finally" could 
 be added.

 Further, this might be pretty easy to implement (i.e. Walter, if 
 you're interested, I'm willing to make a patch). It's all 
 backwards-compatible and would even work in D1.

 Thoughts?


 
 Of the keywords mentioned, I only needed "body" in the past. And (maybe 
 except for "in" and "out") I don't think I would ever need the others. 
 Freeing them is generally good though. But if it slows down compilation 
 time, I would rather have it as it is. And requiring try/catch to have 
 braces introduces inconsistency.


Besides, I find it easier to read source code when keywords are only 
used as keywords. Not only because of possible syntax-highlighting errors.



 Aug 02 2009



prev sibling  parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Oliver Hoog wrote:

  And requiring try/catch to have
 braces introduces inconsistency.


That was probably a bad idea. However note that D is actually the 




 Aug 02 2009



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Sun, Aug 02, 2009 at 07:05:01PM -0700, Robert Fraser wrote:

 Oliver Hoog wrote:
 That was probably a bad idea. However note that D is actually the 



The inconsistency is with D itself: for, foreach, while, if, etc., don't
require braces. Why should try?


-- 
Adam D. Ruppe
http://arsdnet.net



 Aug 02 2009



prev sibling next sibling parent reply Don <nospam nospam.com>  writes:


Robert Fraser wrote:

 Hi, hope you're all enjoying the properties debate.
 
 I've been seeing the "too many keywords" argument a lot lately, and I 
 think it's definitely a valid argument. "shared" and "body" in 
 particular are rather annoying keywords since I frequently use them in 
 code. And if users are deciding not to use D because of the number of 
 keywords, that's even worse.


Why not just get rid of 'body'?

'body' is the most useless keyword in D. It's ugly, and doesn't achieve 
anything much at all -- it's just a compiler-checked comment, really.
Almost identical to // body

Compare:
----------------------
int foo(int a)
in {
    assert(a>2);
}
body
{
    return a-1;
}
----------------------
int foo(int a)
in {
    assert(a>2);
}
// body
{
    return a-1;
}
----------------------

That's a ridiculously tiny benefit for a keyword. I hate my body.
<g>



 Aug 03 2009



 next sibling parent reply Pete <example example.com>  writes:


Don Wrote:


 Robert Fraser wrote:

 Hi, hope you're all enjoying the properties debate.
 
 I've been seeing the "too many keywords" argument a lot lately, and I 
 think it's definitely a valid argument. "shared" and "body" in 
 particular are rather annoying keywords since I frequently use them in 
 code. And if users are deciding not to use D because of the number of 
 keywords, that's even worse.


 
 Why not just get rid of 'body'?
 
 'body' is the most useless keyword in D. It's ugly, and doesn't achieve 
 anything much at all -- it's just a compiler-checked comment, really.
 Almost identical to // body
 
 Compare:
 ----------------------
 int foo(int a)
 in {
     assert(a>2);
 }
 body
 {
     return a-1;
 }
 ----------------------
 int foo(int a)
 in {
     assert(a>2);
 }
 // body
 {
     return a-1;
 }
 ----------------------
 
 That's a ridiculously tiny benefit for a keyword. I hate my body.
 <g>


I think this is much more elegant:











 Aug 03 2009



  parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com>  writes:


Pete wrote:


 I think this is much more elegant:
 









I have to disagree. That suggests that 'in' is a scope within the body,
which would have access to its local variables. Of course, it shouldn't.

-- 
Michiel Helvensteijn



 Aug 03 2009



  parent reply Don <nospam nospam.com>  writes:


Michiel Helvensteijn wrote:

 Pete wrote:
 

 I think this is much more elegant:










 
 I have to disagree. That suggests that 'in' is a scope within the body,
 which would have access to its local variables. Of course, it shouldn't.


If you make 'in' clauses 'pure' (which they are, conceptually), it works 
fine.

I agree with Pete, I think that's a greatly superior syntax to what we 
have now.



 Aug 03 2009



  parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com>  writes:


 I think this is much more elegant:










 
 I have to disagree. That suggests that 'in' is a scope within the body,
 which would have access to its local variables. Of course, it shouldn't.


 
 If you make 'in' clauses 'pure' (which they are, conceptually), it works
 fine.


But 'in' still needs read-access to the actual parameters and every visible
symbol in a scope shallower than that of the function.


 I agree with Pete, I think that's a greatly superior syntax to what we
 have now.


Then I assume you still want to restrict the precondition to being the first
element in the body? Because putting it in there suggests that it may
appear anywhere a statement can.

-- 
Michiel Helvensteijn



 Aug 03 2009



  parent reply "Denis Koroskin" <2korden gmail.com>  writes:


On Mon, 03 Aug 2009 15:53:03 +0400, Michiel Helvensteijn  
<m.helvensteijn.remove gmail.com> wrote:


 I think this is much more elegant:










 I have to disagree. That suggests that 'in' is a scope within the body,
 which would have access to its local variables. Of course, it  
 shouldn't.


 If you make 'in' clauses 'pure' (which they are, conceptually), it works
 fine.


 But 'in' still needs read-access to the actual parameters and every  
 visible
 symbol in a scope shallower than that of the function.


 I agree with Pete, I think that's a greatly superior syntax to what we
 have now.


 Then I assume you still want to restrict the precondition to being the  
 first
 element in the body? Because putting it in there suggests that it may
 appear anywhere a statement can.


Why not?



 Aug 03 2009



  parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com>  writes:


Denis Koroskin wrote:


 Then I assume you still want to restrict the precondition to being the
 first element in the body? Because putting it in there suggests that it
 may appear anywhere a statement can.


 
 Why not?


Because a function precondition indicates the set of admissible states
before execution of a function. Emphasis on *before* and *function*.

-- 
Michiel Helvensteijn



 Aug 03 2009



 next sibling parent reply "Denis Koroskin" <2korden gmail.com>  writes:


On Mon, 03 Aug 2009 16:22:40 +0400, Michiel Helvensteijn  
<m.helvensteijn.remove gmail.com> wrote:


 Denis Koroskin wrote:


 Then I assume you still want to restrict the precondition to being the
 first element in the body? Because putting it in there suggests that it
 may appear anywhere a statement can.


 Why not?


 Because a function precondition indicates the set of admissible states
 before execution of a function. Emphasis on *before* and *function*.


Allowing them anywhere inside a function body will only improve the  
feature.

BTW, it is already allowed, just use 'debug' instead of 'in':

Suggested way:


 int foo(int a) {
    in {
       assert(a>2);
    }

    return a-1;
 }


My way:

int foo(int a) {
    debug {
       assert(a>2);
    }
    return a-1;
}

TBH, I'd just drop the whole DBC feature from a language, it creates more  
problems than solves.



 Aug 03 2009



 next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com>  writes:


Denis Koroskin wrote:


 Because a function precondition indicates the set of admissible states
 before execution of a function. Emphasis on *before* and *function*.


 
 Allowing them anywhere inside a function body will only improve the
 feature.
 
 BTW, it is already allowed, just use 'debug' instead of 'in':


Or just use an assertion without an enclosing scope?

The difference between a precondition (in) and an arbitrary assertion inside
the function body is that the precondition is part of the public interface,
whereas the function implementation is not.


 TBH, I'd just drop the whole DBC feature from a language, it creates more
 problems than solves.


I, on the other hand, believe it's the future of program verification.

-- 
Michiel Helvensteijn



 Aug 03 2009



  parent reply Oliver Hoog <kingboscop gmail.com>  writes:


Michiel Helvensteijn schrieb:

 Denis Koroskin wrote:
 

 Because a function precondition indicates the set of admissible states
 before execution of a function. Emphasis on *before* and *function*.


 Allowing them anywhere inside a function body will only improve the
 feature.

 BTW, it is already allowed, just use 'debug' instead of 'in':


 
 Or just use an assertion without an enclosing scope?
 
 The difference between a precondition (in) and an arbitrary assertion inside
 the function body is that the precondition is part of the public interface,
 whereas the function implementation is not.
 

 TBH, I'd just drop the whole DBC feature from a language, it creates more
 problems than solves.


 
 I, on the other hand, believe it's the future of program verification.
 


I also find them very useful with inherited functions.
That they can be inherited wouldn't be intuitive (and not as easily 
possible) with an 'in' block nested into the function block.



 Aug 03 2009



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Oliver Hoog wrote:

 Michiel Helvensteijn schrieb:

 Denis Koroskin wrote:


 Because a function precondition indicates the set of admissible states
 before execution of a function. Emphasis on *before* and *function*.


 Allowing them anywhere inside a function body will only improve the
 feature.

 BTW, it is already allowed, just use 'debug' instead of 'in':


 Or just use an assertion without an enclosing scope?

 The difference between a precondition (in) and an arbitrary assertion 
 inside
 the function body is that the precondition is part of the public 
 interface,
 whereas the function implementation is not.


 TBH, I'd just drop the whole DBC feature from a language, it creates 
 more
 problems than solves.


 I, on the other hand, believe it's the future of program verification.


 
 I also find them very useful with inherited functions.
 That they can be inherited wouldn't be intuitive (and not as easily 
 possible) with an 'in' block nested into the function block.


And that's not even an option for interfaces that have "in" blocks, 
something not implemented.

By and large, my opinion is that either we implement DbC correctly (with 
contract inheritance) or we drop it from the language. As of now it's 
completely redundant.


Andrei



 Aug 04 2009



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Denis Koroskin wrote:

 On Mon, 03 Aug 2009 16:22:40 +0400, Michiel Helvensteijn 
 <m.helvensteijn.remove gmail.com> wrote:
 

 Denis Koroskin wrote:


 Then I assume you still want to restrict the precondition to being the
 first element in the body? Because putting it in there suggests that it
 may appear anywhere a statement can.


 Why not?


 Because a function precondition indicates the set of admissible states
 before execution of a function. Emphasis on *before* and *function*.


 
 Allowing them anywhere inside a function body will only improve the 
 feature.
 
 BTW, it is already allowed, just use 'debug' instead of 'in':
 
 Suggested way:
 

 int foo(int a) {
    in {
       assert(a>2);
    }

    return a-1;
 }


 
 My way:
 
 int foo(int a) {
    debug {
       assert(a>2);
    }
    return a-1;
 }
 
 TBH, I'd just drop the whole DBC feature from a language, it creates 
 more problems than solves.


I think the interesting uses are when you can e.g. specify constraints 
on an interface, inherit them, add to them in derived classes etc. What 
DbC support is in the language so far adds very little compared to debug 
and scope(success).

Andrei



 Aug 03 2009



prev sibling  parent reply Don <nospam nospam.com>  writes:


Michiel Helvensteijn wrote:

 Denis Koroskin wrote:
 

 Then I assume you still want to restrict the precondition to being the
 first element in the body? Because putting it in there suggests that it
 may appear anywhere a statement can.


 Why not?


 
 Because a function precondition indicates the set of admissible states
 before execution of a function. Emphasis on *before* and *function*.


I would expect the precondition/postcondition to behave exactly as a 
nested function, (except that it is automatically executed before/after 
the first/last statement in the function is executed), so the lexical 
order shouldn't matter. If they were implemented as pure nested 
functions, they could safely call other pure nested functions -- so 
allowing them to be later in the function would potentially be useful.

It would be strange to put outer function statements before the 
precondition, but that's true of any inner function.



 Aug 03 2009



  parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com>  writes:


Don wrote:


 It would be strange to put outer function statements before the
 precondition, but that's true of any inner function.


I don't see it as an inner function, but as a part of the public interface.
It's an enforceable documentation of the function.

-- 
Michiel Helvensteijn



 Aug 03 2009



  parent reply Don <nospam nospam.com>  writes:


Michiel Helvensteijn wrote:

 Don wrote:
 

 It would be strange to put outer function statements before the
 precondition, but that's true of any inner function.


 
 I don't see it as an inner function, but as a part of the public interface.
 It's an enforceable documentation of the function.


I agree, except that I don't see any reason why a special inner function 
cannot be part of the public interface. I don't think it makes any 
difference where it is appears in the code.
In my experience, most of the code in the precondition frequently gets 
duplicated in the function itself. But that's secondary -- I just want 
to get rid of 'body'.

The stronger argument against the 'inner function' syntax is the case 
when you have an interface, which naturally has no body, but still has 
an 'in' contract. Where does the contract go?

I refuse to believe that the optimal solution to that problem involves 
the 'body' keyword.



 Aug 03 2009



 next sibling parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 03 Aug 2009 11:47:49 -0400, Don <nospam nospam.com> wrote:


 Michiel Helvensteijn wrote:

 Don wrote:


 It would be strange to put outer function statements before the
 precondition, but that's true of any inner function.


  I don't see it as an inner function, but as a part of the public  
 interface.
 It's an enforceable documentation of the function.


 I agree, except that I don't see any reason why a special inner function  
 cannot be part of the public interface. I don't think it makes any  
 difference where it is appears in the code.
 In my experience, most of the code in the precondition frequently gets  
 duplicated in the function itself. But that's secondary -- I just want  
 to get rid of 'body'.

 The stronger argument against the 'inner function' syntax is the case  
 when you have an interface, which naturally has no body, but still has  
 an 'in' contract. Where does the contract go?

 I refuse to believe that the optimal solution to that problem involves  
 the 'body' keyword.


Don't template constraints have a similar syntax, but no body keyword?   
Why can't that be the same for preconditions?

-Steve



 Aug 03 2009



prev sibling  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2009-08-03 11:47:49 -0400, Don <nospam nospam.com> said:


 I refuse to believe that the optimal solution to that problem involves 
 the 'body' keyword.


Then would this do?


int test(int i)
in {
	assert(i > 1);
}
out (z) {
	assert(z < 0);
}
do {
	return -i + 1;
}


Also, I wonder why we need braces everywhere in contracts. I'd like it 
if I could write:


int test(int i)
in
	assert(i > 1);
out (z)
	assert(z < 0);
do
	return -i + 1;


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Aug 03 2009



  parent reply grauzone <none example.net>  writes:


Michel Fortin wrote:

 Also, I wonder why we need braces everywhere in contracts. I'd like it 
 if I could write:
 
 
 int test(int i)
 in
     assert(i > 1);
 out (z)
     assert(z < 0);
 do
     return -i + 1;


Just bikeshedding a bit around... why not make it even simpler, and just 
leave away the body/do completely? That would finally be a syntax I'd be 
happy with. It wouldn't destroy the normal code layout too, because 
in/out contracts are fully additional syntax.

int test(int i)
   in assert(i > 1);
   out(z) assert(z < 0);
{ return -i + 1; }



 Aug 03 2009



  parent  Michel Fortin <michel.fortin michelf.com>  writes:


On 2009-08-04 02:50:23 -0400, grauzone <none example.net> said:


 Michel Fortin wrote:

 Also, I wonder why we need braces everywhere in contracts. I'd like it 
 if I could write:
 
 
 int test(int i)
 in
     assert(i > 1);
 out (z)
     assert(z < 0);
 do
     return -i + 1;


 
 Just bikeshedding a bit around... why not make it even simpler, and 
 just leave away the body/do completely? That would finally be a syntax 
 I'd be happy with. It wouldn't destroy the normal code layout too, 
 because in/out contracts are fully additional syntax.
 
 int test(int i)
    in assert(i > 1);
    out(z) assert(z < 0);
 { return -i + 1; }


That could work if the in and out blocks were alwasy one-statement 
long. That's hardly the case, and so you'd have two blocks following 
each other which I find a little strange:

int test(int i)
in {
	assert(i > 1);
}
out (z) {
	assert(z < 0);
}
{
	return -i + 1;
}

Nothing catastrophic, but in my opinion it reads better with a keyword 
in front of the last opening brace.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Aug 04 2009



prev sibling  parent  Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Mon, Aug 3, 2009 at 3:11 AM, Don<nospam nospam.com> wrote:

 Robert Fraser wrote:

 Hi, hope you're all enjoying the properties debate.

 I've been seeing the "too many keywords" argument a lot lately, and I
 think it's definitely a valid argument. "shared" and "body" in particula=




r

 are rather annoying keywords since I frequently use them in code. And if
 users are deciding not to use D because of the number of keywords, that'=




s

 even worse.


 Why not just get rid of 'body'?

 'body' is the most useless keyword in D. It's ugly, and doesn't achieve
 anything much at all -- it's just a compiler-checked comment, really.
 Almost identical to // body

 Compare:
 ----------------------
 int foo(int a)
 in {
 =A0 assert(a>2);
 }
 body
 {
 =A0 return a-1;
 }
 ----------------------
 int foo(int a)
 in {
 =A0 assert(a>2);
 }
 // body
 {
 =A0 return a-1;
 }
 ----------------------

 That's a ridiculously tiny benefit for a keyword. I hate my body.
 <g>


Seeeeconded.  It's the silliest keyword.



 Aug 03 2009



prev sibling  parent reply Michael Mittner <m.mittner shebang.at>  writes:


Robert Fraser wrote:


 Thoughts?


Maybe doing more things analog to scope(exit/etc) might be an idea, where we 
have one "major" keyword and a couple of "minor" ones that differentiate the 
meaning further.

-Mike



 Aug 03 2009



  parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


Michael Mittner wrote:

 Robert Fraser wrote:
 

 Thoughts?


 
 Maybe doing more things analog to scope(exit/etc) might be an idea, where we 
 have one "major" keyword and a couple of "minor" ones that differentiate the 
 meaning further.
 
 -Mike


Yes. Maybe every keyword could be just "keyword(...)". For example: 
keyword(static), keyword(final), etc. For example this code now:

pure SomeType foo() {
}

would be, with this change:

keyword(pure) SomeType foo() {
}

Hmm...

Or maybe:

 pure void foo() {
}

:-)



 Aug 03 2009



  parent reply Michael Mittner <m.mittner shebang.at>  writes:


Ary Borenszweig wrote:


 Yes. Maybe every keyword could be just "keyword(...)". For example:
 keyword(static), keyword(final), etc. For example this code now:
 
 pure SomeType foo() {
 }
 
 would be, with this change:
 
 keyword(pure) SomeType foo() {
 }
 
 Hmm...
 
 Or maybe:
 
  pure void foo() {
 }
 
 :-)


For future extensibility it should be

<keyword type="pure"> SomeType foo() { /* ... */ }

;)



 Aug 03 2009



 next sibling parent  Michiel Helvensteijn <m.helvensteijn.remove gmail.com>  writes:


Michael Mittner wrote:


 For future extensibility it should be
 
 <keyword type="pure"> SomeType foo() { /* ... */ }
 
 ;)


You forgot the closing tag.

-- 
Michiel Helvensteijn



 Aug 03 2009



prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Mon, Aug 3, 2009 at 2:20 PM, Michael Mittner<m.mittner shebang.at> wrote:

 Ary Borenszweig wrote:


 Yes. Maybe every keyword could be just "keyword(...)". For example:
 keyword(static), keyword(final), etc. For example this code now:

 pure SomeType foo() {
 }

 would be, with this change:

 keyword(pure) SomeType foo() {
 }

 Hmm...

 Or maybe:

  pure void foo() {
 }

 :-)


 For future extensibility it should be

 <keyword type="pure"> SomeType foo() { /* ... */ }

 ;)


You referring to that blogger who said he was "ready for languages
with keywords enclosed in XML tags" after seeing a D presentation?  ;)



 Aug 03 2009



  parent  Michael Mittner <m.mittner shebang.at>  writes:


Jarrett Billingsley wrote:


 You referring to that blogger who said he was "ready for languages
 with keywords enclosed in XML tags" after seeing a D presentation?  ;)


No, I didn't see that one.



 Aug 04 2009



prev sibling  parent reply Daniel Keep <daniel.keep.lists gmail.com>  writes:


Michael Mittner wrote:

 Ary Borenszweig wrote:
 

 Yes. Maybe every keyword could be just "keyword(...)". For example:
 keyword(static), keyword(final), etc. For example this code now:

 pure SomeType foo() {
 }

 would be, with this change:

 keyword(pure) SomeType foo() {
 }

 Hmm...

 Or maybe:

  pure void foo() {
 }

 :-)


 
 For future extensibility it should be
 
 <keyword type="pure"> SomeType foo() { /* ... */ }
 
 ;)


<function-declaration>
    <pure>true</pure>
    <returnType>SomeType</returnType>
    <name>foo</name>
    <parameters/>
    <body>
        <comment> ... </comment>
    </body>
</function-declaration>

<smilie>:)</smilie>

Using elements instead of attributes allows you to put arbitrary
subexpressions as the value.  :D



 Aug 03 2009



  parent  Robert Fraser <fraserofthenight gmail.com>  writes:


Daniel Keep wrote:

 <function-declaration>
     <pure>true</pure>
     <returnType>SomeType</returnType>
     <name>foo</name>
     <parameters/>
     <body>
         <comment> ... </comment>
     </body>
 </function-declaration>


Ah, you saw the announcement for Microsoft's new .NET language?



 Aug 05 2009