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 
at C#: "get", "set", "value", "event", "var", etc. are only 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?
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
 at C#: "get", "set", "value", "event", "var", etc. are only 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?

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

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

isn't to make them free for use, it's more to reduce the number of people bitching about how many keywords there are.

available keywords to be remembered doesn't decrease.

that we'll run short of identifier space in the conceivable future :-) The real problem is remembering the keywords.

the wars about "enum". Overloading keywords is MUCH more confusing than reserving another word.

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.

isn't to make them free for use, it's more to reduce the number of people bitching about how many keywords there are.

available keywords to be remembered doesn't decrease.

that we'll run short of identifier space in the conceivable future :-) The real problem is remembering the keywords.

the wars about "enum". Overloading keywords is MUCH more confusing than reserving another word.

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 next sibling parent 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=

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

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=

 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

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=

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




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




 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 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 
 at C#: "get", "set", "value", "event", "var", etc. are only 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.
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. 
 Look at C#: "get", "set", "value", "event", "var", etc. are only 
 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 next sibling parent 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 inconsistency here -- C++, Java, and C# all require the braces.
Aug 02 2009
prev sibling 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 
 inconsistency here -- C++, Java, and C# all require the braces.

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: # int foo(int a) { # in { # assert(a>2); # } # # return a-1; # }
Aug 03 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Pete wrote:

 I think this is much more elegant:
 
 # int foo(int a) {
 #    in {
 #       assert(a>2);
 #    }
 #
 #    return a-1;
 # }

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:

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

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:

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

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

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

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


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

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

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


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


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

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